Wirtualizując środowisko IT, otrzymujemy między innymi takie korzyści jak jego konsolidacja, skalowalność, wysoka dostępność. Jednak aby te cechy uzyskać, trzeba zwrócić szczególną uwagę na najważniejsze elementy infrastruktury. Przede wszystkim w każdym aspekcie należy wystrzegać się pojedynczych punktów awarii. Wraz ze wzrostem gęstości wirtualnych maszyn na serwerze ewentualne uszkodzenie (pojedynczego elementu, całego serwera lub innego urządzenia) naraża nas na efekt domina i niedostępność wielu systemów.

Łańcuch zależności jest bardzo długi i spełnienie wszelkich wymogów jest obarczone zaporowym kosztem. Te wydatki są w barierą szczególnie dla firm z sektora małych i średnich przedsiębiorstw, jednak nie oznacza to, by miały one rezygnować z dążenia do wydajnej i zoptymalizowanej kosztowo infrastruktury. Wirtualizacja środowiska SAP jest jednym ze sposobów optymalizacji kosztów utrzymania infrastruktury IT w firmie.

Migracja sprzętowa dobrym pretekstem do wirtualizacji

Skala środowiska SAP jest zwykle odbiciem wielkości i złożoności przedsiębiorstwa. Jednak bez względu na wielkość, oczekiwania użytkowników są podobne: wszyscy życzyliby sobie, by czynności i zadania były wykonywane optymalnie i szybko. Wprowadzanie danych zakupowych, przygotowywanie wydań magazynowych, tworzenie raportów sprzedaży itp. – użytkownicy oczekują, że te czynności zostaną wykonane niemal natychmiast. Ale wydajność systemów nie idzie w parze z upływającym czasem i rozrostem baz danych.

Na tym samym sprzęcie fizycznym wydajność, przy uwzględnieniu przyrostu danych, niemalże z definicji musi się pogarszać. I choć oczywiście w wielu przypadkach możliwe są optymalizacje kosztownych zapytań poprzez poprawki deweloperskie lub utworzenie indeksów, to jednak w wielu przypadkach jedynym rozwiązaniem poprawiającym sytuację jest migracja na nowe zasoby sprzętowe. Gdy stajemy przed taką potrzebą, warto wykorzystać ten moment, by migrację sprzętową zakończyć wirtualizacją.

Niewątpliwie zaletą wirtualizacji jest skalowalność. Jeszcze kilka-kilkanaście lat temu pamięć operacyjna była tak droga, że z oszczędności optymalizację buforów wykonywano z dokładnością co do kilobajta. Nadal wiele wartości historycznie konfiguruje się w tych jednostkach, a nawet w pojedynczych bajtach. Niemniej trudno dziś wyobrazić sobie serwery fizyczne z 1 GB czy 4 GB pamięci operacyjnej. Popularne smartfony charakteryzują się podobnymi parametrami. Serwery fizyczne z 256 GB czy 512 GB pamięci operacyjnej nie należą obecnie do wyjątków. Podobnie zastosowanie w procesorach dodatkowych instrukcji czy wielu rdzeni spowodowało wielokrotny wzrost ich wydajności.

W tej sytuacji przy odpowiednim przygotowaniu firmowej infrastruktury z powodzeniem możemy uruchomić – z wykorzystaniem wirtualizacji – systemy SAP przetwarzające kilka, kilkanaście czy kilkaset tysięcy kroków dialogowych, jak również takie, które przetwarzają np. 1,5 mln kroków dialogowych dziennie. W przypadku niewielkich systemów nic nie stoi na przeszkodzie, by uruchomić ich kilka, kilkanaście na jednym mocnym serwerze. Z kolei dla największych systemów możemy przeznaczyć na ten cel kilka serwerów (jeden dla instancji DB, kilka dla instancji centralnej i dialogowych).

Jednocześnie w przypadku zgodności procesorowej migracja między nowymi serwerami fizycznymi może nastąpić bez wyłączenia, a w przypadku nowocześniejszego procesora (wyłączone EVC) może nastąpić poprzez opcję wyłącz i włącz (przerwa kilkuminutowa).

Kilka przydatnych wskazówek

