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

[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-айты.

[zVlad]

....

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

У нас storage не внутренняя, но и не SAN. У нас storage обьединяет достоинства обоих этих подходов и лишена их недостатков.

[zVlad]

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

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

Второй, основной. ДР сайт является еще одним сайтом с приложением. Так как вся инсталляция делается стандартно и апгрейды тоже то по сути он просто - еще один инстанс........

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

Первый вариант - единственный реальный для произвольных приложений. Второй и третий - для тех что написаны по опредеенным стандартам......

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

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

....

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

Серьезные организации имеют как минимум два сайта, два дата центре, удаленных друг от друга хотя бы на десятки километров. Production сервера распределяются между ними равномерно, примерно, и ко всем этим сайтам у бизнеса имеетстя "прямой" канал.
Subnet у сайтов может быть разный, но в случает ДР может быть использован re-direction потeрянного subnet-a на оставшийся в живых. Именно это у нас и предполагается на случай DR.

Я поначалу был сторонником второго варианта - живой стандбы сервер с репликацией в реально времени (я никак не могу понять Вашу привязанность к снапшотам с интервалами связи). У нас кстати БД с МФ реплицируется в MS SQL и в Oracle базы, и эта репликация непрерывная, но не синхронная естественно.

С тестированием DR в системе с 3-рд парти конекциями мне кажется Вы несколько драматизуруете. Если используется первый Ваш вариант (или иначе наш вариант) то с какой стати может возникнуть сомнения если основной сайт работал нормально и мы в случае ДР используем те же IP аддреса? По сути дела наша репликация в MS SQL это аналог 3-рд парти и мы ее естесвенно не тестируем поскольку нет никаких сомнений что она будет работать точно также в DR ситуации поскольку в нашем варианте концепсии DR это будет та же самая (байт в байт) система и приложения в ней. Именно поэтому, кмк, у нас был выбран вариант репликации всего дискового пространства Production чтобы в реальной ДР ситуации не чесать репу до дыры. Хотя конечно это избыточный вариант - есть много изменений которыми в случае DR можне принебречь - диски страничного обмена, диски временных файлов batch jobs, может даже какие-то логи. Но у нас так решили и я не разу не слышал чтобы наша репликация для ДР сильно отстает. Я не стораге ман, но думаю до меня бы такое опасение было бы доведено.

Еще раз подчеркиваю что из-за уникальных возможностей MF нам не нужны ресурсы на DR MF пока не наступит сам ДР. А при его наступлении мы легко и быстро перераспределяем ресурсы (в случае memory) и добавляем ресурсы (в случае CPU) и все это делается динамически не останавливая работы тех Production что на DR сайте нормально выполняются. С нашими двумя сайтами у нас один другому является ДР сайт и МФ работают постоянно в полную свою мощность. На других платформах так сделать не возможно. На интел Вы будете вынуждены иметь простаивающие ресурсы. Вы скажете VMWare, облако. До определенной степени может быть, но если цапациты не имеет резерва то два сайта на одном задавят Ваше облако 100%, если Вы не будете иметь резрв или не сможете его оперативно добавить.

[StrangerR]

....

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

У нас storage не внутренняя, но и не SAN. У нас storage обьединяет достоинства обоих этих подходов и лишена их недостатков.

Если внешняя то это SAN, независимо от того каким протоколом она подключена. Хотя оно и неважно, давно уже размылась граница между SAN и DAS.

[StrangerR]

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

Все правильно. Эта задача простейшая, так как допускает ручную настройку при катастрофе первичного центра и не нуждается в быстром переключении назад (после взрыва ядерной бомбы один пепел остался). Настолько то ДР мы уже много лет обеспечиваем там, где обещали. Плюс уже заодно используем ДР инстанс для тестирования, благо заодно и сама ДР система проверяется.

НО хочется то большего. Хочется симметричный DR чтобы можно было без накладок переключать нагрузку между двумя центрами, например для проведения замены железа. И вот тут все много сложнее. Первая то задача давно решена (причем без миллионных затрат) а вот вторая... Или вот у нас было - ураган Санди, и решали переключаться или нет - если бы переключились то потом назад бы довольно долго переезжали и работало бы все довольно криво 2 суток, не переключаться - как понять долбанулся там ДС или нет. Мы не переключались, там затопило центр в Ньйю Йорке но не в Нью Джерси, в итоге несколько часов все таки система не была доступна (впрочем там агентам было не до неё). Был бы симметричный ДР - просто перекючились бы на сайт2 а потом назад... но мы к сожалению назад быстро не можем, потому что это ДР а не HA. Поэтому хочетс скрестить ДР с HA.

С тестированием DR в системе с 3-рд парти конекциями мне кажется Вы несколько драматизуруете. Если используется первый Ваш вариант (или иначе наш вариант) то с какой стати может возникнуть сомнения если основной сайт работал нормально и мы в случае ДР используем те же IP аддреса?

1) Внешние или внутренние IP?
2) Если мы собираемся перетащить внешние IP на DR сайт в случае катастрофы, то оно конечно многое упрощает, но (1) как это протестировать, если адреса то заняты на первичном сайте, и (2) даже и при том, а IPSEC с 3-d парти с DR сайта как делать и тестировать? Если как у нас - адреса разные и IPSEC есть потому что он юзается для стейджинга - то как например проверить что ДР сайт сможет послать файлы для печати и что там все скрипты правильно среплицировались. А еще вылезает обратная проблема - при тестировании не послать СЛУЧАЙНО что то ненужное (история из жизни - где то девелоперы ляпнулись вводя новый дата фид, и в конфигурации по умолчанию вышла синтаксическая ошибка.. при реплицировании конфигурация не поправилась а осталась продакшен, и тестовый сайт украл файлы ему не предназначенные...)

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

