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 SAP ERP – 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 SAP ERP. Tylko jak do tego doszło, że awarii uległy wszystkie trzy środowiska SAP ERP – 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.
