Отладка в D365FO

[Ivanhoe]

Раз можно тут, значит и в облаке можно было бы при желании.
Пишут, что нужно оставить один аос, чтобы точно на нем ловить исполнение. В он-прем нет варианта входа конкретного пользователя на конкретный аос?

[fed]

Цитата:

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

Раз можно тут, значит и в облаке можно было бы при желании.
Пишут, что нужно оставить один аос, чтобы точно на нем ловить исполнение. В он-прем нет варианта входа конкретного пользователя на конкретный аос?

По крайней мере - мне о таком способе не известно. Вообще - похоже что этот Azure Service Fabric - это такая среда исполнения контейнеров типа Docker. При этом - ax там работает не в контексте IIS (который может быть даже не установлен),а где-то в контексте своего собственного процесса (axservice.exe), который где-то на каком-то хосте Service Fabric крутится. При этом, Service Fabric, вроде бы, может реплицировать состояние каких-то областей памяти между процессами на разных узлах кластера и из за этого, последовательные запросы одного и того же пользователя могут, в теории, вообще обрабатываться разными физическими серверами. Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Теоретически про архитектуру Service Fabric рассказано вот здесь, но у меня времени видео смотреть не было, а просто в тексте там не все технические подробности механизмов state replication рассказаны.

[AlexeyS]

Цитата:

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

Вообще - похоже что этот Azure Service Fabric - это такая среда исполнения контейнеров типа Docker. При этом - ax там работает не в контексте IIS (который может быть даже не установлен),а где-то в контексте своего собственного процесса (axservice.exe), который где-то на каком-то хосте Service Fabric крутится. При этом, Service Fabric, вроде бы, может реплицировать состояние каких-то областей памяти между процессами на разных узлах кластера и из за этого, последовательные запросы одного и того же пользователя могут, в теории, вообще обрабатываться разными физическими серверами. Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Заинтересовался, полез читать: Service Fabric - это оркестратор контейнеров, который развертывает микрослужбы в кластере виртуальных машин. Микрослужбы это, например, ASP.Net Core или приложение любого типа.

Единицей развертывания является не сервис, а совокупность сервисов, называемая приложением — в манифесте приложения можно, кроме прочего, определить партиционирование сервиса для поддержания масштабируемости, а для отказоустойчивости в случае выхода из строя серверов ASF каждая партиция может иметь несколько экземпляров сервисов. И сервисы и приложения версионируются независимо, что позволяет обновлять приложение, не обновляя в нем все сервисы разом. Для развернутого приложения ASF создает нужное количество экземпляров сервисов, размещает на нодах кластера, запускает, синхронизирует состояние между экземплярами, пересоздает экземпляры для балансировки нагрузки.

Сервисы в ASF могут быть statefull и stateless, и судя по сценарию приложений для statefull, запросы одного пользователя будут обрабатываться на одном сервисе. Но на каком именно - неизвестно, это определяет балансировщик, поэтому и должен остаться только один.
С другой стороны, непонятно, как тонко разделено приложение на сервисы.
Например модуль Sales это приложение (в терминах ASF) как совокупность сервисов или нет? Создание заказа это отдельный сервис или нет? А создание нового клиента по ходу создания заказа это отдельный сервис?

[fed]

Цитата:

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

Сервисы в ASF могут быть statefull и stateless, и судя по сценарию приложений для statefull, запросы одного пользователя будут обрабатываться на одном сервисе. Но на каком именно - неизвестно, это определяет балансировщик, поэтому и должен остаться только один.
С другой стороны, непонятно, как тонко разделено приложение на сервисы.
Например модуль Sales это приложение (в терминах ASF) как совокупность сервисов или нет? Создание заказа это отдельный сервис или нет? А создание нового клиента по ходу создания заказа это отдельный сервис?

Ну там сейчас вся старая добрая аксапта живет как один Service Type - AXSF. Так что не так уж оно чтобы и очень микро-сервис
Кроме того - мне не очень понятно как именно они сделали поддержку репликации и масштабирования stateful service. Они там что-то пишут по поводу репликации, но конкретики не так чтобы уж очень много. Я правильно понимаю, что в случае если у меня один из серверов остановлен, все пользователи просто магически переедут на другой сервер, не заметив подмены ?

