Миф: как IBM победил БЭСМ

[zVlad]

DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.

Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.

зеркало зеркалу рознь. Синхронный стендбай базы данных - средство High Availiability а также средство zero downtime при мейнтенсах.

Ну вот мы уже про HA вспомнили. Скоро, говоря, о всего лишь DR вспомним все технологии IT не важные с точки зренуя юзера.

Раз уж заговорили о HA, напомню, на MF это нажевается Sysplex и предполагает совместную работу нескольких систем (на разных бох-ах в одном датацентре или на одном бохе- в разных LPAR, в любом случае обединенных с помощью CF - Coupling Facility: http://en.wikipedia.org/wiki/Coupling_Facility Это,чтобы Вам было понятнее, нечто вроде Oracle RAC, но сделаное по настоящему). Все системы SysPlex используют одни и теже диски. Любую систему можно остановить на maintenance.

Ваша HA со standby, kоторый стоит и ничего не делает кроме как принимает данные с primary, это детский лепет по сравнению с Sysplex, где все системы работают на результат. Sysplex это одномременно и клaстер, т.е. получении мощности где одного сервера недостаточно, но опять сделано по-настоящему в отличии от клaстер с Shared Nothing.

Асинхронное, скорее всего снапшотное, зеркало сторейджа - средство защиты от потери сайта или вашей супер МейнФреймы. Оно всегда будет отставать, будет копировать кучу ненужного. Обычно делают комбинированное решение
- приложения, сами ОС и прочее защищают так как у вас, реплицированием на уровне SAN системы. Потому как они меняются редко и мало.
- данные (базу и файлы, особенно базу) реплицируют на уровне логическом, например базу - синхронным стендбаем. Ну или если репликация в другой город то асинхронным.

Потаря сайта амбивалентна к любым платформам, поэтому выделять специально МФ здесь не обязательно.

Production, если это действительно Production не должен изменяться без надобности, для это есть другие сайты. На Production изменяются только рабочие данные в БД. Диски со страничным обменом и для временных ресурсов БД могут быть исключены из такого реплицирования (у нас реплицуреется все и никто никогда в этом проблем не видил, может они и есть но до меня это не доходило).
Говоря о такой репликации мы говорил именно о репликации "в другой город" для DR.

А так... сторейдж она реплицирует снапшоты, или же все транзакции вынуждены идти по каналу связи то есть он должен быть таким же как ширина вашего IO. В итоге (1) реплика отстает потому что снапшотная, и (2) реплицируется куча никому не нужного хлама, заодно. Нет, это хорошая стратегия, полная репликация на уровне SAN, но (1) очень дорогая по ресурсам, (2) вечно будет отставать то есть применима именно как DR _все пропало дата центр утонул_, и (3) если она не на VM то её нелегко тестировать. Обычно это применяют именно как DR между удаленными сайтами. Мы рассматривали такую возможность, но пока плюнули, обошлись rsync + DB репликацией + как я сказал - локально синхронное зеркало базы, удаленно репликация асинхронная другими средствами. Репликация дисков серверов базы данных - ну вероятно прошла бы ели снапшот раз в 20 минут делать, но канал бы потребовался раз в 10 толще чем сейчас.

(Я про один только проект. Их много, в других может и дисковая репликация встретиться. Но я пока как то ей не вдохновился.)

Про хлам я уже сказал - это детский лепет, извините. Конечно будет отставание и его не надо пытаться устранять - это же ДР. Может это решение и дорого, но в определенных отрослях с этим мирятся так же как с мифической дороговизной МФ. В итоге получается, кстати, что в совокупности все затрат на ИТ доля МФ не такая уж и драматическая.

Не знаю может в Ваших возможностях для тестирования обязательно нужна ВМ, наверное нужна, или физижеский нужен сервер. У нас на МФ это делается на раз-два-три:

1. Исходное состояние. MF в другом городе ранит другую Production используя все ресурсы: CPU и memory. Этот МФ может иметь меньше MIPS i меньше CPUs чем MF в этом городе. В его конфигурации имеется LPAR для DR сайта в неактивно состоянии, т.е. никаких ресурсов не потребляет. Этот МФ имеет CBU records (Capacity BackUp).

2. Подготовка. Приходит время тестировать, или мы в самом деле потераыли сайт в "этом городе". Продуцтион систему в "другом городе" просят освободить n GB memory. Как только это завершается активизируют DR LPAR в освобожденных GB-ax. Активизируется CBU record добaвляя capacity - MF в "другом городе" становится мощее (в нашем случае примерно в сто раз).

3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать. Для Test DR используется свой IP address конечно, потому нормальная работа ведь продолжается. В случае настоящего DR IP конечно не меняется.

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

По завершению тестa DR LPAR деактивируется. Продуцтион системе отдают n GB и она на них расползается снова. CBU record сам деактивируется через 10 дней, или его можно убрать динамически. МФ в "другом городе" возвращется к своей обычной capacity за которую мы платим.

[iDesperado]

3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать

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

[zVlad]

Да нет, ну я преувеличиваю конечно. Я понимаю zVlad-а, который видит тот ужас что пишут в области _массового программирования_ и то что получается когда вместе лепим многоуровневый бутерброд (NetApp / VMWare / 100 хостов / 1000 VM под 10 операционками... а еще разные SAN и прочее вокруг, не считая нетаппов...) и сравнивает с чистой красивой архитектурой МФ. Я и сам вспоминаю код Алгола ГДР и кажется еще и Фортран ГДР был - чисто, красиво, по немецки аккуратно, без единой лишней запяток... а потом открываем что нибудь на жабе или C++ и ужасаемся...

Тем не менее, к сожалению, и МФ и _чистый красивый очень компактный код_ уходят в прошлоее. А на их место - сотня ПС серверов, тысяча индусских кодеров, и парочка грамотных архитекторов... Кстати, напоминает как ЕС вытеснила (точнее ИБМ) Бэсм - конечно бэсм была чистой красивой аккуратной, ЕС сборищем убожества, но ... функциональность важнее красоты...

Как то у Вас легко получается свалить в одну кучу разные вещи и найти в ней какую то общность. В данном случае собственно программирование и архитектуру ИТ замесили вместе. ИВМ МФ это действительно не бутерброд какие Вы видимо складываете из дешевых ингредиентов, которые чудом умудряются работать все вместе и давать результат. С точки же зрения программирования нет никакой разницы какая БД выполняет запросы и где она стоит и нет разницы где стоит WebSphere чтобы ранить Java (кстати Java может раниться и под "древним" CICS и не только Java но и Web Services тоже). Так что с точки зрения программирования МФ ничем не уступает Вашим бутербродам и даже превосходит их потому что не будерброд, из которого вечно наровит что нибудь выпасть когда его ешь.
Гладя назад в 60-е из сегодняшнего дня становится абсолютно ясно что БЭСМ не мог в принципе быть взят за основу того что мы называем МФ. Из-за слишком простой, если не сказать примитивной архитектуры - схема когда CPU непосредственно управляет молоточками АЦПУ не для большой многообразной нагрузки. Независимый канал это как раз то, что и БЭСМ- у пришлось бы осваивать чтобы хотя бы теоритически конкурировать с ИБМ МФ. А на самом деле гораздо больше. Если использовать Вашу же терминологию можно сказать что БЭСМ был чист до исчезновения. Вот он и исчез а ИБМ МФ в полном здравии и исчезать не собираются. В следующем году ИБМ наверняка что-нибудь новое выдадут.

P.S. Почитайте вот хотя бы в wiki о гетерогенных архитектурах на основе МФ:
http://en.m.wikipedia.org/wiki/IBM_zEnterprise_System

[StrangerR]

Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли. Место освободилось, и меня взяли в этот стартап. Это.было более 10 лет назад в Америке... так что для production dba опечатка в одну букву может быть концом карьеры )

