1. Akademia Górniczo-Hutnicza
im. Stanisława Staszica w Krakowie
Wydział Elektrotechniki, Automatyki, Informatyki
i Elektroniki
Katedra Informatyki
PRACA DYPLOMOWA
Magisterska
Zarzadzanie dostepnoscia usług sieciowych w
zwirtualizowanej infrastrukturze obliczeniowej
Autorzy:
Jakub Lasek <kuba@cloudyna.pl>
Tomasz Kraus <tomek@cloudyna.pl>
Kierunek studiów: Informatyka
Opiekun pracy: dr inz. Sławomir Zielinski
Kraków 2012

2. Oswiadczenie autorów
Oswiadczamy, swiadomi odpowiedzialnosci karnej za poswiadczenie nieprawdy, ze ni-niejsza
prace dyplomowa wykonalismy osobiscie i samodzielnie (w zakresie wyszczegól-nionym
we wstepie) i ze nie korzystalismy ze zródeł innych niz wymienione w pracy.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Podpisy autorów)

3. Spis tresci
Spis rysunków . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Spis tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Spis skrótów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Streszczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Podział pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Metodologie zapewniania wysokiej dostepnosci usług sieciowych . . . . . 12
1.1. Wzorce projektowe wysokiej dostepnosci . . . . . . . . . . . . . . . . . . . . . 12
1.1.1. Redundancja pasywna . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.2. Redundancja N+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.3. Redundancja aktywna . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.4. Monitoring systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.5. Informowanie o usterce . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.6. Naprawa usterki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.7. Informowanie o naprawie . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2. Przeglad istniejacych rozwiazan . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.1. Srodowiska monitorujace usługi sieciowe . . . . . . . . . . . . . . . . 20
1.2.2. Srodowiska wdrazania i instalowania . . . . . . . . . . . . . . . . . . 22
1.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2. Przeglad istniejacych rozwiazan wirtualizacji i chmur obliczeniowych . . 27
2.1. Wirtualizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1. Wirtualizacja sprzetowa . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.2. Inne rodzaje wirtualizacji . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2. Chmura obliczeniowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1. Kolokacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2. Infrastructure-as-a-Service (IaaS) . . . . . . . . . . . . . . . . . . . . 32
2.2.3. Platform-as-a-Service (PaaS) . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.4. Software-as-a-Service (SaaS) . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.5. Software plus Services (S+S) . . . . . . . . . . . . . . . . . . . . . . . 34
2.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3. Proponowana architektura systemu . . . . . . . . . . . . . . . . . . . . . . . . 36
1

4. Spis tresci 2
3.1. Motywacja i cele projektowe . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2. Wymagania stawiane systemowi Cloudyna . . . . . . . . . . . . . . . . . . . 36
3.2.1. Automatyczna konfiguracja srodowiska . . . . . . . . . . . . . . . . . 37
3.2.2. Niezawodnosc i monitoring usług . . . . . . . . . . . . . . . . . . . . 37
3.2.3. Dynamiczna rekonfiguracja, mechanizm migracji . . . . . . . . . . . . 37
3.2.4. Persystencja danych i stanu . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5. Przypadki uzycia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3. Architektura projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1. Warstwa zarzadzajaca . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2. Warstwa agentowa hostów i kontenerów . . . . . . . . . . . . . . . . . 42
3.3.3. Warstwa serwisowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4. Srodowisko projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.1. Mechanizm persystencji danych . . . . . . . . . . . . . . . . . . . . . 45
3.4.2. Wymagania dotyczace sieci . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.3. Wymagania dotyczace architektur maszyn i systemu operacyjnego . . 45
3.5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4. Przeglad technologii niezbednych przy implementacji i ich zastosowanie 47
4.1. Wybór technologii - przeglad . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1. Wirtualizacje lekkie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2. Mechanizmy i protokoły komunikacji . . . . . . . . . . . . . . . . . . 53
4.1.3. Rozwiazania routingu dynamicznego . . . . . . . . . . . . . . . . . . 55
4.1.4. Przykładowe nadzorowane serwisy . . . . . . . . . . . . . . . . . . . . 56
4.1.5. Persystencja - serwer . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.6. Persystencja LDAP - API dostepowe . . . . . . . . . . . . . . . . . . 58
4.2. Decyzje technologiczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3. Zastosowane mechanizmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.1. Wirtualizacja na poziomie srodowiska (LXC) . . . . . . . . . . . . . . 61
4.3.2. Mechanizm komunikacji agentów (JMX) . . . . . . . . . . . . . . . . 65
4.3.3. Rozwiazania routingu dynamicznego (OSPF) . . . . . . . . . . . . . . 67
4.3.4. Warstwa persystencji (ApacheDS + UnboundID) . . . . . . . . . . . 70
4.3.5. Generowanie plików konfiguracyjnych (Mustache) . . . . . . . . . . . 75
4.4. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5. Implementacja systemu Cloudyna . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1. Działanie systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.1. Definicje pojec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.2. Przekrój przez warstwy systemu . . . . . . . . . . . . . . . . . . . . . 78
5.1.3. Bezawaryjnosc warstwy zarzadczej . . . . . . . . . . . . . . . . . . . . 78
5.1.4. Obsługa zadan przez warstwe zarzadcza . . . . . . . . . . . . . . . . 82
5.1.5. Obsługa zadan przez warstwe agentowa . . . . . . . . . . . . . . . . . 82
5.1.6. Instalacja / rekonfiguracja / deinstalacja . . . . . . . . . . . . . . . . 86
5.1.7. Monitoring usług i reakcja na okreslone zdarzenia . . . . . . . . . . . 93
5.2. Budowa systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3. Mozliwosci rozbudowy systemu . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4. Ograniczenia zastosowanego rozwiazania . . . . . . . . . . . . . . . . . . . . 97
5.5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6. Wyniki eksperymentów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.1. Opis wykorzystanego srodowiska testowego . . . . . . . . . . . . . . . . . . . 99

5. Spis tresci 3
6.2. Weryfikacja realizacji przypadków uzycia . . . . . . . . . . . . . . . . . . . . 100
6.2.1. Zestawienie poczatkowego srodowiska . . . . . . . . . . . . . . . . . . 100
6.2.2. Skalowalnosc srodowiska . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2.3. Wydajnosc architektury . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.4. Reakcja na awarie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.2.5. Reakcja na obciazenie . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7. Podsumowanie i wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.1. Zrealizowany zakres pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2. Przyszłosc projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2.1. Propozycje architektoniczne i projektowe . . . . . . . . . . . . . . . . 113
7.2.2. Optymalizacja istniejacych procesów . . . . . . . . . . . . . . . . . . 114
7.3. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A. Implementacja nowej usługi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.1. Persystencja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.2. Konfiguracja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.3. Wykonanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
B. Konfiguracja nowej maszyny fizycznej . . . . . . . . . . . . . . . . . . . . . . 119
C. Limity zasobów poszczególnych technologii wirtualizacji lekkiej . . . . . . 120

6. Spis rysunków
1.1 Redundancja pasywna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Mechanizm rozwiazywania konfliktów w redundancji pasywnej . . . . . . . . . . 14
1.3 Przykład wykorzystania redundancji N+1 . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Redundancja aktywna z zaznaczonym dyspozytorem . . . . . . . . . . . . . . . . 16
1.5 Serwery Apache umieszczone za proxy Nginx . . . . . . . . . . . . . . . . . . . . 17
1.6 Przekazanie zadan do pasywnej repliki . . . . . . . . . . . . . . . . . . . . . . . 19
1.7 Podjecie próby naprawy usterki . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8 Przekazanie informacji o naprawie repliki . . . . . . . . . . . . . . . . . . . . . . 20
1.9 Przykładowe wyniki wygenerowane przez Munin . . . . . . . . . . . . . . . . . . 24
1.10 Monit - informacje na temat systemu plików . . . . . . . . . . . . . . . . . . . . 25
2.1 Wirtualne systemy operacyjne - dzisiaj . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Modele chmur obliczeniowych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Diagram przypadków uzycia - monitoring . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Diagram przypadków uzycia - warstwa zarzadcza . . . . . . . . . . . . . . . . . . 38
3.3 Diagram przypadków uzycia - rekonfiguracja . . . . . . . . . . . . . . . . . . . . 39
3.4 Warstwy systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Komunikacja przy uzyciu protokołu RMI . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Przypadek uzycia cgroup do limitowania zasobów po uzytkownikach . . . . . . . 62
4.3 Diagram architektury JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Diagram sieci systemu Cloudyna . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.5 LDAP - ou=applications - konfiguracja startowa aplikacji . . . . . . . . . . . . . 72
4.6 LDAP - instalacja usługi - diagram stanów . . . . . . . . . . . . . . . . . . . . . 74
4.7 LDAP - deinstalacja usługi - diagram stanów . . . . . . . . . . . . . . . . . . . . 74
4.8 Kolejnosc i zaleznosci instancjonowania konfiguracji . . . . . . . . . . . . . . . . 75
5.1 Diagram architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2 Algorytm elekcji - widok nadawcy - diagram przepływu . . . . . . . . . . . . . . 79
5.3 Algorytm elekcji - widok odbiorcy - diagram przepływu . . . . . . . . . . . . . . 80
5.4 Algorytm elekcji z róznych perspektyw . . . . . . . . . . . . . . . . . . . . . . . 81
a Algorytm elekcji - perspektywa A . . . . . . . . . . . . . . . . . . . . . 81
b Algorytm elekcji - perspektywa B . . . . . . . . . . . . . . . . . . . . . 81
c Algorytm elekcji - awaria hosta . . . . . . . . . . . . . . . . . . . . . . 81
d Algorytm elekcji - powrót hosta . . . . . . . . . . . . . . . . . . . . . . 81
5.5 HostManager - diagram stanów . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 CloudynaClient - diagram stanów . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4

7. Spis rysunków 5
5.7 Mechanizm kolejki w GuestManagerze . . . . . . . . . . . . . . . . . . . . . . . . 85
5.8 Instalacja usługi - diagram sekwencji . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.9 HostManager - instalacja usługi - diagram przepływu . . . . . . . . . . . . . . . 89
5.10 HostManager - deinstalacja usługi - diagram przepływu . . . . . . . . . . . . . . 90
5.11 HostManager - bazowa konfiguracja - diagram przepływu . . . . . . . . . . . . . 91
5.12 HostManager - bazowe czyszczenie - diagram przepływu . . . . . . . . . . . . . . 92
5.13 Monitoring parametru - diagram przepływu . . . . . . . . . . . . . . . . . . . . . 94
5.14 Monitoring parametru - diagram stanów . . . . . . . . . . . . . . . . . . . . . . . 94
5.15 Diagram pakietów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.1 Schemat sieci srodowiska testowego . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 Obsługa zadan przez Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3 Skalowalnosc srodowiska - Zaleznosc liczby realizowanych zapytan od liczby
instancji usługi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.4 Wydajnosc architektury - Zaleznosc liczby realizowanych zapytan od liczby
instancji usługi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8. Spis tabel
1 Podział pracy miedzy autorów pracy dyplomowej . . . . . . . . . . . . . . . . . . 11
1.1 Poziomy dostepnosci systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Miary rozliczeniowe w IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Dostawcy usług IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Dostawcy usług PaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Dostawcy usług SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Porównanie wirtualizacji lekkich . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1 Proces wdrazania usługi - czas wdrozenia . . . . . . . . . . . . . . . . . . . . . . 101
6.2 Skalowalnosc srodowiska - jeden serwer WWW . . . . . . . . . . . . . . . . . . 102
6.3 Skalowalnosc srodowiska - dwa serwery WWW . . . . . . . . . . . . . . . . . . 102
6.4 Skalowalnosc srodowiska - trzy serwery WWW . . . . . . . . . . . . . . . . . . 104
6.5 Skalowalnosc srodowiska - cztery serwery WWW . . . . . . . . . . . . . . . . . 104
6.6 Skalowalnosc srodowiska - piec serwerów WWW . . . . . . . . . . . . . . . . . . 104
6.7 Skalowalnosc srodowiska - szesc serwerów WWW . . . . . . . . . . . . . . . . . 105
6.8 Wydajnosc - jeden serwer WWW . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.9 Wydajnosc - dwa serwery WWW . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.10 Wydajnosc - trzy serwery WWW . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.11 Wydajnosc - cztery serwery WWW . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.12 Wydajnosc - piec serwerów WWW . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.13 Wydajnosc - szesc serwerów WWW . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.14 Awaria kontenera - Reakcja systemu na awarie . . . . . . . . . . . . . . . . . . . 108
6.15 Awaria hosta - Reakcja systemu na awarie . . . . . . . . . . . . . . . . . . . . . 109
6.16 Test szczytowy - Reakcja systemu na obciazenie . . . . . . . . . . . . . . . . . . 109
6.17 Test wytrzymałosciowy - Reakcja systemu na obciazenie . . . . . . . . . . . . . . 110
C.1 OpenVZ - Przykładowe parametry User Beancounters . . . . . . . . . . . . . . . 121
C.2 Linux VServer - Parametry dostepne do limitowania . . . . . . . . . . . . . . . . 121
C.3 OpenSolaris - metody limitowania zasobów . . . . . . . . . . . . . . . . . . . . . 122
6

