Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
01421 026618 16223417 na godz. na dobę w sumie
Chmura obliczeniowa. Rozwiązania dla biznesu - książka
Chmura obliczeniowa. Rozwiązania dla biznesu - książka
Autor: , Liczba stron: 280
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3416-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> inne
Porównaj ceny (książka, ebook, audiobook).

Odkryj wielką moc chmur obliczeniowych i potencjał, jaki kryją w sobie!

Jeszcze parę lat temu udostępnienie dużej, popularnej aplikacji wiązało się z ogromnymi wydatkami na infrastrukturę. Konieczne było posiadanie własnej serwerowni, wynajmowanie przestrzeni w centrum danych lub uciekanie się do innych kosztownych rozwiązań. W tej chwili na zawołanie można otrzymać dokładnie tyle mocy obliczeniowej i przestrzeni dyskowej, ile w danej chwili jest potrzebne. Zmartwienia związane z nagłymi i chwilowymi wzrostami obciążenia odeszły na zawsze, a dostępność Twoich aplikacji na poziomie bliskim 100% przez okrągły rok jest w zasięgu ręki. Jak to możliwe?

Książka ta wprowadzi Cię w świat, jakiego nie znałeś. Dowiesz się, czym są chmury obliczeniowe, kiedy z nich korzystać i co w nich umieszczać. Poznasz obecnych na rynku dostawców i ich platformy: Google App Engine, Amazon EC2, Windows Azure oraz Salesforce.com i Force.com. Każda z nich ma swoje mocne i słabe strony oraz sprawdza się najlepiej w innych rozwiązaniach. Po lekturze tej książki bezbłędnie wybierzesz najlepsze z nich - idealnie dopasowane do Twoich potrzeb. W kolejnych rozdziałach autorzy poruszają kwestie związane z bezpieczeństwem w chmurze, omawiają najlepsze wzorce dla aplikacji w niej działających oraz sposoby szacowania kosztów przechowywania danych. Znajdziesz tu też sposoby prowadzenia testów i wdrażania aplikacji w chmurach. Chmury obliczeniowe są przyszłością świata informatyki - głównie w sferze biznesu. Nie pozostawaj w tyle i już dziś sięgnij po kompendium, które otworzy przed Twoją firmą nowe możliwości!

Wyjdź naprzeciw nowym technologiom i przenieś swój biznes do chmury!

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Chmura obliczeniowa. Rozwiązania dla biznesu
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: