История изменений
Исправление sanyo1234, (текущая версия) :
У тебя скорее диск сдохнет или память сбойнёт.
Если ты сравниваешь с вероятностью обнаружения ошибок в OpenZFS или даже просто её нестабильностью вплоть до зависания пула до ребута всего хоста, то ты неправ. У меня дома никогда не помирали диски в пулах, проверенная оперативка тоже очень живучая даже без ECC. А вот подвисшие OpenZFS пулы я встречал, и даже приходилось перезагружать хост из-за таких подвисаний. А ещё иногда дурит resilvering после возврата offline устройств обратно в состояние online. Реализация OpenZFS очень сырая для использования в production. Именно поэтому и нужен DRBD кластер, чтобы если один пул начнёт капризничать, то можно было бы продолжать работу на другом пуле без downtime в то время, как приводишь мозги глючащего пула в нормальное состояние.
Одна из реализаций в один «прекрасный» момент может просто отказаться принимать поток, приняв его за несовместимые данные.
Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive
при этом НЕ используется. Ещё раз, ZFS при использовании с DRBD нужен только вместо аппаратного рейда ибо в среднем сильно круче и надёжнее, несмотря на все свои глюки.
Если задача стоит переехать без даунтайма, ты перестрахуешься насколько это возможно.
Я вообще не понимаю, что там нужно firkax и зачем, уже просил уточнить.
Исходная версия sanyo1234, :
У тебя скорее диск сдохнет или память сбойнёт.
Если ты сравниваешь с вероятностью обнаружения ошибок в OpenZFS или даже просто её нестабильностью вплоть до зависания пула до ребута всего хоста, то ты неправ. У меня дома никогда не помирали диски в пулах, проверенная оперативка тоже очень живучая даже без ECC. А вот подвисшие OpenZFS пулы я встречал, и даже приходилось перезагружать хост из-за таких подвисаний. А ещё иногда дурит resilvering после возврата offline устройств обратно в состояние online. Реализация OpenZFS очень сырая для использования в production. Именно поэтому и нужен DRBD кластер, чтобы если один пул начнёт капризничать, то можно было бы продолжать работу на другом пуле без downtime в то время, как приводишь мозги глючащего пула в нормальное состояние.
Одна из реализаций в один «прекрасный» момент может просто отказаться принимать поток, приняв его за несовместимые данные.
Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive
при этом НЕ используется. Ещё раз, ZFS нужен только вместо аппаратного рейда ибо в среднем сильно круче и надёжнее, несмотря на все свои глюки.
Если задача стоит переехать без даунтайма, ты перестрахуешься насколько это возможно.
Я вообще не понимаю, что там нужно firkax и зачем, уже просил уточнить.