Migracja SAP Business Suite na SAP HANA przenosi rozwiązania takie jak SAP ERP, SAP CRM, SAP SCM w zupełnie nowy wymiar przetwarzania w pamięci. Wyposażenie sprawdzonych systemów transakcyjnych, jak np. SAP ERP, w platformę przetwarzania w pamięci SAP HANA pozwala na wielokrotne zwiększenie wydajności systemu.

SAP HANA eliminuje ograniczenia relacyjnej bazy danych RDBMS, łącząc cechy bazy transakcyjnej z analityczną. Wielokrotnie zwiększona wydajność, pozwalająca uzyskać nawet tysiąckrotne przyspieszenie, pozwala na raportowanie bezpośrednio z systemu transakcyjnego SAP, bez szkody dla wykonywanych jednocześnie transakcji. Dzięki zastosowaniu SAP HANA w systemach SAP Business Suite możliwe staje się wykorzystanie przetwarzania w czasie rzeczywistym, tam gdzie dotychczas ze względu na wydajność zadania były wykonywane „w tle”.

Projekty migracji SAP Business Suite na SAP HANA to ciągle jeszcze przedsięwzięcia pionierskie. W migracji rozwiązań SAP na platformę HANA, BCC (aktualnie All for One Poland) wykorzystuje swoje wcześniejsze doświadczenia z podobnych projektów, na różne platformy sprzętowe i systemowe.

Zanim zaczniesz

Platforma HANA – mimo że obecna w ofercie SAP od trzech lat i bardzo obiecująca, dopiero przeciera sobie szlak do biznesu. Rozwiązanie jest ciągle rozwijane i pierwsze projekty migracji odbywają się pod nadzorem konsultantów SAP. Ich rolą jest przekazywanie rekomendacji i doświadczeń odnośnie do podejścia do planowania prac i wersji narzędzi koniecznych do wykorzystania w trakcie upgrade’u i migracji systemów.

Na potrzeby migracji systemów na HANA firma SAP dostarcza też nieodpłatną usługę, z  pomocą której łatwiej można określić obszary wsparcia i wpływ na poprawę wydajności systemu zainstalowanego już na platformie HANA. Usługa nazwa się Business Scenario Reccomendation  for Suite on HANA i polega na analizie odpowiednio przygotowanego zestawienia wykorzystania oraz wydajności transakcji realizowanych na systemie klienta. Odpowiednio spreparowany raport z transakcji ST03N jest przekazywany do specjalistów SAP, którzy po analizie zawartości przekazują informację o transakcjach i obszarach, które ulegną poprawie po migracji.

Ze względu na nowatorskie rozwiązania, przed rozpoczęciem projektu migracji rekomendujemy przeprowadzenie dokładnej analizy zakresu prac oraz dostępnej dokumentacji, jaką daje producent systemu. Podczas analizy zakresu działań na początku należy zweryfikować:

  • wersje komponentów wykorzystywanych w systemie,
  • różnice w funkcjonowaniu systemów dla docelowych wersji komponentów,
  • narzędzia techniczne służące do przeprowadzenia upgrade’u i migracji,
  • dostępną dokumentację techniczną oraz systemową,
  • aktualną konfigurację systemu oraz odpowiednie raporty z działania systemu.

Całe przedsięwzięcie prowadzone jest zgodnie ze standardami SAP (metodyka All for One Go Forward oparta na ASAP) i best practices opracowanych przez Project Management Institute, co narzuca wysokie standardy postępowania oraz zapewnia podwyższenie poziomu bezpieczeństwa, a także zwiększa szanse na powodzenie projektu. Chodzi tu głównie o dokładną analizę zakresu zidentyfikowanych zadań uczestników i osób zaangażowanych, ryzyk projektowych, czasu i planu realizacji, budżetu i obowiązujących wymagań jakościowych.

Migracja na SAP HANA – nie taki diabeł straszny

SAP HANA (High Performance Analytic Appliance) to technologia oparta na przetwarzaniu danych w pamięci. Z technicznego punktu widzenia to przede wszystkim bardzo szybka baza danych, która jako platforma doskonale nadaje się dla systemów SAP ERP czy BW.

Projekt migracji systemu do bazy HANA nie jest projektem skomplikowanym, jeśli właściwie się do niego przygotujemy. Całość możemy podzielić na cztery etapy:

  • przygotowanie,
  • migracja,
  • kroki po migracji,
  • optymalizacja.

Przygotowanie

