«DB2 Portfolio director»… ну вот и рассказал бы как здорово строить хранилища и витрины на DB2 BLU MPP. Хотя… нет, не надо — во времена гринплумов и кликхаусов 81790$/core это за гранью вменяемости.
В деталях как обычно «дьявол». Я то может и понимаю, но могут не понять остальные читатели. z/VM и PowerVM это гипервизоры разных «уровней». А KVM на паверах ну такое себе. Был даже нативный, но вроде помер.
«Amazon EC2 and RDS — count two vCPUs as equivalent to one Oracle Processor license if
hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if
hyper-threading is not enabled.»
Надо быть очень альтернативно одаренным, чтобы вытаскивать оракл в облако на таких условиях.
Для эффективного использования хранилищ под продуктивные HANA использовали общие диски без системной репликации БД средствами SAP. Все это завернули в Active-Standby кластер SUSE HAE на базе Pacemaker. Да, время восстановления немного дольше, чем с репликацией, зато получаем экономию пространства СХД в два раза и как следствие экономию бюджета заказчика.
«немного дольше» ??? При HANA-репликации время восстановления фактически равно времени отработки takeover-команды на секондари-БД и обычно это минуты. В вашем варианте когда/если вдруг продуктивная CХД ляжет и не встанет вы будете восстанвливать дата-бекап(ы) и лог-бекапы (и хорошо если будет куда) и это точно не минуты для больших БД (о каких обьемах, кстати, речь?). Какое RTO прописано в SLA c заказчиком? Он в курсе такой «особенности» реализации продуктивного ландшафта?
Приветствую. Это понятно. Речь шла о SYSTEMDB + 1 tenant only. Действительно, технически при наличии ресурсов ничто не мешает упихать все БД тенантами в один инстанс, но есть нюансы, например, как следствие, единая версионность всех БД-тенантов (что может быть неприемлемо для конкретных SAP-систем) и репликация (и takeover) в режиме все или никто. Собственно с учетом этого при необходимости консолидации продуктивных БД на одном хосте деплоймент в MultiSID-варианте выглядит, имхо, предпочтительнее, хотя тоже не без некоторых ограничений.
MDC это все-таки далеко не «типичный корпоративный SAP-ландшафт» и для БД классичесих SAP-систем в основном делают single-tenant. Ни разу не видел, чтобы в реальном проде кто-то совмещал базы, скажем, S/4, BW, HCM в одном инстансе. MDC это больше про облачную историю, ну или DEV/QAS среды.
Спасибо за ответы. Уж простите за занудство (как говорится, у кого чего болит, да и кейс интересный), но я правильно понял, что DR внутри Azure cделан через HSR-реплики БД и ASR-реплики серверов приложений в другую AZ (т.е. как по ажуровским SAP DR best practice) или нет :)?
И еще вопрос (если NDA позволяет) — что используете в Azure для бекапов БД? Местный Azure Backup for SAP HANA или изготоваливали свою CРК?
Заказик не рассмативал варинт с multitarget-репликацией хАны ( + вторая асинхроная реплика в свой ЦОД) раз есть некоторое подменное железо?
1. При еженедельном копировании бекапов хАны получается в худшем случае RPO порядка 7 дней. Заказчик с этим согласен? При восстановлении этих бекапов на «земле» у заказчика есть необхдимое железо?
2. Если правильно понял, то для DR используете другое облако. Реплики ханы делаете HSR'ом? А серверы приложений чем и как реплицируете из Azure в «другое» облако?
Из нюансов с которыми столкнулись (не в части хАны) — Azure Site Recovery при репликации в Azure не поддерживает VMware-машинки со включенным Fault Tolerance и об этом нигде не написано в документации.
Супермикровский сервер аналогичный вашей виртуалке на 32 ядра (Xeon 6226R)+96GB+2000GB NVMе в интернетах стоит 597 054 руб.
Откуда вы взяли 3 794 496 / 2 можно только догадываться.
На вашем тарифе «SSD MEDIUM» для 2TB мы получим аж целых ....2000 IOPS, а если в вашем же конфигураторе выбрать топовый «SSD MAX» (60 000 IOPS) хоть чуть-чуть соответсвующий NVM'е диску в своем сервере, то внезапно получим ...185 285 руб в месяц.
Ну какой же это shared nothing. Это вполне себе shared disk.
В scale-out-кластере хАны у каждой ноды свои датаволюмы и они не шарятся. Так что логически это вполне себе shared-nothing хоть и физически обычно лежит на одной СХД («shared-disk») ;)
Думал, в части OLAP у них в основном Netezza, а оказывается и такое есть.
Netezza по факту уже давно мертва, с DB2 BLU/DPF ситуация не сильно лучше «благодаря» «усилиям» голубого гиганта. В этой нише они старательно и целенаправлено «прос… ли все полимеры».
Но ведь это тоже сертификация, только ей занимается не поставщик оборудования, а непосредственно клиент
Да нет никакой сертификации «на клиенте». Теперь даже тест HWCCT не обязательно прогонять перед Go-Live ;)
Вот на счёт и т. д. – можно поподробнее?
Я имел ввиду, что ничто не мешает запилить свое собственное MPP DWH на хАне без BW-блекджека, но, честно признаться, мне про такие кейсы неизвестно (что не означает, что их нет). Да и вообще очень похоже, что SAP'у не сильно интересно продвижение HANA'ы в качестве универсальной СУБД (по большей части сделано «под себя»).
классифицировать СУБД по какому-то одному признаку я считаю категорически неправильным.
Да тут дело не в классификации, а скорее в том, что есть и чего нет в конкретной СУБД. У той же DB2 есть как shared-nothing кластер для OLAP задач (DPF+BLU) так и shared-disk кластер для OLTP задач (pureScale). У HANA'ы по-сути только shared-nothing для OLAP.
SAP HANA работает не только на x86, но и на IBM POWER
В продуктивную эксплуатацию допускаются не только сертифицированные апплайнсы с фиксированным core-to-memory, но и серверы из списка supported systems в SAP HANA hardware directory в конфигурациях от 16ти ядер и 128ми GB по модели TDI5 и workload sizing.
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д) (за очень редким и специфическим исключением а-ля очень большие SAP S/4HANA ERP). Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.
для IBM i на IBM POWER не выполняется.
hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if
hyper-threading is not enabled.»
Надо быть очень альтернативно одаренным, чтобы вытаскивать оракл в облако на таких условиях.
feel the difference again
Аналогичный по ресурсам DELL R640 c трехлетним ProuspportPlus (4hour) ~ 31700$, ну пусть еще по 100$ в месяц (3600$) за 1U-коло в TIER3 ЦОДе.
«feel the difference» ©
«немного дольше» ??? При HANA-репликации время восстановления фактически равно времени отработки takeover-команды на секондари-БД и обычно это минуты. В вашем варианте когда/если вдруг продуктивная CХД ляжет и не встанет вы будете восстанвливать дата-бекап(ы) и лог-бекапы (и хорошо если будет куда) и это точно не минуты для больших БД (о каких обьемах, кстати, речь?). Какое RTO прописано в SLA c заказчиком? Он в курсе такой «особенности» реализации продуктивного ландшафта?
Спасибо за пост. Интересный кейс.
И еще вопрос (если NDA позволяет) — что используете в Azure для бекапов БД? Местный Azure Backup for SAP HANA или изготоваливали свою CРК?
Заказик не рассмативал варинт с multitarget-репликацией хАны ( + вторая асинхроная реплика в свой ЦОД) раз есть некоторое подменное железо?
По №7 пару вопросов:
1. При еженедельном копировании бекапов хАны получается в худшем случае RPO порядка 7 дней. Заказчик с этим согласен? При восстановлении этих бекапов на «земле» у заказчика есть необхдимое железо?
2. Если правильно понял, то для DR используете другое облако. Реплики ханы делаете HSR'ом? А серверы приложений чем и как реплицируете из Azure в «другое» облако?
Из нюансов с которыми столкнулись (не в части хАны) — Azure Site Recovery при репликации в Azure не поддерживает VMware-машинки со включенным Fault Tolerance и об этом нигде не написано в документации.
Откуда вы взяли 3 794 496 / 2 можно только догадываться.
На вашем тарифе «SSD MEDIUM» для 2TB мы получим аж целых ....2000 IOPS, а если в вашем же конфигураторе выбрать топовый «SSD MAX» (60 000 IOPS) хоть чуть-чуть соответсвующий NVM'е диску в своем сервере, то внезапно получим ...185 285 руб в месяц.
Вот такое вот ....«TСО»
В scale-out-кластере хАны у каждой ноды свои датаволюмы и они не шарятся. Так что логически это вполне себе shared-nothing хоть и физически обычно лежит на одной СХД («shared-disk») ;)
Netezza по факту уже давно мертва, с DB2 BLU/DPF ситуация не сильно лучше «благодаря» «усилиям» голубого гиганта. В этой нише они старательно и целенаправлено «прос… ли все полимеры».
Да нет никакой сертификации «на клиенте». Теперь даже тест HWCCT не обязательно прогонять перед Go-Live ;)
Я имел ввиду, что ничто не мешает запилить свое собственное MPP DWH на хАне без BW-блекджека, но, честно признаться, мне про такие кейсы неизвестно (что не означает, что их нет). Да и вообще очень похоже, что SAP'у не сильно интересно продвижение HANA'ы в качестве универсальной СУБД (по большей части сделано «под себя»).
Да тут дело не в классификации, а скорее в том, что есть и чего нет в конкретной СУБД. У той же DB2 есть как shared-nothing кластер для OLAP задач (DPF+BLU) так и shared-disk кластер для OLTP задач (pureScale). У HANA'ы по-сути только shared-nothing для OLAP.
SAP HANA работает не только на x86, но и на IBM POWER
В продуктивную эксплуатацию допускаются не только сертифицированные апплайнсы с фиксированным core-to-memory, но и серверы из списка supported systems в SAP HANA hardware directory в конфигурациях от 16ти ядер и 128ми GB по модели TDI5 и workload sizing.
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д) (за очень редким и специфическим исключением а-ля очень большие SAP S/4HANA ERP). Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.