Czy jest to możliwe? Oczywiście migracja systemów SAP to złożony i żmudny proces, którego powodzenie wymaga skoordynowanej pracy wszystkich uczestników. A jeśli migracja zostanie przeprowadzona w krótkim czasie, zadanie staje się znacznie bardziej skomplikowane. Nie każdy decyduje się na to. Powodów może być kilka. Na przykład sam proces jest długotrwały i skomplikowany organizacyjnie. Ponadto istnieje ryzyko nieplanowanego przestoju systemu. Lub klienci nie są pewni, że po przejściu takiej operacji otrzymają korzyści proporcjonalne do włożonych wysiłków. Są jednak wyjątki.
Poniżej skrótu porozmawiamy o trudnościach, jakie napotykają klienci w procesie migracji i utrzymania systemów SAP, omówimy, dlaczego stereotypy nie zawsze odpowiadają rzeczywistości oraz podzielimy się studium przypadku pokazującym, jak udało nam się przeprowadzić migrację systemów klienta do systemu SAP nową infrastrukturę w 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ły one wdrażane lokalnie. Jednak wraz z rozwojem modeli outsourcingu i rynku usług chmurowych światopogląd klientów zaczął się zmieniać. Jakie argumenty wpływają na wybór chmury dla SAP?
- Dla początkujących, którzy dopiero planują wdrożenie SAP, infrastruktura chmurowa to niemal standardowy wybór – skalowalność zasobów do bieżących potrzeb systemu i niechęć do przekierowania zasobów na rozwój kompetencji spoza kluczowych.
- W firmach o dużym krajobrazie systemowym, przy pomocy hostingu systemów SAP, CIO osiągają jakościowo inny poziom zarządzania ryzykiem, ponieważ Partner jest odpowiedzialny za umowę SLA.
- Trzecim najczęstszym argumentem jest wysoki koszt budowy infrastruktury w celu wdrożenia scenariuszy wysokiej dostępności i DR.
- Factor 2027 – sprzedawca zapowiedział zakończenie wsparcia dla starszych systemów w 2027 roku. Oznacza to przeniesienie bazy danych do HANA, co wiąże się z kosztami modernizacji i zakupu nowej mocy obliczeniowej.
Rynek hostingu SAP w Rosji można obecnie uznać za dość dojrzały. Daje to szerokie możliwości klientom, którzy chcą zmienić swoje platformy hostingowe. Jednak tego typu projekty mogą słusznie budzić obawy przedsiębiorców ze względu na złożoność procedury migracyjnej. Wymusza to na klientach stawianie zwiększonych wymagań dostawcom usług, którzy muszą posiadać nie tylko wyjątkowe kompetencje w zakresie hostingu i utrzymania systemów SAP, ale także udane doświadczenie w zakresie migracji.
Jakie są trudności związane ze zmianą hostingu SAP?
Hostingi są różne. Niezgodność z deklarowanym poziomem usług, wiele „ale” i gwiazdek przy zastrzeżeniach pisanych drobnym tekstem, ograniczone zasoby i możliwości dostawcy hostingu, brak elastyczności w kwestiach komunikacji z klientem, biurokracja, ograniczenia techniczne, niskie kompetencje wsparcia technicznego specjalistów, a także wiele innych niuansów – to tylko niewielka część pułapek, na jakie mogą natrafić klienci operując swoimi systemami biznesowymi w infrastrukturze outsourcingowej. Często dla Klienta wszystko to pozostaje w cieniu, w gąszczu wielostronicowej umowy, a wyłania się w trakcie korzystania z usług.
W pewnym momencie dla klienta staje się oczywiste, że poziom obsługi, jaki otrzymuje, odbiega od jego oczekiwań. Jest to swego rodzaju katalizator do znalezienia rozwiązań mających na celu naprawę sytuacji i w przypadku niepowodzenia, gdy problemy narastają do granic możliwości i staje się to bardzo bolesne, przechodzą do aktywnych działań w celu opracowania alternatywnych opcji w kierunku zmiany usługodawcy .
Dlaczego czekają do ostatniej chwili? Powód jest prosty – proces migracji systemów dla klientów nie zawsze jest przejrzysty i zrozumiały. Klientowi trudno jest ocenić rzeczywiste ryzyko związane z procesem migracji. Można powiedzieć, że migracja dla klientów to swego rodzaju czarna skrzynka: nie jest jasna cena, czas przestoju systemu, ryzyka i sposób ich minimalizacji, ogólnie jest ciemno i strasznie. To tak, jakby to nie wyszło, głowy potoczą się zarówno na górze, jak i na wykonawcach.
SAP to system na poziomie Enterprise, złożony i, delikatnie mówiąc, nie tani. Na ich wdrożenie, modyfikację i utrzymanie przeznaczane są przyzwoite budżety, a od ich dostępności i prawidłowego działania zależy żywotność przedsiębiorstwa. Teraz wyobraźcie sobie konsekwencje wstrzymania dużej produkcji. Są to straty finansowe, które można obliczyć liczbowo z dużą liczbą zer, a także ryzyko reputacyjne i inne równie istotne ryzyko.
Przeanalizujemy trudności, jakie mogą pojawić się na każdym etapie w przypadku migracji systemów SAP od jednego z naszych klientów.
Przygotowanie i projektowanie
Migracja to formuła składająca się z wielu różnych części. A jednym z najważniejszych jest etap projektowania i przygotowania docelowej (nowej) infrastruktury.
Musieliśmy zagłębić się w istniejące wdrożenia systemów i ich architekturę. W docelowej infrastrukturze powtarzaliśmy gdzieś istniejące rozwiązania, w niektórych miejscach je uzupełnialiśmy i ulepszaliśmy, gdzieś przerabialiśmy, przemyślaliśmy i dobieraliśmy rozwiązania, aby zapewnić odporność na awarie i dostępność, a także maksymalnie skonsolidowaliśmy wszystkie zasoby.
W procesie projektowania wykonano wiele różnych ćwiczeń, co ostatecznie pozwoliło przygotować się do migracji w jak największym stopniu i uwzględnić wszelkiego rodzaju niuanse i pułapki (więcej o nich później).
W rezultacie otrzymaliśmy indywidualnie zaprojektowaną infrastrukturę chmury prywatnej w oparciu o nasze centrum danych:
- dedykowane serwery fizyczne dla SAP HANA;
- Platforma wirtualizacyjna VMware dla serwerów aplikacji i usług infrastrukturalnych;
- zduplikowane kanały komunikacji pomiędzy centrami danych dla L2 VPN;
- dwa główne systemy magazynowania służące do oddzielenia produktu od „wszystkich innych”;
- SRC oparty na Veritas Netbackup z oddzielnym serwerem, półką dyskową i biblioteką taśmową.
A oto jak to wszystko zaimplementowaliśmy od strony technicznej.
SAP
- Aby efektywnie wykorzystać przestrzeń dyskową dla produktywnej platformy HANA, zastosowaliśmy dyski współdzielone bez systemowej replikacji bazy danych za pomocą SAP. Wszystko to zostało opakowane w klaster SUSE HAE w trybie gotowości aktywnej oparty na Pacemakerze. Tak, czas odzyskiwania jest nieco dłuższy niż przy replikacji, ale oszczędzamy miejsce na dysku o połowę i w efekcie oszczędzamy budżet klienta.
- W środowiskach przedprodukcyjnych porzucono klastry HANA, ale technicznie rzecz biorąc, konfiguracja produkcyjna została powtórzona.
- Środowiska testowe i programistyczne zostały rozproszone na kilku kolejnych serwerach bez klastrów w konfiguracji MCOS.
- Wszystkie serwery aplikacji zostały zwirtualizowane i hostowane w VMware.
Sieci
- Fizycznie oddzieliliśmy kontury sieci sterującej i produkcyjnej stosami przełączników, kierując te produktywne w stronę centrów danych klienta.
- Zainstalowaliśmy wystarczającą liczbę interfejsów sieciowych, aby nie mieszać dużych potoków ruchu.
- Do przesyłania danych z systemów pamięci masowej wykonaliśmy klasyczne fabryki FC SAN.
SHD
- Produktywne i przedprodukcyjne obciążenie SAP pozostawiono w macierzy all-flash.
- Deweloperskie środowiska testowe i usługi infrastrukturalne zostały umieszczone na osobnej macierzy hybrydowej.
ZJD
- Wykonane przy użyciu Veritas Netbackup.
- Dodaliśmy trochę do wbudowanych skryptów do tworzenia kopii zapasowych konfiguracji MCOS.
- Kopie operacyjne kładziemy na półce dyskowej w celu szybkiego odzyskania, a do długotrwałego przechowywania używamy taśm.
Monitorowanie
- Cały sprzęt, system operacyjny i SAP zostały zainstalowane w Zabbix.
- W Grafanie zebraliśmy wiele przydatnych dashboardów.
- Gdy pojawi się alert, Zabbix może utworzyć żądanie w systemie zarządzania incydentami, mamy to zaimplementowane w Jira. Informacje są również powielane w kanale Telegramu.
Telegram
Ogólny stan zdrowia HANA
Stan serwera aplikacji SAP:
Usługi infrastrukturalne
- Do obsługi wewnętrznych przestrzeni nazw stworzono klaster serwerów DNS, który jest synchronizowany z serwerami Klienta.
- Stworzyliśmy osobny serwer plików do wymiany danych.
- Do przechowywania różnych konfiguracji dodano Gitlab.
- W celu uzyskania różnych poufnych informacji wybraliśmy HashiCorp Vault.
Proces migracji
Generalnie proces migracji składa się z następujących etapów:
- przygotowanie wszelkiej niezbędnej dokumentacji projektowej;
- negocjacje z obecnym dostawcą - rozwiązywanie kwestii organizacyjnych;
- zakup, dostawa i montaż nowego sprzętu na potrzeby projektu;
- testowanie migracji i debugowanie procesów;
- transfer systemów, migracja bojowa.
Pod koniec października 2019 podpisaliśmy umowę, następnie zaprojektowaliśmy architekturę i po uzgodnieniu z klientem zamówiliśmy niezbędny sprzęt.
To, na co należy zwrócić uwagę w pierwszej kolejności, to czas dostawy sprzętu. Dostawa certyfikowanego sprzętu dla SAP NAHA spełniającego wymagania producenta oprogramowania dla platform sprzętowych trwa średnio 10-12 tygodni. A biorąc pod uwagę sezonowość (realizacja projektu przypadła dokładnie na Nowy Rok), okres ten mógł wydłużyć się o kolejny miesiąc. W związku z tym konieczne było maksymalne przyspieszenie procesu: współpracowaliśmy z dystrybutorem-dostawcą i uzgodniliśmy przyspieszoną dostawę samolotem (zamiast drogą lądową i morską).
Listopad i grudzień upłynęły na przygotowaniach do migracji i odbiorze części sprzętu. Przygotowania przeprowadziliśmy na stanowisku testowym w naszej chmurze publicznej, gdzie przepracowaliśmy wszystkie główne etapy i wychwyciliśmy możliwe trudności i problemy:
- przygotował szczegółowy plan interakcji pomiędzy członkami zespołu projektowego z harmonogramem minuta po minucie;
- zbudował stanowisko testowe dla serwerów bazodanowych i aplikacji w przybliżeniu taki sam sposób, jak w docelowej infrastrukturze;
- skonfigurował niezbędne kanały komunikacji i usługi infrastrukturalne w celu przetestowania działania integracji;
- opracowane scenariusze przełączeń;
- Chmura pomogła nam również stworzyć wstępnie skonfigurowane szablony maszyn wirtualnych, które następnie po prostu zaimportowaliśmy i wdrożyliśmy w środowisku docelowym.
Tuż przed świętami noworocznymi dotarła do nas pierwsza partia sprzętu. Umożliwiło to wdrożenie niektórych systemów na prawdziwym sprzęcie. Ponieważ nie wszystko dotarło, podłączyliśmy sprzęt zastępczy, którego dostawę udało nam się uzgodnić ze sprzedawcą i dystrybutorami. Pozostałości docelowej infrastruktury otrzymaliśmy w końcowym etapie.
Aby dotrzymać terminu, nasi inżynierowie musieli poświęcić święta noworoczne i rozpocząć prace nad przygotowaniem docelowej infrastruktury już 2 stycznia, w środku wakacji. Tak, czasami tak się dzieje, gdy się pali i po prostu nie ma innej opcji. Stawką była wydajność systemów, od których zależy życie przedsiębiorstwa.
Ogólny porządek migracji wyglądał następująco: najpierw systemy najmniej krytyczne (pejzaż deweloperski, krajobraz testowy), następnie systemy produkcyjne. Ostatni etap migracji nastąpił na przełomie stycznia i lutego.
Proces migracji został zaplanowany co do minuty. Jest to plan przełączenia z listą wszystkich zadań, czasem realizacji i osobami odpowiedzialnymi. Wszystkie kroki zostały już opracowane w przypadku migracji testowej, więc w przypadku migracji na żywo wystarczyło jedynie postępować zgodnie z planem i koordynować proces.
Migracja odbywała się systematycznie w kilku etapach. Na każdym etapie istnieją dwa systemy.
Efektem trzymiesięcznego sprintu był w pełni działający system w centrum danych CROC. Ogólnie rzecz biorąc, pozytywny wynik został osiągnięty dzięki pracy zespołowej, a wkład i zaangażowanie wszystkich uczestników procesu było maksymalne.
Rola klienta w projekcie
Komunikacja z dostawcą, z którego odchodził nasz klient, nie była łatwa. To zrozumiałe, to oni byli ostatnią osobą na liście osób zainteresowanych pomyślną realizacją projektu. Klient wziął na siebie zadanie eskalacji i pedałowania wszystkich problemów komunikacyjnych i poradził sobie z tymi 100500%. Specjalne podziękowania dla niego za to. Bez tak realnego udziału w procesie rezultat projektu mógłby być zupełnie inny.
Ze względu na sformalizowanie procesów po stronie „byłego” dostawcy, wsparciem infrastruktury zajmowali się specjaliści, którzy dosłownie byli daleko od problemów, będąc wówczas jeszcze ich klientem. Na przykład proces eksportowania tej samej bazy danych może zająć od godziny do pięciu. Wtedy wydawało się, że to jakaś magia, tajemnica, która nigdy nam nie została ujawniona. Pewnie inżynierowie wsparcia technicznego w międzyczasie oddawali się medytacjom, zapominając, że gdzieś w odległej Rosji są terminy, inżynierowie bez sałatek noworocznych, klient płacze i cierpi…
Wyniki projektu
Ostatnim etapem migracji było przekazanie systemów do konserwacji.
Obecnie zapewniamy obsługę zapytań klientów w jednym oknie i wspólnie z naszym partnerem – itelligence, pokrywamy cały zakres zadań związanych ze wsparciem komponentów infrastruktury i podstaw SAP. Klient od sześciu miesięcy żyje w chmurze prywatnej. Oto statystyki dotyczące spraw serwisowych w tym czasie:
- 90 incydentów (20% rozwiązanych bez angażowania klienta)
- Rozwiązane w ramach SLA – 100%
- Nieplanowane wyłączenia systemu – 0
Jeśli masz problemy podobne do naszych klientów i chcesz dowiedzieć się więcej jak je rozwiązać, napisz na adres: [email chroniony]
Źródło: www.habr.com