Вопрос: Как хранить данные на машине, мощность которой вырезается наугад


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

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

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

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

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

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

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


14
2017-11-07 16:51


Источник


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


Ответы:


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

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

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


23
2017-11-07 17:09



+1 Правильный ответ: «Не делай этого», - Chris S
+1 В конечном итоге случайные отключения питания могут повредить вашу файловую систему. Электроника делает странные непредсказуемые вещи, поскольку их власть терпит неудачу. - Grant
-1 (виртуальный -1). Я думаю, что такая система должен основываться на предположении, что время от времени происходят отключения электроэнергии. Это предположение является реальным фактом, с которым вам приходится иметь дело. - Igal Serban


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

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


11
2017-11-07 17:40



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


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

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


6
2017-11-07 17:36



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


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


4
2017-11-07 17:37



... и инвестировать в карту контроллера диска с батарейным питанием, и убедитесь, что на диске нет кеша записи, или вы все еще ввернуты. - voretaq7
Пришли сюда, чтобы сказать, что они должны быть загружены с Live-CD или аналогичной системы ROM, с некоторым твердотельным хранилищем, используемым с плоскими файловыми решениями. - Mark Allen
Кэш записи можно отключить. Такой подход является жизнеспособным. Добавлять только механизм хранения рекомендуется. Блоки записываются атомарно (я предполагаю), поэтому вы можете иметь два блока «указатель», которые указывают на начало и конец раздела с новыми данными / todo. Указатели обновляются после записи / обработки данных. NCQ также должен быть отключен. - sleeplessnerd