„Wir haben ein Problem“ – Wenn der Platz ausgeht …

Hin und wieder kommt es vor, dass Storage-Systeme „einfach“ volllaufen. Die Folgen laufen fast immer auf einen Systemstillstand hinaus. Nicht selten zu 100%.

Schuld ist meist einer dieser Punkte:

  • Hängengebliebene Snapshots
  • Überprovisionierte Storages – „Thin Provisioning“
  • Software

Gehen wir auf die einzelnen Punkte näher ein:

Snapshots

Wir alle lieben Snapshots. Mal schnell ein Upgrade rückgängig machen? Kein Problem.

Man sagt, ein VM-Snapshot sollte nicht älter als 48 Stunden werden. Das wäre eine gute Faustregel. In der Realität existieren Snapshots aber oft Wochen, Monate und manchmal sogar Jahre auf einer VM.

Neben anderen Randerscheinungen, benötigen diese natürlich Speicherplatz. Was uns hier zum Thema bringt. Snapshots können gigantisch groß werden, denn jede Änderung an der jeweiligen Disk wird in ein eigenes Delta-File geschrieben. Wenn eine Applikation „Amok“ läuft und wie verrückt Daten (zB. Logs) produziert, kann ein Datastore schnell an seine Kapazitätsgrenzen kommen. Zumindest für diese eine VM wäre hier Schluss – bedeutet der Service wird nicht mehr verfügbar sein.

Snapshots gibt es auch eine Ebene weiter unten. Netapp hat Snapshots Salonfähig gemacht. Ich kenne keine einzige Netapp-Installation wobei keine Snapshots angelegt werden. Hier gibt es einen Snapshot-Reserve-Bereich, worin die „Delta“ abgelegt werden. Läuft dieser über, wird freier Speicherplatz aus dem jeweiligen Volume allokiert. Ist dieser bis auf die letzten 4KB verbraucht, ist auch hier Schluss. Sollten LUNs im Volume abgelegt sein, werden diese auf Read-Only gesetzt. Auch hier geht schlussendlich ein Service Offline.

 

Wie kann man das umgehen?

Seitens VMware empfehle ich einen Alarm zu definieren, welcher erscheint sobald ein Snapshot eine gewisse Größe überschreitet. Ein guter Schwellwert ist in meinen Augen 1GB. Damit wird man aktiv daran erinnert, dass hier noch ein Snapshot hängt.

Seitens Storage empfiehlt sich in erster Linie ein regelmäßiges Monitoring der Snapshots. Entweder man verändert die Retention oder man weist dem Volume mehr Speicherplatz zu. Bei Netapp kann man übrigens definieren, was im oben genannten Fall passieren soll. Entweder die Read-Only-Variante oder löschen des ältesten Snapshots. Default ist übrigens Read-Only.


Ueberprovisionierung

Alias „Thin Provisioning“. Gerne auch als Teil von „Storage Efficiency“ betitelt.

Was ist „Thin Provisioning“? Im Grunde ist das schnell erklärt. Eine LUN stellt 100GB Speicherkapazität zur Verfügung. Jedoch sind davon nur 35GB belegt. Warum also am Storage 100GB Kapazität reservieren, wenn ich mir 65GB sparen kann? Ist eine LUN „thin“ provisioniert, werden tatsächlich nur die genutzten 35GB am Storage verbraucht. Das Betriebssystem sieht jedoch 100GB und kann diese auch verwenden. Kommen also 40GB Daten hinzu, verbraucht diese LUN effektiv 75GB am Storage.

„Thin Provisioning“ kann auf mehreren Ebenen aktiviert werden. Konkret fallen hier auch wieder die zwei oben Kandidaten aus dem Snapshot-Szenario ins Gewicht. Fast jeder kennt zB. die Auswahl bei der Erstellung von neuen VMs oder VMDKs:

VMware_Thin_Thick_Provision

Nicht selten wird hier „thin“ ausgewählt. Das macht durchaus auch Sinn (sofern man ein VAAI aktiviertes Storage verwendet). Jedoch kommt man hier in die selbige Situation wie mit den Snapshots. Wenn auf einmal eine „thin“-Disk anwächst und der Datastore zu 100% gefüllt ist, bleiben sämtliche „thin“-Disks und somit auch VMs und Services stehen.

Am Storage passiert genau das gleiche. Habe ich in einem Aggregat nur 15TB Speicherkapazität zur Verfügung, platziere aber 10 Volumes mit je 2TB, geht dass genau solange gut bis genau die verfügbaren 15TB aufgebraucht wurden.

 

Wie kann man das umgehen?

Monitoring ist alles.

Seitens VMware kann wieder ein Alarm definiert werden, welcher den Datastore überwacht.

Auch am Storage läuft es darauf hinaus: Immer regelmäßig den tatsächlichen Verbrauch monitoren und Alarmierungsmails nicht zu ignorieren. Als gut gemeinter Ratschlag: Wenn du einen gewissen Respekt vor deinem Storage hast, aktivierte dieses Feature nicht. Ebenso solltest du die Finger davon lassen, solltest du der einzige Storage-Admin sein. Wer übernimmt das Monitoring und eventuelle Anpassungen in deinem 4-wöchigen Urlaub?

Besonders fatal kommt mir übrigens die Kombination mehrerer „Thin Provisionings“ vor. Wenn also Volumes am Storage sowie VMs als thin provisioniert sind. Dann hat man sein 15TB Storage mit 20TB provisioniert und provisioniert VMDKs in Summe mit 23TB.


Fehlerhafte-Software

Mit „Software“ bewege ich mich in diesem Artikel zum ersten Mal auch ins Innere einer VM.

Fangen wir gleich damit an. Stellt euch vor, eine Software fängt auf einmal an unkontrolliert Log-Files zu produzieren. Schlussendlich läuft die jeweilige Partition voll und die eigentliche Applikation kann nicht mehr arbeiten. So ein SQL-Server ist hier ein gutes Beispiel. Wie oft truncated ihr eure Log-files? Ein Beispiel für fehlerhafte Software könnte zB. eine Applikation sein, welche irgendwie im Restart-Loop hängt und dabei Unmengen von Logs generiert.

Das hat übrigens gleich mehrere Auswirkungen. Denn läuft der SQL-Server in einer VM, welche „thin“ provisioniert ist wächst die VM sehr schnell an. Ist der Datastore auch noch „thin“ provisioniert, zieht sich das bis ganz nach unten durch.

Das Beispiel ist nicht bei den Haaren herbeigezogen. So ein DBA macht schnell mal eine Wartung und migriert Daten. 🙂

Was eher selten ist, sind Bugs in der Storage-Firmware. Ontap hatte letztens  einen Fehler im DeDupe-Bereich. Dabei wurden alte Fingerprints nicht gelöscht. Das können auf Dauer mehrere TB werden, was ein Aggregat zum überlaufen  bringen kann.

 

Wie kann man das umgehen?

Ich muss mich leider nochmals wiederholen. Regelmäßiges Monitoring ist alles. 🙂

Was die Applikationsschicht betrifft, sollte man sich überlegen wo welche Daten abgelegt werden. Bei einem SQL-Server trennt man für gewöhnlich Datenbanken von Logs, usw.! Dh. jeweils eigene LUNs/VMDKs verwenden.

Generell ist ein regelmäßiger Blick in die Release-Notes diverser Hersteller anzuraten. Hin und wieder findet man behobene Bugs, in die man zu einem späteren Zeitpunkt eventuell gelaufen wäre.

 

 

Ich hoffe der Artikel ist für den ein oder anderen hilfreich. Das es die oben genannten Probleme gibt, weiß ich aus meinen täglichen Supportanfragen …

Habt ihr noch Tipps? Was fehlt euch hier?

Ein Gedanke zu „„Wir haben ein Problem“ – Wenn der Platz ausgeht …“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.