W serwerach zaleca się wykorzystywanie procesorów najnowszej generacji ze względu na ich wsparcie dla wirtualizacji (m.in. Extended Page Tables EPT – intel, Rapid Virtualization Indexing RVI – AMD). W przypadku procesorów z opcją HT (hyperthreading) należy rozważyć jej wyłączenie na serwerze. Przy włączonej opcji HT może się zdarzyć, że jeden z wirtualnych procesorów bardzo wymagającego systemu „utknie” w wątku HT. Jeśli to nastąpi, dla takiej wirtualnej maszyny należy w opcji „Hyperthreaded Core Sharing” wybrać „none”. Dodatkowo z poziomu BIOS zaleca się wyłączenie zarządzania energią lub przełączenie w opcję „OS controlled”.

W wirtualnych maszynach wymagana jest instalacja sterowników i narzędzi VMware Tools. Przy planowaniu zasobów vCPU i RAM dla maszyn produktywnych należy mieć na uwadze, by nie przekraczać zasobów fizycznych. Dla dużej maszyny zaleca się przypisywanie ilości pamięci operacyjnej w ramach węzła NUMA, po przekroczeniu ilości zaleca się wykorzystanie opcji vNUMA.

O ile przekroczenie wirtualnych procesorów do fizycznych rdzeni jest możliwe, to dla systemów produktywnych o dużej utylizacji będzie to skutkowało znacznym pogorszeniem wydajności. Dojdzie bowiem do rywalizacji pomiędzy konkurującymi o zasoby fizyczne wirtualnymi maszynami.

W odniesieniu do wydajności należy pamiętać również, a może przede wszystkim, o znaczeniu zasobów macierzowych. Skala wielu systemów wzrastała od 100 GB poprzez 500 GB do ponad 1 TB, a nawet kilkunastu TB w przypadku bardzo rozbudowanych i wiele przetwarzających systemów. Postęp i w tej dziedzinie jest olbrzymi, jednak z punktu widzenia wydajności jest to działka wymagająca szczególnej staranności przy projektowaniu i wdrażaniu architektury. O ile niestosowanie zaleceń w tym obszarze dla małych systemów, o małej utylizacji może nie przynieść zauważalnych dla użytkownika opóźnień, o tyle może skutkować dużymi problemami z wydajnością systemów dużych, o bardzo dużej utylizacji.

Zaleca się stosowanie kontrolerów PVSCSI (Paravirtual SCSI Controller) dla maszyn wirtualnych wykorzystywanych dla systemów SAP. Dodatkowo korzystne jest rozdzielenie dyskowe i kontrolerowe danych os/swap z bazą danych i plikami logów transakcyjnych. Podział ten zwiększy możliwości kolejkowania I/O do dodatkowych dysków i kontrolerów w ramach systemu operacyjnego. Do dyspozycji mamy cztery kontrolery, dlatego optymalne wydaje się wykorzystanie jednego dla os/swap, drugiego dla logów transakcyjnych, a trzeciego i czwartego dla bazy danych.

W warstwie sieciowej zalecane jest wykorzystywanie karty sieciowej vmxnet3 dla wirtualnych maszyn. W przypadku hosta należy zwrócić uwagę, by był on podłączony do przełączników redundantnie.

W systemach o bardzo dużym ruchu zaleca się przełączenie wirtualnej maszyny w opcjach „Latency Sensitivity” z domyślnego „Normal” na „High”. Wyłączy to między innymi wspomnianą wcześniej rywalizację vCPU z wątkiem pCPU. Dodatkowo włączy rezerwację dla pamięci operacyjnej. Wyłączy przerwania koalescencyjne i LRO (Large Receive Offload) dla vmxnet3.

Zastosowanie powyższych zaleceń przybliża nas do optymalnego przygotowania wirtualnych maszyn dla środowiska SAP. A co, jeśli wykonaliśmy powyższe czynności, a wydajność nie jest wystarczająca?

W takich przypadkach, a nie są one odosobnione, pozostaje analiza wydajnościowa działającego środowiska. Z pomocą przychodzą takie narzędzia jak esxtop uruchamiany z poziomu serwera fizycznego i Perfomance Monitor, uruchamiany przez vSphere klienta (lub jego odmianę webową), a odwołujący się do vCenter w danym środowisku. I choć celem tego artykułu nie jest opisanie wszystkich liczników, jest ich bowiem bardzo wiele, to warto zwrócić uwagę na kilka istotnych, które dotykają źródeł problemów.

Liczniki, odczyty, zapisy

