Automatyczne skalowanie w chmurze

Co to jest automatyczne skalowanie?

Automatyczne skalowanie, zwane tak�e obs�ug� administracyjn�, ma kluczowe znaczenie dla chmury. Bez elastyczno�ci zapewnianej przez automatyczne skalowanie wr�cisz do zapewniania przez ca�y rok rocznych szczyt�w. Ka�da platforma e-commerce wdro�ona w chmurze powinna mie� rozwi�zanie umo�liwiaj�ce skalowanie w g�r� i w d� ka�dej z r�nych warstw w zale�no�ci od zapotrzebowania w czasie rzeczywistym. Rozwi�zania automatycznego skalowania nie nale�y myli� ze wst�pnym udost�pnianiem. Wst�pne udost�pnianie polega na prawid�owym skonfigurowaniu �rodowisk, w tym na r�wnowa�eniu obci��enia, ustawianiu zap�r ogniowych, konfigurowaniu pocz�tkowych obraz�w serwer�w i szeregu dodatkowych jednorazowych dzia�a�. Z drugiej strony, automatyczne skalowanie koncentruje si� na przej�ciu istniej�cego �rodowiska i zwi�kszeniu lub zmniejszeniu pojemno�ci w zale�no�ci od potrzeb w czasie rzeczywistym. Zaopatrywanie i skalowanie mog� ostatecznie korzysta� z tych samych mechanizm�w, ale ich cel i zakres s� ca�kowicie r�ne. Celem automatycznego skalowania jest zapewnienie wystarczaj�cej ilo�ci sprz�tu do obs�ugi ruchu, przy jednoczesnym przestrzeganiu um�w dotycz�cych poziomu us�ug. Je�li rezerwujesz za du�o, marnujesz pieni�dze. Je�li zapewnisz za ma�o, cierpisz na przerwy w dostawach. Dobre rozwi�zanie pomo�e Ci zapewni� wystarczaj�c� ilo�� rodk�w, ale nie tyle, �e marnujesz pieni�dze. Tu om�wimy, co nale�y zapewni�, kiedy nale�y, a nast�pnie jak.

Co nale�y zapewni�

W tej cz�ci skupiono si� na udost�pnianiu sprz�tu z platformy Infrastructure-as-a-Service, poniewa� ma ona najmniej. Gdy u�ywasz infrastruktury jako us�ugi, najni�szym poziomem abstrakcji jest zazwyczaj infrastruktura fizyczna, zazwyczaj serwer wirtualny. Musisz zapewni� moc obliczeniow� i pojemno�� pami�ci, a nast�pnie zainstalowa� na nim oprogramowanie. Om�wimy instalacj� oprogramowania w nast�pnym rozdziale. Dostawcy IaaS zajmuj� si� udost�pnianiem zasob�w ni�szego poziomu, takich jak sie� i zapory ogniowe. Dostawcy infrastruktury jako us�ugi inwestuj� znaczne zasoby, aby zapewni� jak naj�atwiejsze udost�pnianie, ale bior�c pod uwag�, �e masz do czynienia z zwyk�� infrastruktur�, trudno jest inteligentnie zapewni�, jak mo�esz z platform� jako us�ug�. Id�c wy�ej w g�r�, oferty Platform-as-a-Service zwykle zawieraj� �ci�le zintegrowane narz�dzia do obs�ugi administracyjnej jako cz�� ich podstawowej oferty warto�ci. Tw�j najni�szy poziom abstrakcji jest zwykle serwerem aplikacji, przy czym dostawca zarz�dza serwerem aplikacji i wszystkim pod nim. Ty okre�lasz, kiedy chcesz udost�pni� wi�cej serwer�w aplikacji, a dostawca Platforma jako us�uga zapewni wi�cej serwer�w aplikacji i wszystko pod nimi w tandemie. Inicjowanie obs�ugi administracyjnej jest z natury trudne, a robi�c du�o dla ciebie, ci dostawcy oferuj� warto��, kt�r� mo�esz chcie� zap�aci� dodatkowo. Wreszcie istnieje oprogramowanie jako us�uga. Wi�kszo�� dostawc�w oprogramowania jako us�ugi oferuje prawie nieograniczon� pojemno��. Pomy�l o powszechnym oprogramowaniu oferowanym jako oprogramowanie jako us�uga: DNS, r�wnowa�enie obci��enia globalnego serwera, sieci dostarczania tre�ci oraz oceny i recenzje. Po prostu korzystasz z tych us�ug, a od sprzedawcy zale�y skalowanie ca�ej infrastruktury zaplecza, aby m�c sprosta� Twoim wymaganiom. To du�a cz�� warto�ci Software-as-a-Service i jest koncepcyjnie podobna do przyk�adu u�yteczno�ci publicznej z poprzedniego rozdzia�u. Po prostu wyci�gasz wi�cej energii z sieci, kiedy jej potrzebujesz. R�ni si� to od platformy jako us�ugi i infrastruktury jako us�ugi, w kt�rej musisz poinformowa� swojego dostawc�, kiedy potrzebujesz wi�cej, a on wysy�a wi�cej informacji. Minusem twoich dostawc�w zajmuj�cych si� tworzeniem rezerw jest to, �e z natury tracisz kontrol�. Dostarczane przez dostawc� narz�dzia do obs�ugi administracyjnej s� do�� elastyczne i coraz lepsze, ale Twoja platforma zawsze b�dzie mia�a unikalne wymagania, kt�re mog� nie by� dok�adnie spe�nione przez dostarczone przez dostawc�. Im wi�ksze i bardziej skomplikowane wdro�enie, tym wi�ksze prawdopodobie�stwo, �e b�dziesz chcia� zbudowa� co� niestandardowego. Twoim celem w udost�pnianiu jest dopasowanie ilo�ci zasob�w do poziomu ka�dego wymaganego zasobu oraz dowolnego istniej�cego wsp�czynnika bezpiecze�stwa. Czynnikiem bezpiecze�stwa jest to, jak� dodatkow� pojemno�� zapewnisz, aby unikn�� awarii. Ta warto�� jest zwykle reprezentowana przez zdefiniowane regu�y automatycznego skalowania. Je�li twoja aplikacja jest zwi�zana z procesorem, mo�esz zdecydowa� o udost�pnieniu wi�kszej pojemno�ci przy 25%, 50%, 75% lub 95% zagregowanym wykorzystaniu procesora. Im d�u�ej czekasz na zaopatrzenie, tym wi�ksze prawdopodobie�stwo wyst�pienia awaria z powodu nieoczekiwanego wzrostu nat�enia ruchu.

Czego nie mo�na zapewni�

O wiele �atwiej jest udost�pni� wi�cej zasob�w dla istniej�cego �rodowiska ni� zbudowa� nowe �rodowisko od zera. Ka�de �rodowisko, kt�re zbudujesz, ma sta�e koszty og�lne - musisz skonfigurowa� modu� r�wnowa�enia obci��enia, DNS, baz� danych i r�ne konsole zarz�dzania dla twoje aplikacje. Nast�pnie musisz zaszczepi� baz� danych i wszystkie pliki wymagane przez aplikacje i oprogramowanie po�rednie. Teoretycznie mo�liwe jest napisanie tego wszystkiego z wyprzedzeniem, ale nie jest to zbyt praktyczne. Nast�pnie istnieje kilka zasob�w, kt�re nale�y w pe�ni przygotowa� i skalowa� przed szczytem. Na przyk�ad, je�li wdra�asz w�asn� relacyjn� baz� danych, nale�y j� wcze�niej zbudowa�. Trudno jest dodawa� w�z�y bazy danych dla relacyjnych baz danych w czasie rzeczywistym, poniewa� ca�a baza danych uruchamia si� ponownie i cz�sto wymagane s� inne zmiany konfiguracji. W�ze� bazy danych dla relacyjnej bazy danych nie przypomina serwera aplikacji ani serwera WWW, w kt�rym mo�na po prostu doda� kolejny i zarejestrowa� go w module r�wnowa�enia obci��enia. Oczywi�cie mo�esz korzysta� z elastycznych rozwi�za� baz danych dostawcy, ale niekt�re z nich mog� by� niewygodne, gdy poufne dane znajduj� si� w bazie danych zawieraj�cej wiele podmiot�w. Nierelacyjne bazy danych, takie jak bazy danych NoSQL, zazwyczaj mo�na skalowa� w locie, poniewa� maj� architektur� "nic wsp�lnego", kt�ra nie wymaga ponownego uruchamiania ca�ej bazy danych. Ka�de �rodowisko powinno zawiera� co najmniej jeden z ka�dego typu serwera. Pomy�l o ka�dym �rodowisku jako o rozmiarze �rodowiska programistycznego na pocz�tek. Nast�pnie mo�esz zdefiniowa� zasady automatycznego skalowania dla ka�dej warstwy. Sta�a pojemno�� dla ka�dego �rodowiska mo�e by� oparta na dedykowanym sprz�cie, w przeciwie�stwie do normalnie pobieranych op�at godzinnych. Dedykowany sprz�t jest cz�sto znacznie ta�szy ni� ceny za godzin�, ale sprz�t wymaga p�atno�ci z g�ry przez okre�lony czas, zwykle przez rok. Ponownie powinien to by� do�� niewielki rozmiar, sk�adaj�cy si� tylko z kilku serwer�w. Koszt nie powinien by� du�y

