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

[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