А для этого есть полиси. Вы вот не поверите но у нас ДБА _не имеет права_ работать с продакшен базой. НЕ ИМЕЕТ. И никогда не работает.

Есть процедура. Любое изменение пишется в виде скрипта. Оформляется в виде патча. Патч прогоняется на тестовом инстансе, патч публикуется в чейндж рикевесте, прогоняется оператором на стейджинге, прогоняется оператором на продакшене.

И пусть ДБА хоть в 10 букв ошибется. Не будет НИЧЕГО. Ну грохнет он стейджинг, так все поматерятся, запустят скрипт refresh_instance_xxx.sh и через 10 часов все будет снова в порядке.

3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать. Для Test DR используется свой IP address конечно, потому нормальная работа ведь продолжается. В случае настоящего DR IP конечно не меняется.

Ну, если у вас это тестирование то мы так тестируеем ДР раз в две недели, потому что он используется для тестирования. Но это именно ТЕСТОВЫЙ режим. Не реальный. Потому что реально так ничего не оттестировать. Продакшен система посылает в Банк Оф Америка еженочно данные о списании денег. Как протестировать ДР на то что он будет это делать? Продакшен система проверяет рейт на реальном сайте, тестовая на тестовом, как проверить то что ДР сможет работать с реальным сайтом? Это тестовый режим ДР который тестирует его лишь наполовину. Знакомо, проходили уже, используем лет 5. Только вот на реальных ресурсах под ДР даже СПУ освобождать не приходится потому что на интел облаке ресурсов хватает и без того.

