Как хранить данные на машине, мощность которой отключается случайным образом

13

У меня есть виртуальная машина (Debian), работающая на хосте физической машины. Виртуальная машина выступает в качестве буфера для данных, которые она часто получает по локальной сети (период для этих данных составляет 0,5 с, поэтому довольно высокая пропускная способность). Все полученные данные хранятся на виртуальной машине и многократно пересылаются на внешний сервер по UDP. Как только внешний сервер подтверждает (через UDP), что он получил пакет данных, исходные данные удаляются с виртуальной машины и больше не отправляются на внешний сервер. Интернет-соединение, которое соединяет виртуальную машину и внешний сервер, ненадежно, то есть оно может быть разорвано на несколько дней.

Физическая машина, на которой размещена виртуальная машина, отключается несколько раз в день наугад. Невозможно определить, когда это произойдет, и невозможно добавить ИБП, батарею или подобное решение в систему.

Первоначально данные хранились в файловой базе данных HSQLDB на виртуальной машине. Однако частые отключения питания в конечном итоге приводят к повреждению файла сценария базы данных (не на уровне файловой системы, то есть он доступен для чтения, но HSQLDB не может это понять), что приводит к моему вопросу:

Как следует хранить данные в среде, где отключение питания может происходить и происходит часто?

Один из вариантов, который я могу придумать, - использовать плоские файлы, сохраняя каждый пакет данных в виде файла в файловой системе. Таким образом, если файл поврежден из-за потери питания, его можно игнорировать, а остальные данные остаются нетронутыми. Однако это создает несколько проблем, в основном связанных с объемом данных, которые могут храниться на виртуальной машине. Через 0,5 с между каждым фрагментом данных за 10 дней будет сгенерировано 1 728 000 файлов. По крайней мере, это означает использование файловой системы с увеличенным числом инодов для хранения этих данных (в текущей настройке файловой системы исчерпаны иноды с ~ 250 000 сообщений и 30% используемого дискового пространства). Кроме того, это трудно (не невозможно) управлять.

Есть ли другие варианты? Существуют ли движки баз данных, работающие на Debian, которые не будут повреждены отключениями питания? Кроме того, какую файловую систему следует использовать для этого? ext3 - это то, что используется в данный момент.

Программное обеспечение, работающее на виртуальной машине, написано с использованием Java 6, поэтому, надеюсь, решение не будет несовместимым.

Sevas
источник
14
«Физическая машина, на которой размещена виртуальная машина, отключается несколько раз в день в случайном порядке. Невозможно определить, когда это произойдет, и невозможно добавить ИБП, батарею или подобное решение для система «. Я действительно хочу знать, как это возможно. Это на Международной космической станции, поэтому для отправки ИБП нужно 20 миллионов долларов или что-то в этом роде?
ceejayoz
3
Есть ли у компьютера хотя бы RAID-контроллер с кэш-памятью на батарейках?
Зоредаче
4
Мы могли бы порекомендовать очень интересные, креативные и, возможно, теоретически правильные решения этой проблемы. Однако мы не знаем, какой гипервизор и оборудование работают на хосте, поэтому не было бы никакой гарантии, что запись на диск действительно записана или записана в правильном порядке ...
pino42
5
@Sevas Звучит так, будто это не ваш звонок, но я бы посоветовал отметить, что 50 основных дешевых ИБП обойдутся в 2500 долларов и не требуют обслуживания (вы заменяете их через пару лет, когда батареи начинают разряжаться) ). Стоимость попыток решить эту проблему в программном обеспечении будет намного выше, если вы не знаете группу программистов, которые работают бесплатно. Может быть полезно, чтобы руководство решило эту проблему за 50 долларов США за единицу вместо десятков или сотен квалифицированных человеко-часов при 3 цифрах в час.
HopelessN00b
9
Это на самом деле звучит как вредоносная программа. Пользователь не знает, что «ВМ» работает на его компьютере. Он крадет данные по всей сети, а затем направляет их через одно соединение, чтобы спрятаться. Пользователь «случайным образом выключает и включает компьютер», поэтому вы не можете просто добавить ИБП.
Лоуренс

Ответы:

23

Честно говоря, ваш лучший подход здесь - это либо исправить отключение электроэнергии, либо развернуть другую систему в лучшем месте.

Да, есть такие системы, как redis, которые будут хранить данные в журнале только для добавления для воспроизведения, но вы рискуете повредить их на более низких уровнях - например, если ваша файловая система зашифрована, то данные на диске потенциально находятся под угрозой.

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