9. Spis skrótów
• Access Control Information (ACI)
• Advanced Micro Dynamics Virtualization (AMD-V)
• Application Programming Interface (API)
• Berkeley Internet Name Domain (BIND)
• Complex Event Processing (CEP)
• Completely Fair Queuing (CFQ)
• Common Object Request Broker Architecture (CORBA)
• Central Processing Unit (CPU)
• Customer Relationship Management (CRM)
• create, read, update and delete (CRUD)
• Domain Name System (DNS)
• Diffusing Update ALgorithm (DUAL)
• Enhanced Interior Gateway Routing Protocol (EIGRP)
• Fair Share Scheduler (FSS)
• GNU General Public License (GPL)
• HyperText Markup Language (HTML)
• Hypertext Transfer Protocol (HTTP)
• Hypertext Transfer Protocol Secure (HTTPS)
• Infrastructure-as-a-Service (IaaS)
• International Business Machines Corporation (IBM)
• Internet Communications Engine (ICE)
• Interior Gateway Routing Protocol (IGRP)
• Internet Inter-ORB Protocol (IIOP)
• Internet Protocol (IP)
• Internet Protocol version 4 (IPv4)
• Internet Protocol version 6 (IPv6)
• Inter-process Communication (IPC)
• Internet Protocol Quality of Service (IPQoS)
• Intermediate System To Intermediate System (IS-IS)
• Java Management Extensions (JMX)
• Java Naming and Directory Interface (JNDI)
7

10. Spis skrótów 8
• Java Virtual Machine (JVM)
• Linux, Apache, MySQL, Perl/PHP/Python (LAMP)
• Local Area Network (LAN)
• Lightweight Directory Access Protocol (LDAP)
• Lightweight Directory Access Protocol (over SSL) (LDAPS)
• Logical Volume Manager (LVM)
• Linux Containers (LXC)
• Maximum Transmission Unit (MTU)
• Network Information Service (NIS)
• Non-Uniform Memory Access (NUMA)
• Object identifier (OID)
• Open Systems Interconnection (OSI)
• Open Shortest Path First (OSPF)
• Platform-as-a-Service (PaaS)
• PHP Hypertext Preprocessor (PHP)
• Process identifier (PID)
• Routing Information Protocol (RIP)
• Routing Information Protocol next generation (RIPng)
• Remote Method Invocation (RMI)
• Remote Procedure Call (RPC)
• Software-as-a-Service (SaaS)
• Software Development Kit (SDK)
• Simple Network Management Protocol (SNMP)
• Scalable Processor Architecture (SPARC)
• Secure Shell (SSH)
• Secure Socket Layer (SSL)
• Spanning Tree Protocol (STP)
• Solaris Volume Manager (SVM)
• Transmission Control Protocol (TCP)
• Transport Layer Security (TLS)
• User Datagram Protocol (UDP)
• Virtual Desktop Infrastructure (VDI)
• Virtual Machine Monitor (VMM)
• Virtual Private Server (VPS)
• Virtualization Technology (VT)
• Wireless Local Area Network (WLAN)
• World Wide Web (WWW)
• Zettabyte File System (ZFS)

11. Streszczenie
W ramach pracy Dyplomanci dokonali przegladu istniejacych metod wspomagaja-cych
gwarantowanie dostepnosci usług sieciowych w zwirtualizowanych srodowiskach
obliczeniowych udostepnianych zgodnie z paradygmatem Infrastructure-as-a-Service
(IaaS). Celem realizacji pracy była identyfikacja brakujacych elementów srodowisk
zarzadzajacych zwirtualizowana infrastruktura oraz implementacja prototypów po-trzebnych
mechanizmów. Systemowi implementowanemu w ramach czesci praktycznej
nadano nazwe “Cloudyna”.
Rozdział pierwszy, zatytułowany “Metodologie zapewniania wysokiej dostepnosci
usług sieciowych” zawiera teoretyczne wprowadzenie do omawianej tematyki. Przed-stawiony
został w nim opis rozwiazan, których celem jest zapewnienie wysokiego
poziomu dostepnosci usług sieciowych realizowanych w formie rozproszonej. W tym
miejscu zaprezentowane zostały takze istniejace srodowiska, których zadaniem jest
monitoring usług sieciowych oraz automatyzacja procesu instalacji i wdrazania zło-zonych
systemów komputerowych. Omówienie istniejacych srodowisk monitoringu za-wiera
nie tylko informacje o tym, co moze zostac poddane obserwacji, ale przedstawia
takze mozliwosci reagowania na sytuacje niepozadane.
Rozdział drugi, noszacy tytuł “Przeglad istniejacych rozwiazan wirtualizacji i
chmur obliczeniowych” przedstawia rodzaje rozwiazan wykorzystywanych do wirtuali-zacji
oraz wprowadza w tematyke modeli architektur zrealizowanych w postaci chmur
obliczeniowych. W tym rozdziale przyblizone zostały pojecia zwiazane z poszczegól-nymi
rodzajami wirtualizacji, a takze wymagania stawiane systemom, które maja z
tych typów wirtualizacji korzystac.
Rozdział trzeci, o tytule “Proponowana architektura systemu” został poswiecony
definicji celu i przedstawieniu motywacji kierujacej Dyplomantami przy wyborze te-matu
realizowanej pracy. W tym rozdziale zostały zdefiniowane wymagania, których
realizacja powinna byc zapewniona przez stworzone srodowisko. Kolejnym elemen-tem
tej czesci pracy jest opis architektury systemu, zawierajacy przede wszystkim
szczegółowa liste wymagan stawianych poszczególnym warstwom. Rozdział konczy
zestawienie warunków, które powinna spełniac infrastruktura sieciowa i sprzetowa, w
której system Cloudyna moze funkcjonowac.
Rozdział czwarty, zatytułowany “Przeglad technologii niezbednych przy imple-mentacji
i ich zastosowanie” skupia sie głównie na technicznych aspektach realizacji
9

12. Streszczenie 10
systemu i srodowiska. W pierwszej kolejnosci przedstawione zostały mozliwe do wyko-rzystania
technologie. Przedstawienia technologii dokonano na podstawie uprzednio
zdefiniowanych wymagan. Nastepnie przedstawiono i umotywowano wybór konkret-nych
technologii wykorzystywanych przy implementacji. W ostatniej czesci dokonano
opisu konkretnych mechanizmów wybranych technologii słuzacych do implementacji
systemu Cloudyna: wirtualizacji na poziomie systemu operacyjnego (Linux Containers
(LXC)), komunikacji agentów pracujacych na poszczególnych wezłach (Java Manage-ment
Extensions (JMX)), persystentnej konfiguracji (Lightweight Directory Access
Protocol (LDAP)) oraz komunikacji sieciowej (Open Shortest Path First (OSPF)).
Rozdział piaty, zatytułowany “Implementacja systemu Cloudyna” skupia sie wo-kół
przedstawienia realizacji konkretnych przypadków uzycia. Opisana została imple-mentacja
poszczególnych warstw systemu Cloudyna. Poswiecono podrozdział budowie
pakietowej systemu. Zaprezentowane zostały takze metody monitoringu usługi oraz
sposoby definiowania reakcji na dobrze zdefiniowane zdarzenia. Ostatnia czesc tego
rozdziału skupia sie na pokazaniu ograniczen zbudowanego rozwiazania oraz mozli-wosciach
rozbudowy systemu.
Rozdział szósty, zatytułowany “Wyniki eksperymentów” przedstawia wyniki prze-prowadzonych
eksperymentów. Zaprezentowane zostało zachowanie systemu Cloudy-na
w przypadku przejscia jego wezłów w zdefiniowane stany niepozadane. Przeprowa-dzone
testy systemu zostały wykorzystane do weryfikacji poprawnej obsługi przypad-ków
uzycia.
Praca konczy sie krótkim podsumowaniem dokonan oraz pokazaniem potencjal-nych
kierunków rozwoju.
Słowa kluczowe
wysoka dostepnosc, wirtualizacja, chmura obliczeniowa, IaaS, SaaS, PaaS, monito-ring,
reakcja na zdarzenia, automatyczna konfiguracja, rekonfiguracja, równowazenie
obciazenia, rozproszenie, automatyzacja, redundancja, automatyczne wdrazanie, kon-tenery

13. Abstract
In the master thesis, MSc candidates are about to review methods addressed
towards web services high-availability. Thesis is focused on web services hosted in
virtualized computational architectures, based on Infrastructure-as-a-Service (IaaS)
paradigm. Dissertation will focus on identifying missing elements of existing virtuali-zation
management environments. Next step will be implementation of prototypes of
missing elements. System implemented in the technical part of the dissertation has
been named “Cloudyna”.
Chapter one, entitled “Web services high-availability patterns” consists of theore-tical
introduction, which describes solutions helping in maintaining high-availability
of distributed environments. Furthermore, existing monitoring and automated deploy-ment
environments have been reviewed. Review addressed failure reaction capabilities
of described environments.
Chapter two, entitled “Review of existing virtualization and cloud computing so-lutions”
shows types of solutions used to implement current virtualization techniques,
and briefly describes architecture types used in cloud computing environments. This
chapter addresses definitions of key terms related to reviewed virtualization methods,
and the requirements of the systems that are about to run on virtualized architectures.
Chapter three, entitled “System architecture proposal” begins with motivation and
goals of the system that MSc candidates have chosen for their dissertation. Next, thesis
addresses requirements that are about to be satisfied by implemented system. Fur-thermore,
architecture of the system is presented, consisting of precise requirements of
every system layer. Last, chapter presents requirements laid upon newly-implemented
system environment, such as network and hardware infrastructure.
Chapter four, entitled “Technology review, technology necessary for implementa-tion”
focuses mainly on technical aspects of the thesis. Firstly, MSc candidates have
completed review of solutions and technologies capable of addressing each system lay-er’s
requirements. Solutions on each layer have been compared, and the reasoning for
choosing a concrete technology has been presented. Moreover, detailed mechanisms of
chosen technologies have been presented, such as: operating system-level virtualization
(Linux Containers (LXC)), communication between agents operating on distributed
nodes (Java Management Extensions (JMX)), persistent configuration (Lightweight
11

14. Abstract 12
Directory Access Protocol (LDAP)) and network communication (Open Shortest Path
First (OSPF)).
Chapter five, entitled “Cloudyna system implementation” focuses on presentation
of implemented use cases. Methods of services’ monitoring and specific events’ reaction
definitions have been presented. Package structure of the project is shown in this
chapter. Last part focuses on limits enforced by the used solutions and potential
future development of the system.
Chapter six, entitled “Test results” shows the results of experiments, that have
been performed on running Cloudyna system. Behavior of various failure-handling
Cloudyna capabilities have been thoroughly tested and presented in this chapter.
Tests that have been performed are used to prove that implemented system satisfied
previously mentioned use cases.
Thesis ends with brief summary of the project, and presents potential ways of
future development.
Keywords
high availability, virtualization, cloud computing, IaaS, SaaS, PaaS, monitoring,
event reaction, automated configuration, reconfiguration, load balancing, distibution,
automatization, redundancy, automated deployment, containers

15. Podział pracy
Praca i implementacja została stworzona przez dwóch autorów: Jakuba Laska i To-masza
Krausa. Rozwazania teoretyczne, implementacje, testy, przykładowe wdrozenia
podzielono na okreslone grupy funkcjonalne, gdzie nastepował podział obowiazków
miedzy dyplomantami. Nie wyszczególniono podziału obowiazków na poziomie przy-dzielenia
osobom okreslonych funkcji w całym projekcie, jak np. tester, programista,
projektant.
Jakub Lasek był odpowiedzialny w czesci teoretycznej za analize metod wysokiej
dostepnosci, analize wyników eksperymentów. W czesci praktycznej Jakub skupił sie
na mechanizmach monitoringu oraz komunikacji miedzy agentami, oraz dokładnym
przetestowaniu zaimplementowanego systemu.
Tomasz Kraus był odpowiedzialny w czesci teoretycznej za przeglad metod wir-tualizacji,
oraz stworzenie architektury implementowanego systemu. W czesci prak-tycznej
Tomasz skupił sie na mechanizmach wirtualizacji, komunikacji sieciowej oraz
zaimplementował podsystem persystencji.
Obaj dyplomanci porównywalnie partycypowali w przygotowaniu rozdziałów czesci
teoretycznej, dotyczacych przegladu technologii niezbednych do implementacji oraz
samej implementacji systemu Cloudyna.
Kluczowe decyzje projektowe i architektoniczne zapadały na mocy wspólnych usta-len,
narad i konsultacji.
Dokładniejszy podział przedstawiono w tabeli 1. Kazdemu opisanemu elementowi
przyznano sumarycznie 10 punktów. Punkty sa dysponowane miedzy dyplomantów,
w zaleznosci od ich zaangazowania i realizacji konkretnego elementu pracy.
13

16. Podział pracy 14
Element pracy JL* TK*
Tekst pracy magisterskiej - rozdziały
Metodologie zapewniania wysokiej dostepnosci . . . 10 0
Przeglad istniejacych rozwiazan wirtualizacji . . . 0 10
Proponowana architektura systemu 2 8
Przeglad technologii niezbednych przy implementacji . . . 5 5
Implementacja systemu Cloudyna 5 5
Wyniki eksperymentów 8 2
Podsumowanie i wnioski 5 5
Implementacja
Jadro systemu 5 5
Mechanizmy wirtualizacji 1 9
Mechanizmy komunikacji agentów 8 2
Mechanizmy komunikacji sieciowej 2 8
Mechanizmy persystencji 1 9
Mechanizmy monitoringu 9 1
Testy
Projektowanie 6 4
Przeprowadzanie 5 5
Analiza i raporty 8 2
*JL - Jakub Lasek, TK - Tomasz Kraus
Tabela 1. Podział pracy miedzy autorów pracy dyplomowej

