Transparent redirect eller fejlmeddelelse

Jeg har to webservere, den ene er altid online og den anden er ikke.

Den server, der altid er online og kan tilgås med et domæne foobar.tld (server1).
Den server, der nogle gange er online, kan tilgås med et subdomæne baz.foobar.tld (server2).

Jeg godt kunne tænke mig, at få en pæn fejlmeddelelse hvis baz.foobar.tld (server2) ikke er tilgængelig.

Jeg tænker, at jeg kan sætte en ny vhost op på server1, med subdomæne baz.foobar.tld og pege DNS til den server.

Hvad vhosten så skal gøre er at tjekke om server2 er oppe, og hvis dette er tilfældet, så skal den redirecte browseren til server2s IP, uden at brugeren opdager noget. Requesten skal altså stadig indholde domæne, baz.foobar.tld. Og den vhost på server2 skal svare.

Hvis serveren derimod ikke er oppe, så skal server1 svare browseren med en fejlmeddelelse.

Jeg er ikke i tvivl om, at det er muligt at lave dette setup, men min manglende erfaring på området gør, at jeg ikke lige ved, hvilken teknologi jeg skal gribe ud efter.

Har I nogle forslag til, hvordan jeg får lavet et sådanne setup?

På forhånd tak.
MVH
qed

qed (1) skrev:

så skal den redirecte browseren til server2s IP, uden at brugeren opdager noget.

Det kan ikke lade sig gøre. Hvis der redirectes til en URL med IP adressen, så er det den URL som brugeren vil se. Du kan lave en grim løsning med frames. En sådan løsning vil måske se fornuftig ud for det utrænede øje. Men ser jeg sådan en løsning, så tænker jeg at udvikleren er inkompetent.

Under alle omstændigheder vil jeg på det kraftigste fraråde at du baserer dig på URLer med IP adresser i. I langt de fleste tilfælde er det bedre at sætte et domænenavn mere op end det er at bruge en IP adresse i URLen.

Det spørgsmål jeg har lige nu er hvorfor du ikke bare lægger begge sites på den server der oftere er oppe. Svaret på det spørgsmål vil gøre det langt nemmere at foreslå en fornuftig løsning.

Uden at vide mere om dit setup er det bedste forslag jeg kan komme med at bruge en reverse proxy. På den server som oftest er oppe sætter du en reverse proxy op som kan sende requests videre til den server som ikke altid er oppe. Så kan du selv styre fejlmeldingen i proxyen.

Da du skal have både proxy og webserver til at køre på samme maskine skal du enten køre dem på forskellige portnumre eller tildele serveren to IP adresser.

Hvis du vil have at den webserver stadigvæk kan tilgås uden at gå gennem proxy, så er du nødt til at have to offentlige IP adresser på serveren. Hvis du i stedet vælger at køre webserveren på en intern IP adresse eller et andet portnummer, så kommer brugere til at gå gennem proxyen til begge webservere.

kasperd (2) skrev:

Det kan ikke lade sig gøre. Hvis der redirectes til en URL med IP adressen, så er det den URL som brugeren vil se. Du kan lave en grim løsning med frames. En sådan løsning vil måske se fornuftig ud for det utrænede øje. Men ser jeg sådan en løsning, så tænker jeg at udvikleren er inkompetent.

Under alle omstændigheder vil jeg på det kraftigste fraråde at du baserer dig på URLer med IP adresser i. I langt de fleste tilfælde er det bedre at sætte et domænenavn mere op end det er at bruge en IP adresse i URLen.

Tak for svar. Det var aldrig meningen at bruge adresser med IP'er eller frames. Jeg troede, at det måske var muligt at lade server1 give browseren en 3xx HTTP response, som fortalte browseren at den skulle "videresende" sin forespørgsel til server2 i de tilfælde, hvor den er oppe. Og at alt dette kunne være helt transparent for brugeren.

kasperd (2) skrev:

Det spørgsmål jeg har lige nu er hvorfor du ikke bare lægger begge sites på den server der oftere er oppe. Svaret på det spørgsmål vil gøre det langt nemmere at foreslå en fornuftig løsning.

Uden at vide mere om dit setup er det bedste forslag jeg kan komme med at bruge en reverse proxy. På den server som oftest er oppe sætter du en reverse proxy op som kan sende requests videre til den server som ikke altid er oppe. Så kan du selv styre fejlmeldingen i proxyen.

