Wdra�anie w wielu centrach danych (Multimaster)

Tu skupimysi� na jednej platformie e-commerce i uruchomieniu jej z dw�ch lub wi�cej fizycznych centr�w danych, kt�re s� geograficznie od siebie oddzielone. Chocia� zak�ada si�, �e te centra danych znajduj� si� w chmurze, wi�kszo�� zasad om�wione maj� zastosowanie do tradycyjnych uzgodnie� dotycz�cych hostingu. Zaczniemy od om�wienia podstawowego problemu prowadzenia eCommerce z wielu centr�w danych, zasad architektury le��cych u podstaw przetwarzania rozproszonego, jak przypisywa� klient�w do poszczeg�lnych centr�w danych, a wreszcie r�nych podej�� do dzia�ania z wielu centr�w danych. Wielu dostawc�w e-commerce dzia�a ju� z dw�ch centr�w danych z pewn� pojemno�ci�, aby zapewni� najwy�sz� mo�liw� dost�pno��. Trend ten przyspieszy w nadchodz�cych latach, poniewa� platformy e-commerce staj� si� coraz wa�niejsze dla biznesu. W dzisiejszym �wiecie wielokana�owym awaria w coraz wi�kszym stopniu powoduje zamkni�cie ka�dego kana�u w celu generowania przychod�w. Kiedy� awaria strony by�a oczywi�cie nieprzyjemna, ale by�a odizolowana od tego kana�u. Obecnie wiele system�w sprzeda�y, kiosk�w i aplikacji mobilnych korzysta z tej samej platformy. Przerwy w dzisiejszych czasach maj� miejsce na ca�ej platformie, a zatem wp�ywaj� na wszystkie kana�y. Przed naruszeniem bezpiecze�stwa przed�u�aj�ce si� lub powtarzaj�ce si� przerwy s� najpewniejszym sposobem na utrat� pracy. Wdro�enie tej samej platformy w dw�ch lub wi�cej centrach danych w konfiguracji aktywnej / pasywnej lub wielopunktowej pomaga zapewni� dost�pno��, zapewniaj�c odporno�� na kl�ski �ywio�owe (np. Huragany, tajfuny, po�ary, powodzie), b��dy ludzkie (np. Przeci�cia kabli, b��dne konfiguracje) , przerwy w dostawie (np. utrata zasilania, utrata po��czenia z Internetem) i problemy z oprogramowaniem (np. b��dy, problemy z aktualizacj�). Jest na przyk�ad ma�o prawdopodobne, aby na dowolne dwa centra danych na �wiecie wp�yn�� ten sam po�ar lub przeci�cie kabla. W ka�dym centrum danych powinna istnie� nadmiarowo�� i og�lnie dzia�a bardzo dobrze. Ale czy m�g�by� zaufa� swojemu dostawcy us�ug w chmurze i gwarancjom zastosowanym przez dostawc� w ka�dym centrum danych? Jak wielokrotnie widzieli�my, jedynym sposobem na zapewnienie dost�pno�ci jest u�ycie wielu centr�w danych, najlepiej jak najdalej od siebie. Historycznie platformy e-commerce zosta�y zaprojektowane z my�l� o najlepszej mo�liwej dost�pno�ci, zwykle tylko w jednym centrum danych. Nacisk na dost�pno�� ma pierwsze�stwo: detaliczne systemy sprzeda�y. Wi�kszo�� system�w w punktach sprzeda�y ma dwie lub wi�cej unikalnych metod po��czenia z domowym biurem w celu wykonania kluczowych funkcji, takich jak �adowanie kart kredytowych i wystawianie zwrot�w. Po��czenie telefoniczne jest nadal powszechnie u�ywane jako kopia zapasowa. Je�li podstawowy i zapasowy nie powiedzie si�, wielu sprzedawc�w b�dzie nadal przyjmowa� zam�wienia o warto�ci poni�ej 25 USD lub 50 USD, a nast�pnie przeprowadzi autoryzacj� karty kredytowej w p�niejszym terminie, kiedy po��czenie b�dzie mo�na ponownie nawi�za�. Chocia� mo�liwe jest, �e kilka op�at nie zosta�o pomy�lnie autoryzowanych, strata prawdopodobnie b�dzie ni�sza ni� koszt braku otwarcia dla firmy. Wiele system�w e-commerce dzia�a w ten sam spos�b: je�li brama p�atno�ci, system zarz�dzania zapasami lub inny system jest wy��czony, system mo�e nadal odbiera� zam�wienia, ale czeka� na faktyczne obci��enie kart kredytowych, zmniejszenie zapas�w i tak dalej. Zalet� transakcji e-commerce jest to, �e wszelkie wykryte problemy mo�na naprawi� przed wysy�k� towar�w. W fizycznym sklepie detalicznym klienci wychodz� z produktami. Je�li p�niej oka�e si�, �e autoryzacja karty kredytowej nie powiod�a si�, nie mo�esz odzyska� produkt�w. Podczas gdy potrzeba dost�pno�ci ro�nie, chmura i jej wymagania sprawiaj�, �e obs�uga z wielu centr�w danych jest jeszcze �atwiejsza i bardziej przyst�pna cenowo. Automatyczne skalowanie, instalowanie oprogramowania na nowo wyposa�onym sprz�cie, solidna architektura i globalne r�wnowa�enie obci��enia serwera s� podstaw� dzia�ania z wielu centr�w danych. Sama chmura i wprowadzana przez ni� elastyczno�� sprawiaj�, �e obs�uga z wielu centr�w danych jest niezwykle tania. Przed przetwarzaniem w chmurze ka�de centrum danych, z kt�rego dzia�a�e�, musia�o mie� wystarczaj�cy sprz�t, aby m�c obs�u�y� 100% ruchu produkcyjnego na wypadek jedno z centr�w danych mia�o awari�. Ca�y ten sprz�t zwykle pozostaje bezczynny przez prawie kilka minut w roku. Zbudowanie ca�ej drugiej (lub trzeciej) repliki jest niezwykle kosztowne - zar�wno pod wzgl�dem nak�ad�w kapita�owych z g�ry, jak i bie��cej konserwacji. Wprowadzenie chmury ca�kowicie to zmienia. Mo�esz mie� infrastruktur� pow�oki i szybko j� skalowa� w razie awarii. Wszystko to zale�y od tego, jak dobrze instalujesz oprogramowanie na nowo wyposa�onym sprz�cie, od tego, jak dobra jest twoja architektura, od tego, czy korzystasz z r�wnowa�enia obci��enia globalnego serwera i od tego, jak dobrze mo�esz skalowa� automatycznie. Bez odpowiedniego spe�nienia tych wymaga� nie powiniene� nawet tego pr�bowa�. Podobnie jak sama chmura, przyj�cie architektury wielostanowiskowej tylko pogarsza techniczne i nietechniczne braki.

G��wny problem dzia�ania z wielu centr�w danych

G��wny problem z dzia�aniem z wielu centr�w danych, kt�ry jest do�� unikalny dla e-commerce, polega na tym, �e mo�esz mie� wielu klient�w loguj�cych si� przy u�yciu tego samego konta (np. Kombinacji nazwy u�ytkownika i has�a) z r�nych centr�w danych. Ka�de konto ma sw�j w�asny profil klienta, koszyk i inne dane. Dane te s� przechowywane w jakiej� bazie danych, przy czym wszystkie te dane musz� by� replikowane w r�nych centrach danych, z kt�rych obs�ugiwana jest platforma. �adne podstawowe dane w e-commerce, takie jak profile klient�w i koszyki, nie mog� zosta� utracone. Problemem, kt�ry tworzy wiele r�wnoczesnych logowa�, jest to, �e je�li dw�ch klient�w zaktualizuje te same dane w tym samym czasie z dw�ch r�nych lokalizacji, jedno dzia�anie klienta zako�czy si� sukcesem, a drugie zako�czy si� niepowodzeniem, co mo�e spowodowa� uszkodzenie danych po drodze. Z powodu op�nie� baza danych w jednym centrum danych nie wie w czasie rzeczywistym, co si� dzieje w bazie danych w innym centrum danych. O ile nie zablokujesz r�wnoczesnego logowania, zawsze b�dzie wyst�powa� problem wielu aktualizacji z r�nych centr�w danych. Zaskakuj�co cz�sto zdarza si�, �e wiele r�nych logowa� dla tego samego konta znajduje si� w r�nych centrach danych. Mo�e si� tak zdarzy�, gdy klienci udost�pniaj� swoje dane logowania w rodzinie, znajomym i coraz cz�ciej w mediach spo�eczno�ciowych. Lojalni klienci otrzymuj� specjalne rabaty, wi�c istnieje silna zach�ta do dzielenia si� danymi logowania, aby uzyska� lepsz� ofert� lub po prostu dla wygody. Ten problem mo�e si� r�wnie� zdarzy�, gdy agenci contact center modyfikuj� zam�wienie w tym samym czasie, co klient. Wyobra� sobie scenariusz, do kt�rego dzwoni klient centrum kontaktowe w celu zaktualizowania zam�wienia, ale aktywnie kontynuuje pr�b� rozwi�zania problemu podczas rozmowy telefonicznej. Te scenariusze s� powszechne. Kosztem awarii s� og�lnie uszkodzone dane. Problem ten narasta, poniewa�:

• Klienci dokonuj� transakcji w wi�kszej liczbie kana��w z wi�kszej liczby urz�dze�.
• Dostawcy e-commerce kieruj� reklamy do segment�w lub okre�lonych klient�w, zwi�kszaj�c w ten spos�b motywacj� do dzielenia si� kontami.
• Media spo�eczno�ciowe nadal umo�liwiaj� klientom udost�pnianie kont.

Sposobem na zmniejszenie (ale nie wyeliminowanie) prawdopodobie�stwa wyst�pienia tego scenariusza jest u�ycie dok�adnego r�wnowa�enia obci��enia globalnego serwera opartego na blisko�ci, co zapewnia, �e klienci w tym samym mie�cie, stanie, zbiorze stan�w, kraju lub kontynencie uderz� w to samo Centrum danych. Wi�c je�li klient jest w jednym pokoju na iPadzie, a jego c�rka jest w drugim na laptopie, obaj powinni przynajmniej uderzy� w to samo centrum danych i dokona� transakcji z t� sam� baz� danych. Om�wimy to wkr�tce.

Zasady architektury

Chocia� istniej� metody zmniejszania prawdopodobie�stwa wyst�pienia kolizji, problem nale�y kompleksowo rozwi�za�. Zepsujesz swoje dane i zdenerwujesz klient�w, je�li nic nie zrobisz lub je�li zastosujesz z�e rozwi�zanie. Zasad�, kt�rej nale�y przestrzega�, jest upewnienie si�, �e wszyscy klienci zalogowani do tego samego konta aktualizuj� t� sam� baz� danych (lub inny system zapisu) w ramach jednej logicznej bazy danych. Mo�esz mie� dwie lub wi�cej aktywnych baz danych z pe�n� dwukierunkow� replikacj�, ale wszystkie zapisy dla danego konta musz� mie� t� sam� logik� baz� danych w tym samym centrum danych. Dwa czynniki w du�ej mierze determinuj� wybrane przez ciebie podej�cie:

Cel czasu regeneracji (RTO)

Jak szybko musisz wyj�� z awarii centrum danych? Zakres warto�ci wynosi od zera do wielu godzin, w zale�no�ci od wybranego podej�cia. Je�li wdra�asz tylko z jednego centrum danych, ta warto�� mo�e wynosi� tygodnie. Aktywny / pasywny trwa zwykle co najmniej godzin�. Formy aktywne / aktywne zwykle zapewniaj� zerowe przestoje, nawet w przypadku ca�kowitego wy��czenia centrum danych. Im ni�sza warto�� RTO, tym wi�cej pracy i wi�kszy koszt.

Zdolno�� do wykonywania

Jak dobrze ty i Twoja organizacja robicie trudne rzeczy? Wszystko to jest bardzo skomplikowane, szczeg�lnie z chmur� wrzucon� do mieszanki. Wdro�enie wymaga znacznej wiedzy technicznej, czasu, pe�nego wsparcia organizacyjnego i du�ej ilo�ci pieni�dzy. Je�li masz problem z utrzymaniem platformy dost�pnej z jednego centrum danych, kt�rym zarz�dzasz, wdro�enie jej w dw�ch lub wi�cej centrach danych w chmurze nie jest czym�, co powiniene� rozwa�y�. Cel punktu odzyskiwania (RPO) okre�la, ile danych mo�na utraci�, i zwykle stanowi podstaw� planowania ci�g�o�ci dzia�ania. Jednak nikt zaanga�owany w e-commerce nie ma nic przeciwko zerowym warto�ciom dla podstawowych danych, takich jak profile klient�w i koszyki. Utrata danych jest po prostu nie do przyj�cia dla niekt�rych klas danych. Zasady i podej�cia w tej cz�ci s� zorientowane wok� tego za�o�enia.

Zasady rz�dz�ce przetwarzaniem rozproszonym

Za komputerami rozproszonymi kryje si� ogromna literatura naukowa i bran�owa na temat informatyki. Dog��bna dyskusja na temat tych zasad nie wchodzi w zakres tej ksi��ki, ale kr�tki przegl�d zasad i kompromis�w zwi�zanych z przetwarzaniem rozproszonym jest w�a�ciwy przed kontynuowaniem. Modele sp�jno�ci reguluj� warunki, w kt�rych zapis w rozproszonej bazie danych b�dzie widoczny dla innych czytelnik�w. Rozproszona baza danych mo�e by� pojedyncz� instancj� bazy danych z�o�on� z wielu w�z��w lub wielu instancji bazy danych w r�nych centrach danych. Bazy danych maj� tendencj� do pod��ania za jednym modelem sp�jno�ci lub odmian� tego modelu. Modele sp�jno�ci maj� zastosowanie do wszystkich problem�w przetwarzania rozproszonego w informatyce, od system�w plik�w po pami��. Silna sp�jno��, znana jako ACID, oznacza:

Atomicity (Atomowo��) : Ca�a transakcja ko�czy si� powodzeniem lub niepowodzeniem.
Consistency (Konsystencja) : Transakcja zostaje pope�niona bez naruszenia jakichkolwiek ogranicze� integralno�ci (np. Typ danych, czy kolumna ma warto�� zerow�, ograniczenia klucza obcego).
Isolation (Izolacja) ; Ka�da transakcja jest wykonywana we w�asnym prywatnym obszarze izolowanym i nie jest widoczna dla �adnej innej transakcji, dop�ki nie zostanie zatwierdzona.
Durability (Trwa�o��) : Dokonana transakcja nie zostanie utracona.

Zak�ada si�, �e wszystkie transakcje powinny by� zgodne z ACID, ale cz�sto jest to niepotrzebne. Na przyk�ad dane zwi�zane z produktem (np. Opis, atrybuty i metadane zwi�zane z optymalizacj� wyszukiwarki) mo�na prawdopodobnie zapisa� w jednym w�le w jednej bazie danych i propagowa� asynchronicznie w innych w�z�ach i bazach danych. Je�li czytelnicy zobacz� niesp�jne dane przez kilka sekund, prawdopodobnie nie jest to wielka sprawa. Bardzo ma�o danych musi by� bardzo sp�jnych. Klienci nie b�d� tolerowa� nie widzie� profilu klienta a zmiany zwi�zane z zam�wieniami s� natychmiast odzwierciedlane. Podstawowe dane klient�w powinny zawsze by� przechowywane w bazie danych zgodnej z ACID. Zmuszaj�c wszystkich klient�w zalogowanych do tego samego konta do korzystania z tej samej bazy danych, zapewniasz siln� sp�jno�� danych konkretnego klienta we wszystkich instancjach bazy danych. S�aba konsystencja, znana jako BASE, pozwala unikn�� ciasnych ogranicze� ACID:

- Podstawowa dost�pno��
- System jest og�lnie dost�pny do aktualizacji.
- Stan mi�kki

Dane nie s� trwa�e - mog� znajdowa� si� w pami�ci i mog� zosta� utracone w przypadku awarii.

Ostateczna sp�jno��

Czytelnik mo�e nie widzie� najbardziej aktualnej kopii danych, poniewa� replikacja odbywa si� asynchronicznie. BASE staje si� coraz bardziej powszechny, poniewa� zapisy s� znacznie szybsze, a systemy znacznie bardziej skalowalne, a kompromis w sp�jno�ci wystarcza dla wielu rodzaj�w danych. Wszystkie popularne platformy medi�w spo�eczno�ciowych s� w wi�kszo�ci PODSTAWOWE. Ponownie tylko stosunkowo niewielki podzbi�r wymaga pe�nej zgodno�ci z ACID. Istnieje kontinuum mi�dzy ACID a BASE. Musisz wybra� to, co najbardziej Ci odpowiada i ka�dy rodzaj danych, kt�re musisz przechowywa�. Cz�sto same bazy danych pozwalaj� na okre�lenie po��danego modelu sp�jno�ci na do�� szczeg�owej podstawie. Oczywi�cie BASE jest prawdopodobnie wystarczaj�cy do napisania dziennika kontroli, podczas gdy dla zam�wie� wymagany jest ACID. A co z zapasami i cenami? To troch� szara strefa. Wymagane jest staranne rozwa�enie, a nast�pnie wdro�enie. �adna dyskusja na temat modeli sp�jno�ci nie jest kompletna bez kr�tkiej dyskusji na temat twierdzenia CAP Erica Brewera, kt�re stwierdza, �e ka�dy system rozproszony mo�e zagwarantowa� dwa z nast�puj�cych trzech:

• Konsystencja
• Brak konflikt�w danych
• Dost�pno��
• Brak pojedynczego punktu awarii
• Tolerancja podzia�u
• System utrzymuje dost�pno�� i sp�jno��, je�li problem z sieci� izoluje cz�� systemu

Systemy rozproszone, szczeg�lnie z chmur� obliczeniow�, nie mog� zagwarantowa� tolerancji partycji, poniewa� po��czenia mi�dzy bazami danych s� z natury zawodne. Dlatego musisz dokona� kompromisu mi�dzy sp�jno�ci� (faworyzuje ACID) a dost�pno�ci� (faworyzuje BAZA). Nie mo�esz mie� obu.

Unikanie konflikt�w

Dwukierunkowe narz�dzia do replikacji bazy danych maj� zdolno�� wykrywania i rozwi�zywania konflikt�w. Wykrywanie i rozwi�zywanie konflikt�w jest integraln� cz�ci� tych ofert. Je�li dw�ch klient�w aktualizuje to samo zam�wienie w tym samym czasie z dw�ch centr�w danych w odleg�o�ci 100 milisekund od siebie i obaj aktualizuj� ten sam rekord w tym samym czasie w tym oknie o d�ugo�ci 100 milisekund, nast�pi kolizja. Podobnie, je�li dw�ch klient�w aktualizuje ten sam obiekt (np. Profil klienta lub zam�wienie), nast�pi r�wnie� kolizja. Poni�sze przyk�ady ilustruj� ten potencjalny problem. Klient 1, konto "kellygoetsch", centrum danych A:

update order set submitted = 1 where order_id='12345';
(100 milliseconds of latency)
Customer 2, account "kellygoetsch," data center B:
insert into order_lines (order_id, sku_id, quantity)
values ('12345', '54321', 1);

W tym przyk�adzie dw�ch klient�w wykonuje przeciwne dzia�ania: jeden sk�ada zam�wienie (wykonuje ostateczn� wycen�, przesy�a je do systemu zaplecza), a drugi dodaje kolejny element do zam�wienia. To oczywi�cie doprowadzi do problem�w. Nie mo�esz doda� elementu do zam�wienia, je�li zam�wienie zosta�o z�o�one, ale inny klient nie wie, �e zosta�o ono przes�ane z powodu 100 milisekund op�nienia. Ten przyk�ad podkre�la g��wny problem zwi�zany z wykrywaniem i rozwi�zywaniem konflikt�w. Tak, cz�sto mo�e to technicznie dzia�a�, ale wyniki mog� nie by� zgodne z oczekiwaniami. Czy zam�wienie tego klienta zostanie dostarczone wraz z SKU 54321? Czy jej karta kredytowa zostanie obci��ona? Czy ta klientka chcia�a doda� ten przedmiot do koszyka, czy mo�e to jej dziecko bawi�o si� na iPadzie w innym pokoju? Kto wie. To jest problem. Bardziej technicznym problemem jest to, �e wi�kszo�� platform e-commerce pisze do bazy danych za pomoc� systemu mapowania obiektowo-relacyjnego (ORM). Systemy te pozwalaj� na interakcj� kodu z rzeczywistymi obiektami reprezentowanymi w kodzie, w przeciwie�stwie do SQL. Na przyk�ad mo�esz wywo�a� order.setProperty ("przes�ane", prawda), w przeciwie�stwie do r�cznego konstruowania zestawu zam�wienia aktualizacji przes�anego = 1, gdzie order_id = 12345; SQL r�cznie. Systemy te generuj� ogromn� liczb� instrukcji SQL, poniewa� zosta�y zbudowane z my�l� o maksymalnej elastyczno�ci i przeno�no�ci w przeciwie�stwie do wydajno�ci SQL. Dzi�ki jednemu dzia�aniu (np. Dodaniu do koszyka) generuj�cemu potencjalnie dziesi�tki pojedynczych instrukcji SQL, mo�esz napotka� potencjalne niesp�jno�ci, gdy niekt�re aktualizacje i wstawki si� powiod�, a inne zawiod�. Wyznaczenie dzia�a� na podstawie transakcji w bazie danych jest trudne, je�li nie niemo�liwe. Instrukcje SQL maj� tendencj� do przep�ywu z aplikacji do bazy danych w ba�aganiarskich, nak�adaj�cych si�, nadmiernie szczeg�owych transakcjach lub w og�le bez transakcji. Niezwykle trudno jest wyznaczy� akcj� (np. Dodanie przedmiotu do koszyka) z wyra�nymi granicami transakcji w bazie danych. Nawet je�li uda�o Ci si� uruchomi� rozwi�zywanie konflikt�w i wykrywanie, radzi�by� sobie z problemem braku pami�ci podr�cznej. Platformy swobodnie buforuj� dane na wszystkich warstwach. Jak od�wie�y� pami�� podr�czn� wy�szego poziomu, obiektow� po zastosowaniu zmiany replikacja bazy danych? Pami�� podr�czna jest zwykle ustawiona na aktualizacj� tylko wtedy, gdy zmiany dokonano za po�rednictwem warstwy ORM. Ale kiedy zmiana zostanie zastosowana bezpo�rednio do bazy danych, trudno jest powiedzie� platformie, jak zaktualizowa� swoje pami�ci podr�czne. Je�li nie korzystasz z tradycyjnej relacyjnej bazy danych, nadal masz wiele takich samych problem�w, ale tylko w innej formie. Kiedy masz do czynienia z obiektami lub parami klucz-warto��, ko�czysz nadpisywanie wi�kszej ilo�ci danych, poniewa� systemy te nie s� tak szczeg�owe jak odpowiednia relacyjna baza danych ze znormalizowanymi danymi. Po prostu nadpiszesz ca�e zam�wienie w przeciwie�stwie do jego w�a�ciwo�ci, ale jest to r�wnie z�e z powodu wszystkich wsp�zale�no�ci mi�dzy obiektami. Jedynym sposobem zapewnienia sp�jno�ci jest upewnienie si�, �e wszyscy klienci zalogowani do tego samego konta aktualizuj� t� sam� baz� danych lub inny system zapisu. To wci�� wymaga wyzwa�, ale jest to przynajmniej status quo i te problemy mo�na rozwi�za�.

Wyb�r centrum danych

Przed rozpocz�ciem przetwarzania w chmurze sta�y koszt dzia�ania z centrum danych by� bardzo wysoki. Trzeba by�o fizycznie zbudowa� centrum danych lub wynaj�� troch� miejsca w istniej�cym centrum danych. Nast�pnie trzeba by�o statycznie zbudowa� swoje �rodowisko, tak aby mog�o ono obs�u�y� 100% obci��enia produkcyjnego, gdyby by�o to jedyne centrum danych lub inne centrum danych zosta�o wy��czone. Chmura sprawia, �e niezwykle �atwe jest uruchamianie z wielu centr�w danych, eliminuj�c narzut zwi�zany z obs�ug� nowego centrum danych i umo�liwiaj�c elastyczne skalowanie w g�r�. Nie musisz ju� skalowa� �rodowiska tylko po to, aby pozostawa�o ca�kowicie bezczynne. Z punktu widzenia API centrum danych jest cz�sto tylko jeszcze jedn� zmienn�. Optymalna liczba centr�w danych do obs�ugi to dwa lub trzy. Co� wi�cej ni� to jest do�� marnotrawstwem. Cokolwiek mniej, a nie masz wystarczaj�cej redundancji, aby uchroni� si� przed awariami. Wielu powo�uje si� na ograniczenie op�nie� jako przyczyn� budowy tak wielu centr�w danych. Jak om�wili�my w cz�ci 7, czas reakcji i op�nienie po stronie serwera stanowi� niewielki u�amek ca�kowitego czasu potrzebnego na wy�wietlenie strony. Klienci rutynowo uzyskuj� dost�p do platform e-commerce hostowanych na r�nych kontynentach. To, �e chmura oferuje mo�liwo�� atwego korzystania z wielu centr�w danych, nie oznacza, �e powiniene�. Dostawcy chmur maj� wiele centr�w danych na ca�ym �wiecie, ale mo�na je podzieli� na segmenty wed�ug koncepcji domeny b��d�w. Ka�dy dostawca ma w�asn� nazw� dla tej koncepcji, ale sprowadza si� do tego, �e istnieje niewiele zale�no�ci lub po��cze� mi�dzy centrami danych w r�nych domenach b��d�w. Ta izolacja powinna zatrzyma� rozprzestrzenianie si� problem�w w r�nych domenach, zapewniaj�c w ten spos�b najwy�szy poziom dost�pno�ci. Na przyk�ad aktualizacje oprogramowania zwykle maj� miejsce na podstawie domen b��d�w. Zawsze nale�y wybiera� centra danych, kt�re s� geograficznie oddzielone (aby unikn�� tej samej kl�ski �ywio�owej, przerwy w dostawie pr�du lub po�aru), ale kt�re r�wnie� znajduj� si� w r�nych domenach b��d�w. Ponownie wszystko czego potrzebujesz to dwa (a mo�e trzy) centra danych, ale musz� by� odpowiednio wybrane. Awarie w ca�ej chmurze s� wyj�tkowo rzadkie, ale wyst�puj�, jak om�wiono w cz�ci 3. Aby uchroni� si� przed awari� w chmurze, mo�esz wdro�y� je u wielu dostawc�w chmury. Jest to sprzeczne z intuicj�, ale mo�e to faktycznie skr�ci� czas pracy, poniewa� dw�ch dostawc�w powoduje co najmniej dwukrotny wzrost z�o�ono�ci. Z�o�ono�� i b��dna konfiguracja wynikaj�ce ze z�o�ono�ci s� g��wn� przyczyn� awarii. W po��czeniu z bardzo wysok� dost�pno�ci�, dzia�anie w dw�ch centrach danych mo�e nie zapewni� dodatkowego wzrostu dost�pno�ci, jakiego mo�na si� spodziewa�.

Inicjowanie ka�dego centrum danych

Wykorzystanie chmury do e-commerce r�ni si� zasadniczo od tradycyjnych wdro�e� statycznych ze wzgl�du na elastyczno�� zapewnian� przez chmur�. Nie trzeba ju� skalowa� ka�dego z centr�w danych, aby obs�u�y� 100% obci��enia produkcyjnego. Mo�esz teraz dowolnie skalowa� w g�r� i w d�, aby spe�ni� wymagania w czasie rzeczywistym. Problem z tym podej�ciem polega na tym, �e w przypadku nag�ej awarii ma�o prawdopodobne jest, aby zachowane �rodowisko (a) posiada�o wystarczaj�c� przepustowo��, aby poradzi� sobie z nag�ym ruchem. W tym momencie system automatycznego skalowania powinien uruchomi� si�, aby rozpocz�� udost�pnianie wi�kszej ilo�ci sprz�tu. Po udost�pnieniu sprz�tu na ka�dym serwerze musi by� zainstalowane oprogramowanie. Zaopatrzenie w sprz�t, a nast�pnie zbudowanie ka�dego serwera zajmuje du�o czasu - potencjalnie kilkadziesi�t minut. Ka�de centrum danych w chmurze nale�y skonfigurowa� z wyprzedzeniem ze szkieletow� struktur�, kt�r� mo�na nast�pnie skalowa�. Nie jest praktyczne budowanie nowego centrum danych w locie w odpowiedzi na awari�. Ale praktyczne jest zabranie czego�, co znajduje si� w centrum danych i bardzo szybkie skalowanie. Ka�de centrum danych powinno zawiera� co najmniej dwa wyst�pienia (dla redundancja) wszystkiego, czego potrzebujesz do dzia�ania �rodowiska - od siatki pami�ci podr�cznej, przez serwery aplikacji, po magistral� us�ug. Pomy�l o tym �rodowisku jako o wielko�ci �rodowiska programistycznego, ale skonfigurowanego do produkcji. To wszystko mo�e by� na dedykowanym sprz�cie, w przeciwie�stwie do normalnie pobieranych op�at godzinnych. Dedykowany sprz�t jest cz�sto znacznie ta�szy ni� cena za godzin�, ale korzystanie z dedykowanego sprz�tu 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. Je�li wdra�asz w�asn� relacyjn� baz� danych, musisz 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. Bazy danych oferowane przez dostawc�w us�ug w chmurze s� bardziej elastyczne, ale oczywi�cie istniej� wady korzystania ze wsp�u�ytkowanych zasob�w. Wykorzystanie bazy danych powinno by� do�� lekkie, je�li masz odpowiedni� architektur�. Zdecydowana wi�kszo�� ods�on pochodzi od anonimowych klient�w (lub bot�w wyszukiwarek) statyczne strony z mo�liwo�ci� buforowania, takie jak strony g��wne i strony ze szczeg�owymi kategoriami. Mo�esz odci��y� wi�kszo�� odczyt�w do baz danych slave. Pomaga pe�ne wykorzystanie siatki pami�ci podr�cznej. Twoja podstawowa baza danych zawieraj�ca dane transakcyjne (np. Zam�wienia, profile klient�w) jest do�� ma�a, zwykle nie wi�cej ni� kilka w�z��w zu�ywa nie wi�cej ni� kilka terabajt�w pami�ci.

Usuwanie singleton�w

Wydaje si�, �e ka�da platforma ma oprogramowanie, kt�re mo�na wdro�y� na dok�adnie jednym serwerze na �rodowisko. Typowe przyk�ady obejmuj� serwery koordynacyjne, serwery przesy�ania wiadomo�ci, broker�w blokady, administracyjne interfejsy u�ytkownika i serwery wykonuj�ce zadania wsadowe. Te przypadki, zwane singletonami, s� klasycznym przyk�adem zasady Pareto, zgodnie z kt�r� 80% czasu sp�dzasz na 20% serwer�w. 20% wydaje si� by� singletonami. Problemy z singletonami obejmuj�:

• Mog� by� pojedynczym punktem awarii. Musisz po�wi�ci� du�o czasu i wysi�ku, aby zapewni� najwy�sz� mo�liw� dost�pno��.
• Ka�dy serwer musi og�lnie wskazywa� na singleton, z unikaln� nazw�, adresem URL, adresem IP lub nazw� domeny. Aktualizacja kilkudziesi�ciu, je�li nie setek pojedynczych serwer�w wymaga ka�dej pracy za ka�dym razem, gdy zmienia si� nazwa lub lokalizacja singletonu. • Niekt�re singletony musz� by� unikalne dla �rodowiska, podczas gdy inne musz� by� unikalne dla bazy danych. Je�li singleton musi by� unikalny dla �rodowiska, co najmniej po�owa ��da� do tego singletonu musi zosta� z�o�ona w centrum danych. Je�li singleton jest unikalny dla bazy danych, potencjalnie b�dziesz musia� poradzi� sobie z konfliktami replikacji bazy danych, poniewa� ka�dy singleton aktualizuje w�asn� baz� danych, a dane s� jednokierunkowo replikowane mi�dzy nimi.
• Przy aktywnym / aktywnym b�dziesz musia� aktywowa� singleton w nowo aktywnym centrum danych po prze��czeniu awaryjnym.
• Wraz ze wzrostem �rodowiska, singleton mo�e napotyka� granice skalowania w pionie. W normalnym �rodowisku, kt�re kontrolujesz, mo�esz rzuci� du�o sprz�tu na takie problemy. W chmurze jeste� ograniczony do maksymalnej ilo�ci sprz�tu oferowanego przez dostawc� dla pojedynczego serwera.
• Musisz utworzy� jednostk� wdra�ania dla tego singletonu.

Najlepiej jest zaprojektowa� swoje rozwi�zanie, aby ca�kowicie unika� singleton�w, a je�li musz� istnie�, pozwoli�, aby ka�da instancja przej�a t� odpowiedzialno��. Na przyk�ad, zamiast dedykowanego serwera, kt�ry jest odpowiedzialny za okresowe przebudowywanie indeksu wyszukiwania, ka�dy serwer, kt�ry odpowiada na zapytania, mo�e zbudowa� niewielk� cz�� indeksu z boku. Lub popro�, aby twoje w�z�y wyznaczy�y jeden w�ze� do okresowego wykonywania tego zadania. Architektura, kt�ra nie opiera si� na singletonach, jest lepsza pod ka�dym wzgl�dem.

Nigdy nie replikuj konfiguracji

