sobota, 3 lipca 2010

Cloud - Z głową w chmurach.

Dziś będzie nieco mniej storagowo a więcej o ogólnym trendzie/modzie jaki od pewnego czasu można zaobserwować w IT. O co konkretnie chodzi , ano o chmurę (cloud) i o tzw "przetwarzanie w chmurze" (cloud computing).

Czym jest cloud computing?

Z technicznego punktu widzenia jest to połączenie dwóch metod: Grid Computingu i Utility Computingu.

  • Grid Computing
    Opiera się na przetwarzaniu równoległym. Duża ilość serwerów jest połączonych ze sobą w klaster/grid, dzięki temu ich moc obliczeniowa sumuje się i w efekcie dostajemy jedną "strukturę" o bardzo dużej mocy obliczeniowej.
  • Utility computing
    Bazuje na wirtualizacji i agregowaniu dostępnych zasobów w tzw: pule ( pools ). Nie interesuje nas już sam fizyczny sprzęt, czy to serwery czy storage, mamy kilka dużych "pojemników" z np: mocą obliczeniową, przestrzenią , przepustowością łącza i w razie potrzeby wydzielamy z niej maszyny wirtualne o zadanych przez nas parametrach.


Łącząc ze sobą grid i utility computing dostajemy w rezultacie wielki zbiornik z którego możemy czerpać ( oczywiście w ograniczony sposób ) i na bazie którego możemy tworzyć komputery wirtualne o wymaganych w danym momencie parametrach. Zbiornik ten nazwijmy chmurą.

Co daje nam zastosowanie modelu "chmurowego" i czym różni się to od tradycyjnego podejścia? Przede wszystkim odrywamy się od fizycznej architektury i wszystkich związanych z tym ograniczeń. Wyróżnia się trzy modele dostępu i wykorzystania zasobów z chmury:


  • SaaS ( Software as a Service )
    Praktycznie wszystko poza końcową aplikacją jest zwirtualizowane i umieszczone gdzieś w chmurze. Użytkownik traktuje oprogramowanie jako usługę , nie martwimy się kombatybilnością aplikacji z naszym komputerem, procesem instalacji czy zapewnieniem zgodności. Zamawiamy konkretne rozwiązanie jakiego dostarcza nam usługodawca i gotowe. Przykłady to choćby usługi dostarczane przez Google ( Docs , Gmail ) lub firmy oferujące miejsce na strony WWW.

  • PaaS ( Platform as a Service )
    Użytkownik ( consumer ) dostaje od dostawcy u środowisko ( platformę ) w którym może pisać własne aplikację. Wszystkie warstwy leżące poniżej tego, czyli między innymi system operacyjny , infrastruktura serwerowa i storage znajdują się w chmurze.

  • IaaS ( Infrastructure as a Service )
    W tym modelu w chmurze znajduje się "jedynie" fizyczna infrastruktura. Serwery, systemy pamięci masowych, osprzęt sieciowy jest ukryty i zwirtualizowany. Na tej bazie użytkownik instaluje i konfiguruje system operacyjny, systemy bazodanowe i końcowe aplikacje.


W zależności od wybranego modelu zmienia się zakres i poziom zasobów, którymi osobiście zarządzamy.

Kolejnym kryterium według którego możemy podzielić chmury, to sposoby w jaki zostanie ona zaprojektowana i stworzona ( a także w późniejszym okresie zarządzana ), tutaj także można wyróżnić trzy kategorie: chmura prywatna, publiczna i hybrydowa.


  • Chmura prywatna ( private )
    Cała infrastruktura stworzona w chmurze jest przydzielone dla jednego przedsiębiorstwa. Może ona być przygotowana i zarządzana przez firmę zewnętrzną lub przez wewnętrzne IT danej firmy. W tym drugim przypadku firma utrzymuje swoje własne serwerownie i ludzi nim zarządzających a z samego "cloud computingu" korzystają ludzie zajmujący się administracja na poziomie OS lub wyżej ( w zależności który model: SaaS, PaaS, IaaS jest wdrożony).

  • Chmura publiczna ( public )
    W tym rodzaju "cloud computingu" zasoby sprzętowe nie są dedykowane pod
    poszczególnych klientów korzystających z usług firmy dostarczającej "chmurę". Czasem taki model nazywa się "on demand" lub "pay as you go" - klient określa jakie parametry go interesują i płaci dokładnie za o co zamówił ( np: daną moc obliczeniową + pewną ilość pamięci masowej o zadanej wydajności). Jeżeli jego potrzeby rosną to "na żądanie" może zwiększyć zasoby w dzierżawionym przez siebie środowisku ( np: wykupić więcej mocy lub szybszy storage) i te dodatkowa usługa zostanie dodana w locie i bez potrzeby zatrzymywania pracujących aplikacji i maszyn wirtualnych.

  • Chmura hybrydowa ( hybrid )
    Połączenie filozofii chmury prywatnej i publicznej. Pewna część aplikacji i infrastruktury danego klienta pracuje w chmurze prywatnej a część jest umiescowiona w przestrzeni chmury publicznej.


Co daje nam chmura?

