Fallback Strategie für Serverausfall

Ansgar Offermanns

Ansgar Offermanns

Angesehenes Mitglied
Hiho!

Immer wenn massig Webseiten eines Hoster ausfallen, weil er umzieht oder eine Fehler gemacht hat, beschweren sich zu Recht viele Webmaster über den Ausfall ihrer Seiten mit den für sie oft schmerzhaften Konsequenzen: Verdienstausfall, Besucherschwund...

Und immer melden sich dann Leute die sagen: "Naja, wenn Deine Seite so wichtig ist, dann solltest Du eben eine FallBack-Strategie haben, für den Fall, dass sie mal ausfällt."

Doch wie könnte so ein Server-FallBack aussehen?

Wie kann ich z.B. eine Domain temporär & schnell auf einen anderen Server / Webaccount bei einem anderen Hoster umbiegen?

Was gibt es sonst noch für Möglichkeiten?

Gibt es hier überhaupt jemanden, der selbst über ausgearbeitete und realisiert FallBack-Strategien verfügt? Wenn ja: wie habt Ihr das umgesetzt und warum?


MfG
Ansgar.

 
QUOTE (St. Ansgar Böttcher @ Fr 28.03.2008, 19:43) Wie kann ich z.B. eine Domain temporär & schnell auf einen anderen Server / Webaccount bei einem anderen Hoster umbiegen?


Kannst Du in dem Sinne nicht. Du kannst vor möglichen problematischen Zeitpunkten die TTL Deiner Nameservereinträge langsam runter setzen, um dann bei einem Ausfall andere IPs einzutragen und damit ohne Cache-Verzögerung auf den neuen Server zu resolven.

Andere Möglichkeiten:
Einer meiner Hoster hat eine Standleitung zwischen zwei Rechenzentren. Über diese werden die Server gespiegelt. Fällt der Server aus, stellt jemand im RZ das Routing um. Fertig. Allerdings bleibt eine Ausfallzeit.

Andere Lösungen setzen auf vorgeschaltete Logik, die den Traffic verteilt. Die RZ-Betreiber haben zumindest hier ganz nette Lösungen im Managed Bereich.

Abgesehen davon brauchst Du natürlich Backups etc.
 
Ich habe folgende Fallbackstrategie:

1. Der Nameserver MUSS unter VOLLER Eingekontrolle stehen.
Wenn der Nameserver auch beim selben Hoster ist, wird es schwierig, falls mal was nicht geht!

2. Load-Balancing für HTTP:80
Meine Domains sind auf 3 Servern gehostet:
QUOTE nslookup adserver.*.ch

Nicht autorisierte Antwort:
Name: adserver.*.ch
Addresses: 91.135.65.*, 87.230.17.*, 91.135.66.*



Das bedeutet:
Wenn 91.135.66.* abraucht, gehen die Anfragen auf 87.230.17.* wenn der auch weg ist, geht es auf 91.135.65.*.
Eine Kiste steht in Zürich, eine in Deutschland und eine bei mir zuhause.

Die OS sind:
Einmal Win2003, Debian, SuSe

Somit sollte ein definitves abrauchen der HTTP Verfügbarkeit vermeidbar sein.

3. Mail
Ein oder zwei Backup Mailserver. Wenn die ZEIT der Zustellung (Falls primary abraucht) EGAL ist.

MySQL
Was noch ein Problem ist, ist MySQL.
Der läuft inzwischen recht stabil auf einem eigenen Server.

Demnächst gibt es einen MySQL Cluster.

Kosten
Diese Übung war nicht ganz günstig!
Einmalig: ca. CHF 5'000.-
Setup: ca. CHF 500.-
Monatlich: ca. CHF 300.-

Dies ist aber meine persönlcihe Spielwiese. Vernünftig umsetzbar solle es mit ca. CHF 50.- im Monat sein...
 
QUOTE (sd12 @ Fr 28.03.2008, 23:54) 2. Load-Balancing für HTTP:80
Meine Domains sind auf 3 Servern gehostet:

QUOTE nslookup adserver.*.ch

Nicht autorisierte Antwort:
Name: adserver.*.ch
Addresses: 91.135.65.*, 87.230.17.*, 91.135.66.*



Das bedeutet:
Wenn 91.135.66.* abraucht, gehen die Anfragen auf 87.230.17.* wenn der auch weg ist, geht es auf 91.135.65.*.
Eine Kiste steht in Zürich, eine in Deutschland und eine bei mir zuhause.


