Clustering

1. Clustering Vortrag für die .NET Users Group KA am 14.04.2005 Stefan Falk sfalk@ct-systeme.com

2. Wozu Cluster? • Redundanz • Ausfallzeiten verringern! • Lastverteilung • Mehr User abdecken, als es eine einzelne Maschine könnte • Aber mit einheitlicher Konfiguration

3. 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

4. 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

5. Aufbau eines Serverclusters öffentlich Boot Daten privat öffentlich Boot

6. 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

7. 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

8. 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…

9. Benötigte Software • Clusterfähige Betriebssysteme • Windows Server 2003 Enterprise Edition • Windows 2000 Advanced Server • Windows NT Server 4.0 Enterprise Edition ;-)

10. 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

11. Konfiguration • Betriebssysteme installieren • Mit Treibern für die Clusterhardware • Netzwerke konfigurieren • KB258750: Recommended private "Heartbeat" configuration on a cluster server • Gemeinsame Platten formatieren

12. 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

13. 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

14. 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

15. Die Clusterverwaltung

16. Eine Cluster-Ressource

17. SQL Server, Exchange Server

18. 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

19. 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

20. Und so sieht so was aus

21. 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

22. 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

23. 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

24. Netzwerkaufbau NLB-Server Hub Status-Server bis zu 32 öffentlich NLB-Server

25. 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

26. 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

27. 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

28. 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…