Jak zaplanować infrastrukturę w chmurze i jak wyliczyć jej koszt

Jak zaplanować swoją infrastrukturę w chmurze i jak wyliczyć jej precyzyjny koszt?

Maciej Kuźniar 20.06.2014

Kwestia doboru odpowiedniej infrastruktury to jedno z najważniejszych zagadnień podczas przesiadki na chmurę. Na szczęście nie jest to aż tak skomplikowane, jak mogłoby się wydawać, i sprowadza się do przyswojenia kilku zasad związanych z chmurową optymalizacją.

Z racji tego, że cloud computing to technologia stosunkowo nowa i wiele firm wciąż spotyka się z nią po raz pierwszy, warto przy takim spotkaniu wykorzystać szansę na przemyślenie i uporządkowanie swojej dotychczasowej filozofii używania infrastruktury IT. W dużym uogólnieniu drogi są dwie:

  1. można zwyczajnie przenieść swoją dotychczasową architekturę do chmury (bo są w niej wszystkie standardowe usługi: serwery, dyski, storage oraz interfejsy sieciowe),

  2. można wykorzystać ten moment do optymalizacji naszych dotychczasowych pomysłów.

Zapytajcie swoich administratorów (lub samych siebie) i z pewnością usłyszycie, że dzięki chmurze dostaną oni w swoje ręce zabawki, o których do tej pory mogli tylko pomarzyć. Dlaczego? Otóż jedna instancja OCI o mocy: 64 GB RAM, 16 VCPU x 2,5 Ghz z łatwością może zastąpić nawet kilka wysłużonych już serwerów, a w akompaniamencie ultra szybkich dysków OVS, kontenerów, loadbalancingu i Autoskalera ukaże ona przed każdym wydajność nieosiągalną do tej pory dla większości firm (poza naprawdę dużymi firmami, które było stać na rozwiązania storage’owe za kilka milionów złotych).

W połowie drogi

Migracja do chmury obliczeniowej jest więc szansą dla firmy, aby przeprowadzić optymalizację obecnej infrastruktury – to fakt, są jednak i takie wdrożenia, gdzie trzeba zacząć od zera. Tym krokiem zerowym często jest odwzorowanie fizycznego sprzętu tak, aby miał on swój odpowiednik w chmurze. Jest to zwykle zadanie, którego podejmuje się administrator, architekt systemów IT czy też dyrektor działu IT.

W Oktawave postanowiliśmy spotkać się z administratorami w połowie drogi. Naszym klientom z jednej strony dajemy całkowitą wolność w zakresie budowy swojej architektury, z drugiej pomagamy w doborze parametrów, a w razie potrzeby i na wyraźne życzenie nawet je korygujemy. Nam zależy na zadowolonych z naszych usług klientach, których zadowolenie wynika nie tylko z wydajności ich maszyn, ale również optymalizacji kosztowej.

Zrób to sam

Chociaż dostawca chmury może pomóc we wstępnej konfiguracji (i często robimy to z wykorzystaniem naszych ninja), to i tak dobrze jest samemu wiedzieć, jak zaprojektować architekturę IT w chmurze. Jak już wstępnie wspomnieliśmy, pewnym minimum może być utrzymanie w chmurze logiki infrastruktury fizycznej. Najłatwiej ugryźć to zagadnienie przy pomocy poniższego schematu.

Do dopełnienia obrazu potrzebny jest jeszcze jeden schemat, który pokazuje ruch.

Powyższe schematy przedstawiają środowiska informatyczne w ujęciu infrastruktury fizycznej i logicznej, jakie można znaleźć w wielu firmach. W przykładzie widać, że taka infrastruktura chroniona jest przez urządzenie zabezpieczające i filtrujące dostęp do serwerów firmowych.

Co jest po drugiej stronie firewalla?

Po drugiej stronie zapory ogniowej administratorzy mogą stworzyć wymaganą liczbę sieci prywatnych, pamiętając o takich aspektach jak np. ustalenie, które z tych sieci znajdą się w DMZ (strefie zdemilitaryzowanej, ograniczonego zaufania), lub do których maszyn będzie przyznany dostęp publiczny, oraz z którymi będą komunikować się pozostałe serwery (bez wymaganego dostępu dla użytkowników).

Na drugim schemacie widać, że serwer pełniący funkcję bramki Exchange’a został udostępniony publicznie, jednak pozostałe sieci nie posiadają już dostępu publicznego.

Jest to bardzo standardowa konfiguracja, którą można traktować jako wyjściową i modyfikować w zależności od konkretnych potrzeb.

Jakiej dokładnie klasy maszynę potrzebuję?

Infrastruktura w chmurze to jednak nie tylko aspekt firmowego backendu. Jeśli moc obliczeniowa chmury potrzebna jest do zasilenia aplikacji, która dostępna będzie szerszemu gronu odbiorców, to trudne będzie dokładne oszacowanie, jakiej klasy infrastruktura będzie potrzebna.

Są ku temu dwa powody:

  1. po pierwsze, kod aplikacji jest zawsze inny (inaczej zoptymalizowany, posiadający więcej lub mniej błędów),

  2. po drugie, różna może być ilość spodziewanego ruchu w takiej aplikacji, z tego względu faza testowa jest obowiązkowym punktem każdego wdrożenia.

Technologie chmury odpowiadające za rozkładanie ruchu i automatyczne skalowanie infrastruktury (Autoskaler, loadbalancing) są oczywiście odpowiedzią na takie problemy, jednak nie wszyscy chcą i potrafią z nich korzystać. W takim przypadku, jeśli administrator nie zda się na automat, musi wykonać stosowne obliczenia.

Dość trudno jest stwierdzić, bez żadnych testów, jaka maszyna w chmurze zaspokoi potrzeby konkretnego klienta. Dlatego w Oktawave zawsze pozwalamy testować.

Wszystko zależy bowiem od tego, co taki serwer ma robić. Wiedza administratorów ma również bezpośrednie przełożenie na to, z jakiej klasy maszyny będzie korzystać firma – dla przykładu, odpowiednia konfiguracja serwera nginx może obniżyć wymaganą moc firmowej maszyny nawet o jedną klasę, tym samym w prosty sposób prowadząc do wymiernych oszczędności.

Oczywiście sama konfiguracja nie będzie wystarczająca, jeśli skorzystamy z chmury słabych lub przeciętnych osiągach. Tak jak we wszystkich dziedzinach, również w przypadku chmur obliczeniowych, istnieją bowiem rozwiązania lepsze i gorsze. My w Oktawave akurat nie mamy powodów do wstydu i z radością przypominamy o naszych osiągach potwierdzonych przez niezależny test CloudHarmony.

Ten jeden wykres, przedstawiający szybkość dostępu do danych (czyli np. komunikacji między bazą danych a CPU), po prostu musi dawać do myślenia. Mamy ich więcej, sprawdźcie sami.

Ogromne znacznie ma też to, z jakiego kodu zewnętrznego korzysta firma. Znam przypadki, gdzie źle przygotowane wtyczki do WordPressa i nieodpowiednio napisane skrypty obciążały wybrane instancje do granic możliwości – i to przy niewielkim ruchu. Z drugiej strony, po zamianie wtyczek, przy ruchu setki razy większym, możliwe było nawet… obniżenie klasy maszyny.

Jak to wygląda w przypadku migracji?

Jeśli mamy do czynienia z migracją, a nie nowym wdrożeniem, to najczęstszą praktyką jest oparcie się po prostu o dane dotychczasowej maszyny. Dla spokoju ducha, przy wyborze klasy maszyny, administratorzy często zaokrąglali parametry w górę.

Jeśli zatem dotychczasowa infrastruktura to serwer, w którym znajdowało się 4 GB RAM oraz 2 CPU, a w ofercie dostawcy chmury nie ma maszyny o takiej klasie, to zazwyczaj wybierano pozycję wyżej, np. z 4 GB RAM, 4 VCPU (np. nasza instancja klasy Large).

To nie jest złe podejście, można wręcz powiedzieć, że coś w rodzaju pewniaka. Ale klasa maszyny to jednak nie wszystko, nie zapominajmy o storage’u – ten w chmurze, przewyższa to, co do zaoferowania mają serwery dedykowane. Jeśli zapoznaliście się z wspomnianymi wyżej wynikami niezależnego testu CloudHarmony, to spróbujcie zestawić je ze swoimi benchmarkami.

