В рассматриваемом мной развертывании у нас есть производственный sQL-сервер, который должен быть высокодоступным. Он будет установлен на кластере Server 2008R2. Hyper-V уже будет настроен. Меня беспокоит, что запуск SQL на виртуальной машине не обеспечит достаточного количества решений высокой доступности по сравнению с кластеризацией SQL на корневых разделах. Производительность SQL, работающая на виртуальной машине, не является проблемой, меня просто беспокоит, что в случае жесткого аварийного переключения виртуальная машина перезагрузится, что приведет к большему времени простоя, чем период аварийного переключения для обычного SQL-кластера.
Меня интересуют несколько аспектов. Будет ли время простоя ВМ отличаться от простоя SQL-кластера? Какова средняя продолжительность отработки отказа в кластере SQL? Есть ли какое-то скрытое преимущество SQL-кластера, такое как общая очередь, в которую отправляются транзакции, поэтому, если один узел не работает, транзакции будут применяться к базе данных, как только она вернется в сеть? Или это не имеет значения?
Сейчас Hyper-V выглядит неплохо, потому что запланированные отработки отказа могут выполняться без прерывания доступа клиентов.
Отработка отказа SQL Server включает запуск основного сервера, владеющего базой данных, с резервным сервером, готовым к владению базой данных. В момент аварийного переключения сервер резервного копирования становится владельцем хранилища, воспроизводит журналы и затем переводит базу данных в оперативный режим. За этим следует период, когда наиболее горячие части базы данных помещаются в память по мере необходимости. Самым большим ограничением времени переключения при отказе является воспроизведение журналов, поскольку это должно произойти до того, как база данных сможет начать отвечать на запросы.
Если вы кластеризуете виртуальную машину, а не SQL-сервер, вы добавляете время перезагрузки виртуальной машины вместе с любыми проверками файловой системы. Они, как правило, не влияют на общее время восстановления.