обавляем ресурсы (в случае CPU) и все это делается динамически не останавливая работы тех Production что на DR сайте нормально выполняются. С нашими двумя сайтами у нас один другому является ДР сайт и МФ работают постоянно в полную свою мощность. На других платформах так сделать не возможно. На интел Вы будете вынуждены иметь простаивающие ресурсы.

Ну да, конечно... На 1 ресурс продакшена приходится примерно 5 таких же ресурсов в стейджинге девелопменте и прочим. И во первых ДР сам по себе юзается для тестирования (благо оно ничему не мешает) во вторых в случае чего оставовим како нибудь _десятый ночной билд седьмого бранча пятого проекта кастомера XXX_ и все. У нас суммарных ресурсов больше чем на вашей MФ примерно в 20 раз, при том что общий бюджет много меньше, поэтому такой проблемы которая идет от бедности МФ - в интел облаках давным давно уже нету. Сервер о 12 коровах 10 ТБ райд10 дисков и 256 гигах памяти стоит около $10K и поставляется за 1 сутки, если уж что совсем так нужно стало... но реально ресурсов в сети столько что наскрести еще немного на разницу _ДР в тестовом режиме - ДР в прод режиме_ никаикх проблем нет и платить никаким ИБМ тоже не придется.

Именно поэтому, кмк, у нас был выбран вариант репликации всего дискового пространства Production чтобы в реальной ДР ситуации не чесать репу до дыры.

Что однозначно говорит о небольшом размере вашего приложения. Что и позволяет крутить его на МФ, большое просто не влезло бы.

[zVlad]

....

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

У нас storage не внутренняя, но и не SAN. У нас storage обьединяет достоинства обоих этих подходов и лишена их недостатков.

Если внешняя то это SAN, независимо от того каким протоколом она подключена. Хотя оно и неважно, давно уже размылась граница между SAN и DAS.

Вы зря так самоуверенны - ведь Вы не знаете о дисках МФ ничего кроме того что это внешнее устройство на магнитных дисках. Я знаю это потому сравнивать интеллектуальные диски с тупым хранилищем блоков данных да еще с доступом к ним по сети может только не знающий предмет разговора человек.

[zVlad]

Что однозначно говорит о небольшом размере вашего приложения. Что и позволяет крутить его на МФ, большое просто не влезло бы.

С точки зрения уровня мощности нашего МФ в диапазоне мощностей МФ вообще это так - наше приложения не велико, хотя могу Вам сказать что среди фирм юзающих это приложение мы самые крупные пользователи. Более того наш МФ будучи одним из маломощных в семействе тянет не только Production, но и все непродакшн instances, при этом не-продакшн имеют 20% shares и только 3 CPU из 5. А Вы кстати уверяете что:

.... На 1 ресурс продакшена приходится примерно 5 таких же ресурсов в стейджинге девелопменте и прочим......

Но это все так сказать относительные оценки в рамках одной платформы. Я докладывал здесь уже не раз что один из наших клиентов имеющий такое же приложение ушел с МФ в половину менее мощном чем тот клиента которуй еще не ушел ушел сначала на группу Юникс сервер с общим количеством CPU - 40 и памятью - 760 GB. И это была первая их конфигурация, сейчас они ее обновили и раза в полтора увеличили. Причем приложение и под МФ и под Юникс пидхется одним и тем же разработчиком.

Глядя на эти относительные параметры я бы не стал называть наше приложение маленьким.

Скоро наш клиент начнет сваливать с МФ и начнется планирование capacity. Я буду держать Вас в курсе что будут брать чтобы заменить наш скромный (по меркам МФ) МФ. Я также надеюсь доработать до того как переход полностью состоится и надеюсь услышать впечатления. После чего уйду на пенсию.

[zVlad]

... Поэтому хочетс скрестить ДР с HA.

....

На МФ это уже давно есть. Я приводил ссылку на GDPS. Вы ее естественно даже не открывали.

[StrangerR]

... Поэтому хочетс скрестить ДР с HA.

....

На МФ это уже давно есть. Я приводил ссылку на GDPS. Вы ее естественно даже не открывали.

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

Про сторейдж не надо, САН он и есть САН, тем паче давно уже сетью может быть и Инфинибанд, и SAS и даже PCIx тоже ведь сеть (и есть уже виртуальные IO системы работающие по ним). И то что у вас стоит это тоже SAN, другое дело что возможно так как у Оракла на ексадате, на сторейдж могли какие то операции перевесить.

Главная беда МФ уже понятна. В целом система неплохая. Но... дико - просто дико - дорогая. И поэтому она проиграла уже _системам на базе массовых PC серверов_ а сегодня еще и _облакам на базе массовых РС серверов_. Потому что как бы там не было качественно сделано все в МФ, а зная ИБМ я не сомневаюсь что там все куда продуманнее чем в МС или в Линуксах (в которых вечно приходится собирать паззлы) и даже сравнивая с VMware - но если 1 гигабайт памяти обходится вам в $1000 или $1500, а 2 терабайта дисковой памяти - в $2000, то все, финита ля комедия. Как со сцены сошли Тандемы, так сходят и МФ-ы. Потому что мне добавление в облака 2 сокетов по 6 чистых кор в каждом + 256 гигов памяти + 8 терабайтов обойдется в $10K, а владельлцу Мейнфрейма тысяч в 300. И он чертыхаясь и вспоминая про прелести МФ но все равно уползет на Линуксы, МС-ы, ВМваре и прочее, не такое красивое... но вместо 300К он заплатит 10К а на остальные 290 программисты все допинают.

[Dmitry67]

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

ой спасибо! а я то и не знал!!!
вы все так буквально понимаете?

[Dmitry67]

У нас кстати БД с МФ реплицируется в MS SQL и в Oracle базы, и эта репликация непрерывная, но не синхронная естественно.

А вот с этого момента поподробнее
Зачем вам эти реплики? Зачем зоопарк? чтобы с ними работали front ends? У front ends нет connectivity к МФ? МФ не тянет нагрузку от front ends?
Впрочем, не буду гадать, дождусь вашего ответа

[iDesperado]

Спасибо что обьяснили Диме что операции чтения которых гораздоо больше чем записей в OLTP приложениях не реплицируются. Таким образом про "реплицировать весь IO" это ошибка, увы, распространенная у нас.

снова все та же проблема, Влад не улавливает контекста разговора и не может понять, что понятие репликации с чтением никак не соотноститься.
Влад, вы уже выяснили, что вы перепутали в истории о 10 cpu ? вы cpu с lcpu (threads) поппутали, ведь верно ?

[zVlad]

... Поэтому хочетс скрестить ДР с HA.

....

