BBWC: teoretycznie dobry pomysł, ale czy kiedykolwiek zapisałeś twoje dane?

Wiem, do czego służy BBWC (pamięć podręczna zapisu z podtrzymaniem bateryjnym) - i wcześniej używałem ich na moich serwerach, nawet z dobrym zasilaczem UPS. Są oczywiste awarie, których nie zapewnia ochrony. Jestem ciekawy, czy rzeczywiście oferuje to jakąkolwiek rzeczywistą korzyść w praktyce.

(Uwaga: szczególnie szukam odpowiedzi od osób, które mają BBWC i miały awarie / awarie i czy BBWC pomogło odzyskać, czy nie)

Aktualizacja

Po otrzymaniu opinii jestem coraz bardziej sceptyczny, czy BBWC wnosi jakąkolwiek wartość.

Aby mieć pewność co do integralności danych, system plików MUSI wiedzieć, kiedy dane zostały przydzielone do nieulotnej pamięci masowej (niekoniecznie na dysk - kwestia, do której wrócę). Warto zauważyć, że wiele dysków kłamie na temat tego, kiedy dane zostały zapisane na dysku ( http://brad.livejournal.com/2116715.html ). Chociaż rozsądne wydaje się założenie, że wyłączenie bufora podręcznego na dysku może uczynić dyski bardziej uczciwymi, nadal nie ma gwarancji, że tak się stanie.

Ze względu na typowo duże bufory w BBWC, bariera może wymagać znacznie większej ilości danych na dysku, co powoduje opóźnienia w zapisie: ogólna rada to wyłączanie barier podczas korzystania z nieulotnej pamięci podręcznej zapisu (i wyłączanie włączenia buforowanie dysku). Wydaje się jednak, że podważa to integralność operacji zapisu - tylko dlatego, że więcej danych jest przechowywanych w pamięci trwałej, nie oznacza, że ​​będzie bardziej spójna. Rzeczywiście, prawdopodobnie bez rozgraniczenia transakcji logicznych wydaje się, że istnieje mniej możliwości zapewnienia spójności niż w innych przypadkach.

Gdyby BBWC uznało bariery w momencie, gdy dane wchodzą do ich nieulotnej pamięci masowej (zamiast zostać przydzielone na dysk), wydaje się, że spełnia wymóg integralności danych bez ograniczenia wydajności - co oznacza, że ​​bariery powinny być nadal włączone. Ponieważ jednak urządzenia te na ogół zachowują się spójnie z opróżnianiem danych do urządzenia fizycznego (znacznie wolniej z barierami) i rozpowszechnioną wskazówką dotyczącą wyłączania barier, nie mogą zatem zachowywać się w ten sposób. DLACZEGO NIE?

Jeśli we / wy w systemie operacyjnym jest modelowane jako seria strumieni, istnieje pewien zakres, aby zminimalizować efekt blokujący bariery zapisu, gdy buforowanie zapisu jest zarządzane przez system operacyjny - ponieważ na tym poziomie tylko transakcja logiczna (pojedynczy strumień ) musi zostać popełnione. Z drugiej strony BBWC, nie wiedząc, które bity danych składają się na transakcję, musiałby przekazać całą pamięć podręczną na dysk. To, czy jądro / systemy plików faktycznie to zaimplementują, wymagałoby o wiele więcej wysiłku, niż zamierzam zainwestować w tej chwili.

Kombinacja dysków informujących fibs o tym, co zostało popełnione, i nagła utrata mocy niewątpliwie prowadzi do uszkodzenia - oraz z systemem plików o strukturze Journalling lub logu, który nie robi pełnego fsck po awarii, jest mało prawdopodobne, że uszkodzenie zostanie wykryte, nie mówiąc już o tym próba naprawy.

Jeśli chodzi o tryby awarii, z mojego doświadczenia wynika, że ​​najbardziej nagłe przerwy w dostawie prądu występują z powodu utraty zasilania sieciowego (łatwo złagodzone za pomocą UPS i zarządzanego wyłączenia). Ludzie wyciągający niewłaściwy kabel ze stelaża sugerują słabą higienę centrów danych (etykietowanie i zarządzanie kablami). Istnieją pewne rodzaje nagłych awarii zasilania, których nie zapobiega UPS - awaria zasilacza lub VRM lub BBWC z barierami zapewniłaby integralność danych w przypadku awarii, jednak jak często zdarzają się takie zdarzenia? Bardzo rzadko, sądząc po braku odpowiedzi tutaj.

Z pewnością zwiększenie odporności na awarie na stosie jest znacznie droższe niż BBWC - jednak implementacja serwera jako klastra ma wiele innych korzyści pod względem wydajności i dostępności.

Alternatywnym sposobem na złagodzenie skutków nagłej utraty mocy byłoby wdrożenie SAN - AoE sprawia, że ​​jest to praktyczna propozycja (tak naprawdę nie widzę sensu w iSCSI), ale znowu jest to wyższy koszt.

Pewnie. Miałem pamięć podręczną z podtrzymaniem bateryjnym (BBWC), a później pamięć podręczną z pamięcią flash (FBWC) chronią dane w locie po awarii i nagłej utracie zasilania.

Na serwerach HP ProLiant typowy komunikat to:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Co oznacza: „ Hej, w pamięci podręcznej zapisu są dane, które przetrwały restart / utratę zasilania! Teraz zamierzam zapisać to z powrotem na dysk !! ”

Ciekawym przypadkiem był mój post-mortem systemu, który stracił moc podczas tornada , sekwencja tablic:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Błąd testu POST 1793 jest unikalny. - Gdy system był używany, zasilanie zostało przerwane, gdy dane znajdowały się w pamięci Array Accelerator. Jednak ze względu na to, że było to tornado, zasilanie nie zostało przywrócone w ciągu czterech dni, więc baterie matrycy zostały wyczerpane, a dane w nich utracone. Serwer miał dwa kontrolery RAID. Drugi kontroler miał jednostkę FBWC, która trwa znacznie dłużej niż bateria. Ten dysk został poprawnie odzyskany. Niektóre uszkodzenia danych spowodowały, że tablica jest wspierana przez pustą baterię.

Pomimo dużej ilości czasu pracy baterii w obiekcie, cztery dni bez zasilania i niebezpiecznych warunków uniemożliwiły każdemu bezpieczne wyłączenie serwerów.

Tak, miałem tę sprawę.

Serwer „bez UPS” w centrum danych (z centrum danych posiadającym UPS). Awaria PDU - system mocno się zawiesił. Bez utraty danych.

I w zasadzie to jest to. Zaletą BBWC jest to, że jest w maszynie. Miej UPS - uwierz mi, czasami ktoś robi coś głupiego (jak ciągnięcie niewłaściwego kabla). UPS jest zewnętrzny. Och, TEN kabel;)

Miałem 2 przypadki, w których pamięć podręczna podtrzymywana bateryjnie w kontrolerach HW RAID całkowicie zawiodła (w 2 oddzielnych firmach).

BBC opiera się na zaskakującym pomyśle, że bateria działa. Chodzi o to, że w pewnym momencie bateria w kontrolerze ulega awarii, a druzgocące jest to, że w wielu kontrolerach rajdowych HW zawiesza się cicho . Myśleliśmy, że mamy pamięć podręczną chronioną przed utratą zasilania, ale nie mieliśmy.

W przypadku utraty zasilania utrata danych z macierzy RAID była tak duża, że ​​cała zawartość dysku stała się niemożliwa do odzyskania. Wszystko zginęło. Jeden z przypadków dotyczył maszyny przeznaczonej wyłącznie do testowania, ale nadal.

Potem powiedziałem „nigdy więcej”, przestawiłem się na programowe tworzenie kopii lustrzanych dysków (mdadm) w systemie Linux + oparty na dzienniku fs, który ma przyzwoitą odporność na utratę zasilania (ext4) i nigdy nie oglądał się za siebie. To prawda, że ​​użyłem go na serwerach, które nie miały ekstremalnie wysokiego wykorzystania IO.

Wydaje się, że wymaga to drugiej odpowiedzi na pytanie ...

Właśnie miałem autonomicznego hosta VMware ESXi, który stracił dysk w macierzy RAID 5. Zdegradowana macierz wpłynęła na wydajność na poziomie maszyny wirtualnej i aplikacji.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

Informatyk w tej firmie nie był świadomy awarii dysku i twardego resetu serwera ( aby wszystko było lepiej? ).

Interesujący efekt zrobienia tego w przypadku skompromitowanej tablicy z zajętymi maszynami wirtualnymi działającymi na szczycie był następujący:

Szczegóły stanu pamięci podręcznej: aktualny kontroler macierzy miał prawidłowe dane zapisane w pamięci podręcznej zapisu wspieranej przez baterię / kondensator podczas ostatniego resetu lub zasilania. Oznacza to, że system mógł nie zostać bezpiecznie zamknięty. Kontroler macierzy automatycznie zapisał lub próbował zapisać te dane na dyskach. Ten komunikat będzie wyświetlany do następnego resetu lub cyklu zasilania kontrolera macierzy.

Nawet jeśli system został nagle zatrzymany, dane w locie były chronione przez BBWC. Wszystkie maszyny wirtualne zostały poprawnie odzyskane, a system jest teraz w dobrej formie.

Oprócz „zapisywania danych” są one również przydatne do innych celów. Są również dobre w buforowaniu zapisów (w pamięci podręcznej), aby poprawić wydajność podsystemu IO, utrzymując niską kolejkę zapisu na dysku. Jest to szczególnie ważne w przypadku serwerów, na których wydajność interaktywna jest najważniejsza - na przykład Citrix XenApp lub Windows Terminal Services.

Jest to mniej ważne dla serwera WWW lub serwera plików. Możesz nie zauważyć, a nawet przyzwyczaić się do niewielkiego opóźnienia. Jednak po kliknięciu ikony w aplikacji pakietu Office oczekujesz czasu reakcji. Podobnie robi twój CEO.