Skala sieci Amazon Web Services to 69 stref na całym świecie w 22 regionach: USA, Europa, Azja, Afryka i Australia. W każdej strefie znajduje się maksymalnie 8 centrów danych – Centrów Przetwarzania Danych. Każde centrum danych ma tysiące lub setki tysięcy serwerów. Sieć jest zaprojektowana w taki sposób, że uwzględniane są wszystkie mało prawdopodobne scenariusze przestojów. Przykładowo wszystkie regiony są od siebie odizolowane, a strefy dostępności rozdzielane są na kilkukilometrowe odległości. Nawet jeśli przetniesz kabel, system przełączy się na kanały zapasowe, a utrata informacji wyniesie kilka pakietów danych. Wasilij Pantyukhin opowie o innych zasadach, na jakich zbudowana jest sieć i jej strukturze.
Wasilij Pantiukhin zaczynał jako administrator Uniksa w firmach .ru, przez 6 lat pracował na dużym sprzęcie Sun Microsystem, a przez 11 lat w firmie EMC głosił świat skoncentrowany na danych. W naturalny sposób przekształciła się w chmury prywatne, a następnie przeniosła się do chmur publicznych. Teraz jako architekt Amazon Web Services zapewnia doradztwo techniczne, które pomaga żyć i rozwijać się w chmurze AWS.
W poprzedniej części trylogii AWS Wasilij zagłębiał się w projektowanie serwerów fizycznych i skalowanie baz danych. Karty Nitro, niestandardowy hypervisor oparty na KVM, baza danych Amazon Aurora – o tym wszystkim w materiale”" Przeczytaj kontekst lub obejrzyj przemówienia.
W tej części skupimy się na skalowaniu sieci, jednym z najbardziej złożonych systemów w AWS. Ewolucja od sieci płaskiej do Virtual Private Cloud i jej konstrukcja, usługi wewnętrzne Blackfoot i HyperPlane, problem hałaśliwego sąsiada, a na koniec – skala sieci, szkieletu i kabli fizycznych. O tym wszystkim pod cięciem.
Zastrzeżenie: wszystko poniżej jest osobistą opinią Wasilija i może nie pokrywać się ze stanowiskiem Amazon Web Services.
Skalowanie sieci
Chmura AWS została uruchomiona w 2006 roku. Jego sieć była dość prymitywna – o płaskiej strukturze. Zakres adresów prywatnych był wspólny dla wszystkich dzierżawców chmury. Podczas uruchamiania nowej maszyny wirtualnej przypadkowo otrzymałeś dostępny adres IP z tego zakresu.
Takie podejście było łatwe do wdrożenia, ale zasadniczo ograniczało wykorzystanie chmury. W szczególności dość trudno było opracować rozwiązania hybrydowe, które łączyłyby sieci prywatne w terenie i w AWS. Najczęstszym problemem było nakładanie się zakresów adresów IP.
Wirtualna chmura prywatna
Chmura okazała się poszukiwana. Nadszedł czas, aby pomyśleć o skalowalności i możliwości wykorzystania jej przez dziesiątki milionów najemców. Główną przeszkodą stała się sieć płaska. Dlatego zastanawialiśmy się, jak odizolować użytkowników od siebie na poziomie sieci, aby mogli samodzielnie wybierać zakresy adresów IP.
Jaka jest pierwsza rzecz, która przychodzi na myśl, gdy myślisz o izolacji sieci? Z pewnością VLAN и VRF – wirtualny routing i spedycja.
Niestety, to nie zadziałało. VLAN ID ma tylko 12 bitów, co daje nam tylko 4096 izolowanych segmentów. Nawet największe przełączniki mogą wykorzystać maksymalnie 1-2 tysiące VRF. Łączne wykorzystanie VRF i VLAN daje nam zaledwie kilka milionów podsieci. To zdecydowanie za mało dla dziesiątek milionów najemców, z których każdy musi mieć możliwość korzystania z wielu podsieci.
Po prostu nie stać nas też na zakup wymaganej liczby dużych pudełek np. od Cisco czy Junipera. Powody są dwa: jest szalenie drogi i nie chcemy być zdani na łaskę ich polityki rozwoju i łatania.
Wniosek jest tylko jeden – stwórz własne rozwiązanie.
W 2009 roku ogłosiliśmy VPC - Wirtualna chmura prywatna. Nazwa utknęła w miejscu i obecnie korzysta z niej również wielu dostawców usług w chmurze.
VPC to sieć wirtualna SDN (Sieć zdefiniowana programowo). Zdecydowaliśmy się nie wymyślać specjalnych protokołów na poziomach L2 i L3. Sieć działa w standardzie Ethernet i IP. W przypadku transmisji przez sieć ruch maszyny wirtualnej jest hermetyzowany w naszym własnym opakowaniu protokołu. Wskazuje identyfikator należący do VPC dzierżawcy.
Brzmi prosto. Istnieje jednak kilka poważnych wyzwań technicznych, które należy pokonać. Na przykład, gdzie i jak przechowywać dane dotyczące mapowania wirtualnych adresów MAC/IP, identyfikatora VPC i odpowiedniego fizycznego adresu MAC/IP. W skali AWS jest to ogromna tabela, która powinna działać przy minimalnych opóźnieniach dostępu. Odpowiedzialny za to usługa mapowania, który rozprzestrzenia się cienką warstwą w całej sieci.
W maszynach nowej generacji enkapsulacja realizowana jest za pomocą kart Nitro na poziomie sprzętowym. W starszych przypadkach enkapsulacja i dekapsulacja opierają się na oprogramowaniu.
Zastanówmy się, jak to działa ogólnie. Zacznijmy od poziomu L2. Załóżmy, że mamy maszynę wirtualną o adresie IP 10.0.0.2 na serwerze fizycznym 192.168.0.3. Wysyła dane do maszyny wirtualnej 10.0.0.3, która działa pod adresem 192.168.1.4. Generowane jest żądanie ARP, które jest wysyłane do sieciowej karty Nitro. Dla uproszczenia zakładamy, że obie maszyny wirtualne znajdują się w tym samym „niebieskim” VPC.
Mapa zastępuje adres źródłowy własnym i przekazuje ramkę ARP do usługi mapującej.
Usługa mapowania zwraca informacje niezbędne do transmisji w sieci fizycznej L2.
Karta Nitro w odpowiedzi ARP zastępuje adres MAC w sieci fizycznej adresem w VPC.
Przesyłając dane, opakowujemy logiczne MAC i IP w opakowanie VPC. Wszystko to transmitujemy poprzez sieć fizyczną wykorzystując odpowiednie źródłowe i docelowe karty IP Nitro.
Kontrolę przeprowadza maszyna fizyczna, do której przeznaczona jest paczka. Jest to konieczne, aby zapobiec możliwości fałszowania adresu. Maszyna wysyła specjalne żądanie do usługi mapowania i pyta: „Z maszyny fizycznej 192.168.0.3 otrzymałem pakiet przeznaczony dla 10.0.0.3 w niebieskim VPC. Czy jest on zgodny z prawem?
Usługa mapowania sprawdza swoją tabelę alokacji zasobów i zezwala na przejście pakietu lub go blokuje. We wszystkich nowych przypadkach w karty Nitro wbudowana jest dodatkowa weryfikacja. Nawet teoretycznie nie da się tego ominąć. Dlatego podszywanie się pod zasoby w innym VPC nie będzie działać.
Następnie dane przesyłane są do maszyny wirtualnej, dla której są przeznaczone.
Usługa mapowania działa również jako router logiczny do przesyłania danych pomiędzy maszynami wirtualnymi w różnych podsieciach. Wszystko jest koncepcyjnie proste, nie będę wdawał się w szczegóły.
Okazuje się, że przesyłając każdy pakiet, serwery zwracają się do usługi mapowania. Jak radzić sobie z nieuniknionymi opóźnieniami? Buforowanie, oczywiście.
Piękno polega na tym, że nie musisz buforować całego ogromnego stołu. Serwer fizyczny hostuje maszyny wirtualne ze stosunkowo niewielkiej liczby VPC. Wystarczy buforować informacje o tych VPC. Przesyłanie danych do innych VPC w „domyślnej” konfiguracji w dalszym ciągu nie jest legalne. Jeśli używana jest funkcjonalność taka jak VPC-peering, wówczas do pamięci podręcznej ładowane są dodatkowo informacje o odpowiednich VPC.
Załatwiliśmy transfer danych do VPC.
Blackfoot
Co zrobić w przypadku konieczności przeniesienia ruchu na zewnątrz, np. do Internetu lub poprzez VPN na ziemię? Pomaga nam tutaj Blackfoot - wewnętrzna obsługa AWS. Został opracowany przez nasz zespół z Afryki Południowej. Dlatego nazwa usługi pochodzi od pingwina żyjącego w Republice Południowej Afryki.
Blackfoot dekapsuluje ruch i robi z nim to, co jest potrzebne. Dane są wysyłane do Internetu w niezmienionej postaci.
Podczas korzystania z VPN dane są dekapsulowane i ponownie pakowane w protokole IPsec.
Podczas korzystania z funkcji Direct Connect ruch jest znakowany i wysyłany do odpowiedniej sieci VLAN.
HyperPlane
Jest to usługa wewnętrznej kontroli przepływu. Wiele usług sieciowych wymaga monitorowania Stany przepływu danych. Na przykład podczas korzystania z NAT kontrola przepływu musi zapewniać, że każda para IP:port docelowy ma unikalny port wychodzący. W przypadku balansera NLB - System równoważenia obciążenia sieciowego, przepływ danych powinien być zawsze kierowany do tej samej docelowej maszyny wirtualnej. Grupy zabezpieczeń to stanowa zapora sieciowa. Monitoruje ruch przychodzący i pośrednio otwiera porty dla przepływu pakietów wychodzących.
W chmurze AWS wymagania dotyczące opóźnień transmisji są niezwykle wysokie. Dlatego HyperPlane krytyczny dla wydajności całej sieci.
Hyperplane jest zbudowany na maszynach wirtualnych EC2. Nie ma tu magii, jest tylko przebiegłość. Sztuczka polega na tym, że są to maszyny wirtualne z dużą ilością pamięci RAM. Operacje mają charakter transakcyjny i są wykonywane wyłącznie w pamięci. Pozwala to osiągnąć opóźnienia rzędu kilkudziesięciu mikrosekund. Praca z dyskiem zabiłaby całą produktywność.
Hyperplane to rozproszony system ogromnej liczby takich maszyn EC2. Każda maszyna wirtualna ma przepustowość 5 GB/s. W całej sieci regionalnej zapewnia to niesamowitą przepustowość i umożliwia przetwarzanie miliony połączeń na sekundę.
HyperPlane działa tylko ze strumieniami. Hermetyzacja pakietów VPC jest dla niego całkowicie przezroczysta. Potencjalna luka w zabezpieczeniach tej usługi wewnętrznej w dalszym ciągu uniemożliwiałaby przerwanie izolacji VPC. Poniższe poziomy odpowiadają za bezpieczeństwo.
Hałaśliwy sąsiad
Nadal jest problem hałaśliwy sąsiad - hałaśliwy sąsiad. Załóżmy, że mamy 8 węzłów. Węzły te przetwarzają przepływy wszystkich użytkowników chmury. Wszystko wydaje się być w porządku, a obciążenie powinno być równomiernie rozłożone na wszystkie węzły. Węzły są bardzo wydajne i trudno je przeciążać.
Ale budujemy naszą architekturę w oparciu o nawet nieprawdopodobne scenariusze.
Niskie prawdopodobieństwo nie oznacza, że jest to niemożliwe.
Możemy sobie wyobrazić sytuację, w której jeden lub więcej użytkowników generowałoby zbyt duże obciążenie. Wszystkie węzły HyperPlane są zaangażowane w przetwarzanie tego obciążenia, a inni użytkownicy mogą potencjalnie doświadczyć pewnego rodzaju spadku wydajności. Przełamuje to koncepcję chmury, w której najemcy nie mają możliwości wzajemnego oddziaływania.
Jak rozwiązać problem hałaśliwego sąsiada? Pierwszą rzeczą, która przychodzi na myśl, jest sharding. Nasze 8 węzłów jest logicznie podzielonych na 4 fragmenty po 2 węzły każdy. Teraz hałaśliwy sąsiad będzie przeszkadzał tylko jednej czwartej wszystkich użytkowników, ale będzie im przeszkadzał bardzo.
Zróbmy wszystko inaczej. Każdemu użytkownikowi przydzielimy tylko 3 węzły.
Sztuka polega na losowym przypisywaniu węzłów różnym użytkownikom. Na poniższym obrazku niebieski użytkownik przecina węzły z jednym z dwóch pozostałych użytkowników - zielonym i pomarańczowym.
Przy 8 węzłach i 3 użytkownikach prawdopodobieństwo, że hałaśliwy sąsiad przetnie jednego z użytkowników wynosi 54%. Z takim prawdopodobieństwem niebieski użytkownik będzie miał wpływ na innych najemców. Jednocześnie tylko część jego ładunku. W naszym przykładzie wpływ ten będzie przynajmniej w jakiś sposób zauważalny nie dla wszystkich, ale tylko dla jednej trzeciej wszystkich użytkowników. To już dobry wynik.
Liczba użytkowników, którzy się przetną
Prawdopodobieństwo w procentach
0
18%
1
54%
2
26%
3
2%
Przybliżmy sytuację do rzeczywistości - weźmy 100 węzłów i 5 użytkowników na 5 węzłach. W tym przypadku żaden z węzłów nie przetnie się z prawdopodobieństwem 77%.
Liczba użytkowników, którzy się przetną
Prawdopodobieństwo w procentach
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
W rzeczywistej sytuacji, przy ogromnej liczbie węzłów i użytkowników HyperPlane, potencjalny wpływ hałaśliwego sąsiada na innych użytkowników jest minimalny. Ta metoda nazywa się mieszanie odłamków - tasowanie sharding. Minimalizuje negatywne skutki awarii węzła.
Wiele usług zbudowanych jest w oparciu o HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala sieci
Porozmawiajmy teraz o skali samej sieci. Od października 2019 r. AWS oferuje swoje usługi w 22 regionyi planowanych jest 9 kolejnych.
- Każdy region zawiera kilka Stref Dostępności. Na całym świecie jest ich 69.
- Każda AZ składa się z Centrów Przetwarzania Danych. W sumie jest ich nie więcej niż 8.
- W centrum danych znajduje się ogromna liczba serwerów, niektóre nawet do 300 000.
Teraz uśrednijmy to wszystko, pomnóżmy i uzyskajmy imponującą liczbę, która odzwierciedla Skala chmury Amazona.
Istnieje wiele połączeń optycznych pomiędzy Strefami Dostępności a centrum danych. W jednym z naszych największych regionów ułożono 388 kanałów tylko do komunikacji AZ między sobą i centrami komunikacyjnymi z innymi regionami (Centra Tranzytowe). W sumie daje to szaleństwo 5000 Tbitów.
Backbone AWS jest zbudowany specjalnie i zoptymalizowany pod kątem chmury. Budujemy go na kanałach 100 GB/s. Kontrolujemy je całkowicie, z wyjątkiem regionów w Chinach. Ruch nie jest współdzielony z ładunkami innych firm.
Oczywiście nie jesteśmy jedynym dostawcą chmury posiadającym prywatną sieć szkieletową. Tą drogą podąża coraz więcej dużych firm. Potwierdzają to niezależni badacze m.in .
Z wykresu wynika, że rośnie udział dostawców treści i dostawców usług w chmurze. Z tego powodu udział ruchu internetowego dostawców szkieletowych stale maleje.
Wyjaśnię, dlaczego tak się dzieje. Wcześniej większość usług internetowych była dostępna i można było z nich korzystać bezpośrednio z Internetu. Obecnie coraz więcej serwerów zlokalizowanych jest w chmurze i można do nich dotrzeć za pośrednictwem CDN - Sieć dystrybucji treści. Aby uzyskać dostęp do zasobu, użytkownik udaje się przez Internet tylko do najbliższego punktu CDN PoP - Punkt obecności. Najczęściej jest gdzieś w pobliżu. Następnie opuszcza publiczny Internet i leci prywatnym szkieletem np. przez Atlantyk i trafia bezpośrednio do zasobu.
Zastanawiam się, jak zmieni się Internet za 10 lat, jeśli ten trend się utrzyma?
Kanały fizyczne
Naukowcy nie wymyślili jeszcze, jak zwiększyć prędkość światła we Wszechświecie, ale poczynili ogromny postęp w metodach przesyłania go przez światłowód. Obecnie używamy kabli światłowodowych 6912. Pomaga to znacząco zoptymalizować koszt ich montażu.
W niektórych regionach musimy używać specjalnych kabli. Na przykład w regionie Sydney używamy kabli ze specjalną powłoką chroniącą przed termitami.
Nikt nie jest odporny na problemy i czasami nasze kanały ulegają uszkodzeniu. Zdjęcie po prawej stronie przedstawia kable optyczne w jednym z amerykańskich regionów, które zostały porwane przez pracowników budowlanych. W wyniku wypadku utracono jedynie 13 pakietów danych, co jest zaskakujące. Po raz kolejny - tylko 13! System dosłownie błyskawicznie przełączył się na kanały zapasowe – waga działa.
Galopowaliśmy przez niektóre usługi i technologie chmurowe Amazona. Mam nadzieję, że macie chociaż pojęcie o skali zadań, jakie stoją przed naszymi inżynierami. Osobiście uważam to za bardzo ekscytujące.
To ostatnia część trylogii Wasilija Pantyukhina o urządzeniu AWS. W części opisują optymalizację serwera i skalowanie bazy danych, a w — funkcje bezserwerowe i Petarda.
Na w listopadzie Wasilij Pantyukhin udostępni nowe szczegóły dotyczące urządzenia Amazon. On o przyczynach awarii i projektowaniu systemów rozproszonych w Amazon. 24 października jest nadal możliwy bilet w dobrej cenie i zapłać później. Czekamy na Ciebie w HighLoad++, przyjdź i porozmawiajmy!
Źródło: www.habr.com