Proces przygotowania warto rozpocząć od określenia, jaki sprzęt będzie nam potrzebny, aby przenieść się na bazę danych HANA. Sprzęt dla HANA jest dostarczany przez certyfikowanych partnerów firmy SAP, takich jak: Dell, Fujitsu, HP, IBM, Cisco  w postaci gotowych serwerów (SAP HANA Appliance) wraz z zainstalowanym oprogramowaniem HANA.

Wymiarowanie sprzętu polega na określeniu, ile będziemy potrzebowali pamięci RAM dla bazy danych HANA. Pozostałe parametry (CPU, dyski itp.) są odpowiednio dobrane w zależności od ilości pamięci, jakie posiada platforma HANA, i nie musimy ich określać. Certyfikowane platformy są publikowane na stronach SAP: http://service.sap.com/pam.

W zależności od rodzaju migrowanego systemu (ERP lub BW) do wymiarowania sprzętu korzystamy z przygotowanych przez SAP raportów:

  • BW: /SDF/HANA_BW_SIZING – raport dostępny w ramach komponentu ST-PI (warto zaktualizować komponent do najnowszej wersji),
  • ERP: ZNEWHDB_SIZE – raport należy utworzyć na systemie zgodnie z notą SAP 1872170.

Jeśli dla systemów ERP nie mamy możliwości utworzenia na systemie raportu ZNEWHDB_SIZE, możemy spróbować oszacować potrzebną ilość pamięci RAM zgodnie z poniższym wzorem (nota SAP 1793345):

RAM = DB size (uncompressed, „well-maintained”) / 2 + 20%.

Tak otrzymaną wartość należy dodatkowo zwiększyć, uwzględniając powiększanie się bazy danych w kolejnych latach.

Należy również pamiętać, że:

  • sprzęt do HANA wykorzystujemy tylko dla baz danych – serwery aplikacyjne instalujemy na osobnych serwerach (lub wirtualnych maszynach),
  • dla systemów rozwojowych oraz testowych SAP wspiera  wykorzystanie wirtualizacji (VMware) lub uruchomienie kilku baz na jednym serwerze HANA,
  • dla systemów produkcyjnych wykorzystujemy tylko fizyczny sprzęt (wirtualizacja nie jest wspierana przez SAP),
  • systemy BW możemy skalować na wielu serwerach HANA,
  • na razie nie ma możliwości skalowania bazy systemu ERP na wielu serwerach HANA – musimy korzystać ze skalowania w ramach jednego serwera (odpowiednia ilość pamięci RAM),
  • platforma HANA pozwala na zachowanie wysokiej dostępności poprzez wykorzystanie serwera standby zarówno dla systemów BW, jak i ERP.

Kolejnym krokiem przygotowań powinno być sprawdzenie, czy nasz system spełnia wymagania stawiane przez platformę HANA. Dodatkowo warto również wykonać dodatkowe czynności, które lepiej przygotują nas do migracji:

  • systemy dual-stack (ABAP+JAVA) – należy rozdzielić części ABAP i JAVA:
    – na platformę SAP HANA migrujemy tylko systemy ABAP,
    – JAVA nie jest wspierana na platformie SAP HANA,
  • Unicode – SAP HANA wspiera tylko systemy Unicode, w przypadku systemów non-Unicode konieczne jest przeprowadzenie konwersji do Unicode,
  • 64bit – system operacyjny tylko 64-bitowy,
  • kompatybilność dodatkowych komponentów wykorzystywanych w systemie – należy sprawdzić, czy wykorzystywane dodatkowe komponenty oprogramowania (add-ons) są kompatybilne z EHP7 (nota 1820906),
  • usługa Going Live OS/DB Migration Check – dla systemów produkcyjnych konieczne jest poinformowanie firmy SAP o zamiarze migracji systemów na nową platformę oraz zamówienie sesji sprawdzającej system produkcyjny (1 sesja przed migracją, 2 po migracji), po której otrzymamy raport z zaleceniami,
  • Maintenance Optimizer (Solution Manager) – system Solution Manager z działającą funkcjonalnością Maintenence Optimizer jest konieczny do wygenerowania listy wymaganych komponentów i informacji konfiguracyjnych (pliki xml), które wykorzystujemy podczas aktualizacji systemu:
    – minimum Solution Manager 7.0 EHP1 SP 23,
    – rekomendowany Solution Manager 7.1 SP 05 lub wyższy,
  • archiwizacja i czyszczenie systemu – warto rozważyć zmniejszenie bazy danych poprzez archiwizację lub czyszczenie zbędnych danych (nota 706478), ponieważ wielkość bazy danych przekłada się na wymagane zasoby sprzętu dla HANA (RAM),
  • programy użytkownika (Z*, Y*) – migracja na platformę SAP HANA może wymagać dostosowania własnego kodu:
    – dostosowania wynikające z migracji na Unicode,
    – dostosowania wynikające z wykorzystania funkcjonalności HANA (mogę być również wykonane po migracji).

