Мы идем на z14.

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

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

Post by flip_flop »

zVlad wrote: 29 Apr 2019 03:16
flip_flop wrote: 28 Apr 2019 23:08 ...
На твои две несовместные точки зрения есть одна точка зрения научного сообщества (неглупые люди, наукой занимаются) - 100% Линукс в HPC, и доминирующая по цифрам (90 %) точка зрения провайдеров облаков. Быстрая, модульная, масштабируемая ОС. У тебя есть полное право иметь отличную от учёных и инженеров мнение. Да и цифры тебе не указ, делов то.
...

Пока ты не блеснешь знанием мф мне с тобой говорить не о чем. Дерзай.
"Не дождётесь"

Да и разговор шёл о Линуксе а не о МФ. Или для знания Линукса необходимо глубокое изучение МФ? Где логика, дружище? Впрочем -если чисел нет, может и логики нет?
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

flip_flop wrote: 29 Apr 2019 10:19
zVlad wrote: 29 Apr 2019 03:16
flip_flop wrote: 28 Apr 2019 23:08 ...
На твои две несовместные точки зрения есть одна точка зрения научного сообщества (неглупые люди, наукой занимаются) - 100% Линукс в HPC, и доминирующая по цифрам (90 %) точка зрения провайдеров облаков. Быстрая, модульная, масштабируемая ОС. У тебя есть полное право иметь отличную от учёных и инженеров мнение. Да и цифры тебе не указ, делов то.
...

Пока ты не блеснешь знанием мф мне с тобой говорить не о чем. Дерзай.
"Не дождётесь"

Да и разговор шёл о Линуксе а не о МФ. Или для знания Линукса необходимо глубокое изучение МФ? Где логика, дружище? Впрочем -если чисел нет, может и логики нет?
Если быть совсем точным то разговор шел о Линуксе и Виндоуз. Впрочем постоянный рефреном этой темы остается мф. Так что о нем можно всегда и везде.
Понятно, самостоятельно раскрывать и погружаться в тему мф ни ты ни твой друг не хотите, будете бесконечно бубнить о своих могучих, ширпотребных и маленьких серверах. Мне тоже есть чем заняться кроме ликвидации вашей (с другом) дремучей отсталости в известных (не вам) отраслях современного ИТ.
User avatar
Flash-04
Уже с Приветом
Posts: 61405
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

с DRAM я даже можно сказать заочно знаком :D несколько лет назад рассматривали возможность покупки быстрых дисковых массивов от Kaminario: https://kaminario.com/
Не знаю как сейчас, а тогда у них был некий продукт, где вместо SSD был DRAM. Какие-то дикие показатели демонстрировали. Увы, зажали нам тогда пол-лимона :| :D
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 »

zVlad wrote: 29 Apr 2019 13:24
flip_flop wrote: 29 Apr 2019 10:19
zVlad wrote: 29 Apr 2019 03:16
flip_flop wrote: 28 Apr 2019 23:08 ...
На твои две несовместные точки зрения есть одна точка зрения научного сообщества (неглупые люди, наукой занимаются) - 100% Линукс в HPC, и доминирующая по цифрам (90 %) точка зрения провайдеров облаков. Быстрая, модульная, масштабируемая ОС. У тебя есть полное право иметь отличную от учёных и инженеров мнение. Да и цифры тебе не указ, делов то.
...

Пока ты не блеснешь знанием мф мне с тобой говорить не о чем. Дерзай.
"Не дождётесь"

