Get best of the week

Bagaimana Yandex.Cloud di-host oleh Virtual Private Cloud dan bagaimana pengguna kami membantu kami menerapkan fitur yang bermanfaat

Hai, nama saya Kostya Kramlikh, saya adalah pengembang terkemuka divisi Virtual Private Cloud di Yandex.Cloud. Saya terlibat dalam jaringan virtual, dan, seperti yang Anda duga, dalam artikel ini saya akan berbicara tentang perangkat Virtual Private Cloud (VPC) pada umumnya dan jaringan virtual pada khususnya. Anda juga akan belajar mengapa kami, pengembang layanan, menghargai umpan balik dari pengguna kami. Tetapi hal pertama yang pertama.



Apa itu VPC?


Saat ini, untuk penyebaran layanan ada berbagai peluang. Saya yakin seseorang masih menyimpan server di bawah meja administrator, meskipun, saya harap, ada semakin sedikit cerita seperti itu.

Sekarang layanan mencoba masuk ke cloud publik, dan di sini mereka dihadapkan dengan VPC. VPC adalah bagian dari cloud publik yang menghubungkan pengguna, infrastruktur, platform, dan kapasitas lainnya bersama-sama, di mana pun mereka berada, di Cloud kami atau di luarnya. Pada saat yang sama, VPC memungkinkan untuk tidak perlu menempatkan kapasitas ini di Internet, mereka tetap berada dalam jaringan Anda yang terisolasi.

Bagaimana jaringan virtual terlihat dari luar




Dengan VPC, kami terutama memahami jaringan overlay dan layanan jaringan, seperti VPNaaS, NATaas, LBaas, dll. Dan semua ini bekerja di atas infrastruktur jaringan gagal-aman, yang sudah ada artikel bagus di Habré.

Mari kita lihat jaringan virtual dan perangkatnya lebih dekat.



Pertimbangkan dua bidang aksesibilitas. Kami menyediakan jaringan virtual - apa yang kami sebut VPC. Bahkan, ini mendefinisikan ruang keunikan alamat "abu-abu" Anda. Dalam setiap jaringan virtual, Anda sepenuhnya mengendalikan ruang alamat yang dapat Anda tetapkan untuk sumber daya komputasi.

Jaringan bersifat global. Pada saat yang sama, diproyeksikan ke masing-masing zona akses dalam bentuk entitas yang disebut Subnet. Untuk setiap Subnet, Anda menetapkan CIDR tertentu dengan ukuran 16 atau kurang. Mungkin ada lebih dari satu entitas seperti itu di setiap zona ketersediaan, sementara selalu ada perutean yang transparan di antara mereka. Ini berarti bahwa semua sumber daya Anda dalam VPC yang sama dapat "berkomunikasi" satu sama lain, bahkan jika mereka berada di zona akses 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 yang khas: dua VPC yang berpotongan di suatu alamat. Keduanya mungkin milik Anda. Misalnya, satu untuk pengembangan, satu lagi untuk pengujian. Mungkin ada beberapa pengguna yang berbeda - dalam hal ini, itu tidak masalah. Dan satu mesin virtual terjebak di setiap VPC.



Untuk memperburuk skema. Anda dapat membuat satu mesin virtual menempel ke beberapa Subnet sekaligus. Dan bukan hanya seperti itu, tetapi di berbagai jaringan virtual.



Pada saat yang sama, jika Anda perlu meletakkan mobil di Internet, ini dapat dilakukan melalui API atau UI. Untuk melakukan ini, Anda perlu mengonfigurasi terjemahan NAT "abu-abu", alamat internal, menjadi "putih" - publik. Anda tidak dapat memilih alamat "putih", melainkan diberikan secara acak dari kumpulan alamat kami. Segera setelah Anda berhenti menggunakan IP eksternal, ia kembali ke kolam. Anda hanya membayar untuk saat Anda menggunakan alamat "putih".



Dimungkinkan juga untuk memberikan mesin akses ke Internet menggunakan instance NAT. Pada contoh, Anda bisa mendapatkan lalu lintas melalui tabel routing statis. Kami telah menyediakan kasus seperti itu, karena pengguna membutuhkannya, dan kami mengetahuinya. Dengan demikian, dalam katalog gambar kami terdapat gambar NAT yang dikonfigurasi secara khusus.



Tetapi bahkan ketika ada gambar NAT siap pakai, konfigurasinya bisa rumit. Kami menyadari bahwa bagi sebagian pengguna ini bukan opsi yang paling nyaman, jadi pada akhirnya kami memungkinkan untuk memasukkan NAT untuk Subnet yang diinginkan dalam satu klik. Fitur ini masih dalam akses pratinjau pribadi, di mana ia digulirkan dengan bantuan anggota komunitas.