[StrangerR]

3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать

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

Да не успевают они ничего реплицировать. Это просто физически невозможно. Они реплицируют снапшоты, с дедупликацией, раз в один - два часа в лучшем случае. Никакой синхронной репликации или пусть даже асинхронной но полной там не происходит. Так как никаких каналов на оную не хватило бы.

[Easbayguy]

Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли. Место освободилось, и меня взяли в этот стартап. Это.было более 10 лет назад в Америке... так что для production dba опечатка в одну букву может быть концом карьеры )

А для этого есть полиси. Вы вот не поверите но у нас ДБА _не имеет права_ работать с продакшен базой. НЕ ИМЕЕТ. И никогда не работает.

Есть процедура. Любое изменение пишется в виде скрипта. Оформляется в виде патча. Патч прогоняется на тестовом инстансе, патч публикуется в чейндж рикевесте, прогоняется оператором на стейджинге, прогоняется оператором на продакшене.

И пусть ДБА хоть в 10 букв ошибется. Не будет НИЧЕГО. Ну грохнет он стейджинг, так все поматерятся, запустят скрипт refresh_instance_xxx.sh и через 10 часов все будет снова в порядке.

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

[zVlad]

....Ну, если у вас это тестирование то мы так тестируеем ДР раз в две недели, потому что он используется для тестирования.....

Я не устану повторять что Вы так ничего не поняли в DR. Вы просто не имели дело с DR другими словами.

[zVlad]

3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать

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

Да не успевают они ничего реплицировать. Это просто физически невозможно. Они реплицируют снапшоты, с дедупликацией, раз в один - два часа в лучшем случае. Никакой синхронной репликации или пусть даже асинхронной но полной там не происходит. Так как никаких каналов на оную не хватило бы.

<.....>

[StrangerR]

Влад, я с оными репликациями и кластерами работаю много лет, а первые кластеры имел аж на Бэсм-6. И концепцию ДР для компании всю писал и защищал. И если вы мне будете сказочки рассказывать, что ваш МФ успевает по каналу связи реплицировать ПОЛНОСТЬЮ например диски на которых живет нагруженная база данных, то позвольте вам не поверить - или там идет репликация снапшотов (что чаще всего и поддерживается провайдерами SAN систем) или там нагрузка невелика или пришлось покупать широкий канал и ставить в добавок апплаенсы или железки для дедупликации и работе по широким но далеким каналам связи.

Есть конечно разные решения и многие провайдеры SAN (тот же НетАпп) поддерживают репликацию (нетапп например поддерживает МетроКластер), но по жизни делать все это на уровне САН систем весьма стремно. Одна из причин хорошо известна - на этом уровне неизвестна ценность конкретного блока данных, и если тупо реплицировать например весь сайт, но один чудак распаковывающий внутри апп сервера 100 гиговый бэкап для последующего использования, подвесит репликацию на много часов (и в том числе забъет и репликацию важных объектов вроде баз данных). Хотя конечно, на сегодня стоимость каналов падает, их ширина растет, появляются хорошие дедупликаторы, и постепенно и такой подход становится возможным... в некоторых случаях. Но он не универсален. А то чт вы там про тестирование ДР рассказали, это не полное тестирование а частичное, я уже объяснил, почему так.

А про ДР вы как раз многого не поняли. Основная проблема почти всех ДР - это во первых _взаимодействие приложения со внешним миром_ (его довольно сложно обеспечивать на ДР сайте), во вторых, это переключение с ДР назад на праймари сайт (оно часто не выходит автоматом), в третьих - тестирование ДР в полноценном рабочем режиме (как протестировать те части, которые меняют объекты во ВНЕШНЕМ мире? Если полным переключением на ДР то должно обеспечиваться и обратное переключение и на время переключения первичный сайт должен сам стать ДР для вторичного. Так удается сделать весьма нечасто, и проще делать как у вас - недотестирование при котором ДР по сути просто работает в режиме стейджинга, не нанося ущерба внешнему миру но в итоге и не работая с ним).