Administratorzy bardzo często mylą ze sobą dwa problemy:

  1. CPU wait,

  2. IO wait.

Ten pierwszy problem to niewystarczająca moc procesora do obsługi zapytań, po prostu: CPU nie ma wystarczająco dużo zasobów, by przetworzyć informacje, które do niego napływają. Druga sytuacja jest odmienna, procesor się nudzi, a dysk nie jest w stanie wystarczająco szybko dostarczać do CPU informacji. Rezultat jednak jest podobny (brak zrealizowanego np. zapytania do bazy), dlatego często mylony.

Dlatego tak ważne jest, by uświadomić sobie, że niekoniecznie potrzebujemy więcej procesorów, a bardzo często mniejsza i tańsza architektura w chmurze zrobi dla nas to samo, co fizyczna o wyższych parametrach, ponieważ to chmura właśnie oferuje najbardziej wydajne dyski.

Ile za to zapłacę?

Pytanie o koszty serwera jest jednym z najczęściej słyszanych przez dostawców chmury. Wynika to z tego, że cennik chmury obliczeniowej nie jest tak prosty, jak w przypadku innych rozwiązań hostingowych. W dużej mierze wynika to z jednej z najfajniejszych cech chmury: jej elastyczności.

Trzeba pamiętać, że chmura nie przywiązuje klienta wyłącznie do jednej konfiguracji sprzętowej, na której trzeba się opierać. W każdej chwili klient może zmienić klasę swojej maszyny z podstawowego serwera posiadającego np. 0,5 GB RAM-u i jeden procesora VCPU, do prawdziwego monstrum z 64 GB pamięci operacyjnej i szesnastoma procesorami.

Natura chmury komplikuje jednak jej wycenę, ale zarazem możliwość elastycznej wyceny gwarantuje przewidywalność i kontrolę.

Zmiana klasy takiej maszyny może odbywać się automatycznie lub ręcznie, co jest niepowtarzalną zaletą chmury. Trzeba bowiem pamiętać, że korzystając z chmury obliczeniowej klient płaci jedynie za realnie wykorzystane zasoby, więc nie płaci się za moc obliczeniową, która nie jest aktualnie do niczego wykorzystywana. To z kolei oznacza, że podczas wyceny trzeba wziąć pod uwagę wiele parametrów (CPU, RAM, wielkość dysku, wielkość storage, transfer, IOPS), które teraz omówię na podstawie konkretnego przykładu.

Pora na konkrety

Po oszacowaniu, jakiej mniej więcej klasy maszyny potrzeba, nadchodzi kolej na wybranie pasującej do tych wymagań instancji. Trzeba w tym miejscu oczywiście pamiętać, że różni dostawcy chmury w inny sposób nazywają to, co my w Oktawave nazywamy instancją. Dostępne predefiniowane konfiguracje środowisk RAM i VCPU są również różne u poszczególnych dostawców chmury.

Ja naturalnie skupię się na naszej ofercie. Zaznaczę też, że wielu klientów decyduje się początkowo na instancję o małej mocy, a dopiero po testach, jeśli jest taka potrzeba, przesiadają się na lepszej klasy instancję. To oczywiście nie jest problem, a góra minuta roboty. Chmura to nie serwer dedykowany, o czym wspominałem już wielokrotnie.

Jak wyglądają obliczenia w praktyce?

Za przykład do wykonania obliczeń może posłużyć OCI (Oktawave Cloud Instance) o klasie Mini. OCI w wersji Mini posiada 0,5 GB RAM oraz jeden VCPU taktowany zegarem 2,5 GHz. Taka maszynka wystarczy do prowadzenia niezbyt obleganej firmowej strony internetowej. Sprawdzi się też bardzo dobrze jako maszyna do backupu lub chociażby jako baza dla serwera DNS. W obliczeniach skupię się na tym ostatnim przykładzie.

Oprócz wyboru klasy instancji trzeba wybrać również system operacyjny: Windows albo Linux. Do wyznaczonych wcześniej celów wystarczy ten drugi, za który nie trzeba dodatkowo płacić opłaty licencyjnej. Koszt pracy takiej instancji za godzinę to 6 groszy, który trzeba pomnożyć przez liczbę godzin w miesiącu, a wynikiem jest kwota wynosząca 43,92 złotych – przy założeniu, że jeden miesiąc w skali roku ma średnio 732 godziny.

Rozliczenie miesięczne

Kolejna rzecz, którą należy wziąć pod uwagę, to transfer wychodzący w rozliczeniu miesięcznym. Jeśli chmura służy za bazę dla serwera DNS, to powinno wystarczyć 1 GB takiego transferu. Do kwoty wyżej należy dodać zatem… 0,02 złotego. Powtórzę, żeby nie było niedomówień, albo domysłów, czy to czasem nie jest jakiś błąd: 1 GB transferu wychodzącego kosztuje w Oktawave dokładnie dwa grosze.

Serwery DNS nie są również wymagające (w kontekście firmowych infrastruktur) jeśli chodzi o przestrzeń dyskową. Można założyć, że 15 GB będzie wystarczającą przestrzenią. Jedna godzina korzystania z dysku o pojemności 1 GB kosztuje 0,0004 zł. Po przemnożeniu tej wartości o przez 24 godziny, a później przez średnią liczbę dni w miesiącu (30,5 dnia) oraz finalnie przez ilość pożądanej przestrzeni – u nas jest to 15 GB – otrzymamy kwotę 4,39 zł.

Co dalej?

Po wyliczeniu kosztów pracy instancji, transferu i przestrzeni dyskowej należy podliczyć liczbę operacji na dysku, tzw. IOPS (operacje wejścia/wyjścia na sekundę, ang. Input/Output Operations Per Second). Przy założeniu wykorzystania dysku z pierwszego Tiera, który jest ograniczony do 1000 operacji wejścia/wyjścia na sekundę, prosty rachunek wskazuje 2 635 200 000 IOPS w odniesieniu miesięcznym.

Takie jest maksimum, jednak w omawianym przykładzie nawet nie zbliżymy się do takiej liczby IOPS. Założyć można wykorzystanie pięciu procent tej liczby, czyli dokładnie 131 760 000 IOPS. Po zaokrągleniu liczbę milionów operacji (w tym wypadku 131) mnoży się przez kwotę 4 groszy, co daje wynik 5,24 złotego.

Całkowity koszt to nieco ponad 50 złotych.

Do kwoty za liczbę operacji dodaje się cenę samej przestrzeń danych (4,39 złotego), co finalnie wynosi 9,63 złotych – dokładnie tyle kosztuje w Oktawave 15 GB przestrzeni miesięcznie. Kwota całkowita za serwer to natomiast suma cen za dysk, instancję oraz transfer. W naszym przykładzie jest to dokładnie 53,57 złotego.

Serwer DNS uruchomiony na Oktawave Cloud Instance o klasie Mini to oczywiście tylko jeden przykład. Po więcej informacji na temat szacunkowych obliczeń dotyczących miesięcznego kosztu chmury mogę odesłać do naszego artykułu w bazie wiedzy pod tytułem “Jak planować budżet na infrastrukturę w chmurze obliczeniowej Oktawave”.

Oczywiście wszystkie podane powyżej ceny pochodzą z naszego cennika, więc możecie mnie sprawdzić.

Podsumowanie

Po lekturze powyższego artykułu wiecie już, jak odwzorować pożądaną infrastrukturę w chmurze i jak obliczyć jej koszt. Dowiedzieliście się też, że nie musicie się obawiać przeszacowania lub niedoszacowania infrastruktury, bo możecie liczyć na pomoc ze strony dostawcy chmury, a finalnie szybko zmienić jej parametry. Oprócz tego w Oktawave możecie na spokojnie przeprowadzić testy wydajnościowe samodzielnie i to zupełnie za darmo.

Każdy nowy klient otrzymuje od nas 25zł na start. To w zupełności wystarczy, aby przekonać się, która klasa maszyny jest odpowiednia dla waszej firmowej infrastruktury, jeśli chcecie się przekonać na własnym przykładzie, czy migracja faktycznie będzie opłacalna.

Maciej Kuźniar, prezes Oktawave sp. z o.o. oraz główny architekt. Pasjonat technologii związanych z przetwarzaniem i przechowywaniem danych, posiadający 12 lat doświadczenia w pracy dla klientów klasy enterprise (banki, telekomy, FMCG). Autor koncepcji technologicznie wspierających rozwój startupów oraz rozwiązań architektonicznych gwarantujących wysokie HA i SLA dla systemów IT.

- - - - - - - -

Chmura obliczeniowa zakorzeniła się w naszym życiu codziennym do tego stopnia, że coraz trudniej jest przeciętnemu użytkownikowi ignorować jej obecność. Czasem jednak terminologia związana z tą dynamicznie rozwijającą się gałęzią usług internetowych potrafi być niejasna. Postanowiliśmy przygotować więc materiał wprowadzający dla osób, które nie miały jeszcze okazji zagłębić się w tajniki chmury obliczeniowej, tak by nie czuły się zagubione podczas wyboru właściwych produktów i usług.

W poniższym artykule, rozpoczynającym na Spider’s Web nowy cykl poświęcony zagadnieniom związanym z chmurą obliczeniową, zaczynamy od zamieszczenia słowniczka najważniejszych pojęć. Wyjaśniamy w nim krótko i zwięźle takie terminy jak wirtualizacja, hiperwizor, serwer wirtualny, storage blokowy, IOPS, tier dyskowy czy storage obiektowy. Porównujemy też modele chmury, takie jak IaaS, PaaS i SaaS.

Poniższy tekst to zaledwie zalążek większej serii materiałów, w których systematycznie będziemy poszerzać poruszone tutaj tematy. W naszym cyklu publikacji będziemy również posiłkować się tym, co już w przeszłości zostało opublikowane na łamach Spider’s Web w postaci właściwych odniesień.

Słownik pojęć podstawowych

Zaczniemy od zapoznania się z podstawowymi pojęciami, które będą się pojawiać w kolejnych tekstach traktujących o chmurze obliczeniowej.

Wirtualizacja

Punktem zerowym na drodze do poznawania chmury jest zrozumienie pojęcia wirtualizacji. W kontekście chmury obliczeniowej, wirtualizacja to możliwość uruchomienia kilku różnych systemów operacyjnych, na kilku odrębnych maszynach wirtualnych, które działają na jednej lub wielu maszynach fizycznych. Oznacza to, że wirtualizacja pozwala na podział zasobów fizycznych, przydzielenie ich do maszyn wirtualnych oraz taką emulację, że system operacyjny ma wrażenie działania na fizycznym sprzęcie.

Oczywiste korzyści płynące z wirtualizacji to oszczędności – zamiast pięciu różnych maszyn, możemy uruchomić jedną i tak rozdzielić jej zasoby, aby pomieściło się na niej pięć zwirtualizowanych środowisk, każde ze swoim systemem operacyjnym. Takie rozwiązanie pozwala na bardziej wydajną utylizacje zasobów, ale z drugiej strony wprowadza jedną z największych zalet dla całej chmury obliczeniowej: uniezależnia środowisko uruchomieniowe od konkretnej maszyny fizycznej. To wprost prowadzi do sytuacji, w której awaria sprzętowa nie musi już wpływać na awarię systemu operacyjnego czy samej maszyny wirtualnej. W razie uszkodzenia sprzętowego zasoby mogą być bardzo łatwo i nawet bez widoczności dla klienta przeniesione do innego zasobu fizycznego, zachowując ciągłość pracy.

Finalnie, zwirtualizowanie środowiska uruchomieniowego pozwala na pełną elastyczność w sposobie jego definiowania oraz skalowania. Teraz, żeby dołożyć do maszyny pamięci RAM, możemy się zalogować do panelu zarządzania i zmienić klasę maszyny. Wcześniej musieliśmy udać się ze śrubokrętem do serwerowni.

Hiperwizor

Hiperwizor (ang. hypervisor) czy też hipernadzorca, to oprogramowanie, które czuwa nad prawidłowym procesem wirtualizacji zasobów. Najczęściej spotykane hiperwizory to:

Wybór hiperwizora może mieć bezpośredni wpływ na dostępność niektórych systemów operacyjnych czy też ich konkretnych wersji – mówimy wówczas o tzw. parawirtualizacji. Jeśli jednak wybierzemy pełną wirtualizację, wówczas w wirtualnej maszynie będziemy mogli uruchomić dowolny OS.

Tutaj warto zaznaczyć, że architektura chmury obliczeniowej Oktawave już w momencie planowania była przemyślana tak, aby całe rozwiązanie było agnostyczne względem hiperwizorów (to znaczy tak, by można je było łatwo wymieniać), choć obecnie korzystamy z – według nas najlepszego obecnie hiperwizora – VMware ESXi, który daje możliwość pełnej wirtualizacji.

Serwer wirtualny

Tak oto przechodzimy do pojęcia serwera wirtualnego, zwanego także maszyną wirtualną. Jest to środowisko uruchomieniowe, które kontroluje wszystkie odwołania oprogramowania do sprzętu oraz do systemu operacyjnego, który został w nim uruchomiony. Innymi słowy serwer wirtualny udostępnia wszystko to, co udostępniłby dla aplikacji serwer fizyczny (moc procesora, pamięć, operacje I/O, przerwania etc.), ale w sposób zwirtualizowany.

Wirtualne serwery z perspektywy użytkownika niczym nie różnią się od fizycznego serwera. Działają pod kontrolą określonego systemu operacyjnego, wgrywanego z przygotowanych przez dostawcę obrazów maszyn wirtualnych (są to zwykle różne dystrybucje Linuksa, Windows Servera, FreeBSD czy Solarisa). Charakteryzują się określoną wydajnością, regulowaną liczbą wirtualnych procesorów i wielkością pamięci.

Różni dostawcy różnie nazywają ten typ usługi. Amazon Web Services określa ją jako Elastic Computing Cloud, Rackspace nazywa ją Cloud Server, w Oktawave mówimy o Oktawave Cloud Instance (czyli o instancjach chmury). Funkcjonalnie nie ma między nimi większych różnic, bez problemów można przenieść aplikacje między serwerami wirtualnymi u różnych dostawców chmury, chyba że korzystają one z unikatowych dla danej chmury interfejsów programowania.

Warto podkreślić, że sam serwer wirtualny w chmurze (czyli tzw. instancja lub jednostka obliczeniowa) to tylko RAM i procesor. Co nakazuje nam wprowadzić i wyjaśnić nowe pojęcie: storage’u blokowego (czyli dysku).

Storage blokowy (dysk)

Storage blokowy należy rozumieć jako wydzielony obszar na fizycznym dysku twardym, który umożliwia zapisywanie i odczytywanie danych w postaci bloków. Jest on szczególnie ważny dla sytuacji, w których musimy często odwoływać się do zasobów danych przechowywanych w postaci plików (np. otwierać je, pobierać z nich dane, zmieniać w nich fragmenty danych), np. systemów operacyjnych czy baz danych. Innymi słowy storage blokowy to odpowiednik dysku twardego komputera.

Ważne jest to, że w chmurze obliczeniowej po uruchomieniu serwera wirtualnego musimy do niego podłączyć dysk (storage blokowy właśnie), aby móc na nim zainstalować system operacyjny i inne aplikacje. Sam dysk możemy w chmurze podłączyć do kilku serwerów wirtualnych, podobnie jak kilka serwerów do jednego dysku.

W Oktawave taka usługa nazywa się Oktawave Volume Storage, u innych dostawców są to np. Amazon Elastic Block Store czy Rackspace CloudBlock Storage.

IOPS

Kolejnym terminem, na który często napotkacie podczas czytania o chmurze obliczeniowej, jest IOPS, czyli operacje wejścia/wyjścia na sekundę – z ang. Input/Output Operations Per Second. Taką wielkością określa się wydajność dysków blokowych podłączanych do serwera wirtualnego. Operacje wejścia/wyjścia to nic innego jak próby zapisu lub odczytu danych z dysku. Im większa jest ta liczba, tym częściej i szybciej dysk może dostarczać dane do procesora, co jest kluczowe dla wydajności wszelkich obliczeń.

