Hi, Am Mittwoch, 9. Mai 2007 21:58 schrieb Alexander Holler: > Markus Hochholdinger wrote: > >> Hmm, das hat allerdings den Nachtteil, daß man bei Ausfall eines > >> Xen-Hosts erstmal ein fsck durchführen muss bzw. sollte, bevor der 2. > >> das filesystem übernehmen kann. Bei grösseren Partitionen könnte das zu > >> einem zeitlichem Problem werden. > >> Welches FS benutzt du denn auf diesem RAID? > > ich nutze hauptsächlich ext3 und das Rollback geht ziemlich schnell nach > > einem Absturz (im übrigen dasselbe wie Stecker (Absturz) raus bei einem > > echten Server). > Einem anderem (Linux-)FS würde ich sowas auch nicht anvertrauen. XFS und :-) > Reiser mögen unsauberes Herunterfahren ja gar nicht gerne. > Und schnell ist relativ, wenn man nicht daran denkt per tune2fs das > Interval zwischen den Prüfungen zu deaktivieren, ist es doch sehr > wahrscheinlich, daß bei einem Einsprung des Reservesystems ein > vollständiger fsck zuschlägt. Zumindest wenn das produktive System > soweit stabil lief, das 6 Monate vergingen (der Default). Murphy ist > immer anwesend. ;) Aus meiner Dokumentation zum Anlegen neuer Dateisystem für virtuelle Instanzen: mkfs.ext3 -m 0 -E resize=1T /dev/md9 tune2fs -c 0 -i 0 /dev/md9 Das "-m 0" fand ich für meine Anwendungsfälle bisher am optimalsten, darüber kann man aber streiten. Mit "-E resize=1T" bereite ich das Dateisystem für eine spätere Vergrößerung auf maximal 1 TeraByte vor (damit sollte man ältere fsck Versionen vom Dateisystem fern halten, sonst wird das "repariert"). tune2fs ist bei mir irgendwie standard geworden. Ich habe bei ext3 bisher kein fsck gebraucht solange die Hardware in Ordnung war. Im Notfall kann ich das auch jederzeit manuell (und wenn es sein muss auch außerhalb der virtuellen Instanz) machen. > Hattest du evtl. mal mit DRBD herumgespielt oder war die RAID1-Lösung > gleich die erste zufriedenstellende Lösung? Ich habe mir DRBD angeschaut. Ich finde die Technik (multipathing) auch sehr toll, allerdings wollte ich auf bewährtes setzen. RAID1 kann hier natürlich nicht so performant sein, dafür ist es einfach (zu verstehen). Bei drbd kann IMHO zu viel in der Konfiguration (des Clusters) schief gehen. Außerdem habe ich dank RAID1 die Möglichkeit ein RAID1 inklusive Dateisystem im Betrieb zu vergrößern. Dazu nehme ich eine Platte im Betrieb raus, vergrößere diese (lvm) und binde diese wieder ein. Mache einen Re-Sync und dann dasselbe mit der anderen Platte. Mit "mdadm --grow" kann man dann das RAID1 vergrößern und mit ext2online das Dateisystem vergrößern. Dies alles mache ich ohne die virtuelle Instanz herunter fahren. Mit drbd kann ich das nicht machen, da meine virtuelle Instanz nur ein Device hätte und die virtuelle Instanz bekommt nicht mit wenn das Block-Device größer wird. (Mir ist zumindest bis jetzt kein Weg bekannt wie ich einer virtuellen Xen-Instanzen sagen soll dass die Platte größer geworden ist ohne die Platte kurz wegzunehmen.) Sprich für mich war RAID1 die Lösung mit am meisten Vorteile. -- greetings eMHa -- http://mailman.uugrn.org/mailman/listinfo/uugrn
Dieses Archiv wurde generiert von hypermail 2.2.0 : 09.05.2007 CEST