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

Präsentation zum Thema: "Clustering Vortrag für die.NET Users Group KA am 14.04.2005 Stefan Falk"—  Präsentation transkript:

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 Boot privat öffentlich Daten

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 gehts 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 öffentlich Status- Server Hub bis zu 32

25 Wie funktionierts? 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…