Awaria środowiska SAP ERP
Jak wygląda to w praktyce? Jeden z polskich klientów miał poważny problem z systemem SAP ERP. Awarii uległy jednocześnie wszystkie trzy środowiska – produkcyjne, testowe oraz deweloperskie.
Niestety, środowisko produkcyjne nie posiadało zabezpieczeń HA czy też DR, które pozwoliłyby, w krótkim czasie uruchomić system na węźle zapasowym lub w innym ośrodku przetwarzania danych.
Po rozpoczęciu sprawdzania logów zarówno aplikacyjnych, bazy danych oraz systemu operacyjnego można było wywnioskować, że błędy, które generuje system są całkowicie losowe i w żaden sposób nie wskazują konkretnej przyczyny awarii. Co ważne, całe środowisko było zwirtualizowane. Pierwszy trop to uszkodzony sprzęt, a konkretniej macierz, na której przechowywane były pliki, obrazy maszyn wirtualnych systemu. Tylko jak do tego doszło, że awarii uległy wszystkie trzy środowiska – produkcyjne, testowe oraz deweloperskie w jednym czasie?
Rozwiązanie ukryło się w macierzy, w której uległ uszkodzeniu kolejny dysk. Konfiguracja macierzy pozwalała na uszkodzenie tylko jednego dysku, aby dedykowana przestrzeń funkcjonowała prawidłowo. Niestety, uszkodzenie drugiego dysku spowodowało, że przestała poprawnie działać jak również wszystkie systemy, które jej używały. Z tej samej, uszkodzonej przestrzeni korzystały systemy SAP ERP zarówno produkcyjny, testowy jak i deweloperski. W efekcie, wszystkie trzy środowiska wymagały całkowitego odzyskania z kopii zapasowej na innych zasobach infrastruktury.
Odtworzenie uszkodzonych systemów SAP
Z pewnością awaria miałaby mniejszy zasięg, gdyby system produkcyjny posiadał dedykowane zasoby, a także środowisko testowe oraz deweloperskie. Odtworzenie uszkodzonych systemów SAP ERP z innych zasobów jest problematyczne, często ze względu na ich braki, a zakup nowych jest zazwyczaj niemożliwy do zrealizowania w krótkim czasie, bo proces trwa zbyt długo.
W rezultacie, macierz została szybko przekonfigurowana, systemy zostały odtworzone dokładnie na tej samej macierzy, ale już bez dwóch dysków, które uległy awarii. System wznowił pracę po kilku dniach.
Awarie a zapewnenie ciągłości działania systemu
Klient miał pełną świadomość o sytuacji, którą jednak trudno było mu zaakceptować z punktu widzenia zapewnienia ciągłości działania systemu oraz SLA. Potrzebował inwestycji, które miały na celu poprawę kondycji systemu, a problemów było kilka:
- wyeksploatowana infrastruktura,
- z punktu widzenia zasobów infrastrukturalnych: brak separacji galwanicznej środowiska produkcyjnego, testowego oraz deweloperskiego
- brak wdrożonego HA (High Availability),
- brak wdrożonych procedur DR (Disaster Recovery) czy też dedykowanego środowiska DR,
- brak procedur bezpieczeństwa,
- wymagające aktualizacji systemy operacyjne ,
- wymagająca aktualizacji baza danych,
- system SAP ERP wymagał aktualizacji do implementacji nowych funkcjonalności oraz podniesienia bezpieczeństwa systemu.
Migracja ERP do Azure – dodatkowe ważne kwestie
Zespół EY SAP w ramach usługi migracji systemu SAP ERP do chmury Microsoft Azure zadbał także o projekt techniczny systemu wraz z HA i procedurą DR, aktualizacje systemów operacyjnych, bazy danych oraz aktualizację systemu do najnowszej wersji.
Kompleksowe podejście pozwoliło na zredukowanie czasu niedostępności systemu, obniżenie kosztów oraz jakże istotne podniesienie bezpieczeństwa systemu i jego SLA.
Czy takie usługi jak aktualizacja systemu operacyjnego, bazy danych, aplikacji SAP czy też konwersja do S/4 HANA są wyznacznikiem przejścia do chmury publicznej?
Niekoniecznie, gdyż zalety chmury publicznej czy też hybrydowej, są niezależne od tych usług. Jednak, w porównaniu z jednostkową wyceną, kompleksowa oferta może okazać się bardziej atrakcyjna z perspektywy budżetowej.
Migracja do Azure – kiedy rozważyć?
Nie ma jednego, uniwersalnego argumentu, który zadecyduje o przejściu do Azure. Jednak w ocenie warto zmierzyć wagę następujących czynników:
- elastyczność,
- separacja galwaniczna aplikacji,
- mechanizmy HA, DR,
- bezpieczeństwo,
- monitorowanie usług,
- możliwość integracji,
- wysokie SLA,
- elastyczność projektowa – bardzo szybkie tworzenie nowych instalacji,
- redukcja TCO (Total Cost of Ownership),
- kwestie zarządzania / administracji w przypadku modelu IaaS (Infrastructure as a Service).
Podsumowanie
Wszystko zaczęło się od niedostępności systemów, których efektem końcowym była migracja do Microsoft Azure. Awaria infrastruktury w prezentowanym, realnym przypadku była pewnego rodzaju zapalnikiem do wdrożenia innowacji u Klienta. Co ważne, proces odbył się bez wpływu na procesy biznesowe.