Kiedy rezerwowa�

Idealnie by�oby idealnie dopasowa� przydzielone zasoby do nat�enia ruchu obs�ugiwanego przez system. To nigdy nie jest takie proste. Problem z obs�ug� administracyjn� polega na tym, �e funkcjonowanie ka�dego zasobu wymaga czasu. Dostarczenie dzia�aj�cego serwera z zainstalowanym obrazem i uruchomionym systemem operacyjnym mo�e potrwa� co najmniej kilka minut. Nast�pnie musisz zainstalowa� oprogramowanie, co zajmuje jeszcze wi�cej czasu. Instalacja oprogramowania na nowo wyposa�onym sprz�cie zosta�a om�wiona w nast�pnej cz�ci. Po udost�pnieniu zasobu nie mo�esz po prostu uruchomi� go natychmiast. Niekt�re zasoby s� zale�ne i musz� zosta� zainicjowane w okre�lonej kolejno�ci, w przeciwnym razie nast�pi awaria. Na przyk�ad, je�li udost�pnisz serwery aplikacji przed serwerami przesy�ania wiadomo�ci, prawdopodobnie nie b�dziesz mie� wystarczaj�cej pojemno�ci przesy�ania wiadomo�ci i nast�pi awaria. W tym przyk�adzie musisz doda� swoje serwery aplikacji do modu�u r�wnowa�enia obci��enia dopiero po pe�nym wyposa�eniu serwer�w przesy�ania komunikat�w. Sztuczka polega na r�wnoleg�ym udost�pnianiu, a nast�pnie r�wnoleg�ym instalowaniu oprogramowania, ale na ostatnim etapie dodaj serwery aplikacji do modu�u r�wnowa�enia obci��enia. Aprowizacja ma dwie formy:

* Proaktywne udost�pnianie : Zaopatrywanie z wyprzedzeniem, kiedy spodziewany jest ruch
* Reaktywne udost�pnianie: Zaopatrywanie w reakcji na ruch

Powiniene� d��y� do reaktywnego udost�pniania, chocia� wi��e si� to z ryzykiem awarii, je�li nie mo�esz zapewni� go wystarczaj�co szybko, aby uzyska� szybki wzrost nat�enia ruchu. Aby si� przed tym zabezpieczy�, nale�y nadmiarowa� (zacznij udost�pnia�, powiedzmy, 50% wykorzystania procesora, zak�adaj�c, �e aplikacja jest zwi�zana z procesorem), ale prowadzi to do marnotrawstwa. Podobnie mo�esz zapewni� 95% wykorzystanie procesora, ale r�wnie� tam poniesiesz koszty, poniewa� b�dziesz okresowo wy��cza� si� z powodu braku mo�liwo�ci szybkiego skalowania. Jest to dzia�anie r�wnowa��ce, kt�re w du�ej mierze zale�y od tego, jak szybko mo�esz zapewni� i jak szybko trafia Ci� nowy ruch.

