Das Dokument beschreibt die Implementierung eines Managed Multisite Failover Clusters (MMFC) zur Erhöhung von Verfügbarkeit und Uptime bei Servern. Es werden aktuelle Herausforderungen, Anforderungen an das System sowie Netzwerk- und Linux-Implementierungsdetails präsentiert. Ziel ist es, eine georedundante, ausfallsichere Infrastruktur mit optimierter Routing- und Lastverteilung zu schaffen.

1. 1
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday

2. 2
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
REDUNDANTER LINUX FAILOVER CLUSTER
… WIE KANN ICH MEINE VERFÜGBARKEIT UND MEINE UPTIME ERHÖHEN?
https://xkcd.com/705/

3. 3
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
THEMEN
1. MOTIVATION / AUSGANGSLAGE
2. SPIELRAUM UND ANFORDERUNGEN
AN MMFC VER. 2
3. NETZWERK
4. LINUX IMPLEMENTATION MMFC
5. DEMO

4. 4
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
MOTIVATION / AUSGANGSLAGE
VORHANDENE SITUATION
• Bisherige bestehende Failover Systeme sind in einem Datacenter
• Vorteile:
• KISS: Keep it simple [and] stupid
• Ausfallsicherheit mit Redundanz gegenüber Hardware Fehler (Server, Netzwerk,
Power)
• Redundanz im Netzwerk-Design (alles ist redundante aufgebaut und
eingestöpselt)
• Failover ist schnell
• Schwächen:
• Connectivity - Bei einem «fettem» Netzwerk-Verkehr wie DDoS auf einen
beliebigen Host im gleichen Rack oder auch Datacenter sind auch andere
Serversysteme und so auch die Failover Systeme betroffen

5. 5
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
SPIELRAUM FÜR MMFC 2.0
MANAGED MULTISITE FAILOVER CLUSTER
Wünsche an ein neuen Multisite Failover Cluster System:
• Betrieb ist standortunabhängig (räumlich und entfernt örtlich) georedundant ✔
• Betrieb hat mehr als einen Stromlieferanten und USVs Strom 2x ✔
• Gespiegeltes Server und Cluster System HW 2x ✔
• Redundanz im Netzwerk (Core, Distribution, Upstream) Netzwerk ✔
• Dedizierter Quorum Server für Königsmacher an einem dritten Standort Quorum ✔
• Gleichbleibende IPs unabhängig vom aktiven Standort (Multisite Virtual IPs) IPv4 ✔

6. 6
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
SPIELRAUM FÜR MMFC 2.0
MANAGED MULTISITE FAILOVER CLUSTER
Linux Server – Netzwerk Wünsche zur Konnektivität:
• Netzwerk zum Server wird per LACP gebündelt Switchausfall ✔
• Announcing der Route per BGP an beide Distribution RouterDistribution Router Ausfall ✔
• Unabhängige Core Router Router Ausfall ✔
• Multi Upstream ProviderUpstream Ausfall ✔
Datacenterausfall:
• Switching muss dann sehr schnell gehen, aber im Normal- BGP mit BFD ✔
Fall wollen wir vom Routing her träge sein
• Inhalte sollen dann schnell ausgeliefert werden Caching ✔ ggf. mit Vorglühen
Bestehende Resourcen nutzend
• Lastspitzen werden optimal mit der bestehenden Infra- Load Balancer ✔
struktur abgedeckt

7. 7
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERK
VORHANDENE SITUATION NINE.CH BACKBONE
• Layer3 only Backbone
• Segmentierte IP Bereiche
• OSPF zwischen Core Routern und Core zu Distribution Layer
• BGP nur auf Core Layer
• Brocade VCS Fabrics pro Segment Distribution/Access
• Redundanz
Schwächen:
• Keine aktive Kommunikation mit einem Server wie sein „Status“ ist
• IP Adresse „kann“ nur an „einem“ Ort im Netz vorhanden sein

8. 8
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERK
PROBLEM ZUR LÖSUNG?
• Protokolle
OSPF, IS-IS, Static, RIP(v2), BGP
• Failover
Ausfall Server
Ausfall Router
Auf Befehl
• Speed
Protokoll träge und langsam
• Sicherheit
Wer darf was senden?

9. 9
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERK
LÖSUNG NETZWERK SICHT
• Distribution Layer spricht BGP mit Server
• Communities
• Aktive Sessions mit oder ohne Prefix
• Prefix Filter
• Redistributing in OSPF
• Segmente sprechen iBGP untereinander
• BFD in Richtung Server aktiv
• Kein iBGP zwischen Distribution und Core
• Failover nach ca. 500ms
• BGP Sessions zu beiden Routern pro Segment
• Aktive BGP Sessions an beiden Standorten mit aktiven Prefixes

10. 10
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
LINUX IMPLEMENTATION
BGP HANDLING AUF DEM SERVER
BIRD Internet Routing Daemon (http://bird.network.cz)
für die eBGP Kommunikation zwischen den Servern und Netzwerk Endpunkten
• Always – on: 2 x 2 BGP Sessions hin zu 2 Routern
• IPs können zwischen den beiden Hosts und DCs innerhalb von 2 Sekunden effektiv
migriert werden
• BFD Fail Action ist schneller
• Die Linux Routing Table gibt dynamisch bekannt, welche IP auf dem Host aktiv ist …
• … und so auch per BGP exportiert wird.

11. 11
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
LINUX IMPLEMENTATION
SAVE STATE HANDLING
3 Node Clusters mit Quorum
• Was passiert, wenn ein Multisite Failover Cluster Node und der Quorum Node ausfallen?
• Multisite DRP

12. 12
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
DEMO
SERVICE MIGRATION

13. 13
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
Nine Internet Solutions AG
Albisriederstr. 243a
CH-8047 Zürich
Tel +41 44 637 40 00
Fax +41 44 637 40 01
info@nine.ch
FRAGEN?

14. 14
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
Nine Internet Solutions AG
Albisriederstr. 243a
CH-8047 Zürich
Tel +41 44 637 40 00
Fax +41 44 637 40 01
info@nine.ch
DANKE FÜR DIE
AUFMERKSAMKEIT!