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


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


Собственно в 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 (2)

  1. hAx says:

    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 🙂

  2. Добавление верное, c 4.0SP1 старый добрый AOCP живет на RPC…

    "Old, New, Borrowed and Blue …" 🙂

Skip to main content