источник
8
+1 Правильный ответ: «Не делай этого»
Крис С
6
+1 В конечном итоге случайные отключения питания повредят вашу файловую систему. Электроника делает странные непредсказуемые вещи, так как их мощность не работает.
Грант
-1 (виртуальный -1). Я думаю, что такая система должна основываться на предположении, что время от времени происходит отключение электроэнергии. Это предположение является фактом реального мира, с которым вам приходится иметь дело.
Игаль Сербан
11

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

Тогда что вы можете сделать, чтобы справиться с проблемой наличия миллионов файлов. Является ли cron заданием, которое запускается, может быть, каждый час, и занимает все файлы старше часа и объединяет их в один большой файл, снова используя атомарные операции с файлами, так что это задание выполняется безопасно даже при сбоях питания, а затем удаляет старые файлы. Вроде как ротация бревен. Часовая стоимость файлов составит около 7200 файлов. Поэтому в любой момент времени на диске не должно быть более 20 000 файлов.

Марван Алсаббах
источник
1
Неплохой ответ, но проблема в том, что сама запись является атомарной операцией, а это не так. Таким образом, сбой питания в неподходящее время может привести к повреждению данных или FS. Вероятно, о лучшем варианте, кроме отключения питания или подключения устройства к ИБП, так что +1.
HopelessN00b
Да, переименование файла после записи является атомарной операцией. Запись файла в первую очередь, нет.
HopelessN00b
3
@ HopelessN00b Неважно, что новый файл наполовину записан или поврежден. У вас есть старый файл, который находится в хорошем состоянии. Когда вы восстанавливаете систему, вы уничтожаете наполовину записанный файл.
DJClayworth
2
@ HopelessN00b Точно! скажем, только временные файлы во временном каталоге могут быть наполовину записаны. Все файлы в вашем конечном каталоге назначения всегда будут не повреждены и
сохранятся
7

Вы устанавливаете в систему ИБП или карту RAID с кэш-памятью с резервным питанием от батареи, и всего за 49,95 долл. США вы достигаете того, что просто невозможно сделать только программным обеспечением.

Ваше утверждение, что каким-то образом невозможно подключить этот сервер к ИБП или батарее ... просто неправдоподобно.

HopelessN00b
источник
9
Бюрократическая глупость всегда правдоподобна.
Дэн возится с 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
Или, как упоминалось в другом месте, пользователь угнанного компьютера был бы удивлен, если бы я попросил установить ИБП. Ситуация немного невероятна в противном случае. Любой, в пределах разумного, примет ИБП из-за поврежденных данных при условии надлежащего экономического обоснования.
WernerCD
@WernerCD Я бы хотел, чтобы вы встретились с нашим ИТ-директором. Хотя я согласен с тем, что угон чьего-то компьютера - это возможный вариант использования, я могу подумать и о законных, так что я дам парню преимущество сомнения. Подумайте о встроенных системах и контроллерах или как о Raspberry Pi - вполне возможно, что используемый вами «компьютер» стоит меньше, чем 50 долларов, которые потребуются для подключения его к ИБП.
HopelessN00b
Даже если компьютер стоит меньше, чем ИБП за 50 долларов - это данные на компьютере, которые действительно чего-то стоят. Google был построен на «бесполезных» компьютерах. Более важным, чем стоимость процессора, является стоимость потерянных данных, потери человеческих ресурсов (это приключение в программировании, отслеживание повреждения данных, отслеживание ошибок в старой системе, а также в этой новой части), потеря потерянных клиентов (потеряли мои данные? Следующая компания, пожалуйста.) И т. Д.
WernerCD
5

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

MikeyB
источник
3
... и инвестируйте в плату контроллера дисков с батарейным питанием, и убедитесь, что на диске нет кэша записи, или вы все еще в замешательстве.
voretaq7
Они пришли сюда, чтобы сказать, что они должны загружаться с Live-CD или эквивалентной системы ПЗУ, с твердотельным хранилищем, используемым с решениями для плоских файлов.
Марк Аллен
Кэш записи может быть отключен. Этот подход жизнеспособен. Рекомендуется только добавить механизм хранения. Блоки написаны атомарно (я полагаю), поэтому вы можете иметь два блока «указателя», которые указывают на начало и конец раздела с данными new / todo. Указатели обновляются после записи / завершения данных. NCQ тоже должен быть отключен.
sleeplessnerd