Перенос доработок на 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 простоев в год легко могут переваливать за миллион.
Разумо было бы выделять регионы в отдельные инстансы. Тогда ночной простой в Бразилии никак не скажется на работе китайского продразделения.

[Vadik]

Цитата:

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

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

План прекрасный, мне очень нравится. Надо только посчитать стоимость дополнительных лицензий, железа и поддержки множественных инстансов, учесть невозможность (да, по-прежнему) работы в "честном" 24x7 в каждом регионе с 100% доступностью и в общем экономию (или потери) нашей сферической мегакорпорации на этих и прочих мелких нюансах. Но в целом - план прекрасный

[macklakov]

Цитата:

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

учесть невозможность (да, по-прежнему) работы в "честном" 24x7 в каждом регионе с 100% доступностью

Где говорилось что в каждом? 100% 24x7 нужен когда у вас в системе разные регионы, от Бельгии и Бразилии в системе. Это значит что единственный зазор когда пользователей не слишком много, это ночь с субботы на воскресенье. А когда в инстансе лишь несколько близко расположенных стран, то почти все выходные можно что-то делать, ибо количество активных пользователей будет в пределах нескольких десятков.

[Vadik]

Цитата:

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

Где говорилось что в каждом?

Не нравится " в каждом" ? Не вопрос - множественные инстансы "честного" 24x7 ни в одном регионе не обеспечивают, так уж система устроена. Так лучше?

Цитата:

100% 24x7 нужен когда у вас в системе разные регионы, от Бельгии и Бразилии в системе

Вы со складом, с которого 24х7 отгрузка идет судя по всему еще не сталкивались

Цитата:

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

Если у мегакорпорации рабочий график 5 дней в неделю, у нее нет проблемы минимизации времени на обслуживание - отмотайте ветку на начало и посмотрите о чем собственно она

[Ivanhoe]

Цитата:

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

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

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