На МФ это уже давно есть. Я приводил ссылку на GDPS. Вы ее естественно даже не открывали.

Да нет этого у вас....

Я никогда и не говорил что это (GDPS) есть у нас, в нашей конторе. Но как технология IBM MF, используемая в других конторах это есть и это именно то о чем Вы мечтаете - HA and DR.

[zVlad]

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

ой спасибо! а я то и не знал!!!
вы все так буквально понимаете?

Тогда не пишите так буквально - весь IO. Отделяйте вовремя мух от котлет и Вам станет легче общаться с другими.

[zVlad]

У нас кстати БД с МФ реплицируется в MS SQL и в Oracle базы, и эта репликация непрерывная, но не синхронная естественно.

А вот с этого момента поподробнее
Зачем вам эти реплики? Зачем зоопарк? чтобы с ними работали front ends? У front ends нет connectivity к МФ? МФ не тянет нагрузку от front ends?
Впрочем, не буду гадать, дождусь вашего ответа

Золотые слова: "не буду гадать", а то Вас уже понесло куда-то.

Сказите Дима я говорил здесь что application servera у нас сидят в той же системе где и DB2 DB приложения? Говорил. А что такое application servera? Это и есть большая часть front enda. Oставшаяся часть - это написовать картинку на экране юзера.

Реплика в MS SQL и Oracle (в начале 2000-х был только Oracle) делается для ad-hoc репортов что давно уже могло бы работать на прямую с DB2 на MF, но по инерции остается такой какую сляпали много-многоо лет назад, еще до того как я был нанят, а это уже почти 15 лет назад.

Кроме ad-hoc репортов у нас есть куча мелких и мельчайших приложений которые вместо того что-бы обращаться напрямую в DB2 на MF идут в реплику на MS SQL, просто им (программистам кто писал эти приложения) так проще. Один из этих программистов из Минска, тоже Владимир, я с ним обсуждал тему прямого доступа, но он тупит. Есть несколько приложений которые достают данные из DB2 на MF напрямую и ничегоо страшного.

Подитожу, а то Вы опять гадать будете: и БД и App Severa приложения нашего сидят на MF (на одном MF). Пользовательские транзакции этого приложения ранятся на MF и только результаты идут в клиентские части чтобы нарисовать картинку и поговорить с юзером. Это MF приложение основное для нашего клиента и много дополнительных не-MF приложений базируются на данных в DB2 на MF, обращаясь к ней напрямую или через реплику, поставляют свои данные в эту центральную БД.

[zVlad]

Вот к вопросу о размере нашего прииложения на МФ. Это статистика пятиминутных интервалов работы в DB2.

Если кого заинтересует я могу пояснить смысл непонятных столбцов.

Code: Select all

+                                  Dlk/  In-DB2  In-DB2  In-DB2           GetP/
+   Time  Thrds Commit Abort DML   TOut  Elap Tm CPU Tm  Wait Tm  Getpage RIO
+   ----- ----- ------ ----- ----- ----  ------- ------- -------  ------- -----
: _ 09:55  4353   4499   141 1809K    0   1254.2  413.81   648.0   22820K  .2K
: _ 09:50  4422   4527   183 1675K    0   1602.3  390.94  1054.3   19589K 72.0
: _ 09:45  5174   5250   205 1989K    0   2568.7  475.24  1530.0   23901K 91.2
: _ 09:40  5021   5063   198 1875K    0   1545.8  413.56   884.3   20401K 97.5
: _ 09:35  4445   4533   170 1868K    2   2232.2  424.91  1497.4   21367K 90.8
: _ 09:30  4066   4123   166 1699K    2   1881.4  436.70  1246.4   22150K  .1K
: _ 09:25  4003   4096   125 1716K    0   1461.8  384.61   934.3   19324K 91.8
: _ 09:20  3920   4047   128 1739K    1   1002.2  344.39   548.7   18974K  .2K
: _ 09:15  3849   3975   124 1724K    1   1257.1  382.34   737.7   20288K  .1K
: _ 09:10  4062   4184   133 1527K    0   1109.1  358.02   653.8   19551K  .1K
: _ 09:05  3408   3497   130 1487K   14   5394.3 2717.05  1743.6  170059K  .7K