Active/Active HA Clustering mit Shared Storage Filesystem am Beispiel Samba

Transkript

1 Herzlich Willkommen zum Vortrag Active/Active HA Clustering mit Shared Storage Filesystem am Beispiel Samba Referent: Dipl.-Ing. Thomas Merz Datum: / Chemnitzer Linux-Tage merz@atix.de Seite 1 Slide 1

2 Beratung ATIX Geschäftsfelder Linux im Datacenter (Cluster-Lösungen, HA) Speichernetzwerke Verfügbarkeitsanalyse / Katastrophenvorsorge Services Competence Center Proof of Concept Projektbegleitung Installation / Produktion Workshops / Schulungen Seite 2 Slide 2

3 ATIX ausgewählte Referenzprojekte Stadtwerke München / Citiworks Infrastruktur für deutschlandweiten Online-Stromhandel und Firmennetz Hochverfügbarkeitsplattform Int. Pharma Konzern Consulting für Pharma-IT Speicherlandschaft Konzept zur Katastrophenvorsorge IP-Tech/Worldcom Infrastruktur für Internetservice Provider (TOP 5, Schweiz) Business Continuance Messe München International Infrastruktur für die Webservices der Messe Hochverfügbarkeitsplattform Seite 3 Slide 3

4 Klassische Speicheranbindung Server Speicher Server Speicher Server Library DAS (Direct Attached Storage) Klassisch: Parallel SCSI LAN Server und Speicher sind eine geschlossene Einheit Schlechte Katastrophenvorsorge Gesamte Datenkommunikation geht über das LAN Software Logik Seite 4 Slide 4

5 Speichernetzwerk Server Speichernetzwerk Primary Storage Library Server sind mit Speicher über eine Netzwerkstruktur verbunden Möglichkeit der räumlichen Trennung Server sind nur Blech Flexible Zuweisung Server Storage möglich Netzwerkabhängige Performance und Verfügbarkeit Seite 5 Slide 5

6 Shared Storage Server Speichernetzwerk Primary Storage Server greifen auf den selben Speicher zu Anwendungen: HA-Cluster High Performance Cluster Storage Cluster Einheitliche Systemkonfiguration ( shared root ) Seite 6 Slide 6

7 Katastrophenvorsorge Server RZ 1 Speichernetzwerk Server RZ 2 Server und Storage sind redundant und räumlich getrennt vorhanden Bei einer Katastrophe kann das zweite Rechenzentrum weiterarbeiten Integraler Bestandteil eines Katastrophenplans Primary Storage RZ 1 Primary Storage RZ 2 Seite 7 Slide 7

8 Backup and Restore Server Speichernetzwerk Primary Storage BU Server Library Backup-Server und Secondary Storage hängen am Speichernetzwerk Benutzer LAN wird nicht mit Backup-Traffic belastet (LAN- free-backup) Datenfluss kann direkt von Primary zu Secondary Storage erfolgen (Serverless Backup) Netzwerkabhängige Performance und Verfügbarkeit Seite 8 Slide 8

9 Was ist Speichervirtualisierung? Abstraktionsschicht zur Trennung von Host-Schicht Storage-Schicht Macht die physikalischen Storage-Charakteristiken unsichtbar für den Host Transparenz für den Speicherort der Daten Dynamisch Transparente on the fly Rekonfiguration Erlaubt die transparente Datenverschiebung/- reorganisation Es gibt SEHR viele unterschiedliche Typen, Ansätze und Grade der Implementerung Seite 9 Slide 9

10 SAN mit Fibre Channel (FC) Bekannteste SAN-Implementierung Offener ANSI Standard Kanal / Netzwerk Hohe Bandweite (100, 200, 400MB/s...) Flexible Topologien WAN Ausdehnung Verschiedene Datenraten und Medientypen parallel Seite 10 Slide 10

11 Simple SAN Servers Hohe Performance Preisgünstiger Einstieg Workgroup SAN SAN Backup Single Point of Failure Kein online Update Storage Seite 11 Slide 11