Oczywiście teoria teorią i można budować najrozmaitsze modele ale interesujące ( a chmura jest interesująca ) są tylko te które mają realne zastosowania i dodatkowo są w nich lepsze i bardziej innowacyjne niż to co już jest dostępne.
Jakie więc są plusy technologi "cloud computingu":


  • Zwiększone możliwości
    Korzystając z rozwiązań dostarczanych przez dostawcę "chmury" możemy wykorzystywać nowe funkcjonalności i rozwiązania techniczne bez żmudnego procesu przekonfigurowywania i migrowania aplikacji. Thin Provisioning , Automated tiering , deduplikacja - wykupujemy to jako usługę i praktycznie od razu korzystamy z ich dobrodziejstw.

  • Zwiększona wydajność
    Za to odpowiada dynamiczna alokacja zasobów, przykładowo nasza aplikacja w pewnym momencie wykazuje o wiele większe zapotrzebowanie na moc obliczeniową ( tzw: peak )- od razu dynamicznie większa moc zostaje z "chmury" przydzielona - nie ma spowolnienia działania i utraty wydajności.

  • Mniejsze koszta
    Przede wszystkim płacimy za to co tak naprawdę wykorzystujemy. W normalnych warunkach projektując środowisko serwerowe musimy dostarczyć taką wydajność żeby nasze serwery mogły obsłużyć momenty gdy obciżenie bardzo rośnie ( wspomniane w poprzednim punkcie "peaks" ). Korzystając z chmury wykupujemy tylko tyle mocy ( i innych zasobów ) ile realnie zużywamy, gdy w krótko trwających okresach będziemy potrzebowali dużo więcej "chmura" automatycznie nam to przydzieli a potem zabierze gdy już szczyt obciążenia minie. Dodatkowo odchodzą nam koszty związane z utrzymaniem infrastruktury ( prąd , klimatyzacja , koszty powierzchni w datacenter itd...)

  • Ograniczenie ryzyka
    Chodzi tutaj o ryzyko "przeinwestowania". Nie musimy alokować środków w dużych inwestycjach w infrastrukturę , nie musimy podpisywać dłogoterminowych kontraktów na wsparcie. Nie ma ryzyka że zainwestujemy w coś , co okaże się niepotrzebne.

  • Łatwa skalowalność
    Nasze wymagania rosną? Nie ma problemu - po prostu wykupujemy od "właściciela" chmury dodatkowe zasoby. Nie ma problemów z instalacją nowego sprzętu, migracjami ze starych struktur na nowe , pogodzenia ze sobą może nie do końca kompatybilnych architektur itd...

  • Łatwość zarządzania
    Koniec z wieloma punktami zarządzania. Osobnym na poziomie storage ( często i tak podzielonym jeszcze na poszczególne macierze, biblioteki itd...) , osobnym zarządzaniem na systemach , zarządzaniem serwerami , mainfraimem , zasobami sieciowymi itd... to wszystko jest już zrobione w "chmurze" , do nas trafia już samo "mięso" pod postacią zasobów gotowych do wykorzystania.



Ograniczenia chmury


Nie ma rzeczy idealnych, chmura to także nie jest "święty grall" stanowiący odpowiedź na wszystkie pytania i bolączki związane z IT.
Są dziedziny i konfiguracje które nie radzą sobie za dobrze w chmurze.


  • Ograniczenia związane z bezpieczeństwem danych.
    Jeżeli mówimy o chmurze prywatnej to użytkownik ma całkiem sporą kontrolę nad tym gdzie i w jaki sposób przechowywane są jego dane, sprawa się komplikuje jeżeli w grę wchodzi chmura publiczna lub hybrydowa - nasze dane mogą i najprawdopodobniej są rozrzucone po wielu lokacjach, które obejmować mogą więcej niż jeden kraj. Niektóre przedsiębiorstwa ( np: sektor bankowy ) mają bardzo restrykcyjne i narzucone odgórnie wymogi dotyczące przechowywania i dostępu do informacji jakie przetwarzają - umieszczenie ich gdzieś w nieokreślonej przestrzeni chmury może stanowić naruszenie tych standardów.


  • Ograniczenia związane z wydajnością aplikacji w chmurze
    Jednym z plusów działania w chmurze jaki został przezemnie wymieniony jest "Zwiększona wydajność". Jest to prawda jeżeli mówimy o sytuacjach gdy nasz program ma właśnie skok w obciążeniu i oprogramowanie chmury może mu dynamicznie i natychmiastowo przydzielić dodatkowe zasoby, są jednak aplikacje których przeniesienie do chmury może powodować problemy z szybkością działania. Są to zwykle aplikcaje działające w czasie rzeczywistym i wymagające bardzo szybkich odpowiedzi ze strony komponentów sprzętowych, ponieważ korzystamy z chmury więc sam końcowy hardware ( dyski , ram , procesory ) może być od nas bardzo odległy ( w sensie sieci IT czyli wiele "hopów" po drodze ), co z kolei spowoduje że opóźnienia będą na tyle duże iż nie damy rady zaspokoić potrzeb aplikacji działającej w "real-time"

  • Obawy związane z dostępnością danych i aplikacji
    Migracja do chmury może także budzić obawy dotyczące dostępności do danych w niej umieszczonych. Normalnie przedsiębiorstwa budują swoje polityki tzw "zachowania ciągłości" (eng: bussines continuity ) zawierające różne mechanizmy zabezpieczania się przed utratą danych , od stosowania redundantnych struktur na każdym poziomie i redukowania tzw SPOFów ( eng: Single Points of Failure ) aż po dublowanie całych centrów obliczeniowych i rozmieszczanie ich w różnych częściach kraju a następnie synchronizowanie i replikowanie zasobów między nimi. Korzystając z chmury publicznej użytkowanik końcowy nie ma de facto takiego wglądu w strukturę i zabezpieczenia jakim podlegają jego dane, musi pod tym względem zdać się na dostawcę danej usługi i umowę SLA jaką z nim podpisuje.



I to by było na tyle w ramach wprowadzenia do "cloud computingu".
Jeszcze film z youtube dla tych którzy wolą bardziej interaktywną prezentację:




Do poczytania:
"Cloud Computing" w Google i wyników aż nad to ;)

Brak komentarzy:

Prześlij komentarz