Proaktywne udost�pnianie

W proaktywnym udost�pnianiu zasoby s� udost�pniane w oczekiwaniu na zwi�kszony ruch. Mo�esz oszacowa� ruch na podstawie:

• Cykliczne trendy

-Codziennie
-Miesi�czny
- Sezonowo

• Aktywny marketing

-Promocje
-Promocje promocyjne
-Socjalne kampanie medialne
-G��bokie zni�ki cenowe
-Sprzeda� flash

Je�li wiesz, �e nadchodzi ruch, i wiesz, �e zostaniesz uderzony wi�kszym ruchem, ni� mo�esz zareagowa� aktywnie, warto proaktywnie zwi�kszy� pojemno��. Na przyk�ad mo�esz upewni� si�, �e podwoisz swoj� pojemno�� na godzin� przed wys�aniem du�ych e-maili promocyjnych. Aby m�c proaktywnie zapewnia� us�ugi, najlepiej jest mie� jeden system do sprawdzania zar�wno ruchu przychodz�cego, jak i sposobu, w jaki odwzorowuje to wykorzystanie ka�dego poziomu. Nast�pnie mo�esz u�o�y� tabel� z mapowaniem ka�dej posiadanej warstwy i ile jednostek tego zasobu (zazwyczaj serwer�w o jednakowych rozmiarach) jest wymaganych na r�nych poziomach. Idealnie by�oby, gdyby Tw�j system skalowa� si� liniowo. Je�li wi�c Tw�j ostatni e-mail reklamuj�cy zni�k� 30% przyni�s� 30 000 jednoczesnych klient�w, wiesz, �e musisz zapewni� 15 serwer�w aplikacji, 9 serwer�w gridu z pami�ci� podr�czn�, 6 serwer�w przesy�ania wiadomo�ci i 6 baz danych NoSQL przed wys�aniem tego e-maila. Wiele z tego sprowadza si� do przetworzenia. O ile nie da si� szybko i niezawodnie zareagowa�, musisz wprowadzi� zabezpieczenia, aby zapewni�, �e marketerzy nie b�d� generowa� nieoczekiwanie du�ej ilo�ci ruchu, dop�ki system nie b�dzie na to przygotowany. Koszty proaktywnego tworzenia rezerw s� wysokie, poniewa� g��wnym celem jest zwi�kszenie pojemno�ci, ni� jest to faktycznie potrzebne. Ruch musi by� prognozowany, a system skalowany r�cznie. Wszystkie te prognozy s� czasoch�onne, ale w por�wnaniu z kosztami awarii i marnotrawstwem przed chmur� koszty s� niewielkie.

Reaktywne udost�pnianie

Reaktywne udost�pnianie ma znacz�ce zalety w stosunku do proaktywnego udost�pniania i jest tym, do czego nale�y d��y�. W dzisiejszym po��czonym �wiecie link do Twojej witryny mo�e podr�owa� po ca�ym �wiecie do milion�w ludzi w ci�gu kilku minut. Gwiazdy i my�l�cy przyw�dcy maj� 50 milion�w obserwuj�cych w popularnych sieciach spo�eczno�ciowych. Wystarczy, �e kto� z 50 milionami obserwuj�cych opublikuje link do Twojej witryny, a ty b�dziesz mie� k�opoty. Mo�esz prognozowa� wi�kszo�� ruchu, ale nie ca�y. Trend gwa�townych wzrost�w ruchu w mediach spo�eczno�ciowych przyspieszy, gdy media spo�eczno�ciowe b�d� si� nadal rozprzestrzenia�. Opr�cz unikania przestoj�w, rezerwowanie reaktywne zapewnia znaczne oszcz�dno�ci koszt�w. Zapewniasz tylko dok�adnie to, czego potrzebujesz, kiedy jej potrzebujesz. Reaktywne udost�pnianie opiera si� na za�o�eniu, �e jest w stanie dok�adnie zbada� kondycj� ka�dego poziomu, a nast�pnie podj�� dzia�ania, je�li uzasadniaj� to zg�oszone dane. Zwi�kszaj�c pojemno�� o 50%, zawsze powiniene� mie� o 50% wi�ksz� pojemno�� ni� potrzebujesz, co jest zdrowym czynnikiem bezpiecze�stwa. Wkr�tce zajmiemy si� cz�ci� obs�ugi administracyjnej. Czasami limity Twojego oprogramowania najlepiej wyra�� si� w niestandardowych danych. Na przyk�ad pojedynczy serwer przesy�ania wiadomo�ci mo�e obs�ugiwa� tylko 1000 wiadomo�ci na sekund�. Ale jak mo�esz to przedstawi� za pomoc� gotowych wska�nik�w, takich jak wykorzystanie sieci i wykorzystanie procesora? Twoje narz�dzie monitorowania najprawdopodobniej pozwoli ci zdefiniowa� niestandardowe wska�niki, kt�re b�d� si� pod��cza� do zdefiniowanych przez ciebie hak�w.