Da du skal have både proxy og webserver til at køre på samme maskine skal du enten køre dem på forskellige portnumre eller tildele serveren to IP adresser.

Hvis du vil have at den webserver stadigvæk kan tilgås uden at gå gennem proxy, så er du nødt til at have to offentlige IP adresser på serveren. Hvis du i stedet vælger at køre webserveren på en intern IP adresse eller et andet portnummer, så kommer brugere til at gå gennem proxyen til begge webservere.

Grunden til, at jeg ikke kan lægge begge sites på server1 er, at den hostes hos en udbyder, hvor server2 står lokalt hjemme hos mig og ikke altid er tændt. Selvom det ikke altid vil være muligt at tilgå de services, der kører på server2, ville det stadig være rart at have mulighed for at vise en pæn meddelelse i de tilfælde.

Af de to muligheder du nævner, tror jeg bare jeg bruger et ekstra (sub)domæne og redirecter til dette, i de tilfælde hvor server2 faktisk er oppe. Den løsning er ikke transparent for brugeren, men det er ikke super kritisk - det ville bare være rart.

2 sites på Server 1

Site 2 tjekker i din backend kode om Server 2 kører. Hvis den kører så lvaer du en Response Redirect til Server 2. hvis den ikke kører så viser du en pæn fejl side.

mfriis (4) skrev:

Hvis den kører så lvaer du en Response Redirect til Server 2.

Skal det forstås sådan at du vil have at alt trafikken på det domæne til at gå gennem hosting udbyderen?

Så vidt jeg ved kan man med mod_rewrite i apache få apache til at hente indholdet fra en anden URL. Men jeg kender ikke nogen måde at forhindre apache i at prøve på det, hvis den anden server er nede.

Uanset om man implementere det i apache konfigurationen, som et script (php eller cgi) eller med en reverse proxy, så kommer man til at bruge ekstra båndbredde gennem hostingudbyderen.

En løsning som måske er at foretrække i den konkrete situation er at bruge et dynamisk DNS navn. Hvilken udbyder man anvender er ikke så afgørende, men dyndns.dk er et fornuftigt bud.

Når serveren derhjemme starter op skal den opdatere DNS navnet til at pege på sig selv. Serveren kunne også opdatere DNS, når den lukker ned. Men det er ikke den mest pålidelige løsning. I stedet skal du have et cron job til at køre hvert 10. minut et andet sted (f.eks. host hostingudbyderen). Dette cron job skal undersøge om serveren derhjemme svarer, og hvis ikke den gør det, skal det ændre DNS navnet så det peger på hostingudbyderen.

Nu kan det sagtens være at det underdomæne du gerne vil flytte frem og tilbage på den måde ikke kan opdateres dynamisk. Det er ikke noget problem. Du lader bare underdomænet være et CNAME, som peger på hostnavnet hos dyndns udbyderen. Dermed kan du også nemt skifte til en anden udbyder af dynamisk DNS.

Jeg kan rimeligt nemt lave en DNS server, som kan lave funktionalitet i lighed med ovenstående helt uden at man selv skal opdatere hostnavnene. Jeg ville simpelthen lade DNS serveren kontakte webserveren for at se om den er oppe. Eneste begrænsning i det jeg har mulighed for at sætte op er, at trafikken mellem recursive resolver og autoritativ DNS server skal køre over IPv6. Det er ikke noget problem, hvis man bruger en seriøs DNS udbyder som f.eks. Googles DNS servere.

kasperd (5) skrev:

Nu kan det sagtens være at det underdomæne du gerne vil flytte frem og tilbage på den måde ikke kan opdateres dynamisk. Det er ikke noget problem. Du lader bare underdomænet være et CNAME, som peger på hostnavnet hos dyndns udbyderen. Dermed kan du også nemt skifte til en anden udbyder af dynamisk DNS.

Aha! Løsningen med at bruge et CNAME entry, som peger på en dyndns.dk-adresse havde jeg ikke tænkt på. Tak for det!

Allerede nu har jeg lavet det sådan, at når serveren herhjemme starter op, så fortæller den server1 sin IP. På den måde kan server1 altid se hvorvidt server2 er oppe, via et cronjob som du nævner.

Jeg vil udvide løsningen til at benytte CNAME-tricket.