{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Jak AWS 'gotuje' swoje elastyczne us\u0142ugi. Skalowanie sieci","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Skala Amazon Web Services to 69 stref na ca\u0142ym \u015bwiecie w 22 regionach: USA, Europa, Azja, Afryka i Australia. W ka\u017cdej strefie znajduje si\u0119 do 8 centr\u00f3w danych. W ka\u017cdym centrum danych s\u0105 tysi\u0105ce lub setki tysi\u0119cy serwer\u00f3w. Sie\u0107 jest zbudowana tak, aby uwzgl\u0119dni\u0107 wszystkie ma\u0142o prawdopodobne scenariusze awarii. Na przyk\u0142ad, wszystkie regiony s\u0105 odizolowane od siebie, a strefy dost\u0119pno\u015bci s\u0105 oddalone o kilka kilometr\u00f3w. Nawet je\u015bli przerwie si\u0119 kabel, system prze\u0142\u0105czy si\u0119 na zapasowe kana\u0142y, a straty danych b\u0119d\u0105 liczone w jednostkach pakiet\u00f3w. O tym, na jakich jeszcze zasadach zbudowana jest sie\u0107 i jak dzia\u0142a, opowie Wasilij Pantyuchin.<\/p>\n

\"Jak
\n
\nWasilij Pantyuchin<\/b> zaczyna\u0142 jako administrator Unix w firmach .ru, przez 6 lat zajmowa\u0142 si\u0119 du\u017cymi urz\u0105dzeniami Sun Microsystem, a przez 11 lat g\u0142osi\u0142 datacenterowo\u015b\u0107 w EMC. Naturalnie ewoluowa\u0142 w kierunku chmur prywatnych, a nast\u0119pnie przeszed\u0142 do chmur publicznych. Obecnie, jako architekt Amazon Web Services, swoimi technicznymi radami pomaga \u017cy\u0107 i rozwija\u0107 si\u0119 w chmurze AWS.<\/p>\n

W poprzedniej cz\u0119\u015bci trylogii o budowie AWS, Wasilij zag\u0142\u0119bi\u0142 si\u0119 w budow\u0119 fizycznych serwer\u00f3w i skalowanie bazy danych. Karty Nitro, niestandardowy hypervisor oparty na KVM, baza danych Amazon Aurora \u2014 o tym wszystkim w materiale \u201eJak AWS 'gotuje' swoje elastyczne us\u0142ugi. Skalowanie serwer\u00f3w i baz danych<\/a><\/noindex>Przeczytaj, aby zanurzy\u0107 si\u0119 w kontek\u015bcie, lub zobacz nagranie wideo<\/a><\/noindex> wyst\u0105pienia.<\/p>\n

W tej cz\u0119\u015bci mowa b\u0119dzie o skalowaniu sieci \u2014 jednym z najtrudniejszych system\u00f3w w AWS. Ewolucja od p\u0142askiej sieci do Virtual Private Cloud i jej budowa, wewn\u0119trzne us\u0142ugi Blackfoot i HyperPlane, problem ha\u0142a\u015bliwego s\u0105siada, a na ko\u0144cu \u2014 rozmiary sieci, backbone i fizyczne kable. O tym wszystkim w dalszej cz\u0119\u015bci.<\/p>\n

Zastrze\u017cenie: wszystko, co poni\u017cej, to osobista opinia Wasilija i mo\u017ce nie pokrywa\u0107 si\u0119 z pozycj\u0105 Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Skalowanie sieci<\/h2>\n

\nChmur\u0119 AWS uruchomiono w 2006 roku. Jej sie\u0107 by\u0142a do\u015b\u0107 prymitywna \u2014 o p\u0142askiej strukturze. Zakres adres\u00f3w prywatnych by\u0142 wsp\u00f3lny dla wszystkich najemc\u00f3w chmury. Przy uruchomieniu nowej maszyny wirtualnej przypadkowo otrzymywa\u0142e\u015b dost\u0119pny adres IP z tego zakresu.<\/p>\n

\"Jak
\n
\nTakie podej\u015bcie by\u0142o \u0142atwe do wdro\u017cenia, ale zasadniczo ogranicza\u0142o wykorzystanie chmury. W szczeg\u00f3lno\u015bci trudno\u015bci sprawia\u0142o rozwijanie hybrydowych rozwi\u0105za\u0144, kt\u00f3re \u0142\u0105czy\u0142y sieci prywatne na ziemi i w AWS. Najcz\u0119\u015bciej wyst\u0119puj\u0105cym problemem by\u0142 konflikt w zakresie adres\u00f3w IP.<\/p>\n

\"Jak
\n<\/p>\n

Wirtualna Chmura Prywatna<\/h3>\n

\nChmura okaza\u0142a si\u0119 popularna. Nadszed\u0142 czas, aby pomy\u015ble\u0107 o skalowalno\u015bci i mo\u017cliwo\u015bci jej wykorzystania przez dziesi\u0105tki milion\u00f3w tenant\u00f3w. P\u0142aska sie\u0107 sta\u0142a si\u0119 g\u0142\u00f3wn\u0105 przeszkod\u0105. Dlatego zacz\u0119li\u015bmy zastanawia\u0107 si\u0119, jak izolowa\u0107 u\u017cytkownik\u00f3w na poziomie sieci, aby mogli samodzielnie wybiera\u0107 zakresy IP.<\/p>\n

\"Jak
\n
\nCo pierwsze przychodzi na my\u015bl, gdy my\u015blisz o izolacji sieci? Oczywi\u015bcie VLAN<\/b> i VRF \u2014 Wirtualne Routinowanie i Forwarding<\/b>.<\/p>\n

Niestety, to nie zadzia\u0142a\u0142o. VLAN ID to zaledwie 12 bit\u00f3w, co daje nam tylko 4096 izolowanych segment\u00f3w. Nawet w najwi\u0119kszych prze\u0142\u0105cznikach mo\u017cna wykorzysta\u0107 maksymalnie 1-2 tysi\u0105ce VRF. Wsp\u00f3lne u\u017cywanie VRF i VLAN daje nam tylko kilka milion\u00f3w podsieci. To zdecydowanie za ma\u0142o dla dziesi\u0105tek milion\u00f3w tenant\u00f3w, z kt\u00f3rych ka\u017cdy powinien mie\u0107 mo\u017cliwo\u015b\u0107 korzystania z kilku podsieci.<\/p>\n

Dodatkowo po prostu nie mo\u017cemy sobie pozwoli\u0107 na zakup wymaganego poziomu du\u017cych urz\u0105dze\u0144, na przyk\u0142ad od Cisco lub Juniper. S\u0105 dwie przyczyny: to szalenie drogie, a my nie chcemy by\u0107 zale\u017cni od ich polityki rozwoju i \u0142atania.<\/p>\n

Wniosek jest jeden \u2013 nale\u017cy stworzy\u0107 w\u0142asne rozwi\u0105zanie.<\/p><\/blockquote>\n

\nW 2009 roku og\u0142osili\u015bmy VPC<\/b> \u2014 Wirtualna Chmura Prywatna<\/b>. Nazwa przyj\u0119\u0142a si\u0119 i teraz wielu dostawc\u00f3w chmur r\u00f3wnie\u017c jej u\u017cywa.<\/p>\n

VPC \u2013 to wirtualna sie\u0107 SDN<\/b> (Zdefiniowana Programowo Sie\u0107). Postanowili\u015bmy nie wynajdowa\u0107 specjalnych protoko\u0142\u00f3w na poziomach L2 i L3. Sie\u0107 dzia\u0142a na standardowym Ethernet i IP. Aby przesy\u0142a\u0107 ruch na sieci, ruch maszyn wirtualnych jest inkapsulowany w naszym w\u0142asnym protokole. Zawiera on ID, kt\u00f3re nale\u017cy do tenantowego VPC.<\/p>\n

\"Jak
\n
\nBrzmi prosto. Jednak trzeba rozwi\u0105za\u0107 kilka powa\u017cnych problem\u00f3w technicznych. Na przyk\u0142ad, gdzie i jak przechowywa\u0107 dane o odwzorowywaniu wirtualnych adres\u00f3w MAC\/IP, ID VPC i odpowiadaj\u0105cych fizycznych adres\u00f3w MAC\/IP. W skali AWS to ogromna tabela, kt\u00f3ra musi dzia\u0142a\u0107 z minimalnymi op\u00f3\u017anieniami przy dost\u0119pie. Za to odpowiedzialny jest us\u0142uga odwzorowywania<\/b>, kt\u00f3ra jest rozproszona cienk\u0105 warstw\u0105 po ca\u0142ej sieci.<\/p>\n

W nowych generacjach urz\u0105dze\u0144 enkapsulacja jest realizowana przez karty Nitro na poziomie sprz\u0119towym. W starszych instancjach enkapsulacja i dekapsulacja odbywa si\u0119 na poziomie programowym.\u00a0<\/p>\n

\"Jak
\n
\nZrozummy, jak to dzia\u0142a w og\u00f3lnych zarysach. Zaczniemy od poziomu L2. Za\u0142\u00f3\u017cmy, \u017ce mamy maszyn\u0119 wirtualn\u0105 z IP 10.0.0.2 na fizycznym serwerze 192.168.0.3. Wysy\u0142a ona dane do maszyny wirtualnej 10.0.0.3, kt\u00f3ra znajduje si\u0119 na 192.168.1.4. Tworzy si\u0119 zapytanie ARP, kt\u00f3re trafia do karty sieciowej Nitro. Dla uproszczenia zak\u0142adamy, \u017ce obie maszyny wirtualne znajduj\u0105 si\u0119 w tej samej \u201eniebieskiej\u201d VPC.<\/p>\n

\"Jak
\n
\nKarta zast\u0119puje adres \u017ar\u00f3d\u0142owy swoim w\u0142asnym i przesy\u0142a ramk\u0119 ARP do us\u0142ugi mapowania.<\/p>\n

\"Jak
\n
\nUs\u0142uga mapowania zwraca informacje potrzebne do przesy\u0142ania przez fizyczn\u0105 sie\u0107 L2.<\/p>\n

\"Jak
\n
\nKarta Nitro w odpowiedzi ARP zast\u0119puje MAC w sieci fizycznej adresem w VPC.<\/p>\n

\"Jak
\n
\nPodczas przesy\u0142ania danych owijamy logiczne MAC i IP w opakowanie VPC. Wszystko to przesy\u0142amy przez sie\u0107 fizyczn\u0105 za pomoc\u0105 odpowiednich kart Nitro IP \u017ar\u00f3d\u0142a i przeznaczenia.<\/p>\n

\"Jak
\n
\nFizyczna maszyna, do kt\u00f3rej przeznaczony jest pakiet, przeprowadza weryfikacj\u0119. Jest to potrzebne, aby zapobiec mo\u017cliwo\u015bci fa\u0142szowania adres\u00f3w. Maszyna wysy\u0142a specjalne zapytanie do us\u0142ugi mapowania i pyta: \u201eZ fizycznej maszyny 192.168.0.3 otrzyma\u0142em pakiet, kt\u00f3ry jest przeznaczony dla 10.0.0.3 w \u00abniebieskiej\u00bb VPC. Czy jest on legitymny?\u201d\u00a0<\/p>\n

\"Jak
\n
\nUs\u0142uga mapowania por\u00f3wnuje to z swoj\u0105 tabel\u0105 rozmieszczenia zasob\u00f3w i zezwala lub zabrania przej\u015bcia pakietu. We wszystkich nowych instancjach dodatkowa weryfikacja jest wbudowana w karty Nitro. Nie da si\u0119 jej obej\u015b\u0107 nawet teoretycznie. Dlatego spoofing na zasoby w innej VPC nie zadzia\u0142a.<\/p>\n

\"Jak
\n
\nNast\u0119pnie dane s\u0105 wysy\u0142ane do maszyny wirtualnej, dla kt\u00f3rej s\u0105 przeznaczone.\u00a0<\/p>\n

\"Jak
\n
\nUs\u0142uga mapowania dzia\u0142a r\u00f3wnie\u017c jako logiczny router do przesy\u0142ania danych mi\u0119dzy maszynami wirtualnymi w r\u00f3\u017cnych podsieciach. W koncepcji wszystko jest proste, nie b\u0119d\u0119 tego dok\u0142adnie omawia\u0107.<\/p>\n

\"Jak
\n
\nOkazuje si\u0119, \u017ce podczas przesy\u0142ania ka\u017cdego pakietu serwery zwracaj\u0105 si\u0119 do us\u0142ugi mapowania. Jak radzi\u0107 sobie z nieuchronnymi op\u00f3\u017anieniami? Poprzez cachowanie<\/b>, oczywi\u015bcie.<\/p>\n

Ca\u0142a przyjemno\u015b\u0107 polega na tym, \u017ce nie trzeba buforowa\u0107 ca\u0142ej ogromnej tabeli. Na fizycznym serwerze \u017cyj\u0105 wirtualki z relatywnie niewielkiej liczby VPC. Informacje trzeba buforowa\u0107 tylko o tych VPC. Przesy\u0142 danych do innych VPC w \u201edomy\u015blnej\u201d konfiguracji i tak nie jest legalny. Je\u015bli u\u017cywana jest funkcjonalno\u015b\u0107, taka jak VPC-peering, to do bufora dodatkowo \u0142adowane s\u0105 informacje o odpowiednich VPC.\u00a0<\/p>\n

\"Jak
\n
\nRozwi\u0105za\u0142em problem z przesy\u0142aniem danych do VPC.<\/p>\n

Blackfoot<\/h3>\n

\nJak post\u0119powa\u0107 w przypadkach, gdy ruch trzeba przesy\u0142a\u0107 na zewn\u0105trz, na przyk\u0142ad do Internetu lub za po\u015brednictwem VPN? W tym przypadku pomaga nam Blackfoot<\/b> \u2014 wewn\u0119trzna us\u0142uga AWS. Zosta\u0142a opracowana przez nasz zesp\u00f3\u0142 z RPA. Dlatego us\u0142uga nazwana zosta\u0142a na cze\u015b\u0107 pingwina, kt\u00f3ry \u017cyje w RPA.<\/p>\n

\"Jak
\n
\nBlackfoot dekapsuluje ruch i robi z nim to, co trzeba. Dane do Internetu s\u0105 wysy\u0142ane w oryginalnej formie.<\/p>\n

\"Jak
\n
\nDane s\u0105 dekapsulowane i ponownie opakowywane w IPsec przy u\u017cyciu VPN.<\/p>\n

\"Jak
\n
\nPodczas korzystania z Direct Connect ruch jest tagowany i przesy\u0142any do odpowiedniego VLAN.<\/p>\n

\"Jak
\n<\/p>\n

HyperPlane<\/h3>\n

\nTo wewn\u0119trzna us\u0142uga kontroli przep\u0142ywu. Wiele us\u0142ug sieciowych wymaga kontroli stanu przep\u0142ywu danych<\/b>. Na przyk\u0142ad, korzystaj\u0105c z NAT, kontrola przep\u0142ywu musi gwarantowa\u0107, \u017ce ka\u017cdemu \u201eIP: port docelowy\u201d odpowiada unikalny port wychodz\u0105cy. W przypadku r\u00f3wnowa\u017cenia obci\u0105\u017cenia NLB<\/b> \u2014 Network Load Balancer<\/b>, przep\u0142yw danych zawsze musi kierowa\u0107 do tej samej docelowej wirtualki. Security Groups to zapora sieciowa z zachowaniem stanu. Monitoruje ruch przychodz\u0105cy i niejawnie otwiera porty dla wychodz\u0105cego strumienia pakiet\u00f3w.<\/p>\n

\"Jak
\n
\nW chmurze AWS wymagania dotycz\u0105ce op\u00f3\u017anienia przesy\u0142ania s\u0105 ekstremalnie wysokie. Dlatego HyperPlane<\/b> jest krytyczne dla funkcjonowania ca\u0142ej sieci.<\/p>\n

\"Jak
\n
\nHyperplane oparty jest na maszynach wirtualnych EC2. Nie ma tu \u017cadnej magii, tylko spryt. Spryt polega na tym, \u017ce s\u0105 to wirtualki z du\u017c\u0105 pami\u0119ci\u0105 RAM. Operacje s\u0105 transakcyjne i prowadzone wy\u0142\u0105cznie w pami\u0119ci. Umo\u017cliwia to osi\u0105gni\u0119cie op\u00f3\u017anie\u0144 rz\u0119du dziesi\u0105tek mikrosekund. Praca z dyskiem zabi\u0142aby ca\u0142\u0105 wydajno\u015b\u0107.\u00a0<\/p>\n

Hyperplane to rozproszony system z ogromn\u0105 liczb\u0105 takich maszyn EC2. Ka\u017cda wirtualka ma przepustowo\u015b\u0107 5 GB\/s. W skali ca\u0142ej regionalnej sieci daje to osza\u0142amiaj\u0105c\u0105 przepustowo\u015b\u0107 terabitow\u0105 i pozwala obs\u0142ugiwa\u0107 miliony po\u0142\u0105cze\u0144 na sekund\u0119.<\/b>.<\/p>\n

HyperPlane dzia\u0142a tylko z w\u0105tkami. Enkapsulacja pakiet\u00f3w VPC jest dla niego ca\u0142kowicie przezroczysta. Potencjalna luka w tej wewn\u0119trznej us\u0142ug\u0119 i tak nie pozwoli na naruszenie izolacji VPC. Za bezpiecze\u0144stwo odpowiadaj\u0105 ni\u017csze warstwy.<\/p>\n

Ha\u0142a\u015bliwy s\u0105siad<\/h3>\n

\nJest jeszcze jeden problem ha\u0142a\u015bliwego s\u0105siada<\/b> \u2014 ha\u0142a\u015bliwy s\u0105siad<\/b>. Za\u0142\u00f3\u017cmy, \u017ce mamy 8 w\u0119z\u0142\u00f3w. Te w\u0119z\u0142y obs\u0142uguj\u0105 w\u0105tki wszystkich u\u017cytkownik\u00f3w w chmurze. Wszystko wydaje si\u0119 w porz\u0105dku, a obci\u0105\u017cenie powinno by\u0107 r\u00f3wnomiernie roz\u0142o\u017cone na wszystkie w\u0119z\u0142y. W\u0119z\u0142y s\u0105 bardzo pot\u0119\u017cne i trudno je przeci\u0105\u017cy\u0107.<\/p>\n

Ale budujemy nasz\u0105 architektur\u0119 w oparciu o nawet ma\u0142o prawdopodobne scenariusze.\u00a0<\/p>\n

Niska prawdopodobie\u0144stwo nie oznacza niemo\u017cliwo\u015bci.<\/p><\/blockquote>\n

\nMo\u017cemy sobie wyobrazi\u0107 sytuacj\u0119, w kt\u00f3rej jeden lub kilku u\u017cytkownik\u00f3w generuje zbyt du\u017c\u0105 ilo\u015b\u0107 obci\u0105\u017cenia. W przetwarzaniu tego obci\u0105\u017cenia bior\u0105 udzia\u0142 wszystkie w\u0119z\u0142y HyperPlane, a inni u\u017cytkownicy mog\u0105 potencjalnie odczu\u0107 pewne obni\u017cenie wydajno\u015bci. To niszczy koncepcj\u0119 chmury, w kt\u00f3rej najemcy nie mog\u0105 wp\u0142ywa\u0107 na siebie nawzajem.<\/p>\n

\"Jak
\n
\nJak rozwi\u0105za\u0107 problem ha\u0142a\u015bliwego s\u0105siada? Pierwsza rzecz, kt\u00f3ra przychodzi na my\u015bl \u2013 shardowanie. Nasze 8 w\u0119z\u0142\u00f3w dzielimy logicznie na 4 shardy po 2 w\u0119z\u0142y w ka\u017cdym. Teraz ha\u0142a\u015bliwy s\u0105siad przeszkadza tylko jednej czwartej wszystkich u\u017cytkownik\u00f3w, ale znacznie.<\/p>\n

\"Jak
\n
\nZr\u00f3bmy inaczej. Ka\u017cdemu u\u017cytkownikowi przypiszemy tylko 3 w\u0119z\u0142y.\u00a0<\/p>\n

\"Jak
\n
\nSztuczka polega na losowym przypisywaniu w\u0119z\u0142\u00f3w r\u00f3\u017cnym u\u017cytkownikom. Na poni\u017cszym obrazku niebieski u\u017cytkownik przecina si\u0119 z w\u0119z\u0142ami z jednym z dw\u00f3ch innych u\u017cytkownik\u00f3w \u2013 zielonym i pomara\u0144czowym.<\/p>\n

\"Jak
\n
\nW przypadku 8 w\u0119z\u0142\u00f3w i 3 u\u017cytkownik\u00f3w prawdopodobie\u0144stwo, \u017ce ha\u0142a\u015bliwy s\u0105siad przecina si\u0119 z jednym z u\u017cytkownik\u00f3w, wynosi 54%. To z takim prawdopodobie\u0144stwem niebieski u\u017cytkownik wp\u0142ynie na innych najemc\u00f3w. Przy tym tylko cz\u0119\u015bci\u0105 swojego obci\u0105\u017cenia. W naszym przyk\u0142adzie to wp\u0142yw zauwa\u017c\u0105 tylko niekt\u00f3rzy, a zaledwie jedna trzecia wszystkich u\u017cytkownik\u00f3w. To ju\u017c niez\u0142y wynik.<\/p>\n

Liczba u\u017cytkownik\u00f3w, kt\u00f3rzy si\u0119 przeci\u0119li<\/p>\n

Prawdopodobie\u0144stwo w procentach<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

Przybli\u017cmy sytuacj\u0119 do rzeczywistej \u2014 we\u017amy 100 w\u0119z\u0142\u00f3w i 5 u\u017cytkownik\u00f3w na 5 w\u0119z\u0142ach. W takim przypadku \u017cadna z w\u0119z\u0142\u00f3w nie przecina si\u0119 z prawdopodobie\u0144stwem 77%.\u00a0<\/p>\n

Liczba u\u017cytkownik\u00f3w, kt\u00f3rzy si\u0119 przeci\u0119li<\/p>\n

Prawdopodobie\u0144stwo w procentach<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

W rzeczywistej sytuacji, przy ogromnej liczbie w\u0119z\u0142\u00f3w i u\u017cytkownik\u00f3w HyperPlane, potencjalny wp\u0142yw ha\u0142a\u015bliwego s\u0105siada na innych u\u017cytkownik\u00f3w jest minimalny. Ta metoda nazywa si\u0119 mieszany szarding<\/b> \u2014 shuffle sharding<\/b>. Minimalizuje negatywny wp\u0142yw awarii w\u0119z\u0142\u00f3w.<\/p>\n

Na bazie HyperPlane powsta\u0142o wiele us\u0142ug: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Skala sieci<\/h3>\n

\nTeraz porozmawiajmy o skali samej sieci. W pa\u017adzierniku 2019 AWS oferuje swoje us\u0142ugi w 22 regionach<\/b>, a planowanych jest jeszcze 9.<\/p>\n