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

[Vadik]

Цитата:

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

Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.

Не только в синхронизацию. В CIL, который надо пересобирать если кастомизации проектами переносить, в AIF/сервисы/SSRS которые будут недоступны пока CIL перестраивается или могут "не подняться" если его целиком не перестроить. Это и AOS-ы живущие на разной бизнес-логике и DDL вроде CREATE INDEX который при работающих пользователях запускается

В принципе, у нас есть клиент 24x7 "от Гуама до Панамы", вот что он делает
a) начинаем заранее drain-ить часть AOS-ов с клиентскими сессиями
b) перенос изменений проектом на выделенный AOS, автоматическая синхронизация
c) CIL
d) перезапуск выделенного AOS-а (сбрасываем метки)
e) перезапуск рабочих AOS-ов по мере освобождения от клиентских сессий с параллельным drain-ом работающих

Формально - у них полного 100% даунтайма нет. По факту - есть ограниченная недоступность на время перестройки CIL (те же 20 минут), вероятность блокировок и "отвала" батчей (особенно это любит делать workflow во время обновления CIL). При инкрементальном обновлении CIL есть ненулевая вероятность отвала SSRS, тогда все бегают с круглыми глазами и все заканчивается часовым простоем с полной компиляцией и CIL. Ну и собственно вопрос - а оно того стоит, и может все-таки выделить 45-60 минут в неделю и сделать все спокойно и без экстрима ?

P.S. В семерке пока что "хуже" (в Вашей постановке задачи) - там простой обязателен и пока что дольше если сравнивать с 2012

[Ivanhoe]

Цитата:

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

Не только в синхронизацию. В CIL, который надо пересобирать если кастомизации проектами переносить, в AIF/сервисы/SSRS которые будут недоступны пока CIL перестраивается или могут "не подняться" если его целиком не перестроить. Это и AOS-ы живущие на разной бизнес-логике и DDL вроде CREATE INDEX который при работающих пользователях запускается

Два варианта:
1. отдельная БД с полным CIL, восстановление БД модели на Prod, перезапуск выделенного АОС, на нем же синхронизация, перезапуск АОСов.
2. перенос проектами на выделенный АОС, синхронизация, CIL (инкр / иногда полный), перезапуск по очереди всех АОСов.

Из неудобств - обеспечить не падаемость пакетов - более менее возможно; минимальная синхронизация - вот тут решений особо нет.

[Vadik]

Цитата:

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

отдельная БД с полным CIL, восстановление БД модели на Prod.

Я надеюсь речь все же про импорт modelstore, а не восстановление БД - а то нам и рабочие подключения AOS-ов к model отстреливать придется, и все HA сценарии (database mirroring / availability groups) идут лесом
Так что (1) - не вариант

Цитата:

Из неудобств - обеспечить не падаемость пакетов - более менее возможно

Да, с дополнительными телодвижениями.
Я это все к чему - может, с мегакорпорацией можно как-то договориться об обеспечении полноценного даунтайма, скажем раз в неделю ? Минут в 45 можно уложиться

[macklakov]

Цитата:

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

Я это все к чему - может, с мегакорпорацией можно как-то договориться об обеспечении полноценного даунтайма, скажем раз в неделю ? Минут в 45 можно уложиться

Можно-то оно можно, если деваться некуда. Только надо понимать что это может стоить мега-корпорации несколько десятков тысяч за каждый простой. Издержки от 50 простоев в год легко могут переваливать за миллион.
Разумо было бы выделять регионы в отдельные инстансы. Тогда ночной простой в Бразилии никак не скажется на работе китайского продразделения.

[Ivanhoe]

Цитата:

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

Я надеюсь речь все же про импорт modelstore, а не восстановление БД - а то нам и рабочие подключения AOS-ов к model отстреливать придется, и все HA сценарии (database mirroring / availability groups) идут лесом
Так что (1) - не вариант

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

[Logger]

Цитата:

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

Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.

Попробовал уменьшить нижнюю границу "от 20 минут". Пока неуспешно.
https://www.sql.ru/forum/1314237/ind...ror-kak-oboyti

Может есть идеи?

[Logger]

Цитата:

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

Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.

Кое-что появилось

Ax 2012 ускорение синхронизации базы в 3-5 раз.

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

[Logger]

Интересно, а как в других ерп эта проблема решается?
Если тот же сап крутится на sql, то синхронизация займет схожее время. Или нет?

[ax_mct]

Цитата:

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

Интересно, а как в других ерп эта проблема решается?
Если тот же сап крутится на sql, то синхронизация займет схожее время. Или нет?

https://blogs.sap.com/2015/03/11/min...-of-an-update/