Да и разговор шёл о Линуксе а не о МФ. Или для знания Линукса необходимо глубокое изучение МФ? Где логика, дружище? Впрочем -если чисел нет, может и логики нет?
Если быть совсем точным то разговор шел о Линуксе и Виндоуз. Впрочем постоянный рефреном этой темы остается мф. Так что о нем можно всегда и везде.
Понятно, самостоятельно раскрывать и погружаться в тему мф ни ты ни твой друг не хотите, будете бесконечно бубнить о своих могучих, ширпотребных и маленьких серверах. Мне тоже есть чем заняться кроме ликвидации вашей (с другом) дремучей отсталости в известных (не вам) отраслях современного ИТ.
Согласен, разговор шел о Линуксе и Виндоуз. Прости и прими мои извинения за неточность. Но ты не можешь даже об этом поговорить, не упомянув великого и могучего дракона МФ. И я не бубню, а ясно и внятно обсуждяю архитектурные решения (новые масштабируемые серверные процессоры, позволяющие использовать энергонезависимую память, использование такой памяти вместе с обычными DRAM и SSD) ведущие к высокой производительности. Всё это выражается в числах.
“Using Supermicro MP servers, we were able to achieve real-time fraud detection against 10TB of data to process an astonishing 10 thousand transactions per second (TPS) with less than 10 microsecond response time.” said Grish Mutraja, CEO of Neeve Research, a pioneer in Next Generation in-memory computing technology. “The baseline today with current mainframes is around 800 TPS with a latency of 50 milliseconds.

На что ты что-то бубнишь, ибо нетехнически и без чисел. Ещё раз:

Сравни, плиз, нечто компьютерное на техническом уровне без чисел.

Твои призывы углубляться в МФ по меньшей мере непонятны. Зачем? Зачем лезть внутрь того, что не используешь и никогда уже использовать не будешь? Только из-за дискуссии? Так не обязательно и, даже более того, вредно из-за захламления мозгов. Конечному потребителю нужны выходные технические показатели, выражаемые в числах. Разработчику тоже надо ориентироваться на рынок, конечного потребителя и разрабатывать конкурентно годные системы, где годность выражается в числах. При этом разработчику, скажем, Феррари не надо знать особенности разработки траков. Оно можно, конечно, из любопытства, но не обязательно.

Кстати, ранее я приводил анализ решений на МФ (скорее на уровне железа чем на уровне логической архитектуры), признавал первенство ИБМ и МФ в некоторых решениях (eDRAM например) и приводил числа в пользу МФ (число уровней и обьём кешей, например). Я щупал (в прямом смысле) z12, держал в руках керамические системные блоки и заглядывал внутрь труб водяного охлаждения. Но это никак не отменяет сравнимость современных решений по техническим показателям, выражаемых в числах. А с твоей стороны вместо сравнения я слышу только обвинения в дремучей отсталости. Не комильфо, не находишь?
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

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

Post by flip_flop »

Flash-04 wrote: 29 Apr 2019 13:59 с DRAM я даже можно сказать заочно знаком :D несколько лет назад рассматривали возможность покупки быстрых дисковых массивов от Kaminario: https://kaminario.com/
Не знаю как сейчас, а тогда у них был некий продукт, где вместо SSD был DRAM. Какие-то дикие показатели демонстрировали. Увы, зажали нам тогда пол-лимона :| :D
Ну, с появлением конкурентных продуктов, цены должны в конце концов снижаться. Хотя цены на память иногда видут себя дико :)

Но в данном случае энергонезависимая память находится в обычных диммах на материнке. Отсюда гораздо более высокая пропускная способность и малое время доступа, даже рассматривая сколь угодно быстрые SSD/DRAM, но сидящие на PCIe. Впрочем, скоро появятся PCIe Gen 5 с 63 GB/s. Правда и системы памяти не стоят на месте. Прогресс на марше.
User avatar
ALV00
Уже с Приветом
Posts: 1355
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

Странно, что показатели надежности вообще не принимаются во внимание в дискуссии. Не терафлопсами едиными живы системы. Если для MF IBM постулирует uptime 99.999%, то что у конкурентов непонятно. Также непонятно, hot-swappable у них блоки или нет.
iDesperado
Уже с Приветом
Posts: 1212
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

flip_flop wrote: 29 Apr 2019 17:50 Но это никак не отменяет сравнимость современных решений по техническим показателям, выражаемых в числах. А с твоей стороны вместо сравнения я слышу только обвинения в дремучей отсталости. Не комильфо, не находишь?
да были уже числа. на его МФ аж 788.5 IOPs бывает. уже разбирали
viewtopic.php?p=6752317#p6752317

ктати глобал фаундрес заморозило техпроцесс, выходит МФ теперь так и останеться на 14 нм и древней ddr3. во, еще ddr память на МФ пришла из мира писюков

update: а нет, в z14 все таки ddr4 прикрутили. технологический лидер. однозначно.
Last edited by iDesperado on 29 Apr 2019 20:01, edited 1 time in total.
User avatar
ALV00
Уже с Приветом
Posts: 1355
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

MF availability.png
You do not have the required permissions to view the files attached to this post.
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

ALV00 wrote: 29 Apr 2019 19:28 Странно, что показатели надежности вообще не принимаются во внимание в дискуссии. Не терафлопсами едиными живы системы. Если для MF IBM постулирует uptime 99.999%, то что у конкурентов непонятно. Также непонятно, hot-swappable у них блоки или нет.
Я всячески подвигал оппонента к хотя бы этому, что как раз в любимых ему числах выражается. Но он упорно выкручивался.
На самом деле это далеко не самое главное достоинства мф, хотя и важное. Но я бы хотел чтобы такие рьяные, многолетние оппоненты мф как flip-flop и iDesperado наконец то взяли на себя труд познакомиться ближе с тем чему посвятили немалые усилия и время.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

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

Post by flip_flop »

ALV00 wrote: 29 Apr 2019 19:28 Странно, что показатели надежности вообще не принимаются во внимание в дискуссии. Не терафлопсами едиными живы системы. Если для MF IBM постулирует uptime 99.999%, то что у конкурентов непонятно. Также непонятно, hot-swappable у них блоки или нет.
Исторически МФ и ИБМ в целом лидировали. Сейчас х86 серверы подтянулись. "In particular, Lenovo'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% reliability for close to three-quarters of the respondents to ITIC’s latest poll" HPE тоже предлагает серверы с гарантированной непрерывной работой NonStop.

Сменямые по горячему блоки - диски/SSD и память - да. Целиком узлы - не знаю, пусть специалисты скажут.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

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

Post by flip_flop »

zVlad wrote: 29 Apr 2019 19:59
ALV00 wrote: 29 Apr 2019 19:28 Странно, что показатели надежности вообще не принимаются во внимание в дискуссии. Не терафлопсами едиными живы системы. Если для MF IBM постулирует uptime 99.999%, то что у конкурентов непонятно. Также непонятно, hot-swappable у них блоки или нет.
Я всячески подвигал оппонента к хотя бы этому, что как раз в любимых ему числах выражается. Но он упорно выкручивался.
.
Неправда. Я всегда оперировал числами, в том числе для RAS. Вот и сейчас привёл.

P.S. Более того, только после того как х86 подтянулись по RAS (RAS выражается в числах, кстати) к МФ, лет 7 тому назад, я и начал дискуссию.
iDesperado
Уже с Приветом
Posts: 1212
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

ALV00 wrote: 29 Apr 2019 19:57 MF availability.png
parallel sysplex это железячка под регионы памяти разных апликух. например у дб2 на этой железячке живет единый список блокировок и буферные пулы. несколько нод МФ могут через эту железячку работать типа как единый инстанс db2, но железячка эта классический single point of failure. потому требует костылей вокруг - дублированных железяк. т.е. каждая нода db2 генерирует огромный трафик на такую железяку (шутка ли, любая попытка чтения db2 требует данных о блокировке), а железяка обязана еще и дублировать весь трафик на резервные CF. вобщем на фоне ораклового RAC, где все ноды полноправны parallel sysplex полное порно. потому в реальных инсталяциях parallel sysplex почти не встречается, а RAC в любом банке и оракл лет пять назад говорил что уже половина инсталяций EE редакции ставяться RACом.
User avatar
ALV00
Уже с Приветом
Posts: 1355
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

