Обновить
4

Пользователь

0,1
Рейтинг
Отправить сообщение

Кроме того, особое внимание следует уделять памяти. Ее размер определяется количеством данных, которые в ней должны быть сохранены.

Нет. Памяти по бест-практикам должно быть 2x от обьема данных. На практике, как миимум 1.5x.

По нашему опыту в крупных проектах SAP HANA требует под себя платиновых процессоров и 3 ТБ оперативной памяти. 

Чтож не "бриллиантовых" то ? :) Часто по процессорам хАны бывают весьма недозагружены и за "платину" можно не переплачивать и вполне обойтись Gold 6252/6254, а 3TB это скорее средний проект, нежели крупный.

Оценить решение на практике можно через сайт. В техническом аспекте построения инфраструктуры #CloudMTS работает по модели Tailored Datacenter Integration — используем сконфигурированные и оптимизированные программно-аппаратные комплексы, позволяющие оперативно развернуть высокопроизводительную среду ландшафтов на базе SAP HANA.  

В вашем КП двухмесячной давности (еще до известных событий) на 3TB машины сказано : "Срок активации выделенных ресурсов частного облака и выделенного оборудования –45-50 недель с даты подписания договора с учетом текущей ситуации на рынке производства полупроводников"

Т.е. в наличии у вас их нет и клиенту предлаается почти год подождать пока вы их закупите и проинсталите ? ;-)

По результатам проекта успешно решена основная задача — обеспечение полной функциональности ERP-системы SAP BW∕4 HANA

BW/4HANA это не ERP. Это отчетно/аналитическая система.

А почему ваш конфигуратор на голдах 63XX дает только 1 процессор ? Только односокетные платформы доступны ? А 2049U-TR4 на 3TB RAM можете собрать ? ;-)

А сколько у вас девопсов на "вот это все", если не секрет ? За статью спасибо.

А если нужно обеспечить высокую доступность реляционных баз данных, то лучше сделать это на уровне СУБД. В этом сценарии приветствуется хорошее знание ее ролевой модели. Правильная настройка ролевой модели помогает распределить транзакции перед переключением на реплику БД: какие-то транзакции закоммитить, какие-то откатить.    

Можно здесь "на пальцах" пояснить о чем речь ? Ролевая модель это обычно про секурити, да и что за "рапределение транзакий" (и зачем) при переключении на реплику непонятно.

Упс....прошу прощения, пропустил. В основном на S4 проблема с неоптимальными СDS выедающими кучу памяти (у нас лимит 400GB и иногда в закрытие приходится крактовременно увеличивать). Тот же "всеми любимый" J_3RMOBVEDH теперь сделан ADMP-процедурой и тоже ест памяти (пришлось на него сделать workload class на 200GB лимита)

Спасибо за статью. А то, что на 11a репорт "Protected VM's" для всех машин со включенным Fault Tolerance говорит, что "Unprotected Time: No Backup", а бекапы свежие вполне себе лежат на репе это бага или фича ?

Большое спасибо за ответы, но появляются еще вопросы (тема «больная») :)

1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.

Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?

В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)
Cкорее всего увидите много «открытий чудных» и мемори-лимит придется раза в два приподнять ;)
Спасибо, что поделились опытом. Очень интересно.

Если не NDA (ну вдруг), то можете рассказать поподробнее?:
1) реплика на которую преключаетесь находится локально в том же ЦОДе? А для DR есть offsite-реплика?
2) у вас реплики под управлением Pacemaker-кластера или просто primary-secondary с ручным takeover'ом?
3) реплика с preload_column_tables = true?
4) сколько выставлен tables_preloaded_in_parallel? И какая скорость чтения с диска при стартапе без FastRestart'а.
5) при таких ресурсах (12TB+448core) и 10K юзеров во сколько выставлены default_statement_concurrency_limit и statement_memory_limit?
6) ECC или S4? :)

Из того как боремся сами (объемы, правда, поменьше): кручение параметров по нотам при различных утечках в разных аллокаторах на разных ревиженах, reload_tables=false на копиях прода, workload-классы для особо прожорливых репортов/транзакций и непонятливых юзеров ну и resman shrink если уж совсем апож. Смотрим на NSE, который теперь можно в ECC/S4.