Zwiększenie parametrów IOPS stało się obecnie jednym z kluczowych aspektów wydajnych systemów IT, ponieważ pozwoliło wyeliminować tzw. I/O wait, czyli sytuację, w której procesor czeka na storage, ponieważ ten nie jest w stanie dostarczyć mu wystarczająco szybko danych do przeprowadzenia obliczeń. Nie musimy dodawać, jak wielkie ma to znaczenie w czasach Big data.

Tier dyskowy

Tier dyskowy to jego klasa wydajności. Tiery dyskowe charakteryzowane są różnie przez poszczególnych dostawców. Dla przykładu w Oktawave prezentują się one następująco:

Dla tradycyjnych serwerów wirtualnych bardzo często jedynym parametrem jest wielkość wirtualnego dysku. Należy jednak mieć na uwadze, że parametr ten jest dla aplikacji internetowych zwykle najmniej ważny. Co z tego, że klient dostanie wirtualny dysk o przykładowej pojemności 50 GB, skoro dostęp do niego będzie spowolniony działaniem wszystkich innych wirtualnych dysków, znajdujących się na tym samym fizycznym urządzeniu?

Prawdziwa chmura obliczeniowa oferuje klientom nie tylko przypisane dla ich dysków miejsce, ale też gwarantuje ich wydajność, wyrażoną właśnie parametrem IOPS.

Można założyć, że standardowe dyski magnetyczne (z interfejsami SAS/SATA/FC) zapewniają wydajność około 200 IOPS. Wirtualna pamięć dyskowa może zapewnić maszynom wirtualnym, w zależności od wybranej klasy wolumenu, od tysiąca do nawet 200 tysięcy IOPS. Istotne jest to, że klient może nie tylko dowolnie konfigurować dostęp do wolumenów (np. przypisując wielu instancjom serwerowym ten sam wolumen), ale też w każdej chwili zmienić jego parametry.

Koszty tak gwarantowanego dostępu są naprawdę niewielkie, zwykle nie przekraczają kilkudziesięciu groszy miesięcznie nawet dla dużych serwisów WWW, pozwalają jednak dostawcom prawdziwych chmur na kontrolowanie zużycia zasobów przez wszystkich użytkowników, a finalnie – możliwość ich gwarancji.

Storage obiektowy (magazyn danych)

Decydując się na chmurę, warto wybrać takiego dostawcę, który w ramach systemu przechowywania danych oferuje zarówno dyski blokowe (dla systemu operacyjnego oraz baz danych), jak również storage obiektowy, gdzie dane przechowywane są w postaci dowolnych obiektów hierarchizowanych do struktur np. drzew lub list. Storage obiektowy różni się od blokowego przede wszystkim tym, że pozwala na zapisywanie i odczytywanie do niego całych obiektów, bez względu na ich rozmiar – dlatego tak dobrze sprawdza się jako magazyn zdjęć, wideo oraz innych obiektów statycznych.

Kiedy w dysku blokowym liczy się szybkość, z którą procesor może otworzyć jakiś zasób (np. bazę danych), dokonać w niej zmian i ją zamknąć, tak w storage’u obiektowym liczy się możliwość taniego i wydajnego przechowywania dużych obiektów i uniezależnienia takiego storage’u od powiązania z konkretnym serwerem wirtualnym.

Więcej na temat obiektowego storage’u przeczytasz w artykule “Obiektowy storage w chmurze. Hardcore? Nie, to jest dla ludzi!”, który jakiś czas temu ukazał się na łamach Spider’s Web.

Modele chmury

Chmura obliczeniowa trafia do klientów końcowych jako sprecyzowany model. Takich modeli jest kilka. Można jednak śmiało przyjąć, że istnieją trzy główne modele chmury obliczeniowej: IaaS, PaaS oraz SaaS.

IaaS

IaaS (z ang. Infrastructure as a Service), czyli infrastruktura jako usługa. Jest to model, który polega na udostępnianiu użytkownikowi końcowemu sprzętu, czyli infrastruktury (na którą składają się procesory, RAM, dyski blokowe, storage obiektowy oraz interfejsy sieciowe). Zamiast ponosić nakłady finansowe na zakup sprzętu i oprogramowania, klient „wypożycza” je w ramach wykupionej usługi.

Za taką usługę klient płaci w zależności od realnie zużytych zasobów, czyli płaci tylko wtedy, kiedy faktycznie korzysta z infrastruktury. Jeśli infrastruktura klienta nie musi pracować w nocy, to za ten czas klient nic nie płaci.

Z chmurą typu IaaS mamy do czynienia, kiedy mówimy o serwerze w chmurze. Jeśli zatem w ofertach różnych dostawców chmury, w tym również i u Oktawave, spotkacie się z terminem serwera w chmurze, to powinna się Wam zapalić lampka – „IaaS”.

PaaS

PaaS (z ang. Platform as a Service), czyli platforma jako usługa. Przez platformę należy tutaj rozumieć gotowe (lub prawie gotowe) środowisko do uruchomienia aplikacji. Bardzo często odbiorcami takiego modelu chmury są firmy zatrudniające programistów – w takich przypadkach uruchomienie stanowiska do pracy z odpowiednio przygotowanym frameworkiem uruchomieniowym to zaledwie kilka minut. PaaS pozwala koderom na skupienie się tylko na kodzie, a nie na przygotowywaniu całej infrastruktury sprzętowej służącej do jego wykonania lub uruchomienia. Dostawcy PaaS załatwiają całą tę robotę za dewelopera – ma to oczywiste przewagi (szybkość uruchomienia), jak również ograniczenia (deweloper nie ma de facto wpływu na środowisko uruchomieniowe i nie może go dostosować do własnych potrzeb).

PaaS to nie tylko gotowe frameworki dla programistów. Ten model chmury obliczeniowej ma szersze zastosowanie, np. świetnie się nadaje do przeprowadzania testów obciążeniowych.

Na łamach Spider’s Web pisaliśmy już szerzej o modelu PaaS w artykule “Chmura obliczeniowa dla programisty. O czym każdy koder wiedzieć musi”.

SaaS

SaaS (z ang. Software as a Service), czyli oprogramowanie jako usługa. To chyba najczęściej spotykany model chmury, czyli po prostu aplikacje działające w chmurze. Taką aplikacją może być klient pocztowy (np. Gmail), program do edytowania grafiki w przeglądarce internetowej (np. pixlr.com) czy też aplikacja na smartfonie.

W modelu SaaS działa również wiele programów firmowych dostępnych jedynie dla pracowników danej firmy – wszelkiego rodzaju CRM-y, CMS-y, itd. W tym modelu klient nie zajmuje się ani sprzętem, ani środowiskiem do uruchomienia aplikacji, po prostu uruchamia gotowe rozwiązanie. Podobnie jak w wypadku PaaS zaletą będzie szybkość uruchomienia gotowego do pracy środowiska, a wadą całkowita zależność od dostawcy oprogramowania.

Podsumowanie

Dobrnęliśmy do końca, a jeśli dobrnąłeś/aś z nami, to wiesz już wszystko, co trzeba wiedzieć na temat podstaw chmury obliczeniowej. W kolejnych odcinkach nauczymy Cię korzystać z tych zasobów.

- - - - - - - -

Wszystko jest dobre, jeśli do rąk nie dostaniesz czegoś lepszego. Tak jest również z tradycyjnymi serwerami oraz tymi uruchomionymi w chmurze obliczeniowej. Czym więc różni się serwer dedykowany od serwera w chmurze i jakie są konkretne przewagi tego drugiego? W poniższym materiale zestawiamy ze sobą technologie, które tylko na pierwszy rzut oka są podobne pod względem możliwości. Pokazujemy też zmianę w sposobie wykorzystywania zasobów wprowadzoną przez cloud computing oraz wskazujemy, jak można na niej skorzystać.

Zapraszamy do kolejnego artykułu z naszego cyklu poświęconego zagadnieniu cloud computingu. Dzisiaj skupimy się na tym, czym różni się serwer uruchomiony w chmurze obliczeniowej od klasycznego rozwiązania zwanego “dedykiem”. Osoby, które dopiero zdobywają wiedzę na temat chmury, zachęcamy przed dalszą lekturą do zapoznania się z przygotowanym przez nas wcześniej słowniczkiem najważniejszych pojęć.

