4 min. czytania 7 gru 2020
SAP na platformie Azure

Jak SAP na platformie Azure może zwiększyć bezpieczeństwo oraz dostępność systemu SAP ERP?

Autor Marcin Przerwa

EY Polska, Technology Consulting, SAP Basis Manager

Pasjonat nowych technologii, nie tylko z obszaru SAP. Gadżeciarz. Miłośnik sportów zespołowych, który wierzy, że wspólny sukces smakuje lepiej.

4 min. czytania 7 gru 2020
Powiązane tematy EY SAP Technologia Consulting

Bezpieczeństwo, zapewnienie ciągłości działania systemów i inteligentne wykorzystanie technologii jest możliwe dzięki wykorzystaniu SAP on Azure w modelu IaaS.

W każdej organizacji zdarzają się awarie systemów informatycznych. Jedne mogą przybrać małą skalę, inne z kolei ogromną. W dużej mierze wszystko zależy od tego, jak dany system został zaprojektowany, a raczej jak została zaprojektowana infrastruktura, na której działa.

Pojedynczy punkt awarii – Single Point of Failure

Najbardziej newralgicznym punktem każdego systemu jest tak zwany „Pojedynczy punkt awarii”. Jest to komponent systemu, którego awaria spowoduje całkowitą niedostępność systemu lub jego podstawowych funkcji. Mając wiedzę o tych punktach, można je wyeliminować poprzez redundancję lub inne sposoby zabezpieczeń jak HA – High Availability czy DR – Disaster Recovery. W efekcie, wzrasta odporność systemu na awarię i zwiększa się jego dostępność dla użytkowników końcowych – SLA. Oczywiście jest wiele rozwiązań HA oraz DR dostępnych na rynku, które są specyficzne dla pojedynczego produktu lub uniwersalne dla całej rodziny produktów. 

W rzeczywistości, niewiedza projektujących infrastrukturę lub też „oszczędności” często prowadzą już na samym etapie projektowania do zwielokrotnienia tzw. „Pojedynczych punktów awarii”, a nie do ich zabezpieczania. Oczywiście, tego typu błędy mogą pojawić się także później, w czasie eksploatacji systemu. Na przestrzeni czasu, podczas użytkowania systemu, często podejmowane są różnego rodzaju decyzje, które wymagają łączenia systemów na poziomie infrastruktury czy też ich przenoszenia na inne zasoby.

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).

Bezpośrednio na maila

Bądź na bieżąco i subskrybuj newsletter EY

Subskrybuj

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.  

Informacje

Autor Marcin Przerwa

EY Polska, Technology Consulting, SAP Basis Manager

Pasjonat nowych technologii, nie tylko z obszaru SAP. Gadżeciarz. Miłośnik sportów zespołowych, który wierzy, że wspólny sukces smakuje lepiej.

Powiązane tematy EY SAP Technologia Consulting