Migracja

Proces migracji bazy systemu SAP na platformę HANA nie różni się znacząco od migracji między innymi platformami (w SAP taki projekt nazywa się OS/DB migration). W BCC (aktualnie All for One Poland) używamy więc sprawdzonych metodologii i narzędzi, które z powodzeniem wykorzystywaliśmy wielokrotnie u wielu klientów podczas migracji systemów między różnymi bazami danych.

Proces migracji, w pewnym uproszczeniu, polega na wykonaniu eksportu bazy źródłowej oraz zaimportowaniu tak otrzymanej zawartości do bazy docelowej (w naszym przypadku HANA).

Podobnie jak w przypadku innych baz danych, migrując na platformę HANA, możemy skorzystać również z takich rozwiązań jak równoległy import i eksport z wykorzystaniem połączenia TCP/IP. W niektórych sytuacjach pozwoli nam to skrócić czas potrzebny na migrację.

Migracja systemu SAP ABAP na nową platformę (OS/DB migration)

Proces migracji dla większości systemów SAP będziemy musieli wykonać w dwóch etapach:

  1. Aktualizacja systemu do wymaganej przez SAP HANA wersji;
  2. Migracja bazy danych na platformę HANA.

W przypadku systemów BW musimy zaktualizować system do wersji 7.3 SP5 lub wyższej, dopiero później możemy rozpocząć właściwą migrację.

Migracja systemu SAP BW na platformę HANA

W przypadku systemów ERP musimy zaktualizować system do ERP 6.0 EHP7, ewentualnie EHP6 for HANA, jednak zalecamy wykorzystanie najnowszego dostępnego EHP (aktualnie EHP7).

Migracja systemu SAP ERP na platformę HANA

W najnowszej wersji narzędzia SUM 1.0 SP9 dostępna jest w ograniczonym zakresie możliwość wykonania aktualizacji oraz migracji w jednym kroku. Funkcja ta nazywa się DMO (Database Migration Option) i może być ciekawą alternatywą w przypadku systemów pracujących w trybie 24h, aby ograniczyć niedostępność systemu.

DMO (Database Migration Option) – migracja i aktualizacja w jednym kroku

Kroki po migracji

Po zakończeniu migracji i uruchomieniu systemu na platformie HANA konieczne jest dostosowanie samego systemu oraz środowiska z nim związanego. Powinniśmy więc zaplanować następujące działania:

  • wykonanie standardowych kroków technicznych po migracji (takie jak przy innych platformach),
  • techniczne kroki integracyjne – sprawdzenie komunikacji w innymi systemami,
  • integracja infrastruktury – dostosowanie backupów, aktualizacja informacji o systemie w Solution Manager, aktualizacja SLD, monitoring itp.,
  • testy aplikacyjne – sprawdzenie zaimplementowanych procesów biznesowych – sam proces migracji na platformę HANA nie wnosi żadnych zmian do warstwy biznesowej systemu, jednak konieczność aktualizacji systemu (np. instalacja EHP7) wymaga przeprowadzenia testów,
  • Going Live OS/DB Migration Check Service – druga sesja sprawdzająca system po wykonanej migracji – zalecenia z raportu powinny zostać zaimplementowane na systemie.

Optymalizacja

Wykorzystanie potencjału, jaki niesie SAP HANA, zależy w dużej mierze od sposobu, w jaki przetwarzamy dane. W przypadku bazy danych HANA przetwarzanie powinno być przesunięte w stronę bazy danych. Oznacza to, że powinniśmy możliwie dużo operacji wykonywać na poziomie bazy danych i ograniczyć przetwarzanie w warstwie aplikacji.

Przetwarzanie danych na tradycyjnej platformie oraz na platformie z bazą danych HANA

Kiedy system działa już na nowej platformie, czas zabrać się za jego optymalizację. Mimo że wiele transakcji i raportów bezpośrednio po migracji będzie działać szybciej niż na dotychczasowej platformie, warto przyjrzeć się bardziej szczegółowo temu, co dzieje się w naszym systemie.

