Мы идем на z14.

User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

Re: Мы идем на z14.

Post by flip_flop »

Palych wrote: 30 Apr 2019 14:48 Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...
МФ нужно охранять, согласен. И технологические решения у него есть интересные. И входя в серверную комнату (хоть и очень редко), мечтаешь о МФ, тихом и прохладном.

И диктата единообразия нет, это фикция. По прежнему есть МФ. Есть спарки. АРМы есть уже в серверах. Да и х86 заметно развиваются и конкурентность проснулась, спасибо CEO AMD. И RISK-V как open source hardware двигается.

Но конкуренция имеет свои законы. Быстрее, выше, сильнее. Ничего личного, только бизнес и числа.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: Мы идем на z14.

Post by mskmel »

flip_flop wrote: 29 Apr 2019 20:05Lenovo's sixth generation System x3850 X6 mission critical server, which is based on Intel’s Xeon E7-4800 v4 and E7 8800 v4 processors, delivered five nines – 99.999%
Именно эта модель была, дохнут как мухи.

ЗЫЖ опять zVlad и господство z, каждые год-два :D
Palych
Уже с Приветом
Posts: 12958
Joined: 16 Jan 2001 10:01

Re: Мы идем на z14.

Post by Palych »

iDesperado wrote: 30 Apr 2019 16:50
Palych wrote: 30 Apr 2019 14:48 Тут как раз все понятно: не наняли настоящих спецов, из участников этой дискуссии.
Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...
не, это уже надо закапывать, так как выродилось из серьезной технологии в тупой культ насилующий неопытных пользователей мыши. посмотрите на Влада. знаний ноль, образование отсутствует напрочь. умудряется попутать core с cpu и vcpu, но верует. верует, что МФ "Нет, на четыре порядка" (c)
А адепты Intel/Windows/Java/Linux отличаются глубиной знаний, проникают мыслью в каждый регистр и инструкцию байт-кода?
И не являются ходячим кешем переполненного стека?
iDesperado
Уже с Приветом
Posts: 1201
Joined: 28 Nov 2008 17:50

Re: Мы идем на z14.

Post by iDesperado »

Palych wrote: 01 May 2019 03:07 А адепты Intel/Windows/Java/Linux отличаются глубиной знаний, проникают мыслью в каждый регистр и инструкцию байт-кода?
И не являются ходячим кешем переполненного стека?
каждый адепт Intel/Windows/Java/Linux получил среднее школьное образование. это уже дистанция в километры от Влада. школьное образование позволяет понимать что термин cpu надо смотреть в контексте, что бывают и виртуальные cpu, что перед cpu буквочки не для красоты утилиты выводят. мало того, многие из них не только в школе учились, но сталкивались с реальными компьютерами, видели, что чем больше памяти в компьютере тем меньше моргает лампочка hdd. у Влада ничего этого нет. с ним можно месяц рассуждать о hi-load oltp нагрузках и потом увидеть, что у него аж 700 iops на весь МФ.
User avatar
Flash-04
Уже с Приветом
Posts: 60596
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы идем на z14.

Post by Flash-04 »

не знаю что там у Влада, но вот тут IBM приводит циферки:
ftp://public.dhe.ibm.com/software/os/sy ... ads_v4.pdf

Up to 16 dedicated System Assist
Processors (SAPs)
 All I/O requests are offloaded to
SAPs
 16 SAPs can sustain up to 2.4M
IOPS*
 I/O subsystem bus speed of 8 GBps
 Number of SAPs increases from 4 to
16 according to system size
 Up to 160 physical FICON cards for
I/O transfers
 Up to 320 RISC processors (2 per
card)
 Up to 320 FICON channels (2 per
card)
 8 Gbps per link, 288 GB/Sec I/O
aggregate per zEC12
 IBM DS8800 Storage System
 Up to 440K IOPS capability

т.е. up to 440K IOPS.
Not everyone believes what I believe but my beliefs do not require them to.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

Re: Мы идем на z14.

Post by flip_flop »

Flash-04 wrote: 01 May 2019 19:19 не знаю что там у Влада, но вот тут IBM приводит циферки:
т.е. up to 440K IOPS.
Приятно иметь дело с циферками :)

