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!