Oto dwa podstawowe kroki, które powinniśmy wykonać, aby wykorzystać potencjał, jaki niesie baza SAP HANA:

  • Uruchomić akcelerację dla wybranych transakcji/raportów – dla części transakcji SAP przygotował „specjalne” modyfikacje, które można włączyć w transakcji SFW5, podobnie jak aktywuje się funkcje biznesowe. Aktywacja zmienia sposób wykonania danej transakcji/raportu pod kątem możliwości wykorzystania bazy HANA. Aktywacja jest odwracalna, tzn. można ją wyłączyć, jeśli stwierdzimy, że chcemy zrezygnować z akceleracji.
  • Zoptymalizować własny kod, aby korzystał z szybkiego przetwarzania w pamięci, a więc należy dostosować sposób, w jaki nasze programy przetwarzają dane:
    – dostosowanie zapytań SQL,
    – dostosowanie sposobu przechowywania danych – wykorzystanie tabel kolumnowych,
    – wykorzystanie widoków,
    -zastosowanie procedur składowanych.

W procesie analizy i optymalizacji pomogą nam dostępne od dawna w systemie narzędzia, takie jak:

  • SAP Workload: Business Transaction Analysis – tr. STAD,
  • Performance Analysis – tr. ST05,
  • Code Inspector – tr. SCI,
  • DBA Cockpit – tr. DBACOCKPIT,
  • Workload Monitor – tr. ST03N.

Możemy również skorzystać z nowego narzędzia ABAP SQL Monitor (transakcje SQML, SQMA, SQMD), dostępnego w systemach opartych na NetWeaver 7.4 SP3 lub w systemach z komponentem ST-PI w wersji 2008_1_700 SP8.

Narzędzie to pozwala na gromadzenie informacji o zapytaniach do bazy danych w ramach całego systemu, nawet z długiego okresu, np. kilku tygodni. Ponadto rozszerza możliwości analizy zapytań SQL, jakie znamy z transakcji ST05 czy DBACOCKPIT o np. możliwość łatwego powiązania zapytania z transakcją czy raportem, z którego został wywołany.

SAP HANA jako baza danych dla SAP ERP – doświadczenia z projektu

Nasze dotychczasowe doświadczenia pokazują, że HANA jest doskonałą alternatywą dla klasycznej bazy danych i posiada ogromny potencjał nie tylko jako baza danych. Ostatnie doświadczenia, zebrane podczas trwającego u jednego z naszych klientów projektu migracji, pokazują, że uruchomienie systemu ERP na platformie HANA daje odczuwalne korzyści wydajnościowe tuż po migracji, a dalsza optymalizacja może je pomnożyć.

W tabeli prezentujemy porównanie wykonania kilku przykładowych transakcji finansowych na systemie z „klasyczną” bazą danych (przed migracją) oraz na systemie z bazą HANA (zaraz po migracji, bez jakiejkolwiek optymalizacji). Transakcje zostały uruchomione z takim samym zestawem danych i parametrami. Wyniki pokazują znaczny wzrost wydajności, co jest wyraźnie zauważalne dla wszystkich użytkowników systemu.

Porównanie czasu trwania przykładowych transakcji finansowych na systemie z „klasyczną” bazą danych oraz systemie z bazą HANA (bez optymalizacji)

Należy również powiedzieć, że nie dla wszystkich transakcji i programów odnotowaliśmy odczuwalny wzrost wydajności. Część operacji na systemie wykonuje się podobnie jak przed migracją i będzie wymagała dalszej optymalizacji.

Po migracji jednego z systemów klienta chcieliśmy się przekonać, jak duży potencjał drzemie w platformie SAP HANA. W tym celu wykonaliśmy proste zapytanie do bazy danych, które sumuje wartości jednej z kolumn tabeli posiadającej ponad 90 mln rekordów:

SELECT SUM (WTGBTR) FROM COEP

  • czas wykonania na systemie z klasyczną bazą danych: 395 656 ms,
  • czas wykonania na systemie z bazą HANA: 78 ms.

Wzrost wydajności o około 5000 razy!

Wyniki, które otrzymaliśmy, przekonały nas, że przetwarzanie w pamięci oraz inne mechanizmy zaimplementowane w SAP HANA, takie jak składowanie danych kolumnowo, pozwalają osiągnąć przyspieszenie, które w klasycznej bazie danych opartej na dyskach byłoby nieosiągalne lub niewyobrażalnie drogie.