Ставятся РАКом - это хорошо сказано ))
Насчет "попытка чтения db2 требует данных о блокировке" - не понял. В Оракле разве не то же самое?
Вот кстати RAC и есть порно, в том смысле, что он не является настоящим кластером, потому что дисковая система общая.
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Flip-flop, я не понимаю чего ты добиваешься. Числа по мф не у меня в кармане лежат недоступными никому. Если бы даже я начал тебе давать числа то они были бы из открытых источников доступных всем. Пойди на ibm.com и там все найдешь.
Я знаю наперед что ты найдешь среди своих чисел равные или большие тех что есть о мф. И что?
Современные архитектуры ИТ это не сумма единичных серверов. Это и сервера и операционные системы и средства связи и методы решения задач, которые можно грубо разбить на две группы: централизованные и децентрализованные. Оба подхода используются по необходимости на мф, с предпочтением в сторону централизации, или co-location. На серверах же х86, в случае крупных и даже не таких уж и крупных, основной метод это децентрализация, дробление, расслоение и т.п..
Причиной этому является невозможность, в комплексе, решать сложные задачи в одном месте, централизованно, т.е. гораздо более эффективно с меньшими издержками по сравнению с искусственной/вынужденной децентрализацией.
Поэтому одни и те же задачи, одного объема, в случае мф потребуют мощностей меньшего размера. Есть задачи, и ты их имеешь в виду, типа числодробилок, как ты сам выражаешься, или задач обработки, грубо говоря, бесконечного потока данных по несложному алгоритму. Вот для этих задач и применяют те сервера о которых ты говоришь.
Мф применяется для решения как можно более разнообразных нагрузок одновременно и в одном месте. Такую нагрузку твои сервера не потянут, не столько по недостаточности чисел, а поскольку операционных систем для этого у низ нет. Ни линукс, ни виндоуз этого делать не могут. Не могут в том числе потому что архитектура х86 для этого не дает адекватной поддержки. Но понять это ты можешь только сам. Если конечно захочешь. Я тебе это дать не смогу, хотя бы потому что ты сам не готов к этому чтобы понять. У тебя есть свое убеждение, на твой взгляд доказаное.
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

iDesperado wrote: 29 Apr 2019 20:27
ALV00 wrote: 29 Apr 2019 19:57 MF availability.png
parallel sysplex это железячка под регионы памяти разных апликух. например у дб2 на этой железячке живет единый список блокировок и буферные пулы. несколько нод МФ могут через эту железячку работать типа как единый инстанс db2, но железячка эта классический single point of failure. потому требует костылей вокруг - дублированных железяк. т.е. каждая нода db2 генерирует огромный трафик на такую железяку (шутка ли, любая попытка чтения db2 требует данных о блокировке), а железяка обязана еще и дублировать весь трафик на резервные CF. вобщем на фоне ораклового RAC, где все ноды полноправны parallel sysplex полное порно. потому в реальных инсталяциях parallel sysplex почти не встречается, а RAC в любом банке и оракл лет пять назад говорил что уже половина инсталяций EE редакции ставяться RACом.
Parallel Sysplex используется не часто. Основное его назначение это создать non-stop инфраструктуру. Non-stop в смысле возможности обслуживать ноды по очереди не останавливая ни на минуту доступность к приложению, или non-stop в смысле устойчивости инфраструктуры к выходу из строя целого мф, или non-stop в смысле DR когда теряем дата центр. Последнее называется GDPS - географически распределенный Parallel Sysplex.
Если non-stop не требуется, т.е. есть окна для обслуживания, то Sysplex не нужен, все можно разместить на единичном мф. Кстати, и Parallel Sysplex можно реализовать на одном мф и обслуживать ноды по очереди не прекращая работу инфраструктуры. Для этого достаточно двух узлов. Можно также вырождать PS в одноузловой и возвращаться к двух узловому накануне обслуживания, обслуживать их по очереди и снова делать один узел.

