Konsolidacja baz danych – moda czy konieczność?

Konsolidacja baz danych – moda czy konieczność?

XIV Konferencja PLOUG
Szczyrk
Październik 2008
Konsolidacja baz danych – moda
czy konieczność?
Agnieszka Czuchryta
Telekomunikacja Polska S.A.
e-mail: [email protected]
Abstrakt. Współcześnie wymagane jest od informatyków nie tylko administrowanie wysokodostępnymi systemami informatycznymi,
ale również obniżanie kosztów utrzymania infrastruktury. „Wirtualizacja”, „Ekologiczna informatyka” - to wiodąca dzisiaj tematyka
konferencji informatycznych i specjalistycznych artykułów.
W referacie zostaje podjęta dyskusja na temat nie tyle, czy warto i dlaczego, ale przede wszystkim w jaki sposób konsolidować środowiska informatyczne. Czy konsolidacja ułatwia, czy utrudnia administrowanie bazami danych? Czy łatwo jest taką operację przeprowadzić? Swoimi doświadczeniami w tej dziedzinie dzielą się specjaliści baz danych z Telekomunikacji Polskiej S.A.
Informacja o autorze. Autorka referatu pracuje na stanowisku Głównego Administratora w Telekomunikacji Polskiej S.A.
Konsolidacja baz danych – moda czy konieczność?
101
1. Projekt C17
W Grupie France Telekom wśród wielu realizowanych projektów w 2007 roku rozpoczęto
przedsięwzięcie konsolidacji infrastruktury. Program obejmuje również Telekomunikację Polską
S.A. Podejście do zagadnienia konsolidacji infrastruktury jest w omawianym przeze mnie przypadku kompleksowe i zgodne z zasadami sztuki prowadzenia zmian informatycznych. Programowi nadano krótką nazwę C17 i tak też jest on nazywany w tej prezentacji.
W programie C17 jasno zdefiniowano cele biznesowe:
– zmniejszenie kosztów hostingu i utrzymania infrastruktury
– zmniejszenie kosztów zakupu i utrzymania wykorzystywanych licencji
oprogramowania
Wskazano metody, dzięki którym wyznaczone cele będą osiągnięte. Są to:
– konsolidacja
– partycjonowanie
– wirtualizacja
– standaryzacja (hardwaru, narzędzi i procesów)
– racjonalizacja (wdrażania, utrzymania i procesów)
Wytypowano obszary infrastruktury które mają być objęte działaniami w ramach C17. Obszary
te to:
– storage,
– serwery z systemem operacyjnym AIX,
– serwery z systemem operacyjnym Solaris,
– serwery z systemem operacyjnym HP-UX,
– x86 VMware,
– obszar baz danych.
W ramach projektu, przygotowano PRZYDATNE ! dokumenty, opisujące ogólne zasady działań w projekcie jak i szczegółowe rozwiązania np. jak migrować bazę Oracle 10.2.0.4 z Solaris na
AIX.
2. Wirtualizacja
Termin wirtualizacja jest modny, ale często używany nie precyzyjnie. Pod pojęciem wirtualizacji kryje się wiele rozwiązań działających na różnym poziomie abstrakcji i różnym sposobie separacji. Środowiska wirtualne charakteryzuje „separacja” między sobą oraz „współdzielenie” sprzętu. Dla sprecyzowania pojęć przyjmuję następujące wyjaśnione poniżej nazewnictwo.
Na dużych serwerach Unix wirtualizacja kryje się pod pojęciem partycjonowania. Partycja to
część dużego serwera UNIXowego (Solaris, AIX, HP-UX) która ma swój adres IP, swój system
operacyjny, swój przydział mocy i pamięci oraz dedykowaną dla siebie sieć. Partycja jest serwe-
102
Agnieszka Czuchryta
rem logicznym. Na serwerach SUN takie rozwiązania to kontenery czy inaczej zony. Na serwerach
AIX partycje to LPARy. Na serwerach HP: NPARy i VPARy.
Odseparowane od siebie serwery logiczne z charakteryzującymi je: IP, pamięć, sieć, CPU,
utworzone na innych niż UNIX systemach operacyjnych (Windows, Linux) to rozwiązania wirtualne typu VMware czy Linux VServer.
Z punktu widzenia informatyka, można powiedzieć, że administrator zajmuje się zwirtualizowanym środowiskiem informatycznym gdy na dużych serwerach ma wyodrębnione serwery logiczne.
Patrząc z biznesowego poziomu na infrastrukturę można powiedzieć, że firma ma zwirtualizowaną infrastrukturę informatyczną gdy formą rozliczenia się działu IT z biznesem jest nie koszt
serwera, sieci, energii czy też licencji tylko udostępniona z uzgodnioną dostępnością funkcjonalność systemu informatycznego. Dobrym przykładem takiej definicji jest hosting domen internetowych. Właściciel domeny absolutnie nie musi wiedzieć na jakim systemie operacyjnym pracuje
jego aplikacja i w jakiej bazie danych są jego dane.
3. Konsolidacja a migracja
Konsolidacją jest taka zmiana dla bazy danych, która nie pociąga za sobą ani zmiany systemu
operacyjnego ani wersji serwera bazy danych.
Migracja natomiast to takie działanie, w którym dla bazy danych zmieniana jest albo wersja
serwera Oracle, albo platforma na której serwer bazy danych pracuje np. z Windows na Solaris,
albo następują obie te zmiany jednocześnie.
Z naszego doświadczenia więcej jest przypadków migracji baz niż konsolidacji. Przy okazji
zmiany platformy podnosimy również wersje Oracle z 9i a nawet 8i do 10g.
4. Teoria Modeli
Dla administratorów baz danych Oracle zbudowano teorię modeli konsolidacji i migracji baz
danych. Poniższe przykłady dotyczą tylko rozwiązań nieklastrowych.
4.1. Model 0
Model 0 to taka architektura systemu w której mamy: 1 serwer fizyczny, na nim 1 system operacyjny, na nim zainstalowany 1 serwer Oracle (1 binaria = 1 ORACLE_HOME ). Utworzona jest
tam 1 baza danych, jest 1 instancja i 1 schemat. Należy tutaj wyjaśnić, że 1 schemat jest rozumiany jako 1 główny schemat aplikacyjny.
Konsolidacja baz danych – moda czy konieczność?
103
Rys. 1.Schemat serwerów i baz danych w modelu 0
4.2. Model 1
Model 1 to taka architektura systemu w której mamy: 1 serwer fizyczny, na nim 1 system operacyjny, na nim zainstalowany wiele serwerów Oracle (wiele różnych binarii = wiele ORACLE_HOME), pracuje wiele baz danych ale zawsze 1 dla 1 ORACLE_HOME, jest wiele instancji
i oczywiście wiele schematów.
Rys. 2 .Schemat serwerów i baz danych w modelu 1
4.3. Model 2
Model 2 to taka architektura systemu w której mamy: 1 serwer fizyczny, na nim 1 system operacyjny, na nim zainstalowany 1 serwer Oracle (1 binaria = 1ORACLE_HOME ), pracuje wiele
baz danych, jest wiele instancji i oczywiście wiele schematów.
104
Agnieszka Czuchryta
Rys. 3. Schemat serwerów i baz danych w modelu 2
4.4. Model 3
Model 3 to taka architektura systemu w której mamy: 1 serwer fizyczny, na nim 1 system operacyjny, na nim zainstalowany 1 serwer Oracle (1 binaria = 1ORACLE_HOME ), jest 1 baza danych, jest 1 instancja i w bazie wiele schematów.
Rys. 4. Schemat serwerów i baz danych w modelu 3
4.5. Model 4
Model 4 jest dopełnieniem tej klasyfikacji. Model 4 to taka architektura systemu w której mamy: 1 serwer fizyczny, na nim 1 system operacyjny, na nim zainstalowany 1 serwer Oracle, jest 1
baza danych, jest 1 instancja i 1 schemat. Model 4 jest architekturą czysto teoretyczną nie stosowaną w praktyce.
105
Konsolidacja baz danych – moda czy konieczność?
Rys. 5. Schemat serwerów i baz danych w modelu 4
Podsumowując zdefiniowane modele otrzymujemy następujące architektury:
Tabela 1. Charakterystyka modeli
Model 0
serwer fiziczny
system operacyjny
ORACLE_HOME
Baza
instancja
schemat =aplikacja
1
1
1
1
1
1
Model 1
Model 2
Model 3
1
1
wiele
wiele
wiele
wiele
1
1
1
wiele
wiele
wiele
1
1
1
1
1
wiele
Model 4
1
1
1
1
1
1
Czy są to już wszystkie przypadki? Okaże się niebawem.
Wiele z istniejących już w naszej firmie rozwiązań infrastruktury bazodanowej odpowiadało
któremuś z powyższych modeli lub w bardziej złożonych przypadkach było ich kombinacją np.
jedna z większych baz TP to 25 TB baza Oracle na 1 serwerze (model 0). Z pewnością nie podlegająca procesowi migracji. Omawiane przeze mnie na zeszłorocznej konferencji PLOUG rozwiązanie to serwery z wydzielonymi partycjami – model 0.5 . Dlaczego nie model 1? Gdyż w takiej
architekturze każda partycja posiada swój osobny system operacyjny. Ponadto na każdej partycji
jest zainstalowany jeden serwer Oracle który „obsługuje” 2 lub 3 bazy (model 2). Na dodatek jest
to rozwiązanie klastrowe -RAC. Dla innego systemu mamy infrastrukturę w modelu 2 na serwerach w klastrze active – passive z oprogramowaniem Application Rollover Facility. Na jednym
serwerze, w jednym ORACLE_HOME, mamy w najliczniejszym przypadku 16 baz.
5. Ograniczenia i wymagania modeli
Decydując się na migrację baz do modelu 0,1,2 lub 3 należy rozważyć konsekwencje jakie niesie taka zmiana w kontekście bezpieczeństwa danych jak i codziennych czynności administratorskich. Należy zastanowić się jaki wpływ ma każda z architektur na systemy informatyczne przy
awarii hardwaru lub patchowaniu softwaru . Być może po migracji lub konsolidacji będą musiały
ulec zmianie scenariusze backupu i odtwarzania. Bardzo ważnym elementem staje się zarządzanie
106
Agnieszka Czuchryta
mocą i pamięcią serwera zarówno fizycznego jak i logicznego. Niezbędna staje się głęboka znajomość narzędzi do zarządzania workload: SO Resource Manager i Data Base Resource Manager.
W przypadku wszystkich modeli od 0 do 3 restart serwera fizycznego wymaga zamknięcia
wszystkich instancji baz danych na nim pracujących. Zaaplikowanie patch’y na system operacyjny
wymaga również w modelach od 0 do 3 zamknięcia wszystkich instancji. Wyjątek stanowi model
0.5 (LPARy na AIX). W tym przypadku patchowanie systemu operacyjnego może być niezależne
dla każdej partycji.
Sytuacja jest bardziej różnorodna w przypadku upgrade serwera Oracle lub wgrywania one-off
patch na serwery Oracle. W modelu 1 zmiana na serwerze Oracle ma swój impakt tylko dla bazy
pracującej na tym serwerze.
W przypadku, gdy na jednym serwerze logicznym pracuje wiele instancji ważne jest właściwe
zarządzanie przydzielaną im mocą i pamięcią. Z pewnością posłużą do tego narzędzia Workload
Manager. Jednocześnie w każdej bazie możemy mieć skonfigurowanego Resource Managera.
Należy być bardzo ostrożnym w stosowaniu obu tych narzędzi jednocześnie tym bardziej, że według sugestii supportu Oracle nie należy ich używać równocześnie.
Problem nie jest banalny. Poniżej cytuję w oryginale stanowisko Oracle. Cytat pochodzi z dokumentacji „20080625_ORCL_FT_Workshop_v1.0”
OS Resource Manager Vs Database Resource Manager
• OS Resource Manager should not be used with the Database Resource Manager because neither of them are aware of each other's existence
– Database Resource Manager – distribute resource with database
– OS Resource Manager – distribute resource with multiple instance
• Use OS Resource Manager
– Each instance should be assigned to OS resource group.
– All instance process run at one priority and no process priority
• Guidelines for using OS Resource Control
• If you want to control resource distribution within an instance,
use the Resource Manager and turn off OS resource control.
• If you have multiple instances on a node and you want to distribute resources among them,
use OS resource control, not the Resource Manager
Note: Oracle Database currently does not support the use of
both tools simultaneously.
If you decide to use an OS resource manager concurrently with Oracle Database Resource
Manager, you must ensure that all of the following conditions are met:
– Each database instance must be assigned to a dedicated operating-system resource manager
group or managed entity.
– The dedicated entity running all the instance's processes must run at one priority (or resource consumption) level
– The CPU resources assigned to the dedicated entity cannot be changed more frequently than
once every few minutes.
– Process priority management must not be enabled.
Konsolidacja baz danych – moda czy konieczność?
107
If resource management decisions are made by operating system, it can lead to problems such as:
– Excessive overhead resulting from operating system context switching of Oracle database
server processes when the number of server processes is high
– Suspension of a database server processes that is holding a latch
– Unequal distribution of resources among all Oracle database processes, and an inability to
prioritize one task over another
– Inability to manage database-specific resources, such as parallel
execution servers and active sessions”.
Koniec cytatu.
Równie ciekawym i złożonym tematem jak zarządzanie mocą i pamięcią serwera jest organizacja backupu i odtwarzania baz (schematów) w modelach od 1 do 3. Wydaje się, że model 3 oprócz
backupu technikami kopii macierzowych czy też RMANem z pewnością wymaga wykonywania
dumpów poszczególnych schematów.
O wymienionych wyżej elementach codziennej pracy administratorów myśleć należy już na
początku decyzji o migracji (konsolidacji) bazy danych do danego modelu. Pamiętajmy, że budujemy dla naszego klienta biznesowego środowisko bezpieczne i odseparowane. Nie może być
mowy o tym, aby odtworzenie jednej bazy wymuszało cofnięcie w czasie innego niezależnego
systemu.
6. Infrastruktura na początku procesu
W tak dużej firmie jak Telekomunikacja Polska, firmie z długoletnim doświadczeniem informatycznym, infrastruktura systemów informatycznych jest różnorodna: są bardzo nowoczesne
rozwiązania klastrowe, ale i stosunkowo niewielkie środowiska. Przy czym nie jest regułą, że małe
serwery większych pełnia mniejsza rolę niż duże środowiska. Pod względem „wieku” infrastruktura jest młoda, ale jest i taka, która wymaga wymiany. Sposób budowania systemów informatycznych w przeszłości był taki, że poszczególne system informatyczne miały swój serwer i swoje
bazy. Takie podejście, jak się okazało w czasie realizacji projektu C17, poskutkowało problemami
przy konsolidacji serwerów i migracji baz danych. Często największym problemem okazuje się nie
problem techniczny – lecz problem psychologiczny związany z uzyskanie zgody na zmianę infrastruktury . Właściciele biznesowi patrząc jedynie przez pryzmat realizacji swych usług nie dostrzegają faktu, że zmiany winno się przeprowadzać wówczas gdy kryzys dotyczący dostarczenie
usługi jeszcze nie nastąpił, nie chcąc prowokować ewentualnych problemów wolą pozostać przy
posiadanych rozwiązaniach często kosztem pewnych kompromisów w sferze funkcjonalności czy
wydajności. Wydłuża to proces uzgodnień i w efekcie wydłuża realizację projektu.
7. Zadania administratorów
Na potrzeby projektu, w natłoku zwykłych prac administratorskich ( kreowanie baz, odtwarzanie, strojenie, itp. ), administratorzy Oracle musieli znaleźć czas na:
– zdefiniowanie standardów implementacji Oracle dla systemów informatycznych,
– zbudowanie „wymarzonej” infrastruktury,
– przedstawienie swojego pomysłu właścicielom biznesowym istniejących systemów,
– namówienie ich na zmianę z udowodnieniem korzyści jakie osiągną,
– zbudowanie środowisk testowych i przeprowadzenie testów.
108
Agnieszka Czuchryta
Marzenia o modelu 3, o tym, że można mieć jeden duży serwer fizyczny, jeden serwer Oracla,
jedną bazę i z nowymi projektami (aplikacjami) będzie się uzgadniało tylko, aby ich aplikacyjni
użytkownicy (schematy) byli różni między sobą, okazały się nieprzystające do możliwości realizacji w tak rozbudowanej infrastrukturze baz danych jaką zajmujemy się w TP. Czy rozwiązanie
w modelu 3 jest realne w przypadku systemów produkcyjnych? Z pewnością jest to wyzwanie.
8. Wybór rozwiązań dla procesu migracji i konsolidacji
W ramach prac C17 zdecydowano się na budowę m.in. następujących środowisk, które będą
stanowiły przyszłą zestandaryzowaną podstawę infrastrukturalną dla baz danych Oracle migrowanych i nowo tworzonych.
8.1. Środowisko Solaris zone
Dwa serwery fizyczne Sun Fire E25K. Na każdym 16 GB pamięci i 4 procesory. Na każdej zonie lokalnej zainstalowany serwer baz danych Oracle EE 10.2.0.4. Zasoby klastrowe Oracle active
– passive. Środowisko zgodne z modelem 1. Mozliwość rozbudowy pionowej przez zwiększanie
ilości procesorów.
Rys. 6. Schemat środowiska opartego o zony
Konsolidacja baz danych – moda czy konieczność?
109
8.2. Środowisko Grid Computing
Jest ono zgodne z modelem 2. Składa się z 4 serwerów serwery IBM x3950. SO Linux Redhat.
Serwer Oracle to EE 10.2.0.4 RAC. Mozliwość rozbudowy poziomej. W najbliższym czasie planowana jest rozbudowa o kolejne 2 serwery.
Rys. 7. Schemat środowiska opartego o Oracle Grid Computing
9. Realizacja procesu migracji
W procesie konsolidacji i migracji baz danych dość łatwo jest wybrać nową infrastrukturę, wytypować bazy do migracji. Łatwo jest przygotować środowisko testowe i przeprowadzić testy.
Udaje się również z właścicielem biznesowym systemu ustalić termin migracji produkcyjnej. Te
etapy przygotowań trwają, z naszego doświadczenia, od 6 do 12 miesięcy. Natomiast o wiele trud-
110
Agnieszka Czuchryta
niej jest doprowadzić do zamknięcia systemu na starej infrastrukturze. Często coś stoi na przeszkodzie: release, stabilizacja po nim, nowy release.
W praktyce okazało się, że całkiem inne problemy pojawiają się w przypadku konsolidacji/migracji baz danych, a inne w przypadku definiowania standardów infrastruktury baz danych
dla przyszłych systemów. Migracje baz danych wiążą się ściśle z testami aplikacji. Od możliwości
wykonania zmian w aplikacji zależy „prawie wszystko”. Standaryzacja jest znacznie prostsza:
wystarczy wybrać najbardziej odpowiadającą wymaganiom infrastrukturę (stabilną, bezpieczną,
nowoczesną, elastyczną), zbudować ją i udostępnić nowym projektom.
W nowych grupach projektowych obserwuje się większe zainteresowanie architekturą Grid
Computing niż przygotowanymi przez nas również dla nowych systemów partycjami Unix. Znajduje zrozumienie nasza argumentacja, że architektura Grid Computing ma duży potencjał rozwoju
i jest stosunkowo tania w rozbudowie poziomej. Wydaje się, że rozwiązanie to może w znacznym
stopniu przyczynić się do unowocześnienia infrastruktury informatycznej w TP S.A.
10. Podsumowanie
Z technicznego punktu widzenia w wyniku realizacji prac w ramach programu C17 uzyskaliśmy:
– nową, „młodą” infrastrukturę informatyczną,
– nowoczesny i elastyczny system administrowania infrastrukturą,
– zagwarantowaną wysoką dostępność danych (klastry dużych maszyn).
Projekt C17 dostarczył firmie taką infrastrukturę informatyczną, która znacząco zmniejsza czas
wdrożenia nowych funkcjonalności biznesowych, zwiększa bezpieczeństwo i dostępność danych
oraz poprawia poziom świadczonych przez IT usług. Pojawiają się oczywiście nowe wyzwania
związane z zarządzaniem tak skomplikowanymi środowiskami i ich tuningiem.
Podsumowując dla biznesu mamy przygotowane urozmaicone, ale stabilne rozwiązania, gotowe do uruchomienia nowych procesów . Dla siebie mamy zagwarantowany komfort pracy administratorskiej.