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

zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

С августа начались работы по уходу с Мф с таргет датой конец 2021. Я естественно вовлечен как ДБ2 ДБА. Настраиваивал Oracle Transparent Gatewaya (OTG), и начал работать с Oracle GoldenGate.
По идее мог бы послать все это далеко и надолго. Мог бы вынудить нанять другого ДБ2 ДБА (мне и кроме ДБ2 есть чем заниматься, да и достаточно дел с ДБ2 без участия в миграции на Оракл). Кроме того ситуация такова что в пиковые, дневные часы зачастую ЦПУ 100% загружен и в связи с тем что этот майнфрайм уже не поддерживается ИБМ повысить его производительность не предтавляется возможным я мог бы настойчив и убедительно предложить не делать миграцию в эти часы пиковой нагрузки, т.е. согнать их дела на ночные часы и в выходные.
Но я решил иначе. Я решил всячески содействовать успешной миграции баз даных с майнфрайм на Оракл, и нахожу для этого возможности. Но пока оказывается что дело вовсе не в возможностях МФ, а в слабости инфраструктуры Оракл. Оракл на который идет миграция в данный момент находится в Azure и представляет собой виртуальный Linux сервер с 8 корами и 32 GB RAM. В августе и сентябре они совершили подвиг и мигрировали одну базу данных размером промерно 500 ГБ за 5 дней (100 часов) с их слов. Было много проблем которые можно было решить, но те кто работает на стороне Оракл никак не могли понять что нужно сделать для этого. Я же был занят имплементацией нового МФ под другое приложение (а также попытакми попасть на шоу Последний Герой на ТВ3, ну и котедж с катером зазимовывал, строил бейсмент).
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

С GoldenGate тоже интересная история. Я установил этот продукт на стороне ДБ2 (две недели назад), сконфигурировал EXTRACT and PUMP, убедился что изменения накапливаются в трайл файле. На стороне Оракла пока конь не валялся. У Оракл ДБА (а их два на миграции задействовано, один на OTG, второй на GoldenGate) нет времени и он ждет курсов по GoldenGate и эксперта из Оракл в помощь. Реально будем начинать в середине декабря.
User avatar
Komissar
Уже с Приветом
Posts: 65198
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

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

Post by Komissar »

где-то с середины 2021 будешь безработный?
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Komissar wrote: 29 Nov 2020 00:08 где-то с середины 2021 будешь безработный?
Нет. Думаю что до семидесяти лет, если захочу, я продержусь без напряжения.

P.S. Вообще то я уже достиг и пенсионный возраст и условие нашего корпоративного пенсионного плана для полной, заработанной пенсии. Так что безработным мне уже не быть. Но я мог бы и другую работу на МФ поискать. Не думаю что есть молодежь способная меня перебить на МФ по спектру моих знаний и опыта.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

40Gb за 12 часов. DBA, который ждет курсов и эксперта по ораклу в помощь. чувствуется профессионализм команды. что бы получить такие скорости нужно одним потоком читать по одной записи и фигачить инсерт + комит на каждую запись.
azure продает vCpu, т.е. пенсионер так и продолжает путать cores с threads.

зы. в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.
deev_a_v
Уже с Приветом
Posts: 4660
Joined: 07 Apr 2018 15:16

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

Post by deev_a_v »

Зато из первых рук узнаем изнанку канадского социализма
jekasa
Posts: 8
Joined: 19 Oct 2009 11:12

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

Post by jekasa »

zVlad wrote: 28 Nov 2020 17:43 С августа начались работы по уходу с Мф с таргет датой конец 2021. Я естественно вовлечен как ДБ2 ДБА. Настраиваивал Oracle Transparent Gatewaya (OTG), и начал работать с Oracle GoldenGate.
По идее мог бы послать все это далеко и надолго. Мог бы вынудить нанять другого ДБ2 ДБА (мне и кроме ДБ2 есть чем заниматься, да и достаточно дел с ДБ2 без участия в миграции на Оракл). Кроме того ситуация такова что в пиковые, дневные часы зачастую ЦПУ 100% загружен и в связи с тем что этот майнфрайм уже не поддерживается ИБМ повысить его производительность не предтавляется возможным я мог бы настойчив и убедительно предложить не делать миграцию в эти часы пиковой нагрузки, т.е. согнать их дела на ночные часы и в выходные.
Но я решил иначе. Я решил всячески содействовать успешной миграции баз даных с майнфрайм на Оракл, и нахожу для этого возможности. Но пока оказывается что дело вовсе не в возможностях МФ, а в слабости инфраструктуры Оракл. Оракл на который идет миграция в данный момент находится в Azure и представляет собой виртуальный Linux сервер с 8 корами и 32 GB RAM. В августе и сентябре они совершили подвиг и мигрировали одну базу данных размером промерно 500 ГБ за 5 дней (100 часов) с их слов. Было много проблем которые можно было решить, но те кто работает на стороне Оракл никак не могли понять что нужно сделать для этого. Я же был занят имплементацией нового МФ под другое приложение (а также попытакми попасть на шоу Последний Герой на ТВ3, ну и котедж с катером зазимовывал, строил бейсмент).
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

