Перенос доработок на Prod

[mazzy]

Цитата:

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

Как MS официально предполагает делать синхронизацию? Кроме скриптов больше никак не ускорить?

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

когда все в одном все равно узким местом будет диск.
и давать параллельные команды - бессмыслено.

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

но тут начинаются: вопросы логической целостности при параллельных заданиях, вопросы как разбито на физические устройства, deadlock и прочее.

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

примерно так.

[trud]

Цитата:

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

но тут начинаются: вопросы логической целостности при параллельных заданиях, вопросы как разбито на физические устройства, deadlock и прочее.

Все же думаю алгоритм немного кривоват, а не "физические диски". т.е. самый простой случай - запускаем синхронизацию без каких то изменений в структуре данных. она работает минут 20
Кстати в АХ7 реализована наконец-то параллельная синхронизация, т.е. выполняется побыстрее при 100% загрузке процессора
Документ "Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments" описывает довольно экзотические способы снижения downtime "Import a model store with minimal downtime", интерестно так кто нибудь делает?

Цитата:

To reduce downtime, we recommend that you import the metadata into a new schema next to the old one, and then switch to the active schema. This methodology lets users continue using the system until the AOS instance needs to be restarted so that the new schema can be applied.

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

[mazzy]

Цитата:

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

Все же думаю алгоритм немного кривоват, а не "физические диски". т.е. самый простой случай - запускаем синхронизацию без каких то изменений в структуре данных. она работает минут 20
Кстати в АХ7 реализована наконец-то параллельная синхронизация, т.е. выполняется побыстрее при 100% загрузке процессора

возможно. для синхронизации в общем случае узким местом является не процессор.
а можно подробнее про параллельную синхронизацию в акс7 или ссылку? похоже, я пропустил.

[trud]

Цитата:

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

а можно подробнее про параллельную синхронизацию в акс7 или ссылку? похоже, я пропустил.

Было в каком-то whats new. В принципе достаточно просто запустить, и увидеть что грузятся все ядра, а не одно как было в 2012

[Vadik]

Цитата:

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

Было в каком-то whats new. В принципе достаточно просто запустить, и увидеть что грузятся все ядра, а не одно как было в 2012

А толку с нее ? В продуктиве MS сам деплоит, и резервирует на все про все 5 часов. По факту - последнее время управляются за 2.5-3

[trud]

Цитата:

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

А толку с нее ? В продуктиве MS сам деплоит, и резервирует на все про все 5 часов. По факту - последнее время управляются за 2.5-3

О..
Кстати вчера вышел Update4, теперь обещают greatly reduced

Цитата:

Apply deployable packages with reduced downtime.
Currently, the average downtime needed to apply a single package in an environment deployed through LCS is 5 hours. With this feature, the package application is optimized so that the downtime is greatly reduced.

Кстати а вот вопрос - если после обновления надо что-нибудь поотлаживать на копии текущей рабочей БД, сколько времени по факту занимает получение такой копии? я так понимаю создается запрос в поддержку на получение копии БД, который может выполняться 1 бизнес день?, потом еще сколько то на развертывание этой копии.. и т.д. Как вы решаете такое?

[Vadik]

Цитата:

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

О..
Кстати вчера вышел Update4, теперь обещают greatly reduced

Таки там с двух сторон пилят - и платформу, и LCS (в январе кажется начали независимые шаги типа накатывания бинарных обновлений на AOS-ы исполнять параллельно). У нас и на Update 2 процесс ускорился с 5 до 3 часов

Цитата:

Кстати а вот вопрос - если после обновления надо что-нибудь поотлаживать на копии текущей рабочей БД, сколько времени по факту занимает получение такой копии? я так понимаю создается запрос в поддержку на получение копии БД, который может выполняться 1 бизнес день?, потом еще сколько то на развертывание этой копии.. и т.д. Как вы решаете такое?

Service request на LCS, указываем откуда, куда и когда восстанавливать (не менее чем за 5 часов). Собственно восстановление где-то за час делают (почему-то руками / скриптами)

[Vadik]

Цитата:

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

Документ "Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments" описывает довольно экзотические способы снижения downtime "Import a model store with minimal downtime", интерестно так кто нибудь делает?