В весьма скромных двухсокетных серверах от Supermicro : Up to 24 hot-swap NVMe (up to 16 million IOPS) Но это мелочь по сравнению с in memory processing. Вот timesten Oracle с использованием энергонезависимой памяти и новых процессоров где то раз в 7 увеличил TPS и преодолел рубеж в 1 миллион TPS : Average throughput = 1.16M TPS . Это без масштабирования. При масштабировании (timesten scale out) timesten говорит уже не о миллионах TPS, но о миллиардах.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Flash-04 wrote: 01 May 2019 19:19 не знаю что там у Влада, но вот тут IBM приводит циферки:
......
Цифирки от 2013 года. Поминается там zEC12. С тех пор были z13, и сейчас мы имеем z14.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Flash-04 wrote: 01 May 2019 19:19 не знаю что там у Влада, но вот тут IBM приводит циферки:
ftp://public.dhe.ibm.com/software/os/sy ... ads_v4.pdf

Up to 16 dedicated System Assist
Processors (SAPs)
 All I/O requests are offloaded to
SAPs
 16 SAPs can sustain up to 2.4M
IOPS*
 I/O subsystem bus speed of 8 GBps
 Number of SAPs increases from 4 to
16 according to system size
 Up to 160 physical FICON cards for
I/O transfers
 Up to 320 RISC processors (2 per
card)
 Up to 320 FICON channels (2 per
card)
 8 Gbps per link, 288 GB/Sec I/O
aggregate per zEC12
 IBM DS8800 Storage System
 Up to 440K IOPS capability

т.е. up to 440K IOPS.
Вот не люблю я числами размахивать и не советую. Во-первых, дали Вы шести летней давности данные, во-вторых, числовой маньяк :no: flip-flop ухватился за число и начал им размахивать не разобравшись с тех о чем это число говорит. Теперь объясняй ему что это число вовсе не про мэйнфрэйм.
iDesperado
Уже с Приветом
Posts: 1201
Joined: 28 Nov 2008 17:50

Re: Мы идем на z14.

Post by iDesperado »

Flash-04 wrote: 01 May 2019 19:19 не знаю что там у Влада, но вот тут IBM приводит циферки:
IBM DS8800 Storage System это просто полка. причем собранная для обычных платформ на обычных power6 процах.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

Re: Мы идем на z14.

Post by flip_flop »

zVlad wrote: 01 May 2019 20:46 Вот не люблю я числами размахивать и не советую. Во-первых, дали Вы шести летней давности данные, во-вторых, числовой маньяк :no: flip-flop ухватился за число и начал им размахивать не разобравшись с тех о чем это число говорит. Теперь объясняй ему что это число вовсе не про мэйнфрэйм.
Хе-хе, жив курилка, хорошо.

Я тоже не про сервер сам по себе говорил а про систему ввода-вывода на диски, которая используется в сервере. Так и для МФ можно поступать. Я думаю, что в z14 можно запросто добиться миллионов IOPS (увидел число 3). Но, для конечного пользователя эти внутренности не важны, ему нужен системный выходниой показатель - используя какие угодно внешние компоненты, какой максимальный показатель (IOPS например) можно выжать из конкретной системы (MF или сервер)? И тут приходят числовые маньяки (хе-хе, хорошее прозвище, спасибо).
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 01 May 2019 04:54
zVlad wrote: 30 Apr 2019 14:00 3. А можно спросить, мне интересно, почему там именно 8 узлов замутили? Были ли те узлы виртуальными, или это были физически отдельные сервера? Насколько линейно росла мощность с увеличением количества узлов?
Этот 8 узловый замутили для отказоустойчивости. Крутилась куча разных задач. Собран был на отдельных серверах от Интел . Только одна задача была распределена на 4 узла для масштабируемости. Остальным хватало по 1 серверу. Милисекунды никто не измерял, считали количество одновременных пользователей. Примерно 2 с половиной тысячи одновременно на кнопки жали.
Не знаю это только мне видится противоречие в сказаном Вами или кто еще видит. Поправьте если я ошибаюсь.
Сначала Вы объясняете что 8 узлов замутили для отказоустойчивости. Потом вдруг оказалось это нужно для масштабируемости. И наконец появились намеки на производительность как проблему для многоузловости.
И все таки. Это 8 узлов одного RAC, одной базы данных? Что значит кроме одной задачи им достаточно было одного сервера? Почему если максимум требовалось 4 узла сделали 8? Удвоили что ли тупо в предположении что все четыре одновременно накрыться могут.

Как не логично это выглядит, необоснованно.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