Zrozumieć rewolucję chmury

Serwery dedykowane jeszcze kilka lat temu uznawane były za szczyt możliwości branży hostingowej lub po prostu obowiązujący standard. Być może wówczas nic więcej nie było nam potrzebne, a być może nie wiedzieliśmy, że pewne procesy można zrealizować bardziej elastycznie i bezpieczniej. Dzisiaj sytuacja zmieniła się znacząco – widzimy, że rynek maszyn dedykowanych kurczy się, a rynek chmury obliczeniowej rośnie. Potwierdzają to regularnie raporty Gartnera czy choćby ostatnie dane finansowe firmy IBM za Q1 2014.

Co więc sprawia, że firmy na całym świecie (tak, w Polsce również) porzucają tradycyjne rozwiązania i tak szybko migrują do chmury obliczeniowej? Jeśli mielibyśmy odpowiedzieć jednym argumentem, wskazalibyśmy chyba: elastyczność. Ale tych powodów jest znacznie więcej i w tym tekście chcielibyśmy je precyzyjnie omówić.

Sprawdźmy zatem już na wstępie, jaka jest różnica pomiędzy chmurą, a popularnie nazywanym „dedykiem”. Chyba najłatwiej będziemy to mogli zrobić za pomocą tabeli zestawiającej cechy poszczególnych produktów. Na marginesie: dodaliśmy także kolumnę z serwerami VPS, choć nie są one głównym tematem tego artykułu.

Legenda: tabela zawiera uśrednione porównanie ofert dostawców obecnych na rynku polskim i zagranicznym. Staraliśmy się w nim ukazać najczęściej oferowane typy usług. Może ona jednak nie odzwierciedlać w pełni stanu obecnego, ponieważ różni dostawcy w różny sposób konfigurują swoje produkty, wykraczając nieraz poza rynkowy standard.

Zrozumieć istotę zmiany

W powyższej tabeli zestawiliśmy najważniejsze cechy zasobów infrastrukturalnych, które różnicują trzy typy produktów dostępnych na rynku. Widać, że cloud computing ma kilka przewag nad pozostałymi rozwiązaniami.

Po pierwsze, w odróżnieniu od VPS chmura daje podobną definiowalność zasobów, jak infrastruktura fizyczna. To oznacza, że klienci chmury mogą liczyć na usługę wyrażoną w postaci konkretnych wartości parametrów, a parametry te dotyczą wszystkich aspektów: CPU, pamięci RAM, dostępu do dysku, transferu etc. A więc tak jak w wypadku fizycznej maszyny dostajemy określoną statyczną konfigurację parametrów, na którą nie wpływają inni użytkownicy, tak samo taką konfigurację parametrów oferuje chmura. Co więcej, ta mierzalność jest właśnie cechą definicyjną bycia chmurą IaaS w ogóle.

Chmura obliczeniowa przynosi nowe. Ale żeby to nowe w pełni wykorzystać, trzeba ja najpierw przyswoić i zrozumieć.

To oznacza, że klienci prawdziwej chmury obliczeniowej muszą być rozliczani ze wszystkich parametrów zużycia, ponieważ tylko w ten sposób chmura jest w stanie je zagwarantować (takiej gwarancji – dodajmy – wymaga przecież każdy poważny biznes). Nikt nie chce uruchamiać swojego środowiska produkcyjnego w otoczeniu, które jest narażone na brak dostępności zasobów – a tak właśnie w skrajnej sytuacji może się przydarzyć np. w wypadku VPS-ów.

Po drugie, w przypadku konieczności zdalnej reinstalacji systemu sprawa wygląda dość podobnie w przypadku każdego z rozwiązań i obecność tej funkcji zależy od konkretnego usługodawcy.

Serwer dedykowany natomiast nie zawsze, choć dość często, ma możliwość zdalnego restartu po jego zawieszeniu się (z czym bez problemu radzi sobie chmura oraz VPS) oraz dość rzadko spotykana jest tutaj możliwość automatycznej instalacji wybranych aplikacji (przy czym nie należy tego mylić z instalacją z poziomu konta root, gdzie w każdym wypadku administrator zainstaluje sobie dowolne oprogramowanie).

Z automatyczną instalacją dedykowanych aplikacji dużo łatwiej radzą sobie natomiast chmury obliczeniowe, a czasem nawet VPS-y.

Po trzecie, zazwyczaj tylko rozwiązania oparte o chmurę pozwalają na natychmiastową zmianę klasy maszyny oraz automatyczne skalowanie liczby rdzeni CPU oraz ilości pamięci RAM. Serwery dedykowane nie mają możliwości zdalnego skalowania zasobów, a w przypadku VPS-ów obecność tej funkcji zależy od usługodawcy. Co być może najważniejsze: tylko chmura pozwala na automatyzację procesu zarządzania skalowaniem maszyn.

Chmura gwarantuje także brak przestoju podczas naprawy lub modernizacji sprzętu i oferuje dostęp do kontenerów i loadbalancingu.

Snapshoty i klony to natomiast funkcje serwerów w chmurze, które rzadko występują w przypadku VPS-ów i nie są dostępne w serwerach dedykowanych od ręki – mogą być ewentualnie zaimplementowane na poziomie systemu operacyjnego i/lub systemu plików – jednak nie zawsze taka możliwość istnieje i nie jest to funkcjonalność samego serwera dedykowanego.

Po czwarte wreszcie, nie bez znaczenia jest też sposób rozliczania się z usługodawcą. W przypadku chmury można płacić wyłącznie za realnie zużyte zasoby. Rozliczanie godzinowe zaś, które w serwerze opartym o cloud computing jest standardem, w przypadku serwerów dedykowanych nie jest dostępne, a w VPS-ach nie zawsze jest normą.

No dobrze, ale co to oznacza dla mojego biznesu?

Decydując się na dedyka, musimy być przede wszystkim świadomi jego podstawowej wady – taki wydzielony w serwerowni dedyk to po prostu fizyczna maszyna. Można pomyśleć: „to przecież plus, bo z nikim nie dzielę zasobów”, ale oprócz oczywistych zalet płynących z tego, że nie dzielimy zasobów z innymi klientami danego dostawcy, płynie z tego zasadnicza wada dedyka. W chwili, kiedy ta fizyczna maszyna ulegnie awarii, prowadzony przez nas biznes staje.

W chmurze obliczeniowej w takiej sytuacji rolę uszkodzonej maszyny przejmuje następna, a nasz biznes zazwyczaj nawet nie odczuje tego, że była jakaś awaria. Jest to przewaga chmury obliczeniowej, o której warto pamiętać. Nie zapominajmy, że nie tylko awaria sprzętowa może zatrzymać serwer dedykowany. Nawet coś tak trywialnego jak dołożenie kości z pamięcią RAM może oznaczać przestój w pracy dedyka.

A co z backupami? Przecież mając serwer dedykowany, musimy samodzielnie zadbać o wykonywanie kopii zapasowych i codzienne zarządzanie nim. W chmurze wszystkie nasze dane są zabezpieczone poprzez stosowanie redundantnych rozwiązań storagowych, ale jeśli chcemy – możemy wykonać dodatkową kopię zapasową za pomocą wbudowanych mechanizmów.

Co więcej, możemy również wyeksportować z chmury obliczeniowej obraz swojego serwera (w formacie .ovf) i uruchomić go w każdym momencie u siebie w firmie, we własnych środowisku wirtualizacyjnym. I tak, to działa we dwie strony – jeśli chcemy, możemy przenieść do chmury obliczeniowej już posiadane zwirtualizowane serwery. W każdym momencie możemy to zrobić z wykorzystaniem funkcji importu plików .ovf.

Niektórych znanych Ci problemów z serwerami dedykowanymi w chmurze po prostu nigdy nie uświadczysz.

Równie istotną sprawą jest coś, co można nazwać „sztywnością” samej konfiguracji serwerów dedykowanych. W momencie zamówienia takiego serwera ma on pewne parametry i nie prędko ulegną one zmianie, a już na pewno nie bez negocjacji z dostawcą usługi. To oczywiście cenny czas i zasoby ludzkie, które z pewnością wolelibyśmy spożytkować w inny sposób. W Oktawave – z zegarkiem na ręku – zmiana klasy maszyny to kilka minut (i nie musisz nikogo o to prosić).

Płacenie za realnie zużyte zasoby to nasz ulubiony argument w dyskusjach na temat tego, która technologia (dedyk czy chmura) jest lepsza. Wiecie już, że chmura daje wam dostęp do niemal nieograniczonych zasobów i być może wyobrażaliście sobie, że za taką rezerwacje zasobów musicie dodatkowo płacić. Przeciwnie: nie tylko nie płacimy tutaj za rezerwację zasobów, ale nie płacimy również w sytuacji, kiedy z zasobów nie korzystamy.

Obrazowym przykładem dobrego wykorzystania chmury jest np. infrastruktura firmowa.

Wszelkiego rodzaju CRM-y, CMS-y czy systemy ERP działają w godzinach operacyjnych firmy, ale wybija szesnasta, a pracownicy wyłączają komputery i idą do domów. Jeśli infrastruktura firmowa działa w oparciu o serwer dedykowany, to pomimo tego, że nasi pracownicy smacznie śpią, my cały czas płacimy za pracę dedyka (lub jego amortyzację), także za prąd, który konsumuje.

Będąc w chmurze, możemy całkowicie wyłączyć swoje instancje lub, co wydaje się bardziej rozsądne, pozwolić Autoskalerowi zrobić to, do czego został stworzony – dostosować klasę maszyny do aktualnego zapotrzebowania na zasoby. To tak na wszelki wypadek, gdyby znalazł się jakiś nadgorliwy pracownik, który nie lubi spać.

Puszczając nieco wodze fantazji, przy odrobinie inwencji możemy także stworzyć taką konfigurację, w której po uzbrojeniu alarmu w biurze, w którym pracujemy, wszystkie zbędne serwery w chmurze są wyłączane. Rano, po rozbrojeniu alarmu i przyjściu do pracy pierwszego pracownika, serwery w chmurze zostaną natychmiast uruchomione. Jak to zrobić ? A to już proste, wystarczy odpowiednio oskryptować API chmury obliczeniowej.

Kto powinien skorzystać z chmury?

Najprostszą odpowiedzią na to pytanie byłoby: każdy, kto ma potrzebę pewności zasobów, kontroli i szybkiej skalowalności. W naszej ocenie obecnie rozwiązania oparte na cloud computingu sprawdzą się w 95% przypadków potrzeb biznesowych. Po prostu, nie ma innego typu usługi dla współczesnego biznesu, która tak dobrze zaspokaja potrzeby najróżniejszych typów klientów. Odnosi się to zresztą do firm hostingowych, twórców oprogramowania, serwisów e-commerce, a nawet agencji marketingowych.

Rozwiązania nie-chmurowe, które stosowało się do tej pory, bazowały na serwerach umieszczonych w konkretnej lokalizacji: siedzibie firmy lub wynajętej serwerowni. Niestety, nie jest łatwo określić – a także przewidzieć na przyszłość – jak dużo zasobów będzie potrzebne do prowadzenia biznesu. Jeśli postawiony serwer jest zbyt mocny, to oznacza, że wyrzucono pieniądze na jego zakup. W sytuacji, gdy zasoby okażą się niewystarczające, mamy do czynienia z jeszcze gorszą sytuacją, bo naraża to firmę na straty.

Cloud computing daje spore możliwości: firmom każdej wielkości.

Dzięki mechanizmom skalowania okazuje się, że nawet mniejsze podmioty stać na naprawdę wydajną infrastrukturę, która do tej pory była domeną wyłącznie olbrzymich przedsiębiorstw zdolnych wybudować własną serwerownię oraz… zatrudnić zespół do jej obsługi. W przypadku rozwiązań dedykowanych powiązanie fizycznej maszyny z oprogramowaniem było hamulcem dla rozwoju.

Chmura pozwala znieść te ograniczenia. Taki serwer w zwirtualizowanym środowisku to też świetne rozwiązanie dla firm, w których IT nie jest trzonem działalności. Skorzystanie z cloud computingu pozwoli przedsiębiorstwu skupić się na ich głównym obszarze zainteresowań, bez konieczności zatrudniania całego sztabu informatyków i budowania własnej serwerowni.

Chmura pozwala bowiem wejść do niej na bardzo niskim poziomie kosztów i rosnąć wraz z rozwojem realnego zapotrzebowania biznesowe. Odtąd posiadanie zasobów IT przestaje być inwestycją, już nie musimy mieć środków na zakup dedyka.

Rozwiązania dedykowane po prostu nie są w stanie zapewnić należytej płynności w alokacji zasobów.

W kryzysowych sytuacjach dostawienie lub nawet wynajęcie kolejnego serwera i jego konfiguracja zajmuje po prostu zbyt dużo czasu. Strach zresztą myśleć o sytuacji, w której nastąpi awaria i konieczne jest przywracanie kopii zapasowej. A ile to zajmuje czasu, ile danych w międzyczasie będzie bezpowrotnie stracone? To wszystko generuje straty dla firmy, dlatego warto korzystać z rozwiązań, które są pozbawione takich problemów i ograniczeń.

Przejście z rozwiązań dedykowanych na chmurę pozwala na uzyskanie należytej elastyczności i skalowalności. Zapewnia też znacznie wyższy poziom bezpieczeństwa i minimalizuje przestoje. Możliwe to było dzięki oderwaniu środowiska programowego od hardware’u. W przypadkach awarii jest możliwe, że klient nawet nie zaobserwuje przełączenia go na nowy, sprawny sprzęt.

Dzięki wirtualizacji i oderwaniu uruchomionych w ramach wirtualnych maszyn systemów operacyjnych klienci mogą dowolnie lokować zasoby i moc obliczeniową. W przypadku chmury zwraca się też uwagę na zupełnie inne parametry: nie jest istotnym parametrem pojemność twardego dysku, a jego szybkość. Chmura gwarantuje nie tylko ilość przestrzeni dyskowej liczoną w gigabajtach, ale też wydajność, wyrażoną parametrem IOPS (Input/Output Operations Per Second, czyli liczba operacji odczytu i zapisu na dysku w czasie jednej sekundy).

A co z VPS-ami?

Warto też określić, jak prezentuje się zwykły VPS na tle dedyka i chmury. Serwer wirtualny to jedynie wydzielone miejsce na jednej fizycznej maszynie, a to oznacza, że oprócz wszystkich wspomnianych wad serwerów (maszyn) dedykowanych, ma jeszcze tą jedną, ale za to zasadniczą – zasoby dzieli z innymi klientami hostera. To, jakie są wady tego rozwiązania, możecie wywnioskować sami.

VPS pod naporem ruchu po prostu się „zapcha”.

Co jest tutaj niebezpieczeństwem? Przykładowo, jeśli na jednej maszynie swój internetowy sklep prowadzi firma zajmująca się sprzedażą sezonową (naszym ulubionym przykładem są bombki na choinkę), to w okresie przedświątecznym taki sklep zagarnie dla siebie sporą część zasobów takiego VPS-a. Wtedy dla Twojego biznesu oznacza to przestój i sfrustrowanych potencjalnych klientów, a jeśli i Ty prowadzisz również sezonową sprzedaż – załóżmy choinek – to oba biznesy staną: zarówno Twój (sprzedający choinki), jak i tego handlarza bombkami.

Wypróbuj chmurę bez ponoszenia kosztów

Z chmury trzeba umieć korzystać, trzeba mieć wiedzę. Ale nie jest to wiedza niedostępna lub coś, czego nie da się ogarnąć – wystarczy rzucić okiem na naszą Bazę wiedzy, aby się przekonać, że niektóre rzeczy są po prostu banalne, a te które nie są, to dla przeciętnego admina jedna noc z mocniejszą kawą. Jeśli nie wiesz, jak zacząć, spróbuj przejść sobie ten tutorial, na pewno Ci pomoże.

Każdy może przetestować Oktawave za darmo. Nowi użytkownicy dostają 25 zł zasilenia konta na start.