А что там экзотичного ? Когда время ограничено - я так делал. Импортнули modelstore во временную схему "на ходу" (не останавливая работу), остановили AOS-ы, переключили схему, запустились на выделенном AOS, синхронизация - и можно запускать остальных и деплоить отчеты
P.S. Ждать пока задеплоятся все отчеты - совсем необязательно

[skuull]

Цитата:

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

Документ "Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments" описывает довольно экзотические способы снижения downtime "Import a model store with minimal downtime", интерестно так кто нибудь делает?

Мы так делаем, в итоге downtime упирается в те же 20 мин синхронизации. Потому что компилить ничего не надо только AOSы перегрузить, а компиляцию и CIL делаем на отдельной машине. В итоге подготовленный modelsore можно накатить на "PreProd" и потестить перед накаткой на PROD, а то бывает кто-то криво код сведет или чего забудет...
По поводу 7ки на яммере МС писали что и сейчас весь downtime уходит на синхронизацию, мол они работают над этим но пока ничего не придумали

[gl00mie]

Цитата:

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

Документ "Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments" описывает довольно экзотические способы снижения downtime "Import a model store with minimal downtime", интересно так кто нибудь делает?

Цитата:

To reduce downtime, we recommend that you import the metadata into a new schema next to the old one, and then switch to the active schema. This methodology lets users continue using the system until the AOS instance needs to be restarted so that the new schema can be applied.

Рассматривали такой вариант на крупном внедрении, к сожалению, он не подошел как раз из-за необходимости останавливать все АОСы одновременно, чтобы переключиться с одной схемы на другую. По описанию логично было бы ожидать, что есть какая-то настройка, указывающая название активной схемы и считываемая АОСом при запуске, однако, это, похоже, не так, и активная схема всегда dbo, а "переключение" заключается в перебивке "временного" названия схемы на dbo, что требует отключения всех АОСов от базы моделей.
Я, может, крамольную вещь скажу, но в моей практике очень часто бывает нужно обновлять рабочее приложение без одновременного перезапуска всех АОСов. Это связано с тем, что обычно АОСы делятся на различные группы по функциональной нагрузке:

• пользовательские - для подключений виндовым клиентом Аксапты
• пользовательские - для подключения через Корпоративный портал
• интеграционные - для хостинга определенных сервисов
• интеграционные - для хостинга еще каких-либо сервисов
• пакетные - для, допустим, разноски розницы
• пакетные - для, допустим, сводного планирования
• пакетные - для еще каких нужд

При этом в каждой группе обычно используется более-менее явно выраженное подмножество функционала приложения, подчас слабо пересекающееся с другими группами. А еще эти группы характеризуются разной чувствительностью к перезапускам и простоям и разными периодами времени, наиболее подходящими для перезапуска и обслуживания. Пользовательские АОСы обычно можно произвольно перезапускать в нерабочее время (скажем, с 18:00 до 9:00 следующего дня), а пакетные АОСы сводного планирования, напротив, предпочтительнее перезапускать днем. В целом пакетники обычно можно произвольно перезапускать в течение суток, но при условии, что запущенные пакетные задания успели отработать. Прерывать выполняющиеся пакетные задания обычно не очень хорошо, а ждать "парада планет", когда на всех пакетниках завершатся текущие выполняемые задания, можно подчас очень долго. Интеграционные АОСы вообще должны иметь как можно меньшее время простоя, потому что такие простои зачастую приводят к отказу в обслуживании в связанных системах. К примеру, интернет-магазин может замечательно работать автономно от Аксапты, но оплата заказа подарочным сертификатом может завершиться в нем неуспешно из-за невозможности проверить и изменить в online статус подарочного сертификата в Аксапте.
При обновлении рабочего приложения, как правило, переносится функционал, который влияет на одну-две-три группы АОСов с т.з. используемых подмножеств функционала приложения, но очень редко - на все группы сразу. Да, может, это нельзя в каждом случае математически точно обосновать, но из опыта поддержки того или иного приложения обычно это достаточно очевидно. И вот наиболее удобным был бы способ обновления рабочего приложения, который позволял бы разнести во времени перезапуск различных групп АОСов. Скажем, online-интеграциям через WCF-сервисы может быть без разницы, что обновились какие-то формочки для Windows-клиента Аксапты, а АОСам разноски розницы - без разницы, что обновилась логика сводного планирования. Но штатного варианта по сути выполнять две разные версии приложения на разных группах АОСов, к сожалению, нет.