All streams
Search
Write a publication
Pull to refresh
1
0
Send message

Проблема проявляется лишь на дистанции. Через 3-5 лет собственное железо окупается, а облачная аренда – история бесконечная. То есть уже через 4-5 лет совокупные затраты плюс-минус выравнятся, а дальше собственный дата-центр начнет работать в плюс.

Если говорить про чистый IaaS и листовые цены, то собственное железо окупается в среднем за 10-12 месяцев в аналогичных ресурсах CPU/RAM/SSD и аренде стойки в Tier-3 ЦОД. Т.е работать в плюс начинает практически со 2-го года. Но и облачники, если им интересно затащить к себе конкретного клиента, бывает дают соответствующую скидку.

В кластере, собранном из двух СХД (scale-out), полный отказ одного контроллерного шасси логичным образом приводит к недоступности всех его дисков для "живой" полки. Только это происходит не в момент отказа системного диска, а когда контроллеры полки полностью недоступны. Такой сценарий - достаточно маловероятен даже при таком серьёзном сбое как авария системного диска.

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

  1. HP ушел из России, т.п вам будут оказывать менеджеры, которые вам продали msa из серого импорта.

Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.

Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.

А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?

А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы?

Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)

Но когда кейсов уже стало несколько десятков, пришлось искать другое решение. 

Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)

Интересно. Спасибо. А можете поделиться временем выполнения q78.sql из TPC-DS для варианта scale=1000 ?

Восстановление контроллеров домена и серверов 1С из резервных копий заняло несколько дней.

А с каких резервных копий восcтанавливали, если "злоумышленник использовал доступ бывшего сотрудника, чтобы удалить резервные копии с лент" ?

Скринов из HMC вроде не было. Может хоть до паверов не добрались....

  • 3-12 HDD – для хранения данных

А больше HDD на одну ноду поддерживается ? Что под капотом и как обеспечивается отказоустойчивость ?

А по факту оно примерно так не только лишь всегда через пару/тройку лет от 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), что практически фантастика :)

а базы данных с состоянием до ЧП откуда?

Из синхронных реплик с DR-сайта вестимо, ну если по правильному

Ну вот за прошлый год выручка Спортмастера составил 170 ярдов. Т.е. условно-примерно 465 лямов в день. Неплохо за день простоя. Безусловно каждый крупный бизнес сам выбирает надо ли оно ему это DR или "и так сойдет". А если бы не затопило и высушили за день, а сгорело ?

А DR-сайта для основных mission critical систем у федерального ритейлера нет ?

Прадедушка (E880) указанной в статье топ-машины E1180 за прошедшие 7 лет продуктивной эксплуатации выключался два раза : 1-ый для добавления CECов, 2-ой при переезде в другой ЦОД. Cам по себе не падал ни разу. Не знаю сколько это девяток, но в плане аппаратной надежности, имхо, очень неплохо. "Фирма веников не вяжет, фирма делает "гробы" ", правда из красного дерева и с золотым теснением ;) Но оно того стоит, если действительно надо.

Ситуация, когда покупается железка с Х CPU ядрами и Y гигабайт памяти, но использовать можно только часть из этих ресурсов, потому что это регулируется условием подписки, мне видится прямо совсем дичью.

Это такая фишка IBM по выкачиванию бабла из заказчиков System Z и POWER. Типа "если вы спрашиваете какой расход топлива у этого автомобиля, значит этот автомобиль не для вас".

Тут скорее не "кто-то", а "не только лишь все" :(

замечательный самопадающий кластер SLES HA, надёжность которого по факту намного меньше надёжности каждого из узлов.

Pacemaker - зло ;) Я имел виду кластер виртуализации, скажем, к примеру, на Proxmox.

5 Year Subscription

CA$  58,491.00

Вопрос: где 336K$/год?

Вы не заметили "мелкий шрифт внизу договора" : 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. Поделитесь, пожалуйста.

https://www.suse.com/shop/server/

Я несколько лет работал с SuSe на МФ. Бесплатно.

Можно и бесплатно, но без обновлений и поддержки, что например для работы всякой 3rd party-корпоративщины есть моветон (тем более если решили для этого зачем-то залезть на IBM System z)

Information

Rating
6,184-th
Registered
Activity