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.