17. Rozdział 1
Metodologie zapewniania wysokiej
dostepnosci usług sieciowych
Wiekszosc współczesnych systemów komputerowych wymaga ciagłego i stabilnego
działania. Sytuacje awarii sa niedopuszczalne dla instytucji, których działanie opiera
sie na pracy ich systemów informatycznych.
O systemach, które zapewniaja ustalony poziom dostepnosci w okreslonym okresie
czasu mozna powiedziec, ze zostały zaprojektowane w sposób gwarantujacy wysoka
dostepnosc (z ang. high availability). W idealnych warunkach, dostepnosc powinna
wynosic 100%, jednak w rzeczywistych przypadkach dochodzi do sytuacji, w których
system jest nieosiagalny dla uzytkowników.Wpraktyce, poziom dostepnosci mierzony
jest w skali okreslanej jako “liczba dziewiatek” (z ang. number of nines ).
Tabela 1.1. Poziomy dostepnosci systemu
Dostepnosc % Dopuszczalny czas przestoju (rocznie)
90% 36,5 dni
99% 3,65 dni
99,9% 8,8 godziny
99,99% 52,6 minuty
99,999% 5,26 minuty
99,9999% 31,5 sekundy
99,99999% 3,2 sekundy
Postawienie wymagania dostepnosci systemu na poziomie “pieciu dziewiatek” (99,999%)
wymaga od systemu, aby jego srednia dzienna niedostepnosc wynosiła około 1 sekun-de.
Wymóg ten pociaga za soba koniecznosc zaprojektowania takiego rozwiazania,
które jest w stanie samodzielnie reagowac na pojawiajace sie problemy z awaryjnoscia
swoich komponentów.
1.1. Wzorce projektowe wysokiej dostepnosci
W ponizszych podrozdziałach przedstawione zostały wzorce projektowe, których
uzycie ma na celu zapewnienie wysokiej dostepnosci w systemach komputerowych. W
opisie poszczególnych metod przyjeto nastepujace nazewnictwo:
15

18. 1.1. Wzorce projektowe wysokiej dostepnosci 16
komponent systemu - oprogramowanie badz sprzet wchodzace w skład systemu,
mogace byc traktowanego jako jedna z jego niezaleznych czesci składowych.
klient komponentu - dowolna jednostka komunikujaca sie z komponentem systemu.
Nie zawsze oznacza klienta całego systemu, moze takze odnosic sie do innego z jego
komponentów, z którym dany komponent wchodzi w interakcje.
awaria systemu (z ang. (system failure)) - sytuacja, w której dostarczana usługa
zachowuje sie inaczej niz zakładał projekt systemu
pojedynczy punkt awarii (z ang. single point of failure) - dowolny ze składników
systemu, którego awaria powoduje przerwanie lub zaburzenie pracy systemu jako
całosci.
1.1.1. Redundancja pasywna
Redundancja pasywna (z ang. Active-Passive Redundancy) polega na wprowadze-niu
dodatkowych zasobów, stanowiacych repliki zdefiniowanych potencjalnych poje-dynczych
punktów awarii systemu. Zasoby te sa niewykorzystywane az do momentu
awarii aktywnego komponentu. W takim przypadku, klienci komunikujacy sie z kom-ponentem
powinni zostac poinformowani o aktywacji repliki. Istotnym wymaganiem
dla klienta jest koniecznosc obsługi powiadomienia o zmianie aktywnego komponentu
i przekierowania do niego kolejnych zadan [?].
W przypadku niektórych komponentów konieczne jest zachowanie stanu w razie
wystapienia awarii. W takiej sytuacji, aktywny komponent powinien kazda zmiane
swojego stanu przesyłac do swoich replik. Przedstawione podejscie wymaga istnienia
pomiedzy komponentami dobrego kanału komunikacyjnego, aby zmiany były przeka-zywane
w czasie rzeczywistym, a w razie awarii nie doszło do ich utraty.
Rysunek 1.1 przedstawia system, w którym pojedynczy punkt awarii posiada dwie
pasywne repliki. Klienci komunikujacy sie z systemem przesyłaja zadania do aktyw-nego
komponentu. W momencie jego uszkodzenia, jedna z replik przejmuje obsługe
zapytan uzytkowników i staje sie dla nich komponentem aktywnym.
Rysunek 1.1. Redundancja pasywna

19. 1.1. Wzorce projektowe wysokiej dostepnosci 17
Algorytm rozwiazywania konfliktów
W celu zwiekszenia dostepnosci systemu, jego poszczególne komponenty moga zo-stac
zduplikowane. Przedstawiony w podrozdziale 1.1.1 przykład pokazuje sytuacje, w
której komponent posiada dwie repliki. W momencie zajscia jego awarii jedna z replik
powinna przejac kontrole nad wykonaniem klienckich zapytan. Uzycie wiekszej liczby
zapasowych komponentów moze byc uzasadnione w przypadku koniecznosci uzyskania
wyzszego stopnia dostepnosci. Wykorzystanie wielu replik powoduje, ze mozliwa jest
sytuacja zakleszczenia, w której przynajmniej dwie z pasywnych replik chca przejac
obsługe zadan po uszkodzeniu aktywnego elementu. W takim przypadku konieczne
jest wykorzystanie algorytmu, którego zadaniem jest rozwiazywanie wystepujacych
konfliktów. Algorytm rozwiazywania konfliktów powinien gwarantowac stan systemu,
w którym w kazdym momencie jego działania aktywny bedzie wyłacznie jeden kom-ponent.
Istnieje kilka mechanizmów, których zadaniem jest rozwiazywanie konflików
pomiedzy replikami, w wiekszosci bazuja one na nadaniu replikom pewnego atrybutu
i wyborze jako aktywnej tej z minimalna jego wartoscia.
Pierwszym sposobem wyboru aktywnej repliki jest nadanie kazdej z replik unikal-nego
numeru identyfikacyjnego ID i wybranie jako aktywnej repliki o najmniejszym
ID. Opisany mechanizm wykorzystywany jest w algorytmie drzewa rozpinajacego
Spanning Tree Protocol (STP), którego budowa rozpoczyna sie od głównego mostka (z
ang. root bridge) wybieranego własnie według numerów identyfikacyjnych mostków.W
przypadku, gdy komponenty nie posiadaja przypisanych numerów identyfikacyjnych,
ich role moga pełnic generowane przez repliki liczby pseudolosowe.
Inne rozwiazanie problemu wyboru aktywnego komponentu moze polegac na opar-ciu
selekcji na znacznikach czasowych startu kazdej z replik. Aktywna w tym przy-padku
zostaje replika, która została wystartowana jako pierwsza. [?]
Rysunek 1.2 przedstawia sytuacje, w której dwie repliki usługi odpytuja mecha-nizm
rozwiazywania konfliktów o okreslenie, która z nich powinna pełnic role aktyw-nej,
a która zapasowej. Jako aktywny został wybrany komponent posiadajacy nizszy
numer identyfikacyjny.
Rysunek 1.2. Mechanizm rozwiazywania konfliktów w redundancji pasywnej

20. 1.1. Wzorce projektowe wysokiej dostepnosci 18
Warto zauwazyc, ze o ile oparcie algorytmu rozwiazywania konfliktów na nume-rach
identyfikacyjnych komponentów jest bezpieczne, to wykorzystanie liczb pseudo-losowych
i znaczników czasowych nie daje pewnosci, ze konflikt zostanie rozwiazany.
Mozliwa jest sytuacja, w której dwie z replik otrzymaja w wyniku losowania te sama
liczbe lub rozpoczna prace z identycznym znacznikiem czasowym.
1.1.2. Redundancja N+1
W przypadku zdefiniowania duzej liczby pojedynczych punktów awarii warto roz-wazyc
wykorzystanie redundancji N+1. Jest to rodzaj redundancji pasywnej, w której
repliki kilku usług zgrupowane sa w jednej pasywnej maszynie, która moze przejac
role aktywnej repliki w przypadku awarii dowolnego z replikowanych wezłów. Wada
systemu zbudowanego w opisywany sposób jest to, ze dopuszcza w kazdym momencie
awarie wyłacznie jednego z komponentów. Główna zaleta omawianego rozwiazania
jest optymalizacja kosztowa srodowiska. Brak koniecznosci duplikowania kazdego z
pojedynczych punktów awarii powoduje, ze ilosc zasobów koniecznych do realizacji
zapewniania dostepnosci jest stosunkowo niska. Klient korzystajacy z systemu uzy-wajacego
redundancji N+1 powinien zapewniac obsługe powiadomien z podsystemu
zarzadzajacego awariami i przekierowan ruchu do nowo aktywowanych replik.
Rysunek 1.3. Przykład wykorzystania redundancji N+1
Zastosowanie redundancji N+1 gwarantuje, ze praca systemu nie zostanie przerwa-na
w przypadku awarii dowolnego z jego komponentów. Wzrost liczby podsystemów
wchodzacych w skład srodowiska niesie ze soba zwiekszenie prawdopodobienstwa jed-noczesnej
awarii kilku wezłów. W takim przypadku podejscie z redundancja N+1

21. 1.1. Wzorce projektowe wysokiej dostepnosci 19
nie zapewnia, ze system bedzie nadal dostepny. W celu zapewnienia odpowiedniego
poziomu dostepnosci w takiej sytuacji, mozliwe jest wykorzystanie kilku pasywnych
replik lub podział systemu na kilka N-elementowych grup i dodanie replik do kazdej
z nich.
1.1.3. Redundancja aktywna
Redundancja aktywna (z ang. Active-Active Redundancy) wykorzystywana jest
w systemach, które wymagaja maksymalizacji wykorzystania posiadanych zasobów
przy jednoczesnym zapewnieniu odpowiedniego stopnia dostepnosci. O ile w przypad-ku
redundancji pasywnej, zadania sa obsługiwane przez tylko jedna aktywna replike,
redundancja aktywna umozliwia współistnienie wielu aktywnych wersji komponen-tu
systemu. Dzieki temu mozliwy jest wzrost wydajnosci srodowiska zbudowanego
z wiekszej liczby zduplikowanych komponentów, co jest najwieksza zaleta tego typu
redundancji. Rozwiazania opierajace sie na redundancji aktywnej bywaja czesto nazy-wane
klastrami (z ang. cluster). Za przydział zadan do konkretnych elementów klastra
odpowiedialny jest dodatkowy element systemu zwany dyspozytorem (z ang. dispat-cher).
Klienci przekazuja swoje zapytanie do dyspozytora, który nastepnie przesyła
je do wybranego elementu klastra [?].
Rysunek 1.4. Redundancja aktywna z zaznaczonym dyspozytorem
Informacja o tym, które wezły klastra powinny byc wyłaczone z obsługi zadan
przechowywane sa bezposrednio w dyspozytorze. Wykorzystanie redundancji aktyw-nej
pozwala na takie skonfigurowanie dyspozytora, aby w przypadku awarii jednego z
elementów klastra zadania były nadal poprawnie obsługiwane przez pozostałe wezły.

22. 1.1. Wzorce projektowe wysokiej dostepnosci 20
Problemem w przypadku wykorzystania klastra moze okazac sie potrzeba zachowa-nia
stanu komponentu. Redundancja pasywna pozwalała na zmiane stanu wyłacznie
aktywnej repliki, uzycie klastra wymusza koniecznosc synchronizacji zmian stanów
wszystkich z jego wezłów. W celu unikniecia konfliktu pomiedzy stanami elementów
klastra, powinny one zapewniac komunikacje w czasie rzeczywistym co pociaga ko-niecznosc
zestawienia wydajnego kanału komunikacyjnego pomiedzy wezłami.
Jako przykład uzycia aktywnej redundancji mozna wymienic rozbudowane serwisy
WWW, składajace sie z wielu serwerów aplikacyjnych oraz zapewniajacego dostep do
nich serwera proxy. Jedna z najczesciej spotykanych konfiguracji jest umieszczenie
wielu serwerów Apache za jednym serwerem Nginx [?], pełniacym role dyspozytora.
Kazdy z serwerów Apache ma dostep do wspólnej bazy danych. Dzieki temu, zadania
Hypertext Transfer Protocol (HTTP) uzytkowników kierowane sa na adres serwera
Nginx, ale ich obsługa odbywa sie w warstwie serwerów Apache niewidocznych dla
klientów.
Rysunek 1.5. Serwery Apache umieszczone za proxy Nginx
1.1.4. Monitoring systemu
Skuteczne działanie w systemie dowolnego z rodzajów redundancji wymaga za-pewnienia
detekcji usterek wchodzacych w skład srodowiska komponentów. System
powinien byc w stanie wykryc uszkodzenie, przekazac informacje o jego wystapie-niu
do pozostałych elementów oraz wykonac próbe rozwiazania problemu. Pierwszym
krokiem na tej sciezce jest monitoring systemu. Proces monitoringu polega na okre-sowym
pomiarze istotnych dla obserwatora parametrów systemu. Celem prowadzenia
obserwacji systemu jest kontrola wszystkich pojedynczych punktów awarii.
Wyróznia sie dwa podstawowe modele komunikacji, według których mechanizm
monitoringu moze przekazywac informacje pomiedzy wezłem monitorujacych a mo-nitorowanym:

23. 1.1. Wzorce projektowe wysokiej dostepnosci 21
• klient-serwer (z ang. client-server) - typ architektury , w którym klienci maja
mozliwosc nawiazania połaczenia z serwerem i wymiany z nim komunikacji. Z usług
serwera korzystac moze wielu klientów, komunikacja z kazdym serwerem wymaga
zestawienia i utrzymania aktywnego połaczenia przez co model klient-serwer jest
mało wydajny przy koniecznosci jednoczesnej komunikacji z wieloma wezłami.
• publish/subscribe - wzorzec w którym nadawcy informacji zwani jako wydawcy
(publishers) publikuja komunikaty nie definiujac kto jest ich odbiorcami (subscri-bers).
Komunikaty grupowane sa w kanały, a odbiorcy maja mozliwosc wyrazenia
checi uzyskania informacji z danego kanału.
Komunikacja publish/subscribe nie zakłada koniecznosci wiedzy wydawców o od-biorcach
i odwotnie. Wydawca przesyła komunikat do kanału, nie zwracajac uwagi
czy ktokolwiek jest zainteresowany danym typem wiadomosci. Takze odbiorcy nie
maja wiedzy o tym, czy nasłuchiwanym przez nich kanałem jakikolwiek wydawca
przesyła informacje.
Do wykrywania niepoprawnego działania komponetów systemu moze byc wyko-rzystywany
dodatkowy element nazywany watchdog. Watchdog wiaze kazdy z mo-nitorowanych
zasobów z dodatkowym licznikiem, którego wartosc jest zwiekszana w
momencie uzyskania informacji od monitorowanego urzadzenia lub usługi. Co pewien
ustalony czas nastepuje sprawdzenie i wyzerowanie liczników. Liczniki, których war-tosci
wynosza zero pozwalaja na zidentyfikowanie urzadzen, które potencjalnie uległy
awarii. Moduł watchdoga moze w takiej sytuacji podjac próbe przywrócenia działania
zasobu. [?]
1.1.5. Informowanie o usterce
System wyposazony z monitoring powinien dostarczac takze mechanizm informo-wania
o usterce (z ang. Failure Notification).
W przypadku systemów opierajacych sie na redundancji pasywnej, otrzymanie
informacji o usterce komponentu powinno spowodowac przekierowanie zadan klien-tów
do aktywowanej pasywnej repliki.Wsrodowiskach wykorzystujacych redundancje
aktywna, dyspozytor oznacza uszkodzony element systemu i kolejne zadania klientów
rozsyła do pozostałych aktywnych wezłów.
Rysunek 1.6 przedstawia sytuacje, w której Replika 1 informuje srodowisko o
swojej awarii, co powoduje przekierowanie zadan klientów do Replika 2.
1.1.6. Naprawa usterki
System dostarczajacy informacje o wystepujacych w nim usterkach powinien takze
udostepniac mechanizm podejmujacy próbe naprawy uszkodzonego wezła (z ang. Fa-ilure
Recovery). Zadaniem tego mechanizmu jest przywrócenie uzywalnosci elementów
systemu, które monitoring uznał za wadliwe. W pierwszej kolejnosci proces naprawy
komponentu moze polegac na próbie jego automatycznej ponownej inicjalizacji. Jezeli
inicjalizacja nie zakonczy sie sukcesem, system moze podjac próbe detekcji usterki na
podstawie przygotowanych testów. Po zdiagnozowaniu problemu, składnik systemu
powinien byc przekazany do recznej naprawy przez administratora. W przypadku
komponentów, które przechowuja swój stan, ich naprawa przez ponowna inicjalizacje

24. 1.1. Wzorce projektowe wysokiej dostepnosci 22
Rysunek 1.6. Przekazanie zadan do pasywnej repliki
lub interwencje administratora powinna skutkowac synchronizacja stanu z pozostały-mi
replikami.
Rysunek 1.7 pokazuje proces, który ma na celu przywrócenie repliki do popraw-nego
stanu, pozwalajacego na ponowne przejscie w stan aktywny.
Rysunek 1.7. Podjecie próby naprawy usterki
1.1.7. Informowanie o naprawie
Wdrozenie w system mechanizmu pozwalajacego na naprawe uszkodzonych ele-mentów
pociaga za soba koniecznosc informowania pozostałych czesci systemu o
ewentualnym sukcesie procesu naprawy komponentu (z ang. Recovery Notification).
Odzyskana replika wraca do puli pasywnych replik przy pasywnej redundancji lub
zwieksza liczbe aktywnych wezłów klastra dla redundancji aktywnej, co pozytywnie
wpływa na zwiekszenie dostepnosci całego systemu. W przypadku systemu, w którym
komponenty posiadaja stan, który powinien byc zachowany, replika musi przeprowa-dzic
proces synchronizacji stanu z jednym z aktywnych wezłów srodowiska.
Rysunek 1.8 obrazuje sytuacje, w której informacja o ponownym poprawnym funk-cjonowaniu
Replika 1 trafia do klienta, który w ramach odpowiedzi zmienia cel wy-syłanych
zadan.

25. 1.2. Przeglad istniejacych rozwiazan 23
Rysunek 1.8. Przekazanie informacji o naprawie repliki
W przypadku systemów wykorzystujacych algorytm rozwiazywania konfliktów,
powrót uszkodzonego wezła do normalnej pracy bedzie czesto powodował zmiane ak-tywnej
repliki obsługujacej zadania klientów.
Jako praktyczny przykład, w którym zaobserwowac mozna przekazanie informa-cji
o naprawie, przedstawic mozna złozony klaster serwerów baz danych MySQL, w
którym ponownie uruchomiony wezeł informuje system zarzadzania klastrem o swoim
działaniu i przeprowadza aktualizacje danych w tabelach z klastrem.
1.2. Przeglad istniejacych rozwiazan
Zapewnienie okreslonego wysokiego stopnia dostepnosci systemu jest zadaniem
złozonym, wykorzystujacym szereg technik przedstawionych w podrozdziale 1.1. Do-datkowym
czynnikiem komplikujacym ten proces jest zmiennosc w czasie stopnia
uzywalnosci systemu. Skuteczna metoda rozwiazujaca ten problem moze okazac sie
dynamiczne przydzielanie replik z dostepnej puli. Liczba replik powinna byc zalezna
od aktualnego obciazenia usługi.Wcelu zastosowania takiego mechanizmu, przydatne
wydaje sie dostarczenie narzedzia kontrolujacego proces wdrazania usług. Niniejszy
rozdział zawiera przeglad powszechnie stosowanych srodowisk monitorujacych oraz
prezentuje narzedzia automatyzujace instalacje i konfiguracje systemu i usług.
1.2.1. Srodowiska monitorujace usługi sieciowe
Budowa coraz bardziej złozonych srodowisk oraz koniecznosc pracujacych w nich
usług sieciowych przyczyniła sie do wzrostu liczby narzedzi, którym zadaniem jest
monitoring systemów rozproszonych. Wiekszosc dostepnych narzedzi realizujacych ten
proces składa sie z trzech nastepujacych warstw:
Agent - jest prostym programem uruchamianym na monitorowanej maszynie. Agent
pozyskuje informacje na temat swoich zasobów i przesyła je do serwera. Agent

26. 1.2. Przeglad istniejacych rozwiazan 24
posiada zwykle niewielkie mozliwosci, które moga byc zwiekszone poprzez dodanie
do niego odpowiednich rozszerzen.
Serwer - rola serwera jest odbiór danych przesyłanych przez agentów ulokowanych
na monitorowanych maszynach. W przypadku wystapienia sytuacji, która została
zdefiniowana jako niepozadana, serwer ma mozliwosc wygenerowania i wysłania
do administratora stosownego powiadomienia.
Warstwa prezentacji - informacje wysyłane przez agentów oraz przetwarzane i
składowane przez serwer moga byc udostepnione administratorom srodowiska po-przez
dostarczona z narzedziem monitorujacym warstwe prezentacji. Role tej czesci
srodowiska pełni najczesciej serwis WWW prezentujacy historie monitorowanych
parametrów przechowywana w bazie danych.
W kolejnych punktach zaprezentowane zostało kilka przykładowych popularnych
srodowisk monitoringu. Przedstawione zostały ich mozliwosci, wady oraz zalety a
takze brakujace elementy. Rozdział konczy próba zdefiniowania srodowiska, którego
realizacja ma byc czescia niniejszej pracy.
Munin
Munin jest narzedziem, którego zadaniem jest pomiar wartosci poszczególnych
parametrów komponentów oraz ich prezentacja w formie graficznej, dostepnej przez
interfejs przegladarki internetowej. Zaprojektowany został w taki sposób, aby rozsze-rzenie
jego mozliwosci było jak najprostsze. Srodowisko zawiera około 500 konfigu-rowalnych
rozszerzen, które umozliwiaja kontrole najczesciej monitorowanych para-metrów
systemów. W przypadku braku rozszerzenia kontrolujacego dany parametr
mozliwe jest jego doimplementowanie w dowolnym jezyku skryptowym. (Munin no-de)
i serwera (Munin master). Agent pracuje na kazdym z monitorowanych hostów,
jego zadaniem jest pomiar parametrów maszyny, na której działa. Serwer jest wezłem
gromadzacym dane na temat monitorowanych parametrów elementów srodowiska.
Serwer jest strona nawiazujaca komunikacje polegajaca na odpytywaniu agentów o
informacje na temat monitorowanych zasobów. [?]
Omawiane srodowisko słuzy wyłacznie do gromadzenia i prezentacji danych o sys-temie.
Nie istnieje mozliwosc zdefiniowania, kiedy system jest w stanie niepozadanym,
nie istnieje tez mozliwosc generowania powiadomien o stanie systemu. Pomimo tych
braków, jako srodowisko do gromadzenia informacji na temat tego, co działo sie z sys-temem
w przeszłosci sprawdza sie bardzo dobrze. Dzieki zastosowaniu narzedzia tego
typu, zdiagnozowanie przyczyny nadmiernego obciazenia zasobu jest zdecydowanie
prostsze.
Nagios
Jednym z najpopularniejszych narzedzi monitoringu usług sieciowych jest Nagios.
Pozwala on na monitoring zarówno serwerów i pracujacych na nich aplikacji jak i
sieci wraz z działajacymi w niej urzadzeniami. Podstawowym zadaniem Nagiosa jest
wykrywanie nieprawidłosci w działaniu monitorowanych zasobów. W przypadku, gdy
wartosc badanego parametru systemu przekroczy dopuszczalne normy, Nagios posia-da
mozliwosc wygenerowania ostrzezenia, które moze byc wysłane do administratora
systemu. Srodowisko posiada takze mozliwosc zdefiniowania działania, które zosta-nie
podjete w przypadku zajscia okreslonych warunków. Zdefiniowane działanie moze

27. 1.2. Przeglad istniejacych rozwiazan 25
prowadzic do automatycznej naprawy zasobu u którego wykryto nieoczekiwane za-chowanie.
Podobnie jak przedstawiony wczesniej Munin, takze Nagios zbudowany jest z głów-nego
serwera i agentów, których mozliwosci moga byc rozszerzane dzieki dodaniu
kolejnych rozszerzen. Zasada działania Nagiosa opiera sie na cyklicznym pomiarze
okreslonych parametrów. Na podstawie wyników, do parametru przyporzadkowany
jest odpowiedni status - OK, WARNING, CRITICAL lub UNKNOWN. Na podstawie wartosci
statusu Nagios pozwala na okreslenie stopnia dostepnosci usługi [?].
Nagios stanowi bardzo potezne narzedzie, które po odpowiednim skonfigurowaniu
zapewnia administratorowi pełna kontrole nad srodowiskiem, którym sie zajmuje.
Monit
Monit jest prostym narzedziem zarzadzajacym i monitorujacym procesy i systemy
plików systemów UNIX. Pozwala na zdefiniowanie automatycznych akcji majacych
na celu eliminacje wykrytych błedów. Monit jest narzedziem przeznaczonym do pracy
wewnatrz srodowiska lokalnego, istnieje takze wersja M/Monit, która pozwala na
prace w srodowisku rozproszonym. Monit działa na nizszym poziomie niz wymienione
wczesniej Munin i Nagios. Posiada mozliwosc pracy bezposrednio na działajacych
procesach, dzieki czemu mozliwa jest operacja restartu nieoczekiwanie zatrzymanej
usługi. Monit udostepnia takze mechanizm monitoringu zmian w systemie plików.
Funkcjonalnosc ta daje kontrole nad wykonywaniem zmian na plikach i katalogach,
które nie powinny byc modyfikowane [?].
Wsrodowiskach składajacych sie z wielu wezłów rozszerzeniem Monita jest M/Mo-nit.
M/Monit jest serwerem, który umozliwia wykorzystanie jako agentów działaja-cych
na wezłach instancji Monit.
Jednym z najbardziej przydatnych sposobów wykorzystania narzedzia takiego jak
Monit moze byc zdefiniowanie operacji ponownego startu usługi Secure Shell (SSH)
w przypadku jej zatrzymania i utraty dostepu do maszyny zdalnej.
1.2.2. Srodowiska wdrazania i instalowania
Zadaniem procesu wdrozenia (z ang. Provisioning process) jest instalacja okreslo-nego
oprogramowania oraz jego konfiguracja na podstawie informacji przechowywa-nych
w zewnetrznej bazie danych.
Vagrant
Vagrant jest srodowiskiem umozliwiajacym wdrazanie lekkich, przenosnych ma-szyn
wirtualnych opartych na technologii Oracle VirtualBox [?]. Vagrant wykorzy-stywany
jest głównie do budowy srodowisk deweloperskich. Oparcie na popularnym
narzedniu do wirtualizacji umozliwia uruchomienie identycznego srodowiska zarówno
na systemie Linux, Windows, jak i Mac OS X. Konfiguracja całego srodowiska kon-figurowanego
poprzez narzedzie zawarta jest w jednym pliku zwanym Vagrantfile
[?].
Vagrant nie jest rozwiazaniem przeznaczonym do srodowisk produkcyjnych, jed-nak
nie trudno przedstawic jego zalety na etapie budowy oprogramowania. Moze byc
stosowany zarówno przez pojedynczego programiste jak i duze zespoły deweloperów.