Cara kerja jaringan virtual dari dalam ke luar





Bagaimana cara pengguna berinteraksi dengan jaringan virtual? Jaringan terlihat keluar dengan API-nya. Pengguna datang ke API dan bekerja dengan negara target. Melalui API, pengguna melihat bagaimana semuanya harus diatur dan dikonfigurasikan, sementara ia melihat status seberapa jauh keadaan sebenarnya berbeda dari yang diinginkan. Ini adalah gambar pengguna. Apa yang sedang terjadi di dalam?

Kami mencatat keadaan yang diinginkan di Yandex Database dan pergi untuk mengkonfigurasi berbagai bagian VPC kami. Jaringan overlay di Yandex.Cloud dibangun berdasarkan komponen yang dipilih dari OpenContrail, yang baru-baru ini disebut Tungsten Fabric. Layanan jaringan diimplementasikan pada platform CloudGate tunggal. Di CloudGate, kami juga menggunakan sejumlah komponen open source: GoBGP - untuk mengakses informasi kontrol, dan VPP - untuk mengimplementasikan router perangkat lunak yang bekerja di atas DPDK untuk jalur data.

Tungsten Fabric berkomunikasi dengan CloudGate melalui GoBGP. Memberitahu apa yang terjadi pada jaringan hamparan. CloudGate, pada gilirannya, menghubungkan jaringan overlay satu sama lain dan ke Internet.



Sekarang mari kita lihat bagaimana jaringan virtual mengatasi skalabilitas dan ketersediaan. Pertimbangkan kasus sederhana. Ada satu zona ketersediaan dan dua VPC dibuat di dalamnya. Kami menggunakan satu contoh Tungsten Fabric, dan menarik puluhan ribu jaringan. Jaringan berkomunikasi dengan CloudGate. CloudGate, seperti yang telah kami katakan, memastikan konektivitas mereka satu sama lain dan dengan Internet.



Misalkan zona aksesibilitas kedua ditambahkan. Seharusnya gagal sepenuhnya terlepas dari yang pertama. Oleh karena itu, di zona akses kedua, kita harus mengirimkan mesin Tungsten Fabric yang terpisah. Ini akan menjadi sistem terpisah yang berhubungan dengan overlay dan hanya tahu sedikit tentang sistem pertama. Dan penampilan bahwa jaringan virtual kami bersifat global, pada kenyataannya, menciptakan API VPC kami. Ini tugasnya.

VPC1 diproyeksikan ke zona akses B jika ada sumber daya di zona akses B yang melekat pada VPC1. Jika tidak ada sumber daya dari VPC2 di zona akses B, kami tidak akan mewujudkan VPC2 di zona ini. Pada gilirannya, karena sumber daya dari VPC3 hanya ada di zona B, VPC3 tidak berada di zona A. Semuanya sederhana dan logis.

Mari kita sedikit lebih dalam dan melihat bagaimana host tertentu diatur dalam 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 berputar pada perangkat keras, sisanya bekerja pada mesin virtual. Kami membangun layanan dengan tingkat yang lebih tinggi berdasarkan layanan infrastruktur dasar, dan juga menggunakan Cloud untuk menyelesaikan beberapa masalah teknis, misalnya, sebagai bagian dari Integrasi Berkelanjutan.



Jika kita melihat host tertentu, kita akan melihat bahwa tiga komponen berputar di OS host:
  • Compute adalah bagian yang bertanggung jawab atas distribusi sumber daya komputasi pada host.
  • VRouter adalah bagian dari Tungsten Fabric yang mengatur overlay, yaitu paket-paket terowongan melalui overlay.
  • VDisk adalah bagian dari virtualisasi penyimpanan.

Selain itu, layanan diluncurkan dalam mesin virtual: layanan infrastruktur Cloud, layanan platform, dan kemampuan pelanggan. Kemampuan pelanggan dan layanan platform selalu ditayangkan melalui VRouter.

Layanan infrastruktur dapat menempel pada overlay, tetapi pada dasarnya mereka ingin bekerja pada overlay. Mereka terjebak dalam lapisan bawah dengan menggunakan SR-IOV. Bahkan, kami memotong kartu menjadi kartu jaringan virtual (fungsi virtual) dan mendorong mereka ke dalam mesin virtual infrastruktur agar tidak kehilangan kinerja. Sebagai contoh, CloudGate yang sama diluncurkan sebagai salah satu dari mesin virtual infrastruktur tersebut.

Sekarang kita telah menggambarkan tugas global dari jaringan virtual dan pengaturan komponen dasar cloud, mari kita lihat bagaimana tepatnya bagian-bagian berbeda dari jaringan virtual saling berinteraksi.