С logreplay есть «дьявол в деталях» — если на реплике выставлен preload_column_tables = false, то indexserver все-равное будет лопать память аллокатором Pool/ColumnStore и чем дольше реплика работает — тем больше. Поэтому при совмещении реплики с препродом/тестом приходится играться с GAL и периодически передергивать реплику или переходить на delta_datashipping, в котором такого нет.
Я всего лишь ненавязчиво предложил Вам воспользоваться Вашим же советом «проверьте факты», но, видимо, Вы советы умеете только раздавать, а заодно разводить soviet-style-демагогию (чувствуется «старая школа») на ровном месте
Похоже Вам действительно пора на заслуженный отдых. За сим откланиваюсь и убегаю «щелкать семечки и обсуждать девах».
Кто, где и когда придумал RDBMS и SQL знает любой. Факт в том, что первый релиз конкретно DB2 стал коммерчески доступным только через несколько лет после аналогичного у Oracle (каким бы он не был). А в 85-ом оракл вообще был уже 5-ой версии.
DB2 на МФ появилось раньше Оракла. Оракл слизал идей реляционных баз данных из журнала где ИБМ-вцы о них рассказывали. В то время Боинг уже использовал System R* — предтечу, опытный вариант реляционной базы данных на МФ. Потом появилась SQL/DS — BD for VM. Потом Оракл, и почти сразу DB2 for MVS. Речь идет о коммерческих продуктах, не опытных.

DB2 Version 1 Release 1 was announced on June 7, 1983, and it became generally available on Tuesday, April 2, 1985.

Although they created a commercial version of RDBMS in 1977, it wasn't available for sale until 1979 with the launch of Oracle version 2.

Так что не раньше, а позже, аж на 6 лет.
«DB2 Portfolio director»… ну вот и рассказал бы как здорово строить хранилища и витрины на DB2 BLU MPP. Хотя… нет, не надо — во времена гринплумов и кликхаусов 81790$/core это за гранью вменяемости.
В деталях как обычно «дьявол». Я то может и понимаю, но могут не понять остальные читатели. z/VM и PowerVM это гипервизоры разных «уровней». А KVM на паверах ну такое себе. Был даже нативный, но вроде помер.
Ваше право, но аналогов SAP-процессоров на IBM POWER нет.
PowerVM это аналог PR/SM, а не z/VM.
«Extensive input-output («I/O») facilities with the ability to offload to separate engines»

для IBM i на IBM POWER не выполняется.
«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.»

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

feel the difference again
AWS Frankfurt, r5a.24xlarge (96VCPU+768GB RAM) + 3500GB Provisioning IOPS io2 (50000 IOPS) 3year reserved instance = 6,074.23 USD, т.е. на 36 месяцев — 218,672$

Аналогичный по ресурсам DELL R640 c трехлетним ProuspportPlus (4hour) ~ 31700$, ну пусть еще по 100$ в месяц (3600$) за 1U-коло в TIER3 ЦОДе.

«feel the difference» ©
Для эффективного использования хранилищ под продуктивные HANA использовали общие диски без системной репликации БД средствами SAP. Все это завернули в Active-Standby кластер SUSE HAE на базе Pacemaker. Да, время восстановления немного дольше, чем с репликацией, зато получаем экономию пространства СХД в два раза и как следствие экономию бюджета заказчика.

«немного дольше» ??? При HANA-репликации время восстановления фактически равно времени отработки takeover-команды на секондари-БД и обычно это минуты. В вашем варианте когда/если вдруг продуктивная CХД ляжет и не встанет вы будете восстанвливать дата-бекап(ы) и лог-бекапы (и хорошо если будет куда) и это точно не минуты для больших БД (о каких обьемах, кстати, речь?). Какое RTO прописано в SLA c заказчиком? Он в курсе такой «особенности» реализации продуктивного ландшафта?

Спасибо за пост. Интересный кейс.
Приветствую. Это понятно. Речь шла о SYSTEMDB + 1 tenant only. Действительно, технически при наличии ресурсов ничто не мешает упихать все БД тенантами в один инстанс, но есть нюансы, например, как следствие, единая версионность всех БД-тенантов (что может быть неприемлемо для конкретных SAP-систем) и репликация (и takeover) в режиме все или никто. Собственно с учетом этого при необходимости консолидации продуктивных БД на одном хосте деплоймент в MultiSID-варианте выглядит, имхо, предпочтительнее, хотя тоже не без некоторых ограничений.

Информация

В рейтинге
4 125-й
Зарегистрирован
Активность