Кластеры и RAC используют потому что мощности одного узла недостаточно для заданой нагрузки. Так заложено что одного сервера для более менее приличной нагрузки недостаточно. Поэтому, несмотря на неизбежные издержки и благодаря дешевизне серверов, их вяжут в кластеры, с разделением дисков (RAC) или без разделения.
RAC отличается от PS нелинейной зависимостью роста производительности от количества узлов и больше 4 узлов RAC не тянет, загибается. PS теоритически ограничен 32 узлами (сейчас может быть больше, не знаю) и имеет близкую к линейной зависимость.
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

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

Post by flip_flop »

zVlad wrote: 29 Apr 2019 21:22 Мф применяется для решения как можно более разнообразных нагрузок одновременно и в одном месте. Такую нагрузку твои сервера не потянут, не столько по недостаточности чисел, а поскольку операционных систем для этого у низ нет. Ни линукс, ни виндоуз этого делать не могут.
Разработчики Enterprise Linux (RHEL или SLES) с тобой не согласяться.

Итак, сужаем задачу. Кластеры отбрасываем. Большие MCP, scale-up серверы, о которых я говорил раньше - тоже отбрасываем, потому как они двойного/тройного применения и могут быть отнесены к суперкомпьютерам. Но сейчас появились маленькие х86 серверы, предназначенные для scale-up и enterprise. Ещё раз:
“Using Supermicro MP servers, we were able to achieve real-time fraud detection against 10TB of data to process an astonishing 10 thousand transactions per second (TPS) with less than 10 microsecond response time.” said Grish Mutraja, CEO of Neeve Research, a pioneer in Next Generation in-memory computing technology. “The baseline today with current mainframes is around 800 TPS with a latency of 50 milliseconds. Supermicro’s servers provide amazing performance and strong value proposition for any enterprises that are seriously considering mainframe migration strategies.”
...
Supermicro’s Multi-Processor servers are designed for enterprise mission-critical workloads such as real-time OLTP + OLAP, in-memory analytics, virtualization"

Теперь к цифрам. Ты хочешь сказать, что 10000 транзакций в секунду это мало а 800 это много? Или что разбив 10000 транзакций на как можно более разнообразные, МФ обойдёт по скорости указанный Xeon сервер на тех же тестах? Если да, то должны быть тесты и результаты, а не ничём не подкреплённое заявление - якобы "не потянут, не могут" и т.д. Например, для виртуализации есть тесты на spec.org, учитывающие разнообразную нагрузку (application server, web server, mail server, batch server) одновременно и в одном месте. Кто там лидер, а кого и вовсе нет - говорить не надо, да?

На сегодня у меня всё, много работы. Обьявлюсь завтра после обеда. Продолжаем разговор.
iDesperado
Уже с Приветом
Posts: 1212
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

ALV00 wrote: 29 Apr 2019 21:11 Ставятся РАКом - это хорошо сказано ))
Насчет "попытка чтения db2 требует данных о блокировке" - не понял. В Оракле разве не то же самое?
нет кончено. во первых оракл версионник, читателю не интересны блокировки, во вторых у оракл блокировка атрибут данных. в самом блоке данные о локах.
ALV00 wrote: 29 Apr 2019 21:11 Вот кстати RAC и есть порно, в том смысле, что он не является настоящим кластером, потому что дисковая система общая.
как у любого облачного сервиса. причем теперь это уже совсем абстракция и "диском" может быть хоть хадуп с hdfs, хоть storage servers от exadata
iDesperado
Уже с Приветом
Posts: 1212
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

