Jak przechowywać dane na maszynie, której zasilanie zostaje odcięte losowo

13

Mam maszynę wirtualną (Debian) działającą na hoście maszyny fizycznej. Maszyna wirtualna działa jako bufor dla danych, które często otrzymuje przez sieć lokalną (okres dla tych danych wynosi 0,5 s, więc dość wysoka przepustowość). Wszelkie otrzymane dane są przechowywane na maszynie wirtualnej i wielokrotnie przekazywane do zewnętrznego serwera przez UDP. Gdy serwer zewnętrzny potwierdzi (przez UDP), że otrzymał pakiet danych, oryginalne dane są usuwane z maszyny wirtualnej i nie są ponownie wysyłane na serwer zewnętrzny. Połączenie internetowe łączące maszynę wirtualną z zewnętrznym serwerem jest zawodne, co oznacza, że może być wyłączone przez kilka dni.

Fizyczna maszyna, na której znajduje się maszyna wirtualna, jest losowo odcinana kilka razy dziennie. Nie ma sposobu, aby powiedzieć, kiedy to nastąpi, i nie można dodać zasilacza UPS, baterii ani podobnego rozwiązania do systemu.

Pierwotnie dane były przechowywane w bazie danych HSQLDB opartej na plikach na maszynie wirtualnej. Jednak częste przerwy w dostawie prądu ostatecznie powodują uszkodzenie pliku skryptu bazy danych (nie na poziomie systemu plików, tzn. Jest on czytelny, ale HSQLDB nie może tego zrozumieć), co prowadzi do mojego pytania:

Jak dane powinny być przechowywane w środowisku, w którym przerwy w dostawie prądu mogą się często zdarzać?

Jedną z opcji, o której mogę myśleć, jest używanie plików płaskich, zapisywanie każdego pakietu danych jako pliku w systemie plików. W ten sposób, jeśli plik jest uszkodzony z powodu utraty zasilania, można go zignorować, a reszta danych pozostanie nienaruszona. Powoduje to jednak kilka problemów, głównie związanych z ilością danych, które prawdopodobnie są przechowywane na maszynie wirtualnej. Co 0,5 sekundy między każdą częścią danych, w ciągu 10 dni zostanie wygenerowanych 1 728 000 plików. Oznacza to co najmniej użycie systemu plików ze zwiększoną liczbą i-węzłów do przechowywania tych danych (w bieżącej konfiguracji systemu plików zabrakło i-węzłów przy ~ 250 000 komunikatów i zużyte 30% miejsca na dysku). Ponadto zarządzanie jest trudne (nie niemożliwe).

Są jakieś inne opcje? Czy istnieją silniki baz danych działające na Debianie, które nie uległyby uszkodzeniu w wyniku awarii zasilania? Jakiego systemu plików należy w tym celu użyć? ext3 jest obecnie używany.

Oprogramowanie działające na maszynie wirtualnej jest napisane w Javie 6, więc mam nadzieję, że rozwiązanie nie będzie niezgodne.

debian filesystems corruption

— Sevas
źródło

14

„Fizyczna maszyna, na której znajduje się maszyna wirtualna, jest losowo odcinana kilka razy dziennie. Nie ma sposobu, aby powiedzieć, kiedy to się stanie, i nie można dodać zasilacza UPS, baterii ani podobnego rozwiązania do system." I naprawdę chcesz wiedzieć, jak to możliwe. Czy jest to na Międzynarodowej Stacji Kosmicznej, więc potrzeba 20 milionów dolarów, aby wysłać UPS czy coś takiego?

— ceejayoz

3

Czy urządzenie ma przynajmniej kontroler RAID z pamięcią podręczną podtrzymywaną bateryjnie?

— Zoredache,

4

Możemy polecić bardzo interesujące, kreatywne i być może teoretycznie poprawne rozwiązania tego problemu. Nie wiemy jednak, jaki hypervisor i sprzęt działają na hoście, więc nie ma gwarancji, że zapisy na dysku są naprawdę zapisywane lub zapisywane we właściwej kolejności…

— pino42,

5

