Comments 17
Какие риски вы снижаете таким решением? Это не отказоустойчивый кластер, а просто failover конфигурация, вроде.
Из SPOF виднеются, как минимум СХД и, вероятно, AD. Кроме того не очевидно дублируются ли пути до AD, пути до СХД.
С MSSQL дел не имел, потому задам пару глупых вопросов:
— эта конфигурация active/passive или active/active?
— какое поведение при падение активной ноды?
— бывает ли split brain сценарий?
Из 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
Из 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»" — опциональность обусловлена всего лишь возможностью работы без него, но понятно, что это не добавляет плюс к надежности. Думаю стоит добавить в туторириал это уточнение.
«Id est о HA речи даже близко нет.» — да. Решение строилось исходя из требований и возможностей
По "«Quorum»" — опциональность обусловлена всего лишь возможностью работы без него, но понятно, что это не добавляет плюс к надежности. Думаю стоит добавить в туторириал это уточнение.
А кто говорил про HA? Автор вроде бы пишет об отказоустойчивом (failover) кластере. Для HA идет следующий шаг — AlwaysOn Availability Groups.
Добавьте подводные камни — в частности то, что запускать установку следует из-под пользователя, имеющего права на заведение новых машин в домен, поскольку при создании кластера сетевое имя приложения MSSQL будет регистрироваться в домене, и если прав не хватит, то вы можете получить проблему (я на 2008R2 ее себе получил, пришлось сносить и устанавливать все заново).
Не читал всю статью, только по диагонали.
Еще на 2003 винде поднимал MSSQL active/passive с общим хранилищем, ничего сложного, все по докам.
Давно с видой не работаю и встала задача поднять MSSQL кластер не с общим хранилищем. Для мааааленькой БД подключения терминальных клиентов, потому что в 2012 для этого теперь просто необходим MSSQL. Вот здесь я получил затык. Не могу найти для чайников документации. А хочется. Хочется MSSQL для такой маленькой но очень важной задачи разнести на две отдельные виртуалки на двух разных серверах виртуализации. Естественно ни о каком общем СХД речи и не идет.
Если есть опыт, поделитесь!!!
Еще на 2003 винде поднимал MSSQL active/passive с общим хранилищем, ничего сложного, все по докам.
Давно с видой не работаю и встала задача поднять MSSQL кластер не с общим хранилищем. Для мааааленькой БД подключения терминальных клиентов, потому что в 2012 для этого теперь просто необходим MSSQL. Вот здесь я получил затык. Не могу найти для чайников документации. А хочется. Хочется MSSQL для такой маленькой но очень важной задачи разнести на две отдельные виртуалки на двух разных серверах виртуализации. Естественно ни о каком общем СХД речи и не идет.
Если есть опыт, поделитесь!!!
Копайте в сторону AlwaysOn Availability — появились в SQL Server 2012.
Это если нужна одна активная на запись нода (остальные — только для чтения). Если нужны записи во все базы — то в сторону репликации.
Это если нужна одна активная на запись нода (остальные — только для чтения). Если нужны записи во все базы — то в сторону репликации.
Да несомненно особо сложного нет, больше промучался с хранилищем, но сложности были поэтому и появился сей туториал.
По Вашему вопросу, согласен с комментарием ниже про AlwaysOn Availability. На счет СХД — можно сделать софтверно на базе ВМ с доступными ресурсами.
По Вашему вопросу, согласен с комментарием ниже про AlwaysOn Availability. На счет СХД — можно сделать софтверно на базе ВМ с доступными ресурсами.
Приведенная конфигурация содержит слишком много точек отказа. Ключевой момент — резервирование СХД.
Прочие штуки вроде нескольких сетевух через разные свитчи и инфраструктуры вроде AD и DNS само собой также нуждаются в резервировании, но это тривиально и не дорого.
СХД, которые могут работать в режиме риалтаймовой репликации стоят космических денег, плюс требуют инфраструктуры для резервирования путей (2x FC или Ethernet свитча), и что самое грустное — работают медленнее локального хранилища (если сравнивать по цене, Violin Memory в расчет не берем).
Мы выбрали AlwaysOn для отказоустойчивости. Он не требует СХД, так как использует локальное хранилище. Есть синхронный режим работы, в котором транзакция коммитится только после записи данных на резервный сервер.
Для кворума достаточно сетевой шары (к сожалению, зарезервировать сетевую шару никак нельзя, поэтому стоит делать ее на максимально доступном сервере). В случае 3 и более серверов, кворум собирается из них.
Синхронный режим дает примерно 5-10% просадки производительности на медном гигабите. Если использовать 10Г оптику — задержка должна уйти совсем.
Для работы требуется режим восстановления FULL.
Прочие штуки вроде нескольких сетевух через разные свитчи и инфраструктуры вроде AD и DNS само собой также нуждаются в резервировании, но это тривиально и не дорого.
СХД, которые могут работать в режиме риалтаймовой репликации стоят космических денег, плюс требуют инфраструктуры для резервирования путей (2x FC или Ethernet свитча), и что самое грустное — работают медленнее локального хранилища (если сравнивать по цене, Violin Memory в расчет не берем).
Мы выбрали AlwaysOn для отказоустойчивости. Он не требует СХД, так как использует локальное хранилище. Есть синхронный режим работы, в котором транзакция коммитится только после записи данных на резервный сервер.
Для кворума достаточно сетевой шары (к сожалению, зарезервировать сетевую шару никак нельзя, поэтому стоит делать ее на максимально доступном сервере). В случае 3 и более серверов, кворум собирается из них.
Синхронный режим дает примерно 5-10% просадки производительности на медном гигабите. Если использовать 10Г оптику — задержка должна уйти совсем.
Для работы требуется режим восстановления FULL.
( дубль )
Скорректировал немного топик, добавил пару поясняющих моментов.
Sign up to leave a comment.
Как развернуть отказоустойчивый кластер MS SQL Server 2012 на Windows Server 2012R2 для новичков