Кластеризация AOS-серверов (2009)

[sergeypp]

У кого был опыт кластеризации аосов для 2009..
Есть ли собственные механизмы или нужно использовать механизмы операционной системы. Может есть ссылки на документацию??

[sergeypp]

Тема оказывается уже поднималась.. видимо плохо умею пользоваться поиском,
Но рассматривалась кластеризация 4-ки)) а у меня 2009..
внимательно почитал топики
AOS cluster
AOS в кластере
Из прочитанного я понял, что существуют 2 варианта реализации кластеров:
1. Кластеризация средствами ОС. Ссылка, которую дал уважаемый Mazzy, сдохла (http://technet.navision.com/usered/A...01.00-ENUS.doc ) есть ли у кого сей ценный документ??
2. Кластеризация средствами самого АОСа. Тут как я понял, обязательно использование одного физического приложения и в случае падения одного из аосов, все соединения падают, транзакции откатываются?..
Меня интересует решение, при котором переключение с одного клатера на другой происходило бы прозрачно для пользователей, без отваливания сессий.
Поменялось ли что нибудь в 5-ке в отличии от 4-ки..
Какие есть минумсы использования того или другого решения??

[gl00mie]

Цитата:

Сообщение от sergeypp

Из прочитанного я понял, что существуют 2 варианта реализации кластеров:
1. Кластеризация средствами ОС.
2. Кластеризация средствами самого АОСа. Тут как я понял, обязательно использование одного физического приложения и в случае падения одного из аосов, все соединения падают, транзакции откатываются?..

Своего рода кластеризация серверов приложения рассматривается в курсе 80019 AX 2009 Installation and Configuration, в 4-й главе. Т.е. кластеризация предлагается как средство балансировки нагрузки на AOS'ы в смысле равномерного распределения клиентских соединений. При этом предлагается, опять же, два варианта: с выделенным сервером балансировки нагрузки (выполняющим лишь функцию диспетчеризации новых клиентских соединений и не выполняющим бизнес-логику) и без такового. Согласно курсу, преимущество использования выделенного сервера балансировки нагрузки заключается в упрощении конфигурирования клиентов, для которых нужно будет указать лишь этот выделенный сервер, а состав кластера можно будет изменять произвольно, не переконфигурируя клиентов. В случае же отсутствия выделенного сервера балансировки клиентам якобы нужно будет прописывать все сервера, входящие в кластер, и обновлять их конфигурацию при изменении состава кластера. Впрочем, по сообщениям на буржуйских форумах, даже если не указывать все сервера в конфигурации клиента, AOS'ы и так могут якобы перенаправлять новые соединения на другие сервера.

Цитата:

Сообщение от sergeypp

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

Согласно официальной документации, такого решения нет. Более того, для AX 2009 официально поддерживается кластеризация ролей сервера БД, сервера приложений, но не файл-сервера, хранящего собственно приложение, т.е. даже использование DFS официально не поддерживается. Думается, этот вопрос будет решен в AX6, где приложение обещают хранить в СУБД.

[sergeypp]

А если кластеризация реализована на уровне ОС.. с синхронизацией дискового пространства, памяти.. Может кто-то тестировал это решение..
Насколько я знаю Hyper-v2 позволяет кластеризировать вирт машины.. У кого нить есть опыт?

[Vadik]

Цитата:

Сообщение от sergeypp

А если кластеризация реализована на уровне ОС.. с синхронизацией дискового пространства, памяти..

Вы скорее всего мешаете понятия failover и live migration. Корректный failover (без потери session state) при падении виртуальной машины, гипервизора или хоста в принципе невозможен. А live migration Вам отказоустойчивости не добавляет, он только позволяет перемещать работающую VM между нодами (а - со своими ограничениями и б - процедура требует тестирования с каждым используемым приложением)
Потом, инстанс AOS-а внутри VM что в 4.0, что в 2009 стопроцентной "пуленепробиваемостью" не отличается и нет-нет да и накапливает всякий хлам при мелких проблемах с сетью, БД или клиентами, в результате чего либо через какое-то время падает сам (surprise!), либо планово перезапускается (по возможности - без подключенных пользователей и, соответственно, незаметно), так что бороться за доступность инстанса самого по себе не имеет смысла - он того не стОит. А вот доступность сервиса (количество работающих инстансов AOS-а не ниже заданного и load balancing) Вы и с аксаптовким кластером обеспечить сможете
Так что технологии-технологиями, а про принцип keep it simple тоже забывать не следует

[Bishop]

Цитата:

Сообщение от sergeypp

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

От сервиса сервера приложений AX (Ax32Serv.exe) нельзя требовать стабильной работы в режиме 24/7. Рано или поздно он "падает", со всеми вытекающими последствиями. А "упавший" сервис переносить между кластерами смысла нет . Кроме того, такая стабильность никогда не заявлялась со стороны MS, так что тут все честно.

[sergeypp]

Цитата:

Сообщение от Bishop

От сервиса сервера приложений AX (Ax32Serv.exe) нельзя требовать стабильной работы в режиме 24/7. Рано или поздно он "падает", со всеми вытекающими последствиями. А "упавший" сервис переносить между кластерами смысла нет . Кроме того, такая стабильность никогда не заявлялась со стороны MS, так что тут все честно.

А я думал, что кластер как раз нужен для того, что бы обеспечивать доступность сервисов, если один из серверов в кластере падает.. Спасибо что открыли мне глаза!!
После исследования проблемы выяснилось следующее:
Решения, обеспечивающего прозрачное переключения пользователей между аосами нет..В любом случае потребуется переподключение.
Были попытки кластеризовать АОС сервер целиком вместе с приложением. Кластер постоянно падал. Аудит, проведенный сотрудниками Микрософта, постановил следующее: Микрософт не гарантирует стабильную работу аосов в таком режиме. Отсюда 2 следующих варианта кластеризации аосов:
1. Поднимаются 2 аоса. Оба включаются в кластер. На клиенте прописывается маска аос-серверов. Клиент сам выбирает наименее загруженный аос в момент подключения. Плюсы - легко настроить. Минусы - неудобство администрирования
2. Поднимаются 2 аоса..Поднимаются 2 сервера в кластере.. На сервера в клстере устанавливается АОС по балансировке нагрузки (Select Use this AOS instance for load balancing only (accept no client connections)). Клиентские машины настраиваются на кластер аосов по распределению нагрузки.. В случае падения одного из серверов, второй продолжает работать и распределять. Плюсы - простота управления аосами, Минусы - гемор в настройке, необходимо выделения 2-ух спец серверов (или вешать сервисы на сервера с другими ролями), покупка доп. лицензий на винду. Сам балансирующий аос лицензии не требует.

Есть еще 3-ий вариант.. Кластеризация аосов на уровне кластеризации виртуальных машин.. Будем рыть в этом направлении..

[Bishop]

Цитата:

Сообщение от sergeypp

Отсюда 2 следующих варианта кластеризации аосов:
1. Поднимаются 2 аоса. Оба включаются в кластер. На клиенте прописывается маска аос-серверов. Клиент сам выбирает наименее загруженный аос в момент подключения. Плюсы - легко настроить. Минусы - неудобство администрирования
2. Поднимаются 2 аоса..Поднимаются 2 сервера в кластере.. На сервера в клстере устанавливается АОС по балансировке нагрузки (Select Use this AOS instance for load balancing only (accept no client connections)). Клиентские машины настраиваются на кластер аосов по распределению нагрузки.. В случае падения одного из серверов, второй продолжает работать и распределять. Плюсы - простота управления аосами, Минусы - гемор в настройке, необходимо выделения 2-ух спец серверов (или вешать сервисы на сервера с другими ролями), покупка доп. лицензий на винду. Сам балансирующий аос лицензии не требует.

Советую использовать следующий вариант:
На каждый сервер приложения (физический) устанавливается два АОСа: "основной" (Make this AOS instance part of the load balancing cluster) и "балансировщик" (Use this AOS instance for load balancing only (accept no client connections)), который действительно не требует доп. лицензии (еще бы он ее требовал!).
В конфигурационной утилите клиента перечисляются все "балансировщики".
Таким образом, при выходе из строя любого сервера, приложение останется доступным для клиентов и распределение нагрузки будет продолжать функционировать (если вы используете больше двух "основных" АОСов).
"Балансировщик" никак не нагружает систему, так что не беспокойтесь относительно совмещения двух ролей одним сервером.

И еще, вся балансировка заключается лишь в равномерном распределении количества клиентских сессий по АОСам. Никакого анализа нагруженности процессора/памяти не происходит (AX 4.0, насчет AX 2009 - не знаю).
Например, если на первом АОСе "сидит" 10 пользователей, листающих справочники, а на втором АОСе - 5 пользователей, закрывающих склад, то следующие 5 новых подключений "отбалансируются" на второй АОС, как бы туго ему в этот момент не было...

[Vadik]

Цитата:

Сообщение от Bishop

Советую использовать следующий вариант:
На каждый сервер приложения (физический) устанавливается два АОСа: "основной" (Make this AOS instance part of the load balancing cluster) и "балансировщик" (Use this AOS instance for load balancing only (accept no client connections)), который действительно не требует доп. лицензии (еще бы он ее требовал!).
В конфигурационной утилите клиента перечисляются все "балансировщики".

С тем же успехом можно не создавать load balancer-ов вообще и тупо перечислить в конфигурации клиента все "рабочие" инстансы
А опции "make this AOS instance part of the load balancing cluster" в конфигурации AOS в AX2009 нет, оно теперь из клиента настраивается

[Maximin]

Я, может быть, что-то не так понимаю, но и без двух AOSов на машину достаточно перечислить в конфигурационной утилите клиента просто все рабочие AOSы. Результат будет тот же. Я не вижу смысла в отдельном балансировщике на каждый AOS - они и так замечательно балансируют сами. Более того, даже если у клиента прописан только один из АОСов, тот МОЖЕТ перекинуть его на другой AOS, из числа входящего в кластер AOSов.
Проверено, в т.ч. и в критических ситуациях, когда падал (вместе с железом) основной AOS вместе с приложением, пришлось заливать приложение на один из дополнительных. Все взлетело и распределилось. Более того, если я подниму свой рабоче-тестовый AOS, подключенный к основной базе и не прописанный ни в одной клиентской конфигурации, и забуду вырубить галку @make part of...", то очень сокро обнаружу там работающих пользователей.
А отдельный AOS-балансировщик MS предлагает использовать только при большом числе входящих подключений для уменьшения нагрузок на основные AOSы. И то - одну штуку.

Цитата:

Сообщение от Bishop

В конфигурационной утилите клиента перечисляются все "балансировщики".

Vadik Опередил, пока писал...

[Maximin]

А что нового кроме того, что описано в документации, вы ожидали увидеть?
Да, Ax 4.0 не умеет (как и тот же SQL Server, к примеру), как писал Vadik failover без потери session state при использовании кластеризации средствами ОС. Толку таскать между серверам VM с AOSом. Более того, вариант неподдерживаемый и был приведен пример неудачи с ним. Ну, а раз так - смысл этой кластеризации отпадает, раз есть кластеризация средствами самой Аксапты (читай возможность запустить несколько AOSов) с вариантами реализации с /без балансировщиков. Собственно, это всё и изложено в поставляемом в дистрибутиве Axapta Implementation Guide. Здесь только вольные пересказы и обсуждения подробностей.