[zVlad]

Влад, я с оными репликациями и кластерами работаю много лет, а первые кластеры имел аж на Бэсм-6. И концепцию ДР для компании всю писал и защищал. И если вы мне будете сказочки рассказывать, что ваш МФ успевает по каналу связи реплицировать ПОЛНОСТЬЮ например диски на которых живет нагруженная база данных, то позвольте вам не поверить - или там идет репликация снапшотов (что чаще всего и поддерживается провайдерами SAN систем) или там нагрузка невелика или пришлось покупать широкий канал и ставить в добавок апплаенсы или железки для дедупликации и работе по широким но далеким каналам связи.

Есть конечно разные решения и многие провайдеры SAN (тот же НетАпп) поддерживают репликацию (нетапп например поддерживает МетроКластер), но по жизни делать все это на уровне САН систем весьма стремно. Одна из причин хорошо известна - на этом уровне неизвестна ценность конкретного блока данных, и если тупо реплицировать например весь сайт, но один чудак распаковывающий внутри апп сервера 100 гиговый бэкап для последующего использования, подвесит репликацию на много часов (и в том числе забъет и репликацию важных объектов вроде баз данных). Хотя конечно, на сегодня стоимость каналов падает, их ширина растет, появляются хорошие дедупликаторы, и постепенно и такой подход становится возможным... в некоторых случаях. Но он не универсален. А то чт вы там про тестирование ДР рассказали, это не полное тестирование а частичное, я уже объяснил, почему так.

А про ДР вы как раз многого не поняли. Основная проблема почти всех ДР - это во первых _взаимодействие приложения со внешним миром_ (его довольно сложно обеспечивать на ДР сайте), во вторых, это переключение с ДР назад на праймари сайт (оно часто не выходит автоматом), в третьих - тестирование ДР в полноценном рабочем режиме (как протестировать те части, которые меняют объекты во ВНЕШНЕМ мире? Если полным переключением на ДР то должно обеспечиваться и обратное переключение и на время переключения первичный сайт должен сам стать ДР для вторичного. Так удается сделать весьма нечасто, и проще делать как у вас - недотестирование при котором ДР по сути просто работает в режиме стейджинга, не нанося ущерба внешнему миру но в итоге и не работая с ним).

Почему Вы решили что у нас SAN? Я где-нибудь об этом писал? Может Вы думаете что кроме того что Вам лично известно больше ничего в природе не существует.?

"это не полное тестирование а частичное" звучит как "нет, у тебя не закрытый, а открытый перелом". Так и хочется ответить: "золото брилианты". Обясните еще раз, я видимо пропустил это откровение, хотя читаю Вас болле менее полно.

То что Вы пишите про внешний мир, то естественно для внешного мира тест DR как бы не существуют и допускаются некоторые услoвности на время теста (в свете этих условностей можно сказать что наш DR test частичен, согласен). На тестовой системе работают только специально назначенные люди клиента, исключенные на время из реального процесса управления внешними обектами. Плановые отчеты в виде batch jobs выполняются в полном обьеме. После DR теста делается синхронизация данных с primary.

Кроме куска ИТ клиента на МФ восстанавлиются и другие критические куски ИТ клиента (на не-МФ платформах), некоторые из которых работают в связке с приложением на МФ, и эта связка тестируется тоже. Вот на этих кусках каждый ДР тест у нас спотыкается, не был исключением и последний тест неделю назад.

Я не упоминал, не думал что наши дебаты о DR зайдут так далеко, но у нас на DR сайте два комплекта дисков Production. Первый называется Secondary, а второй Business Continuity BCV). BCV мирорится с Secondary локально, они на одной дисковой подсистеме. DR test делается на BCV комплете, a Secondary продолжает получать изменения с Primary. Так сделано чтобы защититься от реального дизастера во время DR test и для других целей. Поэтому синхронизация BCV с Primary происходит не в виде полного удаленного копирования всех терабайтов (что взяло бы дни), а путем локального переливания (что берет часы).