flip_flop wrote: 01 May 2019 20:57 .... И тут приходят числовые маньяки (хе-хе, хорошее прозвище, спасибо).
Наздоровье. Только ударяться в рассуждения о том что важно а что нет для конечного пользователя я не буду. Это ты можешь легко за него говорить, а я привык слушать конкретного пользователя в конкретной обстановке по конкретным проблемам, а не по абстрактным парамерам типа IOPS.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

Re: Мы идем на z14.

Post by flip_flop »

zVlad wrote: 01 May 2019 21:06
flip_flop wrote: 01 May 2019 20:57 .... И тут приходят числовые маньяки (хе-хе, хорошее прозвище, спасибо).
Наздоровье. Только ударяться в рассуждения о том что важно а что нет для конечного пользователя я не буду. Это ты можешь легко за него говорить, а я привык слушать конкретного пользователя в конкретной обстановке по конкретным проблемам, а не по абстрактным парамерам типа IOPS.
Какие же это абстрактные параметры? Вполне конкретные. Можно мерять. На основе совокупности таких параметров производительности, потреблеямой мощности, площади, RAS, пропускной способности IO и памяти, времени инсталляции и пр. покупатель и будет выбирать систему, имея в виду свою конкретную задачу. Более конкурентная система имеет большие шансы быть купленной, отсюда и прибыль и развитие. А как иначе?

--
числовой маньяк
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 02 May 2019 00:33
zVlad wrote: 01 May 2019 21:01
Lazy444 wrote: 01 May 2019 04:54
zVlad wrote: 30 Apr 2019 14:00 3. А можно спросить, мне интересно, почему там именно 8 узлов замутили? Были ли те узлы виртуальными, или это были физически отдельные сервера? Насколько линейно росла мощность с увеличением количества узлов?
Этот 8 узловый замутили для отказоустойчивости. Крутилась куча разных задач. Собран был на отдельных серверах от Интел . Только одна задача была распределена на 4 узла для масштабируемости. Остальным хватало по 1 серверу. Милисекунды никто не измерял, считали количество одновременных пользователей. Примерно 2 с половиной тысячи одновременно на кнопки жали.
Не знаю это только мне видится противоречие в сказаном Вами или кто еще видит. Поправьте если я ошибаюсь.
Сначала Вы объясняете что 8 узлов замутили для отказоустойчивости. Потом вдруг оказалось это нужно для масштабируемости. И наконец появились намеки на производительность как проблему для многоузловости.
И все таки. Это 8 узлов одного RAC, одной базы данных? Что значит кроме одной задачи им достаточно было одного сервера? Почему если максимум требовалось 4 узла сделали 8? Удвоили что ли тупо в предположении что все четыре одновременно накрыться могут.

Как не логично это выглядит, необоснованно.
Кластер был сделан для двух целей : масштабируемости и отказоустойчивости ? Так понятно и логично ?
База данных одна на все задачи. Бизнес решил, что хочет получить "два в одном флаконе" (масштабируемость и отказоусточивость) для нескольких задач. Некоторые задачи требуют много ресурсов, другие немного ресурсов. Я понятно объяснил ?
Достаточно понятно чтобы присовокупить этот пример к череде подобных примеров, известных мне, где логика настолько вычурна и как правило навязанная не специалистами ИТ, а, в данном случае, бизнесом (варианты: кастомер, клиент).

В моем, скучном мире мф, отказоустойчивость решается отдельно, масштабируемость отдельно, количество одновременных пользователей тоде отдельно. Отдельно не в пространсивенном смыслею а в смысле методов решения. Причем отказоустойчивость мы получаем, как говорится, из коробки. Масштабируемость тоже оттуда же, по факту рождения. Ну и так далее, без узлов. Узлы мешают, тормозят по факту. Лучше обходиться одним, отказоустойчивы, масштабируемым узлом. А количество одновременных пользователей решается правильной настройкой work load manager policies, and service classes.
Не уверен что понятно объяснил, понятно чтобы было это долго.
User avatar
Flash-04
Уже с Приветом
Posts: 60596
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы идем на z14.

Post by Flash-04 »

