You are here

Vorsicht bei der Nutzung von SAN

Vorsicht bei der Nutzung von SAN (Storage Area Networks) oder ähnlichen Shard Storage Lösungen (und allen anderen Virtualisierungs-, Konsolidierungs- oder Cloud-Lösungen).

Diese Woche ist es wieder passiert: Ein Kunde rief bei uns an, weil er Ärger mit seinem on-line Shop hatte (siehe Datum!). Alle in seiner Firma beschwerten sich, dass die Datenbank langsam antwortet.

Als wir auf seine Maschine schauten (mit iostat), haben wir I/O Last und einige pending reads in InnoDB gesehen (SHOW ENGINE INNODB STATUS und SHOW GLOBAL STATUS LIKE 'InnoDB%') und eine sehr schlechte InnoDB Buffer Pool Hit Ratio (ungefähr 80%, ja, ich weiss Hit Ratios sind schlechte Indikatoren, aber manchmal sind sie recht nützlich).

Der Kunde beteuerte, dass er seit einigen Tagen nichts am System geändert habe. Und am vorherigen Tag sei alles prima gelaufen, aber an diesem Nachmittag wurde das System plötzlich langsam. Er teilte uns im weiteren mit, dass sie zur Zeit daran seien, Monatsreports zu generieren. Aber nur auf den Slaves.

Wir fanden eine Abfrage, welche seit 25 Minuten am laufen war, also nahm ich an, dass diese Abfrage der Übeltäter ist. Nachdem wir die Abfrage gekillt hatten, entspannte sich das System ein wenig, war aber immer noch unter I/O last und der Kunde merkte an, dass wir kurz vor Ende der Hauptlast-Zeit sind. Das würde erklären, warum das System nicht mehr so ausgelastet sei.

Bis zu diesem Zeitpunkt hatte ich keine Ahnung, was der Grund für unser Problem ist. Etwas frustrierend, wenn man dem Kunden nicht erklären kann, warum er gerade ein Problem hat.

Glücklicherweise kam gerade einer der Systemadministratoren ins Büro und beschwerte sich, dass wir gerade sein SAN füllen. Schuld sei der Slave unseres langsamen Masters. Auf dem Slave fanden wir eine Abfrage (Monatsend-Report), welche seit 2 bis 3 Stunden am laufen war, welche eine temporäre Tabelle von ungefähr 350 Gbyte erzeugte! Diese Tabelle füllte das SAN auf ungefähr 99%.

Der Systemadministrator bemerkte im Weiteren, dass das Füllen eines SAN's auf mehr als 90%, das ganze SAN ausbremsen würde (warum auch immer).

Diese Aussage liess bei uns die Alarmglocken klingeln: Hatten wir nicht ein I/O Problem, welches urplötzlich vor 2 bis 3 Stunden einsetzte? Wir fanden heraus, dass unser Master und der Slave unglücklicherweise auf dem selben SAN platziert waren.

Als wird die Abfrage gekillt hatten, wurde die Tabelle automatisch gelöscht und nach einigen Minuten wurde der Diskplatz wieder frei gegeben. Mir wurde gesagt, dass es einige Stunden dauert, bis das SAN sich wieder beruhigt haben wird (warum auch immer). Am nächsten Tag bestätigte der Kunde, dass alles wieder wie gewohnt läuft. Somit können wir ziemlich sicher sein, dass das Füllen des SAN's mit dem Slave das Problem auf unserem produktiven Master verursacht hat.

Schlussfolgerung: SAN's können verschiedene unerwartete Nebeneffekte und Auswirkungen auf die Performance haben. Wenn Sie nicht ungewollt unvorhersehbare Performanceauswirkungen erleben wollen, versuchen sie auf dedizierten Storagelösungen zu bleiben.

Siehe auch unser Commit Demo Test:

trx_san_vm.png