HP ушел из России, т.п вам будут оказывать менеджеры, которые вам продали msa из серого импорта.
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Но когда кейсов уже стало несколько десятков, пришлось искать другое решение.
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
А по факту оно примерно так не только лишь всегда через пару/тройкулет от go live:) Это в ECC 6.0 все было в абапе, а в S/4HANA теперь БД-монстры, выжирающие селектом по 500+GB оперативы. И в "стандарте" в том числе.
Требования к RAM для сервера БД зависят от ожидаемого количества данных во всех развертываемых модулях, поскольку вся БД in-memory
Начиная с S/4HANA 2020 можно использовать NSE (будет как классическая CУБД работать через буффер-кэш), если с памятью совсем напряг, но, естественно с некоторымоверхедом
На практике для стандартного набора модулей (бухучет, управленческий учет, казначейство, закупки и склад, сбыт, производство, техобслуживание и ремонты) от 256 до 512 гигов, для особо тяжелых случаев 1 TB.
Для S/4HANA на 1000 конкурентных юзеров 1TB RAM БД это скорее для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
Ну вот за прошлый год выручка Спортмастера составил 170 ярдов. Т.е. условно-примерно 465 лямов в день. Неплохо за день простоя. Безусловно каждый крупный бизнес сам выбирает надо ли оно ему это DR или "и так сойдет". А если бы не затопило и высушили за день, а сгорело ?
Прадедушка (E880) указанной в статье топ-машины E1180 за прошедшие 7 лет продуктивной эксплуатации выключался два раза : 1-ый для добавления CECов, 2-ой при переезде в другой ЦОД. Cам по себе не падал ни разу. Не знаю сколько это девяток, но в плане аппаратной надежности, имхо, очень неплохо. "Фирма веников не вяжет, фирма делает "гробы" ", правда из красного дерева и с золотым теснением ;) Но оно того стоит, если действительно надо.
Ситуация, когда покупается железка с Х CPU ядрами и Y гигабайт памяти, но использовать можно только часть из этих ресурсов, потому что это регулируется условием подписки, мне видится прямо совсем дичью.
Это такая фишка IBM по выкачиванию бабла из заказчиков System Z и POWER. Типа "если вы спрашиваете какой расход топлива у этого автомобиля, значит этот автомобиль не для вас".
Вы не заметили "мелкий шрифт внизу договора" : To entitle systems with more than 1 IFL, please purchase multiples of this product. У RedHat (который нынче принадлежит IBM), кстати, точно также (что вообще лютая наглость). Лично у меня от такой "дифференциации по цвету штанов" одного продукта для разных платформ сильно пригорает, типа "z-кастомер дофига богатый раз покупает такую машину, поэтому купит и лунукс за 12K$/год на ядро" . Есть, конечно, еще убунта, с гораздо более вменяемым ценником, но это не для "корпоративщины"
Нет не за всю, а только за то что будет в LPAR с Linux для SAP.
Естественно. Речь о том, сколько придется заплатить, если нужно лицензировать аж все 28 IFL-ядер
Вы и на сервере х86 за SLES будете платить по $12 000/год за ядро. Вот только ядер у Вас будет раз в десять больше
За 2 сокета (что нынче в максимуме равно 384 ядрам) придется заплатить аж ~1500$/год. Да, на x86 такая вот "халява" в отличие от.
Диски понабятся и желательно не entry/midrange level (хотя и такие можно подключать к МФ чего я лично не рекомендую)
Уже можно подключать СХД не умеющее в FICON ? Какие например ?
С каким таким capacity? Вы посмотрели только на числа CPU.
C тем которое указано Вами в z14.
А что Вы знаете про ввод-вывод этой стойки 19"?
SAP-процессоры, каналы, i/o offload и т.д.
В целом совершенно безответственное заявление. Что Вы можете сказать про 30 летнюю давность? Приведите пример.
Что назвать 34 "ядра" (например в виде пачки S/390-машин) датацентром можно было году в 95-ом и уж точно не сегодня какие-бы волшебные технологии не были бы внутри.
Вы где такие прайсы берете? 336K$/год за 30 ядер и 5K$/год за 256. Поделитесь, пожалуйста.
Можно и бесплатно, но без обновлений и поддержки, что например для работы всякой 3rd party-корпоративщины есть моветон (тем более если решили для этого зачем-то залезть на IBM System z)
Как видно из таблички максимальное количество PUs доступных пользователю 34. Из этого набора можно под z/OS сконфигурировать максимум 6 (CP) плюс к этому 28 IFL (Integrated Faculty for Linux) 6 + 28 = 34. На IFL можно запускать Linux в LPARS, и/или zVM с Linux на виртуальных машинах.
А если вдруг захочется погонять на этих IFLях какую-нибудь корпоративщину а-ля SAP, то не забыть заплатить 12K$/год на одно IFL-ядро за, например, SLES-подписку (т.е. 336K$/год за всю машину). А еще понадобятся диски. И не с какой-нибудь entry/midrange level СХД, а с hi-end а-ля IBM DS8K с соответствующим ценником за террабайт.
Если нужен Parallel Sysplex (хотя на 6 CP много z/OS запускать смысла нет особого) то к вашим услугам ICF(Integrated Coupling Facility). Можно, например, из двух LPAR по 3 закрепленных CP сделать Sysplex из двух members. А можно сделать Sysplex из 4 z/OS LPARs с 6 СP в каждом в shared mode. И с парочкой ICF.
Это ли не Дата Центр?
C таким capacity разве что образца 30-летней давности
Бизнес, который точно знает зачем ему IBM System Z БУ-шные z-ки на барахолке не покупает, а все-таки берет у IBM за "более другой" прайс. За 50k сегодня можно взять 2-сокетный x86-сервер на 256 ядер, а за 5K$/год SLES-подписку на него на неограниченно кол-во виртуалок. За стоимость годовой SLES-подписки на указанную выше z14 можно будет взять еще пяток таких "писюков" и собрать в кластер. По capacity и price/performance это будет гораздо больше похоже на современный "дата-центр" (хоть и маленький)
IBM Sytem Z - технически великолепная платформа, но для новых проектов (а не поддержки легаси) в 99% кейсов экономически абсолютно бессмысленная (1% на всякие визы/мастеркарды, сити/жпморганы и т.д где по требованиям надежности core-систем нужны все эти z/OS-сисплексы и, соответственно, в части бюджета "мы за ценой не постоим")
Очень круто. Спасибо, что поделились. Понравилось как структурировали (сначала схема, а потом поблочное описание). Пару вопросов (если возможно): 1) сколько сегментов и ядер в самом большом GP-кластере ?; 2) Сколько людей в команде(ах), которые эту T Data Platform разрабатывают, внедряют и суппортят ?
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
Спасибо.
Интересно. Спасибо. А можете поделиться временем выполнения q78.sql из TPC-DS для варианта scale=1000 ?
А с каких резервных копий восcтанавливали, если "злоумышленник использовал доступ бывшего сотрудника, чтобы удалить резервные копии с лент" ?
Скринов из HMC вроде не было. Может хоть до паверов не добрались....
А больше HDD на одну ноду поддерживается ? Что под капотом и как обеспечивается отказоустойчивость ?
А по факту оно примерно так не только лишь всегда через пару/тройку лет от go live :) Это в ECC 6.0 все было в абапе, а в S/4HANA теперь БД-монстры, выжирающие селектом по 500+GB оперативы. И в "стандарте" в том числе.
Начиная с S/4HANA 2020 можно использовать NSE (будет как классическая CУБД работать через буффер-кэш), если с памятью совсем напряг, но, естественно с некоторым оверхедом
Для S/4HANA на 1000 конкурентных юзеров 1TB RAM БД это скорее для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
Из синхронных реплик с DR-сайта вестимо, ну если по правильному
Ну вот за прошлый год выручка Спортмастера составил 170 ярдов. Т.е. условно-примерно 465 лямов в день. Неплохо за день простоя. Безусловно каждый крупный бизнес сам выбирает надо ли оно ему это DR или "и так сойдет". А если бы не затопило и высушили за день, а сгорело ?
А DR-сайта для основных mission critical систем у федерального ритейлера нет ?
Прадедушка (E880) указанной в статье топ-машины E1180 за прошедшие 7 лет продуктивной эксплуатации выключался два раза : 1-ый для добавления CECов, 2-ой при переезде в другой ЦОД. Cам по себе не падал ни разу. Не знаю сколько это девяток, но в плане аппаратной надежности, имхо, очень неплохо. "Фирма веников не вяжет, фирма делает "гробы" ", правда из красного дерева и с золотым теснением ;) Но оно того стоит, если действительно надо.
Это такая фишка IBM по выкачиванию бабла из заказчиков System Z и POWER. Типа "если вы спрашиваете какой расход топлива у этого автомобиля, значит этот автомобиль не для вас".
Тут скорее не "кто-то", а "не только лишь все" :(
Pacemaker - зло ;) Я имел виду кластер виртуализации, скажем, к примеру, на Proxmox.
Вы не заметили "мелкий шрифт внизу договора" : To entitle systems with more than 1 IFL, please purchase multiples of this product. У RedHat (который нынче принадлежит IBM), кстати, точно также (что вообще лютая наглость). Лично у меня от такой "дифференциации по цвету штанов" одного продукта для разных платформ сильно пригорает, типа "z-кастомер дофига богатый раз покупает такую машину, поэтому купит и лунукс за 12K$/год на ядро" . Есть, конечно, еще убунта, с гораздо более вменяемым ценником, но это не для "корпоративщины"
Естественно. Речь о том, сколько придется заплатить, если нужно лицензировать аж все 28 IFL-ядер
За 2 сокета (что нынче в максимуме равно 384 ядрам) придется заплатить аж ~1500$/год. Да, на x86 такая вот "халява" в отличие от.
Уже можно подключать СХД не умеющее в FICON ? Какие например ?
C тем которое указано Вами в z14.
SAP-процессоры, каналы, i/o offload и т.д.
Что назвать 34 "ядра" (например в виде пачки S/390-машин) датацентром можно было году в 95-ом и уж точно не сегодня какие-бы волшебные технологии не были бы внутри.
https://www.suse.com/shop/server/
Можно и бесплатно, но без обновлений и поддержки, что например для работы всякой 3rd party-корпоративщины есть моветон (тем более если решили для этого зачем-то залезть на IBM System z)
А если вдруг захочется погонять на этих IFLях какую-нибудь корпоративщину а-ля SAP, то не забыть заплатить 12K$/год на одно IFL-ядро за, например, SLES-подписку (т.е. 336K$/год за всю машину). А еще понадобятся диски. И не с какой-нибудь entry/midrange level СХД, а с hi-end а-ля IBM DS8K с соответствующим ценником за террабайт.
C таким capacity разве что образца 30-летней давности
Бизнес, который точно знает зачем ему IBM System Z БУ-шные z-ки на барахолке не покупает, а все-таки берет у IBM за "более другой" прайс. За 50k сегодня можно взять 2-сокетный x86-сервер на 256 ядер, а за 5K$/год SLES-подписку на него на неограниченно кол-во виртуалок. За стоимость годовой SLES-подписки на указанную выше z14 можно будет взять еще пяток таких "писюков" и собрать в кластер. По capacity и price/performance это будет гораздо больше похоже на современный "дата-центр" (хоть и маленький)
IBM Sytem Z - технически великолепная платформа, но для новых проектов (а не поддержки легаси) в 99% кейсов экономически абсолютно бессмысленная (1% на всякие визы/мастеркарды, сити/жпморганы и т.д где по требованиям надежности core-систем нужны все эти z/OS-сисплексы и, соответственно, в части бюджета "мы за ценой не постоим")
Очень круто. Спасибо, что поделились. Понравилось как структурировали (сначала схема, а потом поблочное описание). Пару вопросов (если возможно): 1) сколько сегментов и ядер в самом большом GP-кластере ?; 2) Сколько людей в команде(ах), которые эту T Data Platform разрабатывают, внедряют и суппортят ?