Rozwi�zania do automatycznego skalowania

Dost�pnych jest wiele rozwi�za� do automatycznego skalowania, od niestandardowych rozwi�za� po rozwi�zania wbudowane w rdze� oferty dostawc�w us�ug w chmurze po rozwi�zania innych firm. Chocia� wszystkie te rozwi�zania dzia�aj� w zasadzie to samo, ich cele, podej�cie i wdro�enie r�ni� si�. Ka�de zastosowane rozwi�zanie musi by� w pe�ni dost�pne i najlepiej wdro�y� poza chmurami, kt�rych u�ywasz na swojej platformie. Musisz zapewni� pe�n� wysok� dost�pno�� w ramach ka�dego centrum danych dzia�a to rozwi�zanie, a tak�e wysoka dost�pno�� w centrach danych. Je�li automatyczne skalowanie nie powiedzie si� z jakiegokolwiek powodu, platforma mo�e ulec awarii. Wa�ne jest, aby zastosowa� wszelkie mo�liwe �rodki, aby zapobiec awariom.

Wymagania dotycz�ce rozwi�zania

Poni�sze sekcje pokazuj� og�lnie, co nale�y zrobi�, aby skalowa� automatycznie.

Zdefiniuj ka�d� warstw�, kt�ra ma zosta� przeskalowana

Na pocz�tek musisz zidentyfikowa� ka�d� warstw�, kt�ra musi zosta� przeskalowana. Wsp�lne poziomy obejmuj� serwery aplikacji, serwery pami�ci podr�cznej, serwery przesy�ania wiadomo�ci i serwery baz danych NoSQL. W ramach ka�dej warstwy istnieje wiele typ�w instancji, z kt�rych niekt�re mo�na skalowa�, a niekt�re nie. Na przyk�ad wi�kszo�� poziom�w ma jeden serwer administracyjny, kt�ry nie mo�e i nie powinien by� skalowany. Jak wspomniano wcze�niej, niekt�re poziomy s� sta�e i nie mo�na ich dynamicznie skalowa�. Na przyk�ad warstwa relacyjnej bazy danych jest do�� statyczna i nie mo�na jej dynamicznie skalowa�.

Zdefiniuj zale�no�ci mi�dzy poziomami

Po zidentyfikowaniu ka�dej warstwy musisz zdefiniowa� zale�no�ci mi�dzy nimi. Niekt�re poziomy wymagaj� wcze�niejszego udost�pnienia innych poziom�w. Wcze�niejszym przyk�adem zastosowanym w tej cz�ci by�o dodanie wi�kszej liczby serwer�w aplikacji bez wcze�niejszego dodawania kolejnych serwer�w przesy�ania komunikat�w. Mog� istnie� skomplikowane zale�no�ci mi�dzy poziomami i mi�dzy komponentami w ramach ka�dej warstwy. Zale�no�ci mog� si� kaskadowo. Na przyk�ad dodanie serwera aplikacji mo�e wymaga� dodania serwera przesy�ania komunikat�w, kt�ry sam mo�e wymaga� innego w�z�a bazy danych NoSQL.

Zdefiniuj stosunki mi�dzy poziomami