Hi,
Bist Du sicher, dass das funktioniert? Die A-Records haben im Gegensatz zu den MX Records keine Prioritäts-Attribute. Ist IMHO ein reines Load-Balancing, aber kein Fail-Over
martin
 
QUOTE (Martin J @ Sa 29.03.2008, 00:00) Bist Du sicher, dass das funktioniert? Die A-Records haben im Gegensatz zu den MX Records keine Prioritäts-Attribute. Ist IMHO ein reines Load-Balancing, aber kein Fail-Over

Hast mich verunsichert...

Dann hab ich den primary Apache abgeschossen und die Seite war weiterhin erreichbar...


QUOTE Eine Domain oder Subdomain enthält mehrere IP Adressen, gemäss AUX Prioritäten werden die Clients auf die Server verteilt.


Wie es genau funktioniert ist mir auch noch nicht klar...

ISt ist eine Mischung aus LoadBalancing und Failover...
 
Hmm, ich bin ja selbst nicht sicher. Ich habe jetzt mal Deinen Adserver angepingt. Von einem Server aus verteilt sich jeder neue Ping-Aufruf gleichmaessig auf die drei IPs. Von einem anderen Server gehen die Pings immer auf den ersten Eintrag (91.135.66.*)??? Vielleicht cacht bei letzterem Server der DNS(in meinem RZ) die Einträge über die TTL hinaus?

Verstehen tue ich das ganze ehrlich gesagt nicht. Werde es mal selber ausprobieren, glaube aber noch nicht so recht daran.
 
QUOTE 1. Der Nameserver MUSS unter VOLLER Eingekontrolle stehen.
Wenn der Nameserver auch beim selben Hoster ist, wird es schwierig, falls mal was nicht geht!

Das denke ich ist das A und O.

Alle wirklich wichtigen Projekte habe ich immer noch auf Servern bei andern Providern installiert. Bei einem Serverausfall muss ich nur die ein aktuelles DB Backup einspielen und den NS Eintrag ändern. Nach ein paar Stunden läuft alles wieder.
Eine großartige FallBack Strategie ist das nicht, aber einen Ausfall von ein paar Stunden ist für mich tolerierbar. Zum Glück kommt das nur sehr selten vor.
Ein Problem hätte ich allerdings wenn der Provider komplett ausfallen würde wo ich die meisten Server habe. Weil das dann erstens zuviele Anwednungen wären um das kurzfristig umzuschalten und auch hätte dann auch nicht genug Backupserver.
Das ist das Restrisiko

 
QUOTE (St. Ansgar Böttcher @ Fr 28.03.2008, 18:43)Und immer melden sich dann Leute die sagen: "Naja, wenn Deine Seite so wichtig ist, dann solltest Du eben eine FallBack-Strategie haben, für den Fall, dass sie mal ausfällt."


Ich halte das für völlig illusorisch - abgesehen von einem Fall: Einer rein statischen Html-Seite, die auf dem lokalen Rechner drauf ist und die sich per FTP auf den neuen Server hochladen läßt. Dann würde sich die Ausfallzeit auf den Nameserver-Wechsel reduzieren.


QUOTE (St. Ansgar Böttcher @ Fr 28.03.2008, 18:43)Wie kann ich z.B. eine Domain temporär & schnell auf einen anderen Server / Webaccount bei einem anderen Hoster umbiegen?


Man darf gar nicht erst in so eine Situation kommen. Sprich: Das Problem entscheidet sich im Vorfeld.

Ich kann bsp. ein so komplexes Gebilde wie server-daten nicht auf die Schnelle bei einem anderen Hoster unterbringen, das wäre völlig illusorisch. Für hinreichend komplexe Webanwendungen (Shops, eigenprogrammierte Anwendungen) dürfte dasselbe gelten. Ich kann mir aber per SLA einen raschen Austausch der Hardware bei möglichen Defekten zusichern lassen. Plus nächtliche Sicherung, Qualitätshardware, entsprechende Infrastruktur. Das heißt: Provider mit eigenem Rechenzentrum, eigenem technischen Personal, der Arbeiten an der Hardware nachts erledigt.

Im Prinzip ist das ganz einfach: Man sollte auf den Preis achten - allerdings im umgekehrten Sinne dessen, wie so eine Aussage üblicherweise verstanden wird. Wenn ein Angebot zu günstig ist, dann kann es gewisse Dinge nicht leisten. Und Anbieter, die mit ihrem Preis werben, scheiden damit im Zweifelsfall aus. Entweder Premium oder günstig - beides zusammen ist für mich ein Widerspruch.

