Вопрос: AlwaysOn SQL Server 2012 - любая опция для действительного активного / активного?


Я собираюсь обновить и консолидировать группу SQL Server 2008R2 до одного SQL Server 2012. Я хочу иметь высокую доступность и искать различные варианты. Количество баз данных довольно велико (150+), поэтому вопрос о DBMirroring не может быть и речи.

Теперь я смотрю «AlwaysOn Availability Group» и «AlwaysOn отказоустойчивый кластер», и я не могу понять, куда идти ..... возможно, еще больше вариантов.

кластеризация может быть хорошим способом сделать что-то, но это действительно раздражает, когда большой сервер власти ничего не делает, но ждет, пока основной сервер не сработает.

Есть ли способ сделать реальную активную / активную кластеризацию в SQL Server (реальная балансировка нагрузки)?


5
2018-05-03 07:07


Источник


Пожалуйста, отметьте более тщательно. это не Кластер-анализ вопрос. Заменили это Балансировка нагрузки - Anony-Mousse


Ответы:


Microsoft SQL Server не поддерживает «реальную» схему балансировки нагрузки из коробки. AFAIK, это все еще верно в SQL Server 2012. (Кто-то просветит меня, если я ошибаюсь.) Неважно, говорим ли мы о зеркалировании базы данных или AlwaysOn или кластерах.

(Чтобы забить эту точку дома, MS, похоже, в последнее время вызывает кластеры SQL Server «отказоустойчивые кластеры SQL Server». «Педантика».)

Если вы хотите загрузить баланс своих баз данных, вам придется самому усердно работать с каким-то осколком, федерацией или репликацией. (Обратите внимание, что федерация (по видам) находилась в продукте со времен SQL Server 2000, она просто не очень популярна.) И, конечно, это означало бы изменение ваших баз данных или самих приложений, что почти всегда либо слишком много работы или нарушает ваши соглашения с поставщиками. С 150 базами данных это намного более непреодолимо.

У вас может быть активный активный кластер, но дело в том, что вам придется тщательно распределять базы данных на своих узлах, чтобы разделить нагрузку. С 150 базами данных это может быть более зернистым, чем если бы у вас было только пять баз данных, но если у вас есть одна база данных, которая представляет собой тонну нагрузки и 149, которые легки или используются редко, вы все равно можете найти одну машину, увязшую и другой нет. И некоторые базы данных иногда заняты и не заняты в другое время. Это означает, что все может сработать, когда пользователь решит запустить какой-то тяжелый процесс.

Конечно, вы должны иметь возможность поддерживать всю эту нагрузку на одном узле, когда вы терпите неудачу, по какой-либо причине, даже если это что-то обычное, как исправление Windows. Если вы только патчи во время известных периодов медленного трафика, это здорово. Если у вас нет медленных периодов или происходит переход на другой ресурс, поскольку на самом деле у аппаратного обеспечения есть неисправность, другой узел может не принять нагрузку, и вашим пользователям будет не повезло. Если вы так думаете об этом, то вторая машина, «ничего не делая», не настолько раздражает. По крайней мере, вы знаете, что это займет весь трафик, который обычно выполняет основной.


7
2018-05-03 21:31





Группы доступности AlwaysOn также поддерживают реплики только для чтения - это позволит балансировать нагрузки для чтения, и насколько я могу судить об этом, впервые такая возможность появилась в SQL Server 2012.

2012 также поддерживает классический кластер, активный / активный, который часто упоминается (что происходит, если вы добавляете более двух узлов, активных / активных / активных yuck!), Но имейте в виду, что имеет ограничения в том, что он предоставляет 2 экземпляра и как только по мере того как один идет вниз, другой оставшийся сервер может потенциально захлопнуться с удвоенной нагрузкой или более.

В дополнение к балансируемым по нагрузке репликам только для чтения группы доступности обеспечивают гораздо большую гибкость, особенно с третьим асинхронным сервером-свидетелем, который может находиться на удаленном узле DR.


0
2017-08-02 22:04





Еще одна вещь, которую вы могли бы сделать, это настроить несколько экземпляров сервера sql на каждом узле и сгруппировать каждый экземпляр. Разбивайте базы данных по каждому экземпляру. Каждый экземпляр сам является активным / пассивным, но если вы запускаете каждый экземпляр на отдельном узле, вы эффективно распределяете нагрузку. Вам все равно нужно убедиться, что если вы выполните сбой, один узел может поддерживать ресурс


0
2018-02-07 22:45