У меня есть хост ESXi со следующими виртуальными машинами:
1 x сервер Active Directory
1 x сервер служб удаленных рабочих столов
1 x сервер базы данных SQL
1 x сервер приложений бухгалтерского программного обеспечения
У меня есть второй "пустой / пустой" хост ESXi.
Теоретически я просто хотел запланировать клонирование виртуальных машин на второй хост в качестве резервной копии. Если что-то случится с первым сервером, я могу просто загрузить виртуальные машины на второй машине и продолжить работу, как если бы первая никогда не выходила из строя.
На практике это кажется гораздо менее практичным, если проделать довольно много поисков здесь, в SF.
Меня больше всего беспокоит целостность и непротиворечивость базы данных SQL ... Эта стратегия резервного копирования не рекомендуется для серверов SQL из-за того, что незаписанные данные находятся в памяти. Полагаю, я мог бы выключить сервер, клонировать его, а затем перезагрузить, но в моем идеальном мире я хотел бы дублировать эти виртуальные машины хотя бы каждую ночь, пока они еще живы.
Какой была бы наилучшая стратегия резервного копирования для репликации этих конкретных типов серверов на второй хост ESXi каждую ночь, пока они еще работают? Рассмотрите отдельные варианты для бюджета в 1000 долларов и бюджета в 10 000 долларов.
Есть ли в целом лучшая стратегия резервного копирования?
Изучите VMware vSphere 5.0 с VSA (Virtual Storage Appliance). Это позволит вам запустить кластер на двух машинах и автоматически реплицировать виртуальные машины между двумя машинами в реальном времени.
Данные в SQL Server не считаются принятыми, пока они не записаны в журнал транзакций. Как только это будет записано на диск, клиентское приложение получит уведомление о том, что запись завершена. Даже если измененные страницы все еще хранятся в памяти и не записываются на диск, запись в журнал будет завершена. Когда база данных переходит в оперативный режим на новом хосте, транзакции, отмеченные как завершенные в журнале, будут считаны из журнала и применены до того, как пользователи смогут войти в систему.
В этой настройке вы фактически должны запускать два контроллера домена с одним из каждого сервера (правила могут помочь вам в этом), чтобы, когда хост выходит из строя, один контроллер домена все еще находится в сети, поэтому все остальное продолжает работать, пока не появятся другие гостевые ОС. снова в сети.
Хотя это даже не укладывается в бюджет в 10 000 долларов, лучшим вариантом является наличие двух SAN и репликация данных в реальном времени между двумя SAN, а затем использование VMWare SRM для загрузки виртуальных машин на другой стороне в случае сбоя. отказ.
При бюджете в 10 000 долларов вы должны иметь возможность получить один массив SAN, а затем использовать функцию высокой доступности VMWare, что означает, что в случае сбоя хоста все его виртуальные машины немедленно загружаются на другие хосты. Это делает SAN единственной точкой отказа, и вам нужно убедиться, что она достаточно быстра, чтобы не стать узким местом, влияющим на вашу повседневную работу.
За бюджет в 1000 долларов я бы предложил «дешевый» NAS (например, серию QNap 4xx) и предоставил бы общее хранилище через iSCSI. Они предоставляют только интерфейсы 1GbE, которые могут нормально работать с такими вещами, как контроллер домена, но не более того (я пробовал это, у нас здесь qnap 6 ТБ, и это просто не для работы с большой нагрузкой iSCSI).
Лично я бы посоветовал, если вы можете себе позволить простой, установить второй SQL-сервер на хосте B и доставить ему журнал транзакций. Возможно, вам даже не придется покупать дополнительное оборудование для этого и уточнять у представителя Microsoft, но вам может даже не потребоваться лицензировать его. Поэтому оставьте их оба активными, а затем перенаправьте свои приложения на 2-й сервер SQL, когда хост перейдет в автономный режим.
Кроме того, я настоятельно не рекомендую клонировать контроллер домена, поскольку возникают проблемы с возвратом назад после восстановления (или моментального снимка). Я бы снова предложил иметь два DC, по одному на каждом хосте, и позволить их собственной репликации (DFS) заниматься этим.
Для ваших учетных и RDS-серверов ваше решение клонирования должно работать нормально. Я не знаю, что вы используете на своем RDS, но мы решили, что можем позволить себе потерять до 24 часов данных без серьезных последствий, поэтому, если вы просто клонируете его в ночное время, вы можете быть в порядке.