28. 1.2. Przeglad istniejacych rozwiazan 26
Pojedynczy uzytkownik moze wykorzystac Vagrant do budowy dla kazdego z re-alizowanych
przez siebie projektów pełnego, działajacego niezaleznie od uzywanego
systemu operacyjnego i bibliotek srodowiska. Wykorzystanie jednego srodowiska do
realizacji wielu projektów sprawdza sie w sytuacji, gdy róznia sie one zaleznosciami
na poziomie uzywanych bibliotek. Mozliwa jest wtedy instalacja wszystkich zalezno-sci.
Trudniejsza moze byc sytuacja, w której dwa projekty wymagaja róznych wersji
tej samej biblioteki, których wspólna instalacja jest skomplikowana a czasami nawet
niemozliwa. Stworzenie izolowanych srodowisk pozwala na odseparowanie zaleznosci,
a takze łatwe przywrócenie konfiguracji srodowiska w przypadku awarii.
Problemem towarzyszacym pracy w zespołach liczach wieksza ilosc osób jest utrzy-manie
spójnego srodowiska pomiedzy członkami zespołu. Dzieki uzyciu narzedzia ta-kiego
jak Vagrant, mozliwe jest zapewnienie, ze kazda osoba w zespole bedzie posia-dała
identyczne srodowisko zarówno jesli chodzi o zainstalowane biblioteki i aplikacje,
ich wersje jak i konfiguracje.
Sam Vagrant zapewnia funkcjonalnosc zarzadzania srodowiskami przechowanymi
w postaci maszyn wirtualnych. Srodowisko udostepnia takze mozliwosc przeprowadze-nia
procesu wdrozenia, do którego wykorzystane moga byc zewnetrzne systemu takie
jak Chef czy Puppet. Mozliwa jest takze konfiguracja z wykorzystaniem skyptów po-włoki
UNIX. Dla srodowisk wymagajacych specjalnego potraktowania przygotowano
opcje umozliwiajaca wykorzystanie własnego mechanizmu realizujacego Provisioning.
Chef
Chef jest narzedziem słuzacym do integracji duzych systemów zbudowanych w
strukturze chmurzastej. Załozeniem narzedzia jest zarzadzanie serwerami nie poprzez
wywoływanie polecen systemowych, ale poprzez pisanie kodu realizujacego obsługe
pozadanych zmian. Chef posiada mozliwosc wdrazania i konfiguracji maszyn na pod-stawie
wczesniej przygotowanych przepisów (z ang. recipes). Skrypty definiuja jakie
oprogramowanie powinno zostac zainstalowane, które usługi uruchomione i jaka po-winna
byc ich konfiguracja.
Wykorzystanie Chef powinno prowadzic do pełnej automatyzacji procesu wdra-zania
i konfiguracji srodowiska. Chef ułatwia skalowanie aplikacji na wieksza liczbe
maszyn, w tym celu wystarczy na nowych wezłach wykonac wczesniej sprawdzony
skrypt. W niektórych sytuacjach, konieczne jest takze powiadomienie srodowiska o
dodaniu nowych wezłów realizujacych zadania (np. skonfigurowanie load balancera
serwerów WWW) [?].
Puppet
Srodowiskiem posiadajacym podobne mozliwosci jak Chef jest Puppet. Główna
róznica pomiedzy tymi narzedziami jest posiadanie przez Puppet własnego deklara-tywnego
jezyka, w którym administrator definiuje przebieg procesu wdrozenia. Puppet
pozwala na zarzadzenie srodowiskami złozonymi z setek wezłów, które moga byc kon-figurowane
przy pomocy wczesniej przygotowanych skryptów [?].

29. 1.2. Przeglad istniejacych rozwiazan 27
Rysunek 1.9. Przykładowe wyniki wygenerowane przez Munin
zródło: http://munin.ping.uio.no/

30. 1.2. Przeglad istniejacych rozwiazan 28
Rysunek 1.10. Monit - informacje na temat systemu plików
zródło: http://mmonit.com/monit/screenshots/

31. 1.3. Podsumowanie 29
1.3. Podsumowanie
Na podstawie przeprowadzonych obserwacji dostepnosci narzedzi mozna stwier-dzic,
ze aktualnie brakuje rozwiazania realizujacego pełny proces zarzadzania we-złami
złozonego srodowiska rozproszonego. W przypadku monitoringu istnieje wiele
srodowisk o duzych mozliwosciach, ale nie pozwalaja one na przeprowadzenie rekonfi-guracji
całego srodowiska. Problem stanowi takze proces wdrazania konfiguracji. Na
tym obszarze dostepnosc oprogramowania nie jest duza, a istniejace rozwiazanie nie
zapewniaja separacji usług.
Celem realizacji systemu Cloudyna jest próba stworzenia srodowiska, które łaczy-łoby
proces wdrazania poczatkowej konfiguracji z monitoringiem srodowiska i wpro-wadzaniem
zmian do jego struktury. Srodowisko powinno takze zapewniac separacje
usług poprzez uzycie mechanizmu wirtualizacji.

32. Rozdział 2
Przeglad istniejacych rozwiazan
wirtualizacji i chmur obliczeniowych
Obserwowalnym trendem w przedsiebiorstwach, wykorzystujacych technologie in-formatyczne
jest optymalizacja kosztów sprzetu i infrastruktury. Pozwala na to wir-tualizacja.
W tym rozdziale zrealizowany zostanie przeglad technicznych typów wir-tualizacji.
Dodatkowym celem tego rozdziału jest przeglad powszechnie dostepnych i
wykorzystywanych modeli udostepniania zasobów chmury obliczeniowej.
2.1. Wirtualizacja
Wirtualizacja to tworzenie wirtualnej (w przeciwienstwie do rzeczywistej) wersji
czegos, np. platformy sprzetowej, systemu operacyjnego, urzadzenia dyskowego lub
zasobu sieciowego. [?]
Wirtualny zasób to pewna iluzja zasobu, implementowana przez system operacyjny
przez skonstruowanie logicznej reprezentacji prawdziwego zasobu. Mozemy wyróznic
wirtualne zasoby jakosciowe, np. dodatkowy interfejs sieciowy, lub wirtualne zasoby
ilosciowe, np. wieksza ilosc pamieci (pamiec wirtualna). [?]
Wirtualny zasób jest pewnego rodzaju abstrakcja. Ta abstrakcja jest implemento-wana
przez system operacyjny. Implementacja moze zostac zmieniona bez naruszenia
działania aplikacji korzystajacej z zasobu wirtualnego. Pozytywnie wpływa to tez na
przenosnosc aplikacji. Aplikacja moze byc przeniesiona na inny host oferujacy te sama
abstrakcje. Poczatkowo wirtualnymi zasobami były:
• Pamiec wirtualna - mechanizm pozwalajacy procesowi odnosic wrazenie pracy na
jednym, duzym, ciagłym obszarze pamieci, podczas gdy naprawde pamiec jest
nieciagła, pofragmentowana i moze byc przechowywana na wolnych urzadzeniach
dyskowych [?]
• Macierze dyskowe - przed uzytkownikiem ukryta jest realna struktura fizyczna
dysków, uzytkownik zapisuje do wirtualnego systemu plików, rozrzuconego miedzy
wiele fizycznych dysków, a czasem tez do wielu macierzy dyskowych rozproszonych
w sieci [?]
Wirtualny zasób po pewnym czasie zaczał ewoluowac do pojecia wirtualnej ma-szyny.
Poczatkowo motywacja było dostarczenie jednej maszyny, takiej aby kazdy z
uzytkowników mógł pracowac na wybranym przez siebie systemie operacyjnym.
Poczatki wirtualizacji siegaja roku 1972, kiedy International Business Machines
30

33. 2.1. Wirtualizacja 31
Rysunek 2.1. Wirtualne systemy operacyjne - dzisiaj
Corporation (IBM) wydał system operacyjny VM/370, pełna nazwa: Virtual Machine
Facility/370. Był to system operacyjny dopuszczajacy wirtualizacje na komputery
klasy mainframe. Co ciekawe, jako system oferujacy pełna wirtualizacje jest oferowany
do dzisiaj, jego aktualna nazwa brzmi IBM z/VM V6.2, a najnowsza rewizja miała
miejsce 13 lutego 2012 roku.
Czesto uzywana terminologia sa nazwy host i guest. Host jest własciwa, fizyczna
maszyna na której zachodzi wirtualizacja. Guest jest maszyna wirtualna.
2.1.1. Wirtualizacja sprzetowa
Termin “wirtualizacja sprzetowa” odnosi sie do wirtualizacji odbywajacej sie na
pewnym sprzecie realizowanej przez oprogramowanie hosta (ang. hypervisor), które
tworzy symulowane srodowisko komputerowe - maszyne wirtualna - dla goszczonego
oprogramowania. Goszczone oprogramowanie moze byc systemem operacyjnym lub
zwyczajna aplikacja. Oprogramowanie goscia wykonuje sie jakby było uruchomione
na fizycznym sprzecie, z paroma wyjatkami. Dostep do fizycznych zasobów (jak in-terfejsy
sieciowe, wyswietlacz, klawiatura, przestrzen dyskowa) jest udostepniany w
sposób bardziej restrykcyjny niz procesor czy pamiec hosta. Goscie zazwyczaj nie
moga uzyskiwac dostepu do okreslonych urzadzen peryferyjnych, albo moga wyko-nywac
na owych urzadzeniach tylko okreslone operacje. Wszystko zalezy od polityki
realizowanej przez system operacyjny hosta.
Ponizsza lista przedstawia podstawowe przypadki uzycia oraz korzysci wynikajace
z zastosowania wirtualizacji sprzetowej:
1. Wiele małych serwerów fizycznych mozna zastapic jednym wiekszym urzadze-niem,
w celu poprawy wykorzystania drogich podzespołów, jak np. Central
Processing Unit (CPU). Sprzet zostaje skonsolidowany, prowadzi to do uru-chomienia
wielu goszczonych systemów operacyjnych na jednej maszynie hosta.
(ang. Physical-to-Virtual transformation).
2. Konfiguracja i obserwacja maszyny wirtualnej z poziomu systemu operacyjne-go
hosta moze byc łatwiejsza, niz obserwacja fizycznego hosta. Moze to byc
przydatne przy rozwoju niskopoziomowego oprogramowania.

34. 2.1. Wirtualizacja 32
3. Wirtualna maszyne łatwo przeniesc z jednego fizycznego hosta na drugi. Moze
to byc przydatne, np. przy migracji architektury.
4. Błedy zachodzace w maszynie wirtualnej nie uszkadzaja hosta fizycznego, wiec
de facto jest to minimalizacja zakresu ryzyka, wynikajacego z wadliwego opro-gramowania.
Wirtualizacja ułatwia realizacje scenariusza, w którym srodowisko bedzie w stanie
samo soba zarzadzac bazujac na aktualnym postrzeganym obciazeniu, i niezbednych
zasobach. Scenariusz przewiduje, ze klienci beda rozliczani za zuzyta moc obliczenio-wa.
Czestym celem wirtualizacji jest centralizacja zadan zarzadczych przy jednocze-snej
poprawie skalowalnosci i ogólnej poprawie wykorzystania zasobów sprzetowych
[?]
Mozna wyróznic cztery rodzaje wirtualizacji sprzetowej:
1. Pełna wirtualizacja
2. Czesciowa wirtualizacja
3. Parawirtualizacja
4. Wirtualizacja na poziomie systemu operacyjnego
Pełna wirtualizacja
Pełna wirtualizacja wymaga aby kazda funkcjonalnosc realizowana przez sprzet
była mozliwa do wykonania w srodowisku dostarczanym maszynie wirtualnej. Do-tyczy
to pełnego zestawu instrukcji procesora, operacji wejscia/wyjscia, przerwan,
dostepu do pamieci i wszystkich innych elementów uzywanych na surowej maszynie,
których uzycie jest planowane na maszynie wirtualnej.Wtak stworzonym srodowisku,
kazde oprogramowanie mogace sie wykonac na surowej maszynie, moze zostac wyko-nane
na maszynie wirtualnej, w szczególnosci - system operacyjny. Najlepszym testem
jest próba uruchomienia systemu operacyjnego przeznaczonego do uruchomienia sa-modzielnego
(ang. stand-alone) we wnetrzu maszyny wirtualnej. Inne rodzaje wirtu-alizacji
udostepniaja mozliwosc uruchomienia tylko niektórych lub zmodyfikowanych
rodzajów oprogramowania - w szczególnosci, zazwyczaj nie dopuszczaja mozliwosci
uruchomienia systemu operacyjnego.
Na platformie x86 pełna wirtualizacja nie była mozliwa az do 2005-2006 roku,
kiedy wprowadzono rozszerzenia Advanced Micro Dynamics Virtualization (AMD-V)
oraz Intel Virtualization Technology (VT), pod nazwa kodowa Intel VT-x. Wczesniej
wielu producentów twierdziło, ze osiagneło pełna wirtualizacje. Do przykładów naleza:
1. Parallels Workstation [?]
2. VMWare Workstation [?]
3. VMWare Server [?]
4. VirtualBox [?]
Prawdziwym wyzwaniem dla pełnej wirtualizacji jest przechwycenie i symulacja
uprzywilejowanych operacji, jak np. operacje dyskowe, zarzadzanie pamiecia. Efek-ty
kazdej operacji, która zachodzi we wnetrzu maszyny wirtualnej, musza dotyczyc
tylko niej samej, konieczne jest zachowanie poufnosci przetwarzania. Wirtualne ope-racje
nie moga korzystac z zasobów (ani modyfikowac) innej maszyny wirtualnej,
programu zarzadzajacego ani sprzetu bezposrednio. Niektóre instrukcje maszynowe
moga byc uruchomione bezposrednio przez sprzet, poniewaz ich efekty zawieraja sie
bezposrednio w elementach kontrolowanych przez program zarzadzajacy, takich jak

