Hochverfügbarkeit über zwei oder mehere Standorte realisieren - im Katastrophen- und Desasterfall -

Hallo,

ich beschäftige mich als Student z.Z. mit dem Thema Hochverfügbarkeit im Zusammenhang der Erreichbarkeit z.B. einer Webanwendung/Webseite, die über 2 oder mehrere geografisch getrennter Standorte angeboten wird.
Dabei geht es mir jetzt nicht darum, wie sich die beiden Seiten synchronisieren oder die HA in den einzelnen Standorten umgesetzt wird.
Meine Frage zielt darauf ab, wie ich eine nahtlose Verfügbarkeit der Anwendung realisieren kann, wenn z.B. ein Standort/Rechenzentrum (K-Fall) komplett ausfällt. Ist das überhaupt möglich? Das eine aufgebaute Session verloren geht und sich der Nutzer evtl. neu anmelden muss, spielt erstmal keine Rolle, hauptsache man kann sich gleich wieder anmelden.

Meine bisherigen Erkenntnisse:
Angenommen jeder Standort verfügt über eine eigene Internetanbindung, also jeweils eigene IPs, dann ist es ja möglich der betreffenden Domain mehrere A Resource Records im (autoritativen) DNS zu zuweisen. Ist jetzt eine IP nicht mehr erreichbar liefert der DNS immer noch alle IPs aus, auch die die nicht mehr erreichbar ist.
Selbst wenn die fehlerhafte IP im DNS gelöscht wird, haben andere DNS die falschen Informationen noch gecacht und liefern diese aus. Bis alle anderen DNS die neuen Information erhalten haben, vergeht (trotz kleiner TTL) eine gewisse Zeit, in der evtl. die „falsche“ IP ausgeliefert wird.
--> Kann man an dieser Stelle in irgendeiner Weise entgegen wirken?
--> Ich habe mich irgendwie auf die DNS Geschichte eingeschossen, gibt es noch andere „Themen/Sachen“ die ich beachten sollte?
--> Dann gibt es noch die Sache mit dem „Global Server Load Balancing“. Ist das eine reine DNS Geschichte oder evtl. eine Hersteller abhängige Technologie?
--> Weis jmd von euch wie das die „Großen“ machen, z.B. Google
--> Ich wäre über jeden, auch neuen, Ansatzpunkt (Literatur, ...) zu diesem Thema dankbar.

Viele Grüße
ByteKiller

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 157026

Url: https://administrator.de/contentid/157026

Ausgedruckt am: 22.11.2024 um 16:11 Uhr

8 Kommentare

Neuester Kommentar

Mahlzeit!

DNS - das oben angegebene Round-Robin verfahren bringt in dieser Hinsicht keine Ausfallsicherheit, da der 1. Host die erste ip, der 2. Host die zweite, der 3. wieder die erste usw. bekommt.
Dies hilft eigentlich nur um die Gesamtlast auf beiden Systemen zu verteilen.

Für ein HA wie oben beschrieben, kommt man im Normalfall um einen Load-Balancer nicht herum.

Dieser hält dann die Haupt-IP und leitet die Anfragen an die 1. oder 2. weiter, wobei bei einem Ausfall einer Seite nur noch die andere verwendet wird.

Gruß
Yali0n

Ok ein Load-Balancer, aber was passiert wenn der die Hufe hochreist?
Oder wie wird dann der Load-Balancer realisiert, an welchem Standort, etc...

Moin,

schau doch mal hier .... http://loadbalancer.org/

Gruß

24

Moin,

also ich sag mal so: Man kann sowas natürlich bauen. Ich würde dabei z.B. 2 Loadbalancer nehmen. Diese hängen an 2 verschiedenen Internet-Leitungen und sind über beide erreichbar. Zwischen den LB hast du z.B. nen Heartbeat am laufen -> fliegt einer weg dann übernimmt der zweite sofort die IP vom ersten und dessen Konfig. Idealerweise hast du sogar eine steuerbare Steckdose / Stromversorgung -> LB 2 sendet an die Stromversorgung notfalls nen Signal das die den LB1 sofort abschaltet (damit du sicher sein kannst das du keine doppelte IP hast). Hier könnte man z.B. die Kopplung von LB1 u. LB2 über ein Crosslink- oder über ein Serielles Kabel laufen lassen -> schon hast du auch kein Problem das ggf. nur der Switch grad auf Pause war...

HINTER dem Load-Balancer hast du dann die Anwendungsserver 1-n. Diese kannst du im RR-Verfahren nutzen (Lastverteilung) - und wenn einer ausfällt dann sendet der ja auch kein Heartbeat mehr -> raus aus dem RR-Verfahren.

Ob diese dann neben dem LB stehen oder ggf. eben über ne Internet-Strecke angebunden sind das kannst du dann selbst definieren -> du leitest ja jetzt eh auf die Adressen der Server weiter... Wobei man üblicherweise da natürlich Server nehmen sollte die schon in einem Rechenzentrum o.ä. stehen - und nicht grad den kleinen Applikationsserver im Büro da mit einbinden würde...

Probleme machen an der Stelle nur Datenbank-Systeme. Hier musst du etwas vorsichtiger rangehen. Hier musst du einen Master-Server haben auf dem alle Schreib- & Lesevorgänge erfolgen. Dieser darf sich dann auf die Slaves replizieren. NUR wenn der Master tod ist dann darf nen Slave zum neuen Master werden. Ansonsten hast du ggf. "Racing Conditions" -> d.h. es kann zu problemen führen wenn 2 Server gleichzeitig auf verschiedenen Datenbankservern arbeiten...

Global Server Load Balancing (GSLB) nennt man das und ist ein alter Hut und millionenfach bei RZs im Einsatz.
2 Load Balancer im Active/ Active odef Active/Standby Mode pro Location und gut iss...
F5 und Brocade/Foundry haben seit langem die Geräte für solche Standardanwendungen...

@aqui: Du meinst das wird millonenfach so betrieben, dann muss doch irgendwo stehen wie das technisch umgestezt wird. Ich geh ja mit, wenn du meinst es gibt 2 Loadbalancer pro RZ (Location). Mich würde jetzt interessieren, was genau passiert wenn ein Standort wegfällt. Ist das so technisch machbar wie maretz sagt, das die übrig gebliebenen "einfach" die IP von den "verschwundenen" übernehmen?
Und super cool wäre es, wenn du mir nen Link von z.B. einen der o.g. Hersteller gegben kannst (also vom konkreten Produkt). Ich weiß nicht nach was dort genau suchen soll

Gruß

ok das mit dem link hat sich erstmal erledigt, da war ich zu voreilig: Geographic Redundancy and Scalability

Moin,

ein gutes RZ hat ja nicht - wie du zuhause - nur ein Kabel was ins RZ geht. Hier sind üblicherweise mehrere unabhängige Verbindungen geschaltet. D.h. fliegt die Leitung A weg weil der Baggerfahrer grad meinte das er seine Schaufel mal mit Glasfaserkabel füttern möchte -> dann übernimmt Leitung B.

Ok, natürlich hast du immer nen Single point of failure. Ich sag mal so: Bügelst du z.B. bei der Denic den DECIX weg -> dann bringt es nichts mehr wenn dein RZ erreichbar ist. Denn dann hast du derart viele Kommunikationsausfälle im Netz das den Server keiner mehr wirklich erreichen kann (es sei denn der hängt zufällig im selben Provider-Netz). Allerdings steht natürlich auch bei der DENIC nicht nur ein kleiner Router in der Ecke -> auch die haben natürlich ein paar Vorsorgen getroffen...

Weiterhin gibt es natürlich noch Probleme mit den Routing-Tables. Diese wären m.E. ebenfalls als SPOF zu bezeichnen. Wie ja in diesem Jahr schonmal passiert reicht da nen falsches Update und schon trennt man ganze Netze weg weil die großen Systeme das so übernehmen (wenn man das an der richtigen Stelle macht). Wenn dein RZ jetzt z.B. das Segment 123.123.123.x besitzt aber irgendwer es schafft in die Routing-Tabellen "123.123.123.x -> GW 127.0.0.1" übernehmen zu lassen dann helfen dir auch zig redundante Verbindungen nicht mehr. Weil ja die Routing-Tabelle bestimmt das du das Netz gar nicht mehr erreichen kannst...

Von daher: Du kannst natürlich eh nur eine gewisse Ausfallsicherheit schaffen. Du bist _IMMER_ abhängig davon das eben die externen Faktoren auch stimmen. Aber zumindest in dem Bereich wäre es gar kein Problem das man z.B. beim Ausfall von Standort 1 das alles auf Standort 2 routen lässt. DAS macht dann dein Anbieter für dich - weil DER eben dann die entsprechenden Sicherungssysteme einbaut, prüft ob der Server online ist und seinen Router anweist das entsprechend zu verteilen...