PS: Klar: Teuer heißt noch nicht 'Premium'.

PPS: Angesichts der anderen Antworten: Klar, man kann sozusagen verschiedene Hoster 'gegeneinander ausspielen' - klappts beim einen nicht, dann vielleicht beim nächsten. Ich ziehe da allerdings eine 'Ein-Hoster-Strategie' vor und mache um andere Anbieter einen Bogen. Wie sich ein Angebot rechnet, kann man ja oft an den Preisen ablesen (Einnahmen pro Angebot * Festplatten-Größe / Angebotsgröße - Serverkosten). Wenn dann kaum mehr Luft ist, dann bleibt kein Geld mehr für gutes Personal. Und schlechtes Personal führt bei technischen Defekten zu neuen Problemen.
 
Das von sd12 beschriebene Setup ist kein Loadbalancing, sondern Failover.

Problematisch ist bei jeder derartigen Lösung, die Daten auf den verteilten Büchsen in sync zu halten. Was bei statischen Seiten kein Problem darstellt, wird bei dynamischen Applikationen schnell sehr schwierig (== teuer).
 
QUOTE (mainlink @ Sa 29.03.2008, 19:05) Problematisch ist bei jeder derartigen Lösung, die Daten auf den verteilten Büchsen in sync zu halten. Was bei statischen Seiten kein Problem darstellt, wird bei dynamischen Applikationen schnell sehr schwierig (== teuer).

wink.gif
genau :)

Ich habe einen Master Server2003, welcher die Daten hat.

Diese Synct dann immer mit allen Servern...

...Config und spezielle Files sind excludet.
 
QUOTE (mainlink @ So 30.03.2008, 17:46) Darf ich fragen, wie weit die voneinander entfernt sind?

Darf ich das als Frage der Datensicherheit ansehen?
 
Na, ich wüßte gerne, ob das über eine weitere Strecke (sprich: außerhalb des Racks) möglich ist.
 
QUOTE (mainlink @ Mo 31.03.2008, 04:59) Na, ich wüßte gerne, ob das über eine weitere Strecke (sprich: außerhalb des Racks) möglich ist.


QUOTE (sd12)Eine Kiste steht in Zürich, eine in Deutschland und eine bei mir zuhause.



Das wäre ein ziemlich grosses Rack.
wink.gif
 
Ja, es ist über grosse Strecken möglich:

Server2003: Storage kein WebServer Standort: Bülach
Win XP: WebServer/Mailserver (web3.*.ch Standort: Bülach
Server2003: Webserver/DB Server/Mailserver (web1.*.ch) Standort: RZ Zürich equinix I
SuSe: Webserver (web2.*.ch) Standort RZ HostEurope, irgendwo in Deutschland
Debian: Webserver (web4.*.ch) Standort RZ Zürich equinix II
Linux: Webserver web5.*.ch) Standort RZ HostMonster, irgendwo in USA
 
Ich hoffe, niemanden zu langweilen, wüßte aber gerne, in welchem Rhythmus die DBs synchronisiert werden (nach jedem Commit oder nach X Sekunden?).
 
Ein wirklich gutes Rechenzentrum fällt nicht aus (d.h. wie immer nur das die Wahrscheinlichkeit wesentlich geringer ist) das Problem ist also eher was in einem Serverausfall passiert.
Prävention ist sicher wichtig, aber ein Ausfall läst sich nicht ausschließen, und ist der Server wichtig genug muss man schon einen Plan und Vorkehrungen für die diversen Notfälle haben,

Die Antwort sieht man bei größeren Sites eigentlich recht gut. Fällt einer der Webserver aus teilt der Loadbalancer dem Server keine Besucher mehr zu, fällt einer der DB-Server vom DB-Cluster aus übernehmen andere die Arbeit. Im Detail braucht es dafür natürlich schon ein gutes Konzept, bei den Sites die mir genauer bekannt sind funktioniert es aber so, wenngleich mit sehr unterschiedlichen Umsetzungen.

Das Problem beginnt natürlich dann wenn man eben keinen kleinen Server-Cluster hat, da sind down-times einfach nicht vermeidbar.

Klar kann ich ein super SLA haben, nur wenn der Server nicht richtig funktioniert und nicht sofort klar ist ob es ein Hardwarefehler oder ein Software-Fehler ist nützt das beste SLA nichts. Daneben hat man auch noch das Problem das man wenn nicht schon mal ein schwerwiegendes Problem eingetreten ist eigentlich nicht weiß wie gut das SLA auch eingehalten wird, bei den meisten Anbietern im unteren aber auch mittleren Segment ist die Reaktionszeit außerhalb der Geschäftszeiten schlicht Glückssache.

