В настоящее время мы работаем над реализацией стратегии аварийного восстановления для файлового сервера Windows. Мы исключили репликацию хранилища, потому что это предварительная версия, а отказоустойчивая кластеризация предназначена для обеспечения высокой доступности, а не для аварийного восстановления. DFSR также имеет недостатки в репликации открытых / заблокированных файлов, что делает его неидеальным для данной задачи.
Репликация из SAN в SAN виртуальной машины файлового сервера кажется мне лучшим методом, хотя меня предостерегали от этого, поскольку репликация представляет собой необработанную копию, которая не объединяется на более высоком уровне, что может вызвать несоответствия в файловая система или поврежденные файлы. Однако этот факт верен для любого сервера, реплицированного с помощью этого метода, и этот метод используется для других серверов в нашем плане аварийного восстановления. VSS / предыдущие версии всегда можно использовать для восстановления любых поврежденных файлов.
Перевешивают ли преимущества репликации SAN риск повреждения файлов? Или есть лучший метод аварийного восстановления файлового сервера? Возможно, существует продукт, который выполняет репликацию / моментальный снимок более высокого уровня, что минимизирует логические несоответствия в данных?
Примечание: кластер работает под управлением vSphere 5.5
Репликация из SAN в SAN - лучший способ вернуть файловый сервер в оперативный режим как можно быстрее с минимальными потерями после объявления аварии. Обратите внимание, что этот тип защиты от аварийного восстановления не защищает от тех же вещей, что и локальное резервное копирование - вы не можете использовать реплицированный том SAN, например, для восстановления файла из прошлого месяца.
Поврежденные файлы не представляют опасности для репликации из SAN в SAN, если только файловый сервер на основном сайте не повреждает их. Каждая сеть SAN, обеспечивающая репликацию блочного хранилища (LUN), имеет некоторый механизм для предотвращения повреждения и обеспечения согласованности. Это более сложная проблема, чем думает большинство людей, потому что записи часто производятся на диск не по порядку, даже без репликации, по причинам оптимизации. Вот почему кэш записи для большинства хранилищ имеет своего рода сеть защиты от сбоев питания (например, аккумулятор или ИБП): если записи не сохраняются только в кеше, основной диск, вероятно, поврежден. Обычно это нормально, однако, если вы теряете питание, вам необходимо убедиться, что последняя запись, подтвержденная хранилищем, сохраняется на диск, чтобы сделать диск согласованным, когда он появится.
Репликация обрабатывает это по-разному, в зависимости от того, как вы реплицируете:
Все эти механизмы обеспечивают «стабильность при сбоях». Диск находится в том же состоянии, в котором было бы, если бы вы резко отключили питание на сервере. Чтобы заставить файловые системы и базы данных работать из отказоустойчивой копии, требуется немного поработать, но это всегда выполнимо. Если вы хотите чего-то большего (того «более высокого уровня», о котором вы упоминаете в вопросе), вам необходимо интегрировать репликацию с вашими приложениями. Обычно это означает приостановку записи в приложении, ожидание, пока все не будет удалено в хранилище, а затем запуск точки согласованности для репликации. Это называется «согласованность приложения». Обычно он предоставляет немного более старую точку восстановления, но немного меньшее время восстановления, чем согласованность при сбое.
Репликация из SAN в SAN - это самый быстрый способ восстановления после сбоя сайта, но я столкнулся с повреждением SAN в своей ИТ-жизни из-за ошибки прошивки, и это может стать некрасивым
Вы забываете написать, какой гипервизор используете. Но я предлагаю с репликацией SAN продукт vReplicator, если вы используете ESX. По умолчанию они реплицируются каждые 15 минут, и ваша удаленная виртуальная машина находится в состоянии готовности к работе. vReplicator требуется лицензия vCenter и физический хост для хранения реплицированной виртуальной машины (может стоить меньше, чем другой SAN, но, как сказал @IceMage, это зависит от того, сколько времени вы можете потерять)
Вы должны быть готовы к нескольким уровням и видам бедствий, включая полное злонамеренное нарушение (хакеры) и полную потерю всего оборудования (эпическая погода). Это потребует, чтобы вы перегрузили некоторые данные в методы распространения кроссовок (прочтите, внешнее хранилище, такое как ленты / жесткие диски), какую-либо форму решения с однократной записью или онлайн-службу резервного копирования (дорого).
Аварийное восстановление - это совсем другое дело, чем простая репликация. Вам необходимо определить это, прежде чем что-либо решать: "Сколько данных я могу потерять?"Не думайте о гигабайтах, думайте о ВРЕМЯ. Могу ли я потерять 4 часа данных, могу ли я потерять дневные? Выбор метода будет зависеть от вашего ответа на этот вопрос. Мы все хотим решение с нулевыми потерями, но, как правило, это неосуществимая инвестиция из-за снижения риска. Вам также нужно будет хранить копии ваших ежемесячных / годовых резервных копий в течение длительного времени, так как у вас также могут произойти бедствия (пользователи удаляют ненужную им хрень), о которых вы очень долго не подозреваете.
Veeam и другие продукты для резервного копирования, использующие моментальные снимки, идут вразрез с рекомендациями VMware, которые не делают их так часто. Это поставит серверы на колени и почти не будет отвечать. Представьте себе 50 серверов, которые делают снимки за 15 минут, 1200 снимков в день? Трудно управлять, много места для хранения. Такая технология CDP, как Zerto, решает эту проблему для VMware и Hyper-V.
Я бы посоветовал использовать Veeam для репликации виртуальных машин ваших файловых серверов с низким RPO. Он поддерживает VSS и может использоваться для локальной репликации, а также в WAN и облачные цели с несколькими точками хранения.
Настройте прокатные 15-минутные снимки, ежечасные или ежедневные отчеты за пределами сайта. Это довольно надежно по цене.
Если у вас есть удаленный гипервизор, вы можете настроить частичную книгу выполнения, которая запускает реплицированную виртуальную машину с соответствующими настройками сети и IP.