У меня очень тыжелое впечатление от Вас и от iDesperado остается. Я конечно погоричился вчера, но такое впечатление что вы оба ничего не слышать ни видеть не хотите, даже думать не хотите. Не весь ввод-вывод на Primary ведет к репликации, а только изменения. Чтение составлят весьма приличный кусок работы и БД и апп серверов, и это не влечет никакх репликаций. На Production не может появиться чудак "распаковывающий внутри апп сервера 100 гиговый бэкап", на Production вообще ничего не может происходить не одобренное Change Control Management и то в определенном окне времени. В обычном режиме на Production могут работать только работники клиента и только используя программы написанные для них и прошедшие проверку, ну и я конечно . Все, больше никаких чудаков на Production быть не может.
Я никогда не слышал от наших дисковиком кокая у нас задержка на зеркале, может они тоже ей не интересуются. Канал у нас конечно широкий, от Bell-a, с гарантированной пропускной способностью, завтра постораюсь узнать параметры, если интересно.
Но вы ребята думайте в самом деле когда говорите "этого не может быть потому что этого не может быть никогда, потому что я в это не верю и все". Это глупо, не достойно вас. То что мы не в реале не оправдывает такое поведение тоже никак.

[zVlad]

Влад, я с оными репликациями и кластерами работаю много лет, а первые кластеры имел аж на Бэсм-6. И концепцию ДР для компании всю писал и защищал. ....

Раскажите как работает написанная Вами концепсия DR. Мне интересно.

[StrangerR]

Влад, я с оными репликациями и кластерами работаю много лет, а первые кластеры имел аж на Бэсм-6. И концепцию ДР для компании всю писал и защищал. ....

Раскажите как работает написанная Вами концепсия DR. Мне интересно.

(Какая разница САН у вас или внутренняя сторейдж?)

Есть 2 варианта или 3 варианта.

Первый как у вас. Реплицируем все на уровне VM или дисков. Можно даже Vmware DR использовать. Недостатков два
- если большие объемы изменений то ДР запросто отстанет или замучает каналы
- если приложение активно ходит к 3-d party то как это тестировать непонятно. Вероятно, проще всего просто переносить и IP адреса тоже (внешние и внутренние).
- я думал, не сделать ли так что и сетка внешняя пусть переезжает (благо BGP).

Второй, основной. ДР сайт является еще одним сайтом с приложением. Так как вся инсталляция делается стандартно и апгрейды тоже то по сути он просто - еще один инстанс. База и Доки реплицируются раз в 10 - 20 минут методом или через бэкап логов и их копированием на второй сайт (не в саму базу а на сервер бэкапов) или прямой репликацией (архив документов например). У ДР есть состояния

STOP -> INIT -> SYNC -> {TEST, PROD}

(Причем реплицирование данных идет всегда и даже если ДР стоит в режиме ТЕСТ его можно пересинхронизовать снова на текущий момент даже если первичный сайт упал).

В TEST он поднимается с конфигурацией _для тестирования_. Например все 3 парти в ТЕСТ стоят от стейджинга. Это основной режим, в нем он гоняется например каждый конец месяца (два зайца убиваем - и ДР проверяем и тестируем то что конец месяца не пришибет продакшен). В ПРОД он поднимается с конфигурацией _для продакшена_, это достигается тем что конфигурация состоит из 2 частей - одна общая а другая только для прода. Но там важно то что все конфигурится автоматом. Руками никто - никогда - ни один файл - не редактирует (кроме конфиг файлов и патчей).

Третий, который я хочу сделать на другом проекте - ДР вообще логическая часть продакшена. То ест ьпросто есть например 4 апп сервера. Добавляем еще 2 но делаем их стендбай, то есть по умолчанию они не включены. Аналогично база - делаем 3 зеркала, 2 синк и 1 асинк. Аналогично документы - делаем 2 копии. И делаем так что любой тир может работать с любым бэктиром. То есть так что можно переключить апп на ДР, можно переключить базу на ДР, можно переключит доки на ДР (да будет помедленнее если апп на первичном сайте а база на вторичном но жить будет). После чего становится легко переключать вперед и назад и 3 парти отлаживать просто - переключили ту часть что с ними работает на второй сайт и проверили, переключили обратно.

Первый вариант - единственный реальный для произвольных приложений. Второй и третий - для тех что написаны по опредеенным стандартам. Второй вовсю работает и используется но там есть где то 10 - 20 минут гап в данных и на ДР нельзя просто так перейти как на первичный сайт. Если сделаем третий то все станет очень просто (можно будет вообще первичный сайт выводить и вводить в работу), но он на MS SQL требует SQL 2012 или кучи извратов, и он требует добавить в конфигурацию приложения концепцию первичный и стендбай хост, что требует некоторых доделок.