@Sevas Wygląda na to, że to nie twoja rozmowa, ale sugeruję, że warto zauważyć, że 50 podstawowych, tanich zasilaczy UPS kosztowałoby 2500 USD i nie wymaga konserwacji (wymieniasz je po kilku latach, kiedy baterie zaczną się rozładowywać) ). Koszt próby rozwiązania tego problemu w oprogramowaniu będzie znacznie wyższy, chyba że znasz grupę programistów pracujących za darmo. Pomocne może być nakłonienie kierownictwa do rozwiązania tego problemu za 50 USD za jednostkę, zamiast dziesiątek lub setek wykwalifikowanych roboczogodzin przy 3 liczbach na godzinę.

— HopelessN00b

9

To właściwie brzmi jak złośliwy program. Użytkownik nie wie, że na jego komputerze działa „VM”. Kradnie dane z całej sieci - następnie rozprowadza je za pomocą jednego połączenia, aby się ukryć. Użytkownik „losowo wyłącza i włącza komputer”, więc nie można po prostu dodać zasilacza UPS.

— Laurence

23

Szczerze mówiąc, Twoim najlepszym podejściem jest naprawienie awarii zasilania lub wdrożenie innego systemu w lepszej lokalizacji.

Tak, istnieją systemy takie jak redis, które będą przechowywać dane w dzienniku tylko do dołączania w celu odtworzenia, ale ryzykujesz uszkodzenie na niższych poziomach - np. Jeśli twój system plików jest zaszyfrowany, dane na dysku są potencjalnie zagrożone.

Doceniam, że jakakolwiek poprawa byłaby dla ciebie przydatna, ale tak naprawdę nie jest to problem, który można rozwiązać, biorąc pod uwagę nakreślony przez ciebie scenariusz.

8

+1 Prawidłowa odpowiedź to „Nie rób tego”

— Chris S

6

+1 Ostatecznie przypadkowe przerwy w zasilaniu spowodują uszkodzenie systemu plików. Elektronika robi dziwne, nieprzewidywalne rzeczy, ponieważ ich moc nie działa.

— Grant

-1 (wirtualny -1). Myślę, że taki system musi opierać się na założeniu, że od czasu do czasu dochodzi do przerw w dostawie prądu. To założenie jest faktem, z którym musisz sobie poradzić.

— Igal Serban

11

Twoje podejście może działać. Pozwól, że zasugeruję kilka ulepszeń. Wystąpiło pytanie o przepełnienie stosu podczas zapisu atomowego do pliku . Zasadniczo zapisujesz każdy pakiet danych w pliku tymczasowym, a następnie zmieniasz jego nazwę na jego ostateczną nazwę. Zmiana nazwy jest operacją atomową, która będzie bezpieczna od awarii zasilania. W ten sposób masz pewność, że wszystkie twoje pliki w miejscu docelowym zostały poprawnie zapisane bez żadnych uszkodzeń.

To, co możesz zrobić, aby poradzić sobie z problemem posiadania milionów plików. Czy cron to zadanie uruchamiane może co godzinę, które zajmuje wszystkie pliki starsze niż godzinę i łączy je w jeden duży plik, używając ponownie operacji na plikach atomowych, dzięki czemu zadanie to działa bezpiecznie nawet podczas awarii zasilania, a następnie usuwa stare pliki. Coś w rodzaju rotacji kłody. Pliki warte godziny będą około 7200 plików. Dlatego w żadnym momencie nie powinieneś mieć więcej niż 20 000 plików na dysku.

— Marwan Alsabbagh
źródło

1

Nie jest to zła odpowiedź, ale problemem jest założenie, że sam zapis jest operacją atomową, a tak nie jest. Dlatego awaria zasilania w niewłaściwym czasie może nadal powodować uszkodzenie danych lub FS. Prawdopodobnie o najlepszej opcji poza ustaleniem zasilania lub podłączeniem rzeczy do UPS, więc +1.

— HopelessN00b,

@ Zmiana nazwy

— Marwan Alsabbagh,

Tak, zmiana nazwy pliku po zapisaniu jest operacją atomową. Zapisywanie pliku w pierwszej kolejności nie jest.

— HopelessN00b

