Zarządzanie wielkością środowiska SAP stanowi istotny aspekt posiadania systemu praktycznie w każdej firmie. Dla administratorów i deweloperów rodzi wyzwania związane z utrzymaniem i rozwojem. Użytkownicy muszą się borykać ze zbyt długim czasem reakcji systemu i wykonywania się kolejnych operacji. Dla zarządu firmy duże wolumeny danych utrzymywanych na dyskach i serwerach to dodatkowe nakłady na utrzymanie systemu zintegrowanego.
Zarządzanie wielkością systemów jest ważne w każdym momencie ich cyklu życia. Coraz więcej danych i rozrost bazy z dziesiątek do setek gigabajtów i dalej wartości liczonych w terabajtach zawsze przekłada się bowiem na rosnące koszty. Przy znacznym przyroście danych koszty nie rosną już liniowo, lecz wykładniczo.
Odpowiednio wydajne macierze dyskowe, serwery o wystarczającej mocy obliczeniowej, systemy backupowe pozwalające odtworzyć system w akceptowalnym przez biznes czasie to wymagania, za którymi kryją się konkretne kwoty.
Wyróżnikiem – i zarazem największą zaletą platformy SAP HANA – jest wykorzystanie dobrodziejstw rozwoju technologii, która umożliwia wykonywanie wszystkich operacji w pamięci operacyjnej. Serwery z 1 TB lub więcej pamięci operacyjnej jeszcze kilka lat temu były poza zasięgiem wyobraźni. Dziś są już dostępne (dla SAP HANA firma SAP rekomenduje tzw. certyfikowane serwery SAP HANA Appliance, o pojemności powyżej 1 TB), jednak ich koszt nadal pozostaje poza zasięgiem wielu firm.
Czas na porządki
Nie oznacza to jednak, że firmy, w których obecna wielkość bazy danych generuje koszty infrastruktury pod HANA przekraczające ich budżety, powinny pożegnać się z myślą o większej szybkości przetwarzania i wydajności systemów SAP, jaką oferuje SAP HANA. Oznacza to jedynie, że czas na… porządki.
Po kilku latach bieżącego prowadzenia przedsiębiorstwa w systemie SAP jego rozmiar zazwyczaj znacznie się powiększa. Część starszych danych nie jest już wykorzystywana, część jest wykorzystywana sporadycznie (powodem mogą być np. wymogi prawne związane z udostępnianiem instytucjom takim jak ZUS czy US). Duży potencjał odchudzenia tkwi także w tabelach technicznych systemu.
Dostępne w systemie SAP mechanizmy archiwizacji oraz usunięcie niepotrzebnych danych pozwalają na odzyskanie znacznych przestrzeni dyskowych i kilkukrotne zmniejszenie wielkości bazy danych. Zarchiwizowane dane są nadal dostępne z poziomu systemu SAP, na co dzień nie obciążają jednak bazy danych, a są przechowywane w zewnętrznych archiwach.
Wykonanie archiwizacji, a następnie usunięcie niepotrzebnych danych technicznych, wraz z ich reorganizacją to istota projektów Data Volume Management, jakie BCC wykonuje dla swoich klientów i jakie rekomenduje jako pierwszy krok wszystkim firmom, które rozważają przejście na platformę HANA. Uzupełnieniem projektu DVM powinien być cykliczny przegląd systemów pozwalający utrzymać sizing na rozsądnym poziomie i nie dopuszczać do ponownego niekontrolowanego przyrostu wielkości bazy danych.
Data Volume Management – podkręcić i odchudzić system
BCC (aktualnie All for One Poland) od lat oferuje i rozwija usługi, których celem jest optymalizacja i efektywne zarządzanie wolumenem danych. Celem pakietu usług oferowanych pod nazwą Data Volume Management (DVM) jest wypracowanie rozwiązania, które zaspokoi wymagania biznesowe związane z dostępem do dużych ilości informacji. W skład pakietu wchodzą m.in. analiza systemów pod kątem sizingu baz danych, archiwizacja danych historycznych, a także kompresja i reorganizacja plików danych. Oprócz projektu DVM naszym klientom rekomendujemy także cykliczne przeglądy i czyszczenie baz danych. W ramach usług administracji SAP dla klientów BCC wykonujemy także weryfikację krótko- i długoterminowych trendów w zakresie nagłego przyrostu danych, ustalenie przyczyn, a także opracowujemy plany działań zaradczych.
Działania z zakresu DVM rekomendujemy szczególnie tym firmom, które planują wirtualizację lub migrację swoich systemów na nową platformę sprzętową, w tym SAP HANA.
Bądź fit, urealnij koszty
Dbałość o przechowywanie tylko tych danych, które są istotne dla funkcjonowania biznesu, pozwoli firmom skorzystać z HANA przy akceptowalnym poziomie kosztów. Dlaczego? Jednym z powodów niech będą dane przechowywane kolumnowo w bazie, które w przypadku bazy danych HANA muszą być wczytane w całości do pamięci operacyjnej. Jak łatwo się domyśleć, im danych więcej, tym czas ładowania i odczytu jest dłuższy. Także np. uruchomienie bazy, a w konsekwencji systemu trwa dłużej.
Oczywiście nowe rozwiązania technologiczne wychodzą naprzeciw tym potrzebom. I tak np. karty FusionIO, dyski SSD w certyfikowanych serwerach SAP HANA Appliance czy odpowiednio przygotowane macierze dyskowe w rozwiązaniach SAP HANA Tailored Datacenter Integration (TDI) pozwalają szybko odczytywać wiele gigabajtów danych. Niemniej w każdym rozwiązaniu każdy gigabajt kosztuje.
Wśród wspomnianych już tabel kolumnowych istnieją też takie, które mogą zająć wiele pamięci operacyjnej (np. >500 GB), a w konsekwencji potrzebują także dużo czasu na ich wczytywanie. Niektóre są potrzebne tylko w niewielkiej części, inne z kolei pozostają niewykorzystane i niepotrzebne. Tu szczególną uwagę warto zwrócić na tabele techniczne, które mogą zawierać dane nieużywane w pracy biznesowej, a które można zarchiwizować lub po prostu usunąć.
Bardzo pomocne i wręcz obowiązkowe w przygotowaniach do migracji systemów SAP na platformę HANA są dostarczane przez SAP raporty sizingowe, tj. /SDF/HDB_SIZING (ZNEWHDB_SIZE).
System 5 razy mniejszy
Posłużmy się w tym momencie przykładem. Powyżej zamieszczamy wycinki rezultatów raportu sizingowego dla systemu SAP ERP, w którym nie była wykonywana archiwizacja komunikatów IDOC. Konieczność weryfikacji komunikatów znacznie się różni w zależności od systemu, specyfiki działania przedsiębiorstwa i biznesu, niemniej zasadą jest, że komunikaty IDOC powinny być regularnie archiwizowane. Pozwala to na utrzymanie wielkości tabel EDID4 i EDIDS w rozsądnych wartościach.
W sytuacji, którą obrazują fragmenty raportów, nadmiarowe dane zaowocowały przewidywanym zapotrzebowaniem na ok 1,4 TB pamięci operacyjnej. Oczywiście taka wartość może zostać obsłużona zarówno przez rozwiązania SAP HANA Appliance, jak również przez SAP HANA TDI. Jednak w tym przypadku konieczne koszty nie mają żadnego uzasadnienia.
Po uprządkowaniu, analizie i z archwizowaniu komunikatów, jakie BCC (aktualnie All for One Poland) wykonało w ramach usługi DVM, okazało się, że wystarczyłaby wirtualna maszyna w rozwiązaniu SAP HANA TDI z 256 GB pamięci operacyjnej.
Dla pojedynczego systemu otrzymaliśmy estymację na użycie pamięci operacyjnej w wysokości 1428 GB (przed analizą i optymalizacją) oraz zaledwie 266 GB (po projekcie DVM). Różnica jest ponad 5-krotna!
W tym konkretnym przypadku pejzaż środowiska SAP składał się z trzech systemów: deweloperskiego, testowego i produkcyjnego. A zatem, upraszczając rachunki, system, który nie został poddany Data Volume Management, wykazuje ponad 15-krotnie większe zapotrzebowanie infrastrukturalne niż system, który został poddany temu procesowi. Odpowiednio wyższe są także koszty zakupu i następnie utrzymania infrastruktury.
Po wykonaniu usługi DVM system zajmuje 5 razy mniej pamięci operacyjnej
DVM – konieczny krok migracji
Nie wszystkie systemy mają aż tak spektakularne możliwości odchudzenia, lecz nie będzie nadużyciem stwierdzenie, że we wszystkich znajdą się rzeczy nadmiarowe. Analiza danych przechowywanych w tabelach kolumnowych, jak również archiwizacja danych niepotrzebnych są koniecznością.
Doświadczenia BCC w migracjach systemów SAP na nowe platformy sprzętowe, w tym także SAP HANA, a także stałe usługi utrzymania i administracji SAP, jakie świadczymy dla naszych klientów, potwierdzają, że powyższy przykład nie jest odosobniony.
Dlatego też analiza wielkości bazy danych systemu SAP oraz wykonanie prac z zakresu Data Volume Management to kroki, które zawsze zalecamy naszym klientom przed migracją systemów do SAP HANA, a nawet jeszcze przed planowaniem budżetu na taką inwestycję.
Warto także mieć świadomość, że ewentualne konsekwencje pominięcia analizy i uporządkowania to nie tylko zbyt wysoki koszt sprzętu i jego utrzymania. Znaczne wydłużenie czasu koniecznego na wykonanie procesu migracji może sprawić, że będzie to wręcz niemożliwe w akceptowanym przez biznes oknie czasowym.
Wszyscy płacimy za zbędne informacje. Administratorzy w codziennej walce z wydajnością i skalowalnością systemów. Deweloperzy z kodem programów, by minimalizować liczbę odczytywanych danych. Użytkownicy z dodatkowymi polami wyboru, by nie wyławiać np. tej jednej poszukiwanej faktury z oceanu utworzonych. A zarząd z rachunkami za utrzymanie i zarządzanie infrastrukturą. Dbanie o rozsądne (czytaj: możliwie jak najmniejsze) wielkości baz danych systemów jest w interesie wszystkich.
SAP HANA w modelu TDI w All for One Data Centers
Alternatywą wobec struktury SAP HANA Appliance jest możliwość utrzymania systemów SAP HANA w oparciu o rozwiązanie TDI w All for One Data Center. Ta opcja obniża barierę wejścia w rozwiązania HANA dla tych firm, w których wielkość bazy danych systemu SAP nie uzasadnia inwestycji w infrastrukturę SAP HANA Appliance.
Systemy SAP HANA utrzymywane w All for One Data Centers wykorzystują platformę sprzętowo-programową określoną przez SAP jako Tailored Datacenter Integration (TDI). TDI w All for One Data Centers to udzielana przez SAP gwarancja, że wykorzystywane przez centra przetwarzania danych BCC (aktualnie All for One Poland) zasoby infrastruktury sprzętowej spełniają restrykcyjne wymagania dotyczące wydajności, dostępności i bezpieczeństwa w kontekście utrzymywania systemów SAP HANA. Gwarancja producenta obejmuje również personel techniczny zajmujący się instalacją systemów oraz ich późniejszym utrzymywaniem.
Dodatkowym potwierdzeniem profesjonalizmu i bezpieczeństwa gwarantowanego przez All for One Data Centers są certyfikaty SAP Certified in Hosting Services, SAP Certified in SAP HANA Operations Services.