Wysoka dostępność usług bibliotecznych prezentacja lokalnych rozwiązań BUW

1. Wysoka dostępność usług bibliotecznychprezentacja lokalnych rozwiązań BUW Andrzej Regmunt, Adam TwarowskiOddział Komputeryzacji IV Spotkanie PGU VTLS Biblioteka Uniwersytecka w Warszawie 15-16 czerwca 2011

2. O czym będziemy mówić • Środowisko standardowe • Co było? Co jest? Nowe wyzwania • Co to jest wirtualizacja i jej typy • Porównanie platform wirtualizacji • Nasz wybór • Możliwości Oracle VM • Architektura rozwiązania w BUW • DEMO Virtua serwer • Live Migration • High Availability

3. Trochę historii • 1998 – awaria dysku twardego w serwerze HP 3000 brak dostępu do systemu VTLS - 4 dni • 2001 – problemy z płyta główna serwera Sun Enterprise 450 brak dostępu do systemu VTLS - 2 dni • 2003 – uszkodzenie systemu plikowego, konieczność odtworzenia danych z backupu + odtworzenie „transaction log” brak dostępu do systemu VTLS - 3 dni • 2000-2010 – coroczna migracja do nowej wersji Virtua brak dostępu do systemu VTLS - 3-5 dni 98,904 – dostępność z migracją 97,534 – dostępnosć z migracją i kopią zapasową

4. Sytem informacyjno biblioteczny UW • 37 bibliotek wydziałowych kataloguje w Virtua • - w tym 15 bibliotek wydziałowych wypożycza w Virtua • Co najmniej 220 pracowników BUW i BW korzysta z Virtua w codziennej pracy • Ponad 120.000 czytelników bazie (3500 odwiedzin dziennie w BUW) • Ponad 179.000 dziennie żądań do serwera WWW z Chameleon’em • W sesji BUW czynny 22 godziny na dobę System biblioteczny MUSI DZIAŁAĆ – NON STOP

5. Próby poprawy sytuacji • Propozycje firmy VTLS mające na celu poprawę dostępności i skrócenie czasu awarii do minimum to • Hot swappable devices • RAID • Primary and secondary (standby) servers • Oracle Data Guard • RMAN • Tape and disk backup • SAN (DAS,NAS) • Orientacja na ochronę danych, a nie na dostępność usług

6. Środowisko standardowe • Najczęściej jedna aplikacja działa na jednym serwerze (maszynie) • Wykorzystanie serwerów jest tylko między 8% a 30% (Gartner) • Wada: podatność na awarie, pojedynczy punkt awarii • Zaleta: maksymalane wykorzystanie wydajności serwera

7. Środowisko wirtualizowane • Konsolidacja, wyższe wykorzystanie serwerów • Redundancja, zapewnienie Failover, HA oraz LB • Zmniejszone inwestycje w sprzęt (mniej serwerów) • Zmniejszenie kosztów administracyjnych i operacyjnych

8. Partycjonowanie sprzętowe • doskonała separacja logicznych partycji sprzętowych • dostępność wyłącznie na specjalizowanych platformach sprzętowych • podział poprzez podstawowe zasoby serwera (płyty procesorów, płyty pamięci, karty w gniazdach rozszerzeń) • dowolne dostępna dla danej platformy systemy operacyjne dla logicznych prartycji • np IBM DLPAR i WPAR, Sun LDOM/Oracle VM (SPARC)

9. Partycjonowanie programowe(wirtualizacja poziomu systemu operacyjnego) • umiarkowana separacja pomiędzy wirtualizowanymi obszarami • potencjalnie dość dobra skalowalność • podział poprzez najmniejsze zasoby systemu operacyjnego (procesory, pamięć, interfejsy) • brak możliwości mieszania systemów operacyjnych i ich wersji (np dla kontenerów) • np AIX WPARs, HP SRP, OpenVZ, Sun Solaris Container/Oracle VM (SPARC)

10. Wirtualizacja hypervisora - typ 1 • działa bezpośrednio na poziomie sprzętu (natywny, bare metal) • ma nad nim pełną kontrolę i monitoruje uruchomione systemy operacyjne • systemy operacyjne działają na poziomie wyżej niż hypervisor • bardzo dobra izolacja pomiędzy wirtualizowanymi maszynami • podział poprzez najmniejsze zasoby hypervisora (wirtualne procesory, pamięć, interfejsy oraz mapowane urządzenia blokowe) • dowolne dostępne dla danego hypervisora systemy operacyjne gościa • np VMware vSphere, Microsoft Hyper-V, Citrix XenServer, Oracle VM