zVlad wrote: 29 Apr 2019 21:49
Кластеры и RAC используют потому что мощности одного узла недостаточно для заданой нагрузки. Так заложено что одного сервера для более менее приличной нагрузки недостаточно. Поэтому, несмотря на неизбежные издержки и благодаря дешевизне серверов, их вяжут в кластеры, с разделением дисков (RAC) или без разделения.
RAC отличается от PS нелинейной зависимостью роста производительности от количества узлов и больше 4 узлов RAC не тянет, загибается. PS теоритически ограничен 32 узлами (сейчас может быть больше, не знаю) и имеет близкую к линейной зависимость.
PS имеет нулевую клиентскую базу и титул проигравшего ораклу подчистую, в первую очередь потому что такой костыль не масштабируется. я расписал почему. что касается узлов RAC то еще 10 лет назад ibm утверждал что у них 5 узлов RAC отмасштабировались линейно в sap-sd parallel тестах.
deev_a_v
Уже с Приветом
Posts: 3472
Joined: 07 Apr 2018 15:16

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

Post by deev_a_v »

zVlad wrote: 29 Apr 2019 21:22
...
Сколько понадобится МФ, чтобы построить поисковик типа Гугла?
Просто я живу на улице Ленина
И меня зарубает время от времени
https://www.youtube.com/watch?v=WS7hHNiwZVo
alex_127
Уже с Приветом
Posts: 5391
Joined: 29 Mar 2000 10:01
Location: Kirkland,WA

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

Post by alex_127 »

deev_a_v wrote: 30 Apr 2019 12:30
zVlad wrote: 29 Apr 2019 21:22
...
Сколько понадобится МФ, чтобы построить поисковик типа Гугла?
один. это же простая система, всего одна таблица "вопрос" -> "ответы"
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Lazy444 wrote: 30 Apr 2019 03:25
zVlad wrote: 29 Apr 2019 21:49
Кластеры и RAC используют потому что мощности одного узла недостаточно для заданой нагрузки.
1. Совсем нет. По собственному опыту Oracle RAC ставят в первую очередь для повышения отказоусточивости. Видел и такое, что на двух узловом Oracle RAC вторй узел использовали толко для открытия сессий для случая failover. Производительности даже одного узла хватало вполне.
zVlad wrote: 29 Apr 2019 21:49 Так заложено что одного сервера для более менее приличной нагрузки недостаточно.
2. Спорное утверждение. Зависит от того, что вы называете нагрузкой. Что вы называете "более менее приличной нагрузкой"
zVlad wrote: 29 Apr 2019 21:49 RAC отличается от PS нелинейной зависимостью роста производительности от количества узлов и больше 4 узлов RAC не тянет, загибается. PS теоритически ограничен 32 узлами (сейчас может быть больше, не знаю) и имеет близкую к линейной зависимость.
3. О как ! Работал с Oracle RAC на 8 узловом кластере на Линуксе. Он тянул, только в путь.
1. Да и отказоустойчивость тоже причина для RAC. Потому что связка RISC/Unix/Oracle неотказоустойчивa. Я в своем перечьне причин для Parallel Sysplex отказоустойчивость не назвал и даже отмечал что в большенстве случаев можно подобрать такую модел МФ которая потянет любую нагрузку без запрягания больше одного коня в сани. Failover тоже из той же серии. На МФ мы про failover не паримся вообще. Только DR.

2. Общаясь с ребятами нашими по Wintel я вижу как они любят кластеры, даже там где не нужно решать проблему мощности. Теоритически существуют весьма мощные сервера х86 способные, как уверяет flip_flop, творить чудеса. Но вот, как я понимаю и вишу там где я могу видеть, до создания мощного инстанса БД на одном узле дело редко доходит. У нас самая мощная установка БД это DB2 на МФ. А наш МФ это чуть-чуть от пола по мошцности для мф вообще. В остальных применениях данные мелко дробятся между задачами и локациями пользователей. И то при этом наровят закластериться. Попозже придет наш MS SQL/Oracle DBA я его допрошу на эту тему и добавлю. Есть у него базы терробайтные, но это помойки, т.е. данные из них используются редко.

