Я собираюсь обновить и консолидировать группу SQL Server 2008R2 в один SQL Server 2012. Я хочу иметь высокую доступность и искать различные варианты. Количество баз данных довольно велико (150+), поэтому о DBMirroring не может быть и речи.
Теперь я смотрю на «Группу доступности AlwaysOn» и «Отказоустойчивый кластер AlwaysOn» и не могу понять, в каком направлении двигаться… может быть, доступно еще больше вариантов.
кластеризация может быть хорошим способом сделать что-то, но это действительно раздражает, когда большой мощный сервер ничего не делает, кроме как ждет отказа основного сервера.
Есть ли способ сделать реальную активную / активную кластеризацию в SQL Server (реальная балансировка нагрузки)?
Microsoft SQL Server не поддерживает «настоящую» схему балансировки нагрузки из коробки. AFAIK, это все еще верно для SQL Server 2012. (Кто-то просветит меня, если я ошибаюсь.) Не имеет значения, говорим ли мы о зеркальном отображении базы данных, AlwaysOn или кластерах.
(В последнее время MS, кажется, называет кластеры SQL Server «отказоустойчивыми кластерами SQL Server», для того, чтобы забить эту точку. Педантика.)
Если вы хотите сбалансировать нагрузку в своих базах данных, вам придется самостоятельно проделать тяжелую работу с каким-то сегментированием, федерацией или репликацией. (Обратите внимание, что федерация (по представлениям) присутствует в продукте с SQL Server 2000, она просто не пользовалась большой популярностью.) И, конечно же, это означало бы изменение либо ваших баз данных, либо самих приложений, что почти всегда тоже много работы или нарушает ваши соглашения с поставщиком. Со 150 базами данных это гораздо более непреодолимо.
У вас может быть активный-активный кластер, но дело в том, что вам придется аккуратно распределить свои базы данных по узлам, чтобы распределить нагрузку. Со 150 базами данных это может быть более детализировано, чем если бы у вас было всего пять баз данных, но если у вас есть одна база данных, которая представляет собой тонну нагрузки, и 149 баз данных, которые легковесны или редко используются, вы все равно можете обнаружить, что одна машина зависла, а другие нет. Кроме того, некоторые базы данных иногда заняты, а в другое время почти не используются. Это означает, что все может свестись к тому, что пользователь решит запустить какой-то тяжелый процесс.
Конечно, вы должны иметь возможность поддерживать всю эту нагрузку на одном узле при отказе по любой причине, даже если это что-то обыденное, например, исправление Windows. Если вы исправляете только известные периоды медленного трафика, это прекрасно. Если у вас нет медленных периодов или если переключение происходит из-за сбоя оборудования, другой узел может не принять на себя нагрузку, и вашим пользователям не повезет. Если вы думаете об этом так, то, что вторая машина «ничего не делает», не так уж и раздражает. По крайней мере, вы знаете, что он займет весь трафик, который обычно делает основной.
Еще одна вещь, которую вы можете сделать, - это настроить несколько экземпляров sql server на каждом узле и кластеризовать каждый экземпляр. Разделите базы данных по каждому экземпляру. Каждый экземпляр сам по себе активен / пассивен, но если вы запускаете каждый экземпляр на отдельном узле, вы эффективно распределяете нагрузку. Вам по-прежнему необходимо убедиться, что при отработке отказа один узел может поддерживать ресурс
Группы доступности AlwaysOn также поддерживают реплики только для чтения - это позволит балансировать нагрузку при чтении, и, насколько я могу судить, это первый раз, когда такая вещь стала доступной в SQL Server 2012.
2012 также поддерживает классический кластер активный / активный, который часто упоминается (что произойдет, если вы добавите более 2 узлов, активный / активный / активный фу!), Но имейте в виду, что у него есть ограничения в том, что он предоставляет 2 экземпляра и как только когда один из них выходит из строя, другой оставшийся сервер потенциально получает удвоенную нагрузку или больше.
В дополнение к репликам, доступным только для чтения с балансировкой нагрузки, группы доступности обеспечивают гораздо большую гибкость, особенно с третьим асинхронным следящим сервером, который может находиться на удаленном сайте аварийного восстановления.