Як зберігати дані на машині, потужність якої скорочується навмання

13

У мене віртуальна машина (Debian) працює на хості фізичної машини. Віртуальна машина виступає в якості буфера для даних, які вона часто отримує через локальну мережу (період для цих даних становить 0,5 с, тому досить висока пропускна здатність). Будь-які отримані дані зберігаються на віртуальній машині та повторно передаються на зовнішній сервер через UDP. Після того, як зовнішній сервер визнає (через UDP), що він отримав пакет даних, вихідні дані видаляються з віртуальної машини і більше не надсилаються на зовнішній сервер. Підключення до Інтернету, яке з'єднує VM та зовнішній сервер, ненадійне, тобто може бути відключено протягом кількох днів.

Фізична машина, яка розміщує ВМ, вимикає потужність кілька разів на день навмання. Немає можливості сказати, коли це станеться, і неможливо додати в систему джерело живлення, акумулятор чи подібне рішення.

Спочатку дані зберігалися у файловій базі даних HSQLDB на віртуальній машині. Однак часті відключення живлення зрештою призводять до пошкодження файлу скрипта бази даних (не на рівні файлової системи, тобто він є читабельним, але HSQLDB не може його мати сенс), що призводить до мого питання:

Як слід зберігати дані в середовищі, коли відключення електроенергії можуть і трапляються часто?

Один з варіантів, який я можу придумати, - це використання плоских файлів, збереження кожного пакету даних у вигляді файлів у файловій системі. Таким чином, якщо файл пошкоджений через втрату живлення, його можна проігнорувати, а решта даних залишиться недоторканою. Однак це викликає декілька питань, головним чином пов'язаних із кількістю даних, які, ймовірно, зберігаються на віртуальній машині. За 0,5s між кожним фрагментом даних за 10 днів буде створено 1,728,000 файлів. Принаймні, це означає використання файлової системи із збільшеною кількістю входів для зберігання цих даних (поточна настройка файлової системи закінчилася в розмірах ~ 250 000 повідомлень та 30% використовуваного дискового простору). Також керувати важко (не неможливо).

Чи є інші варіанти? Чи є двигуни бази даних, які працюють на Debian, які не були б пошкоджені відключення живлення? Також яку файлову систему слід використовувати для цього? ext3 - це те, що використовується на даний момент.

Програмне забезпечення, яке працює на віртуальній машині, написане за допомогою Java 6, тому, сподіваємось, рішення не було б несумісним.

debian filesystems corruption

— Севас
джерело

14

"Фізична машина, на якій розміщений VM, вимикає живлення кілька разів на день навмання. Немає способу сказати, коли це станеться, і неможливо додати джерело живлення, батарею чи подібне рішення система ". Я дуже хочу знати, як це можливо. Чи є це на Міжнародній космічній станції, тож потрібно 20 мільйонів доларів, щоб відправити ДБЖ або щось таке?

— ceejayoz

3

Чи принаймні машина має RAID-контролер з кешем, керованим акумулятором?

— Зоредаче

4

Ми могли б порекомендувати дуже цікаві, творчі та, можливо, теоретично правильні рішення цієї проблеми. Однак ми не знаємо, який гіпервізор та апаратне забезпечення працює на хості, тому не було б гарантії, що записи на диску дійсно написані або написані у правильному порядку ...

— pino42

5

@Sevas Здається, що це не ваш дзвінок, але я б припустив, що варто зазначити, що 50 базових дешевих ДБЖ обійдуться в 2500 доларів і не потребують технічного обслуговування (ви замінюєте їх через пару років, коли батареї почнуть заряджатися ). Вартість спроби вирішити це в програмному забезпеченні буде набагато вище, ніж якщо ви не знаєте купу кодерів, які працюють безкоштовно. Може допомогти керівництву вирішити це за 50 доларів / одиницю замість десятків чи сотень кваліфікованих людино-годин @ 3-цифри на годину.

— HopelessN00b

9

Це насправді звучить як шкідлива програма. Користувач не знає, що "VM" працює на їх комп'ютері. Це крадіжка даних у всій мережі - потім виведення їх через одне з'єднання, щоб приховати себе. Користувач "вимикає і вмикає комп'ютер" випадковим чином, тому ви не можете просто додати ДБЖ.

— Лоуренс

23

Чесно кажучи, ваш найкращий підхід тут - або виправити вимкнення електроенергії, або розгорнути іншу систему в кращому місці.

Так, є такі системи, як redis, які зберігатимуть дані в журналі додавання лише для відтворення, але ви ризикуєте зіпсуватись на нижчих рівнях - наприклад, якщо ваша файлова система зашифрована, то дані на диску потенційно загрожують.

Я вдячний, що будь-яке вдосконалення було б корисним для вас, але насправді проблема не така, яку можна вирішити, враховуючи окреслений вами сценарій.

8

+1 Правильна відповідь - "Не робіть цього"

— Кріс С

6

+1 Врешті випадкові відключення живлення можуть пошкодити вашу файлову систему. Електроніка робить дивні непередбачувані речі, коли їх потужність виходить з ладу.

— Грант

-1 (віртуальний -1). Я думаю, що така система повинна будуватися на припущенні, що час від часу відключаються електроенергії. Це припущення - справжній світовий факт, з яким вам доводиться мати справу.