[AlexeyS]

Цитата:

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

Ну там сейчас вся старая добрая аксапта живет как один Service Type - AXSF. Так что не так уж оно чтобы и очень микро-сервис
Кроме того - мне не очень понятно как именно они сделали поддержку репликации и масштабирования stateful service. Они там что-то пишут по поводу репликации, но конкретики не так чтобы уж очень много. Я правильно понимаю, что в случае если у меня один из серверов остановлен, все пользователи просто магически переедут на другой сервер, не заметив подмены ?

Ответа на этот вопрос не нашел, но в целом, создалось впечатление, что нет. Чтобы работало именно так, то один экземпляр сервиса должен уметь передавать состояние клиента другому экземпляру сервиса. Это подразумевает постоянное сохранение состояния в каком-то хранилище. В каком-нибудь google docs это на уровне архитектуры, умеет ли это аксапта - не знаю.

[trud]

Цитата:

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

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

Вот такое прочитаешь и непонятно, откуда взялось 3 часа полной остановки системы при любой заливке нового кода
т.е. то-ли разработчики ах не разобрались, то ли сервис фиговой
Кстати помимо АХ есть ведь еще Data management service который работает с локальными папками, он вряд ли отказ узла переживет

[AlexeyS]

Цитата:

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

Вот такое прочитаешь и непонятно, откуда взялось 3 часа полной остановки системы при любой заливке нового кода
т.е. то-ли разработчики ах не разобрались, то ли сервис фиговой
Кстати помимо АХ есть ведь еще Data management service который работает с локальными папками, он вряд ли отказ узла переживет

Так это для приложений, которые написаны в полном соответствии с концепцией Service Fabric. А на сегодня ASF выступает просто контейнером для сервиса Аксапты. Возможно в будущем, когда основное ядро будет закрыто для изменений, AOS порежут на тысячи мелких сервисов, собранных в приложения-пакеты по функциональным областям и любой бизнес-процесс будет набором сервисов, выстроенных в цепочки, по типу WorkFlow. Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

[fed]

Цитата:

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

Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

Опыт показывает, что время для честного переноса (и редизайна) любой крупной программной системы на принципиально новую технологию заметно превышает длительность hype cycle. Так что я думаю Аксапточка так и останется одиноким statefull service type AXSF. А там глядишь либо опять менеджмент в микрософте сменится или DEVOPS выйдет из моды и будет заменен Waterfall 4.0 или еще чего-нить подобное случится. В общем - в полном соответствии со старой притчей про Насреддина, бухарского эмира и осла...
P.S. Кстати - не могу не вспомнить как при том же Наделлле, в Ax 4.0 старый сетевой протокол имени Damgaard был заменен на Windows RPC (с большой помпой и вынужденный интеграцией с доменной системой windows). Но при этом единственная вызываемая по RPC функция принимала в качестве параметра, BLOB в формате старого дамгаардовского сетевго протокола.

[trud]

Цитата:

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

Вот тогда возникнет ситуация, что можно собрать себе приложение на заказ из куска AX, куска CRM и куска NAV, но пока это только фантазии.

Почему фантазии? это уже есть, т.е. все приложения умеют хранить данные в Common Data Service(уже чуть ли не 2 версия выходит), плюс пользователь сам создает недостающие компоненты через PowerApps мышкой

[AlexeyS]

Цитата:

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

Почему фантазии? это уже есть, т.е. все приложения умеют хранить данные в Common Data Service(уже чуть ли не 2 версия выходит), плюс пользователь сам создает недостающие компоненты через PowerApps мышкой

Как это работает на примере, можете пояснить?
Это способ интеграции между приложениями, каким в свое время выступил XML или что-то большее?

[Logger]

Цитата:

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

Из за этого Тарик и рассказывает как остановить избыточные axservice.exe - как раз для того чтобы все запросы падали на один и тот же сервер, на котором у нас отладчик крутится...

Получается что по живой уже не отладишься. Всех придется выгонять. Или может есть какой-нить аналог -aos2 ?

[Ivanhoe]

Цитата:

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

По крайней мере - мне о таком способе не известно.