11. Wirtualizacja aplikacyjna - typ 2 • działa jako program uruchomiony na danym systemie operacyjnym (hoście) • zwirtualizowane systemy działają dwa poziomy ponad sprzętem • podział poprzez najmniejsze zasoby wirtualizatora (emulowane procesory, pamięć czy interfejsy) • dedykowany dla rozwiązań desktopowych • np VMware Workstation, Microsoft Virtual PC, Oracle VirtualBox

12. Porównanie platform wirtualizacji

13. Architektura Oracle VM • Oracle VM Server • Open Source • Działający bezpośrednio na poziomie sprzętu • Wsparcie dla architektur x86(IA-32), x86_64 (AMD64) oraz IA-64 • Wymagania: procesor ze wsparciem Intel VT-x lub AMD-V dla wirtualizacji sprzętowej

14. Architektura Oracle VM • Oracle VM Manager • Interfejs do zarządzania z poziomu przeglądarki WWW • Własny serwer aplikacyjny (Oracle Containers) • Standardowe repozytorium (Oracle Express) • Wymagania: procesor x86 lub x86_64 min 1.83GHz *1, pamięć operacyjna min 2 GB

15. Architektura Oracle VM • Oracle VM Manager • Zarządzanie cyklem życia maszyn wirtualnych (LCM) • Tworzenie • Konfiguracja • Klonowanie • Współdzielenie • Uruchamianie • Migrowanie • Dostęp z poziomu przeglądarki WWW

16. Architektura Oracle VM – Role serwerów • Oracle VM Manager • Interfejs zarządzania (bazujący na WWW) • Przekazywanie poleceń do wykonania (agent) • Prezentacja rezultatów (logi) • Oracle VM Server • Fizyczny serwer należy do puli serwerów • Od jednej do trzech ról • Uruchomiony Oracle VM Agent

17. Architektura Oracle VM – Role serwerów • Server Pool Master • ●Dokładnie jeden w puli (wymagany) • ●Kontakt ze światem zewnętrznym/Dyspozytor w puli • ●Zarządza obciążeniem/Load Balancing maszyn VM • Utility Server • ●Wiele możliwych w obrębie puli również na Master • ●Odpowiedzialny za operacje I/O (Copy/Move) • ●Tworzenie/Usuwanie/Zmiana nazw maszyn VM • serwerów i puli

18. Architektura Oracle VM – Role serwerów • Virtual MachineServer • ●Wiele możliwych w obrębie puli również na Master • ●Po prostu hostuje maszyny VM • Storage • ●Wspólny Storage w puli (SAN, NAS, iSCSI) • ●Maszyny wirtualne, zasoby zewnętrzne + pliki danych • ●System plików: OCFS2 lub NFS

19. Architektura Oracle VM

20. Architektura Oracle VM • XEN Hypervisor • Mały, lekki VMM (Virtual Machine Monitor) • Narzędzie niezbędne do prowadzenia procesu wirtualizacji • Decyduje które procesy wirtualizowanego systemu operacyjnego można wykonywać bezpośrednio sprzęcie, a które należy emulować.

21. Architektura Oracle VM • Domain 0 (Dom0) • Posiada uprzywilejowane prawa, przejmuje zadania związane z kontrolą i sterowaniem • Jest startowana jako pierwsza • Dostęp do sprzętu jest realizowany tylko tutaj, posiada niezbędne sterowniki • Zawiera aplikacje do sterowania domenami DomU • Domain U (DomU) • Zawierają instancje systemu operacyjnego • Są nieuprzywilejowane

22. Dwa rodzaje wirtualizacji - PVM i HVM • Wirtualizacja sprzętowa (HV) • Działa w oparciu hardware’owe rozszerzenia CPU • Intel VT-x i AMD-V dla x86/x86_64 • System operacyjny gościa nie wie, że działa na wirtualnym środowisku • Jądro systemu jest zamknięte np. Windows 2003, Windows Server 2003 and Windows XP • Parawirtualizacja (PV) • System operacyjny gościa wie, że jest uruchomiony w wirtualnym środowisku • Jądro systemu gościa jest zmodyfikowane, bardzo wydajny dostęp do sprzętu przy pomocy API, porównywalny do natywnego

