Мы уходим с майнфрайм.

[Мальчик-Одуванчик]

На МФ отказов не бувает под любой нагрузкой. Это тестируется в IBM. А какие отказы, интересно, Вы симулируете?

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

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

[Palych]

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

если был нормой, творчество этих людей не выкинули бы на свалку истории. в том числе и с МФ.

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

[zVlad]

На МФ отказов не бувает под любой нагрузкой. Это тестируется в IBM. А какие отказы, интересно, Вы симулируете?

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

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

Я Вас понимаю. Мне приходилось иметь дело с приложениями на Java и я много могу сказать, но скажу меньше - формат форумa не предполагает долгих речей.
Есть у нас приложение, работающее на сервере в контакте с DB2 на МФ, прямом контакте. И вот когда МФ нагружен тем о чем я писал выше (но может быть и по другой причине. Я это оставляю не доказаным достоверно) то это приложение начинает "бомбиыь" конекциями. Количество одновременных активных коннекций, которое обычно не выходит за пару десятков начинает превышать число 200 - йето условный максимум, свыше которого запросы на присоедение ставятся в очередь.
Пару месяцев назад это же приложение в подобных условиях достигало другого предела - 1000 неактивных коннекций. Тогда вендор заявил о баге и пофиксал его. Эта проблема ушла, проблема с неконтролируемым ростом активных осталась. Я вижу это из данных мониторинга, сообщаю - никакой реакции. Будь[ это в рамках МФ я бы уже докопался, но это на серверах.
Отказов БД на МФ - DB2 не было никогда у нас (был один, лет 17 назад, из-за бага. Был устранен с помощью IBM за пару-тройку дней). Потеря связи, особенно после перевода серверов в Azure - обычное явление, сегодня репликация рухнула из-за этого. Решение - перрезапуск репликации и самосинхронизация. Можно легко автоматизировать, но из-за редкости этого остается неавтоматизированно. Возможно из-за Azure придется автоматизировать.

[zVlad]

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

если был нормой, творчество этих людей не выкинули бы на свалку истории. в том числе и с МФ.

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

Никто ничего не выкидывает. То на что пытаемся перенести приложение с МФ есть в точности тоже самое переписанное нa Java с COBOL. Модель данных та же (косметические изменения не в счет), алгоритмы те же, вендор тот же. Программы дописанные нашими программерами на COBOL уже полгода перетряхиваются и подготавливаются для переписывания один-к-одному в Java. Смысл?!
На Ассемблер на МФ програм нет в этом приложении, но COBOL все равно гораздо эффективнее любой Java.
Причины ухода с МФ просты как виноград - вендор не в состоянии поддерживать приклад на разных платформах. Привлекалово вендора (из их же презентанции- мы даем решение на бесплатных (Open source - WildFly), но в тоже время дорогой Oracle в качестве БД и дорогой GoldenGate для миграции получается).

[zVlad]

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

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zIIP. Если коротко с Java на МФ сейчас все в шооколаде.

[Мальчик-Одуванчик]

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zip. Если коротко с Java на МФ сейчас все в шооколаде.

Вот поэтому поведение java-приложения может отлтчаться просто потому что движок пишут разные команды.

[iDesperado]

Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

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

типичная история. вместо того что бы накропать скриптик и активировть виртуалки на несколько нужных отладке часов вы сожгли пол года. а могли на оплатить как 2% от того компа.

[Мальчик-Одуванчик]

Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

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

типичная история. вместо того что бы накропать скриптик и активировть виртуалки на несколько нужных отладке часов вы сожгли пол года. а могли на оплатить как 2% от того компа.

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

[iDesperado]

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

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

[liamkin]

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

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zIIP. Если коротко с Java на МФ сейчас все в шооколаде.

Когда мы в 90-х начинали Яву, на писюганах, тоже был IBM JDK и Sun JDK. IBM Ява 1.1.7 забарывала Сановскую, там были опциешки полезные, например размер стэка для трэда, он должен умещаться в кэше проца - быть 256к или меньше. И ИБМ Ява видимо была написана прямее. В-общем мы ею пользовались. Сан конечно потом догнал, появились и там эти опции и оптимизации. Но сам факт!

[zVlad]

.....

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

Наш проект перехода приостановлен из-за перерасхода денег в том числе на Azure. А мы еще в самом начале, на уровне sandbox.

Кроме того, наши "архитекторы" закладывают QA размером в Production. И это будет не временно, для стрестеста, а постоянно. Два Production size в Azure! А к Production еще понадобится DR & Business Continuity. 4 раза по Production.
Каким он будет Production в Azure никто пока не занает, даже идей ни у кого нет. С чего-нибудь конечно начнут, но как он поплывет - загадка без ответа.

Я предлагал развернуть новую версию приложения на одном из наших МФ что есть безусловно возможно на том же Linux который они таргетируют в Azure. Причем для Linux версии мощность МФ была бы ровно в три раза больше чем та что имеется для версии не под Линух. И потом можно было в более четким пониманием какие же надо ресурсы перенестись в Azure. Этот вариант был оставлен без внимания. Значит будем гадать на кофейной гуще.

[iDesperado]

Я предлагал развернуть новую версию приложения на одном из наших МФ что есть безусловно возможно на том же Linux который они таргетируют в Azure. Причем для Linux версии мощность МФ была бы ровно в три раза больше чем та что имеется для версии не под Линух. И потом можно было в более четким пониманием какие же надо ресурсы перенестись в Azure. Этот вариант был оставлен без внимания. Значит будем гадать на кофейной гуще.

виртуалка D16 на 16 vcpu, 64Gb ram и 2Tb ssd в регионе канада стоит $817 в месяц, нужно быть полным неадекватом, что бы рассматривать вариант с МФ, который за активацию 64Gb ram затребует десятки тысяч долларов, еще несколько тысяч за ziip.
за пол года D16 виртулка сожжет $5k, ни один вменяемый манагер не будет искать путей эконмить на такой позиции. что за бюджет у проекта если $5k имеют в нем видимую долю ?

[Мальчик-Одуванчик]

те кто в теме так с облаками не работают. так работают корпорации, которым сложно свои датацентры поддерживать. вам же видимо было выгоднее хостинг снять, там ресурсы минимум в трое дешевле.

У нас разные клиенты. Некоторые хотят быть модными и им вынь да подай облако.

[zVlad]

Миграция в Оракл с GoldenGate уперлась в офигенно медленный и в тоже время офигенно ресурсоемкий процесс извлечения данных из таблицы с LOB колонками. Времена на сравнительно небольшие об'емы просто ужасные. Экстраполяция показывает что нам нужны месяца чтобы всю таблицу перебросить таким образом.
Я знаю что там не так и знаю как это исправить, но надо переписывать extract программу. Не сильно, но надо.

[Flash-04]

А что вы там храните в таких колонках, если не секрет?