Unikaj pokusy replikacji konfiguracji, niezale�nie od tego, czy znajduje si� ona w bazie danych, czy w systemie plik�w. Logiczne jest powielanie wszystkiego, ale nale�y pami�ta�, �e wi�kszo�� awarii spowodowanych jest wprowadzeniem z�ej konfiguracji. W przypadku replikacji konfiguracji wystarczy odtworzy� problem. To jest dok�adnie pow�d, dla kt�rego nie wdra�asz kodu w dw�ch lub wi�cej centrach danych jednocze�nie. Poczekaj, aby zobaczy�, jak to dzia�a, a nast�pnie wdr� go w innym miejscu. To samo dotyczy konfiguracji.

Przypisywanie klient�w do centr�w danych

DNS

Elementarz DNS

Jak kr�tko om�wili�my w cz�ci 2, DNS istnieje, wi�c klienci nie musz� pami�ta� adres�w IP. Zamiast tego mog� pami�ta� kr�tkie nazwy, takie jak website.com, kt�re s� sparowane z adresami IP. Ka�de centrum danych, z kt�rego dzia�asz, jest zazwyczaj nara�one na ca�y �wiat jako pojedynczy adres IP. Sercem systemu jest zapis. Ka�da nazwa domeny ma autorytatywny serwer DNS, kt�ry jest jedynym �r�d�em prawdy dla tej nazwy domeny. Tw�j klient (np. Przegl�darka internetowa, urz�dzenie mobilne) prawdopodobnie b�dzie mia� w�asn� pami�� podr�czn� rekord�w DNS. System operacyjny Twojego klienta prawdopodobnie ma w�asn� pami�� podr�czn�. Tw�j dostawca us�ug internetowych najprawdopodobniej ma serwery DNS, kt�re r�wnie� buforuj� rekordy. Serwery DNS rekurencyjnie kaskaduj� ��danie rozstrzygni�cia do autorytatywnego serwera DNS, a ka�dy po�rednik buforuje rekord po drodze. Ka�dy rekord ma czas prze�ycia (TTL), okre�laj�c, jak d�ugo rekord mo�e by� buforowany przez dowolnego po�rednika mi�dzy klientem a autorytatywnym serwerem. Warto�ci TTL mieszcz� si� w przedziale od zera sekund do kilku dni, a zapisy zwykle wygasaj� po pi�ciu minutach. DNS jest ostatecznie sp�jnym systemem, w kt�rym rekordy mog� by� nieaktualne przez okres nieprzekraczaj�cy TTL. DNS obs�uguje wiele rekord�w A, co oznacza, �e witryna.com.com mo�e rozwi�za� dwa lub wi�cej unikalnych adres�w IP, przy czym ka�dy adres IP reprezentuje centrum danych. Wyniki s� uporz�dkowane, tak aby pierwszy zwr�cony adres IP mia� by� pierwszym adresem IP, z kt�rym ��czy si� klient. Ka�da witryna internetowa wymaga wiarygodnego serwera DNS. Mo�esz samodzielnie hostowa� DNS lub zleca� na zewn�trz dostawcy oprogramowania DNS jako us�ugodawcy. Dostawcy oprogramowania jako us�ugi to niezale�ni dostawcy, dostawcy w chmurze lub dostawcy CDN. Wszystkie zazwyczaj oferuj� jak�� form� DNS. Zdecydowanie skorzystaj z us�ug zewn�trznego dostawcy DNS. Ryzyko przestoju jest zbyt wysokie, aby samemu obs�ugiwa� DNS. DNS, cho� niezwykle elastyczny i innowacyjny system, ma wady:

• Niemo�no�� za�adowania r�wnowagi przy u�yciu jakiejkolwiek prawdziwej inteligencji. Jeste� ograniczony do rundy lub podstawowych algorytm�w tego rodzaju.
• Nie mo�na ustali�, czy adresy IP, kt�re zapisa�e� w rejestrze, faktycznie dzia�aj�. Ta determinacja pozostaje w gestii klient�w, kt�rzy wcale tego nie robi� lub robi� to �le.
• Po�rednicy mi�dzy autorytatywnym serwerem DNS a klientem mog� zmienia� kolejno�� adres�w IP, pr�buj�c za�adowa� r�wnowag�. Jest to bardzo z�e dla aktywnych / pasywnych.
• Po�rednicy obejmuj�cy samego klienta mog� zignorowa� TTL okre�lone przez u�ytkownika w celu ograniczenia liczby zapyta� DNS.
Globalne r�wnowa�enie obci��enia serwera (GSLB), kt�re om�wimy wkr�tce, ma na celu usuni�cie wielu brak�w w zwyk�ym systemie DNS.

Przypisywanie klient�w do jednego centrum danych

Do niedawna wi�kszo�� du�ych platform e-commerce by�a obs�ugiwana tylko z jednego centrum danych, z jednym wirtualnym adresem IP (VIP) dost�pnym dla tego jednego centrum danych. Za pomoc� jednego centrum danych mo�esz po prostu u�y� zwyk�ego DNS, aby powi�za� przyjazn� nazw� domeny (website.com) z adresem IP (161.170.248.20). Mo�esz ustawi� TTL na kilka godzin i pod warunkiem, �e masz wiarygodnego dostawc� DNS, nigdy wi�cej nie my�l o DNS.

Aktywne / pasywne przydzielanie centrum danych

Dzi�ki dodaniu pasywnych centr�w danych w konfiguracji aktywnej / pasywnej musisz obni�y� TTL, aby zmiany mog�y zosta� wprowadzone szybko. Je�li masz 12-godzinny czas wyga�ni�cia, wszelkie zmiany DNS mog� potrwa� do 12 godzin. Kilka minut TTL dzia�a dobrze. Co� kr�tszego ni� to, a zmusisz swoich klient�w do niepotrzebnego sprawdzania serwer�w DNS, co negatywnie wp�ywa na wydajno��. Po zachowaniu prawid�owego TTL b�dziesz musia� by� w stanie szybko opublikowa� aktualizacje swojego rekordu DNS na wypadek, gdyby� musia� prze��czy� si� z podstawowego centrum danych do rezerwowego centrum danych.

Jak wspomniano wcze�niej, DNS obs�uguje wiele rekord�w A, co oznacza, �e witryna.com.com mo�e rozwi�za� dwa lub wi�cej unikalnych adres�w IP, przy czym ka�dy adres IP reprezentuje centrum danych. Wyniki s� uporz�dkowane, tak aby pierwszy zwr�cony adres IP mia� by� pierwszym adresem IP, z kt�rym ��czy si� klient. Trzy problemy z tym podej�ciem dla aktywnej / pasywnej s� nast�puj�ce:

• Nie mo�esz zagwarantowa�, �e po�rednik nie zmieni kolejno�ci adres�w IP.
• Nie mo�esz zagwarantowa�, �e klienci zawsze b�d� ��czy� si� z pierwszym wymienionym adresem IP.
• Mog� wyst�pi� kr�tkie przerwy w dostawie, poniewa� w po��czeniach internetowych wyst�puj� podobne problemy.
Nie chcesz, aby klienci ��czyli si� z Twoim pasywnym centrum danych, dop�ki nie prze��czysz prze��cznika, publikuj�c zaktualizowany rekord A. Dowolny adres IP w rekordzie A mo�e by� pod��czony w dowolnym momencie przez dowolnego klienta. Nie ma gwarancji. Zamiast tego najlepiej jest u�y� w�a�ciwego GSLB z dog��bn� kontrol� kondycji lub u�y� standardowego DNS, ale tylko jeden adres IP jest wymieniony w rekordzie A. GSLB zostanie om�wiony wkr�tce.

Aktywne / aktywne przypisanie centrum danych

Gdy dwa lub wi�cej centr�w danych faktycznie odbiera ruch od klient�w, ka�demu klientowi nale�y przedstawi� dok�adnie uporz�dkowan� list� adres�w IP, z kt�rymi klient powinien si� po��czy�. DNS obs�uguje wiele rekord�w A, ale z tej funkcji nale�y korzysta� tylko wtedy, gdy klient mo�e po��czy� si� z dowolnym zwr�conym adresem IP. Klienci powinni ��czy� si� w kolejno�ci zwracania adres�w IP, ale jest ca�kiem mo�liwe, �e po�rednik zmieni� kolejno�� adres�w IP lub �e klient zignoruje kolejno�� zwracanych adres�w. Warto�ci TTL wydaj� si� by� r�wnie� do�� niskie, poniewa� chcesz mie� mo�liwo�� szybkiego wprowadzania zmian w przypadku awarii. Ponownie, klienci mog� ��czy� si� z dowolnym wymienionym adresem IP, wi�c upewnij si�, �e zwracasz adresy IP, kt�re mog� aktywnie obs�ugiwa� ruch.

Globalne r�wnowa�enie obci��enia serwera

Element startowy do r�wnowa�enia obci��enia serwera globalnego .GSLB to bardzo inteligentny DNS, kt�ry mo�e wybra� optymalne centrum danych dla danego klienta. Czynniki, kt�re wykorzystuje, mog� obejmowa�:

• Dost�pno�� centrum danych (zar�wno to, czy IP reaguje na pingi, jak i bardziej szczeg�owa kontrola stanu)
• Lokalizacja geograficzna klienta
• Op�nienie w obie strony mi�dzy klientem a ka�dym centrum danych
• Pojemno�� ka�dego centrum danych w czasie rzeczywistym
• Wiele algorytm�w r�wnowa�enia obci��enia

Najistotniejsza r�nica w stosunku do standardowego DNS polega na tym, �e pozwala on na przeprowadzanie znacznie bardziej zaawansowanych kontroli stanu centrum danych, z mo�liwo�ci� automatycznego upuszczenia centrum danych w czasie rzeczywistym, je�li stanie si� niezdrowe. W przypadku standardowego systemu DNS jedyne sprawdzanie kondycji jest wykonywane po stronie klienta. Je�li klient nie mo�e po��czy� si� z adresem IP zwr�conym w rekordzie A, przechodzi do nast�pnego na li�cie. Ka�dy klient wykonuje to sprawdzenie nieco inaczej lub czasem wcale. Co gorsza, istnieje wiele sposob�w, w jakie adres IP mo�e odpowiedzie� na polecenie ping, ale nie jest zdrowy. Klienci nie znamy na przyk�ad r�nicy mi�dzy odpowiedziami HTTP 200, 404 i 500. GSLB przejmuje odpowiedzialno�� za kontrol� stanu od klienta i mo�e przeprowadzi� znacznie dok�adniejsze przes�uchanie dotycz�ce kondycji centrum danych. Porozmawiamy o tym w "Sprawdzanie kondycji globalnego r�wnowa�enia obci��enia serwera", ale zasadniczo powiniene� zastosowa� podej�cie sprawdzaj�ce kondycj� z Cz�ci 5 do ca�ego centrum danych i skonfigurowa� swoj� us�ug� GSLB, aby sondowa� t� stron�, aby przetestowa� kondycj� danych �rodek. Je�li korzystasz z platformy z co najmniej dw�ch centr�w danych, zalet� jest to, �e prze��czanie awaryjne odbywa si� automatycznie, bez �adnych interakcji. R�czne przekazywanie rekord�w DNS zajmuje du�o czasu. Opr�cz sprawdzania kondycji, zdolno�� GSLB do wskazywania lokalizacji klienta mo�e by� niezwykle korzystna. Zastosowania obejmuj�:

• Kierowanie klient�w do najbli�szego centrum danych, kt�re jest w stanie najlepiej obs�u�y� ich ��dania. Poprawia to wydajno�� i zwi�ksza wsp�czynniki konwersji.
• Zmniejszenie prawdopodobie�stwa wyst�pienia problemu z jednoczesnym logowaniem om�wionego wcze�niej w tym rozdziale. Dzi�ki dw�m centrom danych i bez geolokalizacji dwaj klienci korzystaj�cy z tego samego konta maj� 50% szansy na trafienie do tego samego centrum danych. Dzi�ki odpowiedniej geolokalizacji oferowanej przez GSLB znacznie zmniejszasz problem. Ludzie w to samo gospodarstwo domowe, miasto, stan lub region znacznie cz�ciej dziel� loginy, a przy odpowiedniej geolokalizacji znacznie cz�ciej trafiaj� do tego samego centrum danych.
• Mo�esz spersonalizowa� do�wiadczenie dla klient�w. Na przyk�ad, mo�esz chcie� pokaza� swoim klientom w Wisconsin r�kawiczki zimowe i kostiumy k�pielowe dla klient�w z Florydy w styczniu.
• Mo�e by� konieczne ograniczenie niekt�rych funkcji w zale�no�ci od fizycznej lokalizacji klienta. Na przyk�ad promocja mo�e by� legalna w jednym stanie, aw innym nielegalna. Zamiast pokazywa� klientom konkurs, w kt�rym nie mog� wzi�� udzia�u, najlepiej po prostu go usun�� dla tych, w kt�rych jest to nielegalne.
• Mo�esz powoli wdra�a� funkcje. Za��my, �e przechodzisz na now� platform�. Mo�esz to zrobi� dla ka�dego miasta podczas pilotowania. W ten spos�b firmy oferuj�ce produkty konsumenckie testuj� nowe produkty.

GSLB mo�e by� oferowany jako DNS hostowany samodzielnie lub jako us�uga. W przypadku hostowania na miejscu cz�sto odbywa si� to za pomoc� urz�dze� sprz�towych. Urz�dze� tych prawdopodobnie nie mo�na u�ywa� w chmurze. Podobnie jak DNS, najlepiej jest wybra� dostawc� oprogramowania GSLB jako us�ugi ni� pr�bowa� robi� to samodzielnie. Sieci CDN, kt�re oferuj� GSLB, s� najlepsze, poniewa� mog� odpowiada� na ��dania klient�w z brzegu, a nie ze scentralizowanego serwera. Prowadzi to do poprawy wydajno�ci, poniewa� ka�dy klient b�dzie sk�ada� zapytanie do autorytatywnego serwera DNS na pocz�tku sesji. W przypadku tradycyjnego systemu DNS konieczne jest znacznie wi�ksze buforowanie, poniewa� dla ka�dego klienta mo�na u�y� tego samego rekordu. GSLB zwraca unikalny rekord dla ka�dego klienta. Sieci CDN, kt�re s�u�� jako zwrotny serwer proxy, maj� r�wnie� znaczn� przewag� nad standardowym systemem DNS dla pe�nego podej�cia aktywnego / aktywnego, dzi�ki czemu niewielka cz�� klient�w jest si�� przenoszona z jednego centrum danych do drugiego. Zamiast pr�bowa� zmusi� Ci� do zmiany adres�w IP dla danej nazwy domeny, mo�esz zamiast tego poinstruowa� swoj� CDN, aby proxy przes�a�a ��dania na brzeg. Mimo �e klient mo�e nadal mapowa� witryn� internetow�.com z powrotem na niew�a�ciwy adres IP, Tw�j CDN po prostu zignoruje go i przekieruje ��danie do w�a�ciwego centrum danych. CDN mo�na poinformowa� o tej zmianie za pomoc� nag��wka odpowiedzi HTTP, pliku cookie lub podobnego. Tradycyjne rozwi�zania GSLB oparte na urz�dzeniach oferuj� to przez proxy. ��danie mo�e trafi� do niew�a�ciwego centrum danych, ale urz�dzenia mog� wsp�pracowa� w celu przes�ania ��dania do w�a�ciwego centrum danych. Minusem jest to, �e zawsze b�dziesz mie� proxy za po�rednictwem po�rednicz�cego centrum danych, by� mo�e podr�uj�c tysi�ce kilometr�w na uboczu przy ka�dym ��daniu. Sprawdzanie kondycji globalnego r�wnowa�enia obci��enia serwera Podobnie jak omawiali�my kontrole kondycji poszczeg�lnych jednostek wdra�ania w centrum danych, musisz sprawdzi� kondycj� ca�ego centrum danych w spos�b odpowiedni dla Twojej platformy. W przypadku pojedynczego serwera aplikacji reprezentatywne testy obejmuj�:

• Zapytanie o siatk� pami�ci podr�cznej dla produktu
• Dodanie produktu do koszyka
• Zapisanie nowego zam�wienia w bazie danych, a nast�pnie usuni�cie go
• Zapytanie magistrali serwisowej o dost�pno�� zapas�w
• Wykonanie zapytania wzgl�dem wyszukiwarki

Je�li wszystkie testy powr�c� OK, odpowiedzi� b�dzie ci�g PASS. W przeciwnym razie odpowied� wr�ci FAIL. Mo�na skonfigurowa� modu�y r�wnowa��ce obci��enie w celu odpytywania o kod odpowiedzi HTTP 200 i PASS w odpowiedzi. Zwyk�y ping ping nie jest wystarczaj�cy. Ta sama koncepcja obowi�zuje w przypadku oceny kondycji ca�ego centrum danych. Odpowiadaj�c na prosty ping ping nic nie m�wi o jego kondycji. Najlepiej jest zbudowa� ma��, niezale�n� aplikacj� internetow�, kt�ra b�dzie sondowa� dynamiczne strony kontroli kondycji ka�dego stosu i innych punkt�w monitorowania. Je�li powiedzmy, 75% test�w powr�ci jako PASS, to zg�o� PASS. Popro� o zapytanie GSLB dotycz�ce tej strony i spraw, aby by�y wysoce dost�pne. Podczas gdy w przesz�o�ci trzeba by�o sprawdza� pojemno�� ka�dego centrum danych, nie trzeba ju� tego robi�, poniewa� mo�na skalowa� ka�de centrum danych zgodnie z wymaganiami. Innymi s�owy, pojemno�� ka�dego centrum danych b�dzie podyktowana ilo�ci� ruchu, jaki daje GSLB, w przeciwie�stwie do tego, ile pojemno�ci centrum danych zg�asza z powrotem do GSLB.