iDesperado wrote:
Flash-04 wrote: 01 May 2019 19:19 не знаю что там у Влада, но вот тут IBM приводит циферки:
IBM DS8800 Storage System это просто полка. причем собранная для обычных платформ на обычных power6 процах.
Ну дайте другие. 8)
Not everyone believes what I believe but my beliefs do not require them to.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 02 May 2019 03:43 Вы таки будете удивлены, но бизнес привык считать деньги. Сколько будет стоить такой мэйнфрейм , способный поддерживать две с половиной тысячи одновременных пользователей ? А сколько стоит ДБ2 для мейнфрейма ? А сколько стоит вся остальная программная часть для всего этого ? И сколько надо ежегодно платить за все эти опции : https://www.ibm.com/support/knowledgece ... 53238.html
Когда бизнес посчитает денежки, то пойдет и купит 8-узловый кластер от Интела/Оракла. ИБМ будет нервно курить в сторонке.

Мы лет пять назад добавили к имевшимся 10-11 тысяч пользователей как раз 2.5 тысяч новых (Вы наверняка об этом читали мой рассказ). При этом исходно мощность МФ была ужата до такого минимума когда в часы пик загрузка ЦПУ была 99-100%. Я немножко паниковал и подавал сигналы мол не справимся с новыми 2.5 тысячами. Ничего, справились, и так и стоим на той же отметки мощности вот уже биольше 10 лет. Обьемы данных при этом растут, их никогда не отрезают.

Те 2.5 тысячи что были переведенны на мф раньше окормлялись некотороым количеством (>>1) серверов Unix/Oracle/SAP. Их, те сервера, декомиссовали не потратив ни цента на MF.

Опять все сводится к вонючим деньгам. Palych уже намекал что мы, специалисты, не тратя ни копья на оборудование печемся о том чтобы не дай бог "бизнес" не потратил лишнюю копейку. При йетом мы (и соответственно бизнес) надеваем лошадинные шоры на глаза и боясь посмотреть по сторонам ходим по одному и тому круга, как та лошадь что качает воду. Нам (вам) вбили в головы при рождении что МФ это обязательно дороже и мы (вы) верите в это.

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

Но даже считать деньги можно по разному. Можно посмотреть на типочную цену мф, ох..ть, и сесть на ж..у. А нужно все расходы, в том числе на обеспечение отказоустойчивости и масштабируемости (а также availability, serviceability и т.п), на персонал, который минимален в случае именно мф, на неизбежных для толп песонала манагеров, их офисов, бенефитов, страховок, пенсий и т.п., учесть. Вот тогда и только тогда могут быть увидены реальные деньги и они, в случае "доминатных архитектур", будут огромны по сравнению с альтернативной архитектурой. Не верите? посчитайте сами.
Не всегда конечно это будет так, но например в нашем, богоугодном и скромном заведении, это точно так и есть. 2000+ разномастных серверов, десяток голов только для поддержки их как серверов, отдельно пяток ДБА-ев. Постоянное обновление этого зоопарка с нерешаемыми проблемами совместимости и как результат размножение их в геометрической прогрессии, усилия по удержанию количества через виртуализацию, которая в свою очередь подбрасывает новые проблемы решaемые новыми серверами.
Бесконечная суета, мой коллега - тим лид Wintel - даже на кофе со мной сходить не всегда может, сидит целый день и либо распределяет тикеты, либо верстает планы обновления. А когда мы выбираемся на кофе ему обязательно приходит алерт, смс, или кто-нибудь позвонит потому что что нибудь да не так. Кроме полевых игроков в штате куча "тренеров", "менторов", "связных" с бизнесом и всем что-то нужно, а в целом вся эта ватага пытается починить тришкин кафтан. Программистов не считаю. И один я на двух МФ, на одном из которых крутится основное приложение бизнеса. Всегда открыт для любого кипиша кроме драки, всегда и со всеми желающими готов идти на кофе, на чай, по пиву. Всегда весел и бодр, а не затюкан и мрачен. Всегда на связи в Привете.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 02 May 2019 03:43 ... А сколько стоит ДБ2 для мейнфрейма ? А сколько стоит вся остальная программная часть для всего этого ? И сколько надо ежегодно платить за все эти опции : https://www.ibm.com/support/knowledgece ... 53238.html
Когда бизнес посчитает денежки, то пойдет и купит 8-узловый кластер от Интела/Оракла. ИБМ будет нервно курить в сторонке.
Ваша эта ссылка не про МФ, не про DB2 for zOS. Во-вторых, кто ж Вас заставляет платить за все? Платите только за то что Вам действительно надо. Вот и все. Не надо выдумуывать трудности, их надо обходить граммотно.