Po zidentyfikowaniu zale�no�ci mi�dzy poszczeg�lnymi poziomami musisz zdefiniowa� stosunki mi�dzy poszczeg�lnymi poziomami, je�li kiedykolwiek b�dziesz w stanie proaktywnie zapewni� pojemno��. Na przyk�ad mo�e si� okaza�, �e potrzebujesz serwera pami�ci podr�cznej dla ka�dego z dw�ch serwer�w aplikacji. W przypadku proaktywnego udost�pniania zdolno�ci nale�y si� upewni� ,�e ka�dy z poziom�w we w�a�ciwych ilo�ciach.

Okre�l, co monitorowa�

Nast�pnie dla ka�dej warstwy musisz zdefiniowa� metryki, kt�re spowoduj� zwi�kszenie lub zmniejszenie skali. W przypadku serwer�w aplikacji mo�e to by� procesor (je�li aplikacja jest zwi�zana z procesorem) lub pami�� (je�li aplikacja jest zwi�zana z pami�ci�). Inne wska�niki obejmuj� wykorzystanie dysku, wykorzystanie pami�ci i wykorzystanie sieci. Ale, jak wspomniano wcze�niej, dane mog� by� ca�kowicie niestandardowe dla ka�dego bitu oprogramowania. Liczy si� to, �e znasz w�skie gard�a na ka�dym poziomie i mo�esz dok�adnie przewidzie�, kiedy ten poziom zacznie zawodzi�.

Monitoruj ka�dy serwer i agreguj dane na ka�dej warstwie

Nast�pnie musisz monitorowa� ka�dy serwer w tej warstwie i przekaza� raport scentralizowanemu kontrolerowi, kt�ry jest w stanie agregowa� te dane, aby� wiedzia�, co si� dzieje na ca�ej warstwie, a nie na tym, co dzieje si� na ka�dym serwerze. Wykorzystanie dowolnego serwera mo�e by� bardzo wysokie, ale og�lny poziom mo�e by� OK. Nie ka�dy serwer b�dzie mia� idealnie jednolite wykorzystanie.

Zdefiniuj zasady skalowania ka�dej warstwy

Teraz, gdy wszystkie zale�no�ci s� na miejscu, trzeba okre�li� zasady skalowania ka�dej kondygnacji. Regu�y s� zdefiniowane dla ka�dej warstwy i s� zgodne ze standardow� logik� if / then. If powinien by� zwi�zany z powrotem do metryki rz�du szeroko�ci, jak procesora i wykorzystanie pami�ci. Ni�szego wykorzystanie powoduje zwi�kszenie bezpiecze�stwa, ale s� kosztem nadmiarowego. Klauzula wtedy mo�e przyj�� dowoln� liczb� i dowoln� kombinacj� nast�puj�cych element�w:

• Dodaj pojemno��
• Zmniejszenie pojemno�ci
• Wy�lij powiadomienie e-mail
• Spadek wiadomo�� na kolejki
• Z�� zapytanie HTTP

Zazwyczaj b�dziesz mie� minimum dw�ch regu� dla ka�dej kondygnacji:

1. Dodanie wi�kszej pojemno�ci
2. Zmniejszenie potencja�u

Je�li s� jakie� wyj�tki, otrzymasz powiadomienie e-mailem lub SMS-em, aby� m�g� podj�� dzia�ania naprawcze. Twoje rozwi�zanie powinno zapewnia� zabezpieczenia, kt�re zapewni�, �e nie zapewnisz go bezterminowo. Je�li wdro�ona aplikacja ma warunek wy�cigu, kt�ry gwa�townie przyspiesza wykorzystanie procesora, nie chcesz zapewnia� jej bezterminowo. Zawsze nale�y ustawi� limity liczby serwer�w, kt�re mo�na wdro�y�

Budowanie rozwi�zania automatycznego skalowania

Niezale�nie od tego, czy zbudujesz, czy kupisz jedno z tych rozwi�za�, b�dziesz u�ywa� tych samych interfejs�w API do wykonywania takich czynno�ci, jak dostarczanie nowych serwer�w, wycofywanie niewykorzystanych serwer�w, rejestrowanie serwer�w za pomoc� modu��w r�wnowa�enia obci��enia i stosowanie zasad bezpiecze�stwa. Dostawcy us�ug w chmurze udost�pnili te interfejsy API i u�atwiaj� im korzystanie z podstawowych element�w ich oferty. Sposoby ��czenia z interfejsami API cz�sto obejmuj�:

• Graficzny interfejs u�ytkownika
• Narz�dzia wiersza polece�
• Us�ugi sieciowe RESTful
• Us�ugi sieciowe SOAP

Te interfejsy API s� tym, czego wszyscy u�ywaj� do ��czenia si� z chmurami w podobny spos�b, jak interfejsy API nap�dzaj� przej�cie do omnichannel. Interfejs (bez wzgl�du na to, czy jest to graficzny interfejs u�ytkownika, narz�dzie wiersza polecenia, czy jaka� odmiana us�ugi internetowej) jest mniej lub bardziej jednorazowym �rodkiem do komunikacji z podstawowym zestawem interfejs�w API

OpenStack to popularny stos zarz�dzania chmur� typu open source, kt�rego rdzeniem jest zestaw interfejs�w API. Wszyscy dostawcy us�ug w chmurze oferuj� interfejsy API tego rodzaju. Oto kilka przyk�ad�w wykonywania typowych czynno�ci:

Utw�rz obraz maszyny (migawka systemu plik�w)
// POST HTTP do / images
{
"id": "production-ecommerce-application-page-server",
"name": "Production eCommerce Application Page Server",
}
Zapisz obraz maszyny
// HTTP PUT to /images/{image_id}/file Content-Type must be 'application/octet-stream'
Lista cechdost�pnych zdj��
// HTTP GET to / flavours
{
"cechy": [
{"id": "1", "name": "m1.tiny"},
{"id": "2", "name": "m1.small"},
{"id": "3", "name": "m1.medium"},
{"id": "4", "name": "m1.large"},
{"id": "5", "name": "m1.xlarge"}
]
}
Zarejestrowany sprz�t
// HTTP POST to /{tenant_id}/servers
{
"server": {
"flavorRef": "/flavors/1",
"imageRef": "/images/production-ecommerce-application-page-server",
"metadata": {
"JNDIName": "CORE"
},
"name": "eCommerce Server 221",
}
}
Wyrejestrowanie sprz�tu
// HTTP POST do / {tenant_id} / servers / {server_id}

Mo�esz po��czy� te interfejsy API i po��czy� je za pomoc� narz�dzia do monitorowania, aby stworzy� do�� kompleksowe rozwi�zanie do automatycznego skalowania. Pod warunkiem, �e sprzedawca udost�pnia wszystkie odpowiednie interfejsy API, zbudowanie niestandardowej aplikacji do obs�ugi administracyjnej nie jest trudne. Mo�esz tak�e skorzysta� z rozwi�zania oferowanego przez dostawc� us�ug w chmurze.

Budowanie a kupowanie rozwi�zania do automatycznego skalowania

Podobnie jak wi�kszo�� oprogramowania, rozwi�zania do automatycznego skalowania mo�na budowa� lub kupowa�. Jak ka�de oprogramowanie, musisz zdecydowa�, w kt�rym kierunku chcesz i��. Og�lnie rzecz bior�c, je�li nie mo�esz si� wyr�ni�, buduj�c co� niestandardowego, powiniene� wybra� jakie� gotowe rozwi�zanie, niezale�nie od tego, czy jest to rozwi�zanie komercyjne sprzedawane przez zewn�trznego dostawc� lub zintegrowane rozwi�zanie wbudowane w chmur�. Liczy si� to, �e masz wyj�tkowo niezawodne, solidne rozwi�zanie, kt�re mo�na rozbudowywa� w celu zaspokojenia przysz�ych potrzeb. Og�lnie rzecz bior�c, najlepiej jest kupi� jedno z tych rozwi�za�, ni� je zbudowa�. Znajd� to, co dzia�a dla Ciebie i zastosuj to. Wszystko mo�e by� lepsze ni� to, co masz dzisiaj

e-Commerce w ChmurzeHandel

Automatyczne skalowanie w chmurze