Jako że jesteśmy ostatnio w temacie BBU do kontrolerów, dziś chciałbym napisać o takim drobnym szczególiku, o którym dobrze jest pamiętać wybierając sprzęt do serwera na którym działać ma MySQL.

Wdrażasz drogi czytelniku duży, rozbudowany projekt. Kilka – kilkanaście serwerów MySQL, sharding, replikacja, cuda najróżniejsze. Sprzęt markowy, Dell na przykład. Serwery dobrane jak należy – szybkie dyski, RAID, bateria, dużo pamięci. Aplikacja gruntownie przetestowana, wszystko ładnie, stabilnie chodzi. Odpalamy całość produkcyjnie.

Przez kilka dni całość działa znakomicie, potem jednak, niespodziewanie, serwery zaczynają niedomagać. I/O staje się niestabilne, znacząco zwiększa się obciążenie podsystemu dyskowego – w efekcie serwis dostaje czkawki. Żeby było zabawniej, problem występuje hurtowo, na wszystkich maszynach. Co jest grane? Sprzęt? Aplikacja? Konfiguracja?
Co się stało? No cóż, baterie zaczęły się testować.

Kontrolery LSI, także wszystkie ich warianty udostępniane przez Intela, Della, HP i innych dostawców sprzętu (w praktyce jest to sprzęt LSI, jedynie oprogramowanie jest ewentualnie tuningowane i dostosowane do danej platformy serwerowej), co pewien czas odczuwają potrzebę przetestowania baterii. Chodzi o to, że kontroler musi być pewny, że bateria posiada pojemność odpowiednią do tego, żeby podtrzymać cache przez wystarczający czas. Test sprowadza się z grubsza do tego, że bateria jest w kontrolowany sposób rozładowywana i ładowana później do pełna. Cały proces trwa kilka (kilkanaście) godzin. Jako że konieczne jest rozładowanie baterii, w razie nagłego wyłączenia serwera nie będzie możliwości podtrzymania zawartości cache. Z tego powodu, ze względu na bezpieczeństwo danych, na czas testu baterii cache zapisu jest wyłączany. Co to znaczy, pisałem w poprzednim poście. Wydajność siada prawie o połowę i jeśli serwer jest mocno obciążony, to po prostu nie będzie w stanie zapewnić stabilnego dostępu do danych.

Tego typu test baterii wykonywany jest automatycznie, co najwyżej można zdefiniować w jakim przedziale czasowym ma być realizowany. Nie ma możliwości zrezygnowania z tego typu testów (a przynajmniej oprogramowanie udostępniane przez LSI nie daje takiej możliwości – jeśli ktoś się z taką opcją zetknął, to prosiłbym o informację w komentarzu).

Jeśli posiadamy już serwery, to rozwiązanie w takiej sytuacji właściwie nie istnieje. Jedyne co można zrobić, to po prostu być świadomym, że do tego typu sytuacji dojdzie i odpowiednio zaplanować rozłożenie obciążenia (np. dostawienie dodatkowego serwera). Można też, o ile oprogramowanie kontrolera to umożliwia, spróbować zaplanować testy na poszczególnych serwerach na różne dni – tak aby spadek wydajności nie wystąpił na wszystkich maszynach na raz.

Jedyny realny sposób na uniknięcie tego typu sytuacji pojawia się na etapie zakupu sprzętu. Trzeba wybrać odpowiedni kontroler. LSI sprzedaje różne modele baterii, które pasują do różnych kontrolerów. Te BBU mają następujące oznaczenia: LSIiBBU07, LSIiBBU08 i LSIiBBU09. Dwa ostatnie z nich posiadają taką cechę, jak “transparentny cykl nauki”. Chodzi tu właśnie o to, że w trakcie testowania baterii cache zapisu nie jest wyłączany i wydajność nie spada. Aby było to możliwe, trzeba zrezygnować z gwarancji długiego czasu podtrzymywania (zamiast 48 godzin gwarantowane jest tylko 12 lub 24 godziny, w zależności od temperatury pracy baterii), ale plusy tego typu rozwiązania są znaczne. Jest to możliwe dzięki temu, że podczas testu bateria rozładowywana jest tylko do takiego poziomu, który jeszcze zagwarantuje że w razie padu serwera te 12 godzin jesteśmy w stanie wytrzymać. Jeśli gwarancja jest, to cache zapisu może być włączony. Trochę więcej na ten temat można znaleźć w ulotce LSI.

Drobny niuansik, o którym dobrze wiedzieć aby nie zostać zaskoczonym w momencie gdy będzie już za późno i serwery będą padać pod obciążeniem.