— Ігал Сербан

11

Ваш підхід може спрацювати. Дозвольте запропонувати деякі вдосконалення. Виникло питання щодо переповнення стека при атомному написанні у файл . По суті, ви зберігаєте кожен пакет даних у тимчасовому файлі, а потім перейменовуєте його на остаточне ім'я. Перейменування - це атомна операція, яка буде захищена від відключень електроенергії. Таким чином ви гарантуєте, що всі ваші файли в кінцевому пункті призначення збережено правильно, без пошкоджень.

Тоді, що ви можете зробити, щоб вирішити питання про наявність мільйонів файлів. Чи є робота cron, яка працює, можливо, щогодини, яка займає всі файли, старші ніж на годину, і об'єднує їх у один великий файл, використовуючи знову операції з атомними файлами, щоб це завдання надійно працювало навіть під час відключення живлення, а потім видаляло старі файли. Начебто обертання журналу. Файли на годину становитимуть близько 7200 файлів. Тож у будь-який момент часу у вас не повинно бути більше 20 000 файлів на диску.

— Марван Ельзабах
джерело

1

Непогана відповідь, але проблема з цим полягає в припущенні, що сама запис - це атомна операція, що це не так. Тож відключення електроенергії в невідповідний час все ще може створити дані або пошкодити ФС. Мабуть, про найкращий варіант, якщо не встановити живлення або підключити річ до ДБЖ, хоча +1.

— HopelessN00b

@ HopelessN00b перейменування буде атомною операцією, це вимога POSIX

— Marwan Alsabbagh

Так, перейменування одного разу записаного файлу - це атомна операція. Написання файлу в першу чергу, це не так.

— HopelessN00b

3

@ HopelessN00b Не має значення, що новий файл напівзаписаний або пошкоджений. У вас є старий файл, який знаходиться в хорошому стані. Після відновлення системи ви знищуєте напівзаписаний файл.

— DJClayworth

2

@ HopelessN00b Рівно! тільки тимчасові файли у тимчасовому каталозі дозволяють сказати, що коли-небудь можна було записати наполовину. Всі файли у вашому кінцевому каталозі призначення завжди будуть

— непідкупними

7

Ви встановлюєте UPS або карту RAID з керованим кешем запису в систему, і за цілих $ 49,95 ви досягаєте того, чого просто неможливо виконати лише в програмному забезпеченні.

Твоє твердження про те, що якось неможливо підключити цей сервер до ІБП або батареї ... просто не є правдоподібною.

— БезнадійнийN00b
джерело

9

Бюрократична дурість завжди правдоподібна.

— Dan is Fiddling Firelight

3

@DanNeely My PHB won't let me hook this up to a UPS/battery- це зовсім інша річ від it is not possible to add a UPS, a battery, or a similar solution to the system. Не надто педантично, але це важлива відмінність, оскільки це змінює підхід та доступні рішення.

— HopelessN00b

Або, як згадувалося в іншому місці, користувач викраденого комп'ютера здивувався б, якби попросив встановити ДБЖ. Інакше ситуація трохи неймовірна. Будь-хто в межах причини прийняв би UPS над пошкодженими даними, враховуючи належний бізнес-випадок.

— WernerCD

@WernerCD Я хотів би, щоб ти познайомився з нашим CIO. Хоча я погоджуюся, що викрадення чийогось комп’ютера - це можливий приклад для цього, я також можу подумати про законні, тому я дам хлопцеві користь від сумнівів. Подумайте про вбудовані системи та контролери, або як Raspberry Pi - це точно може бути так, що "комп'ютер", який ви використовуєте, коштує менше, ніж 50 доларів, які знадобиться для його приєднання до ДБЖ.

— HopelessN00b

Навіть якщо комп'ютер коштує менше, ніж 50 доларів ДБЖ - це дані на комп'ютері, які насправді чогось варті. Google був побудований на "нікчемних" комп'ютерах. Більш важливою, ніж вартість процесора, є вартість втрачених даних, втрачена сила людини (Ця пригода програмування, переслідування корупції даних, відстеження помилок у старій системі, а також ця нова частина), втрачена цінність клієнтів (Втратили мої дані? Наступна компанія, будь ласка.)

— Та

5

Монтуйте всю систему лише для читання, за винятком блочного пристрою, який зберігає всі ваші дані. Використовуйте цей блоковий пристрій безпосередньо та реалізуйте власний механізм зберігання даних, використовуючи цей необроблений блок пристрою.

— MikeyB
джерело

3

... і вкладайте гроші в карту контролера диска, що підтримується батареєю, і переконайтеся, що на диску немає кешу запису, або ви все ще вкручені.

— voretaq7

Сюди прийшли сказати, що вони повинні завантажувати живий компакт-диск або еквівалентну систему ПЗУ, а деякі твердотільні накопичувачі використовуються з рішеннями плоских файлів.

— Марк Аллен

Кеш запису можна відключити. Цей підхід є життєздатним. Додайте лише механізм зберігання. Блоки написані атомно (я припускаю), тож ви можете мати два блоки "покажчика", які вказують на початок і кінець розділу з новими даними / todo. Покажчики оновлюються після запису / закінчення даних. NCQ також слід відключити.

— безсонні