Raid 1 und Ausfall einer Platte

[Fisi]

Hallo zusammen,

ich habe eine Frage zum Thema Software Raid 1 bei Solaris 10:

wir haben mehrere SPARC-Maschinen, sowie auch x86-Solarissysteme im Einsatz. Auf allen Systemen läuft RAID 1. Die Konfiguration war eigentlich kein Problem, wir haben auf einem Slice die Metadatenbank angelegt und dann die restlichen Slices gespiegelt. (auf beiden Platten sind jetzt die selben Slices und Daten)

Wenn wir jetzt einen Ausfall einer Platte simulieren (sprich die Platte einfach abziehen), bootet der Server nur noch im Maintenance-Mode. Soweit verständlich, da die vfstab ja auf die Spiegel verweist. Passe ich jetzt die vfstab an, sodass der Server nur noch von Festplatte 1 booten soll, bootet er gar nicht mehr, sondern gibt kurz eine Meldung "Panic ... ###" aus und rebootet ganz schnell (sodass ich leider nicht die komplette Meldung lesen kann :/ ). Danach komme ich nur noch über den FailSafe bzw. Single-User-Mode in den Server.

Ich habe ein wenig gegoogelt und viele Szenarien gefunden, bei denen dann die Platte sofort ausgetauscht wird. Aber ist Sinn und Zweck eines Raids nicht auch, dass bei Ausfall einer Platte der normale Serverbetrieb mit der zweiten Platte aufrecht erhalten werden kann?

Ich bin für jeden Dankanstoß sehr dankbar
LG, Fisi.

[stiefkind]

Guten Morgen!