3

@ HopelessN00b Nie ma znaczenia, że nowy plik jest w połowie zapisany lub uszkodzony. Masz stary plik, który jest w dobrym stanie. Odzyskiwanie systemu powoduje zniszczenie w połowie zapisanego pliku.

— DJClayworth,

2

@ HopelessN00b Dokładnie! tylko pliki tymczasowe w katalogu tymczasowym, powiedzmy, mogą być w połowie zapisane. Wszystkie pliki w twoim ostatecznym katalogu docelowym zawsze będą nieuszkodzone i bezpiecznie

— zapisane

7

Instalujesz UPS lub kartę RAID z zasilaną bateryjnie pamięcią podręczną zapisu do systemu, a już za 49,95 USD osiągasz to , czego nie da się osiągnąć w samym oprogramowaniu.

Twierdzenie, że w jakiś sposób nie można podłączyć tego serwera do zasilacza UPS lub baterii ... jest po prostu niewiarygodne.

— Beznadziejny
źródło

9

Biurokratyczna głupota jest zawsze wiarygodna.

— Dan bawi się w Firelight

3

@ DanNeely My PHB won't let me hook this up to a UPS/batteryjest czymś zupełnie innym niż it is not possible to add a UPS, a battery, or a similar solution to the system. niezbyt pedantycznym, ale jest to ważne rozróżnienie, ponieważ zmienia podejście i dostępne rozwiązania.

— HopelessN00b

Lub, jak wspomniano w innym miejscu, użytkownik komputera porwanego byłby zaskoczony, gdybym poprosił o zainstalowanie zasilacza UPS. W przeciwnym razie sytuacja jest nieco niewiarygodna. Każdy, z uzasadnionego powodu, zaakceptuje UPS w związku z uszkodzonymi danymi, biorąc pod uwagę właściwe uzasadnienie biznesowe.

— WernerCD

@WernerCD Chciałbym, żebyś poznał naszego CIO. Chociaż zgadzam się, że przejmowanie czyjegoś komputera jest możliwym przykładem użycia, mogę również myśleć o uzasadnionych, więc dam facetowi wątpliwości. Pomyśl o systemach wbudowanych i kontrolerach lub o Raspberry Pi - z pewnością może się zdarzyć, że używany komputer będzie wart mniej niż 50 USD, które trzeba by było podłączyć do zasilacza UPS.

— HopelessN00b

Nawet jeśli komputer jest wart mniej niż 50 $ UPS - to dane na komputerze są w rzeczywistości coś warte. Google został zbudowany na „bezwartościowych” komputerach. Ważniejszy niż koszt procesora jest koszt utraconych danych, utraconej siły roboczej (ta przygoda programowa, ściganie uszkodzeń danych, śledzenie błędów w starym systemie, a także nowa część), utracona wartość klientów (Lost my data?

— Poproszę

5

Zamontuj cały system tylko do odczytu, z wyjątkiem urządzenia blokowego, które przechowuje wszystkie dane. Skorzystaj bezpośrednio z tego urządzenia blokowego i za pomocą tego surowego urządzenia blokowego zaimplementuj własny mechanizm przechowywania danych.

— MikeyB
źródło

3

... i zainwestuj w kartę kontrolera dysku z podtrzymaniem bateryjnym i upewnij się, że na dysku nie ma pamięci podręcznej zapisu, w przeciwnym razie nadal masz problemy.

— voretaq7,

Przybył tutaj, aby powiedzieć, że powinni się uruchamiać z Live-CD lub równoważnego systemu ROM, z pewną ilością pamięci półprzewodnikowej używanej z płaskimi rozwiązaniami plików.

— Mark Allen

Pamięć podręczną zapisu można wyłączyć. To podejście jest realne. Dołącz tylko Zalecany jest mechanizm pamięci. Bloki są zapisywane atomowo (zakładam), dzięki czemu można mieć dwa bloki „wskaźnikowe”, które wskazują początek i koniec sekcji z nowymi danymi / todo. Wskaźniki są aktualizowane po zapisaniu / zakończeniu danych. NCQ również powinno być wyłączone.

— sleeplessnerd