Skip to topic | Skip to bottom
Instantafs.DemoZeller1.1 - 06 Jun 2006 - 18:25 - TWikiGuest? [Zum Ende]

Start of topic | Direkt zum Menü

Demozelle des InstantAFS-Admin-Guide

Auf dieser Wiki-Seite wird eine AFS-Zelle skizziert und an dieser mögliche Fehler und Optimierungsmöglichkeiten diskutiert. Das InstantAFS-Admin-Guide bezieht sich auf diese Zelle, wenn Sachverhalte an Beispielen erklärt werden.

Die Situation

Das Forschungsinstitut rivers.de besteht aus 2 Teilen:

  • Einem grossen Hauptgebäude
  • Einer weit entfernten Aussenstelle

Beide Institutsteile bestehen aus jeweils einen geswitchten logischen Netz - ein Router verbindet beide Teile und das Internet. In der Aussenstelle existiert ein, im Hauptgebäude zwei abschliessbare Serverräume. Wo gehobelt wird fallen Spähne: 3 TiByte? müssen im Hauptgebäude, 1 TiByte? in der Aussenstelle an Daten gehalten werden - Tendenz (wie überall) exponentiell steigend. Die beiden Institutsteile sind durch eine 2MBit-Standleitung verbunden - die Daten sollten deshalb dort liegen, wo sie gebraucht werden.

Warum nicht zwei Zellen?

Besonders dann, wenn noch mehr Aussenstellen hinzukommen, lohnt es sich, mehrere AFS-Zellen zu benutzen. In diesem Fall ergeben sich dann 3 Herrausforderungen:

  • Die Benutzerdatenbanken (Kerberos5, PTDB) müssen abgeglichen werden. Es bietet sich an, dass alle Änderungen zentral eingepflegt werden und der Datenbestand regelmäßig in die anderen Zellen repliziert wird.
  • Wenn zellenübergreifende authentifizierte Zugriffe erfolgen sollen, müssen Benutzer mehrere Tokens (einen für jede Zelle des Instituts) erhalten. Das ist komplexer, als mit einem Token und nicht von der Stange zu haben - Debian bringt zumindest keine Unterstützung für eine solche Situation mit.
  • Das Backup zentral zu managen, bringt Komfortpunkte für den Administrator. AFS hält keine Bordmittel bereit, um Backups zellenübergreifend zu organisieren, jedoch kann man mittels einiger Skripte abhilfe schaffen.

Natürlich ergeben sich ein entscheidender Vorteil:

  • Die Zellen sind unabhängig (solange auch das DNS unabhängig ist). Ein Ausfall der Standleitungen zwischen den Institutsteilen würde das Backup der Einzelnen Teile nicht beeinträchtigen.

Serverpark

  Hauptgebäude
  Netzwerk: 10.1.0.0/255.255.0.0
  Serverraum 1
  orinoco
  Funktion: (primärer) Datenbankserver
IP: 10.1.1.10
  mekong
  Funktion: Fileserver
IP: 10.1.2.1
  Serverraum 2
  rio-grande
  Funktionen: Fileserver, Datenbankserver
IP: 10.1.1.20
  ganges
  Funktion: primärer Backupserver (Portoffset 0)
IP: 10.1.2.2
  Aussenstelle
  Netzwerk: 10.2.0.0/255.255.0.0
  Serverraum
  rubicon
  Funktionen: Datenbankserver, Backupserver ( butc mit Portoffset 1)
IP: 10.2.1.10
  volga
  Funktion: Fileserver
IP: 10.2.2.1
  yang-Tze
  Fileserver
IP: 10.2.2.2

Servername CPU Arbeitsspeicher Sekundärspeicher Weiteres
mekong
volga
yang-tze
rio-grande  
2x 2.6GHz Opteron 2 GiByte? 20 GiByte? (System), 2x 2TiByte RAID5 Fileserver sollten immer üppig dimensioniert sein. Der 2. Prozessor bringt ordentlich Gewinn.
orinoco   K6/2+ 500MHz 256 MiByte? 20 GiByte? Datenbankserver dürfen Sparrechner sein, ohne viel RAM, HDD und CPU.
ganges
rubicon  
2x 2.6Ghz Opteron 4 GiByte? 20 GiByte? (System), 20 GiByte? (Temp), 2x 2TiByte RAID5 (Daten) Backup-Server brauchen für die Kompression der Backups viel Rechenleistung. Arbeitsspeicher können sie nie genug haben, da dann die temporär unkomprimiert auf Platte liegenden Tape-Images im Cache bleiben. Die RAIDs werden benutzt, um komprimierte Tape-Images zu lagern.

Das ist ein Rechenbeispiel. Man kann die Rechner auch wesentlich kleiner dimensionieren und dafür mehr Fileserver einsetzen. 2 Fileserver sollten es aber pro Standort sein, wenn man Daten zur Sicherheit replizieren will. Gigabit-Ethernet-Karten sollten man sich allerdings bei den heutigen Preisen nicht mehr nehmen lassen. Hauptgebäude wie auch Aussenstelle sind jeweils klein genug, um ohne Router auszukommen.

Stärken des Beispiels:

  • Die Datenhaltung ist soweit wie möglich dezentral ( mekong in anderem Serverraum als rio-grande ). Für die Aussenstelle war das mangels zweitem Serverraum nicht machbar.
  • Es wird gar nicht erst versucht, AFS die Datenarchivierung zu überlassen - zumindest OpenAFS ist dafür nicht gedacht. Andere AFS-Implementationen wie MR-AFS können das durch HSM-Fähigkeiten leisten. Alternativ läßt sich auch ein AFS-fremdes HSM-System ankoppeln.
  • Die IP-Adressen sind so gewählt, dass die Datenbankserver immer möglichst niedrige bekommen (1) . Ausserdem ist immer ordentlich Platz zwischen den IPs der Datenbankserver, so dass man in jedem Fall noch Adressen vor und hinter jedem DB-Server zur Verfügung hat. Das könnte später wichtig sein, da AFS bei der Berechnung der Sync-Sites dem Server mit der niedrigsten Adresse eine höhere Wertigkeit (1,5 im Gegensatz zu 1,0 bei normalen Servern) zugesteht.
  • Filesysteme sind in geswitchten Umgebungen schneller als in gerouteten.
  • Die Rolle des Backup-Servers der Aussenstelle könnte auch einer der Fileserver übernehmen. Während des Full-Backups ist ein Backup-Server allerdings für Stunden oder Tage am Lastlimit, um eine effiziente Kompression zu gewährleisten.
    Hinweis: Die Fileserver müssen während dieser Zeit zwar umfangreiche Datenmengen an den Backupserver liefern, die dafür nötige Rechenleistung ist jedoch nicht mit der des Backup-Servers vergleichbar.

(1) Niedrige IP: 10.0.0.1 < 10.0.1.1 < 10.0.1.2 (das erste Oktet ist am höchsten gewichtet)

(teilweise gewollte) Schwächen dieses Beispiels:

  • Datenbankserver sollten dedizierte Rechner sein. Auf ihnen läuft zusätzlich zu den Datenbankprozessen auch noch ein Kerberos-Server, der bei vielen gleichzeitig zugreifenden Nutzer viel zu tun hat.
  • Das Backup wird auf ganges ausgelöst und überwacht. Fällt die Verbindung zwischen den Institutsteilen aus, wird in der Aussenstelle kein Backup durchgeführt.
    Hintergrund:
    • Das AFS-Backup-System speichert Daten über die virtuellen Bänder in der BDB - einem Teil der AFS-Datenbank. speichert klingt natürlich verdächtig nach Schreibzugriff , der jedoch nur bei Erreichbarkeit einer Sync-Site möglich ist. Die Sync-Site wiederum kann es im AFS bei einer Netztrennung nur einmal geben - nämlich in dem Teil des des Netzwerkes, der die meisten Datenbankserver enthält.
  • Ein Backupserver und ein Fileserver ( ganges und rio-grande ) stehen im selben Raum - böser Fehler im Brandfall. Glücklicherweise gibt es durch mekong auch dann noch genug Redundanz.
  • Rechner sind in geswitchten Umgebungen schwerer zu lokalisieren als in gerouteten.

Was machen die Server?

