Comments 17
Какие риски вы снижаете таким решением? Это не отказоустойчивый кластер, а просто failover конфигурация, вроде.

Из SPOF виднеются, как минимум СХД и, вероятно, AD. Кроме того не очевидно дублируются ли пути до AD, пути до СХД.

С MSSQL дел не имел, потому задам пару глупых вопросов:
— эта конфигурация active/passive или active/active?
— какое поведение при падение активной ноды?
— бывает ли split brain сценарий?
Какие риски вы снижаете таким решением? — как минимум увеличивается доступность базы в случае выхода из строя одного из узлов. Пользователи работают, мы восстанавливаем работоспособность. В планах еще разобраться с AlwaysOn
Из SPOF виднеются, как минимум СХД и, вероятно, AD. Кроме того не очевидно дублируются ли пути до AD, пути до СХД.
В описании тестового стенда указано, что есть Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD). На счет путей не понял, что Вы имели ввиду.
— эта конфигурация active/passive или active/active? — active/passive
— какое поведение при падение активной ноды? — происходит разрыв и переключение на вторую ноду (в нашем случае это занимает 10-25сек), пользователю 1С нужно было перезайти в базу.
— бывает ли split brain сценарий? — если правильно понял, то возможно что б роли кластера жили на разных нодах, т.е. на Н1 — MSDTC, а на Н2 — MSSQL
На счет путей не понял, что Вы имели ввиду.
Имелось ввиду дублирование по сетевым картам, коммутаторам, физическим кроссам и т. п. Exempli gratia 2 сетевые карты по 2 порта, с каждой по пути к каждому из двух свитчей, эти пути проходят через разные коммутационные шкафы. Избыточность, конечно, определяется рисками, которые хочется минимизировать и доступной инфраструктурой.

происходит разрыв и переключение на вторую ноду (в нашем случае это занимает 10-25сек), пользователю 1С нужно было перезайти в базу.
Id est о HA речи даже близко нет.

если правильно понял, то возможно что б роли кластера жили на разных нодах, т.е. на Н1 — MSDTC, а на Н2 — MSSQL
Нет. Имелась ввиду возможность недостижения кворума (я не очень понял, почему у вас хранилище «Quorum» является опциональным), когда каждая из нод не может достучаться до другой, тогда обе ноды считают себя слейвами; или обратная ситуация, когда обе ноды считают себе мастерами.
С «путями» — несомненно нужно минимизировать эти риски. Но — это за рамками статьи(добавлю об этом пару строк)
«Id est о HA речи даже близко нет.» — да. Решение строилось исходя из требований и возможностей
По "«Quorum»" — опциональность обусловлена всего лишь возможностью работы без него, но понятно, что это не добавляет плюс к надежности. Думаю стоит добавить в туторириал это уточнение.
А кто говорил про HA? Автор вроде бы пишет об отказоустойчивом (failover) кластере. Для HA идет следующий шаг — AlwaysOn Availability Groups.
Добавьте подводные камни — в частности то, что запускать установку следует из-под пользователя, имеющего права на заведение новых машин в домен, поскольку при создании кластера сетевое имя приложения MSSQL будет регистрироваться в домене, и если прав не хватит, то вы можете получить проблему (я на 2008R2 ее себе получил, пришлось сносить и устанавливать все заново).
Не читал всю статью, только по диагонали.
Еще на 2003 винде поднимал MSSQL active/passive с общим хранилищем, ничего сложного, все по докам.
Давно с видой не работаю и встала задача поднять MSSQL кластер не с общим хранилищем. Для мааааленькой БД подключения терминальных клиентов, потому что в 2012 для этого теперь просто необходим MSSQL. Вот здесь я получил затык. Не могу найти для чайников документации. А хочется. Хочется MSSQL для такой маленькой но очень важной задачи разнести на две отдельные виртуалки на двух разных серверах виртуализации. Естественно ни о каком общем СХД речи и не идет.

Если есть опыт, поделитесь!!!
Копайте в сторону AlwaysOn Availability — появились в SQL Server 2012.

Это если нужна одна активная на запись нода (остальные — только для чтения). Если нужны записи во все базы — то в сторону репликации.
Да несомненно особо сложного нет, больше промучался с хранилищем, но сложности были поэтому и появился сей туториал.
По Вашему вопросу, согласен с комментарием ниже про AlwaysOn Availability. На счет СХД — можно сделать софтверно на базе ВМ с доступными ресурсами.
Приведенная конфигурация содержит слишком много точек отказа. Ключевой момент — резервирование СХД.
Прочие штуки вроде нескольких сетевух через разные свитчи и инфраструктуры вроде AD и DNS само собой также нуждаются в резервировании, но это тривиально и не дорого.
СХД, которые могут работать в режиме риалтаймовой репликации стоят космических денег, плюс требуют инфраструктуры для резервирования путей (2x FC или Ethernet свитча), и что самое грустное — работают медленнее локального хранилища (если сравнивать по цене, Violin Memory в расчет не берем).

Мы выбрали AlwaysOn для отказоустойчивости. Он не требует СХД, так как использует локальное хранилище. Есть синхронный режим работы, в котором транзакция коммитится только после записи данных на резервный сервер.

Для кворума достаточно сетевой шары (к сожалению, зарезервировать сетевую шару никак нельзя, поэтому стоит делать ее на максимально доступном сервере). В случае 3 и более серверов, кворум собирается из них.

Синхронный режим дает примерно 5-10% просадки производительности на медном гигабите. Если использовать 10Г оптику — задержка должна уйти совсем.

Для работы требуется режим восстановления FULL.
Для кворума достаточно сетевой шары (к сожалению, зарезервировать сетевую шару никак нельзя, поэтому стоит делать ее на максимально доступном сервере)

Почему же нельзя, сетевая шара «кладется» на кластерный файловый сервис. Это даже в каком-то Best Practice по кластерам Microsoft было написано.
Only those users with full accounts are able to leave comments. Log in, please.