Auf das Backup vom Provider sollte man sich alleine auch nicht verlassen. Wenn im schlimmsten Fall die Daten weg sind nützt es einem nicht wirklich was dass der Provider Mist gebaut hat, da selber regelmäßig Daten zu sichern macht sich bezahlt.

Sehr viel hat da einfach mit Geld zu tun, wer ein wirklich gutes Rechenzentrum sucht soll einfach mal schauen wo mittlere Sites (kein Yahoo aber doch welche mit zig Millionen oder ein paar Hundert Millionen Seitenaufrufen) unterkommen.
Nur muss man da halt auch deutlich tiefer in die Tasche greifen, ein gemanagter Server kommt in einem Hochsicherheitsrechenzentrum deutlich teurer als bei guten Maßenhostern.
 
QUOTE (hatschi1810 @ Mi 2.04.2008, 20:22)Ein wirklich gutes Rechenzentrum fällt nicht aus (d.h. wie immer nur das die Wahrscheinlichkeit wesentlich geringer ist) das Problem ist also eher was in einem Serverausfall passiert. [...]

Also beim Anfang des Satzes dachte ich hier erstmal an einen Witz.

Nicht umsonst bauen Anbieter mehrere - miteinander verbundende - Rechenzentren auf, da die Wahrscheinlichkeit einfach noch zu hoch ist, dass eines ausfällt. Für wichtige Daten werden dann sogar noch so genannte Lampertz-Zellen eingerichtet, die gegen Einwirkungen von Außen und gegen Feuer im Inneren der Zelle schützen sollen, welche im Falle eines Falle nur die Daten sichern sollen und nicht den Ausfall der Systeme.
Klar ist die Wahrscheinlichkeit eines Serverausfalls wesendlich höher, was bei ca. 2000 Server Alltagsgeschäft ist, nichts desto trotz kann auch immer noch ein Rechenzentrum ausfallen, wobei es viele Möglichkeiten für geben kann. Für mich ist ein Ausfall dann gegeben, wenn die rechenzentrumseigene Standortverbindung zum Internet unterbrochen ist, aus welchen Gründen auch immer (Murphy ist allgegenwärtig). Dies muss nicht mal heißen, dass die Server nicht mehr erreichbar sind, denn die Verbindung kann ja auch über die eigene Vernetzung vom anderen Rechenzentren kommen. Ein Ausfall würde in meinen Augen dann aber bereits vorliegen.


Bei einen Loadbalancerkonzept, ist leider meinstens der Loadbalancer selber der Wunde Punkte, d.h. ein Loadbalancer alleine würde für ein Ausfallkonzept nicht unbedingt genügen. Es muss hierbei aber ganz klar unterschieden werden, zwischen Kostenaufwand (Was zahlt der Kunde dafür?), technischer Machbarkeit (Welche Applikation? usw.) und praktischer Umsetzbarkeit (Menschen machen auch Fehler oder auch Murphy: "Wenn etwas schief geht, dann geht alles schief.").


Der letzte Satz hat viel Wahres. Leider muss ich sagen, dass in diesen Forum, sich zumindestens vor knapp einen Jahr leider die gleiche Sache immer wieder vorfinden ließ, in den die Leute sich oftmals über Ausfälle beschweren, aber auch oft im gleichen Zug keinen wirklichen Preis für Web-/Serverhosting bezahlen wollten. Und hierbei sind nicht nur von 400 EUR Servermiete im Monat die Rede, sondern von einen komplett anderen Preissegment.


In dem Sinne: http://www.tcp-ip-info.de/fun/murphy.htm / http://www.tcp-ip-info.de/fun/computer_murphy.htm




Mich persönlich würde das Konzept hinter sd12s Ausfallstratigie auch sehr interessieren und welche Ausrichtung dieses Konzept hat. Wird ein Microsoftcluster eingesetzt? Welche Datenbank wird eingesetzt? Wwie sind dort die Ausfallsenarien geplant? Ist ggf. sowas wie ein konkorierender Zugriff auf das Dateisystem (Cluster-Dateisystem) (für die Datenbank) möglich?



MfG Sascha
 
SD12 ist eine faule Sau...
...Er hat einen MySQL ist aber zu bequem den MySQL Cluster einzurichten.

Die Systeme sind gemischt, wie Du ein paar Beiträge weiter oben lesen kannst.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben