[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux, network root filesystems


Hi,

Am Montag, 9. Januar 2006 17:09 schrieben Sie:
> Ich kenne noch das hier:
> http://www.drbd.org/

sehr guter Ansatz. Hast Du damit Erfahrung? Was mir daran nicht so gut gefaellt 
ist dass man Heartbeat benoetigt. Mir scheint das sehr kompliziert zu sein. 
Mir gefallen ausgereifte und einfache (transparente) Loesungen am meisten.

Gibt es hier sonst niemanden der Erfahrung mit so etwas hat?

Hier mal mein aktueller Stand:
Wie es ausschaut ist wohl iSCSI (das billige SAN) die Loesung der Wahl. Vor ca. 
3 Jahren war in dieser Richtung viel los. Aber irgendwie findet man nicht 
viele Erfahrungsberichte.
Vorteil ist, dass man bewaehrte Techniken kombiniert (SCSI mit IP). Umsetzen 
werde ich das wie folgt.
+ Storage Server
 * Viele IDE Festplatten (billig, ca. 50 MB/s pro Festplatte).
 * LVM bzw. CLVM ueber alle Festplatten per Striping (Geschwindigkeit gleich
   Summe der Geschwindigkeit der einzelnen Festplatten).
 * Export einzelner Partitionen des LVM (Volume Groups) per iSCSI.
 * Netzwerkanbindung ueber 1 GBit Ethernet. Damit ca. 100MB/s (OK, evtl. ein
   bischen weniger) moeglich.
 * Zwei Storage Server in jeweils einem eigenen 1 GBit Netzwerk an die
   Hardware-Server angebunden. Hardware-Server benoetigt somit 3 mal 1 GBit
   Netzwerkkarten.
+ Hardware-Server
 * Virtuelle Server
  - Einbinden der root iSCSI Geraete (Linux: initrd, Windows: moeglich mit
    komerzieller Software). Jeweils ein iSCSI block device von je einem
    Storage Server.
  - Zusammenbauen eines Software-RAID1 ueber die zwei iSCSI Geraete
    (Ausfallsicherheit beginnt erst hier!).
  = Ab hier laeuft ein System mit nativem Dateisystem auf block devices uebers
    Netzwerk.
  - Datenpartition: Einbinden von iSCSI Geraeten, jeweils RAID1 mit einem block
    device von Storage Server 1 und 2.
  - Mehrere RAID1 devices mit LVM zusammenfassen (Erweiterbarkeit).
  - Mount der Partition ( (2 x iSCSI = RAID1)+ = LVM ) ins Dateisystem.
 * Falls der Virtuelle Server kein iSCSI beim Boot unterstuetzen sollte kann
   auch alles (iSCSI, RAID1, LVM) auf dem Hardware-Server zusammengebaut
   werden und dem virtuellen Server als block device uebergeben werden.
   Notloesung!

Nutzung:
+ Erweiterbarkeit des Storage Server. Wenn eine Festplatte im Storage Server
  kaputt geht kann Dank LVM auch eine groessere Ersatzplatte eingebaut werden.
  Die Daten gehen dabei natuerlich verloren (Striping) ist aber wegen der
  Ausfallsicherheit durch einen zweiten Storage Server irrelevant.
+ Genauso koennen einfach neue Festplatten dazu gesteckt werden.
+ Wenn die volle Ausbaustufe eines Storage Servers erreicht ist koennen neue
  Storage Server dazu gestellt werden. Sogar der Wechsel von "alten" "kleinen"
  Storage Servern auf "neue" "groessere" kann somit ohne Ausfall (nur mit der
  Einschraenkung kurzzeitig keine Ausfallsicherheit zu haben) durchgefuehrt
  werden.
+ Erweiterbarkeit der Datenpartition moeglich. Einfach auf jedem Storage Server
  eine neue Partition freigeben, auf dem virtuellen Server als RAID1
  zusammenbauen und in den LVM auf dem virtuellen Server aufnehmen. Danach
  muss nur noch das Dateisystem entsprechend vergroessert werden. Viele
  Dateisystem erlauben das sogar im Betrieb.
+ Schwieriger wird die Vergroesserung der root Partition da hier jeweils die
  boot-Scripte angepasst werden muessten!

Was hier jetzt nicht angesprochen wurde ist: Wie kommt ein virtueller Server 
an seine Boot-Dateien heran?
Hierfuer habe ich mir ueberlegt waere GFS von Vorteil. Block-Devices von den 
Storage Servern koennen fuer GFS auf dem Hardware Server genutzt werden. Somit 
sind die Boot-Dateien auch auf allen Hardware-Servern verfuegbar (dauerhafte 
(live) migration einfacher moeglich) und trotzdem ausfallsicher.
Und wenn man es noch weiter spinnt, dann koennte man fuer legacy Systeme die nfs 
benoetigen einen nfs-Server auf den Storage Servern einrichten, welcher 
Dateien vom GFS freigibt. Damit wuerde zwar beim Ausfall eines benutzen 
nfs-Servers dieses legacy System haengen, koennte aber ohne viel Zeit- und 
Datenverlust gegen den alternativen nfs-Server gestartet werden, welcher Dank 
GFS ja dieselben Daten hat.

Bei dieser Loesung ist dann auch live migration von virtuellen Servern auf 
andere Hardware moeglich. Sozusagen haette man damit die eierlegende 
Wollmilchsau (Ausfallsicherheit, live migration, Erweiterbarkeit).

Wo ich mir noch nicht ganz sicher bin: Was passiert wenn ein iSCSI Geraet 
"haengt". Wie reagiert das RAID1? Bleibt das auch "haengen"? Benoetigt man evtl. 
dafuer doch Heartbeat um zu erkennen wann ein iSCSI Geraet ausgefallen ist?

Naja, sobald ich diese Umgebung in Betrieb habe (wahrscheinlich innerhalb des 
ersten Quartals 2006) werde ich berichten...


-- 
Gruss
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus@xxxxxxxxxxxxxxxxx             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
                                                       \_)    ) /
                                                             (_/