Na koniec jeszcze tylko mała dygresja – chmura chmurze nie jest równa. Nie dajmy się nabierać na VPS-y czy dedyki sprzedawane z metką “cloud”. To, że na stronie z konfiguratorem u dostawcy są jakieś suwaki do zmiany parametrów maszyny, nie oznacza że jest to prawdziwa chmura. Prawdziwy serwer w chmurze jest:

  1. dostępny na żądanie i całkowicie zarządzany przez użytkownika,

  2. niezależny od sprzętu fizycznego,

  3. skalowalny na żądanie,

  4. w pełni mierzalny parametrycznie,

  5. dostępny z każdego urządzenia w sieci.

Spragnionych dalszej lektury w poruszonym temacie odsyłamy do tekstu O chmurach i niechmurach. Czyli czym się różni cloud computing od zwykłego hostingu, który ukazał się na łamach Spider’s Web jakiś czas temu, oraz do naszego white papera.

- - - - -

Dysk w chmurze to nie tylko miejsce do składowania plików na jakimś bliżej nieokreślonym serwerze i ich późniejszej synchronizacji z dyskiem twardym komputera. Dziś chcielibyśmy Wam pokazać, jakie rozbudowane zastosowania ma storage w cloud computingu i dlaczego Dropbox to dopiero wierzchołek góry lodowej.
Dostawcy popularnych usług internetowych muszą liczyć się z tym, że przygotowując swoje rozwiązania dla masowego odbiorcy, powinni maksymalnie uprościć cały front-end. Dla użytkownika końcowego (często nazywamy go Kowalskim) liczy się przejrzysty interfejs i nie interesuje go działanie usługi „pod maską”. Usługodawca jest w stanie sprawdzić, jakie nawyki i związane z nimi potrzeby ma statystyczny konsument z jego grupy docelowej, i upraszcza sposób korzystania z produktu do tych codziennych, najczęstszych scenariuszy.

Prostota drogą do sukcesu

Najczęściej taki statystyczny Kowalski potrzebuje usługi, która jest wygodna w użyciu i nie odstrasza skomplikowanymi (czyli wymagającymi wiedzy) procedurami obsługi. Lepiej nawet, jeśli rzeczywisty poziom technologiczny jest ukryty i nie przeszkadza on użytkownikowi w realizacji celu funkcjonalnego.

W przypadku przestrzeni dyskowej w cloud computingu obowiązuje taka sama zasada. Dla zwykłego użytkownika dysku w chmurze nie jest istotne to, jak usługa działa. Interesuje go tylko to, gdzie musi kliknąć na stronie lub w aplikacji, aby wybrany przez niego plik powędrował do chmury.

Zwykły user kontra poweruser

Taki użytkownik nie chce, a być może też nie musi wiedzieć, co się tak naprawdę wydarzyło po przeciągnięciu ikony z dokumentem lub zdjęciem w odpowiednie miejsce. Są jednak osoby, które interesuje dokładny mechanizm działania chmury w zakresie storage’u i byliby oni zainteresowani dodatkowymi możliwościami, jakie daje nowoczesny dysk w chmurze.

Do tej grupy można zaliczyć najróżniejsze grupy internautów, zwykle powiązane z siecią zawodowo: programistów, administratorów systemowych i projektantów architektury IT. Do takich osób, oraz wszystkich innych czytelników Spider’s Web zainteresowanych możliwościami dysków uruchamianych w chmurze, kieruję dzisiejszy tekst.

Dysk w chmurze. O co chodzi?

Idea dysku w chmurze nie jest nowa. Rozwiązanie to polega na udostępnianiu przez dostawców infrastruktury swoich zasobów storage’owych w centrach danych, które później można wykorzystać w sposób zdalny. Dzięki temu dane trzymane są w modelu rozproszonym, a takie podejście ma bardzo dużo istotnych plusów:

Dla kogo jest dysk w chmurze?

Klasyczny dysk w chmurze może być więc przydatny dla każdego użytkownika globalnej sieci. Skorzysta z niego zarówno wspomniany we wstępie statystyczny Kowalski do przechowywania zbiorów domowych multimediów, ale można wykorzystać to rozwiązanie jako profesjonalne narzędzie biznesowe (obieg dokumentów) czy wreszcie jako element większej układanki w enterprise’owej architekturze IT.

Przykładem zastosowanie dysku w chmurze w Oktawave może być rodzimy portal Fotosik.pl, gdzie rozwiązanie oparte o cloud computing wykorzystywane jest do zapewnienia bezpiecznej metody wymiany plików pomiędzy różnymi systemami i aplikacjami. To podejście zapewnia nie tylko bezpieczeństwo, ale też niezawodność i wydajność.

Dyski, które wszyscy znamy

Użytkownicy mogą korzystać z dysku w chmurze na najróżniejsze sposoby – najczęściej jednak podstawowym sposobem interakcji jest interfejs WWW w przeglądarce internetowej. Coraz popularniejsze są też dedykowane aplikacje dla systemów stacjonarnych i mobilnych, a niektóre konsumenckie chmury na pliki (Google Drive, OneDrive i iCloud) są zaszyte bezpośrednio w systemach operacyjnych.

Aplikacje służące do synchronizacji danych lokalnych ze zgromadzonymi na dysku w chmurze pozwalają na zautomatyzowanie procesu tworzenia kopii zapasowych, ułatwiają porządkowanie plików oraz ułatwiają współdzielenie z innymi użytkownikami. To oferuje praktycznie każdy dostawca usługi tego typu, ale wymagający użytkownik znający swoje potrzeby na tym nie poprzestanie.

Dodatkowe funkcje chmury

Oprócz funkcji zarządzania i synchronizacji plików chmury mogą być wyposażone w dodatkowe moduły. Często deweloperzy i architekci IT są zainteresowani obsługą szyfrowanej transmisji danych, możliwością tworzenia ustrukturalizowanego obiektowego drzewa, funkcją kontenerów i grup oraz na koniec – a może przede wszystkim – dostępem do API.

Dzięki zaawansowanym możliwościom użytkownicy takich dysków w chmurze mogą nie tylko składować tam swoje dane, ale też budować w oparciu o nie swoje własne usługi i aplikacje. To zresztą jest bardzo popularna praktyka, a przykładów tego nie trzeba daleko szukać.

Chmura na pliki, a storage obiektowy

Jedną z najpopularniejszych konsumenckich i biznesowych dysków w chmurze do składowania plików jest Dropbox. Twórcy tego dysku nie stworzyli go jednak całkowicie od zera, bo tak naprawdę jest on nakładką na usługę Amazon S3. Na naszym rodzimym rynku mamy do czynienia z podobną sytuacją, jak w przypadku Dropboksa i Amazonu. Skala jest inna, ale sposób rozwiązania backendu usługi jest podobny. Usługa o nazwie MantaBOX, czyli przestrzeń na dane użytkowników urządzeń firmy Manta, jest de facto interfejsem WWW dla dysku Oktawave Cloud Storage.

W tym miejscu ujawnia się kluczowe rozróżnienie w sposobie korzystania z dysku w chmurze. Wszystko rozbija się o potrzeby – trudno będzie przekonać użytkownika do bezpośredniej pracy z dyskiem Amazon S3, jeśli chce on wyłącznie podzielić się z przyjaciółmi paczką zdjęć z wakacji. Z drugiej strony, profesjonaliści opierający swoje życie zawodowe na pracy z danymi w chmurze z pewnością zainteresują się możliwością pełnej kontroli nad storage’em, gdzie nie ma klasycznego podziału na hierarchię plików. Dane w ramach tej architektury przechowywane są jako obiekty, stąd stosuje się nazwę storage obiektowy.

Storage obiektowy vs. storage blokowy

Storage blokowy należy rozumieć jako wydzielony obszar na fizycznym dysku twardym, który umożliwia zapisywanie i odczytywanie danych w postaci bloków. Jest on szczególnie ważny dla sytuacji, w których musimy często odwoływać się do zasobów danych przechowywanych w postaci plików (np. otwierać je, pobierać z nich dane, zmieniać w nich fragmenty danych), np. systemów operacyjnych czy baz danych. Innymi słowy storage blokowy to odpowiednik dysku twardego komputera. Oczywiście chmury takie dyski podłączają do serwerów, tak by móc na nich instalować systemy operacyjne czy bazy danych.