In principle two approaches are used:

• Clone
• In place

...
The clone approach needs a full copy of the productive system but it is very flexible regarding maintenance activities.
...
nZDT (near Zero Downtime Service)
The nZDT is a service offered by SAP. It is a customer specific procedure that is technically a clone approach.
When using the nZDT service, the maintenance is performed on the clone of the production system. All changes are recorded and transferred to the clone after the maintenance tasks are completed. During the final downtime, only a few activities are executed, including a switch of the production to the new system (clone).
....
ABAP applications, especially the ERP system with DB sizes in range of several terabytes. Therefore the SAP standard tools use the in place approach for ABAP systems in general to minimize the planned downtime. The in place approach uses the DB and needs a minimum of additional Hardware. The downtime minimization capabilities of SUM, e.g. nZDM, use a separate DB schema (shadow).

[Ivanhoe]

Поменяем мега корпорацию на нормальный интернет-магазин или b2b с кучей проверок при создании заказов. Ну вот не понимают клиенты, почему нужен почти час простоя. Днем офис работает, по ночам склад.

[Vadik]

Цитата:

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

Поменяем мега корпорацию на нормальный интернет-магазин

Работал я в одном нормальном интернет магазине (>10K заказов в день). Так там не было синхронной интеграции сайта с AX. И у сайта интеграция (асинхронная) строилась так, что не требовала постоянной доступности AX и прочих внутренних приложений. Люди, которые все это строили, знали толк в извращениях интернет-торговле

Цитата:

или b2b с кучей проверок при создании заказов

Ну, B2B тоже в принципе не предполагает наличия людей, нажимающих кнопку на одной стороне и ждущих когда она "отожмется" на другой, так что за нормально сделанный B2B я спокоен

Цитата:

Если не нужна длинная синхронизация

Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)

Цитата:

А HA не так уж прям и часто в полный рост настраивают

Часто-часто, особенно мегакорпорпорации На самом деле если будете слишком сильно проталкивать схему с восстановлением model из бэкапа, наживете себе кровников в лице БД админов и они же Вас в случае чего сделают крайним - а оно Вам надо ? Импорт modelstore во временную схему делает в итоге то же самое, а переключение схем работает быстрее чем restore database

[Ivanhoe]

Цитата:

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

Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

[sukhanchik]

Цитата:

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

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

А сделать это не на выделенном AOS, а в БД, с опцией ONLINE у команды CREATE INDEX? (я говорю конечно же про SQL Server)
Ну т.е. запустили и оно себе работает. Понятное дело - ДБА должны выбрать момент запуска скрипта, но это уже второй вопрос - формально простоя не будет. А АХ уже при обновлении подумает, что этот индекс уже создан.

Глобальная идея состоит в том, чтобы все длительные процедуры, которые выполняются при синхронизации вынести на момент до начала обновления.
Максимальный вариант - это "закат солнца вручную", т.е. выполнение всех процедур, которая делает синхронизация - заранее, до начала обновления. Но обычно хватает "золотой середины", а именно построение долгостроящихся индексов, которые как правило всем известны и для каждой компании можно составить свой список наиболее объемных таблиц

[trud]

Цитата:

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

А сделать это не на выделенном AOS, а в БД, с опцией ONLINE у команды CREATE INDEX? (я говорю конечно же про SQL Server)
Ну т.е. запустили и оно себе работает. Понятное дело - ДБА должны выбрать момент запуска скрипта, но это уже второй вопрос - формально простоя не будет. А АХ уже при обновлении подумает, что этот индекс уже создан.

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

Цитата:

ONLINE = ON
В начале операции совмещаемая блокировка (S) удерживается на исходном объекте в течение очень короткого времени. В конце операции на источнике на короткое время удерживается совмещаемая блокировка (S), если создается некластеризованный индекс

[Vadik]

Цитата:

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

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

А что конкретно синхронизуем? ALTER TABLE ADD COLUMN NOT NULL DEFAULT() на SQL 2012 (если мне не изменяет память) EE и выше делается влет (на уровне метаданных). Да, ценник на EE редакцию конский но так оно почти всегда бывает при хотелках enterprise уровня. С индексами - да, возни и накладок больше
Либо - плановая остановка на обслуживание

[Ivanhoe]

Для совсем нагруженных систем других вариантов, кроме синхронизации скриптами прямо на SQL не видно, это понятно.

Но в рамках темы хочется понять, как штатными средствами максимально сократить downtime?

[gl00mie]

Цитата:

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

в рамках темы хочется понять, как штатными средствами максимально сократить downtime?

Использовать SSD-диски под базу моделей и AOS'ы, чтобы последние перезапускались как можно быстрее