23. Oracle VM-Dostęp do urządzeń • Obsługa urządzeń • Dom0 posiada sterowniki do fizycznych urządzeń • Dostęp przez Hypervisor i pod jego kontrolą • Domeny DomU zawierają (para-) wirtualizowane odpowiedniki • Kernel DomU komunikuje się za pomocą wirtualnych sterowników z fizycznymi • Dla zapewniena wysokiej dostępności można np. konfigurowaćNIC bonding i Storage multipathing • Możliwy RAW Device Mapping do maszyn wirtualnych!

24. Najważniejsze funkcje i zalety Oracle VM • •Live Migration • •Pool i Guest High Availability • Pool Load Balancing • •Cloning • •P2V / V2V • •Templates

25. Najważniejsze funkcje i zalety Oracle VM • Live Migration • Migracja maszyn wirtualnych, w czasie rzeczywistym -podczas pracy, z jednego serwera fizycznego na drugi • Brak opóźnień i przestojów • Ciągła dostępność usług • Pełna integralność wszystkich transakcji • Służy do równoważenia obciążenia i planowanych prac konserwacyjnych

26. Najważniejsze funkcje i zalety Oracle VM • Pool i Guest High Availability (HA) • Automatyczne przeniesienie ról oraz uruchomienie maszyn wirtualnych (VM)w obrębie puli po awarii • Pool Load Balancing (LB) • Podczas uruchamiania maszyny wirtualnej (VM) zostanie wybrany serwer OVM z największą ilościa wolnych zasobów • Cloning • Klonowanie maszyn wirtualnych (VM) umożliwia szybką budowę systemów testowych, lub umożliwia przeniesienie VM do innej puli serwerów • P2V / V2V • Dzieki narzędziu P2V na Oracle VM można zwirtualizować fizyczny serwer, V2V migracja plików VDMK VMware do OVM

27. Najważniejsze funkcje i zalety Oracle VM • Templates • Gotowe, prekonfigurowane systemy z oprogramowaniem Oracle • Przetestowane i zoptymizowane pod kątem aplikacji Oracle • Bezpłatny pobieranie z Oracle E-Delivery • Możliwość konfiguracji, a następnie zapisu jako obraz bazowy

28. Architektura rozwiązania BUW • Sprzęt • 4x(2x) Power Edge R910 (4*8 core Intel Xeon 7560) • 2x Sun Fire X2200M2 (2*4 core AMD 2376) • 2x Sun StorageTek 2540 + 2x StorageTek 2501 • 2x Brocade 300 FC • Oprogramowanie • Oracle VM Server 2.2.1 • Oracle VM Manager 2.2.0

29. Podsumaowanie Oracle VM •Darmowy produkt oparty na Xen •Przetestowana i wspierana przez Oracle technologia wirtualizacji serwerów i produktów Oracle •Konsolidacja serwerów Linux i Windows na platformie x86 i x86_64 •Szablony maszyn wirtualnych do automatycznego wdrażania Oracle VM •Zintegrowana konsola zarządzania, oparta na przeglądarce WWW •Zawiera opcję Live Migration bez dodatkowych opłat •Gotowe do ściągnięcia, przetestowane i zoptymalizowane przez Oracle obrazy z zainstalowanymi produktami •Wsparcie techniczne odpowiednie do zawartej umowy

30. Architektura rozwiązania BUW Pełna nadmiarowość infrastruktury

31. DEMO Virtua serwer • Live Migration – bezprzerwowe przenoszenie maszyn wirtualnych w obrębie puli • High Availability - automatyczne uruchomienie maszyn wirtualnych w obrębie puli po awarii

32. Jak działa ”Live Migration”

33. Jak działa ”Live Migration”

34. Jak działa ”Live Migration”

35. Jak działa ”Live Migration”

36. Jak działa ”Live Migration”

37. Jak działa ”Live Migration”

38. Jak działa ”High Availability”

39. Jak działa ”High Availability”

40. Jak działa ”High Availability”

41. Zapraszamy na DEMO

42. Dziękujemy za uwagę a.regmunt@uw.edu.pl adam.twarowski@uw.edu.pl