Gandi tłumaczy awarię swojego serwera. Zawiódł ZFS
Operator DNS i usługodawca hostingu Gandi doświadczył na początku roku (ósmego stycznia) awarii jednego ze swoich magazynów pamięci stałej (storage unit). Ucierpiało na tym do 414 klientów, korzystających między innymi z IaaS – infrastruktury jako usługi. O sprawie głośniej jest dopiero teraz, ponieważ firma wydała szczegółowe i bardzo interesujące oświadczenie dotyczące problemu.
BSD + ZFS
W swoim IaaS Gandi stosuje system FreeBSD oraz potrójny mirroring macierzy dyskowych zapewniany przez system plików ZFS. System ten pozwala klientom infrastruktury na robienie migawek. Należy tutaj zaznaczyć, że migawki i nadmiarowe macierze dyskowe nie są mechanizmem tworzenia kopii zapasowych. To metoda zwiększania dostępności (high availability), a nie bezpieczeństwa danych. Jest w tym subtelna różnica.
Po awarii jednego z serwerów przechowywania stan macierzy był niemożliwy do przywrócenia, ponieważ sama pula ZFS raportowała uszkodzenie. Wymiana sprzętu i wymuszenie importu puli doprowadziło do sytuacji, w której odbudowa znanego stanu trwała tak długo, że wymagałaby 370 godzin na ukończenie.
Stara implementacja
Dokumentacja oferowała opisy parametrów potencjalnie przyspieszających odnalezienie spójnego stanu, ale wersja użyta w Gandi była za stara i nie implementowała ich. Zapadła decyzja, by sprzęt z pulą podpiąć do nowego serwera, z nowszą wersją ZFS. Użyto linuksowej implmenetacji (ZOL). Gandi przytacza ustawienia, które zmodyfikowano celem uniknięcia przejść przez całą pulę i zapewnienia trybu tylko-do-odczytu. ZOL poradził sobie z odbudową puli, ale przywrócenie danych i sprawności infrastruktury zajęło aż cztery dni (!)
Expect the unexpected
Gandi miało nieprzyjemność wpaść w ciekawy scenariusz problemowy. Zastosowany system ZFS i potrójny mirroring (ponad połowa dysków w macierzy może umrzeć i nic się nie stanie) zapewniały łatwą odbudowę w razie awarii oraz szybko dostępne migawki dla spokoju sumienia. Problem, nieznanej zresztą genezy, wywołał jednak awarię metadanych, a na to ZFS nie był odporny tak od razu. Użycie od razu nowszej jego wersji, przyspieszającej odbudowę, doraźnie rozwiązałoby problem klientów, ale wciąż nie adresowało słabości, jaką była awaria metadanych.
To doskonały przykład trudności projektowania mechanizmów odtworzenia po katastrofalnych awariach (disaster recovery, DR). Konieczność postawienia granic w nadmiarowości może poskutkować pominięciem niektórych rzadkich, dziwnych scenariuszy. Nawet jeżeli ktoś w zespole pomyślał o potencjalnym problemie z metadanymi, bardzo możliwe, że odpowiedzią było "no ale na czymś przecież musimy polegać! Jasne, że może się wyłożyć rejestr metadanych, mogą też się popsuć wszystkie dyski w macierzy, może od razu wybudujmy dwie serwerownie?".
Tymczasem powód awarii dalej jest nieznany. Sprzęt okazał się sprawny. Po prostu struktura logiczna danych nagle odmówiła posłuszeństwa. A Gandi prawdopodobnie nie jest jedyną firmą nieposiadającą dokumentu "Procedura Odzyskiwania Danych na ewentualność absurdalnego problemu z integralnością, bez sensownych wytłumaczeń".