С GoldenGate тоже интересная история. Я установил этот продукт на стороне ДБ2 (две недели назад), сконфигурировал EXTRACT and PUMP, убедился что изменения накапливаются в трайл файле. На стороне Оракла пока конь не валялся. У Оракл ДБА (а их два на миграции задействовано, один на OTG, второй на GoldenGate) нет времени и он ждет курсов по GoldenGate и эксперта из Оракл в помощь. Реально будем начинать в середине декабря.
вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов, но, процесс как говориться пошел ....
я уже молчку сколько стоит nvme сейчас.... гиганты обманули всех опять....

Про всякие тредпипперы я думаю начинать даже и не стоит.... :crazy:
voyager3
Уже с Приветом
Posts: 1951
Joined: 11 Mar 2015 01:12

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

Post by voyager3 »

iDesperado wrote: 29 Nov 2020 12:38 40Gb за 12 часов. DBA, который ждет курсов и эксперта по ораклу в помощь. чувствуется профессионализм команды. что бы получить такие скорости нужно одним потоком читать по одной записи и фигачить инсерт + комит на каждую запись.
azure продает vCpu, т.е. пенсионер так и продолжает путать cores с threads.

зы. в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.
Аж в Канаду захотелось.
User avatar
Komissar
Уже с Приветом
Posts: 65198
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

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

Post by Komissar »

jekasa wrote: 30 Nov 2020 01:51
Про всякие тредпипперы я думаю начинать даже и не стоит.... :crazy:
это новое кожно-венерическое заболевание? 8O
alex_127
Уже с Приветом
Posts: 7723
Joined: 29 Mar 2000 10:01
Location: Kirkland,WA

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

Post by alex_127 »

jekasa wrote: 30 Nov 2020 01:51
zVlad wrote: 28 Nov 2020 17:43 В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре.
вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов,
ну вот как не работает - так амазон хоть он и азур... обидно, дааа?
jekasa
Posts: 8
Joined: 19 Oct 2009 11:12

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

Post by jekasa »

Komissar wrote: 30 Nov 2020 02:16
jekasa wrote: 30 Nov 2020 01:51
Про всякие тредпипперы я думаю начинать даже и не стоит.... :crazy:
это новое кожно-венерическое заболевание? 8O
нет, это наследники эпика с 64 ядрами и 128 потоками только подешевле и в серверном шасси с IPMI. Ну а что... дешего и сердито :umnik1:
jekasa
Posts: 8
Joined: 19 Oct 2009 11:12

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

Post by jekasa »

alex_127 wrote: 30 Nov 2020 06:06
jekasa wrote: 30 Nov 2020 01:51
zVlad wrote: 28 Nov 2020 17:43 В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре.
вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов,
ну вот как не работает - так амазон хоть он и азур... обидно, дааа?
дорогой он нынче этот азур с амазоном. мощности растут пропрорционально с ценами.
я как слышу билд на ночь ставить в один поток, потому что план такой, то начинаю тихоньку одуревать
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

jekasa wrote: 30 Nov 2020 01:51
zVlad wrote: 28 Nov 2020 17:43 ...
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

....
вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов, но, процесс как говориться пошел ....
я уже молчку сколько стоит nvme сейчас.... гиганты обманули всех опять....

Про всякие тредпипперы я думаю начинать даже и не стоит.... :crazy:
МФ с которго уходят имеет 4 ядра (с ограниченной производительностью, в 3.5 раза меньше чем неограниченная на 4 ядрах), 32 GB и на нем стоят все инстансы приложения - Production, Dev. QA, Training, Sandbox, etc.. И это не только базы данных, но и аппсервра, batch processing, replication, и другое.