To, o czym mówimy dziś, to storage obiektowy, gdzie dane przechowywane są w postaci dowolnych obiektów hierarchizowanych do struktur np. drzew lub list. Storage obiektowy różni się od blokowego przede wszystkim tym, że pozwala na zapisywanie i odczytywanie do niego całych obiektów, bez względu na ich rozmiar – dlatego tak dobrze sprawdza się jako magazyn zdjęć, wideo oraz innych obiektów statycznych.

Kiedy w dysku blokowym liczy się szybkość, z którą procesor może otworzyć jakiś zasób (np. bazę danych), dokonać w niej zmian i ją zamknąć, tak w storage’u obiektowym liczy się możliwość taniego i wydajnego przechowywania dużych obiektów i uniezależnienia takiego storage’u od powiązania z konkretnym serwerem wirtualnym.

Oktawave Cloud Storage, czyli OCS

Storage obiektowy w chmurze Oktawave (OCS) charakteryzuje się możliwością wykonywania wszystkich klasycznych operacji, do których należy zapisywanie, odczyt i modyfikacja danych. Pozwala to na przechowywanie danych w formie plików oraz drzewa danych o ustrukturalizowanym charakterze, ale nic nie stoi na przeszkodzie, aby przechowywać dane w oparciu o tzw. kontenery i odejść od klasycznej struktury. Więcej informacji o OCS znajdziecie na naszej stronie internetowej poświęconej temu zagadnieniu.

Warto jednak zwrócić uwagę na kilka cech szczególnych Oktawave Cloud Storage:

Jeśli chcesz wiedzieć, w jaki sposób dokładnie zorganizowany jest OCS, zachęcamy do lektury nieco bardziej wymagającego artykułu, pt. „Obiektowy storage w chmurze. Hardcore? Nie, to jest dla ludzi!”.

Jak dobrać się do obiektów?

W storage’u obiektowym każdy z obiektów posiada swój własny zestaw metadanych i unikatowy identyfikator. Pozwala to na łatwe przechowywanie dużej ilości nieustrukturyzowanych danych. Jest to też rozwiązanie skalowalne i może posiadać funkcje samoleczenia uszkodzonych partii danych.

Do storage’u obiektowego (w tym oczywiście do naszego OCS) dostać się można na wiele sposobów, od tych najbardziej oczywistych jak panel administracyjny, poprzez API, a na zewnętrznych klientach kończąc. Przyjrzyjmy się im nieco bliżej.

Panel administracyjny

Panel administracyjny można znaleźć u wszystkich dostawców chmury. Inna kwestia to jego funkcjonalność. Przed wybraniem dostawcy zawsze warto sprawdzić, jak prezentuje się panel administracyjny: czy zawiera on wszystkie niezbędne opcje, czy jego interfejs jest przemyślany, czy nie sprawia problemów w nawigacji i szybko się ładuje.

To bardzo istotne, ponieważ najzwyczajniej w świecie w tym miejscu użytkownik będzie spędzał dużo czasu. W Oktawave dużo czasu poświeciliśmy na to, aby nasz panel był zarówno intuicyjny, jak i funkcjonalny, a kwestia tworzenia storage’u obiektowego może być tego dowodem. Nie musicie wierzyć mi na słowo – możecie sami zobaczyć, jak łatwo się to u nas robi. W niniejszym tutorialu pokazujemy, w jaki sposób wykonywać podstawowe operacje na OCS.

API

Tak naprawdę każdy dostawca dysku w chmurze dostarcza jakieś API, ale przed podjęciem decyzji o wyborze konkretnego rozwiązania należy przyjrzeć się, co to API dokładnie oferuje. W wielu przypadkach jest ono tak napisane, by przywiązać klienta do siebie na stałe, a bariera wyjścia w celu zmiany dostawcy jest bardzo wysoka.

Za pomocą API przeprowadzicie wszystkie operacje, jakie dostępne są z poziomu interfejsu użytkownika w panelu administracyjnym, czyli nie tylko stworzycie współdzielone dyski wirtualne, ale również możecie nimi później zarządzać. Oznacza to, że storage’em obiektowym będziecie mogli zarządzać wprost z wewnątrz swojej aplikacji.

Dzięki pełnemu wykorzystaniu API Oktawave, możliwe jest zbudowanie własnej aplikacji, w taki sposób, aby storage obiektowy stanowił osobną instancję wobec logiki aplikacji. Tak po migracji do infrastruktury Oktawave wygląda to w popularnym hostingu zdjęć Fotosik.pl.

Dodajmy w tym miejscu, że ważna w wypadku storage’u obiektowego jest także standaryzacja. W wypadku Amazon Web Services wyniesienie aplikacji z S3 najczęściej oznacza konieczność przepisywania dużej porcji kodu. Może być to hamulcem dla dewelopera, dlatego warto wybrać na początku dostawcę wspierającego otwarte standardy, czyli np. OpenStack SWIFT (Oktawave Cloud Storage nominalnie jest zgodny z tym standardem). W razie potrzeby gwarantuje to znacznie łatwiejszą migrację.

Aplikacja kliencka

Ostatnim ze sposobów na dostanie się do wykupionego storage’u obiektowego jest aplikacja kliencka do zarządzania storage’em obiektowym. Popularnym wyborem jest Cyberduck (tutorial konfiguracji z OCS), dostępny zarówno na platformy Windows jak i Mac OS X. Można również skorzystać z dowolnego innego oprogramowania zgodnego z OpenStack (np. ExpanDrive).

Dwa scenariusze

Chcielibyśmy jeszcze zwrócić uwagę na dwa klasyczne sposoby wykorzystania storage’u obiektowego w obszarach profesjonalnych. Pierwszym z nich jest backup. Otóż pliki kopii zapasowych to zazwyczaj archiwa o pokaźnych rozmiarach. Nie przewiduje się, że archiwa te będą ulegały modyfikacji, raczej oczekujemy, że w wypadku awarii wyciągniemy backup i odtworzymy dane środowisko czy bazę danych.

Do tego czasu chcemy, by kopia zapasowa w postaci archiwum była przechowywana w odrębnym miejscu (odrębnym, czyli niezależnym od środowiska, które backupujemy). I to jest idealne miejsce na wykorzystanie OCS. Możemy w firmie zainstalować oprogramowanie, które połączy się z storage’em obiektowym i będzie – poza tworzeniem samego archiwum – również wysyłało takowe do bezpiecznej chmury.

Drugim scenariuszem są aplikacje online, które korzystają z pokaźnych zasobów statycznych danych (np. zdjęć). Zaliczyć tutaj można wszelkiego rodzaju hostingi zdjęć czy wideo (tak, znów trzeba wspomnieć Fotosik.pl), wirtualne dyski, a nawet serwisy społecznościowe. Dzięki storage’owi obiektowemu możemy oddzielić te zbiory od logiki aplikacji (czyli serwery z aplikacją i bazą danych od storage’u), co sprawi, że cała architektura stanie się po prostu zoptymalizowana.

Podsumowanie

Tak mniej więcej prezentuje się kwestia dysku w chmurze. Chodziło nam o to, by pokazać Wam, że pod ładnym interfejsem popularnych i prostych usług kryje się konkretna technologia, a coraz częściej jest to właśnie chmura obliczeniowa. Technologia ta daje niesamowite możliwości również dla bardziej zaawansowanych użytkowników. Przykład Fotosik.pl pokazuje, że z jej wykorzystaniem można tworzyć po prostu całkowicie nowe usługi.

Przechowywanie danych to tylko kolejny aspekt chmury i – co warto podkreślić – aspekt, w którym góruje ona nad klasycznymi rozwiązaniami. Dziś użytkownik czy programista nie musi się martwić o to, czy wystarczy mu miejsca na jego dysku. O to dba dostawca chmury, który jednocześnie pobiera opłatę tylko za wykorzystane dane. Czy ktokolwiek powinien dziś korzystać z czegoś gorszego?




Wyszukiwarka

Podobne podstrony:

więcej podobnych podstron