И что? Лицензии. Да, старые on-premise лицензии формально можно использовать на арендованном железе. Но вы хоть раз читали EULA SAP целиком? Там написано, что для использования в облачной среде (даже приватной) нужны специальные условия или покупка подписки
Все, что нужно из "cпециальных условий", это использовать сертифицированные инстансы (для SAP HANA) в случае паблик-клаудов или инфру у приватного провайдера имеющего сертификат SAP Hosting Provider (на что в реальной жизни все забивают, а SAP по-факту никак реально не проверяет). И никаких подписок для хостинга смигрированных on-prem-систем не нужно
Компании с многомиллиардными оборотами не могут позволить себе висеть на волоске.Логично,да?
Несколько российких компаний с ежегодной выручкой в 200-400 ярдов смигрировали свои SAP-ландшафты к российским облачным провайдерам и вполне себе неплохо там живут. Внезапно, да ?
Ты будешь сам дорабатывать SAP? Под ключ? На коленке?
Именно это и делают сейчас крупные российские SAP-кастомеры ну или ходят к LAB SP и иже с ними
Найди мне команду, которая сейчас может качественно поддерживать SAP без вендора, да ещё и за адекватные деньги. Таких единицы, и стоят они бешеных денег.
Открываешь последний рейтинг sap-аутсорсеров, выбираешь первых трех, сталкиваешь лбами на конкурсе, выбираешь лучшее предложение. Один из ритейлеров прямо сейчас это делает. Или кормишь свою sap-"армию", или чужую или мигрируешь в 1С с сохранением бизнес-процессов :)))
В курсе, что с 2025 года ERP-системы в России планируют приравнять к объектам критической информационной инфраструктуры? Если это произойдёт, использование иностранного ПО на значимых объектах КИИ станет вне закона.
В курсе. И там не все так однозначно с категорированием
Переезд ERP для такой сети это не перенос виртуалок, это изменение всех бизнес-процессов.
Класический переезд в облако - это lift and shift миграция, никаких изменений бизнес-процессов реализованных в мигрируемых системах не предусматривающая. Если у вас по другому, то могу только посочувствовать.
Бизнесу нужно работающее, развивающееся, легальное и безопасное решение.
Бизнес, особенно крупный, сам решит ,что ему нужно в текущих условиях с учетом затрат и рисков, а всяких аналитиков и админов спросит об этом в последюю очередь (если вообще спросит).
Так что не надо мне тут рассказывать про приватные кластеры...
Слушайте, у вас либо два с половиной магазина, которые вы так лихо "переносите" (но тогда вопрос откуда вообще деньги на лицензионный SAP/Oracle?), либо вы теоретик.
C ритейлом не связан. SAP-ландшафты на полсотни систем таскал и туда и обратно.
В нормальном, 100% ритейле такой "переезд как есть" невозможен просто исходя из того, что это незаконно.
Что именно незаконно ? Перенести к российскому облачному провайдеру на приватый vmware-кластер или выделенные bare-metal ?
В процитированной мной вашей фразе утверждается, что переехать как есть невозможно. По факту - вполне себе возможно и делается много кем. А чтобы после переезда "не было мучительно больно" и нужны те самые "навыки" и некоторый специфический опыт (ну чтоб например архитектор облачного провайдера не предлагал "расшардить базу данных этой вашей SAP S/4HANA")
Сначала планируется категорирование объектов с обязательным аудитом текущих платформ. Затем предусмотрена миграция на отечественные аналоги с сохранением ключевых бизнес‑процессов. Такой подход должен минимизировать риски простоев.
Произошла по истине великая миграция СУБД. Это одна из самых драматичных глав трансформации.
Ох уж эти сказочники-импортозаместители....Произошла она (но это не точно) в основном в госухе (которая денег не считает) и по понятными причинам. Коммерсы за редким исключением продолжают сидеть на "Oracle, Microsoft SQL Server и DB2" ибопривозить себе собственными руками и за свой счет геморой на голову проблемы с давно и нормально работающими системами дураков желающих не особо много. А самое главное "чтобы что?"
Открытая СУБД PostgreSQL из «одной из опций» превратилась в стратегический стандарт.
Как говорится "на безрыбье и рак рыба"
Её российские форки (Postgres Pro) предложили дополнительные функции и коммерческую поддержку, что было важно для крупных предприятий.
Еще бы ценник адекватный они предложили за свои "дополнительные функции и коммерческую поддержку" форка опенсорного продукта. А так да - "куй железо не отходя от кассы!"
Проблема проявляется лишь на дистанции. Через 3-5 лет собственное железо окупается, а облачная аренда – история бесконечная. То есть уже через 4-5 лет совокупные затраты плюс-минус выравнятся, а дальше собственный дата-центр начнет работать в плюс.
Если говорить про чистый IaaS и листовые цены, то собственное железо окупается в среднем за 10-12 месяцев в аналогичных ресурсах CPU/RAM/SSD и аренде стойки в Tier-3 ЦОД. Т.е работать в плюс начинает практически со 2-го года. Но и облачники, если им интересно затащить к себе конкретного клиента, бывает дают соответствующую скидку.
В кластере, собранном из двух СХД (scale-out), полный отказ одного контроллерного шасси логичным образом приводит к недоступности всех его дисков для "живой" полки. Только это происходит не в момент отказа системного диска, а когда контроллеры полки полностью недоступны. Такой сценарий - достаточно маловероятен даже при таком серьёзном сбое как авария системного диска.
Понятно. Спасибо. Т.е. получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность. А у нетаппов также ?
HP ушел из России, т.п вам будут оказывать менеджеры, которые вам продали msa из серого импорта.
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Но когда кейсов уже стало несколько десятков, пришлось искать другое решение.
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
Конечно нет - https://www.comnews.ru/content/231780/2024-02-28/2024-w09/1008/rossiyskie-zakazchiki-uvideli-buduschee-dlya-sap-sistem-oblakakh .Это все вранье облачных провайдеров и больные фантазии админов таскающих виртуалки. Компания из приведенного вами списка имеет интересный облачный SAP-кейс (теперь, правда, гибридный), но вам почему-то про него в интернетах не рассказали, как и про многие другие.
Все, что нужно из "cпециальных условий", это использовать сертифицированные инстансы (для SAP HANA) в случае паблик-клаудов или инфру у приватного провайдера имеющего сертификат SAP Hosting Provider (на что в реальной жизни все забивают, а SAP по-факту никак реально не проверяет). И никаких подписок для хостинга смигрированных on-prem-систем не нужно
Несколько российких компаний с ежегодной выручкой в 200-400 ярдов смигрировали свои SAP-ландшафты к российским облачным провайдерам и вполне себе неплохо там живут. Внезапно, да ?
Именно это и делают сейчас крупные российские SAP-кастомеры ну или ходят к LAB SP и иже с ними
Открываешь последний рейтинг sap-аутсорсеров, выбираешь первых трех, сталкиваешь лбами на конкурсе, выбираешь лучшее предложение. Один из ритейлеров прямо сейчас это делает. Или кормишь свою sap-"армию", или чужую
или мигрируешь в 1С с сохранением бизнес-процессов :)))В курсе. И там не все так однозначно с категорированием
Класический переезд в облако - это lift and shift миграция, никаких изменений бизнес-процессов реализованных в мигрируемых системах не предусматривающая. Если у вас по другому, то могу только посочувствовать.
Бизнес, особенно крупный, сам решит ,что ему нужно в текущих условиях с учетом затрат и рисков, а всяких аналитиков и админов спросит об этом в последюю очередь (если вообще спросит).
Да не больно то и хотелось.
Действительно, достаточно уже нейрослопа.
C ритейлом не связан. SAP-ландшафты на полсотни систем таскал и туда и обратно.
Что именно незаконно ? Перенести к российскому облачному провайдеру на приватый vmware-кластер или выделенные bare-metal ?
В процитированной мной вашей фразе утверждается, что переехать как есть невозможно. По факту - вполне себе возможно и делается много кем. А чтобы после переезда "не было мучительно больно" и нужны те самые "навыки" и некоторый специфический опыт (ну чтоб например архитектор облачного провайдера не предлагал "расшардить базу данных этой вашей SAP S/4HANA")
Да, в общем, без особых проблем. Вопрос времени на подготовку и технических навыков участников процесса. Проверено неоднократно.
[из-за кулис раздаётся гомерический хохот]Сбер мигрирует на коммерческий Pangolin. ВТБ своими core-системами мигрирует на ванильку ? Или может все-таки на реестровый форк за деньги ?
Ох уж эти сказочники-импортозаместители....Произошла она (но это не точно) в основном в госухе (которая денег не считает) и по понятными причинам. Коммерсы за редким исключением продолжают сидеть на "Oracle, Microsoft SQL Server и DB2" ибо привозить себе собственными руками и за свой счет
геморой на головупроблемы с давно и нормально работающими системамидураковжелающих не особо много. А самое главное "чтобы что?"Как говорится "на безрыбье и рак рыба"
Еще бы ценник адекватный они предложили за свои "дополнительные функции и коммерческую поддержку" форка опенсорного продукта. А так да - "куй железо не отходя от кассы!"
Cпасибо, что поделились. Редко кто отвечает на вопросы про ТТХ инфры.
А сколько было ядер на оракле (single instance или RAC/Exadata ?) и сколько стало на шардмане с учетом всех шардов и их реплик ?
Спасибо за кейс.
Какие ресурсы (кол-во ядер, объем памяти) были на БД-хостах с ораклом и теперь на панголине ?
Приложения переписывать под панголин не пришлось ?
Т.е. наличие Arenadata DB в списке форков PostgreSQL нисколько не смущает?
Вы точно "менеджер по развитию решений СУБД"?
Если говорить про чистый IaaS и листовые цены, то собственное железо окупается в среднем за 10-12 месяцев в аналогичных ресурсах CPU/RAM/SSD и аренде стойки в Tier-3 ЦОД. Т.е работать в плюс начинает практически со 2-го года. Но и облачники, если им интересно затащить к себе конкретного клиента, бывает дают соответствующую скидку.
Понятно. Спасибо. Т.е. получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность. А у нетаппов также ?
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
Спасибо.
Интересно. Спасибо. А можете поделиться временем выполнения q78.sql из TPC-DS для варианта scale=1000 ?
А с каких резервных копий восcтанавливали, если "злоумышленник использовал доступ бывшего сотрудника, чтобы удалить резервные копии с лент" ?