Все там не так просто. В одном из проектов например - да, ДР можно сделать 1 или 2 методом. Но приложение работает с бизнес приложением у пользователя, по прямому каналу из основного дата центра где оно стоит. И толку его делать ДР в другом если там нету прямого канала да и у пользователя все стоит в первом дата центре - умрет так все вместе. Поэтому там все стоит в состоянии _сделать можно но когда у пользователя у самого появится ДР а те как мексиканцы, маньяны сплошные_.

И в большинстве случаев грабли лежат именно в -3d party interactions-, дата фиды, всякие запросы _проверить рейт данного консьюмера_ или _получить информацию о платежах_ или _послать файлы для печати и рассылки_ или что нибудь подобное. ТО есть онлайн работу переключить на ДР как два пальца. Но как ДР будет слать файлы для рассылки писем, если у принт компании прописаны ИП тех кто им шлет, и как это проверить если первичный сайт нельзя полностью выключить и нельзя слать с двух месте.. вечный вопрос (у кого то из 3 парти это легко а у кого то сложно). И этих 3 парти с десяток другой на каждый проект, и все разные.

То что Вы пишите про внешний мир, то естественно для внешного мира тест DR как бы не существуют и допускаются некоторые услoвности на время теста (в свете этих условностей можно сказать что наш DR test частичен, согласен). На тестовой системе работают только специально назначенные люди клиента, исключенные на время из реального процесса управления внешними обектами. Плановые отчеты в виде batch jobs выполняются в полном обьеме. После DR теста делается синхронизация данных с primary.

Ну во втором случае так и делается

drctl sync
drctl test
прогон джобов и тестов
drctl reinit
drctl sync

при этом рядом всегда есть копия данных даже когда сам DR в режиме тест. Никаких особо отличий с вами. Но ... это лишь один из несколких вариантов. А так все ДР приводят к примерно похожим решениям.

"этого не может быть потому что этого не может быть никогда, потому что я в это не верю и все".

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

И судя по стоимости памяти дисков и прочего, на вашем МФ попросту достаточно небольшие приложения крутятся. Которые КОГДА ТО были большими, но на сегодня уже можно считать small business и не более того, по масштабам. На что вам все тут и намекают. Показывая РЕАЛЬНЫЕ ресурсы в РЕАЛЬНЫХ облаках и продакшенах (2 терабайта опертивки и 100 терабайтов дисков, к примеру, для большого продакшена, мы до такого еще не дошли но кое какие пользователи по моему дошли).

[Dmitry67]

Влад, все очень просто: вы не можете реплицировать весь IO просто по чисто арифметическим причинам: локальный bandwidth к дискам на несколько порядков превышает bandwidth внешнего интернет канала.

[StrangerR]

Влад, все очень просто: вы не можете реплицировать весь IO просто по чисто арифметическим причинам: локальный bandwidth к дискам на несколько порядков превышает bandwidth внешнего интернет канала.

Ну в общем то не порядков. Речь то только про ЗАПИСИ да и потом - к дискам ну 4 гигабита, ну 8 в сумме (редко когда все нужны), канал может быть запросто 1 - 2 мегабита.

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

[zVlad]

Влад, все очень просто: вы не можете реплицировать весь IO просто по чисто арифметическим причинам: локальный bandwidth к дискам на несколько порядков превышает bandwidth внешнего интернет канала.

Ну в общем то не порядков. Речь то только про ЗАПИСИ да и потом - к дискам ну 4 гигабита, ну 8 в сумме (редко когда все нужны), канал может быть запросто 1 - 2 мегабита.

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

Спасибо что обьяснили Диме что операции чтения которых гораздоо больше чем записей в OLTP приложениях не реплицируются. Таким образом про "реплицировать весь IO" это ошибка, увы, распространенная у нас.
Кроме того явно упуслается из вида что в такой репликации используется компрессия, которая особо эффективна для массовых измений.
У нас репликация идет непрерывно. Никаких снапшотс, непрерывно. Я вообще не понимаю что Вы в этом имете в виду - чем снапшоты в репликациях на ДР сайт могут быть лучше чем непрерывный процесс? Зачем ждать если и так из-за дорогой операции можно отстать? Чтото тут у вас не логичность выпирает в рассуждениях.
Разнеры нашей апплиикации не GB-айты, a TB-айты.