35. 2.1. Wirtualizacja 33
lokacje pamieci czy rejestry arytmetyczne. Inne instrukcje, które “odwoływałyby sie
poza maszyne wirtualna”, lub mogace doprowadzic do przeciazenia hosta, nie moga
byc dopuszczone do bezposredniego wykonania, nalezy je odpowiednio przechwycic i
emulowac.
Oracle podjał udana próbe utworzenia systemu operacyjnego zorientowanego wy-łacznie
na uruchamianie wirtualnej maszyny Java, rozwiazanie nazwano JRockit Vir-tual
Edition. System JRockit Virtual Edition był uruchamiany bezposrednio pod kon-trola
Oracle VM Server [?]. Głównymi korzysciami z takiego rozwiazania sa: [?]
1. Wydajnosc - redukcja narzutu na istnienie systemu operacyjnego ogólnego za-stosowania
2. Uzycie pamieci - jadro JRockit Virtual Machine zajmuje jedynie kilka MB, co
pozwala na maksymalizacje pamieci przyznawanej maszynie wirtualnej Java
3. Prostota - Warstwa jadra zawiera jedynie operacje wymagane do uruchomienia
Java Virtual Machine (JVM)
4. Bezpieczenstwo - jest uzyskane poprzez ograniczenie punktów dostepu z ze-wnatrz.
Zdalny dostep jest jedynie mozliwy przez serwer Java SSH, nie dozwo-lone
jest uruchamianie natywnego kodu
Rozwiazanie ostatecznie porzucono w grudniu 2011 roku. Przyczyna były zbyt
wysokie koszty utrzymania dodatkowego zespołu odpowiedzialnego za rozwój systemu
operacyjnego. [?]
Czesciowa wirtualizacja
Wirtualizacja czesciowa zakłada wirtualizacje przestrzeni adresowej. Kazda wir-tualna
maszyna posiada własna, niezalezna, przestrzen adresowa. Przy wirtualizacji
czesciowej, całe systemy operacyjne nie moga byc uruchomione na maszynie goscia.
Czesciowa wirtualizacja jest duzo prostsza do zaimplementowania niz wirtualizacja
pełna. Nie wszystkie aplikacje moga pracowac w czesciowej wirtualizacji.
Parawirtualizacja
Parawirtualizacja prezentuje maszynie goscia interfejsy zblizone, ale nie identycz-ne
do lezacego nizej sprzetu. Intencja zmodyfikowanego interfejsu jest zredukowanie
czasu wykonania u goscia potrzebnego na przetwarzanie pewnych operacji, które sa
znaczaco ciezsze do wykonania w srodowisku wirtualnym, niz na realnym sprzecie. Pa-rawirtualizacja
definiuje specjalne uchwyty (ang. hooks), przez które maszyna goscia
moze wysyłac zadania, a host moze je potwierdzac, badz na nie odpowiadac.
Parawirtualizacja wymaga aby system operacyjny goscia był jawnie przystosowany
do korzystania z para-API. Tradycyjny system, który nie jest swiadom mozliwosci
bycia uruchomionym w srodowisku parawirtualnym, prawdopodobnie nie uruchomi
sie. Konieczne jest istnienie sterowników dla para-urzadzen.
Wirtualizacja na poziomie systemu operacyjnego
Wirtualizacja na poziomie systemu operacyjnego jest metoda wirtualizacji, w któ-rej
jadro systemu dopuszcza wiele odizolowanych instancji przestrzeni uzytkowni-ka,
zamiast jednej - klasycznie obecnej. Takie instancje, zwane czesto kontenerami,
Virtual Private Server (VPS), jails moga wygladac jak prawdziwy serwer, z punktu
widzenia ich własciciela. O systemach uniksowych o tym typie wirtualizacji moz-

36. 2.2. Chmura obliczeniowa 34
na myslec jak o zaawansowanej implementacji mechanizmu chroot, pozwalajacego
na uruchamianie procesów ze zmienionym katalogiem głównym (ang. root). Oprócz
mechanizmów izolacji, jadro zazwyczaj dostarcza mechanizmów limitowania i ksiego-wania
zasobów kontenerów, tak aby ograniczyc wpływ jednego kontenera na inne -
rezydujace na tym samym hoscie.
Typowym zastosowaniem wirtualizacji na poziomie systemu operacyjnego jest
swiadczenie usługi hostingu wirtualnego. W takim srodowisku jest przydatne aloko-wanie
skonczonej ilosci zasobów w srodowisku wzajemnie niezaufanych uzytkowników.
Istnieja implementacje pozwalajace na migracje kontenerów (na zywo), moze to
byc wykorzystane w celu równowazenia obciazenia.
Taka wirtualizacja charakteryzuje sie niewielkim narzutem, ale tez mniejszym po-ziomem
izolacji. Technologie wirtualizacji na poziomie systemu operacyjnego przed-stawiono
w dalszej czesci pracy w rozdziale 4.1.1
2.1.2. Inne rodzaje wirtualizacji
Wirtualizacja pulpitu zakłada odseparowanie logicznego pulpitu od maszyny fi-zycznej.
Jedna z form jest Virtual Desktop Infrastructure (VDI), uzytkownik zamiast
operowac bezposrednio urzadzeniami - myszka, klawiatura, wyswietlaczem, pracuje
na innym komputerze udostepniajacym te urzadzenia. Komputer udostepniajacy jest
podłaczony do docelowego komputera siecia Local Area Network (LAN), Wireless
Local Area Network (WLAN) lub nawet przez internet. Ten scenariusz zakłada ze
docelowy komputer pełni role serwera, udostepniajacego wirtualny pulpit jednocze-snie
wielu uzytkownikom. Przez wirtualny pulpit rozumiemy udostepnianie interfejsu
uzytkownika jednej z uruchomionych na serwerze maszyn wirtualnych. [?]
Maszyna wirtualna procesu, lub Maszyna wirtualna aplikacji to podejscie zakłada-jace
niezaleznosc aplikacji od platformy uruchomieniowej. Maszyna wirtualna procesu
dostarcza wysokopoziomowej abstrakcji. Abstrakcja zapewnia przenaszalnosc aplikacji
miedzy systemami operacyjnymi.
Przykładowe aplikacyjne maszyny wirtualne:
• JVM [?]
• Common Language Runtime - maszyna wirtualna frameworku Microsoft .NET [?]
• Parrot - maszyna wirtualna wielu jezyków interpretowalnych, np. Perl 6, Lua [?]
Kolejnym rodzajem wirtualizacji jest pamiec wirtualna. Dla uruchamianych pro-cesów
pamiec wirtualna stwarza abstrakcje ciagłego bloku pamieci, odizolowanego od
fizycznej pamieci.
2.2. Chmura obliczeniowa
Istnieje wiele definicji chmury obliczeniowej. Ponizej przytoczono dwie z nich.
Chmura obliczeniowa (ang. cloud computing) to sposób uruchamiania oprogra-mowania
oraz przechowywania powiazanych z nim danych w centralnym systemie
komputerowym i dostarczanie klientom, badz innym uzytkownikom dostepu do tego
oprogramowania przez internet. [?]
Chmura obliczeniowa to przeniesienie pewnych zasobów (serwerów, danych, apli-

37. 2.2. Chmura obliczeniowa 35
kacji) z przedsiebiorstwa, badz jego własnej serwerowni w inne miejsce. Moze to byc
sprzet, maszyna wirtualna, dane, badz cała aplikacja. [?]
Istnieje wiele modeli udostepniania chmury obliczeniowej. Modele, w kolejnosci od
najprotszego przedstawiono na diagramie 2.2
Rysunek 2.2. Modele chmur obliczeniowych, zródło: [?]
2.2.1. Kolokacja
Kolokacja zakłada udostepnienie miejsca na serwer w serwerowni, energie elek-tryczna,
klimatyzacje oraz łacze internetowe. Sprzet, zabezpieczenia, zapory sieciowe
(ang. firewall), system operacyjny, oprogramowanie i wszystkie aplikacje leza w gestii
klienta.
2.2.2. Infrastructure-as-a-Service (IaaS)
IaaS to model w którym operator chmury dostarcza komputery - jako fizyczne lub
coraz czesciej wirtualne maszyny. Oryginalnie model ten nazywano Hardware-as-a--
Service [?] Oprócz komputerów dostarczane moga byc usługi infrastrukturalne np.
load balancery, firewalle, urzadzenia dyskowe, urzadzenia sieciowe. W zaleznosci od
rozległosci i zastosowania infrastruktury IaaS moze korzystac z sieci internet lub wy-korzystywac
prywatne sieci do transferu danych miedzy jednostkami. W rozwiazaniu
tym klient jest odpowiedzialny za zainstalowanie i utrzymywanie systemu operacyj-nego
oraz kompletu aplikacji koniecznych dla realizacji jego celów. Całosc utrzymania
i aktualizacji systemu ciazy na kliencie.
Typowym modelem rozliczeniowym jest rozliczanie za zuzyte, badz zaalokowane
zasoby. Klient na fakturze widzi rozbicie zuzycia zasobów. Przykładowe zasoby i miary
rozliczeniowe sa zaprezentowane w tabeli 2.1
Przykładowych dostawców IaaS prezentuje tabela 2.2

38. 2.2. Chmura obliczeniowa 36
Tabela 2.1. Miary rozliczeniowe w IaaS
Zasób Miara zuzycia
Moc obliczeniowa za godzine uzycia procesora
Transfer danych do infrastruktury za GB odebranych danych
Transfer danych z infrastruktury za GB wysłanych danych
Zadania Put/List za 1 milion zadan
Przestrzen za 1 GB danych
Transfer z przestrzeni za 1 GB danych pobranych z przestrzeni
Transfer do przestrzeni za 1 GB danych wysłanych do przestrzeni
Zadania I/O za 1 milion zadan Input/Output
Tabela 2.2. Dostawcy usług IaaS
Dostawca Nazwa usługi
Amazon Amazon Web Services
ServePath GoGrid
Rackspace The Rackspace Cloud
2.2.3. Platform-as-a-Service (PaaS)
PaaS jest modelem udostepniania chmury obliczeniowej w którym dostawca do-starcza
platforme obliczeniowa oraz stos rozwiazan technologicznych jako usługe. PaaS
dostarcza srodowisko uruchomieniowe dla aplikacji. Oznacza to ze nie ma konieczno-sci
konfiguracji, instalacji i budowania całej wirtualnej maszyny. Wystarczy jedynie
wysłac do chmury kod aplikacji.
Zapewnianie skalowalnosci nie wymaga od klienta własnego zarzadzania infra-struktura,
konieczne jest jedynie zamówienie ilosci jednostek obliczeniowych koniecz-nych
do wytrzymania spodziewanego obciazenia. Kod aplikacji jest automatycznie
wdrazany na okreslona ilosc maszyn.
Ma to jednak swoje wady, klient jest dosc mocno zwiazany z konkretna platforma i
musi programowac konkretnie pod dostawce platformy. Oznacza to, ze ciezko jest zmi-growac
istniejace juz systemy pod PaaS, jesli nie załozono tego przy ich projektowaniu
[?]
Rozliczanie usług jest bardzo zblizone do modelu IaaS.
Dostawców usług PaaS przedstawiono w tabeli 2.3
Tabela 2.3. Dostawcy usług PaaS
Dostawca Nazwa usługi Srodowisko uruchomieniowe
Google Google App Engine Java Runtime Environment, Python Runti-me
Environment
Microsoft Azure Services Platform Windows Azure
Salesforce Force.com Apex Code, Visualforce

39. 2.3. Podsumowanie 37
2.2.4. Software-as-a-Service (SaaS)
Wmodelu SaaS cała aplikacja jest dostepna na zadanie i zarzadzana przez dostaw-ce
SaaS. Aplikacja istnieje w chmurze i moze byc dostepna z dowolnego miejsca dla
klienta. Klientem SaaS jest wiec uzytkownik koncowy. Zauwazmy, ze jest to róznica w
stosunku do PaaS i IaaS gdzie klientem był twórca oprogramowania. Dostawca SaaS
jest jednoczesnie odpowiedzialny za dostarczanie aplikacji uzytkownikowi koncowemu
jak i za utrzymanie całej infrastruktury na odpowiednim poziomie. Dostawca SaaS
moze wykorzystywac innych dostawców IaaS lub PaaS do zapewnienia odpowiedniej
mocy obliczeniowej. Dostawca SaaS jest jednoczesnie zarzadca aplikacji.
Typowa jednostka rozliczeniowa jest tu prawo dostepu uzytkownika do usługi w
danym okresie czasu. [?]
Dostawców usług SaaS przedstawiono w tabeli 2.4
Tabela 2.4. Dostawcy usług SaaS
Dostawca i Nazwa usługi Zastosowanie
Microsoft - Online Services Aplikacje biurowe, synchronizacja dokumentów
Office, usługa Live Meeting słuzaca do prezen-tacji
i spotkan
Salesforce - SalesForce CRM Oprogramowanie CRM, typowe dla działów
handlowych w firmach
IBM - Lotus Live Zestaw oprogramowania biurowego
37signals LLC - Highrise Oprogramowanie CRM, typowe dla działów
handlowych w firmach
37signals LLC - Basecamp Platforma do prowadzenia projektów
Lucid Software Inc. - Lucidchart Platforma do tworzenia diagramów, wykresów,
zakładajaca współprace miedzy uzytkownikami
2.2.5. Software plus Services (S+S)
S+S to model bedacy połaczeniem klasycznego oprogramowania biurowego z usłu-gami
udostepnianymi w chmurze na zasadzie SaaS. S+S daje uzytkownikowi mozli-wosc
korzystania z nieograniczonych technologiami World Wide Web (WWW), przez
co bardziej rozbudowanych aplikacji po stronie klienckiej. Warto zauwazyc ze model
S+S daje równiez mozliwosc pracy bez połaczenia internetowego (ang. offline). Jest to
wazne w przypadku mobilnych pracowników firmy, którzy nie sa cały czas podłaczeni
do internetu. Termin S+S jest mocno promowany przez Microsoft, który deklaruje
ze przeznacza olbrzymie fundusze na migracje dotychczasowych rozwiazan do modelu
S+S, np. Microsoft Exchange. [?]
2.3. Podsumowanie
W rozdziale szczegółowo omówiono pojecia zwiazane z wirtualizacja. Skupiono
sie głównie na wirtualizacji sprzetowej. Opisane zostały jej cztery typy, od pełnej

40. 2.3. Podsumowanie 38
wirtualizacji sprzetowej poczawszy, na wirtualizacji na poziomie systemu operacyjnego
skonczywszy.
Dodatkowo opisano inne znaczenia wirtualizacji, takie jak: wirtualizacja pulpitu,
wirtualizacja pamieci operacyjnej, maszyna wirtualna aplikacji.
W dalszej czesci rozdziału przedstawiono trendy przedsiebiorstw wynikajace z za-istniałych
mozliwosci wirtualizacyjnych. Scharakteryzowano obliczenia w chmurze.
Dokonano przegladu modeli udostepniania usług w chmurze, przechodzac kolejno
przez: kolokacje, IaaS, PaaS, SaaS, S+S.
Rozdział ten zbudował zaplecze informacyjne, dajace mozliwosc podjecia własci-wych
decyzji architektonicznych przy budowie systemu Cloudyna.

41. Rozdział 3
Proponowana architektura systemu
Na bazie rozwazan z rozdziału 1 oraz na podstawie istniejacych rozwiazan, przed-stawionych
w rozdziale 2 zdecydowano sie przedstawic projekt innowacyjnego syste-mu
dbajacego o wysoka dostepnosc dostarczanych przez siebie usług. Nazwa systemu
został wybrany termin “Cloudyna”. System wpisuje sie w paradygmat udostepniania
chmury obliczeniowej PaaS, jego budowa opiera sie na uzyciu wirtualizacji na poziomie
systemu operacyjnego.
3.1. Motywacja i cele projektowe
Przedstawione w rozdziale 1 istniejace rozwiazania usług sieciowych oraz srodowi-ska
monitoringu potwierdzaja obserwacje, ze nie istnieje kompletne narzedzie umoz-liwiajace
zarówno wstepna konfiguracje, monitoring jak i rekonfiguracje dowolnych
usług pracujacych w rozbudowanej architekturze sieciowej. Istniejace srodowiska mo-nitorujace
pozwalaja na złozony proces kontroli parametrów i stanu usług, jednak ich
mozliwosci w przypadku wystapienia stanu niepozadanego sa mocno ograniczone.Wy-stapienie
awarii usługi moze zostac zaraportowane, ale jej eliminacja wymaga reakcji
ze strony administratora srodowiska. Takze narzedzia umozliwiajace automatyczne
zestawienie złozonej architektury sieciowej nie udostepniaja prostych mechanizmów
odpowiedzialnych za reakcje na zachodzace zmiany.
Celem realizacji systemu Cloudyna było stworzenie dowodu koncepcji (ang. Pro-of
of Concept) rozwiazania umozliwiajacego zarówno konfiguracje usług, ich rozbu-dowany
monitoring a takze rekonfiguracje w przypadku awarii wezła sieci lub jego
nadmiernego obciazenia. W ramach pracy Dyplomanci zrealizowali kompletny szkie-let
srodowiska realizujacego przedstawione powyzej cele oraz zapewnili obsługe kilku
przykładowych usług sieciowych.
3.2. Wymagania stawiane systemowi Cloudyna
Realizowany system powinien realizowac cztery podstawowe zadania:
• automatyczna konfiguracje poczatkowa srodowiska
• monitoring usług i wykrywanie sytuacji niepozadanych
• dynamiczna rekonfiguracje w odpowiedzi na aktualny stan systemu
39

42. 3.2. Wymagania stawiane systemowi Cloudyna 40
• persystencje danych i stanu w warstwie persystencji
3.2.1. Automatyczna konfiguracja srodowiska
Zadaniem, z którym realizowane srodowisko musi zmierzyc sie w pierwszej kolejno-sci
jest wykonanie konfiguracji poczatkowej srodowiska. Do ram realizacji obsługi tej
funkcjonalnosci zalicza sie zarówno załadowanie konfiguracji bazowej przechowanej w
zewnetrznym mechanizmie persystencji, rozesłanie przez zarzadce zlecen konfiguracji
usług na poszczególnych wezłach srodowiska jak i instalacje i konfiguracje usług na
wezłach. Proces konfiguracji konczy sie w momencie uruchomienia usług na wezłach
dostepnych w srodowisku oraz podłaczenia monitoringu tychze usług do wezłów ko-ordynujacych
prace systemu.
3.2.2. Niezawodnosc i monitoring usług
Po wykonaniu konfiguracji bazowej realizowany system powinien przechodzic w
stabilny stan monitoringu. Zadaniem warstwy agentowej hostów i kontenerów oraz
warstwy serwisowej systemu w stanie stabilnym jest monitorowanie parametrów ho-stów
i usług oraz ich przesyłanie do warstwy zarzadzajacej srodowiskiem. Rola war-stwy
zarzadzajacej w omawianym stanie jest nasłuch na informacje napływajace z
kontrolowanych wezłów oraz podjecie zdefiniowanej akcji w przypadku wykrycia sta-nu
niepoprawnego. Zapewnienie niezawodnosci wymaga takze mozliwosci okreslenia
zachowania systemu w sytuacji, gdy kontrolowany wezeł przerwie informowanie o
swoim stanie.
3.2.3. Dynamiczna rekonfiguracja, mechanizm migracji
Głównym elementem odrózniajacym system Cloudyna od istniejacych rozwiazan
jest mozliwosc zdefiniowania akcji podejmowanych w przypadku wykrycia okreslonego
stanu usługi. Projekt systemu zakłada zakłada reakcje na zajscie dowolnego zdarze-nia,
którym moze byc np. awaria, nadmierne obciazenie badz tez spadek obciazenia.
W przypadku zajscia jednej z wymienionych sytuacji, system powinien udostepniac
mozliwosc rozproszenia usługi na dodatkowe wezły dostepne w sieci. W razie zajscia
awarii badz tez utraty komunikacji z czescia srodowiska, system Cloudyna pozwala na
migracje usługi na inny wezeł. Szczególnie istotne jest zachowanie adresacji logicznej
usług.
3.2.4. Persystencja danych i stanu
Realizacja srodowiska zapewniajacego dostepnosc usług musi zakładac mozliwosc
wystapienia awarii na kazdej z warstw systemu. Utrata wezłów obsługujacych po-szczególne
usługi moze byc naprawiona dzieki wykryciu niepoprawnego funkcjono-wania
przez monitoring oraz przeprowadzeniu rekonfiguracji. Takie zachowanie nie
moze byc podjete dla wezłów koordynujacych prace całego srodowiska, w przypadku
których konieczne jest zachowanie aktualnego stanu srodowiska - liczby instancji i lo-kalizacji
poszczególnych usług a takze informacji na temat biezacej konfiguracji usług.
W zwiazku z mozliwoscia uszkodzenia wezłów zarzadzajacych srodowiskiem konieczne
jest zapewnienie persystencji stanu systemu.

43. 3.2. Wymagania stawiane systemowi Cloudyna 41
3.2.5. Przypadki uzycia
Wymagane jest aby system realizował nastepujace przypadki uzycia przedstawione
na diagramach 3.1, 3.2 oraz 3.3.
Rysunek 3.1. Diagram przypadków uzycia - monitoring
Rysunek 3.2. Diagram przypadków uzycia - warstwa zarzadcza

44. 3.3. Architektura projektu 42
Rysunek 3.3. Diagram przypadków uzycia - rekonfiguracja
3.3. Architektura projektu
Przy projekcie tej skali niezbedne jest znaczne zredukowanie złozonosci problemu,
którego rozwiazanie jest celem projektu. Srodkiem który moze tu znacznie pomóc jest
wybór własciwej architektury.
Poprzez architekture rozumiemy wszystko co bedzie implementowane w ramach
projektu dyplomowego, w odróznieniu od tego co bedzie dostarczone z zewnatrz i
stanowiło swoisty kontekst systemu - jego srodowisko (opisane w rozdziale 3.4)
Faktem pozostaje równiez niemoznosc istnienia architekury bez jej srodowiska.
Dopuszczalna jest komunikacja z elementami srodowiska z kazdego elementu archi-tektury.
Własciwa architektura to taka, która w mozliwie najwierniejszy i najpełniejszy
sposób zrealizuje cele stawiane systemowi Cloudyna (cele opisano w rozdziale 3.2).
Kolejnym waznym czynnikiem jest mozliwosc realizacji rozbudowy systemu o kolejne
usługi, czy tez wprowadzanie pewnych zmian na poziomie istniejacych usług. Moze-my
tu mówic o łatwej pielegnacji systemu. Proponowana architektura musi znacznie
wspierac system w jednym z jego głównym zadan tj. stabilnosci i niezawodnosci.
Docelowa architekture widzimy na najwyzszym poziomie ogólnosci jako trójwar-stwowa
• warstwa zarzadzajaca (opisana w rozdziale 3.3.1)
• warstwa agentowa hostów i kontenerów (opisana w rozdziale 3.3.2)
• warstwa serwisowa (opisana w rozdziale 3.3.3)
Definicje pojec:
1. kontener - lekka maszyna wirtualna, wirtualizowana na poziomie systemu ope-racyjnego
2. load balancer - usługa dajaca mozliwosc rozproszenia pewnego obciazenia na
wiele wezłów obliczeniowych, pełni role dyspozytora zadan klienta
3.3.1. Warstwa zarzadzajaca
Ponizej zdefiniowano obszary odpowiedzialnosci tej czesci architektury:
• pobieranie konfiguracji

45. 3.3. Architektura projektu 43
Rysunek 3.4. Warstwy systemu
• zapewnianie instalacji bazowej konfiguracji
• przydzielanie adresów usług
• odbieranie powiadomien z monitoringu
• odpowiednia reakcja na powiadomienia z monitoringu
• kolejkowanie zlecen w warstwie agentowej
— dołozenia / instalacji wezła obliczeniowego
— odjecia / deinstalacji wezła obliczeniowego
— rekonfiguracji wezła obliczeniowego
— obsługi awarii hosta
• zapewnianie własciwego modelu obsługi zlecen active-passive
• reakcja na zlecenia złozone przez administratora systemu
• logowanie zmian (ang. audit trail)
Tematy wymagajace bardziej złozonej logiki opisano ponizej.
Zapewnianie instalacji bazowej konfiguracji Bazowa konfiguracja to konfigura-cja
usług zastana przez zarzadce w momencie jego uruchomienia. Po uruchomieniu

46. 3.3. Architektura projektu 44
nastapi odczyt bazowych parametrów usług z warstwy persystencji oraz ilosci zamó-wionych
kontenerów na kazda z usług kazdej aplikacji. Po elekcji danego zarzadcy
na zarzadce aktywnego (zgodnie z algorytmem opisanym w rozdziale 3.3.1) zarzadca
dokona wstepnej konfiguracji aplikacji i serwisów. Hosty docelowe wybierane beda
losowo, przy zachowaniu ograniczen majacych na celu optymalizacje wykorzystania
zasobów.
Przydzielanie adresów usług W architekturze Cloudyna dopuszczalne bedzie sto-sowanie
dwóch typów adresów dla usług. Adresy konkretne przydzielane sa bez do-konywania
dodatkowej logiki. Adresy nieskonkretyzowane (tzn. niosace tylko czesc
informacji, np. o klasie adresowej) beda dynamicznie przydzielane przez system. Za-rzadca
bedzie odpowiedzialny za przyznanie danej usłudze unikalnego, niezajetego
przez inne instancje adresu.
Odpowiednia reakcja na powiadomienia z monitoringu Zakładamy, ze cała
logika dotyczaca przetwarzania powiadomien z monitoringu bedzie zrealizowana w
tej warstwie. Warstwa serwisów odpowiada za wysyłanie powiadomien.
Z racji współistnienia wielu instancji tej samej usługi, np. wielu serwerów usługi
WWW w obrebie jednej aplikacji, do warstwy zarzadzajacej wpływac bedzie nadmia-rowa
ilosc powiadomien sygnalizujacych koniecznosc zwiekszenia mocy obliczeniowej
danej usługi.
Na krótko po instalacji/deinstalacji instancji konkretnej usługi, cała usługa moze
byc w tzw. stanie miekkim (ang. fresh-soft-state). Moze to byc skutkiem tego ze load
balancer nie przełaczył jeszcze odpowiedniej czesci obciazenia na nowo powstały wezeł
obliczeniowy
Zarzadcy musza filtrowac napływajace zlecenia tak aby nie doprowadzic do in-stalacji
nadmiernej ilosci wezłów bez potrzeby. Zrealizowane to zostanie za pomoca
bazy stanów usług za pomoca usług persystencji (opisanych w podrozdziale 3.4.1) .
Zarzadca w momencie otrzymania dowolnego zlecenia powinien skonsultowac z war-stwa
abstrakcji usług persystencji to zlecenie pod katem istnienia zlecen bedacych w
konflikcie, przez co rozumiane sa:
• nadmiarowe zlecenia doinstalowania usługi
• nadmiarowe zlecenia odinstalowania usługi
• jednoczesne zlecenie instalacji i deinstalacji tej samej usługi w obrebie tej samej
aplikacji.
• zakonczone zlecenia, jednakze pozostajace wciaz w stanie swiezym miekkim
Obsługa zlecen active-passive Aktywny bedzie jeden serwer zarzadczy jak w
przypadku usług persystencji (zob. podrozdział 3.4.1). Zostanie uzyte teoretyczne
zaplecze algorytmu rozwiazywania konfliktów (zob. sekcje 1.1.1).
Przewidywane jest istnienie kilku serwerów zarzadczych, które beda w stanie prze-jac
działanie w razie awarii głównego serwera (serwera który bedzie posiadał najwiek-szy
priorytet).
Sugerowanym rozwiazaniem jest tutaj rozwiazanie heartbeat, czyli regularne no-tyfikacje
rozsyłane pomiedzy serwerami zarzadczymi, których efektem bedzie elekcja
aktywnego serwera zarzadczego.

47. 3.3. Architektura projektu 45
Elekcja lidera jest problemem znanym i rozwazanym w wielu działach informa-tyki.
Polega na wyborze jednego procesu jako organizatora pewnego zadania które
jest rozproszone na wielu wezłach. Przystepujac do elekcji konkurujace procesy nie
sa swiadome stanu innych konkurujacych wezłów, wiedza jednak o mozliwosci ich
istnienia. Po wykonaniu iteracji algorytmu elekcji kazdy wezeł jest swiadom faktu,
który wezeł został wybrany jako lider, i na tej podstawie moze podejmowac decyzje
o podjecie badz odmowie realizacji zlecen.
Stosowne bedzie uzycie algorytmu token ring election, majacego swe korzenie w
sieciach TokenRing. [?]
Istnieje jedna lista definujaca wszystkie hosty, zawierajaca priorytety poszczegól-nych
wezłów. Kazda maszyna ma dostep do tej listy, jest ona przechowywana w kon-figuracji.
Co kilka sekund kazdy host inicjuje wysyłke pakietu w pierscieniu, i przesyła sfor-mowany
pakiet do kolejnego hosta. Jesli kolejny host jest niedostepny, jest on pomijany
i wysyłka nastepuje do nastepnego hosta w pierscieniu. W przypadku nieobecnosci
wszystkich innych hostów, nadawca i odbiorca jest jednoczesnie ten sam host.
Algorytm musi reagowac na zmiany zachodzace w pierscieniu. Załozenia dotyczace
poszczególnych zdarzen przedstawiono ponizej. Zdarzenia opisano z punktu widzenia
jednego z hostów bedacego członkiem pierscienia.
1. Pojawienie sie silniejszego hosta niz koordynator
• Host bedacy aktywnym zrzeka sie uprawnien na rzecz nowego hosta, pozo-stałe
hosty bez zmian. Nowy host zostaje aktywnym
2. Pojawienie sie słabszego hosta niz koordynator
• Wszystkie hosty bez zmian. Nowy host zostaje pasywnym.
3. Awaria hosta nie bedacego koordynatorem
• Wszystkie hosty bez zmian
4. Awaria hosta bedacego koordynatorem
• W kolejnym przebiegu algorytmu elekcji, zapada decyzja o wyborze najlep-szego
hosta o priorytecie mniejszym od byłego koordynatora.
Reakcja na zlecenia administratora W pracy nie ograniczono sie do konkretnego
interfejsu uzytkownika. Zaimplementowane zostały jednak mechanizmy umozliwiajace
reakcje warstwy zarzadczej na podstawie zmian zachodzacych w warstwie persystencji.
Aktywny zarzadca bedzie obserwował warstwe persystencji pod katem pojawiajacych
sie zlecen. W przypadku pojawienia sie takiego obiektu bedzie on transformowany na
odpowiednie zlecenie i rozsyłany do warstwy agentowej.
Logowanie zmian - audit trail System implementuje logowanie wszystkich zmian
zachodzacych w jego architekturze.Wszczególnosci pozadane jest zapisywanie wszyst-kich
zlecen składanych w systemie, zarówno tych zakonczonych powodzeniem jak i
porazka. Nalezy równiez przechowywac wszystkie zebrane parametry monitoringu,
które zostana odebrane za pomoca powiadomien wysyłanych przez monitoring.
3.3.2. Warstwa agentowa hostów i kontenerów
Warstwe ta mozna dalej podzielic na dwie podwarstwy. Zastosowano podejscie
potraktowania kontenera (lekkiej maszyny wirtualnej) jako usługi, przez co mozliwe

48. 3.3. Architektura projektu 46
bedzie maksymalne ponowne wykorzystanie pewnych elementów kodu, jak np. konfi-guracja,
monitorowanie.
Okreslenie warstwa agentowa hostów odnosi sie do podwarstwy hostów warstwy
agentowej, a okreslenie warstwa agentowa kontenerów odnosi sie do podwarstwy kon-tenerów
warstwy agentowej.
Podwarstwa hostów
Dotyczy agentów, którzy odpowiadaja za konfiguracje kontenerów oraz monitorów
zbierajacych jedynie informacje o hoscie bez rozbicia na konkretne usługi.
Ponizej zdefiniowano obszary odpowiedzialnosci podwarstwy hostów
• realizacja zlecen z kolejki pochodzacych od warstwy zarzadczej (zob. sekcje 3.3.1)
• instalacja/deinstalacja kontenerów
• dokonanie zmian w konfiguracji z ograniczeniem do usług kontenerowych.
• zbieranie informacji o aktualnym stanie hosta
• zbieranie informacji o usługach z podwarstwy kontenerów
• przesyłanie informacji o stanie do warstwy zarzadczej (zob. sekcje 3.3.1)
• instalacja monitorów kontenera jako element procesu konfiguracji kontenera
Tematy wymagajace bardziej złozonej logiki opisano ponizej.
Realizacja zlecen z kolejki pochodzacych od warstwy zarzadczej Po stronie
agentów implementowana jest synchronizowana kolejka, do której moze dopisywac
naraz wiele zarzadców (np. w momencie przepiecia w ringu), bez utraty spójnosci.
Kazdy agent czeka w nieskonczonej petli na pojawienie sie nowego zlecenia do ob-sługi.
Zlecenia beda obsługiwane bez aktywnego czekania, za pomoca mechanizmów
synchronizacji watków w wybranym jezyku programowania.
Instalacja/deinstalacja kontenerów Kontenery (lekkie maszyny wirtualne) beda
instalowane przygotowanym wczesniej odpowiednim skryptem wsadowym. Jako ze
na poziomie hosta kontenery dziela jeden system plików mozliwe bedzie dokonywa-nie
operacji klonowania kontenerów z maszyny bazowej, przy niewielkich zmianach
umozliwiajacych personalizacje kazdego z kontenerów, tj. mozliwosc przystosowania
kontenera do pełnienia funkcji usługi webowej, baz danych badz usługi typu load
balancer.
Zbieranie informacji o aktualnym stanie hosta Zaimplementowane zostana me-chanizmy
zbierania informacji na temat niektórych parametrów fizycznych maszyny
fizycznej, jak np. obciazenie (system load) czy zuzycie pamieci.
Zbieranie informacji o usługach z podwarstwy kontenerów Warstwa ta słuzy
dodatkowo jako platforma wymiany miedzy warstwa nizsza tj. podwarstwa konte-nerów
a warstwa zarzadcza. Wykorzystany zostanie mechanizm notyfikacji. Agent
z podwarstwy hostów rejestruje sie w agencie z podwarstwy kontenerów. Nastepnie
agent z podwarstwy kontenerów wysyła notyfikacje w góre, do agenta z podwarstwy
hostów.

49. 3.3. Architektura projektu 47
Podwarstwa kontenerów
Dotyczy agentów, które sa zainstalowane na kontenerach za pomoca agentów z
podwarstwy hostów.
Ponizej zdefiniowano obszary odpowiedzialnosci podwarstwy kontenerów
• realizacja zlecen z kolejki pochodzacych od warstwy zarzadczej (opisanej w roz-dziale
3.3.1)
• dokonanie zmian w konfiguracji z ograniczeniem do konkretnych usług np. usługa
webowa, usługa baz danych
• zbieranie informacji o aktualnym stanie usługi
• przesyłanie informacji o stanie do podwarstwy hostów warstwy agentowej
• instalacja monitorów usługi jako element procesu konfiguracji usługi
Tematy wymagajace bardziej złozonej logiki opisano ponizej. Czesc opisów pomi-nieto
z uwagi na ich tozsamosc z opisami zawartymi w opisach podwarstwy konte-nerów.
Dokonanie zmian w konfiguracji z ograniczeniem do konkretnych usług np.
usługa serwera WWW, usługa serwera baz danych Za pomoca skryptów wsa-dowych
systemu Linux instalowane sa odpowiednie usługi i ich zaleznosci. Po bazowej
instalacji nastepuje konfiguracja usług, zgodnie z detalami zawartymi w mechanizmie
persystencji. Detalami moga byc np. nazwa obsługiwanego hosta, parametry logowa-nia,
katalog zródłowy projektu.
Zbieranie informacji o aktualnym stanie usługi Zbierane parametry zazwyczaj
pochodza z wewnetrznych statystyk usług udostepnianych przez sama usługe, jak np.
ilosc zadan na sekunde, lub ilosc pracujacych jednoczesnie watków przetwarzajacych
serwera WWW.
Przesyłanie informacji o stanie do warstwy agentowej poziomu hostów
Agent zbiera konkretne parametry danej usługi i przesyła je do zarejestrowanych
w nim agentów podwarstwy hostów.
Wtej warstwie nie wystepuje zadna replikacja czy tez zabezpieczanie pojedynczego
hosta. Mechanizmy wykrywajace awarie maszyny lub awarie usługi beda zainstalowa-ne
w warstwie zarzadczej hostów.
3.3.3. Warstwa serwisowa
Ponizej zdefiniowano obszary odpowiedzialnosci tej czesci architektury:
• wykonywanie logiki biznesowej
• dostarczanie wewnetrznych mechanizmów monitoringu
Tematy wymagajace bardziej złozonej logiki opisano ponizej.
Wykonywanie logiki biznesowej Jest to miejsce przetwarzania własciwych zadan
i zadan aplikacyjnych. W warstwie serwisowej dokonuje sie prawdziwa praca instalo-wanych
usług, np. konkretne zadania pewnych serwisów webowych.
Dostarczanie wewnetrznych mechanizmów monitoringu Od warstwy tej ocze-kuje
sie dostarczania podstawowych mechanizmów odczytu okreslonych parametrów.

50. 3.4. Srodowisko projektu 48
Podwarstwa kontenerów warstwy agentowej potrzebuje znac sposoby odczytu moni-torowanych
parametrów
3.4. Srodowisko projektu
Implementowana przez system architektura musi byc zanurzona w odpowiednim
srodowisku umozliwiajacym działanie systemu.
3.4.1. Mechanizm persystencji danych
Przez ten mechanizm rozumiemy zapisywanie pozadanej przez uzytkownika kon-figuracji
oraz przechowywanie informacji o aktualnej konfiguracji hostów, maszyn i
serwisów. W ramach pracy mechanizm persystencji jest równiez nazywany warstwa
persystencji.
Na tym poziomie nie jest planowana własna implementacja rozwiazan zapewnia-jacych
ciagła dostepnosc oraz bezpieczenstwo danych. Ze wzgledu na popularnosc
rozwiazan i ich dopracowanie zostanie zastosowana relacyjna baza danych lub serwer
usługi katalogowej. Zastosowany zostanie model pasywny/aktywny tj. przewidywane
jest jednoczesne uzycie tylko jednego serwera. Drugi lub wiecej serwerów beda słuzyły
jako maszyny zapasowe, wykorzystywane w razie awarii aktywnego serwera. Dane z
serwera aktywnego beda natychmiast replikowane do serwera (serwerów) pasywnych.
Warstwa ta bedzie jedynym miejscem gdzie bedzie przechowywany stan systemu.
Pozostałe warstwy w załozeniach sa w stanie byc obudzone w dowolnym momencie i
posiadac komplet informacji na temat zadanej oraz aktualnej konfiguracji systemu.
3.4.2. Wymagania dotyczace sieci
W celu sprawnego działania systemu konieczna bedzie komunikacja Internet Pro-tocol
version 4 (IPv4) miedzy:
• zarzadcami
• zarzadcami i agentami
• agentami podwarstwy hostów oraz odpowiadajacymi im agentami podwarstwy kon-tenerów
• agentami podwarstwy kontenerów oraz punktami dostepu do wewnetrznych para-metrów
monitorowanych usługi.
Konieczne bedzie równiez dopuszczenie ruchu sieciowego pomiedzy hostami, za-rzadcami
oraz wszystkimi routerami pomiedzy, co umozliwi dynamiczne zestawia-nie
tras na podstawie protokołów routingu opisanych w odpowiednim rozdziale (zob.
4.3.3).
Nie bedzie duzych ograniczen co do puli adresów niedostepnych dla usług. Zare-zerwowane
pule adresowe to pule zarzadcze okreslonych hostów oraz pule słuzace do
komunikacji zarzadca-host. Rozmiar zarezerwowanej puli bedzie zalezny od konfigu-racji
i warunków sieci w miejscu instalacji architektury Cloudyna.
3.4.3. Wymagania dotyczace architektur maszyn i systemu operacyjnego
W projekcie systemu zakładamy wsparcie dla rodziny systemów Linux pod pewny-mi
warunkami. Nie jest zakładane wsparcie dla innych rodzin systemów. Wymagania