Назад в будущее?

Речь пойдет о кластере. Что такое кластер?

Собственно в 3.0 кластер распределения нагрузки составлял список доступных серверов приложений (AOS, Axapta Object Server) в кластере с соответствующим количеством пользователей, соединенных с каждым из серверов. При подключении нового пользователя к кластеру, клиент производил выбор сервера с наименьшим количеством пользовалей в этом списке. И подключался к этому, наименее "загруженному"... Использовался стандартный протокол AOCP, ранее созданный специально для Microsoft Axapta.

В Microsoft Dynamics Ax 4.0 протокол AOCP был заменен на стандартный протокол Microsoft - RPC, тому было множество оснований, в частности лучшая производительность и защищенность RPC. С протоколом AOCP была упразднена архитектура кластеризации из 3.0. В 4.0 для получения подобной кластеризации стали использовать Network Load Balancing (NLB, балансировку нагрузки сети), подробнее можно посмотреть в описании NLB.

Новая реализация, основанная на NLB работала отлично, насмотря на ограничение в 32 сервера в кластере. Однако, использование NLB означает и другое ограничение - невозможность использования кластера для клиента Dynamics Ax подключающегося к кластеру через терминальный доступ (сессию терминального сервера, TS).

Т.е. строить типичное окружение развернутое вовне типа: пользователь-WAN-TS-клиент Ax-кластер Ax-СУБД, стало невозможным.

 

Версия 4.0 сервис - пак 1 (4.0SP1) будет содержать кластерную архитектуру, близкую к 3.0.

Означает ли это возврат к AOCP в том виде, что был в 3.0? - Нет. 

Означает ли это, что AOS перестанет быть сервисом операционной системы? - Нет.

Будет ли архитектура абсолютно идентичной 3.0 с точки зрения функционирования кластера? - Не совсем.

Основное отличие - появление новой роли 'балансировщика нагрузки' ('Load Balancer').  Кластер может быть развернут в двух вариантах:

- Без 'балансировщика нагрузки', функционирование будет похоже на 3.0, при этом клиент Ax должен содержать список всех серверов приложений (хост, имя, порт), входящих в кластер.

- С  'балансировщиком нагрузки', один из серверов (или несколько) приложений выделяется как сервер, занимающийся только распределением нагрузки (составлением списка и перенаправлением клиентов Ax). Клиент Ax может содержать только этот сервер. Балансировщик не участвует в обработке объектов, пользователи не могут подключиться непосредственно к нему. Балансировщик не требует лицензии (не занимает лицензию) на сервер приложения AOS. 

Что дает 'балансировщик нагрузки'? Клиент Ax не требует перенастройки, добавления или удаления серверов приложений из конфигурации в случае замены или добавления серверов приложений AOS. Конечно же, при условиии, что сам 'балансировщик' не изменялся. 

 

Сняты ли все ограничения с 'возвратом' к новой кластерной архитектуре? Увы нет, использование кластеров для Web приложений отложено до 4.1. Пока требуется строгое соответствие: сервер IIS-сервер приложений AOS.

Кроме того, пока не решена и также отложена до 4.1 проблема, когда при отказе сервера приложений AOS (выход из строя материнской платы, например), пользовательские транзакции будут отменены, сессии закрыты и пользователи будут вынуждены заново соединяться с кластером (с остальными серверами приложений).

Для административных целей оставлена возможность подсоединения к необходимому серверу приложений AOS кластера, используя параметр '-noloadbalance' в конфигурации клиента Ax.

Кстати, опция построения кластера на базе NLB в 4.0SP1 осталась... Т.е. теперь есть два пути построения кластера для DAX.

Comments

• Anonymous
  January 02, 2007
  Strictly speaking, AOCP was not abandoned in favour of RPC. In fact, AOCP was only wrapped in RPC. So there still is good old AOCP under the hood of RPC :)
• Anonymous
  January 03, 2007
  Добавление верное, c 4.0SP1 старый добрый AOCP живет на RPC..."Old, New, Borrowed and Blue ..." :)