W ostatnich latach na popularności zyskuje Big Data, czyli przetwarzanie olbrzymich, złożonych zbiorów danych. Przetwarzanie tak dużych ilości informacji jest przydatne lub nawet niezbędne dla sprawnego prowadzenia biznesu, jednak zbyt duża ilość danych wytworzonych i utrzymywanych w bazie danych generuje koszty dla działów IT, utrudnia zarządzanie taką bazą, a co gorsza, powoduje spadek wydajności i wydłuża potencjalny czas przestoju w przypadku awarii. Z takimi problemami w zarządzaniu ilością danych na co dzień mierzą się działy IT firm korzystających z zaawansowanych systemów do zarządzania biznesem.
DVM – podkręcić system
Firma 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 i jednocześnie zoptymalizuje koszty IT dotyczące infrastruktury i utrzymania systemów SAP.
Z usług DVM oferowanych przez BCC skorzystała firma Herlitz, od wielu lat współpracująca z BCC w zakresie rozwiązań IT dla biznesu. Kluczową aplikacją biznesową firmy jest SAP ERP, w którym są realizowane procesy z zakresu zarządzania finansami i kontrolingiem, zarządzania gospodarką materiałową i produkcją, a także sprzedaży. System został wdrożony w 2005 r.
Obecnie środowisko systemu SAP ERP firmy Herlitz składa się z trzech systemów: rozwojowego, testowego (tzw. zapewnienia jakości) oraz produkcyjnego. Rozwiązanie wykorzystuje platformę wirtualną oraz pracuje pod kontrolą systemu operacyjnego Windows Server i bazy danych MS SQL Server.
Wyzwania
Najważniejsze wyzwania związane z postępującym wzrostem wolumenu danych utrzymywanych w bazie systemu SAP, z jakimi przyszło się zmierzyć działowi IT firmy Herlitz, to:
- zapewnienie wydajnego systemu dyskowego,
- zapewnienie odpowiednio dużej przestrzeni dyskowej dla całego pejzażu systemów SAP o nieustannie zwiększających się rozmiarach,
- potrzeba zapewnienia wydajnych mechanizmów tworzenia kopii zapasowej dużej bazy danych,
- odtworzenie bazy danych po potencjalnej awarii z zachowaniem akceptowalnego dla biznesu czasu niedostępności systemu,
- długi czas potrzebny na odświeżenie środowiska testowego danymi z systemu produkcyjnego (ze względu na czas wykonania niemożliwa była już tzw. kopia mandanta podczas weekendowej przerwy serwisowej).
Bieżące utrzymanie SAP
Praktycznie od dnia uruchomienia systemu Herlitz korzysta z usługi wsparcia administracji SAP w BCC. W ramach tej usługi, podczas regularnych konsultacji, nasi specjaliści weryfikują stan i kondycję systemów SAP. Podczas takiej analizy identyfikowane są problemy, potencjalne zagrożenia oraz obszary do poprawy.
Z zakresu DVM weryfikuje się, czy przyrost bazy nie ma niepokojącej tendencji długo- i krótkoterminowej. W przypadku nagłego przyrostu danych ustala się, co jest przyczyną takiego wzrostu, oraz opracowuje się plan działań zaradczych.
Na podstawie wieloletnich doświadczeń w administrowaniu systemami SAP naszych klientów możemy na przykład stwierdzić, że bardzo częstą przyczyną marnotrawienia przestrzeni w bazie danych są błędy związane z bieżącym utrzymaniem systemu (tzw. housekeeping tasks). Tabele z danymi o charakterze technicznym i jednocześnie z założenia tymczasowym powinny być regularnie czyszczone. Przykładem takich danych są niektóre logi, jak log systemowy, logi zadań, a także wydruki i zrzuty ABAP. Za czyszczenie tego typu danych odpowiedzialne są tzw. zadania standardowe. Konsultanci BCC podczas wizyt w Herlitz weryfikują, czy te zadania są wykonywane zgodnie z zaleceniami SAP oraz wymaganiami i potrzebami Herlitz oraz czy nie ma błędów w wariantach selekcji dla tych zadań, które mogłyby wpływać na pomijanie części danych nadających się do usunięcia.
Archiwizacja danych historycznych
Po kilku latach intensywnego wykorzystywania systemu SAP do bieżącego prowadzenia przedsiębiorstwa rozmiar systemu zazwyczaj znacznie się powiększa, podczas gdy wiele starszych danych nie jest wykorzystywanych lub są one wykorzystywane sporadycznie. Częstym powodem przechowywania w SAP danych starszych niż kilka lat są wymogi prawne (np. w celu udostępniania ich instytucjom takim jak ZUS czy urząd skarbowy).
Mechanizmy archiwizacji w systemie SAP pozwalają na zmniejszenie wielkości bazy danych poprzez przeniesienie wybranej części danych do zewnętrznego archiwum. Takim archiwum może być po prostu przestrzeń dyskowa lub zewnętrzne repozytorium dla danych archiwalnych.
Po przeniesieniu danych do archiwum dostęp do nich jest nadal możliwy z poziomu systemu SAP. Zazwyczaj dostęp jest realizowany z poziomu tych samych transakcji, co dla danych dostępnych z bazy. Czasami jednak dostęp może być zapewniony z dedykowanych do tego celu transakcji, a dane mogą być prezentowane w odmienny sposób.
Dla firmy Herlitz projekt archiwizacji danych z SAP został przeprowadzony w dwóch etapach. Pierwszy, w 2014 roku, obejmował archiwizację danych z obszarów MM oraz SD. Drugi etap, wykonany w 2015 roku, dotyczył obszarów FI, CO i PP.
W pierwszym przebiegu archiwizacji odzyskano około 300 GB z przestrzeni bazy danych. W dalszym kroku zaplanowano archiwizację jako działanie cykliczne. Powtarzana co miesiąc sekwencja wykonywanych zadań zapewnia, że najstarsza część danych jest archiwizowana na bieżąco. Taka strategia zapobiega ponownemu nadmiernemu nagromadzeniu starszych danych w bazie i konieczności przeprowadzenia w przyszłości kolejnego złożonego i długotrwałego procesu archiwizacji.
Wychwytywać trendy, odpowiednio reagować
Wydajna i stabilnie działająca baza danych to jedna z podstaw efektywnie funkcjonującego systemu ERP, a MS SQL Server to dobry i wydajny produkt, który dobrze sprawdza się jako bazodanowe zaplecze systemu SAP. Ale, jak każde z rozwiązań informatycznych, również baza danych wymaga opieki i nadzoru, aby dobrze pełniła swoje funkcje. W tym kontekście pracownicy działu informatyki firmy Herlitz chętnie korzystają z wiedzy i doświadczenia specjalistów BCC (aktualnie All for One Poland). W ramach umowy wsparcia administracyjnego, podczas comiesięcznych wizyt monitoringowych – wspólnie analizujemy wskaźniki wydajnościowe oraz logi systemu operacyjnego, bazy danych i SAP – poszukując ewentualnych czynników alarmujących.
Comiesięczny rytm wykonywania analiz i generowania raportów EWA (Early Watch Alert) systemu SAP pozwala dobrze wychwycić trendy dotyczące zmian obciążenia systemu, zajętości dysków i odpowiednio reagować, uprzedzając potencjalne zagrożenia. Dzięki takiemu podejściu pracownikom działu informatyki Herlitz udaje się utrzymać wysoki poziom zadowolenia kilkudziesięciu użytkowników końcowych systemu, którzy nie doświadczają w codziennej pracy irytujących problemów związanych z wydajnością czy długim czasem reakcji systemu.
Rozrost bazy danych był jednym z widocznych trendów, które pojawiły się wraz z upływem kolejnych lat użytkowania systemu SAP. Przysparzał on problemów wydajnościowych – w mniejszym stopniu w codziennej pracy użytkowników systemu – ale raczej w pracach serwisowych realizowanych przez dział informatyki, wykonywaniu codziennych backupów czy kopii mandanta. Na przykład konieczność wykonywania w sposób niestandardowy kopii mandanta produktywnego na system testowy powodowała kilkudniową przerwę w pracy systemu testowego, zatrzymanie prac rozwojowych i wymagała dużo większych nakładów ze strony działu informatyki niż standardowa procedura.
Konsultanci BCC zaproponowali kilka równoległych rozwiązań pomagających poradzić sobie z tym problemem. Jednym z nich było uruchomienie procesów archiwizacji w poszczególnych modułach SAP. Przebiegły one dwuetapowo. Zarchiwizowanie w pierwszej kolejności mniej wrażliwych danych z obszarów MM i SD pozwoliło skutecznie wykonać kolejną kopię mandanta i w drugim etapie dogłębnie przetestować system przy archiwizowaniu bardziej wrażliwych danych z modułów FI i CO.
Po konsultacjach z BCC, przy okazji upgrade’u platformy sprzętowej, zdecydowaliśmy się również na kompresję w bazie danych. Przekonały nas argumenty wydajnościowe, a uzyskany rozmiar wynikowy bazy danych po uruchomieniu kompresji przekroczył nasze oczekiwania. W mojej ocenie kompresja bardzo dobrze sprawdza się na bazie danych operującej na zestawie znaków Unicode, a obsługi tego standardu wymaga od dłuższego czasu SAP.
Dla działu informatyki firmy średniego rozmiaru, jaką jest Herlitz, utrzymanie i zapewnienie wsparcia administracyjnego systemu SAP we własnej siedzibie jest dużym wyzwaniem. Dzięki współpracy z BCC w obszarze wsparcia administracyjnego systemu udaje się to zdanie realizować skutecznie i efektywnie.
Dominik Zakrzewski, Kierownik Działu Informatyki, Herlitz
Kompresja dla SAP
W 2014 roku firma Herlitz przystąpiła do okresowej wymiany platformy sprzętowej dla środowiska SAP. Projekt został zrealizowany przez konsultantów firmy BCC. W ramach projektu, poza przygotowaniem nowej platformy sprzętowej i środowiska wirtualnego Hyper-V, systemy SAP zmigrowano na najnowsze wersje systemu operacyjnego i bazy danych.
Przy rozważaniu uruchomienia kompresji dla SAP częstą obawą administratorów systemu jest ryzyko zwiększenia wykorzystania zasobów CPU związane z narzutem na kompresję i dekompresję danych w locie, tym bardziej, że operacje zapisu/odczytu bufora SQL również wymagają kompresji/dekompresji. Doświadczenie pokazuje jednak, że zysk wynikający ze znacznego spadku operacji dyskowych I/O oraz zwiększenie współczynnika trafień bufora przewyższa straty wynikające z narzutu CPU na kompresję, co przekłada się na ogólny wzrost wydajności systemu SAP. To wydajność podsystemu dyskowego jest zazwyczaj największym ograniczeniem dla wydajności serwerów baz danych, a właśnie kompresja pozwala nam znacznie zmniejszyć zapotrzebowanie na operacje dyskowe I/O.
W przypadku firmy Herlitz nie było obaw o ewentualne problemy z narzutem CPU na kompresję, gdyż nowa platforma sprzętowa, wyposażona w znacznie wydajniejsze procesory niż stare serwery, zapewniała spory zapas mocy obliczeniowej. W tym przypadku zdecydowano się na wykorzystanie kompresji stron, gdyż daje ona lepsze efekty.
Podczas zaledwie jednego weekendu prac na systemie produkcyjnym wykonano jednocześnie:
- wirtualizację – migrację SAP ERP na nowy wirtualny serwer,
- zmianę wersji na najnowsze: systemu operacyjnego Windows Server i bazy danych MS SQL,
- kompresję MS SQL,
- reorganizacja plików danych; po kompresji zmniejszono rozmiar plików bazy danych, dzięki czemu odzyskano przestrzeń zajmowaną dotychczas przez bazę danych.
Od wersji SQL Server 2008 mamy do dyspozycji dwa zasadnicze typy kompresji:
– Kompresja wierszy (ang. row kompression) – polega na przechowywaniu rekordów w słowach o zmiennej długości. I tak np. dla danych typu int, gdzie klasyczny zapis zawsze wykorzystuje 4 bajty, przy kompresji wierszy wartość 1 zapisywana jest z użyciem jednego bajta, co pozwala zaoszczędzić nadmiarowe 3 bajty, a wartości NULL i 0 nie są w ogóle przechowywane. Tego typu kompresja nie wpływa na dodatkowe użycie zasobów CPU.
– Kompresja stron (ang. page compression) – jest niezależna od typu danych. Polega na wyszukiwaniu powtarzających się ciągów bitów i zapisywaniu ich w słowniku kompresji każdej ze stron (strona jest to podstawowa jednostka przechowywania danych w MS SQL; operacje zapisu i odczytu na dyskach odbywają się stronami). Kompresja i dekompresja podczas działania na danych wymaga dodatkowych operacji CPU, zwłaszcza dla operacji DML. Skompresowane strony przechowywane są również w buforze, co oznacza, że dostęp do bufora stron wymaga dodatkowych zasobów CPU. Jednak przechowywanie skompresowanych stron w buforze ma też olbrzymią zaletę – przy tym samym rozmiarze bufora i tej samej liczbie stron w buforze mieści się więcej użytecznych danych, co wpływa na zwiększenie współczynnika trafień bufora (ang. cache hit ratio), a co za tym idzie, dodatkowe zmniejszenie operacji odczytów z dysków i zmniejszenie obciążenia CPU. Kompresja stron pozwala na osiągnięcie lepszego współczynnika kompresji niż kompresja wierszy.
Od maja 2011 r. firma SAP dla swoich produktów opartych na NetWeaver ABAP zaczęła używać domyślnie włączonej kompresji stron dla wszystkich nowych instalacji na MS SQL. Dzięki temu rozmiar bazy dla np. SAP ERP EHP6 po instalacji miał jedynie 30 GB.
Imponujące wyniki
Wyniki kompresji były wręcz imponujące. Z dotychczasowego rozmiaru bazy danych 768 GB zajętość spadła do 158 GB, czyli uzyskany rozmiar stanowił 21% rozmiaru oryginalnego. Już sama reorganizacja danych wykonana podczas kompresji pozwala na odzyskanie części przestrzeni, jednak za tak znaczny spadek wielkości bazy odpowiada właśnie kompresja.
Dla wszystkich trzech systemów w pejzażu SAP ERP Herlitza po serii prac DVM (archiwizacja i kompresja) rozmiar baz danych osiągnął zaledwie 17% wielkości wyjściowej. Tym samym odzyskano ponad 1,7 TB przestrzeni dyskowej. Dla systemu produkcyjnego średni roczny wzrost rozmiaru bazy spadł o 70%. Jeśli założyć, że taki trend wzrostu będzie się utrzymywał, to rozmiar bazy danych systemu produkcyjnego osiągnąłby rozmiar sprzed prac w okolicy roku 2042…