Konsolidacja baz danych moda czy konieczność?

Transkrypt

1 XIV Konferencja PLOUG Szczyrk Październik 2008 Konsolidacja baz danych moda czy konieczność? Agnieszka Czuchryta Telekomunikacja Polska S.A. 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.

2

3 Konsolidacja baz danych moda czy konieczność? 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 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-

4 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 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.

5 Konsolidacja baz danych moda czy konieczność? 103 Rys. 1.Schemat serwerów i baz danych w modelu 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 ORAC- LE_HOME), pracuje wiele baz danych ale zawsze 1 dla 1 ORACLE_HOME, jest wiele instancji i oczywiście wiele schematów Model 2 Rys. 2.Schemat serwerów i baz danych w modelu 1 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.

6 104 Agnieszka Czuchryta 4.4. Model 3 Rys. 3. Schemat serwerów i baz danych w modelu 2 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 Model 4 Rys. 4. Schemat serwerów i baz danych w modelu 3 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.

7 Konsolidacja baz danych moda czy konieczność? 105 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 Model 1 Model 2 Model 3 Model 4 serwer fiziczny system operacyjny ORACLE_HOME 1 wiele Baza 1 wiele wiele 1 1 instancja 1 wiele wiele 1 1 schemat =aplikacja 1 wiele wiele wiele 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

8 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 _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.

9 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.

10 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 Ś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 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

11 Konsolidacja baz danych moda czy konieczność? Ś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 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-

12 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.