Oracle wewnątrz VMware

Wirtualizacja bazy danych Oracle, chociaż technicznie była możliwa od dawna, napotykała na problemy związane ze wsparciem technicznym. Obecnie problemy te można łatwo rozwiązać.

Oracle jest najbardziej skomplikowanym pakietem narzędzi powszechnego użycia w firmach. To kosztowna baza danych, ale stanowi istotny standard biznesowy. Dotychczas wirtualizacja baz Oracle za pomocą VMware była kłopotliwa, gdyż polityka serwisowa Oracle mogła nakazywać odtworzenie błędu w instalacji bezpośrednio na sprzęcie. Firma VMware podjęła decyzję o wprowadzeniu wsparcia technicznego dla wirtualizowanych baz Oracle - obecnie w przypadku zgłoszenia serwisowego może realizować wsparcie w imieniu klienta, jeśli zajdzie taka potrzeba.

Mniej kosztownych licencji

Wirtualizacja kosztownej bazy Oracle staje się sensowną perspektywą, która prowadzi do dużych oszczędności. Koszty licencji Oracle mogą stanowić 80% kosztów sprzętu, na którym baza pracuje. Należy zatem zmniejszyć koszt per transakcja. Baza Oracle jest licencjonowana per rdzeń, przy czym przy wirtualizacji niezbędne jest posiadanie licencji na wszystkie procesory w klastrze VMware. Zatem należy oddzielić fizycznie klaster VMware dla bazy Oracle.

Zobacz również:

  • 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT

Konsolidacja obciążeń

Aby dobrze wykorzystać posiadane licencje Oracle, należy użyć narzędzi, które wychwycą obciążenia, aby można je było połączyć. Dotyczy to zadań, w których szczyty obciążenia się nie pokrywają, takich jak praca wsadowa i obsługa transakcji. W typowej infrastrukturze korporacyjnej możliwe jest dwukrotnie większe obciążenie infrastruktury przy mniejszej liczbie węzłów Oracle RAC. W niekrytycznych zastosowaniach można nawet zrezygnować z RAC na rzecz pojedynczych instancji w klastrze VMware. Wiąże się to nie tylko z niższym kosztem licencji, ale także z lepszą wydajnością, gdyż RAC narzut (w praktyce do około 20%), a narzut związany z wirtualizacją VMware vSphere 5 nie przekracza 4%. Jeśli osiągnie się kompresję 2:1 (co pokazuje przykład wdrożenia w EMC), oszczędności sięgają połowy kosztów licencji Oracle, przy którym to koszcie wydatek na infrastrukturę VMware jest mniejszy o ponad rząd wielkości. W dużym data center można liczyć na oszczędności liczone w setkach tysięcy USD rocznie.

Przyspieszyć pracę bazy

W pierwszej kolejności należy sprawdzić, czy włączony jest tryb hyper threading. Kolejnym ustawieniem są duże strony (huge pages), które od dawna były zalecane w dużych instalacjach. W środowisku wirtualizowanym przynoszą jeszcze lepsze efekty, gdyż zwiększają prawdopodobieństwo trafień indeksu b-drzewa w pamięci, a zatem przyspieszają pracę. Po prawidłowym uruchomieniu huge pages wzrost wydajności może osiągnąć nawet 25% w stosunku do nieoptymalizowanego Oracle RAC.

W praktyce podsystem wejścia/wyjścia jest silnie obciążony. Oznacza to, że przyspieszenie pracy storage’u umożliwi zmniejszenie liczby rdzeni niezbędnych do przetwarzania tych samych zadań. Użycie szybkich macierzy dyskowych z dobrą technologią cache jest kluczem do sukcesu.

Technologia podziału na bloki przenoszone zależnie od częstości ich przetwarzania (np. FAST VP firmy EMC) sprawia, że macierz samoczynnie będzie dobierać właściwe miejsce składowania danych. Dla porównania sztywny podział LUN do typu zasobów niesie ze sobą konieczność okresowego ich przenoszenia. Z kolei technologia EMC FAST Cache, tworząca zasoby pamięci podręcznej przed blokami zapisanymi na dyskach, umożliwia znaczące przyspieszenie transakcji. Należy jednak pamiętać, by dobrać właściwą akcelerację, zależnie od rodzaju obciążenia. FAST VP dobrze się sprawdza przy stałych obciążeniach, tymczasem do zmiennych obciążeń, takich jak różna praca nad tymi samymi danymi, lepiej sprawdzi się FAST Cache.

Wprowadzenie wszystkich powyższych opcji w modelowym wdrożeniu w EMC przyniosło co najmniej siedmiokrotny wzrost wydajności bazy.

Jak podłączyć dyski

Przy wirtualizacji możliwe są cztery scenariusze konfiguracji dysków dla Oracle. Pierwsza metoda zakłada użycie zasobów z sieci SAN z DEM LUN, zamontowanych bezpośrednio w VM, z których utworzono grupy w ASM Oracle; druga zakłada zamontowanie LUN w ESX, z których utworzono woluminy VMFS i dyski vmdk, z nich zaś tworzy się dyski ASM. Trzecia konfiguracja zakłada użycie DirectNFS i zamontowanie zasobów via NFS bezpośrednio w VM, z kolei czwarta zakłada zamontowanie zasobów NFS w ESX, by utworzyć vmdk i dyski dla ASM. Ostatnia konfiguracja nie jest przydatna w praktyce, gdyż jest mało sprawna.

Wersja pierwsza omija ESX, montując zasoby jako RDM, umożliwia koegzystencję w tym samym klastrze RAC infrastruktury wirtualizowanej i pracującej bezpośrednio na sprzęcie, ponadto narzut na wydajność storage jest najmniejszy. Niestety, wymaga to ustawienia w magistrali SCSI flagi shared, co z kolei wyłącza Vmotion.

Zamontowanie LUN w ESX i użycie dysków vmdk wymaga ustawień eager zero tick oraz shared write (KB 1034165), co wyłącza kopie migawkowe oraz thin provisioning. Nie można dodać maszyn fizycznych do klastra RAC ani bezpośrednio migrować do środowiska wirtualizowanego, ponadto nie wszystkie narzędzia integrujące się z Oracle działają (nie działa np. EMC Replication Manager czy RecoverPoint).

Najciekawszym modelem jest zamontowanie zasobów za pomocą NFS w systemie, a następnie użycie Oracle Direct NFS Client (dNFS) do zarządzania punktami montowania. Metoda ta omija całkowicie ESX, charakteryzuje się szerokim pasmem, bardzo dobrym zarządzaniem i obsługuje bardzo duże bazy danych. Jednocześnie w klastrze mogą pracować maszyny wirtualizowane i nie, ponadto w środowisku VMware działa Vmotion.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200