Wcześniej wskazywaliśmy możliwą rywalizację wirtualnych maszyn o zasoby procesorowe jako potencjalną przyczynę pogorszenia wydajności. Licznikiem, który pomoże w wykryciu lub potwierdzeniu takiej sytuacji, jest „Ready” dla CPU. On to właśnie określa czas lub procentowy udział, jaki vCPU (procesor przypisany wirtualnej maszynie) oczekiwał na przydzielenie do fizycznego procesora (jednego z fizycznych rdzeni). Im wyższa wartość, tym sytuacja jest poważniejsza, to znaczy rywalizacja jest większa.

Możliwości migracji wirtualnych maszyn w ramach infrastruktury w trybie włączonym przez mechanizm vMotion umożliwiają nam balansowanie obciążeniem. W zależności od konfiguracji, system może sam podpowiadać optymalne rozłożenie maszyn wirtualnych lub nawet wykonywać migracje z zachowaniem wcześniej określonych reguł. Należy jednak zachować rozwagę przy tworzeniu scenariuszy. Wraz z rozrostem systemów i wzrostem liczby przetwarzanych danych „apetyt” na zasoby może wzrosnąć w takim stopniu, że jedyną drogą jest rozbudowa środowiska.

W przypadku pamięci operacyjnej serwera fizycznego wykorzystanie pamięci swap niesie ze sobą bardzo dużą degradację wydajności, a wiąże się to z czasem dostępu, odczytem i zapisem do pamięci operacyjnej i do pamięci na datastorze (nawet SSD). Porównując np. odczyt sekwencyjny 1 MB z SSD i pamięci, zauważymy, że jest on około czterokrotnie dłuższy (źródło: https://gist.github.com/hellerbarde/2843375). Tego typu operacje przepisywania pamięci i ponownego jej czytania dodatkowo konsumują zasoby sprzętowe, dlatego należy nie doprowadzać do powyższego.

Skoro jesteśmy przy odczytach i zapisach, to zwróćmy również uwagę na – szczególnie istotną – część macierzową. Wszelkie dane wymagane przez program muszą zostać odczytane, a nowo wprowadzone muszą zostać zapisane. Niby nic odkrywczego, ale warto przypomnieć w tym miejscu, że źle napisane programy unieruchomią najbardziej rozbudowane systemy oparte na niemal nieograniczonych zasobach. Zaś te napisane optymalnie w dużej mierze zależą od czasów opóźnienia przy odczycie i zapisie danych na dysku. Dlatego analiza mierników opóźnień odczytu/zapisu na datastorze (Read/Write latency) jest często pomocna przy rozwiązywaniu problemów wydajnościowych.

Skalowalność, wysoka dostępność

Wieloletnie doświadczenia firmy BCC (aktualnie All for One Poland) w wirtualizacji zasobów potwierdzają znaczne korzyści dla firm płynące z tego rozwiązania, przede wszystkim ze względu na skalowalność i wysoką dostępność systemów. Różnorodność systemów, zwiększanie się zasobów przetwarzanych przez nie danych i oczekiwania użytkowników zawsze będą wyzwaniem do doskonalenia technik monitorowania i poprawiania wydajności.

Konsolidacja i wirtualizacja środowisk IT

BCC oferuje projekty migracji heterogenicznych środowisk IT do skonsolidowanego, zunifikowanego środowiska wirtualnego. Korzyści dla klientów to m.in.:

  • zmniejszenie ilości wymaganego sprzętu,
  • uproszczenie architektury,
  • możliwość zarządzania architekturą z pojedynczego punktu,
  • możliwość uzyskania wysokiej dostępności dla całości architektury.

W efekcie konsolidacja i wirtualizacja środowisk IT przekłada się na zmniejszenie kosztów utrzymania i rozwoju IT w firmie, a także na znaczne ułatwienia w codziennej administracji oraz rozwoju infrastruktury IT.
BCC realizuje projekty związane z konsolidacją i wirtualizacją środowisk IT w oparciu o rozwiązania wiodących światowych dostawców, m.in. VMware, Microsoft (Hyper-V). W projektach dla klientów wykorzystujemy również kompetencje i wieloletnie doświadczenia z wykorzystywania wirtualizacji zarówno na własne potrzeby, jak i na potrzeby systemów naszych klientów, które są hostowane w All for One Data Centers.