Cześć, nazywam się Kostya Kramlikh i jestem głównym programistą działu Virtual Private Cloud w Yandex.Cloud. Jestem wirtualnym networkerem i jak można się domyślić, w tym artykule omówię ogólnie urządzenie Virtual Private Cloud (VPC), aw szczególności sieć wirtualną. Dowiesz się również, dlaczego my, twórcy usługi, cenimy opinie naszych użytkowników. Ale najpierw najważniejsze.
Co to jest VPC?
Obecnie istnieje wiele możliwości wdrażania usług. Na pewno ktoś jeszcze trzyma serwer pod biurkiem administratora, choć mam nadzieję, że takich historii będzie mniej.
Teraz usługi próbują przejść do chmur publicznych i tam zderzają się z VPC. VPC jest częścią chmury publicznej, która łączy użytkownika, infrastrukturę, platformę i inne możliwości, gdziekolwiek się znajdują, w naszej chmurze lub poza nią. Jednocześnie VPC pozwala nie narażać niepotrzebnie tych pojemności na Internet, pozostają one w odizolowanej sieci.
Jak wygląda sieć wirtualna z zewnątrz?
Przez VPC rozumiemy przede wszystkim sieć nakładkową i usługi sieciowe, takie jak VPNaaS, NATaas, LBaas itp. A wszystko to działa na odpornej na uszkodzenia infrastrukturze sieciowej, która została już tutaj, na Habré.
Przyjrzyjmy się bliżej sieci wirtualnej i jej urządzeniu.
Rozważ dwie strefy dostępności. Zapewniamy wirtualną sieć - którą nazwaliśmy VPC. W rzeczywistości określa przestrzeń wyjątkowości twoich „szarych” adresów. W ramach każdej sieci wirtualnej masz pełną kontrolę nad przestrzenią adresów, które możesz przypisać do zasobów obliczeniowych.
Sieć jest globalna. Jednocześnie jest rzutowany na każdą ze stref dostępności w postaci bytu o nazwie Subnet. Dla każdej podsieci przypisujesz CIDR o rozmiarze 16 lub mniejszym. W każdej strefie dostępności może istnieć więcej niż jedna taka jednostka, a między nimi zawsze istnieje przejrzysty routing. Oznacza to, że wszystkie Twoje zasoby w ramach tego samego VPC mogą „rozmawiać” ze sobą, nawet jeśli znajdują się w różnych strefach dostępności. „Komunikują się” bez dostępu do Internetu, za pośrednictwem naszych wewnętrznych kanałów, „myśląc”, że znajdują się w tej samej sieci prywatnej.
Powyższy diagram pokazuje typową sytuację: dwa VPC, które przecinają się gdzieś w adresach. Oba mogą być Twoje. Na przykład jeden do programowania, drugi do testowania. Mogą być po prostu różni użytkownicy - w tym przypadku nie ma to znaczenia. Do każdego VPC podłączona jest jedna maszyna wirtualna.
Pogorszmy schemat. Możesz to zrobić tak, aby jedna maszyna wirtualna utknęła w kilku podsieciach jednocześnie. I to nie tylko w ten sposób, ale w różnych sieciach wirtualnych.
Jednocześnie, jeśli chcesz udostępnić komputery Internetowi, możesz to zrobić za pośrednictwem interfejsu API lub interfejsu użytkownika. Aby to zrobić, musisz skonfigurować translację NAT swojego „szarego” adresu wewnętrznego na „biały” - publiczny. Nie możesz wybrać „białego” adresu, jest on przydzielany losowo z naszej puli adresów. Gdy tylko przestaniesz używać zewnętrznego adresu IP, jest on zwracany do puli. Płacisz tylko za czas korzystania z adresu „białego”.
Możliwe jest również nadanie maszynie dostępu do Internetu za pomocą instancji NAT. Możesz kierować ruch do instancji przez statyczną tablicę routingu. Udostępniliśmy taki przypadek, ponieważ użytkownicy czasami go potrzebują, a my o tym wiemy. W związku z tym nasz katalog obrazów zawiera specjalnie skonfigurowany obraz NAT.
Ale nawet jeśli istnieje gotowy obraz NAT, konfiguracja może być trudna. Zrozumieliśmy, że dla niektórych użytkowników nie jest to najwygodniejsza opcja, dlatego w końcu umożliwiliśmy włączenie NAT dla wybranej podsieci jednym kliknięciem. Ta funkcja jest nadal dostępna w zamkniętej wersji zapoznawczej, gdzie jest testowana z pomocą członków społeczności.
Jak zorganizowana jest sieć wirtualna od środka
W jaki sposób użytkownik wchodzi w interakcję z siecią wirtualną? Sieć wygląda na zewnątrz dzięki interfejsowi API. Użytkownik wchodzi do API i pracuje ze stanem docelowym. Poprzez API użytkownik widzi jak wszystko powinno być ułożone i skonfigurowane, natomiast widzi status, jak bardzo stan rzeczywisty różni się od pożądanego. To jest zdjęcie użytkownika. Co się dzieje w środku?
Zapisujemy żądany stan do bazy danych Yandex i przechodzimy do konfiguracji różnych części naszego VPC. Sieć nakładkowa w Yandex.Cloud bazuje na wybranych komponentach OpenContrail, który od niedawna nosi nazwę Tungsten Fabric. Usługi sieciowe są realizowane na jednej platformie CloudGate. W CloudGate wykorzystaliśmy również szereg komponentów open source: GoBGP — do kontroli dostępu do informacji, a także VPP — do wdrożenia routera programowego 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ładki. CloudGate z kolei łączy sieci nakładkowe między sobą oraz z Internetem.
Zobaczmy teraz, jak sieć wirtualna rozwiązuje problemy skalowania i dostępności. Rozważmy prosty przypadek. Jest jedna strefa dostępności i tworzone są w niej dwa VPC. Wdrożyliśmy jedną instancję Tungsten Fabric, która obsługuje kilkadziesiąt tysięcy sieci. Sieci komunikują się z CloudGate. CloudGate, jak już powiedzieliśmy, zapewnia ich łączność między sobą oraz z Internetem.
Załóżmy, że dodano drugą strefę dostępności. Powinien zawieść całkowicie niezależnie od pierwszego. Dlatego w drugiej strefie dostępności musimy zainstalować osobną instancję Tungsten Fabric. Będzie to osobny system, który zajmuje się nakładką i niewiele wie o pierwszym systemie. A widoczność, że nasza sieć wirtualna jest globalna, w rzeczywistości tworzy nasz VPC API. To jest jego zadanie.
VPC1 jest mapowany na strefę dostępności B, jeśli w strefie dostępności B znajdują się zasoby, które są przekazywane do VPC1. Jeśli w strefie dostępności B nie ma zasobów z VPC2, nie zmaterializujemy VPC2 w tej strefie. Z kolei skoro zasoby z VPC3 istnieją tylko w strefie B, to VPC3 nie istnieje w strefie A. Wszystko jest proste i logiczne.
Zajrzyjmy trochę głębiej i zobaczmy, jak działa konkretny host w Y.Cloud. Najważniejszą rzeczą, na którą chcę zwrócić uwagę, jest to, że wszystkie hosty są ułożone w ten sam sposób. Sprawiamy, że tylko niezbędne minimum usług działa na sprzęcie, a cała reszta na maszynach wirtualnych. Budujemy usługi wyższego rzędu w oparciu o podstawowe usługi infrastrukturalne, a także wykorzystujemy Chmurę do rozwiązywania niektórych problemów inżynierskich, np. w ramach Continuous Integration.
Jeśli spojrzymy na konkretnego hosta, zobaczymy, że w systemie operacyjnym hosta działają trzy komponenty:
- Compute - część odpowiedzialna za dystrybucję zasobów obliczeniowych na hoście.
- VRouter jest częścią Tungsten Fabric, która organizuje nakładkę, czyli tuneluje pakiety przez podkład.
- Dyski wirtualne to fragmenty wirtualizacji pamięci masowej.
Ponadto uruchamiane są usługi w maszynach wirtualnych: usługi infrastruktury chmurowej, usługi platformowe i pojemności klientów. Możliwości klienta i usługi platformy zawsze trafiają do nakładki za pośrednictwem VRouter.
Usługi infrastrukturalne mogą wbić się w nakładkę, ale zasadniczo chcą pracować w podkładzie. Wklejane są w podkład za pomocą SR-IOV. W rzeczywistości tniemy kartę na wirtualne karty sieciowe (funkcje wirtualne) i wpychamy je do maszyn wirtualnych infrastruktury, aby nie stracić wydajności. Na przykład ten sam CloudGate jest uruchamiany jako jedna z tych wirtualnych maszyn infrastruktury.
Teraz, gdy opisaliśmy globalne zadania sieci wirtualnej i strukturę podstawowych komponentów chmury, zobaczmy, jak dokładnie różne części sieci wirtualnej współdziałają ze sobą.
W naszym systemie wyróżniamy trzy warstwy:
- Płaszczyzna konfiguracji — ustawia docelowy stan systemu. To właśnie konfiguruje użytkownik za pomocą API.
- Control Plane — zapewnia semantykę zdefiniowaną przez użytkownika, czyli sprowadza stan Data Plane do stanu opisanego przez użytkownika w Config Plane.
- Data Plane - bezpośrednio przetwarza pakiety użytkownika.
Tak jak powiedziałem powyżej, wszystko zaczyna się od tego, że użytkownik lub wewnętrzna usługa platformy przychodzi do API i opisuje pewien stan docelowy.
Ten stan jest natychmiast zapisywany w bazie danych Yandex, zwraca identyfikator operacji asynchronicznej za pośrednictwem interfejsu API i uruchamia nasz wewnętrzny mechanizm w celu zwrócenia stanu pożądanego przez użytkownika. Zadania konfiguracyjne trafiają do kontrolera SDN i informują Tungsten Fabric, co ma robić w nakładce. Na przykład rezerwują porty, sieci wirtualne i tym podobne.
Config Plane w Tungsten Fabric wysyła wymagany stan do Control Plane. Za jego pośrednictwem Config Plane komunikuje się z hostami, informując, co dokładnie będzie się na nich wkrótce kręcić.
Zobaczmy teraz, jak system wygląda na hostach. Maszyna wirtualna ma kartę sieciową podłączoną do VRoutera. VRouter to podstawowy moduł Tungsten Fabric, który analizuje pakiety. Jeśli istnieje już przepływ dla jakiegoś pakietu, moduł go przetwarza. W przypadku braku przepływu moduł wykonuje tzw. punting, czyli wysyła pakiet do procesu usermod. Proces analizuje pakiet i albo odpowiada na niego sam, jak DHCP i DNS, albo mówi VRouterowi, co ma z nim zrobić. Następnie VRouter może przetworzyć pakiet.
Ponadto ruch między maszynami wirtualnymi w ramach tej samej sieci wirtualnej odbywa się w sposób transparentny, nie jest kierowany do CloudGate. Hosty, na których rozmieszczone są maszyny wirtualne, komunikują się ze sobą bezpośrednio. Tunelują ruch i przekazują go sobie nawzajem przez warstwę podkładową.
Płaszczyzny kontrolne komunikują się ze sobą między strefami dostępności za pośrednictwem protokołu BGP, tak jak w przypadku innego routera. Informują, które maszyny znajdują się w danym miejscu, dzięki czemu maszyny wirtualne w jednej strefie mogą komunikować się bezpośrednio z innymi maszynami wirtualnymi.
Płaszczyzna kontrolna komunikuje się z CloudGate. Podobnie raportuje gdzie i jakie maszyny wirtualne są podnoszone, jakie mają adresy. Pozwala to na kierowanie do nich ruchu zewnętrznego oraz ruchu z balancerów.
Ruch wychodzący z VPC trafia do CloudGate, na ścieżkę danych, gdzie VPP z naszymi wtyczkami jest szybko przeżuwany. Następnie ruch jest kierowany do innych VPC lub na zewnątrz, do routerów granicznych, które są konfigurowane przez płaszczyznę kontrolną samego CloudGate.
Plany na najbliższą przyszłość
Podsumowując wszystko, co zostało powiedziane powyżej, w kilku zdaniach, możemy powiedzieć, że VPC w Yandex.Cloud rozwiązuje dwa ważne zadania:
- Zapewnia izolację między różnymi klientami.
- Łączy zasoby, infrastrukturę, usługi platformy, inne chmury i lokalnie w jedną sieć.
A żeby dobrze rozwiązać te problemy, trzeba zapewnić skalowalność i odporność na awarie na poziomie wewnętrznej architektury, co robi VPC.
Stopniowo VPC nabywa funkcje, wdrażamy nowe funkcjonalności, staramy się coś ulepszyć pod kątem wygody użytkownika. Niektóre pomysły są zgłaszane i trafiają na listę priorytetów dzięki członkom naszej społeczności.
Obecnie mamy następującą listę planów na najbliższą przyszłość:
- VPN jako usługa.
- Prywatne instancje DNS to obrazy do szybkiego konfigurowania maszyn wirtualnych ze wstępnie skonfigurowanym serwerem DNS.
- DNS jako usługa.
- Wewnętrzny system równoważenia obciążenia.
- Dodanie „białego” adresu IP bez odtwarzania maszyny wirtualnej.
Balanser i możliwość zmiany adresu IP dla już utworzonej maszyny wirtualnej znalazły się na tej liście na prośbę użytkowników. Szczerze mówiąc, bez wyraźnej opinii przejęlibyśmy te funkcje nieco później. I tak już pracujemy nad problemem dotyczącym adresów.
Początkowo „biały” adres IP można było dodać tylko podczas tworzenia maszyny. Jeśli użytkownik zapomniał to zrobić, maszynę wirtualną trzeba było odtworzyć. To samo i, jeśli to konieczne, usuń zewnętrzny adres IP. Wkrótce będzie można włączać i wyłączać publiczny adres IP bez konieczności ponownego tworzenia maszyny.
Zapraszam do wyrażania swoich inni użytkownicy. Pomagasz nam ulepszać chmurę i szybciej uzyskiwać ważne i przydatne funkcje!
Źródło: www.habr.com