EMC Celerra: Finger weg von CDMS-Migrationen im TByte-Bereich
Es hätte alles so schön sein können: 4 Terabyte von einem Linux-Fileserver
waren auf eine EMC Celerra zu migrieren. Wie gut, daß die Celerra für so einen
Fall einen Mechanismus mitbringt, der das Problem in wenigen Minuten lösbar
macht: Die Rede ist von CDMS, dem Celerra Data Migration
Service. Dabei handelt es sich um eine Kombination aus einem speziellen
Filesystem - dem MGFS, aka Migration Filesystem,
welches offline inodes unterstützt - und im Hintergrund laufenden
Prozessen. Das Zusammenspiel klingt dabei denkbar cool: Das neu angelegte MGFS
wird von einem CDMS-Thread mit dem zu migrierenden Fileserver verbunden
(letzerer darf die Daten dazu natürlich nur noch an die Celerra exportieren).
Danach greifen alle Clients nur noch auf die Celerra zu. Im Hintergrund werden
dabei auf dem MGFS transparent die Verzeichnis-Strukturen und alle Nutzdaten,
die von Clients angefragt werden, angelegt. Wurde eine Datei zwar mal
aufgelistet (z.B. durch ein ls
auf das Verzeichnis), aber noch nie
aufgerufen, so ist der Status des Inodes offline. Sobald die Datei gelesen
wird, ist der Status online, weil sie ja wie erwähnt im Hintergrund vom
Source-Server übertragen wurde. Die Celerra tritt hierbei also als NFS- oder
CIFS-Proxy gegenüber den Clients auf - eine Migration ist somit in wenigen
Momenten erledigt. Um das übertragen der Nutzdaten zu beschleunigen, kann CDMS
im Hintergrund auch aktiv Daten mirgieren. Eigentlich, so sollte man meinen,
eine sehr elegant Lösung.
Der Teufel steckt wie immer im Detail: Im Gegensatz zum Standard-Dateisystem UxFS hat der Code des MGFS leider ein paar Optimierungen für große Dateisysteme verpasst. Die Folge davon ist, daß eine im Speicher des DataMover vorgehaltene Cache-Struktur bei großen Dateisystemen vollkommen versagt, wenn es darum geht, freie Blöcke für Schreibrequests zu finden. Im Log sieht man dann die Nachricht:
|
|
Wenn diese Situation auftritt, so ist die Celerra erstmal mehrere Minuten lang (je nach Größe des Filesystems und dessen Füllstand) damit beschäftigt, die gesamte Platte zu durchsuchen, um freie Blöcke zu finden, wo sie Daten hinschreiben kann. In dieser Zeit blockieren so ziemlich alle anderen Threads, die auf dem Dateisystem was tun wollen. Bei uns wurde das ganze kritisch, sobald 2,7TB auf dem 6TB Filesystem alloziert wurden. Das fiese ist, daß diese Situation bei jedem Schreibrequests passieren kann, also nicht nur bei einem im Hintergrund laufenden CDMS-Thread.
Ein Workaround, um wenigstens die Migration noch zu Ende zu bringen, ist es,
permanent Sparse Files zu erzeugen (512 Byte aus /dev/zero
, dann 16MByte
sparse, wieder 512 Byte etc.) - Skript dazu gibt es auf Anfrage. Nach Abschluß
der Migration steht ja die Konvertierung von MGFS nach UxFS an, und auch hier
kann man in besagte Situation fallen, so daß ein Vorgang, der sonst knappe 30
Sekunden dauert (aktuellen NAS-Code vorausgesetzt) auch gerne mal eine Stunde
Zeit erfordern könnte - und evt. das Filesystem offline bringt. Nach der
Konvertierung in ein UxFS wird ein paar Minuten lang der sog. cylinder group
bitmap cache initialisiert, danach sollten die Probleme der Vergangenheit
angehören.
Deswegen würde ich mir momentan gut überlegen, ob ich so eine Migration - bis
zum Erscheinen eines Fixes im Code, den ich hier bekannt geben würde - derzeit
durchführen würde, wenn große Dateisysteme betroffen sind. Ich selbst habe auf
jeden Fall eine Woche lang einen total kaputten Schlafrythmus gehabt, weil ich
meinem “Severity One”-Service Requests um die ganze Welt nachgereist bin. Am
Schluß habe ich die ganzen in Amerika, Kanada und Australien sitzenden
L2/L3-Supporter an ihren Telefonnummern erkannt. Und ich bin froh, daß der
Wahnsinn zu Ende ist - ich habe das server_cdms server_2 -C filesystemname
heute Nacht hinter mich gebracht und das UxFS hält bisher,
was es verspricht, keine Hinweise mehr auf hashalloc-Probleme.
Rachmaninov, Klavierkonzert Nummer 3 - genau das richtige zum Abschalten.