🥇Опит за прехвърляне на SAP хостинг: как да мигрираме системите без да бъде болезнено

Или возможно? Разумеется, миграция 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 фабрики.

СХД

Продуктивната и пред-продуктивната натовареност на SAP оставиха на all-flash масив.
Тестовите среди на разработчиците и инфраструктурните услуги бяха поставени на отделен хибриден масив.

СРК

Създадоха на база Veritas Netbackup.
Няколко вградени скрипта бяха допълнени, за да архивират MCOS конфигурации.
Оперативните копия бяха поставени на дискова система, за да се възстановят бързо, а за дългосрочно съхранение използваме ленти.

Мониторинг

Всички хардуер, ОС и SAP бяха въведени под Zabbix.
Създадоха множество полезни табла в Grafana.
При възникване на сигнал от Zabbix, той може да създава заявки в системата за управление на инциденти, която при нас е реализирана на Jira. Информацията също се дублира в Telegram канал.

Телеграм

Общо състояние на HANA

Състояние на сървера на приложения SAP:

Инфраструктурни услуги

За обслужване на вътрешни имена бяха повдигнати DNS-сървърен клъстер, който се синхронизира с клиентските сървъри.
Създадоха отделен файлов сървър за обмен на данни.
За съхранение на различни конфигурации добавиха Gitlab.
За различна чувствителна информация използваха HashiCorp Vault.

Процес на миграция

В общия случай процесът на миграция се състои от следните етапи:

подготовка на цялата необходима проектна документация;
преговори с текущия доставчик — разрешаване на организационни въпроси;
закупуване, доставка и инсталиране на ново оборудване за проекта;
тестова миграция и настройка на процеса;
пренос на системи, бойна миграция.

В края на октомври 2019 година подписахме договор, след което проектирахме архитектура, а след одобрението й от клиента, поръчахме необходимото оборудване.

На какво да се обърне внимание на първо място - срока за доставка на оборудването. Средно доставката на сертифицирано оборудване за SAP NAHA, отговарящо на изискванията на софтуерния производител към хардуерните платформи, отнема 10-12 седмици. А с оглед на сезонността (реализацията на проекта се съвпадна точно с нова година) - този срок може да се увеличи с още един месец. Следователно, трябваше да се ускори процесът максимално: работехме с дистрибутор-изпълнител, договаряхме ускорена доставка по въздух (вместо по земя и море).

Ноември и декември преминаха в подготовка за миграцията и получаване на част от оборудването. Подготовката извършихме на тестово място в нашето публично облако, където отработихме всички основни стъпки и уловихме възможни сложност и проблеми:

подготвихме подробен план за взаимодействие на участниците в проектните екипи с минутни графици;
изградихме тестово място за бази данни и приложения по подобен начин на целевата инфраструктура;
настроихме необходимите канали за комуникация и инфраструктурни услуги, за да проверим работата на интеграциите;
отработихме сценарии за cutover;
облакът също ни помогна да съставим предварително настроени шаблони на виртуални машини, които след това просто импортирахме и развернахме в целевия пейзаж.

Непосредствено преди новогодишните празници получихме първата партида оборудване. Това ни позволи да развернем част от системите на реално оборудване. Тъй като не пристигна всичко, включихме резервно оборудване, за доставката на което успяхме да се договорим с доставчиците. Остатъците от целевата инфраструктура получихме вече на финалния етап.
За да успеем в срок, нашите инженери трябваше да жертват новогодишните ваканции и да започнат работа по подготовката на целевата инфраструктура на 2 януари, в разгара на празниците. Да, понякога това се случва, когато гори и няма други опции. На карта беше работоспособността на системи, от които зависи жизнеспособността на предприятието.

Общият ред на миграцията изглеждаше така: на първо място - най-малко критичните системи (разработъчен пейзаж, тестов пейзаж), а след това - продуктивни системи. Финалният етап на миграцията премина в края на януари - началото на февруари.

Процесът на миграция беше разписан с точност до минута. Това е cutover план със списък на всички задачи, времето на изпълнение и отговорните лица. Всички стъпки вече бяха отработени при тестовата миграция, затова в бойната миграция беше необходимо просто да се следва планът и да се координира процесът.

Миграцията се проведе систематично на няколко етапа. Във всеки етап имаше по две системи.

Резултатът от тримесечния спринт е система, напълно функционираща в ЦОД КРОК. В целом, положителният резултат бе постигнат благодарение на съвместната работа, приносът и самоотдаването на всички участници в процеса бяха максимални.

Ролята на поръчителя в проекта

Да комуникираме с доставчика, от който нашият клиент се оттегляше, не беше лесно. И е разбираемо, те бяха последните в списъка на заинтересованите от успешното завършване на проекта. Поръчителят пое задачите по ескалация и управлението на всички комуникационни въпроси и се справи с това на 100500%. За това му благодарим специално. Без такова активно участие в процеса резултатът от проекта можеше да бъде съвсем различен.

Поради формализираността на процесите от страна на бившия доставчик, инфраструктурата се поддържаше от специалисти, които, в буквалния смисъл на думата, бяха далеч от проблемите, на този етап все още техен клиент. Например, процесът на експортиране на една и съща БД можеше да отнеме от час до пет. Тогава изглеждаше, че това е някаква магия, тайна, която така и не ни беше разкрита. Вероятно инженерите на техническата поддръжка междувременно се отдаваха на медитация, забравяйки, че къде-то там в далечна Русия сроковете изтичат, инженерите листват без новогодишни салати, плаче и страда поръчителят...

Резултати от проекта

Финалният акорд на миграцията беше предаването на системите за поддръжка.

Сега предоставяме услуга на едно гише за запитвания от поръчителя и покриваме целия обем задачи по поддръжката на компонентите на инфраструктурата и SAP basis, заедно с партньора ни — itelligence. Клиентът живее в частно облако вече половин година. Ето статистиката по сервизни случаи за това време:

90 инцидента (20% решени без привличане на поръчителя)
Решени в рамките на SLA – 100%
Планови спирания на системите – 0

Ако имате задачи, подобни на тези, които нашият клиент имаше, и искате да разберете повече за това как да ги решите, пишете: ahaidukov@croc.ru

Източник: habr.com