Чи можна? Звісно, міграція SAP-систем — це складний і копіткий процес, успіху якого важлива злагоджена робота всіх учасників. А якщо міграція проводиться у стислий термін — завдання багаторазово ускладнюється. Не всі наважуються на це. Причин може бути кілька. Наприклад, процес сам собою тривалий і організаційно складний. Плюс є ризик незапланованих простоїв систем. Або клієнти не впевнені, що, переживши таку операцію, отримають бенефіти, пропорційні витраченим зусиллям. Однак бувають і винятки.
Під катом розповімо про труднощі, з якими стикаються замовники в процесі міграції та супроводу SAP-систем, обговоримо, чому стереотипи не завжди відповідають реальності, і поділимося кейсом, як нам вдалося мігрувати системи замовника до нової інфраструктури всього за три з лишком місяці.
Хостинг SAP-систем
Ще якихось п'ять років тому важко було припустити, що клієнти масово почнуть використовувати хостингові ресурси для SAP-додатків. Найчастіше їх впроваджували on-premise. Однак з розвитком моделей аутсорсингу та ринку хмарних послуг світогляд замовників почав змінюватися. Які аргументи впливають на вибір на користь хмари для SAP?
- Для новачків, які тільки запланували впровадження SAP, хмарна інфраструктура – це практично стандартний вибір – масштабованість ресурсів під поточну потребу системи та небажання відволікати ресурси на розвиток непрофільних компетенцій.
- У компаніях з великим системним ландшафтом за допомогою хостингу SAP-систем CIO виходять якісно інший рівень управління ризиками, т.к. за SLA відповідає партнер.
- Третій із найчастіше зустрічаються аргументів – висока вартість побудови інфраструктури для реалізації сценаріїв високої доступності та DR.
- Фактор 2027 – анонсоване вендором припинення підтримки застарілих систем у 2027 році. Це означає переведення БД на HANA, що тягне за собою витрати на модернізацію та закупівлю нових обчислювальних потужностей.
Ринок SAP-хостингу в Росії зараз можна вважати досить зрілим. І це надає широкі можливості для клієнтів, які хочуть змінити свої хостинг-платформи. Однак такі проекти слушно можуть викликати побоювання у бізнесу через складність процедури міграції. Це змушує замовників пред'являти підвищені вимоги до постачальників послуг, які повинні мати не тільки виняткові компетенції з хостингу та супроводу систем SAP, але й успішний досвід у галузі міграції.
У чому складність зміни SAP-хостингу?
Хостинги бувають різні. Невідповідність заявленому рівню сервісу, безліч «але» та зірочок з застереженнями дрібним текстом, обмеженість ресурсів та можливостей хостинг-провайдера, відсутність гнучкості в питаннях комунікації з клієнтом, бюрократія, технічні обмеження, низька компетентність фахівців технічної підтримки, а також багато інших нюансів лише мала частина підводного каміння, з якими можуть зіткнутися клієнти в процесі експлуатації їхніх бізнес-систем в аутсорсингових інфраструктурах. Найчастіше для клієнта все це залишається в тіні, в нетрях багатосторінкового контракту і спливає вже в процесі користування послугами.
Якийсь момент для замовника стає очевидним, що рівень сервісу, який він отримує, далекий від його очікувань. Це є деяким каталізатором до пошуку рішень щодо виправленню ситуації й у разі неуспіху, коли проблеми накопичуються до краю і стає дуже боляче, переходять до активних дій щодо опрацювання альтернативних варіантів у напрямі зміни постачальника послуги.
Чому тягнуть до останнього? Причина проста — процес перенесення систем для клієнтів не завжди є прозорим і зрозумілим. Клієнту важко оцінити дійсні ризики, пов'язані з процесом міграції. Можна сказати, що міграція для клієнтів — це своєрідна чорна скринька: незрозуміло, ціна, час простою систем, ризики і як їх нівелювати, та й взагалі темно та страшно. Адже тут як, якщо не вийде, то голови полетять і у топів, і у виконавців.
SAP – це системи корпоративного рівня, складні та м'яко кажучи не дешеві. На їхнє впровадження, доопрацювання, супровід витрачаються пристойні бюджети і від їхньої доступності та коректної роботи залежить життєдіяльність підприємства. А тепер уявіть наслідки зупинки якогось великого виробництва. Це фінансові втрати, які можуть обчислюватися цифрами з великою кількістю нулів, а також репутаційні та інші не менш значущі ризики.
Розберемо складнощі, які можуть виникнути на кожному з етапів на кейсі міграції SAP-систем одного з наших замовників.
Підготовка та проектування
Міграція - це формула з безліччю різних складових. І одним із найважливіших є етап проектування та підготовки цільової (нової) інфраструктури.
Нам необхідно було поринути у існуючу реалізацію систем, їхню архітектуру. У цільовій інфраструктурі ми десь повторили існуючі рішення, в якихось моментах доповнили та покращили, десь переробили, продумали та вибрали рішення щодо забезпечення відмовостійкості та доступності, а також максимально консолідували всі ресурси.
У процесі проектування було виконано багато різних вправ, які в результаті дозволили максимально підготуватися до міграції та врахувати всілякі нюанси та підводні камені (про них пізніше).
Що в нас в результаті вийшло — індивідуально спроектована інфраструктура приватної хмари на базі нашого ЦОДу:
- виділені фізичні сервери для SAP HANA;
- платформа віртуалізації VMware для серверів програм та інфраструктурних сервісів;
- дубльовані канали зв'язку між ЦОД для L2 VPN;
- дві основні СХД для поділу продуктива та «всього решти»;
- СРК на базі Veritas Netbackup з окремим сервером, дисковою полицею та стрічковою бібліотекою.
А ось як реалізували все це з технічного погляду.
SAP
- Для ефективного використання сховищ під продуктивні HANA використовували спільні диски без системної реплікації БД засобами SAP. Все це загорнули у Active-Standby кластер SUSE HAE на базі Pacemaker. Так, час відновлення трохи довший, ніж із реплікацією, натомість отримуємо економію простору СГД у два рази і як наслідок економію бюджету замовника.
- У препродуктивних середовищах від кластерів HANA відмовилися, але технічно повторили конфігурацію продуктива.
- Тестові середовища та середовища розробки рознесли ще кілька серверів без кластерів у конфігурації MCOS.
- Всі сервери програм віртуалізували і розмістили в VMware.
Сети
- Фізично розділили контури мереж управління та продуктивних мереж стеками комутаторів, загорнувши продуктивні у бік ЦОД замовника.
- Заклали достатньо мережевих інтерфейсів, щоб не змішувати великі потоки трафіку.
- Для передачі з СХД зробили класичні FC SAN фабрики.
SHD
- Продуктивне та препродуктивне навантаження SAP залишили на all-flash масиві.
- Тестові середовища розробників та інфраструктурні послуги помістили на окремий гібридний масив.
СПК
- Зробили з урахуванням Veritas Netbackup.
- Дещо дописали вбудовані скрипти, щоб бекапити MCOS-конфігурації.
- Оперативні копії поклали на дискову полицю, щоб швидко відновитись, а для довгострокового зберігання використовуємо стрічки.
моніторинг
- Усі залізо, ОС та SAP завели під Zabbix.
- Зібрали безліч корисних дашбордів у Grafana.
- У разі виникнення алерту Zabbix вміє заводити заявку в системі управління інцидентами, у нас вона реалізована на Jira. Також інформація дублюється у Telegram-канал.
Telegram
Загальний стан HANA
Стан сервера програм SAP:
Інфраструктурні сервіси
- Для обслуговування внутрішніх просторів імен підняли кластер DNS-серверів, який синхронізується із серверами замовника.
- Зробили окремий файловий сервер обмінюватись даними.
- Щоб зберегти різні конфігурації, додали Gitlab.
- Для різноманітної Sensitive-інформації взяли HashiCorp Vault.
Процес міграції
У випадку процес міграції складається з наступних етапів:
- підготовка всієї необхідної проектної документації;
- переговори з поточним провайдером - вирішення організаційних питань;
- закупівля, доставка та встановлення нового обладнання під проект;
- тестова міграція та налагодження процесу;
- перенесення систем, бойова міграція.
Наприкінці жовтня 2019 року ми підписали контракт, далі спроектували архітектуру, а після її узгодження із замовником замовили необхідне обладнання.
На що потрібно звернути увагу в першу чергу терміни постачання обладнання. У середньому постачання сертифікованого заліза під SAP NAHA, що відповідає вимогам виробника програмного забезпечення до апаратних платформ, займає 10-12 тижнів. А з урахуванням сезонності (реалізація проекту випадала якраз на новий рік) — цей термін міг збільшитися ще на місяць. Відповідно, потрібно максимально прискорити процес: працювали з дистриб'ютором-постачальником, домовлялися про прискорену доставку літаками (замість сухопутних та морських шляхів).
Листопад та грудень пішли на те, щоб виконати підготовку до міграції та отримати частину обладнання. Підготовку ми провели на тестовому стенді в нашій публічній хмарі, де відпрацювали всі основні кроки та відловили можливі складнощі та проблеми:
- підготували детальний план взаємодії учасників проектних команд із щохвилинними таймінгами;
- побудували тестовий стенд для БД та серверів додатків приблизно так само, як у цільовій інфраструктурі;
- налаштували необхідні канали зв'язку та інфраструктурні послуги, щоб перевірити роботу інтеграцій;
- відпрацювали cutover-сценарії;
- хмара також допомогла нам сформувати налаштовані шаблони віртуальних машин, які згодом ми просто імпортували та розгорнули у цільовому ландшафті.
Незадовго до новорічних свят до нас приїхала перша партія обладнання. Це дозволило розгорнути частину систем на реальному залізі. Оскільки приїхало далеко не все, ми підключили підмінне обладнання, про постачання якого нам вдалося домовитися з вендором та дистриб'юторами. Залишки цільової інфраструктури ми вже отримали на фінальному етапі.
Щоб встигнути вчасно, нашим інженерам довелося пожертвувати новорічними канікулами та розпочати роботу з підготовки цільової інфраструктури 2 січня, у розпал свят. Так, таке іноді трапляється, коли горить та інших варіантів просто немає. На кону була працездатність систем, яких залежить життєдіяльність підприємства.
Загальний порядок міграції виглядав так: насамперед найменш критичні системи (ландшафт розробки, ландшафт тестування), потім продуктивні системи. Фінальний етап міграції проходив наприкінці січня-початку лютого.
Процес міграції було розписано з точністю до хвилини. Це cutover-план зі списком усіх завдань, часом виконання та відповідальними особами. Всі кроки вже були відпрацьовані на тестовій міграції, тому в бойовій міграції необхідно було просто дотримуватися плану та координувати процес.
Міграція проводилася посистемно у кілька етапів. У кожному етапі по дві системи.
Підсумком тримісячного спринту стала система, що повністю функціонує в ЦОД КРОК. Загалом, позитивний результат отримано завдяки спільній роботі, внесок та самовіддача всіх учасників процесу була максимальною.
Роль замовника у проекті
Комуніцювати із провайдером, якого залишав наш клієнт, було непросто. Воно й зрозуміло, вони були останніми у списку осіб зацікавлених у успішному завершенні проекту. Замовник взяв на себе завдання з ескалації та педалювання всіх комунікаційних питань і впорався з цим на 100500-XNUMX%. За це йому окреме спасибі. Без такої посильної участі у процесі результат проекту міг би бути зовсім іншим.
З огляду на формалізованість процесів на боці «колишнього» провайдера супроводом інфраструктури займалися фахівці, у прямому сенсі далекі від проблем, на той момент ще їх замовника. Наприклад, процес експорту однієї й тієї БД міг займати від години до п'яти. Тоді здавалося, що це якась магія, секрет, який так нам і не відкрився. Напевно інженери техпідтримки між справою вдавалися до медитації, забуваючи про те, що десь там у далекій Росії дедлайни, інженери без новорічних салатів, плаче і страждає замовник.
Підсумки проекту
Фінальною акордом міграції була передача систем на супровід.
Зараз ми надаємо сервіс єдиного вікна для звернень замовника та закриваємо весь обсяг завдань із супроводу компонентів інфраструктури та SAP basis разом із партнером — itelligence. Клієнт живе у приватній хмарі вже півроку. Ось статистика з сервісних випадків за цей час:
- 90 інцидентів (20% вирішено без залучення замовника)
- Вирішення в рамках SLA – 100%
- Позапланових зупинок систем – 0
Якщо у вас є завдання, аналогічні до того, що були у нашого клієнта, і ви хочете дізнатися докладніше, як їх вирішити, пишіть: [захищено електронною поштою]
Джерело: habr.com