В настоящее время я ищу возможность разместить базу данных SQL Server на экземпляре виртуальной машины Azure и подключить веб-сайт через две веб-роли с балансировкой нагрузки. Из-за различных ограничений в архитектуре нашего приложения мы пока не можем перейти на полноценную базу данных Azure, так что это наша золотая середина. У меня просто пара вопросов по избыточности, особенно с виртуальной машиной и SQL Server.
Нужно ли мне поддерживать два экземпляра виртуальных машин, чтобы обеспечить надежную отработку отказа?
Если основная виртуальная машина отключится, сколько времени займет процесс аварийного переключения? Очевидно, в какой-то степени я предполагаю, что это зависит от того, почему он отключился, но возможно ли переключение на другой ресурс за секунды? или мне нужно будет подождать, пока диск на основном сервере будет преобразован в другой узел?
Любая помощь приветствуется!
С виртуальными машинами Windows Azure вы не можете настроить «традиционный» кластер базы данных с общим хранилищем, потому что у вас нет SAN. Это оставляет вам необходимость довольствоваться другими опциями SQL HA - зеркальным отображением базы данных, доставкой журналов и, возможно, (начиная с SQL 2012) использованием групп доступности AlwaysOn. Вы даже можете использовать репликацию - что более или менее скрыто делает SQL Azure. То, как ваше приложение отреагирует, зависит от решения. Зеркальное отображение позволяет обеим базам данных находиться в строке подключения, а ADO.NET обрабатывает связь с другим сервером за вас. С доставкой журналов ваше приложение должно будет обнаружить сбой и самостоятельно перейти на другой узел.
Изучите «Как добиться высокой доступности SQL Server без использования кластера общего хранилища», и вы получите ответы. Вы можете начать здесь, в MSDN.
Разве невозможно сделать одно из следующего: 1) Сделать хранилище BLOB-объектов Azure доступным напрямую для отказоустойчивого кластера SQL? По сути, это общее хранилище. Разве SQL Server не поддерживает запись в такое общее хранилище BLOB-объектов? 2) Создание виртуального жесткого диска на диске на базе хранилища Azure на отдельной виртуальной машине и предоставление его в качестве цели iSCSI экземплярам аварийного переключения. Хотя этот режим не дает вам HA, учитывая, что цель iSCSI установлена на одном узле, который сам становится единственной точкой отказа.