Cześć, nazywam się Kostya Kramliх, jestem głównym programistą działu Virtual Private Cloud w Yandex.Cloud. Zajmuję się wirtualną siecią i, jak można się domyślić, w tym artykule opowiem o budowie Virtual Private Cloud (VPC) w ogóle i wirtualnej sieci w szczególności. Dowiesz się też, dlaczego my, programiści tego serwisu, cenimy opinię naszych użytkowników. Ale po kolei.
Co to jest VPC?
W dzisiejszych czasach istnieje wiele możliwości uruchamiania usług. Jestem pewien, że niektórzy wciąż trzymają serwer pod biurkiem administratora, chociaż mam nadzieję, że takich historii jest coraz mniej.
Obecnie usługi starają się przenieść do chmur publicznych, a tutaj właśnie stykają się z VPC. VPC to część chmury publicznej, która łączy zasoby użytkowników, infrastruktury, platform i inne w całość, niezależnie od ich lokalizacji, w naszej Chmurze lub poza nią. VPC pozwala nie wystawiać tych zasobów do internetu bez potrzeby, pozostają one w ramach twojej izolowanej sieci.
Jak wirtualna sieć wygląda z zewnątrz
Pod VPC rozumiemy przede wszystkim sieć nadbudowaną i usługi sieciowe, takie jak VPNaaS, NATaas, LBaas itp. Wszystko to działa na niezawodnej infrastrukturze sieciowej, o której już była mowa świetny artykuł tutaj, na Habrze.
Przyjrzyjmy się dokładniej wirtualnej sieci i jej budowie.
Rozważmy dwie strefy dostępności. Oferujemy wirtualną sieć – to, co nazwaliśmy VPC. W rzeczywistości definiuje ona przestrzeń wyjątkowości twoich "szarych" adresów. W ramach każdej wirtualnej sieci masz pełną kontrolę nad przestrzenią adresów, które możesz przypisać zasobom obliczeniowym.
Sieć jest globalna. Przez to jest projekcją każdej ze stref dostępności w postaci jednostki zwanej Subnet. Dla każdej Subnet przypisujesz pewną wielkość CIDR, wynoszącą 16 lub mniej. W każdej strefie dostępności może być więcej niż jedna taka jednostka, z zawsze przejrzystym routingiem między nimi. Oznacza to, że wszystkie twoje zasoby w ramach jednej VPC mogą "komunikować się" ze sobą, nawet jeśli znajdują się w różnych strefach dostępności. "Komunikować się" bez wyjścia do internetu, po naszych wewnętrznych kanałach, "myśląc", że znajdują się w jednej prywatnej sieci.
Na powyższym schemacie przedstawiona jest typowa sytuacja: dwie VPC, które gdzieś pokrywają się adresami. Obie mogą należeć do Ciebie. Na przykład, jedna z nich jest przeznaczona do rozwoju, a druga – do testowania. Mogą być też po prostu różni użytkownicy – w tym przypadku to nie ma znaczenia. A w każdej VPC zainstalowana jest jedna maszyna wirtualna.
Utrudnijmy schemat. Można zrealizować tak, żeby jedna maszyna wirtualna była podłączona jednocześnie do kilku Subnet. I to nie byle jak, a w różnych wirtualnych sieciach.
Jeśli jednak musisz wystawić maszyny do internetu, możesz to zrobić za pomocą API lub UI. W tym celu konieczne jest skonfigurowanie translacji NAT z Twojego „szarego”, wewnętrznego adresu na „biały” – publiczny. Nie możesz wybrać „białego” adresu, jest on przydzielany losowo z naszego puli adresów. Gdy przestajesz korzystać z zewnętrznego IP, wraca on do puli. Płacisz tylko za czas korzystania z „białego” adresu.
Istnieje również możliwość nadania maszynie dostępu do internetu za pomocą instancji NAT. Można kierować ruch przez tę instancję za pomocą statycznej tablicy routingu. Przewidzieliśmy taki przypadek, ponieważ jest on potrzebny użytkownikom, i wiemy o tym. W związku z tym w naszym katalogu obrazów znajduje się specjalnie skonfigurowany obraz NAT.
Jednak nawet gdy jest gotowy obraz NAT, konfiguracja może być skomplikowana. Rozumieliśmy, że dla niektórych użytkowników to nie jest najwygodniejsza opcja, dlatego w końcu wprowadziliśmy możliwość włączenia NAT dla wybranej Subnet jednym kliknięciem. Ta funkcja jest jeszcze w ramach zamkniętego dostępu preview, gdzie testowana jest przez uczestników społeczności.
Jak wirtualna sieć jest zbudowana od wewnątrz
Jak użytkownik wchodzi w interakcję z wirtualną siecią? Sieć patrzy na zewnątrz swoimi API. Użytkownik przychodzi do API i pracuje nad stanem docelowym. Poprzez API użytkownik widzi, jak wszystko powinno być zorganizowane i skonfigurowane, widząc jednocześnie status tego, jak aktualny stan różni się od oczekiwanego. To obraz użytkownika. A co dzieje się w środku?
Rejestrujemy pożądany stan w Yandex Database i przechodzimy do konfiguracji różnych części naszej VPC. Sieć nakładkowa w Yandex.Cloud jest zbudowana na wybranych komponentach OpenContrail, który od niedawna nosi nazwę Tungsten Fabric. Usługi sieciowe są realizowane na jednej platformie CloudGate. W CloudGate również wykorzystaliśmy kilka komponentów open source: GoBGP – do przetwarzania informacji kontrolnej, a także VPP – do realizacji oprogramowanego routera, działającego na DPDK dla ścieżki danych.
Tungsten Fabric komunikuje się z CloudGate przez GoBGP. Informuje o tym, co dzieje się w sieci nakładkowej. CloudGate z kolei łączy sieci nakładkowe ze sobą oraz z internetem.
Teraz przyjrzyjmy się, jak wirtualna sieć rozwiązuje problemy z skalowalnością i dostępnością. Rozważmy prosty przypadek. Mamy jedną strefę dostępności i zostały w niej utworzone dwie VPC. Rozłożyliśmy jedną instancję Tungsten Fabric, która obsługuje kilka dziesięciu tysięcy sieci. Sieci są połączone z CloudGate. CloudGate, jak już mówiliśmy, zapewnia połączenie między nimi a internetem.
Załóżmy, że dodana zostaje druga strefa dostępności. Powinna działać całkowicie niezależnie od pierwszej. Dlatego w drugiej strefie dostępności musimy postawić oddzielną instancję Tungsten Fabric. Będzie to oddzielny system, który zajmuje się nakładką i niewiele wie o pierwszym systemie. A widoczność, że nasza wirtualna sieć jest globalna, właściwie tworzy nasz API VPC. To jest jego zadanie.
VPC1 jest projektowana w strefie dostępności B, jeśli w strefie dostępności B są zasoby, które są wpinane do VPC1. Jeśli zasobów z VPC2 w strefie dostępności B nie ma, VPC2 w tej strefie nie materializujemy. Z drugiej strony, ponieważ zasoby z VPC3 istnieją tylko w strefie B, VPC3 nie ma w strefie A. Wszystko jest proste i logiczne.
Przyjrzyjmy się trochę głębiej, jak jest zbudowany konkretny hosting w Yandex.Cloud. Najważniejsze, co należy zauważyć – wszystkie hosty są zbudowane identycznie. Robimy tak, aby tylko niezbędne usługi działały na „sprzęcie”, a pozostałe działają na maszynach wirtualnych. Budujemy usługi wyższego rzędu na bazie podstawowych usług infrastrukturalnych, a także wykorzystujemy Cloud do rozwiązywania niektórych zadań inżynieryjnych, na przykład w ramach Continuous Integration.
Jeśli przyjrzymy się konkretnemu hoście, zobaczymy, że w systemie operacyjnym hosta działają trzy komponenty:
- Compute – część odpowiedzialna za przydzielanie zasobów obliczeniowych na hoście.
- VRouter – część Tungsten Fabric, która organizuje overlay, czyli tuneluje pakiety przez underlay.
- VDisk – to fragmenty wirtualizacji magazynowania.
Oprócz tego w maszynach wirtualnych działają usługi: usługi infrastrukturalne Chmury, usługi platformowe i moc obliczeniowa klientów. Moce obliczeniowe klientów i usługi platformowe zawsze przechodzą przez overlay za pomocą VRouter.
Usługi infrastrukturalne mogą być podłączone do overlay, ale głównie chcą działać w underlay. W underlay są podłączane za pomocą SR-IOV. Faktycznie, dzielimy kartę na wirtualne karty sieciowe (wirtualne funkcje) i wkładamy je do wirtualnych maszyn infrastrukturalnych, aby nie tracić wydajności. Na przykład, ten sam CloudGate uruchamiany jest jako jedna z takich wirtualnych maszyn infrastrukturalnych.
Teraz, gdy opisaliśmy globalne zadania wirtualnej sieci i budowę podstawowych komponentów chmury, przyjrzyjmy się, jak różne części wirtualnej sieci współdziałają ze sobą.
W naszej systemie wyróżniamy trzy warstwy:
- Config Plane – definiuje docelowy stan systemu. To, co konfiguruje użytkownik przez API.
- Control Plane – zapewnia określoną przez użytkownika semantykę, czyli doprowadza stan Data Plane do tego, co zostało opisane przez użytkownika w Config Plane.
- Data Plane – bezpośrednio przetwarza pakiety użytkowników.
Jak już wspomniałem powyżej, wszystko zaczyna się od tego, że użytkownik lub wewnętrzna usługa platformowa przychodzi do API i opisuje określony docelowy stan.
Ten stan natychmiast zapisywany jest w Yandex Database, zwraca przez API identyfikator asynchronicznej operacji i uruchamia naszą wewnętrzną machinę, aby wydać stan, którego chciał użytkownik. Zadania konfiguracyjne trafiają do kontrolera SDN i informują Tungsten Fabric, co należy zrobić w overlay. Na przykład rezerwują porty, wirtualne sieci i tym podobne.
Config Plane w Tungsten Fabric przekazuje do Control Plane wymagany stan. To przez nie Config Plane komunikuje się z hostami, informując, co dokładnie będzie wkrótce uruchomione.
Teraz przyjrzyjmy się, jak wygląda system na hostach. W maszynie wirtualnej Istnieje pewien adapter sieciowy, podłączony do VRouter. VRouter to rdzeniowy moduł Tungsten Fabric, który analizuje pakiety. Jeśli dla danego pakietu istnieje już flow, moduł go przetwarza. Jeśli flow nie ma, moduł wykonuje tzw. punting, czyli wysyła pakiet do procesu w trybie użytkownika. Proces analizuje pakiet i albo odpowiada na niego samodzielnie, jak w przypadku DHCP i DNS, albo mówi VRouterowi, co z nim zrobić. Po tym VRouter może przetwarzać pakiet.
Dalej ruch między maszynami wirtualnymi w obrębie jednej sieci wirtualnej odbywa się przejrzyście, nie jest kierowany do CloudGate. Hosty, na których działają maszyny wirtualne, komunikują się bezpośrednio ze sobą. Tunelują ruch i przekazują go sobie nawzajem przez underlay.
Control Plane komunikuje się ze sobą w różnych strefach dostępności przez BGP, jak z innym routerem. Informują się nawzajem, jakie maszyny są gdzie uruchomione, aby maszyny wirtualne w jednej strefie mogły bezpośrednio komunikować się z innymi maszynami wirtualnymi.
Control Plane komunikuje się również z CloudGate. Również przekazuje, gdzie i jakie maszyny wirtualne są uruchomione, jakie mają adresy. Umożliwia to kierowanie ruchu zewnętrznego oraz ruchu od balancerów do tych maszyn.
Ruch, który wychodzi z VPC, dociera do CloudGate, w ścieżce danych, gdzie szybko przetwarzany jest przez VPP z naszymi wtyczkami. Następnie ruch jest kierowany albo do innych VPC, albo na zewnątrz, do routerów brzegowych, które są konfigurowane przez Control Plane samego CloudGate.
Plany na najbliższą przyszłość
Podsumowując wszystko, co powiedziano powyżej, można stwierdzić, że VPC w Yandex.Cloud rozwiązuje dwie ważne kwestie:
- Zapewnia izolację między różnymi klientami.
- Łączy zasoby, infrastrukturę, usługi platformowe, inne chmury oraz on-premise w jedną sieć.
Aby dobrze realizować te zadania, należy zapewnić skalowalność i odporność na awarie na poziomie wewnętrznej architektury, co VPC właśnie robi.
Stopniowo VPC zyskuje nowe funkcje, wprowadzamy nowe możliwości, staramy się poprawiać aspekty dotyczące wygody użytkowników. Niektóre pomysły są zgłaszane i trafiają na listę priorytetów dzięki udziałowi członków naszej społeczności.
Obecnie mamy mniej więcej taki spis planów na najbliższą przyszłość:
- VPN jako usługa.
- Prywatne instancje DNS – obrazy do szybkiej konfiguracji maszyn wirtualnych z wcześniej skonfigurowanym serwerem DNS.
- DNS jako usługa.
- Wewnętrzny load balancer.
- Dodawanie „białego” adresu IP bez potrzeby ponownego tworzenia maszyny wirtualnej.
Load balancer oraz możliwość przełączania adresu IP dla już utworzonej maszyny wirtualnej znalazły się na tej liście na prośbę użytkowników. Powiem szczerze, bez wyraźnej informacji zwrotnej zajęlibyśmy się tymi funkcjami znacznie później. Tak więc już pracujemy nad zadaniem dotyczącym adresów.
Początkowo „biały” adres IP można było dodać tylko podczas tworzenia maszyny. Jeśli użytkownik zapomniał o tym, trzeba było ponownie tworzyć maszynę wirtualną. To samo dotyczyło potrzeby usunięcia zewnętrznego IP. Wkrótce będzie można włączać i wyłączać publiczny adres IP bez ponownego tworzenia maszyny.
Nie wahaj się dzielić swoimi pomysłami i wspierać propozycje innych użytkowników. Pomagasz nam uczynić Chmurę lepszą i szybciej uzyskujesz ważne i przydatne funkcje!
Źródło: habr.com