Die Fileserver mekong und rio-grande sowie die Fileserver rubicon und yang-tze speichern die Daten der Zelle, wobei folgendes gilt:

  • Jedes Daten-Volume der Zelle liegt einmal auf als RW- und als RO-Instanz auf dem einen sowie nur als RO-Instanz auf dem anderen Server. Hintergründe:
    • Die Entfernte RO-Instanz ist ein physisches Backup vom jeweils letzten Tag, das man mit O(1) in eine arbeitsfähige RW-Instanz verwandeln kann (sollte der Server mit der RW-Instanz ausfallen).
    • Eigentlich wäre eine RO-Kopie auf der Partition der RW-Instanz kein Sicherheitsgewinn, jedoch beschleunigt diese Konstellation die Synchronisation der Entfernten RO-Instanz mit der RW-Instanz gewaltig - vor allem bei grossen Dateimengen.
  • Die Struktur-Volumes der Zelle liegen alle als RW-Instanz sowie als RO-Instanz auf mekong und als reine RO-Instanzen auf allen anderen Fileservern. Hintergrund:
    • Strukturvolumes erzeugen nicht viel Last, weshalb die Fileserverlast kein Gegenargument ist.
    • Solche Volumes sind sehr klein, verbrauchen also nicht viel Platz auf den wertvollen RAIDs.
    • Strukturvolumes sind extrem wichtig. Fallen sie aus geht nichts mehr, obwohl nur ein paar kiByte offline gegangen sind. Die Replikation auf alle anderen Fileserver
  • Es werden 2 "kleinere" ( 2 TiByte? ) -Partitionen benutzt, da bei Ausfall eines grossen 4 TiByte?-Partition mehr Schaden zu beseitigen wäre und es kein Argument für das zusammenlegen gibt. Die virtualisierte Speicherung der AFS-Daten in Volumes läßt es zu, bei Bedarf im laufenden Betrieb Daten von einem RAID auf das andere zu verschieben. Die Vorteile einer einzelnen grossen Partition sind damit hinfällig.

Im Hauptgebäude stehen 2 Datenbankserver orinoco und rio-grande , in der Aussenstelle nur rubicon . Hintergrund:

  • Fällt die Verbindung aus, können beide Institutsteile erst einmal weiterarbeiten (abgesehen vom Backup: das geht nur noch im Hauptgebäude), da ja mindest ein Datenbankserver in jedem der Teilnetze steht.
  • Im Hauptgebäude können weiterhin Änderungen an der Zelle vorgenommen werden (Datenbankupdates werden sowieso nur im Hauptgebäude gemacht). Das funktioniert, weil sich 2 Datenbankserver in diesem Teilnetz sehen und damit eine Sync-Site ermittelt werden kann.

In jedem Institutsteil steht ein Backup-Server. Hintergrund:

  • logisch: Daten werden lokal ins Backup genommen, um Bandbreite auf der Standleitung zu sparen. Abgesehen davon ist ein Backup zeitkritisch, da es bis zum Beginn des Backups vom nächsten Tag fertig werden muss.
    • Das Backup kann tatsächlich parallel zum Produktivbetrieb laufen. Da die Backup-Dumps von geklonten Volume-Instanzen erstellt werden, sind die Daten konsistent.
  • 2 Backup-Server bedeuten im Idealfall doppelte Geschwindigkeit. Dieser Fall ist hier nicht gegeben, da im Hauptgebäude 3 TiByte? und in der Aussenstelle nur 1 TiByte? zu sichern sind - schneller als einer ist es trotzdem.
  • Bei einem Backup (es gibt volle und inkrementelle), löst ganges einen Dump von den jeweiligen Fileservern zum Tapecontroller ( butc ) des jeweiligen Backup-Servers aus.

Datensicherheit

Die Sicherheit der Daten der Zelle (gegen Zerstörung) ist 3-stufig und nutzt alle Möglichkeiten, die InstantAFS bietet voll aus.

1. Stufe: Das Benutzer-Backup

Alle Datenvolumes werden am Abend mit vos backup mit Backup-Instanzen ausgestattet bzw. mit diesen synchronisiert. Ausgelöst wird das durch instantafs.backup , das auf ganges läuft.

Benutzer, die ausversehen eine wichtige Datei gelöscht haben, wechseln in das Verzeichnis /a/backup/user/backup/[Benutzername] und holen sich die Datei zurück.

Worst Case: Der Benutzer bemerkt den Datenverlust zu spät - die Backup-Steuerung hat dann den interessanten Zustand des Volumes bereits mit einem aktuelleren überschrieben. Hier hilft Stufe 3 weiter.

2. Stufe: Das physische RO-Backup

Alle Datenvolumes werden am Abend mit ihren lokalen und mit ihren entfernten RO-Instanzen synchronisiert. Ausgelöst wird das durch instantafs.backup auf ganges . Dabei kann man auch mehrere entfernte RO-Instanzen benutzen, um die Redundanz für besonders wichtige Daten zu erhöhen.

Worst Case: Es sind sowohl ein Server mit RW-Instanzen sowie alle Server mit RO-Instanzen des ersten Servers ausgefallen. In diesem Fall muss man auf Stufe 3 sowie auf ein evtl. vorhandenes HSM-System/etc. zurückgreifen

3. Stufe: Backup per AFS-Backup-System

Die letzte Stufe ist das Backup auf virtuelle Bänder. Die Vorstufe dieses Backups ist das Benutzer-Backup, da Dumps für das AFS-Backup-System aus den Backup-Instanzen der Datenvolumes erzeugt werden. Die Dumps werden zu jeweils nächsten Backup-Server geschickt, dort komprimiert und auf Platten gespeichert. Diese Backup-Stufe ist ausschliesslich dafür gedacht, mehrere Versionen von allen Volumes zu haben und nicht , um Daten zu archivieren - dafür sind weder die Plattenkapazitäten auf den Backup-Servern ausreichend, noch ist die Organisation der Daten auf den Platten dafür geeignet.

In dieser Backup-Ebene werden üblicherweise nicht alle Volumes gesichert, sondern nur die, die im Falle des Versagens der 1. und 2. Stufe nicht wiederhergestellt werden könnten. Sowie einige Volumes, bei denen einige Revisionen in die Vergangenheit gewünscht sind.

Worst Case:

  • Stufe 2 hat versagt. Ausserdem trifft eine der beiden Bedingungen zu:
    • Der Backup-Server, der sich um die Volumes der ausgefallenen Fileserver kümmert, ist vernichtet.
    • Alle Datenbankserver sind ausgefallen - es ist keine aktuelle Kopie der BDB (Backup Data Base) mehr aufzutreiben.
  • Sollte dieser Worst Case eintreten, hat man entweder bei der Auswahl der Serverstellplätze versagt (-> alle Fileserver + Backup-Server stehen im selben abbrennenden Raum) oder man hat alles getan, was in der Macht des Admins steht.
    Merke: Man kann sich nicht gegen alles absichern.

Dateistruktur

Die Datenstruktur richtet sich nach InstantAFS, wurde natürlich den Institutsbedürfnissen entsprechend erweitert:

  /afs/rivers.de/
  admin
  .cellinfo
  cellinfo
  .etc
  etc
  sync-tries
  tmp
  backup
  user
  backup
  gert
  ...
  projects
  ro
  ...
  hosts
  projects
  deltas
  boats
  sediments
  bridges
  user
  gert
  ...
  user-na
  ...
  software
  scripts
  pub

Legende:

  Ein explizit als RW-Instanz gemountetes Volume
  Ein explizit als RO- bzw. Backup-Instanz gemountetes Volume
  Ein magischer Mountpoint (je nach beinhaltendem Volume eine RW- oder RO-Instanz)

Speichererweiterung

Die Zelle muss unweigerlich erweitert werden, da Speicherbedarf exponentiell steigt. Wird der Speicher knapp, kauft man (möglichst Paarweise) neue Fileserver mit RAIDs dran und schliesst sie ans Netzwerk an.

Hinweise:

  • Das geht komplett ohne Betriebsunterbrechung.
  • Man sollte dann auch einige Daten von alten Serverpaaren auf das neue verschieben, damit die neuen Fileserver in den ersten Wochen nicht herumidlen. Das geht im laufenden Betrieb.
  • Wie man einen nackten Fileserver einrichtet, steht im InstantAFS-Admin-Guide.

Ausfallszenarien

Um zu sehen, ob die diversen Server der Zelle ordentlich arbeiten, läuft auf einem Rechner der Zelle das Skript instantafs.servercheck regelmäßig per cron (20 Minuten sind ein gutes Intervall). Bemerkt es einen Fehler, landet eine Mail in den Inboxen der EDV-Abteilung.

Ein Fileserver ist defekt

Ist ein Mainboard, die Systemplatte oder dergleichen eines Fileservers (z.B. mekong ) defekt, ist es eine gute Idee, ein Cold-Standby-System im Serverraum stehen zu haben. In diesem Fall lohnt es vermutlich nicht, auf die Backups der 2. Stufe zurückzugreifen - es ist problemloser den neuen Rechner anzuschliessen, die Netzwerkkonfiguration so anzupassen, dass der Rechner auch mekong heisst und ihn dann hochzufahren.

Ansonsten (wie auch beim Ausfall des RAIDs) muss man auf Ersatzfileserver umschalten:

admin@afs > instantafs.calcrestore -m -r mekong/* > restore.sh;./restore.sh

Damit werden RO-Instanzen der RWs auf mekong , die sich auf anderen Servern befinden, zu RW-Instanzen umgewidmet und der Produktivbetrieb kann weitergehen - allerdings mit den Daten von letzter Nacht. Um die gewünschte Redundanz der Daten der Zelle wiederheszustellen, muss jetzt aber ein neuer Fileserver her - das InstantAFS-Admin-Guide erklärt, wie man das macht.

Achtung:

  • Die Platten muss man an den neuen Fileserver genau so mounten, wie an den alten - sonst kommt die VLDB beim Start des neuen durcheinander.
  • Die Unix-Nutzer werden es wahrscheinlich begrüssen, wenn man sie darauf hinweist, dass ihr Homedirectory jetzt die Version von letzter Nacht ist. Sie haben dann z.B. die Chance Dokumente, die sich noch in laufenden Anwendungen befinden, erneut abzuspeichern, um damit wertvolle Arbeitszeit zu retten.
    • Windows-Nutzer sind davon nicht betroffen, wenn ihr Profil lokal gecacht wird.

Datenbankserver fallen aus

... es ist der primäre :-(

Eigentlich sind Ausfälle der Datenbankserver unter AFS nicht kritisch. Da unter InstantAFS jedoch acall -Server darauf laufen, die es nur einmal pro Zelle geben darf und ausserdem noch der Kerberos5-Admin-Server dort arbeitet, fallen folgende Dinge aus:

  • Das Benutzergestuerte Datenmanagement. Hier muss man die betroffenen Benutzer (üblicherweise sind es nicht viele) informieren, dass es eine kurze Unterbrechung gibt.
  • Das Benutzermanagement funktioniert nicht mehr. Es können also keine neuen Benutzer angelegt, bestehende verändert oder überflüssige entfernt werden.

es ist ein anderer

Durch einen solchen Ausfall verliert man lediglich Redundanz in der AFS-Datenbank. Ansonsten ist keine Eile geboten, den Server zu ersetzen.

Zwei Datenbankserver sind ausgefallen

Jetzt ist Eile angebracht. Der letzte Datenbankserver ist jetzt ein Single-Point-of-Failure für die gesammte AFS-Zelle . Fällt dieser jetzt aus, kann kein Benutzer mehr arbeiten.

Handelt es sich bei den ausgefallenen Servern um orinoco und rio-grande , mutiert ausserdem die Standleitung zur Aussenstelle zum SPOF - die Verbindung zum Datenbankserver ist schliesslich weg, wenn ein Bagger jetzt auf die richtige Glasfaser trifft.

Ansonsten sind die Regeln wie in den Abschnitten vorher angegeben.

Backupserverausfall

Davon merken Benutzer glücklicherweise nichts.

... der primäre ( ganges ) ist's

Hier ist keine Eile geboten - schliesslich sind die Zeiträume beim Backup eher Tage. Wichtig ist, dass der primäre Backupserver am Abend wieder läuft, damit er die anderen dirigieren kann.

Solange der Ausfall andauert, geht folgendes nicht:

  • *Das komplette Backup * !!! - also alle 3 Stufen

Die steuernde Funktionalität des Backupservers läßt sich leicht auf einen anderen AFS-Server übertragen - prädistiniert ist der primäre Datenbankserver, da auf ihm schon eine acall -Keytab liegt. In diesem Fall funktioniert nur die 3. Backup-Stufe für die Daten nicht, die an den entsprechenden Backupserver gebunden sind.

Die rubikon ist ausgefallen

Damit fehlt die Backup-Stufe 3 für die Aussenstelle - bis der Backupserver wieder läuft.

Die Standleitung fällt aus (Zellensplit)

Damit zerfält die Zelle in zwei Teile, die jeder für sich - wenn man die Daten der Zelle sorgfältig verteilt hat - arbeitsfähig bleiben. Allerdings ist das Hauptgebäude privilegiert, da die beiden Datenbankserver dort weiterhin in der Lage sind, eine Sync-Site zu wählen.

Folgendes funktioniert nicht mehr:

  • Aussenstellenmitarbeiter können keine Verwaltungsfunktionen über den primären Datenbankserver mehr auslösen.
  • Ein in der Aussenstelle arbeitender Administrator kann trotz Superuserrechte keine Änderungen an den AFS-Datenbanken vornehmen, da der Datenbankserver der Aussenstelle bemerkt, dass er keine Sync-Site erreichbar ist
  • Es gibt keine Chance, neue Benutzeraccounts in der Aussenstelle anzulegen, da unabhängig vom fehlenden Schreibzugriff auf AFS-Datenbanken der Kerberos-Admin-Server orinoco nicht erreichbar ist. Werden neue Accounts im Hauptgebäude angelegt, so synchronisiert orinoco die Kerberos-Datenbank zur rio-grande - die Rubicon erhält jedoch mangels Verbindung keine Updates.
  • Die Mitarbeiter der Aussenstelle können nicht auf die RW-Instanzen zugreifen, die im Hauptgebäude liegen und umgekehrt. Wichtige RO-Instanzen - u.a. die von Struktur-Volumes - sind jedoch in beiden Teilnetzen verfügbar.
  • Der instantafs -Scannermode, der von vielen InstantAFS-Skripten benutzt wird, ist nicht mehr verfügbar, wodurch diese Skripte deutlich langsamer laufen. Jedes Skript, das Zelleninformationen braucht, versucht ab dann, diese von allen Fileservern einzuholen. Das läuft zwar massiv parallel (zumindest im Scannermode commands ), jedoch muss das Timeout der Fileserver im jeweils nicht erreichbaren Teilnetz abgewartet werden.
    • QUESTION? Warum funktioniert der instantafs -Scannermode im Hauptgebäude nicht, obwohl dort sowohl RW- als auch RO-Instanz von a.cellinfo liegen?
      ALERT! Weil die regelmäßige RO-Synchronisation an den nicht erreichbaren RO-Instanzen der Aussenstelle scheitert und dadurch auch die RO-Instanzen des Hauptgebäudes nicht mehr upgedatet werden.
  • Normale Dateizugriffe können kurzzeitig langsamer werden, da die AFS-Clients der Arbeitsplatzrechner sich u.U. auf Datenbank- oder RO-Instanzen beinhaltende Fileserver des jeweils anderen Teilnetzes eingeschossen haben. Nach einer gewissen Zeit werden diese Server jedoch als nicht verfügbar markiert und nicht weiter benutzt.
  • Benutzerlogins an den Workstation und per SSH dauern länger. Da nicht alle Kerberos-Server sichtbar sind (egal, in welchem Teilnetz man sich befindet), müssen beim Login die Kerberos-Timeouts abgewartet werden. Das läßt sich mit geschickter Anpassung der /etc/krb5.conf -Files der Workstations umgehen, ist jedoch aufwendig und von Seiten InstantAFS' nicht automatisch möglich.

Einbruch mit zerstörerischer Absicht

Wenn einer der AFS-Server geknackt wird und der Angreifer hat die Absicht, Daten zu vernichten, gibt es keine Chance, etwas dagegen zu tun. Die AFS-Server sind per symmetrischer Schlüssel miteinander verbunden - ein geknackter Server ermöglicht Zugang zu allen anderen.

Dieses einer-geknackt-alle-geknackt ist der Nachteil eines verteilten Netzwerkdateisystems wie AFS. Umschiffen läßt sich das nur, wenn man hin zu asymetrischer Kryptographie wechselt, jedoch gibt es auch dann irgendwo einen Schwachpunkt - z.B. der Zertifikat-ausstellende Rechner.
[Zurück zum Start]


Aktuelle Wiki-Seite: Instantafs > DemoZelle

[Zurück zum Start]