При этом есть сервер Windows, на котором стоит IIS и сайт AOSService. Что нам мешает локально на этом сервере запускать браузер и подключаться к Аксапте по локальному адресу? Или Аксапта настолько умная, что может перевести подключение на физически другой сайт / IIS / Windows server?

[fed]

Цитата:

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

При этом есть сервер Windows, на котором стоит IIS и сайт AOSService. Что нам мешает локально на этом сервере запускать браузер и подключаться к Аксапте по локальному адресу? Или Аксапта настолько умная, что может перевести подключение на физически другой сайт / IIS / Windows server?

Так в том то и дело, что нету там IIS и сайта AOSService. Как я уже сказал, все это дело живет в Service Fabric. В требованиях к конфигурации кластера там написано что у тебя DNS-имя ax.contoso.com должно разрешаться на список ip тех хостов, где стоят AOSы. При этом сам URL там выглядит как https://ax.contoso.com/namespaces/AXSF/ Я так понимаю, клиент полезет к первому попавшемуся из AOS, клиенту ответит на первом уровне Service Fabric (возможно - перенаправляя его на другой AOS). Потом уже на втором уровне пойдет соединение к самому axService.exe, на этом же хосте или на каком-то еще.
Когда я пробовал образаться к адресу конкретного хоста (типа https://ax1.contoso.com/namespaces/AXSF/) соединение не устанавливалось из за каких-то граблей с сертификатами. Возможно, там можно было бы настроить и на использование сертификата для конкретного хоста. Возможно при этом даже удалось бы как-то отключить балансировщик нагрузки Service Fabric, который клиента как-то (вероятно) редиректит на конкретный IP. Проблема в том, что никакой документации на эту тему нет. Кроме того документа, на который я уже давал ссылочку, ничего другого найти не удалось. А сам этот документ - это смесь concept guide и tutorial по разработке "Hello world"-приложения....

[Ivanhoe]

Цитата:

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

Так в том то и дело, что нету там IIS и сайта AOSService.

Т.е. он есть только на демо-виртуалках всё-в-одном? Я первым делом пошел туда посмотреть.

[fed]

Цитата:

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

Т.е. он есть только на демо-виртуалках всё-в-одном? Я первым делом пошел туда посмотреть.

В общем - у них в D365 есть понятие топологии. Пока что я видел три варианта топологии:

1. One Box. Весь софт установлен на одной VM (включая SQL Server и Management Reporter). Ax работает как один из сайтов в IIS.
2. Test. БД лежит в Azure SQL. Ax живет как сайт в IIS на одной VM. На другой VM живет Management Reporter, SSRS, локальный SQL Server с Data Warehouse database и локальной базой SSRS. Микрософт собирается эту топологию убить и в дальнейшем запускать тестовое окружение через Service Fabric...
3. On Premises (Вероятно также - продуктивная версия в Azure). 2 или 3 AOS; 1 или 2 SSRS Server, 1 Management Reporter, 3 Оркестратора (служебных сервера) под Service Fabric.БД лежит либо в Azure SQL, либо в обычном SQL Server (но не управляемом через Service Fabric). AOS, SSRS,MR и Оркестратор живут внутри Service Fabric. IIS стоит, кажется, только на серверах Management Reporter (который хоть и деплоится через Service Fabric, но все равно работает через обычный Web Site, похоже что).

Так что даже если какая-то версия D365FOE работает на локальной VM, это не делает ее On Premises версией

Кстати, Микрософт очень напрасно не выпустил официально поддерживаемую On Premises версию, основанную на One Box-топологии. Она вполне себе прилично дежит пользователей 15 при достаточно разумных требованиях к железу. Вот сделали бы они какой-нить On Premises lite, который жил бы в IIS (а не в Service Fabric) - его мелкие клиенты с радостью бы покупали...

[AlexeyS]

Цитата:

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

Кстати, Микрософт очень напрасно не выпустил официально поддерживаемую On Premises версию, основанную на One Box-топологии. Она вполне себе прилично дежит пользователей 15 при достаточно разумных требованиях к железу. Вот сделали бы они какой-нить On Premises lite, который жил бы в IIS (а не в Service Fabric) - его мелкие клиенты с радостью бы покупали...

У МС магистральное направление движения - в облака, поэтому не будет такого, хотя жаль.