Czy to naprawdę możliwe? Oczywiście, migracja systemów SAP to skomplikowany i czasochłonny proces, w którym kluczowe znaczenie ma zgrana współpraca wszystkich uczestników. Gdy migracja odbywa się w krótkim czasie, zadanie staje się jeszcze bardziej skomplikowane. Nie każdy decyduje się na to. Istnieje kilka powodów. Na przykład, sam proces jest długi i organizacyjnie złożony. Dodatkowo, istnieje ryzyko nieplanowanych przestojów systemów. Lub klienci nie są pewni, czy po przetrwaniu takiej operacji otrzymają korzyści proporcjonalne do włożonego wysiłku. Jednak zdarzają się także wyjątki.
Poniżej opowiemy o trudnościach, które napotykają zamawiający w procesie migracji i wsparcia systemów SAP, omówimy, dlaczego stereotypy nie zawsze odpowiadają rzeczywistości, i podzielimy się przypadkiem, w jaki sposób udało nam się zrealizować migrację systemów klienta do nowej infrastruktury w zaledwie nieco ponad trzy miesiące.
Hosting systemów SAP
Jeszcze pięć lat temu trudno było sobie wyobrazić, że klienci masowo zaczną korzystać z zasobów hostingowych dla aplikacji SAP. W większości przypadków była ich wdrażana w modelu on-premise. Jednak wraz z rozwojem modeli outsourcingowych oraz rynku usług chmurowych, perspektywy zamawiających zaczęły się zmieniać. Jakie są argumenty przemawiające za wyborem chmury dla SAP?
- Dla nowicjuszy, którzy właśnie planują wdrożenie SAP, chmurowa infrastruktura to praktycznie standardowy wybór – skalowalność zasobów według aktualnych potrzeb systemu oraz chęć nieodciągania zasobów na rozwój kompetencji niezwiązanych z działalnością.
- W firmach z dużym krajobrazem systemowym, dzięki hostingu systemów SAP, CIO osiągają wyższy poziom zarządzania ryzykiem, ponieważ to partner odpowiada za SLA.
- Trzeci z najczęściej spotykanych argumentów to wysoki koszt budowy infrastruktury do realizacji scenariuszy wysokiej dostępności i DR.
- Czynnik 2027 – zapowiedziane przez dostawcę zakończenie wsparcia dla przestarzałych systemów w 2027 roku. Oznacza to migrację bazy danych na HANA, co wiąże się z kosztami modernizacji oraz zakupu nowych mocy obliczeniowych.
Rynek hostingu SAP w Rosji można obecnie uznać za dość dojrzały. Stwarza to szerokie możliwości dla klientów, którzy chcą zmienić swoje platformy hostingowe. Jednak takie projekty mogą budzić uzasadnione obawy wśród firm z powodu skomplikowanej procedury migracji. Wymusza to na zleceniodawcach stawianie wyższych wymagań wobec dostawców usług, którzy muszą posiadać nie tylko wyjątkowe kompetencje w zakresie hostingu i wsparcia systemów SAP, ale również udokumentowane doświadczenie w migracji.
Na czym polegają trudności związane ze zmianą hostingu SAP?
Hostingi są różne. Niespełnienie deklarowanego poziomu usług, mnóstwo 'ale' i gwiazdek z zastrzeżeniami w drobnym druku, ograniczenia zasobów i możliwości dostawcy hostingu, brak elastyczności w komunikacji z klientem, biurokracja, ograniczenia techniczne, niska kompetencja pracowników wsparcia technicznego, a także wiele innych niuansów — to tylko niewielka część pułapek, na które mogą natknąć się klienci podczas eksploatacji swoich systemów biznesowych w infrastrukturach outsourcowanych. Często dla klienta wszystko to pozostaje w cieniu, w zawiłościach wielostronicowej umowy, i wypływa dopiero podczas korzystania z usług.
W pewnym momencie dla zleceniodawcy staje się oczywiste, że poziom usług, który otrzymuje, daleko odbiega od jego oczekiwań. Jest to pewien katalizator do poszukiwania rozwiązań mających na celu poprawę sytuacji, a w przypadku niepowodzenia, kiedy problemy narastają do granic i stają się naprawdę bolesne, przechodzą do aktywnych działań związanych z poszukiwaniem alternatywnych dostawców usług.
Dlaczego czekają do ostatniej chwili? Powód jest prosty — proces przenoszenia systemów dla klientów nie zawsze jest przejrzysty i zrozumiały. Klientom trudno jest ocenić rzeczywiste ryzyko związane z procesem migracji. Można powiedzieć, że migracja dla klientów to pewnego rodzaju czarna skrzynka: niejasne są koszty, czas przestoju systemów, ryzyka i sposoby ich minimalizacji, a w ogóle panuje mrok i strach. W tej sytuacji, jeśli coś pójdzie nie tak, głowy polecą zarówno u kierowników, jak i u wykonawców.
SAP to systemy korporacyjne, skomplikowane i, delikatnie mówiąc, kosztowne. Ich wdrożenie, modyfikacja i wsparcie wiążą się z znacznie dużymi budżetami, a ich dostępność i poprawne działanie wpływają na funkcjonowanie przedsiębiorstwa. A teraz wyobraźcie sobie konsekwencje wstrzymania jakiejkolwiek dużej produkcji. To straty finansowe, które mogą sięgać cyfr z dużą ilością zer, a także straty reputacyjne i inne, nie mniej istotne ryzyka.
Przeanalizujemy trudności, które mogą wystąpić na każdym etapie, na przykładzie migracji systemów SAP jednego z naszych klientów.
Przygotowanie i projektowanie
Migracja to formuła z wieloma różnymi składnikami. A jednym z najważniejszych etapów jest projektowanie i przygotowanie docelowej (nowej) infrastruktury.
Musieliśmy zapoznać się z istniejącą realizacją systemów, ich architekturą. W docelowej infrastrukturze gdzieś powtórzyliśmy istniejące rozwiązania, w niektórych aspektach je uzupełniliśmy i poprawiliśmy, a w innych przekonstruowaliśmy, przemyśleliśmy i wybraliśmy rozwiązania zapewniające odporność na awarie i dostępność, a także maksymalnie skonsolidowaliśmy wszystkie zasoby.
W procesie projektowania wykonano wiele różnych ćwiczeń, które ostatecznie pozwoliły maksymalnie przygotować się do migracji i wziąć pod uwagę wszelkie niuanse i pułapki (o nich później).
Co nam ostatecznie wyszło — indywidualnie zaprojektowana infrastruktura prywatnej chmury w naszej centrali danych:
- wydzielone fizyczne serwery dla SAP HANA;
- platforma wirtualizacji VMware dla serwerów aplikacji i usług infrastrukturalnych;
- zdublowane kanały komunikacyjne między centraliami danych dla L2 VPN;
- dwa główne systemy pamięci masowej w celu oddzielenia produkcji od 'wszystkiego innego';
- rozwiązanie bazujące na Veritas Netbackup z oddzielnym serwerem, półką dyskową i biblioteką taśmową.
A oto jak zrealizowaliśmy to wszystko z technicznego punktu widzenia.
SAP
- Aby efektywnie wykorzystać przestrzenie pamięci masowej dla produkcyjnych HANA, stosowaliśmy wspólne dyski bez systemowej replikacji Bazy Danych za pomocą SAP. Całość została opakowana w klaster Active-Standby SUSE HAE na bazie Pacemaker. Tak, czas przywracania jest nieco dłuższy niż z replikacją, ale oszczędzamy przestrzeń pamięci masowej o połowę i w efekcie oszczędzamy budżet klienta.
- W środowiskach preprodukcyjnych zrezygnowano z klastrów HANA, ale technicznie powtórzono konfigurację produkcyjną.
- Środowiska testowe oraz deweloperskie rozdzielono na kilka serwerów bez klastrów w konfiguracji MCOS.
- Wirtualizowano wszystkie serwery aplikacji i umieszczono je w VMware.
Sieci
- Fizycznie oddzielono kontury sieci zarządzania od produkcyjnych z użyciem stosów switchy, kierując sieci produkcyjne w stronę centrum danych zamawiającego.
- Zabezpieczono odpowiednią liczbę interfejsów sieciowych, aby nie mieszać dużych przepływów ruchu.
- Do przesyłania danych z systemu pamięci masowej zastosowano klasyczne fabryki FC SAN.
Macierz dyskowa
- Obciążenie produkcyjne i preprodukcyjne SAP pozostawiono na macierzy all-flash.
- Środowiska testowe deweloperów oraz usługi infrastrukturalne umieszczono na oddzielnej hybrydowej macierzy.
SRK
- Stworzono na bazie Veritas Netbackup.
- Nieco dopisano wbudowane skrypty, aby tworzyć kopie zapasowe konfiguracji MCOS.
- Kopie robocze umieszczono na półce dyskowej, aby szybko przywrócić system, a do długoterminowego przechowywania używamy taśm.
Monitoring
- Cały sprzęt, systemy operacyjne i SAP zarejestrowano w Zabbix.
- Zebrano wiele przydatnych pulpitów nawigacyjnych w Grafana.
- W przypadku wystąpienia alertu Zabbix potrafi otworzyć zgłoszenie w systemie zarządzania incydentami, który u nas jest realizowany w Jira. Informacje są również duplikowane w kanale Telegram.
Telegram
Ogólny stan HANA
Stan serwera aplikacji SAP:
Usługi infrastrukturalne
- Aby obsłużyć wewnętrzne przestrzenie nazw, uruchomiono klaster serwerów DNS, który synchronizuje się z serwerami zamawiającego.
- Stworzono oddzielny serwer plików do wymiany danych.
- Aby przechowywać różne konfiguracje, dodano Gitlab.
- Do różnorodnych informacji wrażliwych zastosowano HashiCorp Vault.
Proces migracji
Ogólnie proces migracji składa się z następujących etapów:
- przygotowanie całej niezbędnej dokumentacji projektowej;
- negocjacje z obecnym dostawcą — rozwiązanie kwestii organizacyjnych;
- zakup, dostawa i instalacja nowego sprzętu pod projekt;
- migracja testowa i dostosowanie procesu;
- przeniesienie systemów, migracja bojowa.
Pod koniec października 2019 roku podpisaliśmy umowę, następnie zaprojektowaliśmy architekturę, a po jej zatwierdzeniu przez zamawiającego zamówiliśmy niezbędny sprzęt.
Na co należy zwrócić uwagę w pierwszej kolejności to terminy dostawy sprzętu. Średnio dostawa certyfikowanego sprzętu pod SAP NAHA, spełniającego wymagania producenta oprogramowania dotyczące platform sprzętowych, zajmuje 10-12 tygodni. A biorąc pod uwagę sezonowość (realizacja projektu zbiegła się z nowym rokiem) — ten czas mógł się wydłużyć o kolejny miesiąc. W związku z tym należało maksymalnie przyspieszyć ten proces: współpracowaliśmy z dystrybutorem-dostawcą, ustalając przyspieszoną dostawę samolotami (zamiast drogą lądową i morską).
Listopad i grudzień poświęciliśmy na przygotowania do migracji i pozyskanie części sprzętu. Przygotowania przeprowadziliśmy na testowym stanowisku w naszym publicznym chmurze, gdzie przeszliśmy przez wszystkie główne kroki i wykryliśmy możliwe trudności i problemy:
- przygotowaliśmy szczegółowy plan interakcji uczestników zespołów projektowych z minutowymi harmonogramami;
- zbudowaliśmy testowe stanowisko dla baz danych i serwerów aplikacji w sposób zbliżony do docelowej infrastruktury;
- skonfigurowaliśmy niezbędne kanały komunikacji i usługi infrastrukturalne, aby sprawdzić działanie integracji;
- wypracowaliśmy scenariusze cutover;
- chmura również pomogła nam stworzyć wstępnie skonfigurowane szablony maszyn wirtualnych, które później po prostu zaimportowaliśmy i wdrożyliśmy w docelowym środowisku.
Tuż przed świętami noworocznymi przyjechała do nas pierwsza partia sprzętu. Umożliwiło to uruchomienie części systemów na rzeczywistym sprzęcie. Ponieważ nie dotarło wszystko, podłączyliśmy sprzęt zastępczy, na który udało nam się umówić z dostawcą i dystrybutorami. Pozostałości docelowej infrastruktury otrzymaliśmy już na etapie końcowym.
Aby zdążyć na czas, nasi inżynierowie musieli poświęcić noworoczne wakacje i rozpocząć prace nad przygotowaniem docelowej infrastruktury 2 stycznia, w samym środku świąt. Tak, czasami tak się zdarza, kiedy sytuacja jest pilna i nie ma innych opcji. Na szali była funkcjonalność systemów, od których zależy działalność firmy.
Ogólny przebieg migracji wyglądał następująco: w pierwszej kolejności — najmniej krytyczne systemy (środowisko deweloperskie, środowisko testowe), a następnie — systemy produkcyjne. Ostateczny etap migracji odbył się pod koniec stycznia i na początku lutego.
Proces migracji został szczegółowo rozpisany co do minuty. To plan cutover z listą wszystkich zadań, czasem ich realizacji i osobami odpowiedzialnymi. Wszystkie kroki zostały już przetestowane podczas migracji testowej, więc w migracji na żywo wystarczyło po prostu trzymać się planu i koordynować proces.
Migracja odbywała się systematycznie w kilku etapach. W każdym etapie znajdowały się po dwie systemy.
Efektem trzy miesięcznego sprintu był system w pełni funkcjonujący w Centrum Danych KROK. Ogólnie rzecz biorąc, pozytywny rezultat został osiągnięty dzięki wspólnej pracy, wkład i poświęcenie wszystkich uczestników procesu były maksymalne.
Rola zamawiającego w projekcie
Komunikacja z dostawcą, któremu odchodził nasz klient, była trudna. Nic dziwnego, byli ostatnimi na liście osób zainteresowanych zakończeniem projektu z sukcesem. Zamawiający wziął na siebie zadania związane z eskalacją i rozwiązywaniem wszystkich kwestii komunikacyjnych i poradził sobie z tym w 100500%. Za to składamy mu osobne podziękowania. Bez takiego wsparcia wynik projektu mógłby być zupełnie inny.
Ze względu na sformalizowane procesy u 'byłego' dostawcy, infrastrukturę nadzorowali specjaliści, którzy dosłownie byli odlegli od problemów, byłego już zamawiającego. Na przykład proces eksportu tej samej bazy danych mógł zająć od godziny do pięciu. Wtedy wydawało się, że to jakaś magia, sekret, który nigdy nie został nam ujawniony. Prawdopodobnie inżynierowie wsparcia technicznego poświęcali czas na medytację, zapominając, że gdzieś w dalekiej Rosji deadline'y, inżynierowie bez noworocznych sałatek, płaczą i cierpią zamawiający...
Podsumowanie projektu
Finałem migracji było przekazanie systemów do wsparcia.
Obecnie zapewniamy usługę jednego okna dla wniosków zamawiającego i realizujemy cały zakres zadań związanych z wsparciem komponentów infrastruktury oraz SAP basis wspólnie z partnerem — itelligence. Klient korzysta z prywatnej chmury od pół roku. Oto statystyki dotyczące przypadków serwisowych w tym czasie:
- 90 incydentów (20% rozwiązanych bez udziału zamawiającego)
- Rozwiązane w ramach SLA – 100%
- Nieplanowanych awarii systemów – 0
Jeśli masz zadania podobne do tych, które miał nasz klient, i chcesz dowiedzieć się więcej, jak je rozwiązać, pisz: ahaidukov@croc.ru
Źródło: habr.com