P.S. Недавно я делал рефреш QA и Dev с Production. QA полноразмерная Production и Dev та часть которую мигрировали в Azure 5 дней (100 часов, как они говорят, календарно они бодались месяца два). Делался рефреш по схеме UNLOAD/FTP/LOAD, и заняло это у меня 2 дня - суббота и воскресенье. Та часть что мигрировали в Azure прошла по этой схеме за 4 часа. 44 часа ушло на то что в Azure еще и не пытались мигрировать, начнем в середине декабря. Тогда обещают какие-то другие сервера закупить, "оптимизированные под ДБ", но я как-то слабо верю что это сильно ускорит процесс.
У них проблема еще в том что на Оракл стороне Unicode, и им приходится все транслировать из SBCS. Насколько это трудоемко я не знаю, а все уверения что этого делать не надо, наш клиент не будет использовать иероглифы уперлись в то что это requirement (certification) новой версии приклада. Попахивает непрофессионализмом, причем дремучим..
Palych
Уже с Приветом
Posts: 13975
Joined: 16 Jan 2001 10:01

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

Post by Palych »

iDesperado wrote: 29 Nov 2020 12:38 в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.
Думаю именно поэтому миграция займёт лет 10.
И закончится тем, что всё останется как было.
Причина чисто психологическая: грамотные не-МФ спецы за это дело не возьмутся, их и не наймут.
А грамотные мейнфреймщики на каждый сих будут заявлять что эти ваши писюки в принципе не способны решать такие сложные задачи (как перевод символов из одной кодировки в другую).
Год-другой срача - и всё переедет на Z20.
Oleg Co
Уже с Приветом
Posts: 7911
Joined: 19 May 2008 22:10
Location: BY->DEU->SFBA

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

Post by Oleg Co »

zVlad унд майнкамп.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Palych wrote: 01 Dec 2020 06:18 .... миграция займёт лет 10.
И закончится тем, что всё останется как было.
Причина чисто психологическая: грамотные не-МФ спецы за это дело не возьмутся, их и не наймут.
А грамотные мейнфреймщики на каждый сих будут заявлять что эти ваши писюки в принципе не способны решать такие сложные задачи (как перевод символов из одной кодировки в другую).
Год-другой срача - и всё переедет на Z20.
Палыч, ты не внимательно читаешь то что написано выше:
...Я решил всячески содействовать успешной миграции баз даных с майнфрайм на Оракл, и нахожу для этого возможности. ..
Експерта по Оракл уже подтягивают, но он вряд ли чем то будет полезен на стороне МФ. У меня и без него хватит чтобы решить любые проблемы на МФ, хотя мне этим заниматься и противно и по загрузке без этой миграции не следовало бы. Я это делаю строго в овертайме, строго по личной инициативе. И лучше меня, в нашей ситуации, этого не сделал бы бы никто.
Вам, ребята, остается запастись попкорном и следить за моими донесениями. Ерничать, умничать и прогнозы строить у вас пока плохо получается и пользы никакой. Вот если бы кто-то из вас имел опыт с GoldenGate и мог бы что-нибудь полезное сказать начинающему, вот это было бы по товарищески. Все мы таки на Привете одна коммюнити.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

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

Post by mskmel »

Не совсем ясно зачем OTG при наличии GG. GG сам по себе умеет делать первоначальное копирование.
GG простой как палка продукт, с весьма архаичным синтаксисом. По начальной загрузке https://docs.oracle.com/en/middleware/g ... -load.html

40ГБ за 12.5 часов больше похоже на конвертацию видео, а не перекладывание данных с места на место. Конвертация в юникод это не задача. Может канал слабый?
С ДБ2 не мигрировал, но с того чего мигрировал слабое место почти всегда канал, редко IO источника.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

mskmel wrote: 04 Dec 2020 21:49 Не совсем ясно зачем OTG при наличии GG. GG сам по себе умеет делать первоначальное копирование.
GG простой как палка продукт, с весьма архаичным синтаксисом. По начальной загрузке https://docs.oracle.com/en/middleware/g ... -load.html

40ГБ за 12.5 часов больше похоже на конвертацию видео, а не перекладывание данных с места на место. Конвертация в юникод это не задача. Может канал слабый?
С ДБ2 не мигрировал, но с того чего мигрировал слабое место почти всегда канал, редко IO источника.
Спасибо, добрый человек.

OTG было прописано в инструкции по миграции от вендора. И в принципе я не вижу ничего плохого в OTG за исключением того что с нашим обьемом данных и полученными результатами тестирования варинат OTG не видится приемлемым по времени. Поэтому решили использовать репликацию.
В принципе у нас всегда была и есть репликация из ДБ2 в MS SQL - IBM InfoSphere Data Replication, и этот продукт способен реплицировать в Oracle, но наши манагеры (они очень "умные") решили не ходить протоптаными путями, им подавай что-нибудь неизвестное. Поэтому собственно появился GG на горизонте.

Я использую pdf версию Administrator's Guide version 11. Это пробная, бесплатная версия, но идут переговоры и закупка у Оракла официальной версии, может это будет версия 19, может нет, зависит от версии нашего ДБ2, которая очень старая на сегодня.
У GG есть разные варианты начальной загрузки, в том числе внешняя, т.е. с тем же OTG, если нам удастся его ускорить.