Kami membedakan tiga lapisan dalam sistem kami:
  • Config Plane - mengatur status target sistem. Inilah yang dikonfigurasikan pengguna melalui API.
  • Control Plane - menyediakan semantik yang ditentukan pengguna, yaitu, ia membawa keadaan Data Plane ke apa yang dijelaskan oleh pengguna di Config Plane.
  • Data Plane - 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.

Keadaan ini segera direkam dalam Basis Data Yandex, mengembalikan ID operasi asinkron melalui API, dan memulai mesin internal kami untuk mengembalikan status yang diinginkan pengguna. Tugas konfigurasi menuju ke pengontrol SDN dan memberi tahu Tungsten Fabric apa yang harus dilakukan dalam overlay. Misalnya, mereka memesan port, jaringan virtual, dan sejenisnya.



Config Plane di Tungsten Fabric mengirim status yang diperlukan ke Control Plane. Melalui itu, Config Plane berkomunikasi dengan host, memberi tahu apa yang akan terjadi pada mereka dalam waktu dekat.



Sekarang mari kita lihat seperti apa sistem di host. Di mesin virtual ada adapter jaringan tertentu yang terjebak di VRouter. VRouter adalah modul inti Tungsten Fabric yang memperhatikan paket. Jika sudah ada aliran untuk beberapa paket, modul memprosesnya. Jika tidak ada aliran, modul melakukan punting, yaitu mengirim paket ke proses mode pengguna. Proses mem-parsing paket dan meresponsnya sendiri, seperti, misalnya, untuk DHCP dan DNS, atau memberi tahu VRouter apa yang harus dilakukan dengannya. Setelah itu, VRouter dapat memproses paket tersebut.

Lebih jauh, lalu lintas antara mesin virtual dalam jaringan virtual yang sama berjalan secara transparan, tidak diarahkan ke CloudGate. Host di mana mesin virtual digunakan berkomunikasi secara langsung satu sama lain. Mereka terowongan lalu lintas dan meneruskannya satu sama lain melalui lapisan bawah.



Control Plane berkomunikasi satu sama lain antara zona akses BGP, seperti halnya dengan router lain. Mereka memberi tahu mesin mana yang dibesarkan, sehingga mesin virtual dalam satu zona dapat langsung berinteraksi dengan mesin virtual lainnya.



Juga, Control Plane berkomunikasi dengan CloudGate. Ini juga melaporkan di mana dan mesin virtual mana yang dinaikkan, apa alamatnya. Ini memungkinkan Anda untuk mengarahkan lalu lintas eksternal dan lalu lintas dari balancer ke mereka.

Lalu lintas yang meninggalkan VPC datang ke CloudGate, di jalur data, tempat VPP dengan cepat dikunyah dengan plugin kami. Selanjutnya, lalu lintas dipecat pada VPC lain atau ke luar di router tepi yang dikonfigurasi melalui ControlGane CloudGate.

Rencana untuk waktu dekat


Jika kami merangkum semua hal di atas dalam beberapa kalimat, kita dapat mengatakan bahwa VPC di Yandex.Cloud memecahkan dua tugas penting:

  • Memberikan isolasi antara pelanggan yang berbeda.
  • Menggabungkan sumber daya, infrastruktur, layanan platform, cloud lainnya dan on-premise menjadi satu jaringan.

Dan untuk menyelesaikan masalah ini dengan baik, Anda perlu memberikan skalabilitas dan toleransi kesalahan pada tingkat arsitektur internal, yang VPC lakukan.

VPC secara bertahap mendapatkan fungsi, kami menyadari peluang baru, kami mencoba meningkatkan sesuatu dalam hal kenyamanan pengguna. Beberapa ide disuarakan dan masuk dalam daftar prioritas berkat anggota komunitas kami.

Sekarang kami memiliki kira-kira daftar rencana berikut untuk waktu dekat:

  • VPN sebagai layanan.
  • Private DNS – DNS-.
  • DNS .
  • .
  • «» IP- .

Penyeimbang dan kemampuan untuk mengganti alamat IP untuk mesin virtual yang sudah dibuat ada dalam daftar ini atas permintaan pengguna. Terus terang, tanpa umpan balik eksplisit, kami akan mengambil fungsi ini sedikit kemudian. Jadi kami sudah mengerjakan tugas tentang alamat.

Awalnya, alamat IP "putih" hanya dapat ditambahkan saat membuat mesin. Jika pengguna lupa melakukan ini, mesin virtual harus dibuat ulang. Hal yang sama dan, jika perlu, lepaskan IP eksternal. Segera akan mungkin untuk menghidupkan dan mematikan IP publik tanpa membuat ulang mesin.

Jangan ragu untuk mengekspresikan ide Anda dan mendukung saran dari pengguna lain. Anda membantu kami membuat Cloud lebih baik dan mendapatkan fitur penting dan berguna lebih cepat!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles