Мы создаем систему с использованием служебной шины для Windows 1.1 для pub / sub. Если бы мы были в Azure, мы могли бы использовать секционирование для масштабирования. Однако локальная версия не поддерживает разбиение на разделы. Вместо этого все узлы в ферме, похоже, используют один и тот же SQL Server для своего уровня сохраняемости, и это кажется встроенным узким местом.
Что мы можем сделать, чтобы масштабировать служебную шину для Windows?
Как говорится в этой статье.
http://www.planetgeek.ch/2014/12/10/service-bus-for-windows-server-high-availability/#
Если на сервере имеется более одного контейнера, контроллер фабрики автоматически перебалансирует вычислительную мощность, переназначая контейнеры определенной службе брокера обмена сообщениями. Этот механизм балансировки нагрузки также срабатывает, когда администраторы сервера создают новые контейнеры сообщений или удаляют существующие. Новые серверы можно автоматически присоединить к существующей ферме, выполнив несколько команд PowerShell, о которых мы расскажем в следующих частях.
Для уровня хранения служебная шина для Windows Server не имеет готового решения. Но поскольку базовый уровень хранения основан на Sql Server, вы можете использовать функции Sql Server Mirroring или AlwaysOn новейших выпусков Sql Server Edition.
Для обеспечения высокой доступности вычислительных узлов используются «установщики» служебной шины. На сервере Sql вы должны установить собственный режим высокой доступности.
Моя компания использует «Экземпляр отказоустойчивого кластера AlwaysOn (FCI)». поскольку у нас есть Standard Edition. См. Ссылку ниже.
AlwaysOn - это более крупный зонтик, охватывающий две функции. Группы доступности AlwaysOn (AG) и экземпляр отказоустойчивого кластера AlwaysOn (FCI). Поддерживается FCI для 2 узлов. Функцию AG нельзя использовать в SQL Server Standard Edition
Также см:
https://msdn.microsoft.com/en-us/library/jj193012%28v=azure.10%29?f=255&MSPPError=-2147217396
А также:
Рекомендации: убедитесь, что он является высокодоступным (HA): HA может быть полностью удовлетворено только тогда, когда оба уровня сервиса и базы данных являются HA. HA уровня обслуживания может быть достигнуто, если в кольце будет по крайней мере 3 сервера. Что касается высокой доступности базы данных, это можно сделать разными способами в зависимости от вашего случая (версия базы данных, план аварийного восстановления и т. Д.). Вы можете проверить мои сообщения в блоге об отказоустойчивой кластеризации на одном сайте здесь для SQL 2012 Server. Обратите внимание, что служебная шина v1.1 поддерживает до 5 серверов в кольце. Убедитесь, что она масштабируема: вам необходимо минимум 2n контейнеров сообщений, где n - количество серверов в кольце фермы служебной шины. Таким образом, для реализации высокой доступности и масштабируемой служебной шины требуется как минимум 3 сервера и 6 контейнеров сообщений (экземпляров базы данных).