Если бы дело было в канале то я думаю Оракл сервер не упирался бы в ЦПУ. Юникод, конечно, не проблема. Скорее всего у них там каждая запись коммитится, и возможно это можно поправить. Я подкину им эту идейку на неделе.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Неэластичные системы пихать в AWS дорого. Хотя по сравнению с мэйнфреймами может быть и дешевле
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Dmitry67 wrote: 07 Dec 2020 14:19 Неэластичные системы пихать в AWS дорого. Хотя по сравнению с мэйнфреймами может быть и дешевле
В мире нет систем эластичнее мэйнфрэймов. Они же самые гибкие, самые масшатбируемые и многое другое "самые-самые" (без кавычек).

Мы уходим с МФ по каким угодно причинам только не цена, при том что я всегда говорил и говорю своим что мы используем наши МФ не более чем наполовину несмотря на то что в пиковые часы бывает 100% CPU busy. Но после нескольких, недавних мер по повышению производительности, а также устранении бага в одном из приложений удаленно достающем ДБ2, и это стало крайне редко.

Причины ухода следущие:

- Желание клиента избавиться он своих Data Centre's. Под эту причину Windows/Linux servers пачками переводятся в Azure. МФ тоже можно было бы перевести в IBM Cloud, или "облоко" тех компаний что продолжают использовать МФ и принимают таких как наш клиент, пожелавших превратиться в бомжей. Это при том что много лет заявлялось о том что атомной энергетике подходят только МФ, и что ИТ для атомной энергетики может быть только private. Все это успешно похерено.

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

Уже ясно и очевидно что на платформе Oracle/Linux в Azure нас ждум большие приключения и трудности. В какие деньги это выльется пока тоже не известно. Наши Oracle DBA с ужасом ждут появления моей базы данных на Оракле и они уже зондирует меня на предмет не хочу ли я продолжить быть ДБА для ныне ДБ2-шной базы данных в Оракле. Дело в том что их штат увеличивать не будут, а я уходить тоже пока не собираюсь.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Спасибо.за подробный ответ. Да, любая миграция это боль.

Единственное что, под словом "эластичность" сейчас подразумевается вполне определенная вещь, у одиноких мейнфреймов ее нет.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Dmitry67 wrote: 07 Dec 2020 19:05 Спасибо.за подробный ответ. Да, любая миграция это боль.

Единственное что, под словом "эластичность" сейчас подразумевается вполне определенная вещь, у одиноких мейнфреймов ее нет.
Например?
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

В течение минут увеличить ресурсы в сотни или тысячи раз. То, что у вас сервер работает на 10% загрузки и доплатив за лицензии вы можете получить в 10 раз больше эластичностью не является. За пределы своего сервера Вы не выйдете.

Разумеется, эластичные решения требуют особой архитектуры - не монолит, возможность работать на сотнях похожих серверов в параллель.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Сейчас был на конфколе по поводу DR exercise проходивший в субботу с приложением на МФ, которое тоже должны уйти в следущем году. Это микроскопическое приложение давно должное быть снесно, но по каким-то причинам до сих пор занимающее целый МФ (благо хоть что это МФ - DR site для большого приложения о котором речь в этой теме идет.
Так вот говорилось о том что видимо это последний раз мы делаем этот DR test, и манагер этого упражния высказался в том роде что по его мнению МФ самый, как оно сказал, manageable компонент наряду с понятными другими. Этот манагер ни бум бум в МФ и других платформах, он просто организует многих людей с разными платформами когда такие упражнения проводятся, но он всегда говорил и вот опять повторяет что с его колокольни МФ самый самый.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Dmitry67 wrote: 07 Dec 2020 19:18 В течение минут увеличить ресурсы в сотни или тысячи раз. То, что у вас сервер работает на 10% загрузки и доплатив за лицензии вы можете получить в 10 раз больше эластичностью не является. За пределы своего сервера Вы не выйдете.

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

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

В-третьих, на МФ есть конфигурации когда производительность подстраивается под потребность, т.е. может не только увеличиваться, причем абсолютно автоматически, но и уменьшаться когда потребность изчезает.

Где эта Ваша эластичность в вышеприведенном мной примере с 12.5 часами мигрироивания таблицы в 37.5 ГБ? А ведь это Azure.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

За минуту может и не надо, а вот когда веб приложение нужно смаштабировать от скажем тысячи пользователей в час, до тысячи пользователей в секунду, вот это оно и есть.
Not everyone believes what I believe but my beliefs do not require them to.

Return to “Вопросы и новости IT”