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:

UFS: 6: hashalloc degraded to search sequential [...]

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.