Post on 15-Feb-2017
transcript
1
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
THEMEN1. MOTIVATION / AUSGANGSLAGE
2. SPIELRAUM UND ANFORDERUNGEN
AN MMFC VER. 2
3. NETZWERK
4. LINUX IMPLEMENTATION MMFC
5. DEMO
4
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
MOTIVATION / AUSGANGSLAGEVORHANDENE 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
• Gesamter Ausfall eines Datacenters (Stromunterbruch,
Netzwerk-Fehl-Konfiguration, Naturgewalten) ist nicht abgedeckt
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
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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERKVORHANDENE 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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERKPROBLEM 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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
NETZWERKLÖ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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
LINUX IMPLEMENTATIONBGP 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
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
LINUX IMPLEMENTATIONSAVE STATE HANDLING
3 Node Clusters mit Quorum
• Was passiert, wenn ein Multisite Failover Cluster Node und der Quorum Node ausfallen?
• Multisite DRP
12
TECHTALKTHURSDAY MULTISITE FAILOVER CLUSTER / ÖFFENTLICH ROMAN PLESSL Version 1.0
Version 1.0
#TechTalkThursday
DEMOSERVICE MIGRATION
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
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!