Ich war heute in Nürnberg auf der DOAG-Konferenz. Ziemlich viele gute Vorträge (da ich ja kein echter DBA bin sitze ich nicht so viel in den DB-, sondern eher in den Infrastruktur-Vorträgen), aber einer war eine echte Niete. Ein Conslutant hat vorgestellt, wie er und seine Kollegen einem bekannten deutschen Unternehmen, das wir im folgenden mal die Firma GmbH nennen wollen, dabei geholfen haben, ein Migrationsprojekt abzuschließen, das selbige Firma nicht alleine auf die Reihe gekriegt hat. Und irgendwie ist mir trotz Diskussion mit dem Vortragenden im Anschluß an dessen Präsentation immer noch nicht klar, was eigentlich der Verdienst besagter Beratungsfirma war.

Die beschriebene Situation war folgende: Migration von einem 3-Node RAC-Cluster mit 10.1.x.y auf einen 4-Node RAC-Cluster mit 11.2.x.y. Migration von alter auf neue Storage. Bisserl Kleinkram hintendran (geänderte ETL-Prozesse für das Data Warehouse etc.), aber nix weltbewegendes dabei. Was war passiert? Die Firma GmbH wollte hochverfügbare Storage, die schnell ist. Also redundanter Betrieb, aber die Verfügbarkeit sollte nicht durch ASM-Mirroring erreicht werden, sondern eben von der Storage kommen. Dummerweise waren die Leute, die die Storage gekauft haben, anscheinend nicht auf der Höhe ihres Jobs und haben eine Storage gekauft, die weder hochverfügbar noch schnell, dafür aber teuer war. Ferner hatte monatelang keine in der Firma GmbH den Arsch in der Hose, den Fehler einzugestehen und die Geschäftsführung um Geld für eine neue Storage zu bitten - und diesmal mit dem Hersteller zu vereinbaren, das man das Ding erst abnimmt, wenn man nachgemessen hat, das es schnell ist.

Fremdwahrnehmung: Die Consulting-Bude kam an, hat die Projektleitung abgesägt, viel Geld für eine neue, schnelle Storage ausgegeben, die vorhandene Storage für teueres Geld erweitert und die fehlenden HA-Features via teurem SAN-Virtualisierer nachgerüstet, womit das Ding dann schneller wurde, als man es jemals benötigt hat. Die IT'ler haben paar Nachtschichten geschoben (so what?). Und am Ende haben sie nach Stundensatz abgerechnet.

Eigenwahrnehmung: Die Consulting-Bude kam an und hat die bestehende Projektleitung bei der Ausarbeitung eines Notfallplans unterstützt. Im ersten Schritt wurde ein neuer Storage-Partner an Bord geholt, von dem man schnelle Storage sehen wollte - unter der Bedingung, daß man die alte Storage weiterverwenden kann. Ferner hat sie mit modersten Methoden des Projektmanagements die noch zu erledigenden Arbeiten parallelisiert (z.B. wurde der RAC-Cluster parallel zur Anschaffung der neuen Storage eingerichtet). Man hat klar kommuniziert und die bestehende Projektleitung hat die Führung des Projekts an die Conslutants abgegeben. Der Storage-Partner hat selbstlos zwei extrem schnelle Storages zur Verfügung gestellt, um die Migration zu beschleunigen, weil die Firma GmbH ihm auf Anraten der Consluting-Firma den SAN-Virtualisierer abgekauft hat. Selbiger Virtualisierer hat ermöglicht, daß man die bestehende Storage mitbenutzen kann (das waren ursprünglich zwei getrennte Systeme, die man dann zu einem zusammengefasst hat, um die Performance hinzubekommen - na ja, fast hinzubekommen, man musste da nochmal nachkaufen). Die Migration konnte durchgeführt werden, woraufhin die Geschäftsleitung der Firma GmbH, die toll mit den Conslutants zusammengearbeitet hat, sich dazu entschlossen hat, dem Storage-Partner noch eine der schnellen Storages abzukaufen (was für letzteren bestimmt total überraschend war!). Das ganze war nur durch die langjährige Erfahrung der Berater möglich - und durch den selbstlosen Einsatz der Mitarbeiter. Die Firma GmbH ist heute Referenzkunde bei besagtem Beratungsdienstleister.

WTF?

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