Цена на ДБ2 на МФ зависит от МФ, его MIPS (MSU). Чем больше MIPS Вы будете приводить в движение используя, в том числе, DB2, чем больше, следовательно, Вы получите результат тем больше Вам придется заплатить. Что в этом не так? Вы же не удивитесь разницe в цене садового насоса и того что качает нефть по трубопроводу "Дружба"?
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

А вообще я думал с утра поговорить не о вонючих деньгах а об отказоустойчивости и масштабируемости. Но время идти на утреннюю прогулгу. Вернусь, поговорим.
User avatar
liamkin
Уже с Приветом
Posts: 1970
Joined: 19 Jun 2003 20:22
Location: USA

Re: Мы идем на z14.

Post by liamkin »

Lazy444 wrote: 02 May 2019 03:43 Вы таки будете удивлены, но бизнес привык считать деньги. Сколько будет стоить такой мэйнфрейм , способный поддерживать две с половиной тысячи одновременных пользователей ? А сколько стоит ДБ2 для мейнфрейма ? А сколько стоит вся остальная программная часть для всего этого ? И сколько надо ежегодно платить за все эти опции : https://www.ibm.com/support/knowledgece ... 53238.html
Когда бизнес посчитает денежки, то пойдет и купит 8-узловый кластер от Интела/Оракла. ИБМ будет нервно курить в сторонке.
А что делать тем, кто с 70-х годов бизнес на мейнфреймах имеет? Сколько будет стоить переписать все и еще пережить большой outage когда клиенты разбегаться начнут? Outage будет, потому что перенести данные требует времени. Очень много данных.
iDesperado
Уже с Приветом
Posts: 1201
Joined: 28 Nov 2008 17:50

Re: Мы идем на z14.

Post by iDesperado »

liamkin wrote: 02 May 2019 15:18 А что делать тем, кто с 70-х годов бизнес на мейнфреймах имеет? Сколько будет стоить переписать все и еще пережить большой outage когда клиенты разбегаться начнут? Outage будет, потому что перенести данные требует времени. Очень много данных.
ну а как все переписывали? абсолютно все переезжали с всякого хлама на ораклы. со сторед процедур на жава, теперь вот на микросервисы. мы вот с оракла всю аналитику переписали на хадуп. без outage, клиентов тока прибыло.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Отказоустойчовость (ОУ).

Это способность продолжать функционирование без потери производительности имея отказавшие элементы. Понятно что достичь этого можно только имея избыточность. Понятно что отказоустойчивость не может безконечно длиться без восстановления отказавших элементов. Их надо заменять.
Можно добиваться ОУ исполользуя избыточность на уровне серверов, как это предлагает Lazy444. В этом случае избыточные сервера должны комплектоваться всем ПО тех серверов от отказов которых мы создаем ОУ и более того находиться в "горячем" состоянии и постоянном обслуживании как такой же элемент что защищают они. Т.е. по факту мы создаем удвоение, утроение той ИТ инфраструктуры что нам было бы достаточно не заботься мы об ОУ. Эти инфраструктуры требуют всего того же что и используемые, но они ничего не производят.
А можно заложить избыточность на более низком чем целый сервер уровне, уровне CPUs, модулей памяти, элементов ввода-вывода. Понятно что эти дополнительные элементы будут потреблять электричество, но для них ничего не надо будет делать в смысле ПО, и обслуживания этого ПО. Последний подход исторически давно используется в МФ. Поэтому ОУ МФ мы получаем "из коробки", это "коробочное" решение для ОУ. Если бы МФ не обладали этим то они были бы дешевле и использующие такие МФ пользователи строили бы то о чем говорил Lazy444.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 02 May 2019 15:43
zVlad wrote: 02 May 2019 13:49
Lazy444 wrote: 02 May 2019 03:43 ... А сколько стоит ДБ2 для мейнфрейма ? А сколько стоит вся остальная программная часть для всего этого ? И сколько надо ежегодно платить за все эти опции : https://www.ibm.com/support/knowledgece ... 53238.html
Когда бизнес посчитает денежки, то пойдет и купит 8-узловый кластер от Интела/Оракла. ИБМ будет нервно курить в сторонке.
Ваша эта ссылка не про МФ, не про DB2 for zOS. Во-вторых, кто ж Вас заставляет платить за все? Платите только за то что Вам действительно надо. Вот и все. Не надо выдумуывать трудности, их надо обходить граммотно.

Цена на ДБ2 на МФ зависит от МФ, его MIPS (MSU). Чем больше MIPS Вы будете приводить в движение используя, в том числе, DB2, чем больше, следовательно, Вы получите результат тем больше Вам придется заплатить. Что в этом не так? Вы же не удивитесь разницe в цене садового насоса и того что качает нефть по трубопроводу "Дружба"?
Все прекрасно. Все дело в цене. Цифры услышим ? Сколько ваша компания отстегивает ежегодно ИБМ ?
По ссылке : бэкап базы данных как опция. Платить за бэкап базы данных по отдельному прейскуранту ? Уже смешно.
Чтобы говорить о сколько это стоит надо знать за что, что это дает. Я думаю овчинка стоит выделки если учесть что все попытки заменить МФ у нас, начавшиеся в середине 90-х, успешно проваливались аж до сих пор и есть надежда до 2026.

Прекратите приводить данные из ссылок не касающихся МФ, или прекратите говорить/спрашивать о МФ, сслылась на практику с других платформ. Это, мягко говоря, не корректно. И то что ИБМ причастен и к тому и к другому ничего не меняет. В случаее МФ подходы у того же ИБМ совсем другие, а то о чем Вы сслылаясь сетуете скорее причастно к не-МФ-ским архитектурам.
iDesperado
Уже с Приветом
Posts: 1201
Joined: 28 Nov 2008 17:50

Re: Мы идем на z14.

Post by iDesperado »

zVlad wrote: 02 May 2019 15:57 Чтобы говорить о сколько это стоит надо знать за что, что это дает. Я думаю овчинка стоит выделки если учесть что все попытки заменить МФ у нас, начавшиеся в середине 90-х, успешно проваливались аж до сих пор и есть надежда до 2026.
по факту как и во всем мире с вашего МФ вся нагрузка уехала, просто ты слишком туп, что понять что собственно происходит. не смотря на твою тупизну мы четко выяснили, что нагрузка уезжала на "гигантские" LPAR на Power7 размером аж 8 vcpu, т.е. на 1/4 от Power7 процессора. на твоем МФ же остался какой-то редкоменяемый архив, который с крошечным кешем в 12Gb генерит смешные 700 iops на пике. т.е. нагрузка ноль, все уехало на unix/oracle. как и во всем остальном мире.
3 дня за хамство.
zVlad
Уже с Приветом
Posts: 14388
Joined: 30 Apr 2003 16:43

Re: Мы идем на z14.

Post by zVlad »

Lazy444 wrote: 02 May 2019 16:18 Я понял. Цифр не будет. Засим откланиваюсь.
Откуда, подумайте, мне, простому аналитику, могло бы быть известно сколько отстегивает "наша компания ежегодно ИБМ". Тем более что с 2015 года отстегивает не наша компания, а наш клиент. Более тем мне и самому это не интересно, и не полезно, знать.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

Re: Мы идем на z14.

Post by flip_flop »

zVlad wrote: 02 May 2019 15:50
Можно добиваться ОУ исполользуя избыточность на уровне серверов
...
А можно заложить избыточность на более низком чем целый сервер уровне, уровне CPUs, модулей памяти, элементов ввода-вывода.
Хе-хе,

Ты удивишься, но и в Xeon серверах используется такая избыточность (на более низком чем целый сервер уровне) Например, CHIPKILL. Слава великой и могучей ИБМ, которая эту технологию разработала (да и вообще они были первыми во многих RAS решениях). А сейчас технология используется и на спарках, и на поуерах, и на XEON, родных, хе-хе, а как же? Подобные же решения для дисков.

Для кластеров тоже имеются решения без полной дупликации серверов.

Вовсю используется отказоустойчивый (High Availability, HA) Линукс для разных систем. И как отдельные OS и как пакеты расширения существующих. В Оракл Линукс такое есть, сейчас СюСя тоже такое делает. Ты почему то ужасно, дремуче, люто, бешено недооцениваешь линуксы. А зря. Например, я перешёл и на рабочей станции и на лаптопе на Clear Linux, который быстрее всех именно потому, что использует архитектуру чипов внутри OS.

HPE производит сервера с гарантированной 100 % работой, NonStop x86 серверы. Отказоустойчивость из коробки для scale-up сервера.

Почему же иногда используют дупликацию на уровне серверов? Не знаю, но подозреваю что "дёшево и сердито", проще и дешевле купить парочку серверов чем мудрить с более архитектурно изысканными, но сложными и/или дорогими системами. Пусть Lazy444 поправит, я только спекулирую. Подозреваю, что дело в "вонючих" деньгах.

--
числовой маньяк

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