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