Comments 11
мне кажется, что автор путает понятия fault tolerance и disaster recovery. «Растянутый кластер», реплики СХД и т.д. — это fault-tolerance.
FT — это набор технических мероприятий минимизирующий влияние технических неполадок.
DR — это уже комплекс как технических так и организационных мероприятий, который позволяет продолжать работу при событии нарушающем работу мер FT.
то есть, FT — это два ЦОДа, репликация СХД, растянутые кластеры и т.д. И если выйдет из строя сеть питания всего региона и оба ЦОДа прикажут долго жить или изолируются — все ваши кластеры были ни к чему. DR — это как раз меры, чтоб избежать в том числе и этого. Например, третий ЦОД в 2000км от пары основных с 5мин отставанием в данных, ну или без отставания — зависит от глубины кармана.
FT — это набор технических мероприятий минимизирующий влияние технических неполадок.
DR — это уже комплекс как технических так и организационных мероприятий, который позволяет продолжать работу при событии нарушающем работу мер FT.
то есть, FT — это два ЦОДа, репликация СХД, растянутые кластеры и т.д. И если выйдет из строя сеть питания всего региона и оба ЦОДа прикажут долго жить или изолируются — все ваши кластеры были ни к чему. DR — это как раз меры, чтоб избежать в том числе и этого. Например, третий ЦОД в 2000км от пары основных с 5мин отставанием в данных, ну или без отставания — зависит от глубины кармана.
Всё же кластер и репликация призваны защищать разные вещи. Кластер обеспечивает, что сбойная машина будет быстро загружена в другом месте, в то время как реплика защищает информацию внутри машины.
Грубо говоря, слови вы криптор, кластер радостно отзеркалирует все изменения и у вас будет очень стабильная, но очень зашифрованная машина. В то время как с репликой такого риска нет.
Грубо говоря, слови вы криптор, кластер радостно отзеркалирует все изменения и у вас будет очень стабильная, но очень зашифрованная машина. В то время как с репликой такого риска нет.
С репликой эта проблема также актуальна, если только вы не храните несколько реплик.
Реплика защитит ваши данные в случаи физической потери или не доступности ваших серверов.
Для защиты от криптовирусов нужны резервные копии…
Реплика защитит ваши данные в случаи физической потери или не доступности ваших серверов.
Для защиты от криптовирусов нужны резервные копии…
Не вижу каким образом это может быть актуально, кроме как запустить репликацию после атаки. Но для этого надо обладать совсем уж буйной фантазией. А даже если это произошло автоматически, то хранение реплики с одной точкой отката, это… кхм… странное решение…
По сути это тот же бкап, но лежащий не в сторонке, а на какой-то схд и готовый стартануть несколько быстрее, чем машина в бекапе.
По сути это тот же бкап, но лежащий не в сторонке, а на какой-то схд и готовый стартануть несколько быстрее, чем машина в бекапе.
реплика это не бэкап ;-) снепшот это также не бэкап ;-)
Репликация срабатывает по расписанию раз в несколько минут, и каждая дельта занимает место на СХД и является снепшотом на резервной машине. Хранить бесконечное количество реплик не получится.
Момент атаки можно легко пропустить и установить время её начала не всегда быстро и легко.
Так что, от крипторов только резервное копирование на удалённую площадку.
Момент атаки можно легко пропустить и установить время её начала не всегда быстро и легко.
Так что, от крипторов только резервное копирование на удалённую площадку.
Это всё верно, хотя можно долго спорить про размер дельт, про разницу реплик на уровне схд и гипервизора, про количество хранимых реплик и т.д. Но мой изначальный посыл был про то, что сравнивать реплику и кластер совершенно некорректно. Они дополняют друг-друга, защищая от разных типов угроз и никак не взаимозаменимы.
VMware Site Recovery Manager 6 с vSphere Replication каждые 15 минут для серверов приложений, СУБД — Oracle DataGuard.
Потому как данные терять нельзя, а сервера приложений меняются не так часто, и этого достаточно
Sign up to leave a comment.
Реакция на аварию: растянутый кластер против DR-площадки