Clustering

Vortrag für die .NET Users Group KA am 14.04.2005

Stefan Falksfalk@ct-systeme.com

Wozu Cluster?

Redundanz Ausfallzeiten verringern!

Lastverteilung Mehr User abdecken, als es eine

einzelne Maschine könnte Aber mit einheitlicher Konfiguration

Zwei Clustertechnologien

Server Cluster Vorranging für statusbehaftete Dienste

File und Print SQL Server Exchange Server

Network Load Balancing Cluster Vorrangig für nicht statusbehaftete

Dienste Web Server

Server Cluster

Zuerst verfügbar in Windows NT Server 4.0 Enterprise Edition Damals Codename „Wulfpack“

Prinzip: Mehrere Server greifen auf gemeinsame Festplatten zu

Bei Ausfall eines Rechners übernimmt der andere die Dienste

Aufbau eines Serverclusters

Boot

Boot

priv

at

öffentlich

öffentlich

Daten

Benötigte Hardware

Mindestens 2 NICs pro Knoten 1 private

Nur Verbindung untereinander Nur 2 Knoten: Cross-Over-Kabel reicht Eigenes IP-Subnetz Austausch von Heartbeats

„Mir geht‘s noch gut“ Kommunikation untereinander

Abstimmung der Konfiguration 1 öffentliche

Eigene IP-Adresse pro NIC Virtuelle Adresse(n) für den Cluster

Benötigte Hardware

Eigene Bootplatten pro Knoten Betriebssystem Installierte Anwendungen

EXE usw. sollen auf diese Platten, nicht auf die gemeinsam genutzten

Fehlertoleranz mit Standardmitteln RAID 1 ist hier völlig OK

Benötigte Hardware

Clusterfähige SCSI-Controller Cluster Mode muss üblicherweise eigens

eingeschaltet werden Cluster-Storage-Einheit

Enthält Clustercontroller und Platten Wird via SCSI-Kabel mit allen (!) Cluster-SCSI-

Controllern der Knoten verbunden Nur Cluster-zertifizierte Hardware

Nicht ganz billig…

Benötigte Software

Clusterfähige Betriebssysteme Windows Server 2003 Enterprise

Edition Windows 2000 Advanced Server Windows NT Server 4.0 Enterprise

Edition ;-)

Benötigte Software

Clusterfähige Anwendungen File & Print out of the Box SQL Server, Exchange Server: Enterprise

Edition Normale Dienste können mit Einschränkungen

vom Cluster verwaltet werden Wenn man unbedingt will, auch IIS (ab 2000),

Terminal Services (ab 2003), WINS, DHCP, … Hierfür gibt es aber geeignetere Mittel

Konfiguration

Betriebssysteme installieren Mit Treibern für die Clusterhardware

Netzwerke konfigurieren KB258750: Recommended private

"Heartbeat" configuration on a cluster server

Gemeinsame Platten formatieren

Das Quorum-Laufwerk

Eine Partition ≥ 512 MB auf einer gemeinsam genutzten Platte Speichert die Clusterkonfiguration Empfohlen: RAID 1 Partition nicht größer als 1 GB machen

Kein Sinn, Performancenachteile Eigene Platten!

Auch wenn sie dann nicht ausgenutzt werden! Sonst Konfigurationsschwierigkeiten und kein

Support von Microsoft

Die eigentliche Clusterkonfiguration

Beispiel: Fileserver Cluster auf erstem Knoten „erstellen“

Windows 2000: Clusterdienst installieren Windows 2003: Clusterverwaltung

Zweiten Knoten „beitreten“ lassen Evtl. Beitritt weiterer Knoten

Bis zu 8 bei Windows 2003 Enterprise Edition

Die eigentliche Clusterkonfiguration

Cluster-IP-Adresse Cluster-Netzwerkname

Abhängig von IP-Adresse Physikalische Plattenressource

Auf den gemeinsamen Platten Freigaben

Abhängig von Netzwerkname und Plattenressource

Die Clusterverwaltung

Eine Cluster-Ressource

SQL Server, Exchange Server

Der normale Stand

Ein Server führt die Platten… clusdisk.sys verhindert andere Zugriffe

und „den Dienst“ (z. B. SQL Server)…

und die Cluster-IP-Adresse dafür… und den Cluster-Netzwerknamen

dafür Workstations reden damit mit

diesem „aktiven“ Knoten

Was passiert beim Knotenausfall?

Der andere Server merkt das Heartbeat bleibt aus

Er übernimmt die Ressourcen Platten, IP-Adresse, Netzwerkname

und startet „den Dienst.“ Clients reden (evtl. nach Reconnect) mit

dem anderen Knoten Aber mit demselben Computernamen und

derselben IP-Adresse! Failover dauert meistens < 1 min oder nur

wenige Sekunden

Und so sieht so was aus

Network Load Balancing

Ausfallschutz und Lastverteilung auf TCP-Verbindungs-Ebene

Keine besondere Hardware notwendig

Gut geeignet für Webserverfarmen Alle Knoten werden genutzt Status muss auf anderen Rechnern

geführt werden Evtl. Servercluster

Benötigte Hardware

Eine, besser zwei NICs je Knoten Eine Front End (NLB) Eine Back End (Verbindung zu anderen

Servern) Ggf. Hubs (!), spezielle Switches, Router

Das ist oft sehr knifflig! Ungünstige Konfiguration: Netzwerk tot wegen

Switch Flooding, Broadcasts Theoretisches Limit: 32 Knoten

Benötigte Software

Windows Server 2003 Alle Versionen unterstützen NLB! Konfiguration am einfachsten

Windows 2000 Server Enterprise Edition

Evtl. Windows NT Server 4.0 mit Add-On Das hieß mal „WLBS“ – Windows Load

Balancing Services

Netzwerkaufbau

NLB-Server

NLB-Server

öffentlichStatus-ServerHub

bis zu 32

Wie funktioniert‘s?

Jede NIC hat ihre eigene IP Zusätzlich eine Cluster-IP Eingehende TCP-Verbindung eines Clients

kommt bei der Cluster-IP an Bei allen Knoten wegen gefälschten MACs!

Algorhytmus wählt aus, welcher Knoten die Verbindung übernimmt Jeder Knoten kommt zum selben Ergebnis

Verhalten bei Ausfall

Die Verbindungen mit dem ausgefallenen Server sind verloren

Andere Verbindungen bleiben erhalten

Heartbeats kommen nicht mehr Knoten stimmen sich neu ab Neue Verbindungen werden neu

verteilt Abgleich normalerweise in < 10 s

Spezialfall: Terminaldienste

Problem: Bei Trennung einer Sitzung evtl. Reconnect auf einen anderen Server Führt zu verwaisten, aber noch

laufenden Sitzungen Lösung in Windows Server 2003:

Session Directory-Dienst Führt Liste offener Sitzugen Terminaldienste senden ggf. Redirect

zum RDP-Client

Anwendungsbeispiel

2.500 User, davon knapp die Hälfte aktiv 2 DCs

Incl. DNS, WINS, … 3 Servercluster

File/Print, SQL, Exchange 30 Terminalserver

Migration von W2K + MetaFrame auf W2K3 alleine (Kosten!)

3 NLB-Farmen à 10 Server geplant Hat irgendwie noch keiner gemacht… nicht mal

bei Microsoft selbst…