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

Или е възможно? Разбира се, мигрирането на SAP системи е сложен и труден процес, чийто успех изисква добре координираната работа на всички участници. И ако миграцията се извърши за кратко време, задачата става много по-сложна. Не всеки се решава на това. Може да има няколко причини. Например, самият процес е дълъг и организационно сложен. Плюс това съществува риск от непланиран прекъсване на системата. Или клиентите не са сигурни, че след като са се подложили на такава операция, ще получат ползи, съизмерими с положените усилия. Има обаче и изключения.

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

Хостинг на SAP системи

Само преди пет години беше трудно да си представим, че клиентите ще започнат масово да използват хостинг ресурси за SAP приложения. В повечето случаи те са внедрени на място. Въпреки това, с развитието на аутсорсинг моделите и пазара на облачни услуги, мирогледът на клиентите започна да се променя. Какви са аргументите, влияещи върху избора в полза на облака за SAP?

• За начинаещи, които току-що са планирали да внедрят SAP, облачната инфраструктура е почти стандартен избор - мащабируемост на ресурсите към текущите нужди на системата и нежелание за пренасочване на ресурси към развитие на неосновни компетенции.
• В компании с голям системен ландшафт, с помощта на хостинг SAP системи, ИТ директорите достигат качествено различно ниво на управление на риска, т.к. Партньорът е отговорен за SLA.
• Третият най-често срещан аргумент е високата цена на изграждане на инфраструктура за прилагане на сценарии с висока достъпност и DR.
• Фактор 2027 – доставчикът обяви края на поддръжката за наследени системи през 2027 г. Това означава прехвърляне на базата данни към HANA, което води до разходи за модернизация и закупуване на нова изчислителна мощност.

Пазарът на SAP хостинг в Русия вече може да се счита за доста зрял. И това предоставя широка възможност за клиенти, които искат да променят своите хостинг платформи. Подобни проекти обаче могат с право да предизвикат безпокойство сред бизнеса поради сложността на процедурата за миграция. Това принуждава клиентите да поставят повишени изисквания към доставчиците на услуги, които трябва да имат не само изключителни компетенции в хостинг и поддръжка на SAP системи, но и успешен опит в областта на миграцията.

Какви са трудностите при промяна на SAP хостинг?

Хостингите са различни. Несъответствие с декларираното ниво на обслужване, много „но“ и звездички с резерви в малък текст, ограничени ресурси и възможности на хостинг доставчика, липса на гъвкавост по отношение на комуникацията с клиента, бюрокрация, технически ограничения, ниска компетентност на техническата поддръжка специалисти, както и много други нюанси - това са. Това е само малка част от клопките, които клиентите могат да срещнат, когато управляват своите бизнес системи в аутсорсинг инфраструктури. Често за клиента всичко това остава в сянка, в джунглата на многостраничен договор и изплува в процеса на ползване на услугите.

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

Защо чакат до последния момент? Причината е проста - процесът на мигриране на системи за клиенти не винаги е прозрачен и разбираем. За клиента е трудно да прецени реалните рискове, свързани с процеса на миграция. Можем да кажем, че миграцията за клиентите е вид черна кутия: неясна е цената, престой на системата, рискове и как да ги смекчим, и като цяло е тъмно и страшно. Все едно, ако не се получи, тогава главите ще се търкалят както на върха, така и на изпълнителите.

SAP е система на корпоративно ниво, сложна и, меко казано, не евтина. За тяхното внедряване, модификация и поддръжка се изразходват прилични бюджети, а животът на предприятието зависи от тяхната наличност и правилна работа. Сега си представете последствията от спирането на някое голямо производство. Това са финансови загуби, които могат да бъдат изчислени в числа с голям брой нули, както и репутационни и други също толкова значими рискове.

Ще анализираме трудностите, които могат да възникнат на всеки етап в случай на мигриране на SAP системи от един от нашите клиенти.

Подготовка и дизайн

Миграцията е формула с много различни части. И един от най-важните е етапът на проектиране и подготовка на целевата (нова) инфраструктура.

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

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

Това, което завършихме, е индивидуално проектирана частна облачна инфраструктура, базирана на нашия център за данни:

• специализирани физически сървъри за SAP HANA;
• VMware платформа за виртуализация за сървъри на приложения и инфраструктурни услуги;
• дублирани канали за комуникация между центрове за данни за L2 VPN;
• две основни системи за съхранение за разделяне на продукта и „всичко останало“;
• SRC, базиран на Veritas Netbackup с отделен сървър, дисков рафт и лентова библиотека.

И ето как внедрихме всичко това от техническа гледна точка.

SAP

• За да използваме ефективно хранилището за продуктивна HANA, използвахме споделени дискове без системна репликация на база данни, използвайки SAP. Всичко това беше обвито в Active-Standby SUSE HAE клъстер, базиран на Pacemaker. Да, времето за възстановяване е малко по-дълго, отколкото при репликация, но спестяваме наполовина място за съхранение и в резултат на това пестим бюджета на клиента.
• В предпроизводствени среди клъстерите HANA бяха изоставени, но технически производствената конфигурация беше повторена.
• Средите за тестване и разработка бяха разпределени в още няколко сървъра без клъстери в конфигурация MCOS.
• Всички сървъри на приложения бяха виртуализирани и хоствани във VMware.

Сети

• Физически разделихме контурите на контролните и производствените мрежи със стекове комутатори, обръщайки продуктивните към центровете за данни на клиента.
• Инсталирахме достатъчен брой мрежови интерфейси, за да не смесваме големи потоци трафик.
• За прехвърляне на данни от системи за съхранение направихме класически FC SAN фабрики.

SHD

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

IBS

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

мониторинг

• Целият хардуер, ОС и SAP бяха инсталирани под Zabbix.
• Събрахме много полезни табла за управление в Grafana.
• Когато възникне предупреждение, Zabbix може да създаде заявка в системата за управление на инциденти; ние сме го внедрили в Jira. Информацията се дублира и в канала на Telegram.

Telegram

Общо здравословно състояние на HANA

Състояние на SAP Application Server:

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

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

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

Като цяло процесът на миграция се състои от следните етапи:

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

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

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

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

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

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

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

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

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

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

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

Комуникацията с доставчика, който нашият клиент напускаше, не беше лесна. Това е разбираемо, те бяха последните в списъка на заинтересованите от успешното завършване на проекта. Клиентът се зае със задачата да ескалира и елиминира всички комуникационни проблеми и се справи с тези 100500%. Специални благодарности му за това. Без такова осъществимо участие в процеса резултатът от проекта можеше да бъде съвсем различен.

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

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

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

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

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

Ако имате проблеми, подобни на тези на наш клиент, и искате да научите повече за тяхното разрешаване, пишете на: [имейл защитен]

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