Skala 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ę do 8 centrów danych. W każdym centrum danych są tysiące lub setki tysięcy serwerów. Sieć jest zbudowana tak, aby uwzględnić wszystkie mało prawdopodobne scenariusze awarii. Na przykład, wszystkie regiony są odizolowane od siebie, a strefy dostępności są oddalone o kilka kilometrów. Nawet jeśli przerwie się kabel, system przełączy się na zapasowe kanały, a straty danych będą liczone w jednostkach pakietów. O tym, na jakich jeszcze zasadach zbudowana jest sieć i jak działa, opowie Wasilij Pantyuchin.
Wasilij Pantyuchin zaczynał jako administrator Unix w firmach .ru, przez 6 lat zajmował się dużymi urządzeniami Sun Microsystem, a przez 11 lat głosił datacenterowość w EMC. Naturalnie ewoluował w kierunku chmur prywatnych, a następnie przeszedł do chmur publicznych. Obecnie, jako architekt Amazon Web Services, swoimi technicznymi radami pomaga żyć i rozwijać się w chmurze AWS.
W poprzedniej części trylogii o budowie AWS, Wasilij zagłębił się w budowę fizycznych serwerów i skalowanie bazy danych. Karty Nitro, niestandardowy hypervisor oparty na KVM, baza danych Amazon Aurora — o tym wszystkim w materiale „Przeczytaj, aby zanurzyć się w kontekście, lub zobacz wystąpienia.
W tej części mowa będzie o skalowaniu sieci — jednym z najtrudniejszych systemów w AWS. Ewolucja od płaskiej sieci do Virtual Private Cloud i jej budowa, wewnętrzne usługi Blackfoot i HyperPlane, problem hałaśliwego sąsiada, a na końcu — rozmiary sieci, backbone i fizyczne kable. O tym wszystkim w dalszej części.
Zastrzeżenie: wszystko, co poniżej, to osobista opinia Wasilija i może nie pokrywać się z pozycją Amazon Web Services.
Skalowanie sieci
Chmurę AWS uruchomiono w 2006 roku. Jej sieć była dość prymitywna — o płaskiej strukturze. Zakres adresów prywatnych był wspólny dla wszystkich najemców chmury. Przy uruchomieniu nowej maszyny wirtualnej przypadkowo otrzymywał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 trudności sprawiało rozwijanie hybrydowych rozwiązań, które łączyły sieci prywatne na ziemi i w AWS. Najczęściej występującym problemem był konflikt w zakresie adresów IP.
Wirtualna Chmura Prywatna
Chmura okazała się popularna. Nadszedł czas, aby pomyśleć o skalowalności i możliwości jej wykorzystania przez dziesiątki milionów tenantów. Płaska sieć stała się główną przeszkodą. Dlatego zaczęliśmy zastanawiać się, jak izolować użytkowników na poziomie sieci, aby mogli samodzielnie wybierać zakresy IP.
Co pierwsze przychodzi na myśl, gdy myślisz o izolacji sieci? Oczywiście VLAN i VRF — Wirtualne Routinowanie i Forwarding.
Niestety, to nie zadziałało. VLAN ID to zaledwie 12 bitów, co daje nam tylko 4096 izolowanych segmentów. Nawet w największych przełącznikach można wykorzystać maksymalnie 1-2 tysiące VRF. Wspólne używanie VRF i VLAN daje nam tylko kilka milionów podsieci. To zdecydowanie za mało dla dziesiątek milionów tenantów, z których każdy powinien mieć możliwość korzystania z kilku podsieci.
Dodatkowo po prostu nie możemy sobie pozwolić na zakup wymaganego poziomu dużych urządzeń, na przykład od Cisco lub Juniper. Są dwie przyczyny: to szalenie drogie, a my nie chcemy być zależni od ich polityki rozwoju i łatania.
Wniosek jest jeden – należy stworzyć własne rozwiązanie.
W 2009 roku ogłosiliśmy VPC — Wirtualna Chmura Prywatna. Nazwa przyjęła się i teraz wielu dostawców chmur również jej używa.
VPC – to wirtualna sieć SDN (Zdefiniowana Programowo Sieć). Postanowiliśmy nie wynajdować specjalnych protokołów na poziomach L2 i L3. Sieć działa na standardowym Ethernet i IP. Aby przesyłać ruch na sieci, ruch maszyn wirtualnych jest inkapsulowany w naszym własnym protokole. Zawiera on ID, które należy do tenantowego VPC.
Brzmi prosto. Jednak trzeba rozwiązać kilka poważnych problemów technicznych. Na przykład, gdzie i jak przechowywać dane o odwzorowywaniu wirtualnych adresów MAC/IP, ID VPC i odpowiadających fizycznych adresów MAC/IP. W skali AWS to ogromna tabela, która musi działać z minimalnymi opóźnieniami przy dostępie. Za to odpowiedzialny jest usługa odwzorowywania, która jest rozproszona cienką warstwą po całej sieci.
W nowych generacjach urządzeń enkapsulacja jest realizowana przez karty Nitro na poziomie sprzętowym. W starszych instancjach enkapsulacja i dekapsulacja odbywa się na poziomie programowym.
Zrozummy, jak to działa w ogólnych zarysach. Zaczniemy od poziomu L2. Załóżmy, że mamy maszynę wirtualną z IP 10.0.0.2 na fizycznym serwerze 192.168.0.3. Wysyła ona dane do maszyny wirtualnej 10.0.0.3, która znajduje się na 192.168.1.4. Tworzy się zapytanie ARP, które trafia do karty sieciowej Nitro. Dla uproszczenia zakładamy, że obie maszyny wirtualne znajdują się w tej samej „niebieskiej” VPC.
Karta zastępuje adres źródłowy swoim własnym i przesyła ramkę ARP do usługi mapowania.
Usługa mapowania zwraca informacje potrzebne do przesyłania przez fizyczną sieć L2.
Karta Nitro w odpowiedzi ARP zastępuje MAC w sieci fizycznej adresem w VPC.
Podczas przesyłania danych owijamy logiczne MAC i IP w opakowanie VPC. Wszystko to przesyłamy przez sieć fizyczną za pomocą odpowiednich kart Nitro IP źródła i przeznaczenia.
Fizyczna maszyna, do której przeznaczony jest pakiet, przeprowadza weryfikację. Jest to potrzebne, aby zapobiec możliwości fałszowania adresów. Maszyna wysyła specjalne zapytanie do usługi mapowania i pyta: „Z fizycznej maszyny 192.168.0.3 otrzymałem pakiet, który jest przeznaczony dla 10.0.0.3 w «niebieskiej» VPC. Czy jest on legitymny?”
Usługa mapowania porównuje to z swoją tabelą rozmieszczenia zasobów i zezwala lub zabrania przejścia pakietu. We wszystkich nowych instancjach dodatkowa weryfikacja jest wbudowana w karty Nitro. Nie da się jej obejść nawet teoretycznie. Dlatego spoofing na zasoby w innej VPC nie zadziała.
Następnie dane są wysyłane do maszyny wirtualnej, dla której są przeznaczone.
Usługa mapowania działa również jako logiczny router do przesyłania danych między maszynami wirtualnymi w różnych podsieciach. W koncepcji wszystko jest proste, nie będę tego dokładnie omawiać.
Okazuje się, że podczas przesyłania każdego pakietu serwery zwracają się do usługi mapowania. Jak radzić sobie z nieuchronnymi opóźnieniami? Poprzez cachowanie, oczywiście.
Cała przyjemność polega na tym, że nie trzeba buforować całej ogromnej tabeli. Na fizycznym serwerze żyją wirtualki z relatywnie niewielkiej liczby VPC. Informacje trzeba buforować tylko o tych VPC. Przesył danych do innych VPC w „domyślnej” konfiguracji i tak nie jest legalny. Jeśli używana jest funkcjonalność, taka jak VPC-peering, to do bufora dodatkowo ładowane są informacje o odpowiednich VPC.
Rozwiązałem problem z przesyłaniem danych do VPC.
Blackfoot
Jak postępować w przypadkach, gdy ruch trzeba przesyłać na zewnątrz, na przykład do Internetu lub za pośrednictwem VPN? W tym przypadku pomaga nam Blackfoot — wewnętrzna usługa AWS. Została opracowana przez nasz zespół z RPA. Dlatego usługa nazwana została na cześć pingwina, który żyje w RPA.
Blackfoot dekapsuluje ruch i robi z nim to, co trzeba. Dane do Internetu są wysyłane w oryginalnej formie.
Dane są dekapsulowane i ponownie opakowywane w IPsec przy użyciu VPN.
Podczas korzystania z Direct Connect ruch jest tagowany i przesyłany do odpowiedniego VLAN.
HyperPlane
To wewnętrzna usługa kontroli przepływu. Wiele usług sieciowych wymaga kontroli stanu przepływu danych. Na przykład, korzystając z NAT, kontrola przepływu musi gwarantować, że każdemu „IP: port docelowy” odpowiada unikalny port wychodzący. W przypadku równoważenia obciążenia NLB — Network Load Balancer, przepływ danych zawsze musi kierować do tej samej docelowej wirtualki. Security Groups to zapora sieciowa z zachowaniem stanu. Monitoruje ruch przychodzący i niejawnie otwiera porty dla wychodzącego strumienia pakietów.
W chmurze AWS wymagania dotyczące opóźnienia przesyłania są ekstremalnie wysokie. Dlatego HyperPlane jest krytyczne dla funkcjonowania całej sieci.
Hyperplane oparty jest na maszynach wirtualnych EC2. Nie ma tu żadnej magii, tylko spryt. Spryt polega na tym, że są to wirtualki z dużą pamięcią RAM. Operacje są transakcyjne i prowadzone wyłącznie w pamięci. Umożliwia to osiągnięcie opóźnień rzędu dziesiątek mikrosekund. Praca z dyskiem zabiłaby całą wydajność.
Hyperplane to rozproszony system z ogromną liczbą takich maszyn EC2. Każda wirtualka ma przepustowość 5 GB/s. W skali całej regionalnej sieci daje to oszałamiającą przepustowość terabitową i pozwala obsługiwać miliony połączeń na sekundę..
HyperPlane działa tylko z wątkami. Enkapsulacja pakietów VPC jest dla niego całkowicie przezroczysta. Potencjalna luka w tej wewnętrznej usługę i tak nie pozwoli na naruszenie izolacji VPC. Za bezpieczeństwo odpowiadają niższe warstwy.
Hałaśliwy sąsiad
Jest jeszcze jeden problem hałaśliwego sąsiada — hałaśliwy sąsiad. Załóżmy, że mamy 8 węzłów. Te węzły obsługują wątki wszystkich użytkowników w chmurze. Wszystko wydaje się w porządku, a obciążenie powinno być równomiernie rozłożone na wszystkie węzły. Węzły są bardzo potężne i trudno je przeciążyć.
Ale budujemy naszą architekturę w oparciu o nawet mało prawdopodobne scenariusze.
Niska prawdopodobieństwo nie oznacza niemożliwości.
Możemy sobie wyobrazić sytuację, w której jeden lub kilku użytkowników generuje zbyt dużą ilość obciążenia. W przetwarzaniu tego obciążenia biorą udział wszystkie węzły HyperPlane, a inni użytkownicy mogą potencjalnie odczuć pewne obniżenie wydajności. To niszczy koncepcję chmury, w której najemcy nie mogą wpływać na siebie nawzajem.
Jak rozwiązać problem hałaśliwego sąsiada? Pierwsza rzecz, która przychodzi na myśl – shardowanie. Nasze 8 węzłów dzielimy logicznie na 4 shardy po 2 węzły w każdym. Teraz hałaśliwy sąsiad przeszkadza tylko jednej czwartej wszystkich użytkowników, ale znacznie.
Zróbmy inaczej. Każdemu użytkownikowi przypiszemy tylko 3 węzły.
Sztuczka polega na losowym przypisywaniu węzłów różnym użytkownikom. Na poniższym obrazku niebieski użytkownik przecina się z węzłami z jednym z dwóch innych użytkowników – zielonym i pomarańczowym.
W przypadku 8 węzłów i 3 użytkowników prawdopodobieństwo, że hałaśliwy sąsiad przecina się z jednym z użytkowników, wynosi 54%. To z takim prawdopodobieństwem niebieski użytkownik wpłynie na innych najemców. Przy tym tylko częścią swojego obciążenia. W naszym przykładzie to wpływ zauważą tylko niektórzy, a zaledwie jedna trzecia wszystkich użytkowników. To już niezły wynik.
Liczba użytkowników, którzy się przecięli
Prawdopodobieństwo w procentach
0
18%
1
54%
2
26%
3
2%
Przybliżmy sytuację do rzeczywistej — weźmy 100 węzłów i 5 użytkowników na 5 węzłach. W takim przypadku żadna z węzłów nie przecina się z prawdopodobieństwem 77%.
Liczba użytkowników, którzy się przecięli
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ę mieszany szarding — shuffle sharding. Minimalizuje negatywny wpływ awarii węzłów.
Na bazie HyperPlane powstało wiele usług: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala sieci
Teraz porozmawiajmy o skali samej sieci. W październiku 2019 AWS oferuje swoje usługi w 22 regionach, a planowanych jest jeszcze 9.
- Każdy region zawiera kilka stref dostępności – Availability Zone. Jest ich na całym świecie 69.
- Każda AZ składa się z Centrów Danych. Ich liczba nie przekracza 8.
- W Centrach Danych znajduje się ogromna liczba serwerów, w niektórych do 300 000.
Teraz to wszystko uśrednimy, pomnożymy i otrzymamy imponującą liczbę, która odzwierciedla skalę chmury Amazon.
Między strefami dostępności a Centrami Danych znajduje się wiele kanałów optycznych. W jednym z naszych największych regionów na potrzeby komunikacji między AZ i centrami komunikacyjnymi w innych regionach (Transit Centers) zainstalowano 388 kanałów. W sumie daje to oszałamiające 5000 Tbit.
Backbone AWS został stworzony specjalnie dla chmury i zoptymalizowany do współpracy z nią. Budujemy go na kanałach 100 GB/s. Całkowicie nadzorujemy je, z wyjątkiem regionów w Chinach. Ruch nie jest dzielony z obciążeniami innych firm.
Oczywiście, nie jesteśmy jedynym dostawcą chmury z prywatną siecią backbone. Coraz więcej dużych firm podąża tą ścieżką. Potwierdzają to niezależni badacze, na przykład z .
Na wykresie widać, że udział dostawców treści i dostawców chmury rośnie. W związku z tym udział ruchu Internetowego dostawców backbone stale maleje.
Wyjaśnię, dlaczego tak się dzieje. Kiedyś większość usług internetowych była dostępna i konsumowana bezpośrednio z Internetu. Teraz coraz więcej serwerów znajduje się w chmurze i jest dostępnych przez CDN — Content Distribution Network. Aby uzyskać dostęp do zasobu, użytkownik przechodzi przez Internet tylko do najbliższego PoP CDN – Point of Presence. Zazwyczaj znajduje się to gdzieś w pobliżu. Następnie opuszcza publiczny Internet i przez prywatną sieć backbone leci przez Atlantyk, na przykład, i trafia bezpośrednio do zasobu.
Ciekawe, jak zmieni się Internet za 10 lat, jeśli ta tendencja się utrzyma?
Fizyczne kanały
Naukowcy jeszcze nie wymyślili, jak zwiększyć prędkość światła w Uniwersum, ale znacznie posunęli się naprzód w metodach jego przesyłania przez światłowody. Aktualnie używamy kabli z 6912 włóknami. Umożliwia to znaczne zoptymalizowanie kosztów ich układania.
W niektórych regionach musimy używać specjalnych kabli. Na przykład, w regionie Sydney stosujemy kable o specjalnej powłokę przeciwko termitom.
Nikt nie jest ubezpieczony od nieprzyjemności i czasami nasze kanały ulegają uszkodzeniu. Na zdjęciu po prawej stronie widać włókna optyczne w jednym z regionów Amerykańskich, które zostały zerwane przez budowniczych. W wyniku awarii utracono tylko 13 pakietów danych, co jest zdumiewające. Jeszcze raz – tylko 13! System błyskawicznie przeszedł na kanały rezerwowe — skalowalność działa.
Szybko przeszliśmy przez kilka usług i technologii chmury Amazon. Mam nadzieję, że macie przynajmniej jakieś pojęcie o skali zadań, które muszą rozwiązywać nasi inżynierowie. Osobiście jestem tym bardzo zainteresowany.
To jest finałowa część trylogii autorstwa Wasilija Pantiuchina o architekturze AWS. W części opisano optymalizację serwerów i skalowanie baz danych, a w — funkcje bezserwerowe i Firecracker.
Na w listopadzie Wasilij Pantiuchin podzieli się nowymi szczegółami architektury Amazon. On o przyczynach awarii i projektowaniu systemów rozproszonych w Amazonie. Do 24 października można jeszcze bilet w dobrej cenie, a zapłacić później. Czekamy na was na HighLoad++, przyjdźcie — porozmawiamy!
Źródło: habr.com