12 Basic HA SAN Servers Storage Dual Fabric Dual HBA mit Failover Software Sicherheit gegen logische Fehler Sicherheit gegen menschliche Fehler Sicheres Firmware Update Skalierbarkeit? Seite 12 Slide 12

13 Was ist ein Cluster? Paralleles oder verteiltes Rechensystem Verschiedene Arten der Backend-Datenverwaltung Zusammenschluss von eigenständigen Computern Nach außen eine Ressource Schnelle Netzwerkanbindung Lockere Verbindung der Einheiten Seite 13 Slide 13

14 Rechencluster Idee: Viele kleine erledigen die Aufgabe von einme großen Einsatz: Number Crunching etc. Seite 14 Slide 14

15 Network Loadbalancing Cluster RS1 3. Director/LB RS2 RS3 Eine virtuelle IP-Addresse auf dem Director/LB Verschiedene Arten des Loadbalancing NAT/Tunneling/Direct-Routing Scheduling Algorithmus (RR, LWR, LCR,..) Dynamische Konfiguration (Heartbeating) Seite 15 Slide 15

16 HA Cluster Active/Passive Heartbeat SV1 active SV2 (passive) Konzept: Der passive Knoten wartet auf den Ausfall des aktiven Ein oder mehrere Dienste laufen auf dem aktiven Knoten Eine Software sorgt für die Überwachung und den Failover Seite 16 Slide 16

17 HA Cluster Active/Active SV1 active/(passive) Heartbeat SV2 (passive)/active Konzept: Auf jeden Knoten laufen unterschiedliche Dienste Dadurch ist jeder Knoten aktiv und passiv zugleich Im Fehlerfall gibt es aber Performance-Einbußen Ansonsten gilt das gleiche wie für Active/Passive Cluster Seite 17 Slide 17

18 HA Cluster N+1 SV1 Heartbeat SV2 active active SV3 active SV4 (passive) Konzept: Es werden um einen mehr Server verwendet als notwendig (N+1) Das heißt der Cluster kann den Ausfall eines Knoten ohne Performance-Einbußen hinnehmen N+2, N+3 für größere Ns auch möglich Typischerweise unterstützt HA-Software maximal ca. 16 Server Dieses Konzept kann auch für NLB-Cluster verwendet werden Seite 18 Slide 18

19 HA Cluster: Split Brain Problem Frage: Was passiert, wenn sich zwei Cluster-Knoten nicht mehr erreichen können? Fencing/Stonith (Shoot the other node in the head) Meist in Verbindung mit einem Tie-Breaker Bei Cluster mit Cluster FS Quorum Requirement und Fencing Oft auch Kombination Seite 19 Slide 19

20 Stateless und Statefull Services Problem des transparenten Failovers Theoretisch muss der Dienst in genau dem gleichen Zustand auf dem 2. Knoten wieder laufen Dienste, die stateless sind, speichern im Memory keine clientabhängigen Zustände ab => Transparenter Failover ist kein Problem Dienste, die Zustände im Memory haben, müssen die Möglichkeit bieten diese persistent zu machen Seite 20 Slide 20

21 Stateless und Statefull Services Statefull Services: Perfektes Beispiel: DBMS Lösung: Write-Logs, Redo-Logs etc. Aber auch Dienste wie NFS/CIFS können statefull sein Es ist in diesem Fall immer notwendig, dass solche Dienste auch von der HA-Software unterstützt werden Meist geschieht das über spezielle Resource-Types Werden statefull Services ohne entsprechenden Support gefailovert, kann es zu Datenverlust kommen Seite 21 Slide 21

22 Filesystem Issues SV1 active Heartbeat SV2 (passive) Problem: Exklusiver oder Paralleler Dateisystemzugriff Ein HA-Cluster muss zwei oder mehreren Servern abwechselnd Zugriff auf dieselben Ressourcen geben. Möglichkeiten: Datenreplikation zwischen zwei oder mehreren Volumes Standard Single Host Filesystem wird ping-pong gemountet Cluster-Filesystem ist permanent auf allen Hosts gemountet Seite 22 Slide 22

23 Filesystem Issues Heartbeat SV1 active SV2 (passive) permanente Datenreplikation Datenreplikation zwischen zwei oder mehreren Volumes: nur one way (active -> passive) Replikation Replikation erfolgt LAN/Host basiert (e.g. rsync) Replikation erfolgt SAN/Storage basiert (e.g. HP Continous Access) Seite 23 Slide 23

24 Filesystem Issues Heartbeat SV1 active SV2 (passive) permanente Datenreplikation Replikation erfolgt LAN/Host basiert (e.g. rsync): Starke Belastung der Host CPU's, hohe I/O Last Bottleneck ist das LAN Nur kleine Anzahl an Replikationen möglich Replikation ist allerdings verhältnismäßig günstig Passiver Host kann als aktiver read only Host verwendet werden Seite 24 Slide 24

25 Filesystem Issues Heartbeat SV1 active SV2 (passive) permanente Datenreplikation Replikation erfolgt SAN/Storage basiert: keine Hostbelastung, Replikation erfolgt innerhalb des/der Storage-Systeme (kein LAN Bottleneck, volle SAN Performance) Mögliche Anzahl der Replikationen höher Replikation ist teuer (SAN storage, Lizenzen) Passiver Host kann je nach Lösung als aktiver read only Host verwendet werden Seite 25 Slide 25

26 Filesystem Issues SV1 active Heartbeat SV2 (passive) Standard Single Host Filesystem wird ping-pong gemountet Shared Storage (SAN, Shared SCSI Bus) nötig SAN-Lösung relativ teuer, Shared SCSI-Bus auf zwei Hosts begrenzt Jeder Host kann als Active-Host für eine Applikation (= ein Filesystem) dienen und gleichzeitig für eine andere Applikation (= anderes Filesystem) Passive-Host sein. Mehrere Filesysteme pro Host möglich Seite 26 Slide 26

27 Filesystem Issues SV1 active Heartbeat SV2 (active Cluster-Filesystem ist permanent auf allen Hosts gemountet Shared Storage (SAN) nötig, alternativ GNBD SAN-Lösung relativ teuer, Anzahl der aktiven Hosts nicht begrenzt Jeder Host kann gleichzeitig Active-Host für eine Applikation (= ein Filesystem) sein, je nach Clusterfähigkeit der Applikation ist auch konkurrierender Schreibzugriff möglich Aktive Lastverteilung auf mehrere Hosts möglich Seite 27 Slide 27

28 Filesystem Issues SV1 active Heartbeat SV2 (active Cluster-Filesystem ist permanent auf allen Hosts gemountet Alle Hosts teilen sich die Verwaltung des Filesystems Kein dedizierter Fileserver (eg.: NFS) nowendig Kein Single Point of Failure (SPoF) falls redundante Infrastruktur und redundante Lockserver (= Zustandsverwaltung des Filesystems) Kein Protokolloverhead wie bei IP basierten Systemen (eg: NFS) Filesystemzugriff direkt im SAN, kein Umweg über IP basierte Strecken Seite 28 Slide 28

29 Cluster-Filesystem Issues Alle Hosts sehen die physikalisch identischen Dateien und haben vollen Schreib- und Lesezugriff darauf Zugriffsbeschränkung erfolgt nur auf Applikationsebene Jeder Cluster-Node kann die Rolle eines beliebigen anderen übernehmen Jeder Node kann beliebige Applikationen beherbergen Beliebige Anzahl an Cluster-Nodes möglich Seite 29 Slide 29

30 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Shares: [share1],[share2] [share3] [share4] [share5],[share6] IP: & &81 Hostname: server1 server2 server3 server4 Gemeinsames Filesystem: /mnt/gfs/samba/ auf dem SAN Storage Seite 30 Slide 30

31 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Unterteilung der Filesystemstruktur: Share 1: /mnt/gfs/samba/shares/share1/ Share 2: /mnt/gfs/samba/shares/share2/ Share 3: /mnt/gfs/samba/shares/share3/ Share 4: /mnt/gfs/samba/shares/share4/ Share 5: /mnt/gfs/samba/shares/share5/ Intern: /mnt/gfs/samba/intern/ Intern beinhaltet Teile der notwendigen share-basierten Sambakonfiguration Seite 31 Slide 31

32 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Unterteilung des Intern -Verzeichnisses: ls -la /mnt/gfs/samba/intern/ (Informationen der Ausgabe selektiv) lrwxrwxrwx root root /global drwxr-xr-x root root /server1 drwxr-xr-x root root /server2 drwxr-xr-x root root /server3 drwxr-xr-x root root /server4 Greift Server1 logisch auf das Verzeichnis /mnt/gfs/samba/intern/global/ zu, so greift er physikalisch auf das Verzeichnis /mnt/gfs/samba/intern/global/server1/ zu, bei allen anderen Servern verhält es sich entsprechend. Man spricht hier von Context Dependant Path Names, sog. CDPNs. Seite 32 Slide 32

33 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufbau der Sambakonfiguration, Beispiel für Server1: /mnt/gfs/samba/intern/global/smb_cluster.conf [global] workgroup = atix server string = Mein Sambaserver bind interfaces only = no... bind interfaces = no sorgt dafür, daß Samba auf Anfragen aller auf dem System verfügbaren IP-Adressen reagiert. Seite 33 Slide 33

34 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufbau der Sambakonfiguration, Beispiel für Server1: /mnt/gfs/samba/intern/global/smb_cluster.conf [global] workgroup = atix server string = Mein Sambaserver bind interfaces only = no... include = /mnt/gfs/samba/intern/share1.conf include = /mnt/gfs/samba/intern/share2.conf share<1-5>.conf enthalten die Sharekonfigurationen für die spezifizierte Share. Seite 34 Slide 34

35 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufbau der Sambakonfiguration, Beispiel für Share1: /mnt/gfs/samba/intern/share1.conf [share1] comment = Das ist meine Share1 path = /mnt/gfs/samba/shares/share1 read only = no valid users = myfirstuser,myseconduser,@shareusers... Seite 35 Slide 35

36 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufbau der Sambakonfiguration, Beispiel für Share2: /mnt/gfs/samba/intern/share2.conf [share2] comment = Das ist meine Share2 path = /mnt/gfs/samba/shares/share2 read only = yes guest ok = yes... Seite 36 Slide 36

37 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Wird smbd auf Server1 mit dem korrekten Konfigurationsfile gestartet smbd -D -s /mnt/gfs/samba/intern/global/smb_cluster.conf stellt Samba nun [Share1] und [Share2] zur Verfügung Die Presentation erfolgt unter allen IP-Adressen des Hosts Eine Einschränkung ist möglich, es ist dann aber darauf zu achten, dass alle Cluster-IP-Adressen vom smbd benutzt werden dürfen, andernfalls kann es beim Failover zu Dienstausfällen kommen. Seite 37 Slide 37

38 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Server1 soll zusätzlich Share5 präsentieren Datei: /mnt/gfs/samba/intern/global/smb_cluster.conf [global] workgroup = atix server string = Mein Sambaserver bind interfaces only = no... include = /mnt/gfs/samba/intern/share1.conf include = /mnt/gfs/samba/intern/share2.conf include = /mnt/gfs/samba/intern/share5.conf Seite 38 Slide 38

39 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Server1 soll zusätzlich Share5 präsentieren Voraussetzung/Grund: Server5 ist ausgefallen, Host ist down Zuerst muss Server1 die IP-Adresse erhalten, unter der [Share5] per Definition angeboten wird (eg:): ifconfig eth0: up Der Samba-Dienst muss die veränderte Konfigurationsdatei neu einlesen: killall -HUP smbd Server1 verwaltet ab sofort zusätzlich zu [share1] und [share2] auch [share5] Dieses Failover kann auch automatisiert werden, zb mittels HP Service Guard Seite 39 Slide 39

40 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Server1 soll zusätzlich Share5 präsentieren Weitere Informationen: Die Cluster-IP-Adresse von [share5] wurde Server5 entzogen (entweder per Software oder per herunterfahren des Servers), andernfalls werden Netzwerkprobleme auftreten Samba auf Server5 sollte keinen Zugriff mehr auf Dateien der [share5] haben, also vor Failover gestoppt werden. Filesystemkorruption kann nicht passieren, allerdings könnten auf die Share zugreifende Clients Fehler melden, im schlimmsten Fall eine gerade offene Datei beschädigt werden. Seite 40 Slide 40

41 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Hintergrund: Eine Share wird stark lesend frequentiert (zb Videostreamingfiles), deshalb soll der lesende Zugriff darauf über zwei Sambaserver parallel aus möglich sein. Ein dritter Sambaserver schreibt die Videostreamingfiles auf die Share. Hinweis: Mit dem Einsatz eines Loadbalancers können Zugriffe auch lastverteilt und für den Client transparent präsentiert werden. An den generellen Prinzipien der folgenden Folien ändert das nichts. Seite 41 Slide 41

42 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Server2 soll auf die Share schreiben: Seine zentrale Konfigurationsdatei (smb_cluster.conf) sieht so aus: [global]... include = /mnt/gfs/samba/intern/share7_write.conf... (weitere include könnten hier folgen) Seite 42 Slide 42

43 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Server3 und Server4 sollen von der Share lesen: Deren zentrale Konfigurationsdatei (smb_cluster.conf) sieht jeweils so aus: [global]... include = /mnt/gfs/samba/intern/share7_read.conf... (weitere include könnten hier folgen) Seite 43 Slide 43

44 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Inhalt von share7_write.conf [share7] comment = Videostreamingarchiv mit Schreibzugriff path = /mnt/gfs/samba/shares/share7 read only = no valid users = streamwriter Seite 44 Slide 44

45 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Inhalt von share7_read.conf [share7] comment = Videostreamingarchiv mit Lesezugriff path = /mnt/gfs/samba/shares/share7 read only = yes valid users = streamreader Seite 45 Slide 45

46 Cluster-Filesystem Issues Beispiel: Samba (Fileservices für Windows Clients) Aufgabe: Zugriff von 3 Sambaservern auf eine physikalische Share Die drei beteiligten Server müssen jetzt noch die neue Konfiguration einlesen (killall -HUP smbd) Es wird indirekt davon ausgegangen, dass die Video-Clients nicht während des Schreibvorgangs lesend auf das Archiv zugreifen. Das ist technisch auch möglich, geht aber über das Beispiel hinaus. Seite 46 Slide 46

47 Cluster-Filesystem Issues Die vorgestellte Sambaanwendung ist auch als NFS-Variante möglich, allerdings ist hier aufgrund des unterschiedlichen Filezugriffshandlings etwas mehr Anpassungsarbeit nötig NFS und Sambamischbetrieb sind -wie in einer Standardumgebung auch- möglich Weitere mögliche Applikationen für shared storage HA und/oder Loadbalancingbetrieb sind u.a.: Apache sendmail/postfix Courier IMAP Seite 47 Slide 47

48 Ausblick Shared Root Cluster In den vorigen Beispielen wurde davon ausgegangen, dass jeder Cluster-Node ein lokal installiertes Betriebssystem benutzt Im sog. Shared Root Cluster kann jeder Node direkt aus dem SAN gebootet werden, lokale Harddisks entfallen so (Swapspace ausgenommen). Jeder Node ist somit mit allen anderen identisch (Reduzierung auf reine CPU) Änderungen/Updates/... sind so zentral und müssen nur einmal für die gesamte Infrastruktur aufgespielt werden Siehe hierzu ix 11/2004 (S. 118) Aus dem Pool schöpfen Seite 48 Slide 48

49 Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit! Atix GmbH Einsteinstr Unterschleißheim Seite 49 Slide 49