Podej�cia do dzia�ania z wielu centr�w danych

Pragmatyzm powinien by� twoj� si�� przewodni�, gdy dzia�asz z dw�ch lub wi�cej centr�w danych, a bardziej og�lnie, kiedy wdra�asz przetwarzanie w chmurze. Wa�ne jest, aby przeprowadzi� badania, a nast�pnie zrobi� to, co dzia�a dobrze dla Ciebie. Podej�cia przedstawione tutaj s� po prostu punktami pocz�tkowymi, kt�re nale�y dostosowa� i rozszerzy�, aby dok�adnie odpowiada�y Twoim potrzebom. Og�lne podej�cia opisano w poni�szych sekcjach.

Aktywny/pasywny

Podej�cie to jest do�� tradycyjne, w kt�rym jednocze�nie dzia�a tylko jedna warstwa aplikacji i warstwa bazy danych w centrum danych. Jedno centrum danych jest aktywne, a drugie jest pasywne. Replikacja jest cz�sto ograniczona tylko do bazy danych i jest jednokierunkowa. Awaria centrum danych raczej nie spowoduje utraty danych (tzw. Cel punktu przywracania), ale bardzo prawdopodobne jest, �e spowoduje to d�ugie przestoje (zwane celem przywracania). Oczekiwany jest d�ugi czas przestoju, poniewa� przej�cie do pasywnego centrum danych poci�ga za sob�:

• Sprz�t do udost�pniania
• Instalowanie oprogramowania na nowo wyposa�onym sprz�cie
• Inicjalizacja bazy danych
• Odwr�cenie synchronizacji bazy danych, dzi�ki czemu masz kopi� zapasow� nowo aktywnej bazy danych
• Skierowanie globalnego modu�u r�wnowa�enia obci��enia serwera na nowe centrum danych

Wszystko to wymaga czasu, a system jest wy��czony podczas wykonywania tych czynno�ci. Je�li nie zainwestujesz du�o czasu w automatyzacj� tego, prawdopodobnie b�dzie to musia�o zosta� wykonane r�cznie. W tradycyjnym modelu hostingu pasywne centrum danych by�oby w pe�ni wyposa�one w dedykowany sprz�t. Zmniejsza to przestoje, ale kosztem podwojenia sprz�tu wymaga�by, aby siedzie� bezczynnie przez wi�ksz� cz�� roku. Jest to ogromnie marnotrawstwo, ale marnotrawstwo mo�e zosta� zr�wnowa�one przez skr�cenie d�ugo�ci przestoj�w. Aktywny / pasywny jest naj�atwiejszy w u�yciu, je�li chcesz wprowadzi� jak najmniej zmian w swoich aplikacjach i architekturach wdra�ania. Poniewa� replikacja odbywa si� tylko w bazie danych i istniej� do tego narz�dzia, nie musisz zmienia� �adnego innego oprogramowania, je�li nie chcesz. Oszcz�dza to du�o czasu i pieni�dzy, zw�aszcza je�li pracujesz z oprogramowaniem, kt�re trudno zmieni�. Mo�esz nawet nie by� w stanie zmieni� niekt�rych program�w, co czyni to jedyne realne podej�cie.

Aktywne / aktywne warstwy aplikacji, aktywne / pasywne warstwy bazy danych

Dzi�ki takiemu podej�ciu masz dwa lub wi�cej centr�w danych w pe�ni zbudowanych i dzia�aj�cych niezale�nie, przy czym tylko baza danych jest aktywna / pasywna. To podej�cie jest �wietnym po�rednikiem, kt�ry pozwala unikn�� wi�kszo�ci problem�w zwi�zanych z pe�nym multimasterem (gdzie warstwy aplikacji i bazy danych s� w pe�ni aktywne), ale wi��e si� z tym, �e centra danych nie mog� by� zbyt daleko od siebie. Poniewa� po�owa poziom�w aplikacji b�dzie zapisywa� do bazy danych znajduj�cej si� w innym centrum danych, powodzenie tego podej�cia zale�y w du�ej mierze od tego, jak cz�sto piszesz do bazy danych, czy te zapisy s� synchroniczne i ile op�nie� wyst�puje mi�dzy twoimi warstwy aplikacji i baza danych. Je�li piszesz do bazy danych pi�� razy dla ka�dego wy�wietlenia strony i masz 20 milisekund op�nie�, spogl�dasz na 100 milisekund z czystym op�nieniem, niezale�nie od tego, ile czasu zajmie wygenerowanie odpowiedzi przez baz� danych. Kluczem do sukcesu jest wybieranie centr�w danych, kt�re s� wystarczaj�co blisko siebie, aby zminimalizowa� wp�yw op�nie�, ale wystarczaj�co daleko od siebie, aby nie podlega�y tym samym kl�skom �ywio�owym, b��dom ludzkim i awariom w g�r� �a�cucha dostaw. Na przyk�ad op�nienie w obie strony mi�dzy Chicago a Detroit wynosi tylko 8 milisekund. Mo�esz zrobi� 12 okr��e� mi�dzy nimi i doda� tylko 96 milisekund op�nienia. Wybieraj�c tam centra danych, uzyskuje si� dobr� fizyczn� separacj�, a jednocze�nie powoduje bardzo ma�e op�nienia. Je�li masz problem z centrum danych lub oprogramowaniem wdro�onym w tym centrum danych, mo�esz po prostu przesta� kierowa� ruch do niego i prze��cza� awaryjnie do innego centrum danych. W ci�gu kilku sekund mo�esz prze��czy� swoich klient�w do centrum danych, kt�re przetrwa�o, albo za pomoc� zautomatyzowanego podej�cia opartego na sprawdzaniu kondycji, o kt�rym m�wili�my wcze�niej w tym rozdziale, lub r�cznie wprowadzaj�c zmiany. Prawdziw� zalet� jest to, �e nie musisz zbyt cz�sto zmienia� swoich aplikacji. Zmiany dotycz� g��wnie poziomu bazy danych. By� mo�e trzeba zoptymalizowa� kod, aby zmniejszy� liczb� po��cze� z baz� danych, ale to wszystko.

Aktywne / aktywne warstwy aplikacji, g��wnie aktywne / aktywne bazy danych

Jak om�wiono wcze�niej w tej cz�ci, g��wnym problemem zwi�zanym z multimasterem jest wielokrotne logowanie do tego samego konta. Kiedy tak si� dzieje, mo�esz napotka� konflikty danych, poniewa� te same dane s� aktualizowane z dw�ch r�nych baz danych. Dwa wspomniane podej�cia nie maj� tego problemu, poniewa� istnieje tylko jedna baza danych na �ywo. Mimo �e mo�e istnie� wiele fizycznych centr�w danych, wszystkie zapisy maj� miejsce w tej samej bazie danych zgodnej z ACID. To podej�cie jest pierwszym, w kt�rym ka�de centrum danych ma w�asn� aktywn� baz� danych. Ka�de centrum danych w tym podej�ciu, pokazane na rysunku 10-10, ma w�asn� aplikacj� i stos bazy danych. Domy�lnie klienci pisz� w lokalnej bazie danych w centrum danych, do kt�rego zostali przypisani. Ale gdy aplikacja wykryje, �e klient ma ju� r�wnoczesne logowanie w innym centrum danych, klient zapisze cross-WAN w centrum danych z aktywn� sesj�. Dzi�ki temu masz pe�n� aktywno�� / aktywno�� z wyj�tkiem bardzo ma�ego odsetka klient�w z wieloma jednoczesnymi logowaniami. Aby wdro�y� to podej�cie, musisz zmieni� proces logowania, aby oznaczy� ka�de konto centrum danych, z kt�rego konto jest zalogowane, i czasem ostatniego logowania. Wszystkie dane logowania musz� nast�pnie sprawdzi� te dwie warto�ci, aby sprawdzi�, czy kto� inny jest ju� zalogowany przy u�yciu tych po�wiadcze� w innym centrum danych. Je�li podczas procesu logowania oka�e si�, �e kto� inny jest ju� zalogowany na to konto z innego centrum danych, wskazujesz tego klienta w bazie danych w centrum danych, w kt�rym ju� jest aktywne logowanie. Wszystkie odczyty mog� nadal odbywa� si� z lokalnej bazy danych. Poniewa� jest to pierwsze podej�cie, kt�re wykorzystuje dwie lub wi�cej aktywnych baz danych, wszystkie klucze podstawowe (lub inne trwa�e identyfikatory) musz� by� poprzedzone unikalnym identyfikatorem. Na przyk�ad w centrum danych w Nowym Jorku mo�na wygenerowa� wszystkie klucze podstawowe z przedrostkiem ny. Dzi�ki temu klucze podstawowe pozostaj� unikalne we wszystkich centrach danych. Czynnikiem komplikuj�cym jest spos�b przypisywania baz danych do indywidualnych klient�w. Kluczem jest skonfigurowanie serwera aplikacji do posiadania wielu pul po��cze�, z kt�rych ka�da reprezentuje unikaln� baz� danych. Je�li masz �r�d�o danych dla swoich zam�wie�, zdefiniuj �r�d�o danych o identyfikatorze Order_DS_Local, a drugie o identyfikatorze Order_DS_Remote. Nast�pnie w warstwie aplikacji zmieniasz rozdzielczo�� r�d�a danych ze zmiennej o zasi�gu globalnym na zmienn� o zasi�gu sesji. Pseudokod wygl�da�by mniej wi�cej tak:

public boolean handleLogin(HttpServletRequest request,
HttpServletResponse response)
{
if (!super.handleLogin(request, response)) // loads Account into session
{
return false;
}
Account account = (Account)request.getSession()
.getAttribute("CurrentAccount"); // returns "Chicago"
String thisDataCenterName = Constants.CURRENT_DATA_CENTER_NAME;
// if account.getCurrentDataCenter() = "Chicago"
if (account.getCurrentDataCenter().equals(thisDataCenter))
{
request.getSession().setAttribute("Order_Data_Source",
Constants.LOCAL_ORDER_DATA_SOURCE);
// sets to "Order_DS_Local"
}
else // if account.getCurrentDataCenter() = "Detroit"
{
request.getSession().setAttribute("Order_Data_Source",
Constants.REMOTE_ORDER_DATA_SOURCE);
// sets to "Order_DS_Remote"
}
return true;
}

Twoja implementacja b�dzie zasadniczo inna, ale logika powinna by� do�� podobna

Pe�na aktywna / aktywna

To podej�cie, podobnie jak poprzednie podej�cie, ma centra danych, kt�re dzia�aj� niezale�nie, a ka�de centrum danych jest wyposa�one we w�asne warstwy aplikacji i baz danych. To podej�cie zamiast pisa� cross-WAN dla garstki klient�w z aktywnym logowaniem w innym centrum danych, wymaga takiego przeniesienia klient�w do centrum danych z aktywnym logowaniem. Dzi�ki temu wszyscy klienci mog� by� zawsze obs�ugiwani z lokalnej bazy danych, bez komunikacji mi�dzy sieciami WAN. Wdro�enie tego podej�cia zaczyna si� tak samo jak poprzednie. Musisz oznaczy� ka�de konto centrum danych, z kt�rego zalogowano si�, i czasem ostatniego logowania. Nast�pnie musisz napisa� troch� kodu, aby ustali�, czy klient jest zalogowany w innym miejscu. To wszystko to samo co poprzednie podej�cie. R�nica polega na tym, �e klient znajduj�cy si� w "niew�a�ciwym" centrum danych jest si�� przenoszony do centrum danych, kt�re ma aktywn� sesj� dla konta. Po przekierowaniu obs�ugiwane s� wszystkie ��dania HTTP i sesje HTTP nale��ce do tego konta z tego samego centrum danych, warstwy aplikacji i bazy danych. Anonimowi klienci nigdy nie musz� by� przekierowywani, poniewa� nie maj� domowego centrum danych Problem z tym podej�ciem polega na tym, �e bardzo trudno jest usun�� klienta z centrum danych. Adresy IP (z centrami danych reprezentowanymi przez jedn� nazw� domeny i ka�dy adres IP odwzorowany z powrotem na pojedyncze centrum danych) s� buforowane przez r�nych po�rednik�w. Na przyk�ad wiele przegl�darek internetowych buforuje kombinacje adresu IP / nazwy domeny d�u�ej ni� wymaga tego rekord DNS (czas na �ycie). Nie mo�esz po prostu zmusi� klienta do rzetelnego ponownego rozpoznania nazwy domeny i spraw, aby ta zmiana zacz�a obowi�zywa� natychmiast. Nied�ugo om�wimy to bardziej szczeg�owo, ale na wysokim poziomie musisz przechwyci� ��dania HTTP na kraw�dzi przy u�yciu sieci dostarczania tre�ci i mie� tam proxy. Mog� istnie� pewne sposoby zmuszenia klient�w do ponownego rozpoznania adresu IP, ale by�oby to jeszcze trudniejsze ni� podej�cie CDN / proxy. Przy pe�nej aktywacji / aktywacji mo�e to nawet nie by� mo�liwe, ale takie podej�cie oferuje znaczne korzy�ci w por�wnaniu z poprzednim. Ponownie om�wimy to bardziej szczeg�owo wkr�tce.

Bezstanowe frontendy, stanowe backendy

Sprowadza si� to do oddzielenia frontonu od backendu jako cz�ci architektury omnichannel. W tym scenariuszu backend jest u�ywany tylko do czynno�ci transakcyjnych, takich jak z�o�enie zam�wienia lub ustalenie, kt�re produkty przekaza� klientowi. Korzystasz z niego za pomoc� podstawowych ��da� HTTP, takich jak to: http://backend.website.com/CommitOrder?orderId=12345 Twoje odpowiedzi to JSON, XML lub inny og�lny format, kt�ry frontend mo�e przeanalizowa� i wy�wietli� klientowi:

{
"success": true,
"message": "Your order has been successfully placed.",
…
}

Twoje zaplecze jest wdra�ane w kontrolowanych centrach danych, wykorzystuj�c po��dany sprz�t i oprogramowanie. Wymaga to statycznego administrowania sprz�tem i skalowania dla szczytu, ale r�nica polega na tym, �e backend obs�uguje teraz znacznie mniejszy ruch, poniewa� frontend obs�uguje du�� jego cz��. Zapoznaj si� ze �cie�k� ruchu: wi�kszo�� ruchu jest przeznaczona dla anonimowo przegl�danych stron, kt�re nie wymagaj� interakcji z zapleczem. Interfejs u�ytkownika jest wdra�any w chmurze, gdzie mo�na go elastycznie skalowa�. Kluczow� zalet� tego podej�cia jest to, �e mo�esz wrzuca� wiele interfejs�w na platform� i utrzymywa� sp�jne wra�enia klient�w we wszystkich kana�ach i urz�dzeniach. Frontendy staj� si� g�upimi warstwami prezentacji. S� mniej wi�cej jednorazowe. Prawie wszystkie natywne aplikacje na iPhone'a i Androida dzia�aj� obecnie w ten spos�b, a trend ro�nie, poniewa� coraz wi�cej kana��w i typ�w urz�dze� musi by� nadal obs�ugiwanych. Ta architektura jest znacz�cym odej�ciem od przesz�o�ci, w kt�rej nak�adki by�y spl�tane z backendami, do tego stopnia, �e nie mo�na by�o ich rozdzieli�. Wiele platform e-commerce wci�� dostarcza backend (np. Klasy, biblioteki) w tym samym pakiecie (np. Plik EAR) co frontend (np. JSP, ASP, HTML, CSS lub JavaScript). Renderowanie HTML zajmuje najwi�cej cykli procesora. Je�li pominiesz interfejs u�ytkownika, mo�esz uzyska� znacznie wi�ksz� przepustowo�� ni� w innym przypadku, gdyby by�y one po��czone. Inn� zalet� tego podej�cia jest to, �e mo�esz teraz wdra�a� backendy aktywne / pasywne w dw�ch centrach danych. Tak d�ugo, jak wszystkie interfejsy wskazuj� z powrotem na ten sam backend, nie napotkasz �adnego z problem�w wymienionych w tej cz�ci, poniewa� ka�da aktualizacja danych danego klienta ostatecznie ko�czy si� w tej samej bazie danych.

e-Commerce w ChmurzeHandel

Wdra�anie w wielu centrach danych (Multimaster)