Мы идем на z14.

[flip_flop]

Странно, что показатели надежности вообще не принимаются во внимание в дискуссии. Не терафлопсами едиными живы системы. Если для MF IBM постулирует uptime 99.999%, то что у конкурентов непонятно. Также непонятно, hot-swappable у них блоки или нет.

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

Неправда. Я всегда оперировал числами, в том числе для RAS. Вот и сейчас привёл.

P.S. Более того, только после того как х86 подтянулись по RAS (RAS выражается в числах, кстати) к МФ, лет 7 тому назад, я и начал дискуссию.

[iDesperado]

MF availability.png

parallel sysplex это железячка под регионы памяти разных апликух. например у дб2 на этой железячке живет единый список блокировок и буферные пулы. несколько нод МФ могут через эту железячку работать типа как единый инстанс db2, но железячка эта классический single point of failure. потому требует костылей вокруг - дублированных железяк. т.е. каждая нода db2 генерирует огромный трафик на такую железяку (шутка ли, любая попытка чтения db2 требует данных о блокировке), а железяка обязана еще и дублировать весь трафик на резервные CF. вобщем на фоне ораклового RAC, где все ноды полноправны parallel sysplex полное порно. потому в реальных инсталяциях parallel sysplex почти не встречается, а RAC в любом банке и оракл лет пять назад говорил что уже половина инсталяций EE редакции ставяться RACом.

[ALV00]

Ставятся РАКом - это хорошо сказано ))
Насчет "попытка чтения db2 требует данных о блокировке" - не понял. В Оракле разве не то же самое?
Вот кстати RAC и есть порно, в том смысле, что он не является настоящим кластером, потому что дисковая система общая.

[zVlad]

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

[zVlad]

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 узлами (сейчас может быть больше, не знаю) и имеет близкую к линейной зависимость.

[flip_flop]

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

Разработчики 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]

Ставятся РАКом - это хорошо сказано ))
Насчет "попытка чтения db2 требует данных о блокировке" - не понял. В Оракле разве не то же самое?

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

Вот кстати RAC и есть порно, в том смысле, что он не является настоящим кластером, потому что дисковая система общая.

как у любого облачного сервиса. причем теперь это уже совсем абстракция и "диском" может быть хоть хадуп с hdfs, хоть storage servers от exadata

[iDesperado]

Кластеры и RAC используют потому что мощности одного узла недостаточно для заданой нагрузки. Так заложено что одного сервера для более менее приличной нагрузки недостаточно. Поэтому, несмотря на неизбежные издержки и благодаря дешевизне серверов, их вяжут в кластеры, с разделением дисков (RAC) или без разделения.
RAC отличается от PS нелинейной зависимостью роста производительности от количества узлов и больше 4 узлов RAC не тянет, загибается. PS теоритически ограничен 32 узлами (сейчас может быть больше, не знаю) и имеет близкую к линейной зависимость.

PS имеет нулевую клиентскую базу и титул проигравшего ораклу подчистую, в первую очередь потому что такой костыль не масштабируется. я расписал почему. что касается узлов RAC то еще 10 лет назад ibm утверждал что у них 5 узлов RAC отмасштабировались линейно в sap-sd parallel тестах.

[deev_a_v]

...

Сколько понадобится МФ, чтобы построить поисковик типа Гугла?

[alex_127]

...

Сколько понадобится МФ, чтобы построить поисковик типа Гугла?

один. это же простая система, всего одна таблица "вопрос" -> "ответы"

[zVlad]

Кластеры и RAC используют потому что мощности одного узла недостаточно для заданой нагрузки.

1. Совсем нет. По собственному опыту Oracle RAC ставят в первую очередь для повышения отказоусточивости. Видел и такое, что на двух узловом Oracle RAC вторй узел использовали толко для открытия сессий для случая failover. Производительности даже одного узла хватало вполне.

Так заложено что одного сервера для более менее приличной нагрузки недостаточно.

2. Спорное утверждение. Зависит от того, что вы называете нагрузкой. Что вы называете "более менее приличной нагрузкой"

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). Так он сказал.

[zVlad]

...

Сколько понадобится МФ, чтобы построить поисковик типа Гугла?

на два, а то и на три, порядка меньше чем количество тех серверов на которых поисковик тот работает сейчас. Нет, на четыре порядка. Короче гораздо меньше, но вряд ли задача поисковика, с которого никто ничто не ожидает кроме странички найденного по запросу, требует тех RAS что дает МФ, поэтому то на чем Google построил свой поисковик и есть то на чем его следовало бы строить.

IBM уже давно поставляет решение когда МФ работает в одной упряжке с блэйд серверами. Это для тех работ что не критичны и могут быть, под контролем МФ, отгружены для выполнения на блэйд. Если строить поисковик типа Google-ского, то его следовало бы строить не на МФ, а на гетерогенной zEnterprise, т.е МФ ис блэйдами.

[Palych]

А довод со стороны zVlad, хотя и без подробностей, но вполне КМК весомый: много лет попыток предать МФ анафеме привели к решению продлить их эксплуатацию и обновить версию.

Я кстати так и не понял, почему. Что за принципиальная проблема возникла?

Тут как раз все понятно: не наняли настоящих спецов, из участников этой дискуссии.
Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...

[iDesperado]

Тут как раз все понятно: не наняли настоящих спецов, из участников этой дискуссии.
Интересно другое: почему так сильно желание уничтожить МФ? Причём со стороны энтузиастов, которые не платят за них...
Мне кажется МФ нужно тщательно охранять, как пример альтернативного подхода к современным задачам.
А мы остервенело боремся за диктат единообразия...

не, это уже надо закапывать, так как выродилось из серьезной технологии в тупой культ насилующий неопытных пользователей мыши. посмотрите на Влада. знаний ноль, образование отсутствует напрочь. умудряется попутать core с cpu и vcpu, но верует. верует, что МФ "Нет, на четыре порядка" (c)

[flip_flop]

Теоритически существуют весьма мощные сервера х86 способные, как уверяет flip_flop, творить чудеса.

Хе-хе,

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

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