Halo, nama saya Kostya Kramlikh, saya pengembang utama divisi Virtual Private Cloud di Yandex.Cloud. Saya seorang penggiat jejaring virtual, dan seperti yang Anda duga, dalam artikel ini saya akan berbicara tentang perangkat Virtual Private Cloud (VPC) secara umum dan jaringan virtual pada khususnya. Dan Anda juga akan mengetahui mengapa kami, pengembang layanan, menghargai umpan balik dari pengguna kami. Tapi hal pertama yang pertama.
Apa itu VPC?
Saat ini, ada berbagai opsi untuk menggunakan layanan. Saya yakin seseorang masih menyimpan server di bawah meja administrator, meskipun saya berharap lebih sedikit cerita seperti itu.
Sekarang layanan mencoba masuk ke cloud publik, dan di sinilah mereka bertabrakan dengan VPC. VPC adalah bagian dari cloud publik yang menyatukan pengguna, infrastruktur, platform, dan kapasitas lainnya, di mana pun mereka berada, di Cloud kami atau di luarnya. Pada saat yang sama, VPC memungkinkan Anda untuk tidak mengekspos kapasitas ini ke Internet secara tidak perlu, mereka tetap berada dalam jaringan Anda yang terisolasi.
Seperti apa tampilan jaringan virtual dari luar?
Yang kami maksud dengan VPC adalah jaringan overlay dan layanan jaringan, seperti VPNaaS, NATaas, LBaas, dll. Dan semua ini berfungsi di atas infrastruktur jaringan yang toleran terhadap kesalahan, yang telah di sini, di HabrΓ©.
Mari kita lihat lebih dekat jaringan virtual dan perangkatnya.
Pertimbangkan dua zona ketersediaan. Kami menyediakan jaringan virtual - yang kami sebut VPC. Nyatanya, ini menentukan ruang keunikan alamat "abu-abu" Anda. Dalam setiap jaringan virtual, Anda memiliki kendali penuh atas ruang alamat yang dapat Anda tetapkan untuk menghitung sumber daya.
Jaringannya global. Pada saat yang sama, itu diproyeksikan ke masing-masing zona ketersediaan dalam bentuk entitas yang disebut Subnet. Untuk setiap Subnet, Anda menetapkan CIDR berukuran 16 atau kurang. Bisa ada lebih dari satu entitas seperti itu di setiap zona ketersediaan, dan selalu ada perutean transparan di antara mereka. Ini berarti bahwa semua sumber daya Anda dalam VPC yang sama dapat "berbicara" satu sama lain, meskipun mereka berada di Availability Zone yang berbeda. "Berkomunikasi" tanpa akses ke Internet, melalui saluran internal kami, "berpikir" bahwa mereka berada dalam jaringan pribadi yang sama.
Diagram di atas menunjukkan situasi tipikal: dua VPC yang berpotongan di suatu tempat di alamat. Keduanya bisa menjadi milik Anda. Misalnya, satu untuk pengembangan, yang lain untuk pengujian. Mungkin ada pengguna yang berbeda - dalam hal ini tidak masalah. Dan satu mesin virtual dicolokkan ke setiap VPC.
Mari kita perburuk skemanya. Anda dapat membuatnya sehingga satu mesin virtual terjebak ke dalam beberapa Subnet sekaligus. Dan tidak begitu saja, tetapi di jaringan virtual yang berbeda.
Pada saat yang sama, jika Anda perlu mengekspos mesin ke Internet, ini dapat dilakukan melalui API atau UI. Untuk melakukan ini, Anda perlu mengonfigurasi terjemahan NAT dari alamat internal "abu-abu" Anda, ke "putih" - publik. Anda tidak dapat memilih alamat "putih", itu diberikan secara acak dari kumpulan alamat kami. Segera setelah Anda berhenti menggunakan IP eksternal, itu dikembalikan ke kumpulan. Anda hanya membayar untuk waktu penggunaan alamat "putih".
Dimungkinkan juga untuk memberi mesin akses ke Internet menggunakan instans NAT. Anda dapat merutekan lalu lintas ke instance melalui tabel perutean statis. Kami telah menyediakan kasus seperti itu, karena terkadang pengguna membutuhkannya, dan kami mengetahuinya. Dengan demikian, katalog gambar kami berisi gambar NAT yang dikonfigurasi secara khusus.
Tetapi bahkan ketika gambar NAT sudah siap, penyiapannya bisa rumit. Kami memahami bahwa untuk beberapa pengguna ini bukan opsi yang paling nyaman, jadi pada akhirnya kami memungkinkan untuk mengaktifkan NAT untuk Subnet yang diinginkan dalam satu klik. Fitur ini masih dalam akses pratinjau tertutup, yang diuji dengan bantuan anggota komunitas.
Bagaimana jaringan virtual diatur dari dalam
Bagaimana cara pengguna berinteraksi dengan jaringan virtual? Web melihat ke luar dengan API-nya. Pengguna datang ke API dan bekerja dengan status target. Melalui API, pengguna melihat bagaimana segala sesuatu harus diatur dan dikonfigurasi, sambil melihat status, seberapa besar perbedaan keadaan sebenarnya dari yang diinginkan. Ini adalah gambar dari pengguna. Apa yang terjadi di dalam?
Kami menulis status yang diinginkan ke Yandex Database dan pergi untuk mengonfigurasi berbagai bagian VPC kami. Jaringan overlay di Yandex.Cloud didasarkan pada komponen OpenContrail yang dipilih, yang baru-baru ini disebut Tungsten Fabric. Layanan jaringan diimplementasikan pada satu platform CloudGate. Di CloudGate, kami juga menggunakan sejumlah komponen sumber terbuka: GoBGP - untuk mengakses informasi kontrol, serta VPP - untuk mengimplementasikan router perangkat lunak yang berjalan di atas DPDK untuk jalur data.
Tungsten Fabric berkomunikasi dengan CloudGate melalui GoBGP. Menceritakan apa yang terjadi di jaringan overlay. CloudGate, pada gilirannya, menghubungkan jaringan overlay satu sama lain dan dengan Internet.
Sekarang mari kita lihat bagaimana jaringan virtual memecahkan masalah penskalaan dan ketersediaan. Mari kita pertimbangkan kasus sederhana. Ada satu zona ketersediaan dan dua VPC dibuat di dalamnya. Kami menerapkan satu instans Tungsten Fabric, dan ini menarik beberapa puluh ribu jaringan. Jaringan berkomunikasi dengan CloudGate. CloudGate, seperti yang telah kami katakan, memastikan konektivitas mereka satu sama lain dan dengan Internet.
Katakanlah zona ketersediaan kedua ditambahkan. Seharusnya gagal sepenuhnya terlepas dari yang pertama. Oleh karena itu, di zona ketersediaan kedua, kita harus memasang instance Tungsten Fabric yang terpisah. Ini akan menjadi sistem terpisah yang menangani overlay dan hanya tahu sedikit tentang sistem pertama. Dan visibilitas bahwa jaringan virtual kami bersifat global, pada kenyataannya, menciptakan VPC API kami. Ini tugasnya.
VPC1 dipetakan ke Availability Zone B jika ada sumber daya di Availability Zone B yang didorong ke VPC1. Jika tidak ada sumber daya dari VPC2 di zona ketersediaan B, kami tidak akan mewujudkan VPC2 di zona ini. Sebaliknya, karena sumber daya dari VPC3 hanya ada di zona B, VPC3 tidak ada di zona A. Semuanya sederhana dan logis.
Mari masuk lebih dalam dan lihat cara kerja host tertentu di Y.Cloud. Hal utama yang ingin saya perhatikan adalah bahwa semua host diatur dengan cara yang sama. Kami membuatnya sehingga hanya layanan minimum yang diperlukan yang berjalan di perangkat keras, sisanya berjalan di mesin virtual. Kami membangun layanan tingkat tinggi berdasarkan layanan infrastruktur dasar, dan juga menggunakan Cloud untuk menyelesaikan beberapa masalah teknis, misalnya, dalam kerangka Integrasi Berkelanjutan.
Jika kita melihat host tertentu, kita dapat melihat bahwa ada tiga komponen yang berjalan di OS host:
- Hitung - bagian yang bertanggung jawab atas distribusi sumber daya komputasi di host.
- VRouter adalah bagian dari Kain Tungsten yang mengatur overlay, yaitu paket terowongan melalui lapisan bawah.
- VDisk adalah potongan virtualisasi penyimpanan.
Selain itu, layanan diluncurkan dalam mesin virtual: Layanan infrastruktur cloud, layanan platform, dan kapasitas pelanggan. Kapasitas pelanggan dan layanan platform selalu masuk ke overlay melalui VRouter.
Layanan infrastruktur dapat menempel di overlay, tetapi pada dasarnya mereka ingin bekerja di underlay. Mereka terjebak di lapisan bawah dengan bantuan SR-IOV. Faktanya, kami memotong kartu menjadi kartu jaringan virtual (fungsi virtual) dan mendorongnya ke mesin virtual infrastruktur agar tidak kehilangan kinerja. Misalnya, CloudGate yang sama diluncurkan sebagai salah satu mesin virtual infrastruktur ini.
Sekarang setelah kami menjelaskan tugas global jaringan virtual dan struktur komponen dasar cloud, mari kita lihat bagaimana tepatnya berbagai bagian jaringan virtual berinteraksi satu sama lain.
Kami membedakan tiga lapisan dalam sistem kami:
- Config Plane - menetapkan status target sistem. Inilah yang dikonfigurasi pengguna melalui API.
- Control Plane - menyediakan semantik yang ditentukan pengguna, yaitu, membawa status Data Plane ke apa yang dijelaskan oleh pengguna di Config Plane.
- Pesawat Data - langsung memproses paket pengguna.
Seperti yang saya katakan di atas, semuanya dimulai dengan fakta bahwa pengguna atau layanan platform internal datang ke API dan menjelaskan status target tertentu.
Status ini segera ditulis ke Yandex Database, mengembalikan ID operasi asinkron melalui API, dan memulai mesin internal kami untuk mengembalikan status yang diinginkan pengguna. Tugas konfigurasi masuk ke pengontrol SDN dan beri tahu Tungsten Fabric apa yang harus dilakukan di overlay. Misalnya, mereka memesan port, jaringan virtual, dan sejenisnya.
Config Plane di Tungsten Fabric mengirimkan status yang diperlukan ke Control Plane. Melalui itu, Config Plane berkomunikasi dengan host, memberi tahu apa sebenarnya yang akan segera berputar pada mereka.
Sekarang mari kita lihat bagaimana tampilan sistem di host. Mesin virtual memiliki adaptor jaringan yang dicolokkan ke VRouter. VRouter adalah modul inti Tungsten Fabric yang melihat paket. Jika sudah ada alur untuk beberapa paket, modul akan memprosesnya. Jika tidak ada aliran, modul melakukan apa yang disebut punting, yaitu mengirimkan paket ke proses usermod. Proses mem-parsing paket dan meresponsnya sendiri, seperti DHCP dan DNS, atau memberi tahu VRouter apa yang harus dilakukan dengannya. Setelah itu, VRouter dapat memproses paket tersebut.
Selanjutnya, lalu lintas antar mesin virtual dalam jaringan virtual yang sama berjalan transparan, tidak diarahkan ke CloudGate. Host tempat mesin virtual digunakan berkomunikasi secara langsung satu sama lain. Mereka mengarahkan lalu lintas dan meneruskannya satu sama lain melalui lapisan bawah.
Control Planes berkomunikasi satu sama lain antara availability zone melalui BGP, seperti halnya dengan router lain. Mereka memberi tahu mesin mana yang ada sehingga VM di satu zona dapat berkomunikasi langsung dengan VM lain.
Dan Control Plane berkomunikasi dengan CloudGate. Demikian pula, ini melaporkan di mana dan mesin virtual mana yang dimunculkan, alamat apa yang mereka miliki. Ini memungkinkan Anda untuk mengarahkan lalu lintas eksternal dan lalu lintas dari penyeimbang ke mereka.
Lalu lintas yang keluar dari VPC datang ke CloudGate, ke jalur data, tempat VPP dengan plugin kami dikunyah dengan cepat. Kemudian lalu lintas diarahkan ke VPC lain atau di luar, ke router perbatasan yang dikonfigurasi melalui Control Plane CloudGate itu sendiri.
Rencana dalam waktu dekat
Jika kami meringkas semua yang disebutkan di atas dalam beberapa kalimat, kami dapat mengatakan bahwa VPC di Yandex.Cloud menyelesaikan dua tugas penting:
- Menyediakan isolasi antara klien yang berbeda.
- Menggabungkan sumber daya, infrastruktur, layanan platform, cloud lain, dan on-premise ke dalam satu jaringan.
Dan untuk mengatasi masalah ini dengan baik, Anda perlu menyediakan skalabilitas dan toleransi kesalahan pada tingkat arsitektur internal, yang dilakukan oleh VPC.
Secara bertahap VPC memperoleh fungsi, kami menerapkan fitur baru, kami mencoba meningkatkan sesuatu dalam hal kenyamanan pengguna. Beberapa ide disuarakan dan masuk dalam daftar prioritas berkat anggota komunitas kami.
Saat ini kami memiliki daftar rencana berikut untuk waktu dekat:
- VPN sebagai layanan
- Instans DNS pribadi adalah gambar untuk menyiapkan mesin virtual dengan cepat menggunakan server DNS yang telah dikonfigurasi sebelumnya.
- DNS sebagai layanan.
- Penyeimbang beban internal.
- Menambahkan alamat IP "putih" tanpa membuat ulang mesin virtual.
Penyeimbang dan kemampuan untuk mengganti alamat IP untuk mesin virtual yang sudah dibuat ada di daftar ini atas permintaan pengguna. Sejujurnya, tanpa umpan balik yang jelas, kami akan menjalankan fungsi ini nanti. Jadi kami sudah mengerjakan masalah tentang alamat.
Awalnya, alamat IP "putih" hanya dapat ditambahkan saat membuat mesin. Jika pengguna lupa melakukan ini, mesin virtual harus dibuat ulang. Sama dan, jika perlu, hapus IP eksternal. Ini akan segera memungkinkan untuk menghidupkan dan mematikan IP publik tanpa harus membuat ulang mesin.
Jangan ragu untuk mengekspresikan Anda pengguna lain. Anda membantu kami menjadikan Cloud lebih baik dan mendapatkan fitur penting dan berguna dengan lebih cepat!
Sumber: www.habr.com