Распространенные проблемы в Разработке невеб-Корпоративных приложений С поддержкой кластеров

Сначала я отвечу на часть вопроса о постоянном соединении, так как это проще. Все хорошие решения по балансировке нагрузки сети (включая встроенную в Windows Server службу Microsoft NLB, а также включая устройства балансировки нагрузки, такие как F5 BigIP) имеют возможность "приклеивать" отдельные соединения от клиентов к определенным узлам кластера на время соединения. В NLB от Microsoft это называется "Single Affinity", в то время как другие балансировщики нагрузки называют это "Sticky Sessions". Иногда есть предостережения (например, NLB от Microsoft прерывает соединения, если к кластеру добавляется новый член, хотя одно соединение никогда не переносится с одного хоста на другой).

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

Большинство кластерных приложений, которые я видел, будут хранить общее состояние (даже общее, нестабильное состояние, как глобальные переменные) в СУБД. В основном это неудобно. Для максимальной производительности можно также использовать базу данных в памяти . Но простота использования СУБД для всех разделяемых состояний (переходных и длительных), плюс использование существующих инструментов СУБД для высокой доступности, как правило, срабатывает для многих сервисов. Совершенство СУБД на порядок медленнее, чем глобальные переменные в памяти, но если общее состояние небольшое, вы все равно будете считывать данные из кэша СУБД, а если вы делаете сетевой прыжок для чтения/записи данных, то разница относительно меньше. Вы также можете добиться большой разницы, оптимизируя схему базы данных для быстрого чтения/записи, например, удаляя ненужные индексы и используя NOLOCK для всех запросов на чтение, где точная, до миллисекундная точность не требуется.

Я не говорю, что СУБД всегда будет лучшим решением для общего состояния, только то, что улучшение времени доступа в общее состояние обычно не является способом, с помощью которого приложения, балансирующие нагрузку, получают свою производительность - вместо этого, они получают производительность, удаляя необходимость синхронного доступа (и, особенно, запись в). в общем состоянии по каждому запросу. Это вторая вещь, которую я отметил выше: изменение приложения для уменьшения зависимости от общего состояния.

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

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

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

Я бы не стал утруждать себя использованием MSCS (Microsoft Cluster Service) в вашем сценарии. MSCS - это решение обхода отказа, что означает, что оно хорошо держит односерверное приложение высоко доступным, даже если один из узлов кластера выходит из строя, но вы не получите масштабируемости и простоты, которые вы получите от настоящей службы, балансирующей нагрузку. Я подозреваю, что у MSCS есть способы разделения состояния (на общем диске), но они требуют установки кластера MSCS, который включает установку обхода отказа, использование общего диска, и прочую сложность, которая не подходит для большинства приложений, балансированных по нагрузке. Лучше всего использовать базу данных или специализированное решение в области памяти для хранения общего состояния.