mskmel wrote: ↑27 Sep 2017 02:43
zVlad wrote: ↑27 Sep 2017 01:08
А вот это очень просто. Исходите из того что Вам не нужно будет, да это и не реально, перенести все сотни в один момент. Далее, Вы может очень грубо, приблизительно (в этом Вам могут помочь специалисты ИБМ без всяких тестов. Достаточно сообщить на каких мощностях Ваши сотни скачут сейчас) прикинуть мощность МФ. Берете модель в которую падает расчитаная мощность и просите активировать минимальную мощность. Начинаете переносить виртуальные машины, поодиночке или группами, отслеживая загрузку МФ и по мере надобности просите ИБМ активировать больше и больше ресурсов.
А что если, допустим, в процессе переноса выяснится, что надо еще один МФ "
естественно с прайстэгом в миллионы долларов"? И что он не "тянет" то, что может сделать половинка рэка Oracle Exalogic c 704 cores стоимостью "всего" в $600к? Сдавать его назад в trade in, списав на безвозвратные потери труд инженеров?
Вот, пусть и старый, но вполне так научный документ:
https://www.intel.com/content/dam/doc/w ... -paper.pdf
z13 топовый это 110,000MIPS, да можно поставить акселераторы, но они сами же себе в ногу выстрелили не сказав это производительность только CP или с ускорителями. Скорость самих ускорителей тоже не ясна.
"Performance tests of an 8-core x86 has shown in excess of 2150 mainframe MIPS equivalent rating.", стоит признать что дока очень старая, х86 за это время стал
сильно быстрее. Но будем консервативны и ленивы, 3200MIPS per 8 cores or 400MIPS\core. Т.е. надо 287 ядер, в очень популярных сейчас 22 cores x 2 sockets это меньше 7 серверов. Т.е. надо даже не половинку рэка, а 1/4 с приличным запасом. Она вообще стоит 370к, при этом exalogic не самая оптимальная по цене на MIPS железка.
Если в терминах Cloud - 74 Instances х 4 cores\28GB RAM стоят ~15k\mo или 180к\год. Опять "миллионы долларов" не выходит. И все это без up-front затрат, надо - купил, не надо отдал. На сдачу чтобы протестировать своё приложение - даже звонить никому не надо.
Миф о том что Linux не работает при загрузке 90% - миф. Да, с ростом количества сокетов всё хуже и хуже (МФ не исключение), но на 2х сокетных машинках всё прилично. Да и надо их всего несколько юнитов, чтобы целый шкаф мейнфрейма заменить.
Таких методичек что Вы приводите я прочитал десятки. Конкретно эту можно дальше "Executive summary" не читать потому что уже в нем даются ложные и ошибочные утверждения. Например, "inflexible mainframe servers", и "new processor-intensive workload on 1 or 2 processor z10 BC....".
Использование только одного показателя производительности МФ - MIPS это настолько приближенные результаты может дать что воспользовавшийся такой методой пользователь скорее всего попадет пальцем в небо.
Не вдаваясь в детали я поделюсь лишь одним впечатлением от этой и ей подобных методичек. Все они делают одну и ту же, принципиальную ошибку. Они смотрят на МФ теми же глазами какими смотрят на х86 сервер, и думают о МФ теми же мозгами какими думают о серверах на x86. А это не одно и тоже.
Опять же стараясь оставатся в разумных рамках обьема рассуждений, я хотел бы сегодня поделиться новой для меня мыслью - МФ это сервер серверов серверов (см. ниже в примере) или иначе - МФ это data center (последнее я уже здесь озвучивал не раз). MF не одиночный сервер, выполняющий одиночную нагрузку (методичкa о которой мы говорим явно не учитывало это обстоятельство, наоборот, исходит из того что МФ используется также как сакжем "1.6 GHz Intel Itanium Dual-Core processor 9100 Series").
Те кто считают что МФ такой же сервер как "9100 Series", кто так подходят к задаче переноса работы либо с МФ на x86 либо наоборот с x86 на MF обязательно потерпят фиаско в первом случае будут вынуждены существенно увеличивать мощности "9100 Series" во втором случае их остановит price tag того что они насчитают должен бы быть МФ.
Небольшое упражение с использованием примерa из методички применительно к конфигурации Мф у меня на работе. Из Example 1 в методичке следует что наш MF (~1000 MIPS) может быть заменен на
HP Integrity rx86404p 8c.
Что мы имеем на этом нашем МФ:
- две партиции с zOS, DB2, CICS/Cobol и другое в каждой:
- первая партиция - это продакшн системa ERP class OLTP приложения одного из крупнейших производителей электроэнергии Северной Америки с примерно 10 000 employees. Это приложение состоит из серверов бизнес (не только DB) транзакций (5 серверов в одной zOS) и базы данных ~ 4TB, которaя реплицируется on-line со стороны этого МФ в MS SQL . Нагрузка с явными пиками в рабочие дни дневные часы, до обеда и после. В эти пики загрузка CPU доходит do 100%. Среднее время выполнения транзакций меньше 1 сек (это предмет контроля в SLA). Ночью и в выходные МФ практически простаивает. Пользователь работает в режиме 24*7, и любой не плановый останов системы это ЧП с пенальти для нас.
- во второй партиции полный набор Dev's, QA, Training, Sandbox экземпляров этого же ERP class приложения с базами данных (всего 7 БД такой же структуры как и Prod) обновляемыми по данным перодически полностью (QA) и частично (Dev, Training, Sandbox) из Prod DB. У каждого экземпляра приложения свой сервер бизнес транзакций (всего 7 серверов).
Кроме перечисленного этот МФ является DR site для второго нашего MФ(где другое приложение выполняется), т.е в случае потери второго МФ работа с него переносится на этот без изменения его конфигурации (CPU, RAM теже остаются).
Я спокойно поставлю свой дом (соседний сейчас продается за C$1 290 000) против собачей будки что
"HP Integrity rx86404p 8c" с тем что делает наш МФ не справится, и пять таких HP не справятся тоже. Десять может быть и справятся, но это будет стоить дороже (если учесть все расходы, а не только цену одного HP помноженную на десять, как обычно поступают мои оппоненты здесь), особенно если учесть что наш МФ в целом загружен меньше чем на 40% и, следовательно, способен выполнять дополнительные работы, и не мало.