3. А можно спросить, мне интересно, почему там именно 8 узлов замутили? Были ли те узлы виртуальными, или это были физически отдельные сервера? Насколько линейно росла мощность с увеличением количества узлов?

P.S. Пришел наш MS SQL/Oracle DBA. У нас нет RAC,aMS SQL не имеет возможности работать в калстере (share nothing, nor share disks). Так он сказал.
Last edited by zVlad on 30 Apr 2019 15:23, edited 1 time in total.
zVlad
Уже с Приветом
Posts: 14429
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

deev_a_v wrote: 30 Apr 2019 12:30
zVlad wrote: 29 Apr 2019 21:22
...
Сколько понадобится МФ, чтобы построить поисковик типа Гугла?
на два, а то и на три, порядка меньше чем количество тех серверов на которых поисковик тот работает сейчас. Нет, на четыре порядка. Короче гораздо меньше, но вряд ли задача поисковика, с которого никто ничто не ожидает кроме странички найденного по запросу, требует тех RAS что дает МФ, поэтому то на чем Google построил свой поисковик и есть то на чем его следовало бы строить.

IBM уже давно поставляет решение когда МФ работает в одной упряжке с блэйд серверами. Это для тех работ что не критичны и могут быть, под контролем МФ, отгружены для выполнения на блэйд. Если строить поисковик типа Google-ского, то его следовало бы строить не на МФ, а на гетерогенной zEnterprise, т.е МФ ис блэйдами.
Palych
Уже с Приветом
Posts: 13075
Joined: 16 Jan 2001 10:01

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

Post by Palych »

Flash-04 wrote: 28 Apr 2019 21:41
Palych wrote: А довод со стороны zVlad, хотя и без подробностей, но вполне КМК весомый: много лет попыток предать МФ анафеме привели к решению продлить их эксплуатацию и обновить версию.
Я кстати так и не понял, почему. Что за принципиальная проблема возникла?
Тут как раз все понятно: не наняли настоящих спецов, из участников этой дискуссии.
Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...
iDesperado
Уже с Приветом
Posts: 1212
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

Palych wrote: 30 Apr 2019 14:48 Тут как раз все понятно: не наняли настоящих спецов, из участников этой дискуссии.
Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...
не, это уже надо закапывать, так как выродилось из серьезной технологии в тупой культ насилующий неопытных пользователей мыши. посмотрите на Влада. знаний ноль, образование отсутствует напрочь. умудряется попутать core с cpu и vcpu, но верует. верует, что МФ "Нет, на четыре порядка" (c)
User avatar
flip_flop
Уже с Приветом
Posts: 4363
Joined: 20 Jun 2001 09:01

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

Post by flip_flop »

zVlad wrote: 30 Apr 2019 14:00 Теоритически существуют весьма мощные сервера х86 способные, как уверяет flip_flop, творить чудеса.
Хе-хе,

Это не я уверяю, это всего лишь данные от разработчиков и пользователей. Сухие числа. Я всего лишь противлюсь искажениям фактов. Никаких чудес, простая физика и простая математика. Никакого мягкого лампового звука. И не "теоритически" а вполне практически, можно купить за не очень дорого, прогнать и проверить. И уж несколько лет есть большие SMP scaled up серверы, вполне себе тянущие серьёзную нагрузку с вполне себе тянущим Линуксом. Но ты их отвергаешь, относя к категории суперкомпьютеров, а это не то. Кластеры ты тоже то отвергаешь, то привлекаешь к рассмотрению. Ну ладно, отбросим все кластеры, облака, суеркомпьютеры, и гипер-укомплектованные дата центры. Даже отбросив всё это богатство, есть вполне осязаемые, реальные, маленькие серверы, которые при этом SMP scaled up и вполне тянут МФ нагрузку, используя новые технологические решения.

Это факт, от которого нельзя отмахнуться.

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