wir haben mehrere SPARC-Maschinen, sowie auch x86-Solarissysteme im Einsatz. Auf allen Systemen läuft RAID 1. Die Konfiguration war eigentlich kein Problem, wir haben auf einem Slice die Metadatenbank angelegt und dann die restlichen Slices gespiegelt. (auf beiden Platten sind jetzt die selben Slices und Daten.

Weil Du den Begriff "Metadatenbank" verwendest, vermute ich, ihr arbeitet mit den Solaris Volume Manager. Also diese Kommandos, die alle mit "meta" beginnen.

Wenn wir jetzt einen Ausfall einer Platte simulieren (sprich die Platte einfach abziehen), bootet der Server nur noch im Maintenance-Mode. Soweit verständlich, da die vfstab ja auf die Spiegel verweist.

Nein, nicht verständlich. Wenn das alles sauber konfiguriert ist, sind die Metadevices an sich ja noch vorhanden und können gemountet werden. Bestehen halt nur noch jeweils aus einer Spiegelhälfte, aber das stört Solaris erstmal nicht. Natürlich bekommst Du Fehler in /var/adm/messages und auch metastat sollte sich beschweren, dass den Metadevices jeweils eine Spiegelhälfte fehlt.

Passe ich jetzt die vfstab an, sodass der Server nur noch von Festplatte 1 booten soll, bootet er gar nicht mehr, sondern gibt kurz eine Meldung "Panic ... ###" aus und rebootet ganz schnell (sodass ich leider nicht die komplette Meldung lesen kann :/ ). Danach komme ich nur noch über den FailSafe bzw. Single-User-Mode in den Server.

Weil in /etc/system noch ein Hinweis für den Kernel steht, dass er von einem Metadevice booten soll. Das aber in der von Dir angepassten vfstab nicht mehr existiert.

Ich habe ein wenig gegoogelt und viele Szenarien gefunden, bei denen dann die Platte sofort ausgetauscht wird. Aber ist Sinn und Zweck eines Raids nicht auch, dass bei Ausfall einer Platte der normale Serverbetrieb mit der zweiten Platte aufrecht erhalten werden kann?

Naja... defekte Spiegelplatten sollten so schnell wie möglich ausgetauscht werden, sonst ist ja die Redundanz dahin. Aber Sinn eines RAID-1 ist natürlich, dass das System im beschriebenen Fehlerfall erstmal weiter laufen kann, das siehst Du schon richtig.

Ich vermute, da ist irgendwas in der Konfiguration noch nicht ganz richtig. Wenn Du magst, dann poste doch mal den Output von metadb, metastat, eure "normale" /etc/vfstab und die /etc/system. Kannst mir auch per PN schicken, wenn Dir das lieber ist. Dann schaue ich später am Tag mal drüber. Heute vormittag habe ich erstmal einen Kundentermin.

Ich überlege gerade, wie man einer Intel-Maschine beibringt, im Fehlerfall von der alternativen Platte zu booten. Im OBP bei SPARC ist das glasklar...

wolfgang

[Fisi]

Hi,

danke für die schnelle Antwort!

Ja wir benutzer die meta-Befehle.
Wir haben jetzt noch eine Anleitung auf der SUN/Oracle Seite gefunden, wie man beide Festplatten bootbar machen kann:

Code: [Auswählen]

# set md:mirrored_root_flag = 1

Code: [Auswählen]

# fdisk -b /usr/lib/fs/ufs/mboot /dev/rdsk/c2d0s0

Code: [Auswählen]

# /sbin/installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d0s0
Danach konnten wir Festplatte 1 abziehen und er hat weiterhin (auch mit der Raid-vfstab) gebootet und lediglich gesagt, dass etwas mit dem Raid nicht stimmt. (Beim Boot von Festplatte 1 - ohne 2. Platte - kam allerdings wieder die Panik-Meldung - ok, weils wir die Spiegel ja noch nicht neu aufgebaut haben)

Nachdem wir Platte 1 wieder angesteckt haben, mussten wir die Spiegel wieder neu attachen (metareplace -e). Zur Zeit läuft die Synchronisation und wir erhoffen uns jetzt, dass danach wieder normal im Raid gebootet wird. Beim Abziehen von Platte 2 müsste dann das gleiche Spiel vor vorne losgehen...

Ist das ok, dass die Spiegel erst neu attached/replaced werden müssen? Meines erachtens ja, weil es ja im Normfall eine neue Festplatte ist, die das System noch nicht kennt, oder?

Danke und LG, Fisi.

[stiefkind]

Servus!

Wir haben jetzt noch eine Anleitung auf der SUN/Oracle Seite gefunden, wie man beide Festplatten bootbar machen kann:

Code: [Auswählen]

# set md:mirrored_root_flag = 1
# fdisk -b /usr/lib/fs/ufs/mboot /dev/rdsk/c2d0s0
# /sbin/installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d0s0

Äh... ein metaroot <metadevice_rootmirror> habt ihr beim Einrichten gemacht?

Diese Prozedur mit fdisk und installgrub sehe ich gerade zum ersten Mal in meinem Leben. Aber gut, ich arbeite normalerweise (seit 12+ Jahren) auch quasi nur mit SPARC, kann sein, dass das bei Intel-Solaris etwas anders geht. Da musste ich glaube ich noch nie einen SVM konfigurieren.

Ist das ok, dass die Spiegel erst neu attached/replaced werden müssen? Meines erachtens ja, weil es ja im Normfall eine neue Festplatte ist, die das System noch nicht kennt, oder?

Ja, natürlich. Muss so sein. Sobald die eine Platte raus ist und der Spiegel nur noch auf einer Platte läuft, laufen die Inhalte der beiden Platten ja auseinander. Ein Resync nach dem Einstecken ist also zwingend erforderlich. Normalerweise steckst Du ja eine neue Platte ein, weil die alte kaputt ist...

wolfgang

[Fisi]

Hey,

also wir hatten neu gesynct, hat auch funktioniert, aber die erste Festplatte hat nicht mehr reagiert und es konnte auch von ihr nicht gebootet werden. Ich denke mal, wir haben das System jetzt langsam in Grund und Boden konfiguriert 

Wir setzen das System jetzt gerade frisch auf und probieren es dann nochmal durch.

Die Option # installgrub ist wohl analog zu der Option # installboot unter Sparc. Ein Metaroot haben wir beim Einrichten der Spiegel für das Root-Slice gemacht. Für alle anderen Spiegel haben wir die Einträge in der vfstab manuell gemacht.

Beispielauszug /etc/vfstab

Code: [Auswählen]

# /dev/dsk/c0d0s0     /dev/rdsk/c0d0s0     /    ufs     1     no     -
/dev/md/dsk/d10     /dev/md/rdsk/d10     /     ufs     1     no     -Spiegel d10 steht für das Root-Slice /.

LG, fisi.

[Hexxer]

Was auch noch erwähnenswert ist, es müssen/sollten mehr als 50% der Metadbs vorhanden sein. Also z.B. auf beiden Platten slice 7 und dort jeweils z.B. 3 Metadbs reinschieben. Fällt eine Platte aus sind noch 3 Metadbs vorhanden. Um hier den reboot bzw das "nicht booten" zu verhindern kommt "set md:mirrored_root_flag=1" in die /etc/system

Grundsätzlich:
- Diskausfall
- meta-kommandos checken
- alte Disk raus
- neue disk rein
- Konfiguration der noch laufenden Disk per prtvtoc oder format auf die neue Disk übertragen
- metareplace -e.....
- metadbs checken


Die Dateisysteme sollten laut vfstab natürlich auf die angelegten Meta-Dateisysteme zeigen (dev/md/dsk/d10 - oder was auch immer), denn sonst ist der ganze Kram erstmal nicht ganz so sinnvoll.
An sich ist der ganze SVM Krempel sehr einfach zu handeln, denn selbst im Problemfall kann man halt von Disk1 oder disk 2 booten oder kommt recht einfach an die Daten.

[Fisi]

Hallo,

ich habe es jetzt funktionsfähig bekommen
Mein Problem war wohl, dass ich ich pro Datenbank Slice nur eine Metadatenbank angelegt habe. Ich bin dann letztendlich nach dieser Anleitung vorgegangen und habe mehrere DBs pro Slice angelegt.

Hier nochmal zusammenfassend, welche Änderungen ich noch zusätzlich gemacht habe (falls vielleicht noch andere Probleme damit haben sollten)

/etc/system ergänzen
set md:mirrored_root_flag=1
set md_mirror:md_resync_bufsz = 2048

Bei x86

/boot/solaris/bootenv.rc: (2. Platte als alternative Bootplatte angeben)
setprop altbootpath '/pci@0,0/pci-ide@5/ide@1/cmdk@0,0:a'

2. Platte bootfähig machen
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d0s0

Bei SPARC

Die eeprom-Konfiguration auf zweite Festplatte erweitern:
# eeprom boot-device=`disk disk1 net`

2. Platte bootbar machen:
# installboot /usr/platform/`uname –i`/lib/fs/ufs/bootblk /dev/rdsk/c2d0s0

Jetzt kann jeweils eine der beiden Platten ausfallen und das System ist weiterhin bootfähig und kann einfach um eine neue Festplatte erweitert werden. Danach müssen dann entsprechend die Spiegel neusynchronisiert werden.

Ich danke euch sehr für eure Hilfe und Hinweise

LG, Fisi.