Darmowy fragment publikacji:
Tytuł oryginału: The Cloud at Your Service
Tłumaczenie: Justyna Walkowska
Projekt okładki: Jan Paluch
ISBN: 978-83-246-3416-3
Original edition copyright © 2011 by Manning Publications Co.
All rights reserved
Polish edition copyright © 2011 by Helion S.A.
All rights reserved
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage
retrieval system, without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu
niniej¬szej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą
kserograficz¬ną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym
lub innym powoduje naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi
ich właścicieli.
Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje
były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani
za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz
Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody
wynikłe z wykorzystania informacji zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/chmura
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treĂci
9
11
13
17
Sïowo wstÚpne
Przedmowa
PodziÚkowania
O ksiÈĝce
1. Czym jest chmura obliczeniowa?
25
1.1. PiÚÊ podstawowych zasad definiujÈcych przetwarzanie w chmurze .............................. 27
1.1.1. Pula zasobów ............................................................................................................ 28
1.1.2. Wirtualizacja zasobów obliczeniowych .................................................................. 29
1.1.3. ElastycznoĂÊ wobec zmieniajÈcego siÚ zapotrzebowania ...................................... 30
1.1.4. Automatyczne wdraĝanie nowych zasobów ........................................................... 30
1.1.5. Naliczanie opïat: pïacisz tylko za to, co faktycznie wykorzystasz ......................... 31
1.2. Zyski z przejĂcia na chmurÚ ................................................................................................ 31
1.2.1. Zyski ekonomiczne zwiÈzane z zamianÈ
wydatków inwestycyjnych na operacyjne .............................................................. 31
1.2.2. Zyski zwiÈzane z elastycznoĂciÈ i brakiem zapotrzebowania na serwery ............. 32
1.2.3. Zyski wydajnoĂciowe dajÈce przewagÚ nad konkurencjÈ ...................................... 33
1.2.4. WiÚksze bezpieczeñstwo w chmurze ..................................................................... 33
1.3. Ewolucja w informatyce prowadzÈca do chmury obliczeniowej ..................................... 33
1.3.1. Dlaczego „chmura”? ................................................................................................ 34
1.3.2. Zmiany paradygmatów przetwarzania: od samodzielnych jednostek,
przez architektury klient-serwer, aĝ do sieci ......................................................... 35
1.3.3. Przechowywanie fizycznych zasobów obliczeniowych: ewolucja centrów danych .... 37
1.3.4. Modularyzacja oprogramowania i zdalny dostÚp: wirtualizacja, SOA i SaaS ....... 37
4
Spis treĂci
2. Klasyfikacja chmur obliczeniowych
1.4. Klasyfikacja warstw chmury: róĝne typy do róĝnych zastosowañ ................................... 38
1.4.1.
Infrastruktura jako usïuga (IaaS) ............................................................................. 39
1.4.2. Platforma jako usïuga (PaaS) ................................................................................... 41
1.4.3. Oprogramowanie jako usïuga (SaaS) i framework jako usïuga (FaaS) .................. 41
1.4.4. Chmury prywatne jako prekursorzy chmur publicznych ...................................... 42
1.5. Podsumowanie ...................................................................................................................... 42
43
2.1. Podstawy technologiczne przetwarzania w chmurze ....................................................... 44
2.1.1. Duĝe korzyĂci skali dziÚki centrom danych w chmurze ....................................... 45
2.1.2. Efektywne wykorzystanie serwerów w chmurze dziÚki wirtualizacji .................. 49
2.1.3. Sterowanie zdalnymi serwerami za poĂrednictwem API chmury ........................ 52
2.1.4. Przechowywanie trwaïych danych w chmurze ...................................................... 54
2.1.5. Przechowywanie danych aplikacji w chmurowej bazie danych ............................ 56
2.1.6. ElastycznoĂÊ: skalowanie aplikacji w miarÚ zwiÚkszania siÚ
lub zmniejszania popytu .......................................................................................... 62
2.2. Zrozumienie róĝnych typów chmur .................................................................................... 63
2.2.1. Amazon EC2: IaaS ................................................................................................... 64
2.2.2. Microsoft Azure: IaaS .............................................................................................. 65
2.2.3. Google App Engine: PaaS ....................................................................................... 68
2.2.4. Ruby on Rails w chmurze: PaaS ............................................................................. 69
2.2.5. Salesforce.com i Force.com: PaaS .......................................................................... 70
2.2.6. Chmury prywatne: DaaS (centrum danych jako usïuga) .................................. 70
2.3. Wybór chmury najlepiej dopasowanej do Twoich potrzeb ............................................. 72
2.3.1. Amazon Web Services — chmura IaaS .................................................................. 72
2.3.2. Microsoft Azure — chmura IaaS i PaaS ................................................................. 73
2.3.3. Google App Engine — chmura PaaS ..................................................................... 74
2.3.4. Ruby on Rails — chmura PaaS ............................................................................... 74
2.3.5. Force.com — chmura PaaS .................................................................................... 75
2.4. Podsumowanie ...................................................................................................................... 75
77
3.1. Ekonomika przetwarzania w chmurze ............................................................................... 78
3. Analiza biznesowa chmury
3.1.1. Tradycyjna infrastruktura wewnÚtrzna, kolokacja,
usïugi zarzÈdzane, a moĝe model chmury? ............................................................ 79
3.1.2. Szczegóïowe porównanie kosztów wdraĝania w róĝnych modelach .................... 81
3.2. Kiedy wdroĝenie w chmurze ma sens? ............................................................................... 86
3.2.1. Ograniczony czas ĝycia lub zapotrzebowanie krótkoterminowe .......................... 87
3.2.2. WahniÚcia skali ........................................................................................................ 88
3.2.3. Aplikacje niestrategiczne ........................................................................................ 89
3.3. Kiedy wdroĝenie w chmurze nie ma sensu? ...................................................................... 90
3.3.1. Historyczne aplikacje .............................................................................................. 90
3.3.2. Aplikacje z krytycznymi scenariuszami czasu rzeczywistego ............................... 91
3.3.3. Aplikacje z dostÚpem do poufnych danych ............................................................ 91
3.4. PrzedsiÚbiorstwa typu start-up bez kapitaïu zakïadowego .............................................. 92
3.4.1. Wtedy i teraz: tworzenie niewielkiego sklepu internetowego
w 2000 i 2010 roku ................................................................................................... 92
3.4.2. Czy zewnÚtrzny kapitaï inwestycyjny jest niezbÚdny? ......................................... 93
3.4.3. Przykïad 1.: FlightCaster — przewidywanie opóěnieñ lotów .............................. 94
3.4.4. Przykïad 2.: analiza biznesowa jako SaaS ............................................................... 94
Spis treĂci
5
4. Bezpieczeñstwo i chmura prywatna
3.5. Maïe i Ărednie przedsiÚbiorstwa ......................................................................................... 95
3.5.1. Prosty przykïad: strona firmowa ............................................................................. 95
3.5.2. ¥rednio skomplikowany przykïad: kopie zapasowe i przechowywanie plików ... 96
3.5.3. Przykïad zaawansowany: rozwijanie nowych produktów ................................. 96
3.6. Chmura w korporacjach ...................................................................................................... 97
3.6.1. Eli Lilly: duĝy zbiór danych, obliczenia wysokowydajne ..................................... 97
3.6.2.
„The Washington Post”: duĝe problemy obliczeniowe
z nieprzekraczalnymi terminami ............................................................................ 98
3.6.3. Virgin Atlantic: obecnoĂÊ w sieci i zgromadzenie spoïecznoĂci ........................... 99
3.7. Podsumowanie ...................................................................................................................... 99
101
4.1. Bezpieczeñstwo informacji w chmurze publicznej ......................................................... 102
4.1.1. Obawy o bezpieczeñstwo spowalniajÈce ekspansjÚ chmury ............................... 103
4.1.2. Bezpieczeñstwo najwiÚkszych centrów danych w chmurze ............................... 104
4.1.3. ¥rodki kontroli dostÚpu w chmurze publicznej ................................................... 106
4.1.4. Bezpieczeñstwo sieciowe i bezpieczeñstwo danych w duĝych chmurach ......... 111
4.1.5. Rola i zakres odpowiedzialnoĂci wïaĂciciela aplikacji ......................................... 114
4.2. Przyczyny powstania chmury prywatnej .......................................................................... 115
4.2.1. Definicja chmury prywatnej ................................................................................. 115
4.2.2. Kwestie bezpieczeñstwa ....................................................................................... 117
4.2.3. PewnoĂÊ dostÚpnoĂci zasobów .............................................................................. 117
4.2.4. Duĝa spoïecznoĂÊ .................................................................................................. 118
4.2.5. Efekty skali ............................................................................................................. 118
4.2.6. Potencjalne problemy z chmurÈ prywatnÈ ........................................................... 119
4.2.7. Sposoby wdroĝenia chmury prywatnej ................................................................ 119
4.3. Wirtualna chmura prywatna ............................................................................................. 124
4.3.1.
Jak to dziaïa? .......................................................................................................... 124
4.3.2. API wirtualnej chmury prywatnej ........................................................................ 125
4.3.3. Konsekwencje ........................................................................................................ 126
4.4. Chmury prywatne w praktyce ........................................................................................... 126
4.4.1. Sprint: chmura prywatna dla aplikacji wykrywajÈcej oszustwa .......................... 127
4.4.2. Project Services Network (PSN) firmy Bechtel ................................................... 127
4.4.3. RzÈdowe chmury prywatne ................................................................................... 128
4.5. Dïugoterminowa prognoza dla chmury prywatnej ......................................................... 129
4.6. Podsumowanie .................................................................................................................... 130
131
5.1. Wzorce aplikacji najlepiej pasujÈce do chmury .......................................................... 132
5.1.1. Przeniesienie .......................................................................................................... 132
5.1.2. Skala internetowa .................................................................................................. 133
5.1.3. Ekspansja obliczeñ ................................................................................................ 133
5.1.4. Elastyczne skïadowanie danych ............................................................................ 134
5.1.5. Podsumowanie wzorców aplikacji ........................................................................ 134
5.2. Projektowanie i architektura w skali internetowej: shardowanie ................................. 134
5.2.1. Cechy aplikacji blokujÈce skalowalnoĂÊ ............................................................... 136
5.2.2. Shardowanie: zrównoleglona architektura bazy danych
5. Projektowanie i architektura aplikacji w chmurze
umoĝliwiajÈca skalowanie ..................................................................................... 137
5.2.3.
Jak shardowanie zmienia aplikacjÚ ....................................................................... 139
5.2.4. Porównanie shardowania z tradycyjnymi architekturami baz danych ............... 140
6
Spis treĂci
5.2.5. Shardowanie w praktyce: najpopularniejsze schematy
partycjonowania baz danych ................................................................................. 143
5.2.6. TrudnoĂci i problemy zwiÈzane ze shardowaniem .............................................. 145
5.2.7. Shardowanie w praktyce: jak robi to Flickr? ........................................................ 148
5.3. ZwiÚkszenie mocy na ĝyczenie: cloudbursting ................................................................ 150
5.3.1. Cloudbursting: definicja ................................................................................................. 150
5.3.2. Dwie pieczenie na jednym ogniu: wewnÚtrzne centrum danych oraz chmura ..... 151
5.3.3. Cloudbursting: analiza biznesowa ........................................................................ 152
5.3.4. Cloudbursting: architektura .................................................................................. 154
5.3.5.
Jak zaimplementowaÊ cloudbursting? .................................................................. 156
5.3.6. Cloudbursting: potrzeba standaryzacji ................................................................. 157
5.3.7. Cloudbursting: problem dostÚpu do danych ....................................................... 157
5.4. Jak przygotowaÊ siÚ na wykïadniczy przyrost iloĂci skïadowanych danych? ............... 160
5.4.1. Magazyn danych w chmurze: definicja ................................................................ 160
5.4.2. Amazon S3 .............................................................................................................. 161
5.4.3. Przykïadowy interfejs magazynu danych w chmurze (S3) .............................. 161
5.4.4. Koszty ..................................................................................................................... 164
5.4.5. Montowalne systemy plików w chmurze ............................................................. 164
Jak sobie radziÊ z opóěnieniami? .......................................................................... 165
5.4.6.
5.5. Podsumowanie .................................................................................................................... 166
167
6.1. SOA jako prekursor chmury .............................................................................................. 168
6.1.1. Systemy rozproszone ............................................................................................. 168
6.1.2. Luěne sprzÚĝenie ................................................................................................... 170
6.1.3. SOA ........................................................................................................................ 172
6.1.4. SOA i luěne sprzÚĝenie ......................................................................................... 173
6.1.5. SOA i usïugi sieciowe ............................................................................................ 174
6.1.6. SOA i przetwarzanie w chmurze .......................................................................... 175
6.1.7. Komunikacja miÚdzy procesami w chmurze ........................................................ 176
6.2. NiezawodnoĂÊ wysokowydajnych, rozproszonych aplikacji w chmurze ....................... 176
6.2.1. NadmiarowoĂÊ ....................................................................................................... 177
6.2.2. MapReduce ............................................................................................................ 178
6.2.3. Hadoop: MapReduce w wersji open source ........................................................ 183
6.3. Podsumowanie .................................................................................................................... 184
185
7.1. Typowe wdroĝenia .............................................................................................................. 186
7.1.1.
Tradycyjna architektura wdroĝeniowa ................................................................. 187
7.1.2. ¥rodowisko testowe i Ărodowisko etapu poĂredniego ......................................... 188
7.1.3. Wyliczenie kosztów ............................................................................................... 189
7.2. Chmura na ratunek! ........................................................................................................... 189
7.2.1. Poprawa jakoĂci produkcyjnej dziÚki chmurze .................................................... 190
7.2.2. Szybsze wytwarzanie aplikacji oraz testowanie ................................................... 192
7.3. Siïa równolegïoĂci ............................................................................................................... 195
7.3.1. Testy jednostkowe ................................................................................................. 196
7.3.2. Testy funkcjonalne ................................................................................................. 198
7.3.3. Testy obciÈĝeniowe ............................................................................................... 201
7.3.4. Testy wizualne ....................................................................................................... 204
7.3.5. Testy rÚczne ........................................................................................................... 206
7.4. Podsumowanie .................................................................................................................... 207
6. NiezawodnoĂÊ w skali chmury
7. Testy, wdroĝenie i dziaïanie w chmurze
Spis treĂci
7
8. Kwestie praktyczne
209
8.1. Wybór dostawcy chmury ................................................................................................... 210
8.1.1. Kwestie biznesowe ................................................................................................ 210
8.1.2. Kwestie techniczne ................................................................................................ 212
8.2. Chmura publiczna i SLA ................................................................................................... 218
8.2.1. SLA dla Amazon AWS ........................................................................................... 219
8.2.2. SLA dla Microsoft Azure ....................................................................................... 220
8.2.3. SLA dla chmury Rackspace .................................................................................. 221
8.3. Pomiary jakoĂci operacji w chmurze ................................................................................ 222
8.3.1. WidocznoĂÊ i monitorowanie u dostawcy
9. PrzyszïoĂÊ chmury
jakoĂci Ăwiadczonych przez niego usïug .............................................................. 222
8.3.2. WidocznoĂÊ i monitorowanie jakoĂci usïug,
które Ăwiadczy dostawca, za pomocÈ rozwiÈzañ zewnÚtrznych firm .................. 226
8.4. Podsumowanie .................................................................................................................... 228
229
9.1. Najwaĝniejsza transformacja w dziejach informatyki .................................................... 231
9.1.1.
Internet konsumentów oraz chmura .................................................................... 231
9.1.2. Chmura w przedsiÚbiorstwach ............................................................................. 235
9.2. DziesiÚÊ prognoz na temat ewolucji chmury ................................................................... 239
9.2.1. Tañsza, bardziej niezawodna, bezpieczniejsza i prostsza w uĝyciu .................... 240
9.2.2. Motor napÚdzajÈcy wzrost prekursorów .............................................................. 241
9.2.3. Koszty niĝsze niĝ w firmowych centrach danych ................................................ 241
9.2.4. Do 2020 roku — 500 tysiÚcy serwerów wartych miliard dolarów ...................... 242
9.2.5. Administratorzy a serwery — 1:10 000 w 2020 roku ........................................... 243
9.2.6. Dominacja open source ......................................................................................... 243
9.2.7. Pragmatyczne standardy i rola Amazon API ........................................................ 244
9.2.8. Ostateczny standard ISO dla chmury ................................................................... 245
9.2.9. RzÈd jako prekursor w chmurze ........................................................................... 247
9.2.10. SaaS i standardy ..................................................................................................... 247
9.3. DziesiÚÊ prognoz na temat ewolucji sposobu wytwarzania aplikacji ........................... 248
9.3.1. Rola szkieletów aplikacji ....................................................................................... 248
9.3.2. Druga i trzecia warstwa dziaïajÈce w chmurze .................................................... 249
9.3.3. Gwaïtowna ewolucja mechanizmów skïadowania danych .................................. 250
9.3.4. Lepsza ochrona wraĝliwych danych ..................................................................... 251
9.3.5. Usïugi wyĝszego poziomu o wïasnych API .......................................................... 252
9.3.6. Wzrost znaczenia aplikacji typu mashup ............................................................. 252
9.3.7. Dominacja PaaS i FaaS ......................................................................................... 254
9.3.8. NarzÚdzia do tworzenia aplikacji typu mashup ................................................... 254
9.3.9. Sukces programistów spoza Ăwiata zachodniego ................................................. 255
9.3.10. Koszty wytworzenia aplikacji nie sÈ przeszkodÈ .................................................. 256
9.4. Podsumowanie .................................................................................................................... 256
9.4.1. PiÚÊ podstawowych zasad przetwarzania w chmurze ......................................... 256
9.4.2.
Gïówne zyski z przejĂcia na chmurÚ .................................................................... 257
9.4.3. Chmura powstaïa na drodze ewolucji .................................................................. 257
9.4.4. Klasyfikacja chmur: od IaaS do SaaS .................................................................... 257
9.4.5. Podstawy technologiczne ...................................................................................... 258
9.4.6. Opïaty tylko za rzeczywiste zuĝycie ..................................................................... 258
9.4.7. Przesadne obawy o bezpieczeñstwo ..................................................................... 259
9.4.8. Chmury prywatne jako zjawisko tymczasowe ...................................................... 259
9.4.9. Projektowanie z myĂlÈ o skali i shardowanie ....................................................... 260
8
Spis treĂci
A. Powtórka z bezpieczeñstwa
9.4.10. Projektowanie z myĂlÈ o niezawodnoĂci i MapReduce ....................................... 260
9.4.11. Lepsze testy, wdroĝenia i dziaïanie w chmurze .................................................. 261
9.4.12. Wybór dostawcy .................................................................................................... 261
9.4.13. Monitorowanie chmur publicznych i SLA ........................................................... 261
9.4.14. PrzyszïoĂÊ chmury obliczeniowej ......................................................................... 261
263
Sekretna komunikacja ................................................................................................................. 264
Klucze .......................................................................................................................................... 265
Kryptografia klucza wspóïdzielonego ....................................................................................... 265
Kryptografia klucza publicznego ............................................................................................... 266
XML Signature ............................................................................................................................ 268
XML Encryption .......................................................................................................................... 268
271
Skorowidz
Klasyfikacja chmur
obliczeniowych
W tym rozdziale:
i podstawy technologiczne wspólne dla
wszystkich typów chmur,
i klasyfikacja typów chmur i ich moĪliwoĞci,
i zasady wyboru chmury odpowiedniego typu
i najlepszego dostawcy.
44
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
Poprzedni rozdziaï byï wprowadzeniem do Ăwiata przetwarzania w chmurze.
W tym zajmiemy siÚ bardziej szczegóïowÈ analizÈ róĝnych typów chmur i cha-
rakterystycznych dla nich sposobów dziaïania. Za przykïad niech nam posïuĝy
samochód — jeĂli chmura jest samochodem, to nowoczesne centrum danych
odgrywa rolÚ silnika, a wirtualizacja odpowiada resorom, chroniÈcym nas na wy-
boistej drodze. API chmury przypomina deskÚ rozdzielczÈ, pozwalajÈcÈ kontrolo-
waÊ chmurÚ. Magazyn danych dziaïa jak bagaĝnik, umoĝliwiajÈcy transportowanie
róĝnych rzeczy. Bazy danych w chmurze to system nawigacyjny — konkretne
informacje niezbÚdne w podróĝy. W zaleĝnoĂci od potrzeb samochód elastycz-
nie przestawia siÚ na inny bieg — moĝna porównaÊ to do elastycznoĂci aplika-
cji, która moĝe obsïugiwaÊ jednego uĝytkownika, a chwilÚ póěniej rozszerza siÚ tak,
ĝe moĝliwa jest obsïuga miliona zgïoszeñ. Istnieje wiele modeli pojazdów i wiele
typów chmur. Przyjrzymy siÚ z bliska dominujÈcym dzisiaj typom. Ocenimy, czy
potrzebujesz wyĂcigówki, gdyĝ zaleĝy Ci na prÚdkoĂci, czy moĝe wolisz osiem-
nastokoïowego olbrzyma, który zapewni Ci mnóstwo przestrzeni.
Na poczÈtek przeanalizujmy najbardziej niezbÚdne aspekty technologiczne
chmury, by dobrze zrozumieÊ, z jakich elementów jest ona zbudowana. W roz-
dziale 1. omówiliĂmy wstÚpnie róĝne typy chmur i porównaliĂmy je ze sobÈ.
Teraz rozwiniemy to zagadnienie, by uïatwiÊ Ci podjÚcie decyzji na temat wy-
boru typu chmury oraz wspomóc najbardziej efektywne jej wykorzystanie.
2.1. Podstawy technologiczne
przetwarzania w chmurze
WiÚkszoĂÊ kierowców zna podstawy dziaïania samochodu — niektórzy poznali je
z czystej ciekawoĂci, innym zaleĝaïo na byciu lepszymi kierowcami i wïaĂcicie-
lami auta. W przypadku chmury równieĝ moĝliwe jest wyodrÚbnienie ogólnych
zasad dziaïania niezaleĝnych od typu. Omówimy je dla lepszego zrozumienia
póěniejszych kwestii:
Chmura potrzebuje serwerów sieciowych, te zaĂ potrzebujÈ domu.
Serwery zgromadzone w pewnej fizycznej lokalizacji bÚdziemy
okreĂlali mianem centrum danych.
Serwery w chmurze naleĝy zwirtualizowaÊ. Celem tego procesu jest
zwiÚkszenie efektywnoĂci banku serwerów. W przeciwnym razie
koszty utrzymania serwerów obniĝÈ efektywnoĂÊ finansowÈ chmury.
Chmura potrzebuje API. Bez interfejsu dostÚpowego zwirtualizowane
serwery w chmurze tkwiïyby w ciszy i samotnoĂci. Uĝytkownicy muszÈ
mieÊ dostÚp do chmury. ChcÈ zamawiaÊ nowe serwery, wysyïaÊ i pobieraÊ
dane, uruchamiaÊ i zatrzymywaÊ aplikacje, a takĝe pozbywaÊ siÚ serwerów,
które przestaïy juĝ byÊ potrzebne. Wszystko to ma siÚ odbywaÊ zdalnie,
gdyĝ stopa uĝytkowników nigdy nie postanie w fizycznej serwerowni.
2.1.
Podstawy technologiczne przetwarzania w chmurze
45
Chmura musi gdzieĂ przechowywaÊ dane. Musi skïadowaÊ obrazy maszyn
wirtualnych, aplikacje uĝytkowników i wykorzystywane przez nie trwaïe
dane.
Chmura wymaga bazy danych. WiÚkszoĂÊ aplikacji do dziaïania potrzebuje
ustrukturyzowanych danych — w konsekwencji potrzebuje ich takĝe
chmura.
Chmura musi byÊ elastyczna i skalowaÊ siÚ dynamicznie zgodnie
z potrzebami aplikacji i ich uĝytkowników. Dla uĝytkowników chmury
moĝliwoĂÊ dostosowania iloĂci wykorzystywanych zasobów (oraz pïatnoĂci
za nie) do aktualnego obciÈĝenia aplikacji to jedna z najwiÚkszych
korzyĂci z przejĂcia na chmurÚ.
Omówimy teraz bardziej szczegóïowo kaĝdy z wymienionych szeĂciu aspek-
tów technologicznych i infrastrukturalnych.
2.1.1. DuĪe korzyĞci skali dziĊki centrom danych w chmurze
WróÊmy do analogii samochodowej — centrum danych to silnik samochodu.
Centrum danych, posiadane obecnie przez kaĝdÈ wiÚkszÈ instytucjÚ, to obiekt
(nierzadko pilnie strzeĝony), w którym znajduje siÚ wiele komputerów i innego
sprzÚtu sieciowo-komunikacyjnego. Duĝe korporacje internetowe, takie jak
Amazon, Yahoo, Google, Intuit czy Apple, w ciÈgu lat zgromadziïy megacentra
danych z tysiÈcami serwerów. StanowiÈ one punkt wyjĂcia infrastruktury przetwa-
rzania w chmurze.
Warto dobrze zrozumieÊ strukturÚ i ekonomikÚ tych ogromnych centrów
danych. To na nich oparte sÈ mechanizmy skalowania, niezawodnoĂÊ przetwa-
rzania, bezpieczeñstwo danych i przyszïoĂÊ rozwoju chmur publicznych. Rozwaĝ
te kwestie, zwïaszcza jeĂli myĂlisz o stworzeniu wïasnej chmury prywatnej. Jeszcze
w tym rozdziale opowiemy co nieco o chmurach prywatnych. Dodatkowo caïy
rozdziaï 4. jest poĂwiÚcony chmurom prywatnym i bezpieczeñstwu.
Struktura centrum danych
Centrum danych moĝe mieĂciÊ siÚ w jednym pokoju, zajmowaÊ jedno albo
wiÚcej piÚter, a nawet objÈÊ we wïadanie caïy budynek. WiÚkszoĂÊ jego wyposaĝe-
nia z reguïy stanowiÈ serwery upakowane w dziewiÚtnastocalowych szafach,
najczÚĂciej ustawianych w rzÚdach, pomiÚdzy którymi tworzÈ siÚ korytarze
umoĝliwiajÈce dostÚp do serwerów z dwóch stron. Serwery róĝniÈ siÚ rozmiarami.
Serwer wielkoĂci 1U (ang. rack unit) zajmuje jeden slot (z czterdziestu dwóch)
w szafie montaĝowej, ale istniejÈ takĝe samostojÈce serwery, których nie montuje
siÚ w szafach. Komputery typu mainframe oraz niektóre magazyny danych mogÈ
byÊ tak duĝe jak szafy i sÈ ustawiane w szeregach razem z nimi. Duĝe centra
danych czasami korzystajÈ z kontenerów po tysiÈc lub wiÚcej serwerów kaĝdy.
JeĂli potrzebna jest naprawa lub aktualizacja, wymienia siÚ caïy kontener, a nie
poszczególne serwery.
46
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
NiezbÚdny jest czysty, stabilny dopïyw energii. Komputery w centrach danych
dziaïajÈ bez przerwy. MuszÈ byÊ odporne na spadki napiÚcia, a nawet przerwy
w dostawach prÈdu. Serwerownia musi byÊ zaopatrzona w stabilizator napiÚcia,
zapasowe baterie oraz generatory prÈdu, zapewniajÈce nieograniczony, nieprze-
rwany dopïyw prÈdu. Waĝne jest takĝe chïodzenie sprzÚtu. NajczÚĂciej stosuje
siÚ do tego schïodzone powietrze, jednak pojawiajÈ siÚ równieĝ systemy wyko-
rzystujÈce wodÚ, jeĂli jest ona ïatwo dostÚpna. WodÈ chïodzone sÈ na przykïad
nowe centra danych poïoĝone wzdïuĝ rzeki Kolumbia w stanie Waszyngton. Kli-
matyzacja ma za zadanie nie tylko obniĝenie temperatury, lecz takĝe kontrolÚ
wilgotnoĂci, by nie doszïo do skraplania siÚ lub wyïadowañ elektrostatycznych.
Centrum danych wymaga szerokopasmowego ïÈcza umoĝliwiajÈcego odbiór
i wysyïanie danych. Istnienie serwerów i magazynów danych nie ma sensu, jeĂli
nikt nie moĝe siÚ z nimi poïÈczyÊ.
Waĝne jest takĝe bezpieczeñstwo, zarówno fizyczne, jak i logiczne. Duĝe
centra danych sÈ pod ciÈgïym ostrzaïem hakerów z caïego Ăwiata. Procedury
bezpieczeñstwa w niektórych centrach danych zaczynajÈ siÚ od tego, ĝe ukrywane
jest samo istnienie centrum w danej lokalizacji. Straĝnicy, puïapki i najnowo-
czeĂniejsze mechanizmy autentykacji majÈ za zadanie fizycznie powstrzymaÊ
nieproszonych goĂci. Firewalle, bramki VPN, oprogramowanie wykrywajÈce
wïamania i inne tego typu rozwiÈzania chroniÈ centrum przed wïamaniem przez
sieÊ (wiÚcej na temat bezpieczeñstwa w chmurze w rozdziale 4.).
Ponadto centra danych muszÈ byÊ przygotowane na najgorsze oraz posiadaÊ
strategie wznowienia i utrzymania struktury po awarii, wïamaniu lub innym
zdarzeniu, by uniknÈÊ utraty danych i zminimalizowaÊ okres nieaktywnoĂci.
Centra danych: skalowanie na potrzeby chmury
Tradycyjne duĝe centra danych przeznaczone do obsïugi jednej duĝej korporacji
kosztujÈ miÚdzy 100 a 200 milionami dolarów1. Dla porównania: caïkowity
koszt budowy najwiÚkszych megacentrów danych, ĂwiadczÈcych usïugi prze-
twarzania w chmurze, wynosi ponad 500 milionów dolarów2,3. Co powoduje taki
przyrost kosztów? Co majÈ najwiÚksze centra przeznaczone dla chmury, czego
nie majÈ tradycyjne centra dedykowane jednej firmie?
NajwiÚksi operatorzy, tacy jak Google, Amazon czy Microsoft, lokujÈ swoje
centra w nieduĝej odlegïoĂci od rejonów, których mieszkañcy intensywnie z nich
korzystajÈ, co zmniejsza opóěnienia i uïatwia przeïÈczanie siÚ pomiÚdzy maszynami
w przypadku awarii. SzukajÈ takĝe miejsc, w których energia elektryczna jest
tania. W Stanach Zjednoczonych takim obszarem jest Póïnocny Zachód —
elektrownie wodne produkujÈ najtañszÈ energiÚ w kraju, a koszty chïodzenia sÈ
bliskie zeru. Sama konsumpcja energii przez duĝe centrum danych moĝe koszto-
waÊ wiÚcej niĝ 30 milionów dolarów rocznie. Obecnie zuĝycie energii przez takie
centra stanowi 1,2 procenta caïkowitego zuĝycia energii w kraju i wciÈĝ roĂnie.
1 http://perspectives.mvdirona.com/2008/11/28/CostOfPowerInLargeScaleDataCenters.aspx.
2 http://www.datacenterknowledge.com/archives/2007/11/05/microsoft-plans-500m-illinois-data-center.
3 http://www.theregister.co.uk/2009/09/25/microsoft_chillerless_data_center.
2.1.
Podstawy technologiczne przetwarzania w chmurze
47
ĝwiatowe serwery emitują wiĊcej dwutlenku wĊgla niĪ caáa Holandia
Firma doradcza McKinsey Co. donosi, Ĕe 44 miliony dziaäajñcych na Ĉwiecie serwerów
sñ odpowiedzialne za 0,5 procenta Ĉwiatowej konsumpcji energii oraz 0,2 procenta
emisji dwutlenku wögla, co odpowiada 80 megatonom rocznie. ZbliĔone iloĈci dwutlenku
wögla emitujñ takie kraje, jak Argentyna czy Holandia.
Plusem dla operatorów jest to, ĝe przy takim zapotrzebowaniu na energiÚ mogÈ
negocjowaÊ potÚĝne zniĝki.
Dodatkowo megacentra mogÈ negocjowaÊ ogromne zniĝki na zakup sprzÚ-
tu, wykraczajÈce daleko poza zniĝki oferowane najwiÚkszym nawet firmom bu-
dujÈcym prywatne, dedykowane serwerownie. Przykïadowo w 2008 roku firma
Amazon zapïaciïa okoïo 90 milionów dolarów za 50 tysiÚcy serwerów firmy
Rackable/SGI4. W normalnym handlu kosztowaïyby one 215 milionów.
Serwery stanowiÈ najwiÚkszÈ czÚĂÊ kosztów ponoszonych przez centra danych.
Dlatego Google i inni próbujÈ ciÈÊ koszty, samodzielnie konstruujÈc serwery
z gotowych komponentów. Google polega na tanich komputerach ze zwykïymi
procesorami wielordzeniowymi. Jedno centrum danych Google posiada dziesiÈtki
tysiÚcy takich niedrogich procesorów i dysków pospinanych rzepami, co umoĝli-
wia ïatwÈ wymianÚ komponentów.
By ograniczyÊ apetyt maszyn na energiÚ, firma Google wprowadziïa me-
chanizmy optymalizujÈce dopïyw prÈdu, wentylatory o zmiennej prÚdkoĂci oraz
pïyty gïówne wypatroszone ze wszystkich zbÚdnych elementów, w tym kart gra-
ficznych. Eksperymentowano takĝe z dynamicznym skalowaniem napiÚcia i czÚ-
stotliwoĂci. NapiÚcie lub czÚstotliwoĂÊ procesora sÈ obniĝane w pewnych okresach
(np. gdy wynik obliczeñ nie jest wymagany natychmiast). Serwer dziaïa wolniej,
co zmniejsza konsumpcjÚ energii. Inĝynierowie Google twierdzÈ, ĝe w niektó-
rych testach oszczÚdnoĂÊ energii wyniosïa 20 procent.
W roku 2006 firma Google wybudowaïa w miejscowoĂci Dalles w Oregonie
dwa centra danych, z których kaĝde zajmuje teren wielkoĂci boiska futbolowego,
ma cztery piÚtra i czteropiÚtrowÈ chïodniÚ (rysunek 2.1). Strategiczne znacze-
nie dla centrum danych ma tama w Dalles, zapewniajÈca dopïyw energii oraz
chïodzenie. (Niektóre nowe centra danych korzystajÈ z chïodni kominowych,
które odparowujÈ wodÚ wykorzystanÈ do chïodzenia, co zuĝywa o wiele mniej
energii niĝ tradycyjne chïodziarki).
Centrum danych w Dalles jest doskonale poïÈczone istniejÈcymi juĝ wcze-
Ăniej Ăwiatïowodami z róĝnymi lokalizacjami w USA, Azji i Europie. Kable te sÈ
spuĂciznÈ po bañce internetowej.
W 2007 roku firma Google stworzyïa co najmniej cztery nowe centra danych
warte Ărednio 600 milionów dolarów. Weszïy one w skïad Googleplexu: wielkiej
Ăwiatowej sieci komputerowej, szacowanej na 450 tysiÚcy serwerów w dwudziestu
piÚciu lokalizacjach. Firma Amazon równieĝ zdecydowaïa siÚ umieĂciÊ swoje
najwiÚksze centrum danych w Dalles, kawaïek dalej wzdïuĝ rzeki.
4 http://www.datacenterknowledge.com/archives/2009/06/23/amazon-adds-cloud-data-center-in-virginia.
48
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
Rysunek 2.1. ZdjĊcie przedstawia ĞciĞle tajne centrum danych Google w miejscowoĞci
Dalles w Oregonie, zbudowane w pobliĪu tamy w celu uzyskania dostĊpu do taniej energii.
Zwróü uwagĊ na duĪe cháodnie kominowe na koĔcach znajdujących siĊ po lewej stronie
zdjĊcia budynków wielkoĞci boiska do futbolu. Kominy cháodzą budynki przez parowanie, bez
uĪywania kosztownych energetycznie cháodziarek. ħródáo: Melanie Conner, „New York Times”
Yahoo! i Microsoft wybraïy miejscowoĂÊ Quincy w Waszyngtonie. Budynek
Microsoftu ma powierzchniÚ porównywalnÈ niemal z obszarem dziesiÚciu boisk
futbolowych. Przedstawiciele firmy nabrali wody w usta, jeĂli chodzi o liczbÚ
serwerów, jednak wiadomo, ĝe wykorzystuje siÚ tam prawie piÚÊ kilometrów
rur chïodzÈcych, prawie tysiÈc kilometrów przewodów elektrycznych, niemal
10 tysiÚcy metrów kwadratowych pïyt kartonowo-gipsowych i 1,6 tony baterii
zapewniajÈcych prÈd w razie awarii. Centrum zuĝywa 48 megawatów energii,
co wystarczyïoby dla 40 tysiÚcy domów.
Chmurowe centra danych:
wiĊksza efektywnoĞü i elastycznoĞü dziĊki modularyzacji
Juĝ teraz, dziÚki zakupom hurtowym, serwerom budowanym na zamówienie
i starannie wybranym lokalizacjom, wïaĂciciele najwiÚkszych centrów danych
ponoszÈ o wiele mniejsze koszty w przeliczeniu na operacje procesora niĝ zwykïe
firmy. RobiÈ, co mogÈ, by jeszcze zwiÚkszyÊ tÚ róĝnicÚ. Centra danych w chmurze
stajÈ siÚ coraz bardziej efektywne dziÚki modularyzacji. Moduïowe, skalowalne,
efektywne centra danych sÈ natychmiast dostÚpne za niewielkÈ cenÚ z kaĝdego
miejsca na Ăwiecie.
Rysunek 2.2 przedstawia wizualizacjÚ modularnego centrum danych (fotografie
takich obiektów sÈ pilnie strzeĝone). Firmowe centra danych zostaïy w tyle za
wydajnymi megacentrami, a ich sytuacja bÚdzie siÚ jeszcze pogarszaïa.
Modularyzacja ma na celu ustandaryzowanie centrów danych i odstÈpienie
od wïasnych projektów, co ma uïatwiÊ produkcjÚ sprzÚtu dla takich centrów.
JednÈ z najbardziej uderzajÈcych postulowanych cech jest to, ĝe takie centra
znajdujÈ siÚ pod goïym niebem.
Podobnie jak Google Microsoft stara siÚ ciÈÊ koszty energii, ulega takĝe naci-
skom ekologów, by ograniczaÊ emisjÚ i poprawiÊ wydajnoĂÊ. Docelowy wspóï-
czynnik wydajnoĂci energetycznej PUE (ang. Power Usage Effectiveness) to co
najwyĝej 1,125 we wszystkich centrach danych Microsoftu do 2012 roku.
2.1.
Podstawy technologiczne przetwarzania w chmurze
49
Rysunek 2.2. Rozszerzalne, modularne centrum danych dla chmury. Warto zwróciü uwagĊ
na brak zadaszenia. Kontenery z serwerami, zasilaniem, sprzĊtem cháodzącym i monitorującym
mogą byü dodawane i usuwane w miarĊ potrzeb. ħródáo: magazyn „IEEE Spectrum”
2.1.2. Efektywne wykorzystanie serwerów
w chmurze dziĊki wirtualizacji
Pozostañmy przy analogii samochodowej — wirtualizacja to zawieszenie. Zapew-
nia ona poĝÈdane intensywne wykorzystanie serwerów. agodzi róĝnice pomiÚ-
dzy aplikacjami, które prawie nie potrzebujÈ mocy obliczeniowej (mogÈ one
dzieliÊ procesor z innymi aplikacjami), a tymi, które domagajÈ siÚ kaĝdego ist-
niejÈcego cyklu procesora. Z wszystkich rewolucyjnych technologii wykorzy-
stywanych w chmurze to wïaĂnie wirtualizacja i jej udane wdroĝenie zadecy-
dowaïy o przyjÚciu siÚ nowego trendu. Bez wirtualizacji i umoĝliwianego przez niÈ
zuĝycia procesora wynoszÈcego ponad 60 procent chmura nie byïaby opïacalna.
Wspóáczynnik wydajnoĞci energetycznej (PUE)
Wspóäczynnik wydajnoĈci energetycznej (PUE, ang. Power Usage Effectiveness) okreĈla
wydajnoĈè centrum danych. PUE wyznacza siö, dzielñc iloĈè energii dostarczanej przez
centrum danych przez iloĈè niezbödnñ do dziaäania infrastruktury obliczeniowej we-
wnñtrz. WydajnoĈè poprawia siö, gdy PUE zmniejsza siö w kierunku wartoĈci 1.
Wedäug organizacji Uptime Institute Ĉrednia wartoĈè PUE typowego centrum danych to
2,5. Oznacza to, Ĕe z kaĔdego 2,5 wata na liczniku tylko wat jest wykorzystywany do obliczeþ.
Z szacunków Uptime wynika, iĔ wiökszoĈè centrów mogäaby osiñgnñè wynik 1,6 PUE,
stosujñc najlepszy sprzöt i dobre praktyki. Google i Microsoft zbliĔajñ siö do wartoĈci
1,125 — to wynik nieosiñgalny dla firmowych, a nawet wspóädzielonych centrów danych.
50
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
WIRTUALIZACJA
W tej ksiñĔce koncentrujemy siö gäównie na wirtualizacji platformy. Wirtualizacja platfor-
my to technika abstrakcji zasobów komputera oddzielajñca system operacyjny od sprzö-
tu. System operacyjny nie odwoäuje siö bezpoĈrednio do sprzötu. Zamiast tego odwoäuje
siö on do nowej warstwy programistycznej, nazywanej monitorem maszyny wirtualnej,
która ma dostöp do sprzötu i przedstawia systemowi wirtualny zestaw zasobów sprzöto-
wych. Oznacza to, Ĕe wiele obrazów maszyn wirtualnych lub instancji moĔe dziaäaè na
jednym fizycznym serwerze, a nowe instancje mogñ byè tworzone i uruchamiane na Ĕñ-
danie. W ten sposób tworzona jest podstawa elastycznych zasobów obliczeniowych.
WspomnieliĂmy wczeĂniej, ĝe wirtualizacja wcale nie jest nowym pomysïem.
Komputery typu mainframe produkowane przez IBM stosowaïy wirtualizacjÚ
czasowÈ juĝ w latach szeĂÊdziesiÈtych, umoĝliwiajÈc wielu osobom korzystanie
z jednej maszyny w róĝnym czasie bez ĝadnej interakcji i wchodzenia sobie
w drogÚ. WczeĂniej na uĝytkowników nakïadany byï obowiÈzek wykonania caïoĂci
planowanej pracy w jednym, wyznaczonym okienku czasowym. PojÚcie pamiÚci
wirtualnej, wprowadzone okoïo 1962 roku, choÊ uznawane wówczas za rady-
kalne, raz na zawsze uwolniïo programistów od ciÈgïego zamartwiania siÚ moĝ-
liwoĂciÈ przekroczenia wielkoĂci pamiÚci fizycznej. Dzisiaj wirtualizacja ser-
werów ma równie znaczÈcy wpïyw na wdraĝanie i skalowanie aplikacji, bÚdÈc
zarazem jednym z najwiÚkszych motorów rozwoju chmury. Jak do tego doszïo?
PrzeciÚtny serwer w firmowym centrum danych jest wykorzystywany w okoïo
6 procentach5. Nawet w chwilach maksymalnego obciÈĝenia wykorzystanie nie
przekracza 20 procent. W najlepiej zarzÈdzanych centrach danych serwery wy-
korzystujÈ Ărednio okoïo 15 procent swoich moĝliwoĂci. Jednak gdy takie centra
zdecydujÈ siÚ na peïnÈ wirtualizacjÚ, wykorzystanie mocy procesora wzrasta do
65 procent lub wiÚcej. Z tego powodu w ciÈgu ostatnich paru lat w wiÚkszoĂci
centrów danych wdroĝono setki lub tysiÈce serwerów wirtualnych w miejsce
poprzedniego modelu, w którym jeden serwer odpowiadaï jednej fizycznej jedno-
stce. Przyjrzyjmy siÚ teraz temu, co sprawia, ĝe wykorzystanie zmienia siÚ aĝ
tak radykalnie.
Jak to dziaáa?
Wirtualizacja serwera przeksztaïca (wirtualizuje) zasoby sprzÚtowe komputera
— w tym czas procesora, pamiÚÊ RAM, dysk twardy i kontroler sieciowy — by
stworzyÊ w peïni funkcjonalnÈ maszynÚ wirtualnÈ, na której system operacyjny
i inne aplikacje mogÈ dziaïaÊ tak, jakby dziaïaïy na fizycznym komputerze. Efekt
ten osiÈga siÚ, dodajÈc cienkÈ warstwÚ oprogramowania dziaïajÈcÈ bezpoĂrednio
nad sprzÚtem. Warstwa ta zawiera monitor maszyny wirtualnej (VMM, ang.
Virtual Machine Monitor), który przydziela zasoby sprzÚtowe w dynamiczny
i przejrzysty sposób. DziÚki temu na jednej fizycznej maszynie moĝe dziaïaÊ wiele
systemów operacyjnych, które wspóïbieĝnie korzystajÈ z zasobów sprzÚtowych.
Enkapsulacja caïej maszyny, w tym procesora, pamiÚci i urzÈdzeñ sieciowych,
5 McKinsey Company, 2008 Data Center Efficiency — raport na temat wydajnoĂci centrów danych.
2.1.
Podstawy technologiczne przetwarzania w chmurze
51
sprawia, ĝe maszyna wirtualna staje siÚ w peïni kompatybilna ze standardowymi
systemami operacyjnymi, aplikacjami i sterownikami urzÈdzeñ. Architektura ma-
szyny wirtualnej VMware dla procesorów x86 zostaïa przedstawiona na rysunku 2.3.
Rysunek 2.3. Architektura maszyny wirtualnej na przykáadzie VMware. Warstwa
wirtualizacji odwoáuje siĊ bezpoĞrednio do komponentów sprzĊtowych, w tym do procesora.
Warstwa ta prezentuje kaĪdemu z goszczących na maszynie systemów operacyjnych jego
wáasny zestaw zasobów sprzĊtowych. Taki system zachowuje siĊ dokáadnie tak samo jak
system faktycznie mający dostĊp do sprzĊtu. DziĊki wirtualizacji wiele systemów i dziaáających
w nich aplikacji moĪe korzystaü z jednej fizycznej maszyny, osiągając lepszą wydajnoĞü.
ħródáo: VMware
Zastosowanie wirtualizacji w chmurze
Wirtualizacja szybko znalazïa uznanie u architektów systemów i kierowników
dziaïów IT z bardzo prostego powodu — pozwala zaoszczÚdziÊ pieniÈdze. Rady-
kalnie zwiÚkszyï siÚ stopieñ wykorzystania zasobów sprzÚtowych. Bez wiÚkszego
wysiïku moĝna byïo przejĂÊ od 5 czy 6 do 20 procent. Przy rozsÈdnym planowa-
niu moĝliwe staïo siÚ osiÈgniÚcie wyniku 65 procent wykorzystania sprzÚtu.
Poza lepszym wspóïczynnikiem wykorzystania sprzÚtu i zwiÈzanymi z nim
oszczÚdnoĂciami wirtualizacja w firmowych centrach danych w duĝej mierze
przygotowaïa grunt dla przetwarzania w chmurze. Uĝytkownicy zostali oddzieleni
od implementacji, poprawiïa siÚ szybkoĂÊ, elastycznoĂÊ i „zwinnoĂÊ”, a do tego
zmieniï siÚ nienaruszalny dotÈd model wyceny i licencjonowania oprogramo-
wania. Tabela 2.1 zawiera objaĂnienia poszczególnych elementów.
Tabela 2.1 przedstawia najwaĝniejsze zyski z wprowadzenia chmury. Chmura
zdobywa coraz wiÚksze uznanie i coraz wiÚcej firm jest gotowych, by przejĂÊ
na ten model obliczeniowy. Wiele firm juĝ wczeĂniej korzystaïo z wirtualizacji,
wiÚc przejĂcie na chmurÚ jest dla nich bezbolesne.
Rozpatrzymy scenariusz z wykorzystaniem tysiÚcy serwerów fizycznych.
Kaĝdy z nich zostaï zwirtualizowany, w zwiÈzku z czym moĝe na nim dziaïaÊ
dowolnie wiele systemów operacyjnych. Konfiguracja i wdraĝanie trwajÈ parÚ
52
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
Tabela 2.1. Wpáyw wirtualizacji na firmowe centra danych
Zysk
Oddzielenie uŞytkowników
od implementacji
Pozyskanie nowego serwera
trwa par¤ minut,
a nie kilka miesi¤cy
Nowy model naliczania
op¨at i licencjonowania
ObjaĞnienie
Poj¤cie serwera wirtualnego sprawia, Şe uŞytkownik nie musi, a nawet nie
moŞe martwiø si¤ o fizyczny serwer lub jego lokalizacj¤. Zamiast tego
koncentruje si¤ na umowach i definicjach us¨ug oraz wdraŞanych aplikacjach.
Zamówienie, instalacja, konfiguracja i uruchomienie fizycznego serwera
w duŞych firmach zajmuje 60, 90, a czasem nawet 120 dni. W modelu serwerów
wirtualnych czas pomi¤dzy Ş daniem a wdroŞeniem gotowej aplikacji jest
liczony w minutach lub godzinach, w zaleŞnoĿci od stopnia automatyzacji.
Centrum danych nie moŞe juŞ naliczaø op¨at za ca¨y serwer ani za wszystkie
serwery, na których dzia¨a aplikacja. Zamiast tego nalicza op¨aty za faktyczne
zuŞycie — to rewolucja w informatyce.
minut, a opïaty sÈ pobierane za kaĝdÈ godzinÚ wykorzystania procesora. Zasoby
megacentrów danych staïy siÚ dostÚpne dla zwykïych uĝytkowników dziÚki
poïÈczeniu nastÚpujÈcych elementów: wirtualizacji, automatycznego dodawa-
nia i usuwania sprzÚtu oraz nowych zasad naliczania opïat. Jako odpowiednik
samochodowych resorów wirtualizacja sprawia, ĝe aplikacja moĝe gwaïtownie
przyspieszyÊ, nie zabijajÈc przy tym wszystkich siedzÈcych w pojeědzie po wjecha-
niu na pierwszy wybój.
Jednak potÚĝny silnik (centrum danych) i dobre zawieszenie (wirtualizacja)
to nie wszystko. Potrzebna jest jeszcze deska rozdzielcza — zestaw urzÈdzeñ
pozwalajÈcych na ruszanie, zatrzymywanie oraz sterowanie autem. NiezbÚdny
jest interfejs dajÈcy kontrolÚ nad chmurÈ.
2.1.3. Sterowanie zdalnymi serwerami
za poĞrednictwem API chmury
API (interfejs programowania aplikacji) jest dla chmury tym, czym deska roz-
dzielcza dla samochodu. Pod maskÈ moĝe czaiÊ siÚ prawdziwy potwór, jednak
bez kontrolek i pokrÚteï nie dowiesz siÚ, co wïaĂciwie dzieje siÚ z pojazdem ani
jak nim sterowaÊ. Potrzebujesz przynajmniej kierownicy, gazu i hamulca. PamiÚtaj
takĝe o tym, ĝe nie moĝna jeědziÊ szybko bez dobrych hamulców.
Do chmury trzeba siÚ jakoĂ dostaÊ. Chmury najwyĝszego poziomu — te
oferujÈce aplikacje SaaS (oprogramowanie jako usïuga) — z reguïy majÈ inter-
fejsy oparte na przeglÈdarce. Chmury niĝszego poziomu, IaaS (infrastruktura
jako usïuga), teĝ muszÈ mieÊ dostÚp do aplikacji. Chmura kaĝdego typu musi
oferowaÊ API, za poĂrednictwem którego da siÚ dodawaÊ zasoby, zarzÈdzaÊ
nimi, konfigurowaÊ je i zwalniaÊ, gdy przestajÈ byÊ potrzebne.
API jest niezbÚdne do korzystania z usïug dostawcy chmury. W ten sposób
sprzedajÈcy prezentuje swojÈ ofertÚ, którÈ kupujÈcy moĝe oceniÊ wedïug swo-
ich potrzeb. Przykïadowo API chmury EC2 firmy Amazon jest oparte na proto-
kole SOAP i HTTP, za pomocÈ którego wysyïa siÚ wïaĂciwe tej firmie ĝÈdania
tworzenia, skïadowania i dodawania obrazów maszyn Amazon (AMI) oraz zarzÈ-
2.1.
Podstawy technologiczne przetwarzania w chmurze
53
dzania nimi. Z kolei API oferowanej przez firmÚ Sun6 chmury Kenai caïkowicie
opiera siÚ na architekturze REST. To za poĂrednictwem API tworzy siÚ zasoby
(moc obliczeniowa, skïadowanie, komponenty sieciowe) i zarzÈdza nimi.
Architektura REST i zgodne z niÈ API REST (ang. Representational
State Transfer, transfer stanów reprezentacyjnych) to styl architektoniczny
dla rozproszononych systemów, takich jak World Wide Web. Opiera siÚ
on na protokole HTTP. SieÊ WWW jest najwiÚkszÈ znanÈ implementacjÈ
zgodnÈ z architekturÈ REST — mówi siÚ nawet, ĝe REST to specyfikacja
post hoc tych wïaĂciwoĂci sieci, które sÈ odpowiedzialne za jej sukces.
Architektura REST zakïada istnienie klientów i serwerów. Klienci wy-
syïajÈ ĝÈdania do serwerów, a procesy serwerów przetwarzajÈ te ĝÈdania
i zwracajÈ odpowiednie odpowiedzi. ¿Èdania i odpowiedzi zawierajÈ
reprezentacje zasobów. Zasób to dowolny spójny i sensowny byt, który
jest adresowalny. Reprezentacja zasobu to z reguïy dokument opisujÈcy
aktualny lub zamierzony stan zasobu. Aplikacje i interfejsy zgodne z za-
sadami i ograniczeniami architektury REST okreĂla siÚ mianem RESTful.
Jako ĝe aplikacja dziaïajÈca w chmurze bÚdzie gïównym ĝywicielem Twojej
firmy, musisz postaraÊ siÚ o jej ochronÚ przed nieuprawnionymi osobami.
Gdyby dziaïaïa ona w prywatnym, naleĝÈcym do Twojej firmy centrum danych,
chronionym przez wiele fizycznych i logicznych warstw zabezpieczajÈcych,
miaïbyĂ pewnoĂÊ, ĝe nie dostanie siÚ do niej nikt niepowoïany. W chmurze
wszystko jest z definicji dostÚpne przez internet. Amazon i inni rozwiÈzujÈ ten
problem, wydajÈc klucze publiczne X.509 i ĝÈdajÈc ich podania przy kaĝdym
wywoïaniu API. W ten sposób serwer zyskuje pewnoĂÊ, ĝe byt wywoïujÈcy API
ma prawo dostÚpu do infrastruktury.
Aby zrozumieÊ API chmury — a nie istnieje jeszcze uznany standard —
najlepiej przyjrzeÊ siÚ API chmury Amazon, gdyĝ firma ta jest liderem i narzuca
rozwiÈzania innym. Tabela 2.2 przedstawia najwaĝniejsze definicje i operacje
leĝÈce u podstaw API chmury Amazon.
To oczywiĂcie wierzchoïek góry lodowej, jeĂli chodzi o terminy i wywo-
ïania w API chmury Amazon. Dokumentacja jest dostÚpna pod adresem: http://
aws.amazon.com/documentation/. API moĝna podzieliÊ na nastÚpujÈce obszary:
adresowanie chmur,
bezpieczeñstwo sieciowe,
regiony i strefy dostÚpnoĂci,
usïuga Amazon Elastic Block Store (EBS),
automatyczne skalowanie, równowaĝenie obciÈĝenia i Amazon Cloud Watch,
publiczne zbiory danych,
chmura prywatna Amazon.
6 Obecnie Oracle — przyp. tïum.
54
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
Tabela 2.2. Podstawowe pojĊcia i operacje API chmury obliczeniowej Amazon EC2
PojĊcie
AMI
Instancja
Standardowy
przep¨yw
Pod¨ czenie
Opis
Obraz maszyny Amazon (AMI, ang. Amazon Machine Image) to zaszyfrowany i podpisany
obraz maszyny, który moŞna uruchomiø w Ŀrodowisku serwera wirtualnego. Przyk¨adowo
na obraz moŞe sk¨adaø si¤ nast¤puj cy zestaw: Linux, Apache, MySQL, PHP oraz aplikacja
w¨aĿciciela AMI.
AMI mog byø publiczne (zapewniane przez Amazon), prywatne (zaprojektowane przez twórc¤
aplikacji), zakupione (od zewn¤trznego producenta) lub wspó¨dzielone (stworzone za darmo
przez pewn spo¨ecznoĿø).
AMI moŞna sk¨adowaø w serwisie Amazon Simple Storage Service (S3).
System dzia¨aj cy w wyniku uruchomienia AMI to w¨aĿnie instancja. Gdy instancja koĬczy
dzia¨anie, jej dane zostaj utracone. Instancja pe¨ni tak sam funkcj¤ jak tradycyjny
samodzielny komputer.
1. Dopasuj AMI do swoich potrzeb.
2. Przygotuj paczk¤ AMI i pozyskaj identyfikator.
3. Uruchom jedn lub wi¤cej instancji AMI.
4. Zarz dzaj dzia¨aj cymi instancjami i korzystaj z nich.
W przegl darce wpisz adres: http:// nazwa-hosta , w którym nazwa-hosta to publiczna
nazwa Twojej instancji.
JeĿli chcesz pod¨ czyø si¤ do dopiero co uruchomionego publicznego AMI, który nie zosta¨
jeszcze zmodyfikowany, skorzystaj z polecenia ec2-get-console-output.
W obu przypadkach masz moŞliwoĿø zalogowania si¤ jako administrator i sprawowania pe¨nej
kontroli nad instancj — odpowiada to podejĿciu do komputera w centrum danych i zalogowaniu
si¤ do niego.
Do róĝnych aspektów API chmury bÚdziemy jeszcze wracaÊ na dalszych
kartach tej ksiÈĝki. Na razie porzucimy ten temat i zajmiemy siÚ kolejnÈ waĝnÈ
warstwÈ: skïadowaniem danych w chmurze.
2.1.4. Przechowywanie trwaáych danych w chmurze
Bagaĝnik samochodu sïuĝy do przechowywania bagaĝu podróĝnego i caïej ma-
sy innych rzeczy. Analogicznie, chmura zapewnia miejsce, w którym moĝesz
przechowaÊ obrazy maszyn, aplikacje i wykorzystywane przez nie dane. Prze-
chowywanie danych w chmurze zyskuje popularnoĂÊ z tych samych powodów,
co przetwarzanie. Na ĝÈdanie otrzymujesz wirtualny magazyn danych w sieci,
wymagasz takĝe usïugi okreĂlonej jakoĂci. Inaczej niĝ w firmowym centrum
danych nie musisz kupowaÊ dysków — czasami nie musisz nawet zamawiaÊ
miejsca przed wysïaniem danych. Z reguïy pïacisz za iloĂÊ przesyïanych danych
oraz, co jakiĂ czas, za zajmowane przez nie miejsce.
Z przechowywania w chmurze moĝna korzystaÊ na róĝne sposoby. Przykïado-
wo moĝesz tworzyÊ kopie bezpieczeñstwa danych lokalnych, na przykïad tych
z prywatnego laptopa. Moĝesz zsynchronizowaÊ z chmurÈ dysk wirtualny i mieÊ
dostÚp do danych z róĝnych maszyn. Moĝesz równieĝ archiwizowaÊ dane
zgodnie z pewnÈ politykÈ, na przykïad w celu nadzorczym.
2.1.
Podstawy technologiczne przetwarzania w chmurze
55
Standard przechowywania danych w chmurze
Stowarzyszenie Storage Networking Industry Association powoäaäo specjalnñ grupö robo-
czñ, która miaäa zajñè siö wypracowaniem standardu skäadowania danych w chmurze.
Nowy interfejs CDMI (ang. Cloud Data Management Interface, interfejs zarzñdzania da-
nymi w chmurze) umoĔliwia uniwersalne, niezaleĔne od Ĉrodowiska zarzñdzanie takimi
danymi. W CDMI magazyn danych jest widziany przez interfejsy jako abstrakcyjny kontener.
Dodatkowo kontener uäatwia grupowanie danych i tworzenie agregatów.
Przechowywanie w chmurze sprawdzi siÚ w przypadku aplikacji, które do-
starczajÈ dane bezpoĂrednio do klientów w sieci. Aplikacja przekierowuje klienta
do odpowiedniej lokalizacji, gdzie pobiera on dane, na przykïad pliki audio czy
wideo. Wymagania zwiÈzane z przesyïaniem strumieni danych poprzez sieÊ bÚdÈ
siÚ skalowaïy niezaleĝnie i nie zaburzÈ dziaïania aplikacji.
Wykorzystuje siÚ tu interfejs HTTP. Moĝesz pobraÊ plik za pomocÈ prze-
glÈdarki bez pisania dodatkowego kodu — automatycznie uruchomi siÚ odpo-
wiednia aplikacja. Tylko jak umieĂciÊ plik w chmurze i jak upewniÊ siÚ, ĝe ma-
gazyn jest odpowiedniego typu i zapewnia wymaganÈ przez Ciebie jakoĂÊ?
Znów mamy do czynienia z szerokÈ ofertÈ. W tym wypadku nie dziwi, iĝ wielu
dostawców korzysta z interfejsów zgodnych z zasadami architektury REST.
NajczÚĂciej mamy do czynienia z interfejsem pozwalajÈcym na tworzenie, od-
czytywanie, aktualizacjÚ i usuwanie poszczególnych obiektów danych za po-
Ărednictwem metod HTTP.
Kolejny raz potraktujemy API chmury Amazon jako przykïad do analizy.
Tabela 2.3 przedstawia najwaĝniejsze elementy chmury S3.
Tabela 2.3. Podstawowe pojĊcia i operacje chmury danych Amazon S3
PojĊcie
Obiekt
Kube¨ek
Klucz
Wykorzystanie
Opis
Podstawowa jednostka sk¨adowana w chmurze danych S3. Obiekt moŞe mieø rozmiar
od 1 bajta do 5 gigabajtów. KaŞdy obiekt ma swoje metadane w postaci par klucz-wartoĿø,
opisuj cych obiekt.
Podstawowy kontener do przechowywania danych w chmurze S3. Obiekty wgrywa si¤ do
kube¨ków. Kube¨ek (ang. bucket) to unikalna przestrzeĬ nazw, umoŞliwiaj ca zarz dzanie ca¨
zawartoĿci . Nazwy kube¨ków s globalne. Jeden programista moŞe korzystaø jednoczeĿnie
z maksymalnie stu kube¨ków.
Klucz to unikalny identyfikator obiektu wewn trz kube¨ka. Nazwa kube¨ka po¨ czona z kluczem
jednoznacznie identyfikuje obiekt wewn trz ca¨ej chmury S3.
1. Stwórz kube¨ek, w którym b¤dziesz przechowywaø dane.
2. Za¨aduj (zapisz) dane (obiekty) do kube¨ka.
3. Pobierz (odczytaj) dane z kube¨ka.
4. Skasuj cz¤Ŀø danych przechowywanych w kube¨ku.
5. Wypisz obiekty znajduj ce si¤ w kube¨ku.
56
ROZDZIAà 2 Klasyfikacja chmur obliczeniowych
W wielu przypadkach „gruboziarnista” i nieuporzÈdkowana natura usïug
przechowywania w chmurach takich jak S3 okazuje siÚ niewystarczajÈca —
potrzebna jest alternatywna metoda przechowywania o ustalonej strukturze.
Spójrzmy zatem, jak dziaïajÈ (i nie dziaïajÈ) chmurowe bazy danych.
2.1.5. Przechowywanie danych aplikacji
w chmurowej bazie danych
Samochodowy system nawigacji na bieĝÈco informuje CiÚ o Twoim aktualnym
poïoĝeniu i odlegïoĂci od celu podróĝy. Prowadzi CiÚ drogÈ, którÈ musisz przebyÊ.
Tego typu dane, chociaĝ niezbÚdne w czasie podróĝy, po jej zakoñczeniu prze-
stajÈ byÊ przydatne. System nawigacyjny jest dla samochodu tym, czym chmurowa
baza danych dla aplikacji dziaïajÈcej w chmurze: dane transakcyjne sÈ tworzone
i wykorzystywane tylko w czasie dziaïania aplikacji. Gdy mówimy o transakcyjnych
danych przechowywanych w bazie, z reguïy myĂlimy o relacyjnych bazach danych.
Czym jest RDBMS i dlaczego czÚsto sïychaÊ, ĝe nie dziaïa on w chmurze?
RDBMS (ang. Relational Database Management System) to system zarzÈdzania
relacyjnÈ bazÈ danych, w której przechowuje siÚ dane w postaci tabel. Relacje
pomiÚdzy danymi takĝe reprezentowane sÈ przez tabele. Rysunek 2.4 przed-
stawia prosty przykïad.
Rysunek 2.4. Prosty przykáad dziaáania bazy relacyjnej. Cztery tabele odwzorowują
zaleĪnoĞci (relacje) pomiĊdzy danymi. Osobna tabela sáuĪy do prezentowania marek, inna
pokazuje kolory — dziĊki temu nie zachodzi koniecznoĞü oddzielnego reprezentowania na
przykáad czerwonego Nissana lub niebieskiego Forda. Jednak by w peáni zrozumieü, czym
jest samochód o identyfikatorze SamKlucz 1, musisz poáączyü tabele Samochód, Kolor,
Model i Marka
2.1.
Podstawy technologiczne przetwarzania w chmurze
57
RDBMS System zarzÈdzania bazÈ danych (ang. Database Management
System) opartÈ na modelu relacyjnym. Relacyjne bazy danych to bazy
naleĝÈce do doĂÊ rozlegïej klasy systemów bazodanowych, w których
dane sÈ prezentowane uĝytkownikowi w postaci relacji (zestaw tabel zïoĝo-
nych z wierszy i kolumn speïnia ten warunek), a on moĝe modyfikowaÊ
te dane za pomocÈ operatorów relacyjnych. Wszystkie wspóïczesne relacyj-
ne bazy danych wykorzystujÈ jÚzyk zapytañ SQL, przez co bazy RDBMS
czÚsto nazywa siÚ bazami SQL.
Wyzwaniem dla systemów RDBMS dziaïajÈcych w chmurze jest skalowalnoĂÊ.
Aplikacje o znanej liczbie uĝytkowników i obciÈĝeniu nie odnotujÈ kïopotów.
WiÚkszoĂÊ dostawców chmur oferuje usïugi RDBMS dla takich przypadków.
Jednak gdy aplikacje dziaïajÈ w Ărodowisku o duĝym obciÈĝeniu (jak w przy-
padku usïug sieciowych web services), ich wymagania dotyczÈce skalowalnoĂci
mogÈ zmieniaÊ siÚ (a zwïaszcza rosnÈÊ) bardzo szybko. ZmieniajÈce siÚ wymagania
sÈ problemem, gdy baza danych jest zainstalowana na pojedynczym serwerze
— jeĂli iloĂÊ danych codziennie siÚ potraja, jak szybko bÚdziesz nadÈĝaÊ z roz-
budowÈ sprzÚtu? Zbyt duĝa iloĂÊ danych moĝe
Pobierz darmowy fragment (pdf)
