Geekly articles weekly

Otomasi Untuk Yang Terkecil. Bagian satu (yang setelah nol). Virtualisasi jaringan

Dalam rilis sebelumnya, saya menggambarkan kerangka kerja otomatisasi jaringan. Menurut ulasan dari beberapa orang, bahkan pendekatan pertama untuk masalah ini telah mengajukan beberapa pertanyaan di rak. Dan ini membuat saya sangat senang, karena tujuan kami dalam siklus ini bukan untuk menutupi yang mungkin dengan skrip Python, tetapi untuk membangun sistem.

Kerangka kerja yang sama menetapkan urutan di mana kita akan menangani pertanyaan.
Dan virtualisasi jaringan, yang didedikasikan untuk masalah ini, tidak benar-benar cocok dengan tema ADSM, tempat kami menganalisis otomatisasi.

Tapi mari kita lihat dari sudut yang berbeda.

Sudah sejak lama banyak layanan menggunakan satu jaringan. Dalam kasus pembawa, ini adalah 2G, 3G, LTE, broadband dan B2B, misalnya. Dalam kasus DC: konektivitas untuk klien yang berbeda, Internet, penyimpanan blok, penyimpanan objek.

Dan semua layanan membutuhkan isolasi satu sama lain. Jadi muncul jaringan overlay.

Dan semua layanan tidak ingin menunggu seseorang mengkonfigurasinya secara manual. Maka muncullah orkestra dan SDN.

Pendekatan pertama untuk otomatisasi sistematis jaringan, atau lebih tepatnya, bagian dari itu, telah lama dilakukan dan telah diterapkan di banyak tempat: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Di sini kita berurusan dengannya hari ini.



Isi


  • Alasan
  • Terminologi
  • Underlay - Jaringan Fisik
  • Overlay - jaringan virtual

    • Overlay dengan ToR
    • Hamparan dari host
    • Studi Kasus Kain Tungsten

      • Komunikasi dalam satu mesin fisik
      • Komunikasi antara VM terletak di berbagai mesin fisik
      • Keluar ke dunia luar


  • Faq
  • Kesimpulan
  • Tautan yang bermanfaat



Alasan


Dan karena kita membicarakan hal ini, perlu disebutkan prasyarat untuk virtualisasi jaringan. Sebenarnya, proses ini tidak dimulai kemarin.

Anda mungkin pernah mendengar lebih dari sekali bahwa jaringan selalu menjadi bagian yang paling lembam dari sistem apa pun. Dan ini benar dalam segala hal. Jaringan adalah dasar di mana semuanya didasarkan, dan membuat perubahan di atasnya cukup sulit - layanan tidak mentolerir ketika jaringan berada. Seringkali, menonaktifkan satu node dapat menambah sebagian besar aplikasi dan mempengaruhi banyak klien. Ini adalah sebagian alasan mengapa tim jaringan dapat menolak perubahan apa pun - karena sekarang ini entah bagaimana berfungsi ( kita mungkin bahkan tidak tahu caranya ), tetapi di sini kita perlu mengkonfigurasi sesuatu yang baru, dan tidak diketahui bagaimana hal itu akan mempengaruhi jaringan.

Agar tidak menunggu penyedia jaringan untuk lulus VLAN dan tidak mendaftarkan layanan pada setiap node jaringan, orang memutuskan untuk menggunakan overlay - jaringan yang ditumpangkan - yang ada beragam: GRE, IPinIP, MPLS, MPLS L2 / L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, dll.

Daya tarik mereka terletak pada dua hal sederhana:

  • Hanya node akhir yang dikonfigurasi - Anda tidak perlu menyentuh node transit. Ini secara signifikan mempercepat proses, dan kadang-kadang bahkan memungkinkan Anda untuk mengecualikan departemen infrastruktur jaringan dari proses memperkenalkan layanan baru.
  • Beban disembunyikan jauh di dalam header - node transit tidak perlu tahu apa-apa tentang hal itu, tentang mengatasi host, rute dari jaringan yang dikenakan. Dan ini berarti Anda perlu menyimpan lebih sedikit informasi dalam tabel, jadi gunakan perangkat yang lebih sederhana / lebih murah.

Dalam masalah yang tidak sepenuhnya lengkap ini, saya tidak berencana untuk menganalisis semua teknologi yang mungkin, melainkan menggambarkan kerangka kerja untuk pengoperasian jaringan overlay di DC.

Seluruh seri akan menjelaskan pusat data, yang terdiri dari barisan rak yang sama di mana peralatan server yang sama dipasang.

Peralatan ini menjalankan mesin virtual / wadah / serverless yang mengimplementasikan layanan.





Terminologi


Dalam loop, saya akan memanggil server program yang mengimplementasikan sisi server dari komunikasi client-server.

Mesin fisik di rak tidak akan disebut server.

Mesin fisik adalah komputer yang dipasang di rak x86. Paling sering kita menggunakan istilah host . Jadi kita akan menyebutnya " mesin " atau host .

Hypervisor adalah aplikasi yang berjalan pada mesin fisik yang mengemulasi sumber daya fisik yang dijalankan Mesin Virtual. Terkadang dalam literatur dan jaringan kata "hypervisor" digunakan sebagai sinonim untuk "host".

Mesin virtual adalah sistem operasi yang berjalan pada mesin fisik di atas hypervisor. Bagi kami, dalam kerangka siklus ini, tidak begitu penting apakah itu sebenarnya mesin virtual atau hanya sebuah wadah. Kami akan menyebutnya " VM "

Penyewa adalah konsep luas yang akan saya definisikan dalam artikel ini sebagai layanan terpisah atau klien terpisah.

Multi-tenancy atau multi-tenancy - penggunaan aplikasi yang sama oleh klien / layanan yang berbeda. Pada saat yang sama, isolasi klien dari satu sama lain dicapai karena arsitektur aplikasi, dan bukan contoh yang berjalan secara terpisah.

ToR - Top of the Rack switch - sakelar yang dipasang di rak yang terhubung dengan semua mesin fisik.
Selain topologi ToR, penyedia yang berbeda mempraktikkan End of Row (EoR) atau Middle of Row (meskipun yang terakhir adalah kelangkaan yang meremehkan dan saya belum melihat singkatan MoR).
Jaringan dasar atau jaringan dasar atau dasar - infrastruktur jaringan fisik: sakelar, router, kabel.

Overlay network atau overlay network atau overlay - jaringan virtual terowongan yang berjalan di atas yang fisik.

Pabrik L3 atau pabrik IP adalah penemuan luar biasa umat manusia, yang memungkinkan wawancara untuk tidak mengulangi STP dan tidak untuk belajar TRILL. Sebuah konsep di mana seluruh jaringan hingga tingkat akses secara eksklusif L3, tanpa VLAN dan domain siaran yang sangat luas. Dari mana asal kata "pabrik" di bagian selanjutnya.

SDN - Jaringan Buatan Perangkat Lunak. Hampir tidak membutuhkan pengantar. Suatu pendekatan untuk manajemen jaringan ketika perubahan pada jaringan tidak dilakukan oleh seseorang, tetapi oleh suatu program. Biasanya berarti memindahkan Control Plane di luar perangkat jaringan akhir ke controller.

NFV - Virtualisasi Fungsi Jaringan - virtualisasi perangkat jaringan, yang mengasumsikan bahwa bagian dari fungsi jaringan dapat diluncurkan dalam bentuk mesin atau wadah virtual untuk mempercepat implementasi layanan baru, mengorganisasikan Service Chaining dan skalabilitas horizontal yang lebih sederhana.

VNF - Fungsi Jaringan Virtual. Perangkat virtual spesifik: router, switch, firewall, NAT, IPS / IDS, dll.


Sekarang saya sengaja menyederhanakan deskripsi ke implementasi tertentu agar tidak membingungkan pembaca. Untuk bacaan yang lebih bijaksana, kirimkan ke bagian Tautan . Selain itu, Roma Gorge, yang mengkritik artikel ini karena ketidakakuratannya, berjanji untuk menulis masalah terpisah tentang teknologi virtualisasi server dan jaringan, lebih dalam dan lebih memperhatikan detail.


Sebagian besar jaringan saat ini dapat dengan jelas dibagi menjadi dua bagian:

Underlay - jaringan fisik dengan konfigurasi stabil.
Overlay - Abstraksi overlay untuk mengisolasi penyewa.

Ini berlaku baik untuk kasus DC (yang akan kami analisis dalam artikel ini) dan untuk ISP (yang tidak akan kami analisis, karena sudah ada di SDSM ). Dengan jaringan perusahaan, tentu saja, situasinya agak berbeda.

Gambar Fokus Jaringan:





Mendasari


Underlay adalah jaringan fisik: sakelar dan kabel perangkat keras. Perangkat yang ada di bawah tahu cara menuju ke mesin fisik.



Itu bergantung pada protokol dan teknologi standar. Paling tidak karena perangkat hardware masih bekerja pada perangkat lunak berpemilik yang tidak memungkinkan pemrograman chip atau implementasi protokol mereka, masing-masing, kompatibilitas dengan vendor lain dan standardisasi diperlukan.
Tetapi seseorang seperti Google mampu mengembangkan sakelar sendiri dan mengabaikan protokol yang diterima secara umum. Tapi LAN_DC bukan Google.
Underlay relatif jarang berubah, karena tugasnya adalah konektivitas IP dasar antara mesin fisik. Underlay tidak tahu apa-apa tentang layanan yang berjalan di atasnya, klien, penyewa - hanya perlu mengirimkan paket dari satu mesin ke mesin lain.
Underlay bisa seperti ini:

  • IPv4 + OSPF
  • IPv6 + ISIS + BGP + L3VPN
  • L2 + TRILL
  • L2 + STP

Jaringan Underlay dikonfigurasikan dengan cara klasik: CLI / GUI / NETCONF.

Secara manual, skrip, utilitas milik.

Secara lebih rinci, artikel selanjutnya dalam seri ini akan dikhususkan untuk lapisan bawah.


Hamparan


Overlay - jaringan terowongan virtual yang terbentang di Underlay, memungkinkan VMs dari satu klien untuk berkomunikasi satu sama lain, sambil memberikan isolasi dari klien lain.

Data klien dienkapsulasi dalam header tunneling apa pun untuk transmisi melalui jaringan bersama.



Jadi VMs dari satu klien (satu layanan) dapat berkomunikasi satu sama lain melalui Overlay, tanpa mengetahui apa sebenarnya paket tersebut.

Overlay dapat misalnya sama dengan yang saya sebutkan di atas:

  • Terowongan GRE
  • VXLAN
  • EVPN
  • L3VPN
  • GENEVE

Jaringan overlay biasanya dikonfigurasikan dan dikelola melalui pengontrol pusat. Dari sana, konfigurasi, Control Plane dan Data Plane dikirimkan ke perangkat yang merutekan dan merangkum lalu lintas klien. Di bawah ini kami akan menganalisis ini dengan contoh.

Ya, ini adalah SDN murni.

Ada dua pendekatan yang berbeda secara mendasar untuk mengatur jaringan Hamparan:

  1. Overlay dengan ToR
  2. Hamparan dari host


Overlay dengan ToR


Overlay dapat dimulai pada sakelar akses yang dipasang di rak (rack-mount access switch, ToR), seperti halnya, misalnya, dalam kasus pabrik VXLAN.

Ini adalah mekanisme yang telah teruji oleh waktu pada jaringan ISP dan semua vendor peralatan jaringan mendukungnya.

Namun, dalam kasus ini, switch ToR harus dapat berbagi layanan yang berbeda, masing-masing, dan administrator jaringan harus sedikit banyak bekerja sama dengan administrator mesin virtual dan membuat perubahan (walaupun secara otomatis) ke konfigurasi perangkat.



Di sini saya akan merujuk pembaca ke artikel tentang VxLAN di hub teman lama kami @bormoglotx .
Dalam presentasi ini dengan ENOG , pendekatan untuk pembangunan jaringan DC dengan pabrik EVPN VXLAN dijelaskan secara rinci.

Dan untuk perendaman yang lebih lengkap dalam kenyataan, Anda dapat membaca buku A Modern, Open, and Scalable Fabric: VXLAN EVPN .
Saya perhatikan bahwa VXLAN hanyalah metode enkapsulasi dan pemutusan terowongan tidak dapat terjadi pada ToR, tetapi pada host, seperti halnya dengan OpenStack, misalnya.

Namun, pabrik VXLAN tempat overlay dimulai pada ToR adalah salah satu desain jaringan overlay yang sudah mapan.

Hamparan dari host


Pendekatan lain adalah memulai dan mengakhiri terowongan pada host akhir.
Dalam hal ini, jaringan (Underlay) tetap sesederhana dan statis mungkin.
Dan tuan rumah itu sendiri melakukan semua enkapsulasi yang diperlukan.



Untuk melakukan ini, Anda tentu perlu menjalankan aplikasi khusus pada host, tetapi itu sepadan.

Pertama, menjalankan klien pada mesin linux lebih sederhana, atau, katakanlah, secara umum mungkin, saat beralih, Anda kemungkinan besar harus beralih ke solusi SDN eksklusif untuk saat ini, yang mematikan gagasan multi-vendor.

Kedua, sakelar ToR dalam hal ini dapat dibuat sesederhana mungkin, baik dari sudut pandang Control Plane dan Data Plane. Memang - maka dia tidak perlu berkomunikasi dengan pengontrol SDN, dan untuk menyimpan jaringan / ARP dari semua klien yang terhubung - juga - hanya tahu alamat IP dari mesin fisik, yang sangat menyederhanakan tabel switching / routing.


Dalam seri ADSM, saya memilih pendekatan overlay dari host - maka kita hanya membicarakannya dan kita tidak akan kembali ke pabrik VXLAN.


Cara termudah untuk mempertimbangkan contoh. Dan sebagai subjek uji, kami akan menggunakan platform OpenSource SDN OpenContrail, yang sekarang dikenal sebagai Tungsten Fabric .
Di akhir artikel saya akan memberikan beberapa pemikiran tentang analogi dengan OpenFlow dan OpenvSwitch.

Studi Kasus Kain Tungsten


Setiap mesin fisik memiliki vRouter - router virtual yang tahu tentang jaringan yang terhubung dengannya dan klien mana yang mereka miliki - bahkan - router PE. Untuk setiap klien, ia memelihara tabel routing yang terisolasi (baca VRF). Dan sebenarnya vRouter melakukan tunneling Overlay.

Lebih banyak tentang vRouter ada di akhir artikel.

Setiap VM yang terletak di hypervisor terhubung ke vRouter mesin ini melalui antarmuka TAP .

TAP - Terminal Access Point - antarmuka virtual dalam kernel linux yang memungkinkan jaringan.



Jika ada beberapa jaringan di belakang vRouter, maka antarmuka virtual dibuat untuk masing-masingnya, yang ditetapkan untuk alamat IP - itu akan menjadi alamat gateway default.
Semua jaringan dari satu klien ditempatkan dalam satu VRF (satu tabel), berbeda - beda.
Saya akan membuat reservasi di sini bahwa itu tidak begitu sederhana, dan mengirim pembaca yang ingin tahu ke akhir artikel .

Agar vRouter'y berkomunikasi satu sama lain, dan, sesuai dengan itu, VM yang berada di belakang mereka, mereka bertukar informasi routing melalui pengontrol SDN .



Untuk masuk ke dunia luar, ada titik keluar dari matriks - gateway jaringan virtual VNGW - GateWay Jaringan Virtual ( istilah saya ).




Sekarang perhatikan contoh-contoh komunikasi - dan akan ada kejelasan.


Komunikasi dalam satu mesin fisik


VM0 ingin mengirim paket ke VM2. Asumsikan untuk saat ini bahwa ini adalah VM klien tunggal.

Pesawat data


  1. VM-0 memiliki rute default di antarmuka eth0-nya. Paket dikirim ke sana.
    Antarmuka eth0 ini sebenarnya terhubung ke router virtual vRouter melalui antarmuka tap0 TAP.
  2. vRouter menganalisis antarmuka yang menjadi tujuan paket, yaitu, klien mana (VRF) miliknya, memeriksa alamat penerima dengan tabel routing klien ini.
  3. Setelah menemukan bahwa penerima pada mesin yang sama berada di belakang port yang berbeda, vRouter hanya mengirim paket ke sana tanpa header tambahan - dalam hal ini, vRouter sudah memiliki catatan ARP.



Paket dalam hal ini tidak masuk ke jaringan fisik - itu diarahkan di dalam vRouter.


Kontrol pesawat


Ketika mesin virtual dimulai, hypervisor memberitahunya:

  • Alamat IP-nya sendiri.
  • Rute default adalah melalui alamat IP vRouter di jaringan ini.

Melalui API khusus, hypervisor melaporkan ke vRouter:

  • Apa yang Anda butuhkan untuk membuat antarmuka virtual.
  • Yang mana (VM) perlu membuat Jaringan Virtual.
  • Ke mana VRF mengikatnya (VN).
  • Catatan ARP statis untuk VM ini adalah antarmuka yang memiliki alamat IP dan alamat MAC yang dilampirkan.

Dan lagi, prosedur interaksi yang sebenarnya disederhanakan demi memahami konsep.


Dengan demikian, semua VM dari satu klien pada mesin yang diberikan, vRouter melihat sebagai jaringan yang terhubung langsung dan dapat merutekan di antara mereka sendiri.


Tetapi VM0 dan VM1 milik klien yang berbeda, masing-masing, dalam tabel yang berbeda vRouter'a.

Apakah mereka dapat berkomunikasi satu sama lain secara langsung tergantung pada pengaturan vRouter dan desain jaringan.
Misalnya, jika VM kedua klien menggunakan alamat publik, atau NAT muncul pada vRouter itu sendiri, maka perutean langsung ke vRouter juga dapat dilakukan.

Dalam situasi yang berlawanan, dimungkinkan untuk melintasi ruang alamat - Anda harus melewati server NAT untuk mendapatkan alamat publik - ini mirip dengan mengakses jaringan eksternal, yang dijelaskan di bawah ini.



Komunikasi antara VM terletak di berbagai mesin fisik


Pesawat data


  1. Permulaannya persis sama: VM-0 mengirimkan paket dengan tujuan VM-7 (172.17.3.2) secara default.
  2. vRouter menerimanya dan kali ini melihat bahwa tujuan berada di komputer lain dan dapat diakses melalui terowongan Tunnel0.
  3. Pertama, ia menggantung label MPLS yang mengidentifikasi antarmuka jarak jauh, sehingga di bagian belakang vRouter dapat menentukan di mana menempatkan paket ini tanpa kait tambahan.


  4. Tunnel0 memiliki sumber 10.0.0.2, penerima: 10.0.1.2.
    vRouter menambahkan header GRE (atau UDP) dan IP baru ke paket aslinya.
  5. Tabel perutean vRouter memiliki rute default melalui alamat ToR1 10.0.0.1. Di sana dan mengirim.



  6. ToR1 sebagai anggota jaringan Underlay tahu (misalnya, melalui OSPF) cara mencapai 10.0.1.2, dan mengirimkan paket di sepanjang rute. Harap dicatat bahwa ECMP termasuk di sini. Dalam ilustrasi ada dua nexstops, dan aliran yang berbeda akan diletakkan di dalamnya oleh hash. Dalam kasus pabrik nyata, kemungkinan akan ada 4 nextops.

    Pada saat yang sama, ia tidak perlu tahu apa yang ada di bawah header IP eksternal. Faktanya, di bawah IP ada sandwich dari IPv6 melalui MPLS melalui Ethernet melalui MPLS lebih dari GRE lebih dari pada bahasa Yunani.
  7. Dengan demikian, di sisi penerima, vRouter menghapus GRE dan, menggunakan label MPLS, memahami antarmuka mana paket ini harus ditransmisikan ke, strip dan kirimkan ke penerima dalam bentuk aslinya.


Kontrol pesawat


Saat Anda memulai mesin, semua yang terjadi dijelaskan di atas.

Dan ditambah yang berikut ini:

  • Untuk setiap klien, vRouter mengalokasikan tag MPLS. Ini adalah label layanan L3VPN di mana pelanggan akan dibagi di mesin fisik yang sama.
    Sebenarnya, tag MPLS selalu dialokasikan oleh vRouter'om selalu - karena tidak diketahui sebelumnya bahwa mesin hanya akan berinteraksi dengan mesin lain di belakang vRouter'om yang sama dan ini kemungkinan besar tidak terjadi.
  • vRouter membuat koneksi dengan pengontrol SDN melalui BGP (atau serupa - dalam kasus TF, ini XMPP 0_o).
  • Melalui sesi ini, vRouter memberi tahu pengontrol SDN rute ke jaringan yang terhubung:

    • Alamat jaringan
    • Metode Enkapsulasi (MPLSoGRE, MPLSoUDP, VXLAN)
    • Label MPLS klien
    • Alamat IP Anda sebagai nexthop

  • Pengontrol SDN menerima rute tersebut dari semua vRouter'ov yang terhubung, dan mencerminkannya ke orang lain. Artinya, dia bertindak sebagai Route Reflector.

Hal yang sama terjadi pada arah yang berlawanan.



Hamparan dapat berubah setidaknya setiap menit. Sesuatu seperti ini terjadi di cloud publik, ketika klien secara teratur memulai dan mematikan mesin virtual mereka.

Pengontrol pusat menangani semua kesulitan mempertahankan konfigurasi dan mengendalikan tabel peralihan / perutean pada vRouter.

Secara kasar, controller dimatikan dengan semua vRouter melalui BGP (atau protokol yang serupa dengan itu) dan hanya mentransmisikan informasi routing. BGP, misalnya, sudah memiliki Keluarga Alamat untuk mentransmisikan metode enkapsulasi MPLS-in-GRE atau MPLS-in-UDP .

Pada saat yang sama, konfigurasi jaringan Underlay tidak berubah dengan cara apa pun, yang, secara kebetulan, jauh lebih sulit untuk diotomatisasi, dan lebih mudah untuk putus dengan gerakan yang canggung.



Keluar ke dunia luar


Di suatu tempat, simulasi harus berakhir, dan dari dunia virtual Anda harus masuk ke dunia nyata. Dan Anda memerlukan gateway telepon umum .

Dua pendekatan dipraktikkan:

  1. Perute perangkat keras diinstal.
  2. Sebuah alat diluncurkan yang mengimplementasikan fungsi router (ya, kami menghadapi VNF setelah SDN). Sebut saja gateway virtual.

— — . , , , , , , , , , .

, , , , ( ). , - , , — .
Dengan satu kaki, gateway melihat ke dalam jaringan virtual Overlay, seperti Mesin Virtual normal, dan dapat berinteraksi dengan semua VM lainnya. Pada saat yang sama, ia dapat mengakhiri sendiri semua jaringan klien dan, dengan demikian, melakukan perutean di antara mereka.

Dengan kaki yang lain, gateway sudah melihat jaringan backbone dan tahu bagaimana menuju ke Internet.




Pesawat data


Artinya, prosesnya terlihat seperti ini:

  1. VM-0, setelah default semua di vRouter yang sama, mengirim paket dengan tujuan di dunia luar (185.147.83.177) ke antarmuka eth0.
  2. vRouter menerima paket ini dan membuat pencarian alamat tujuan di tabel routing - ia menemukan rute default melalui gateway VNGW1 melalui Tunnel 1.
    Dia juga melihat bahwa ini adalah terowongan GRE dengan SIP 10.0.0.2 dan DIP 10.0.255.2, dan juga pertama-tama menutup MPLS- Label klien ini yang VNGW1 harapkan.
  3. vRouter mengemas paket asli dalam MPLS, GRE, dan header IP baru dan mengirimkannya ke ToR1 10.0.0.1 secara default.
  4. Jaringan underlay mengirimkan paket ke gateway VNGW1.
  5. Gateway VNGW1 menghapus header tunneling GRE dan MPLS, melihat alamat tujuan, berkonsultasi dengan tabel peruteannya, dan memahami bahwa itu diarahkan ke Internet - ini berarti melalui Tampilan Penuh atau Default. Jika perlu, lakukan terjemahan NAT.
  6. Dari VNGW ke perbatasan, mungkin ada jaringan IP biasa, yang sepertinya tidak mungkin.
    Ini bisa berupa jaringan MPLS klasik (IGP + LDP / RSVP TE), bisa berupa pabrik kembali dengan BGP LU, atau terowongan GRE dari VNGW ke perbatasan melalui jaringan IP.
    Meskipun demikian, VNGW1 melakukan enkapsulasi yang diperlukan dan mengirimkan paket asli ke perbatasan.



Lalu lintas di arah yang berlawanan melewati langkah yang sama dalam urutan yang berlawanan.

  1. VNGW1
  2. , , Tunnel1 (MPLSoGRE MPLSoUDP).
  3. , MPLS, GRE/UDP IP ToR3 10.0.255.1.
    — IP- vRouter', — 10.0.0.2.
  4. vRouter'.
  5. vRouter GRE/UDP, MPLS- IP- TAP-, eth0 .




Control Plane


VNGW1 menetapkan lingkungan BGP dengan pengontrol SDN, yang darinya ia menerima semua informasi perutean tentang klien: alamat IP (vRouter'om) mana yang menjadi klien, dan dengan label MPLS mana ia mengidentifikasi.

Demikian pula, ia sendiri memberi tahu pengendali SDN rute default dengan label klien ini, menunjukkan dirinya sebagai nexthop. Dan kemudian default ini datang ke vRouter'y.

VNGW biasanya agregasi rute atau terjemahan NAT.

Dan di arah yang berlawanan, dia memberikan rute agregat ini ke sesi dengan boarders atau Route Reflectors. Dan dari mereka menerima rute default atau Tampilan Penuh, atau sesuatu yang lain.

Dalam hal enkapsulasi dan pertukaran lalu lintas, VNGW tidak berbeda dengan vRouter.
Jika Anda sedikit memperluas area, Anda dapat menambahkan perangkat jaringan lain ke VNGW dan vRouter, seperti firewall, pemurnian lalu lintas atau peternakan pengayaan, IPS, dan sebagainya.

Dan dengan bantuan penciptaan VRF berturut-turut dan pengumuman rute yang benar, Anda dapat membuat perulangan lalu lintas sesuai keinginan, yang disebut dengan Chaining Layanan.

Yaitu, di sini SDN-controller bertindak sebagai Route-Reflector antara VNGW, vRouter'ami dan perangkat jaringan lainnya.

Namun pada kenyataannya, pengontrol juga merilis informasi tentang ACL dan PBR (Policy Based Routing), memaksa arus lalu lintas individual untuk pergi berbeda dari rute yang mereka minta.





Faq



Mengapa Anda selalu melakukan komentar GRE / UDP?

Secara umum, dapat dikatakan spesifik untuk Tungsten Fabric - Anda dapat mengabaikannya sama sekali.

Tetapi jika Anda mengambilnya, maka TF itu sendiri, sementara masih OpenContrail, mendukung kedua enkapsulasi: MPLS di GRE dan MPLS di UDP.

UDP bagus karena di Source Port di header-nya sangat mudah untuk kode fungsi hash dari IP + Proto + Port yang asli, yang akan memungkinkan penyeimbangan.

Dalam kasus GRE, sayangnya, hanya ada IP eksternal dan header GRE yang sama untuk semua lalu lintas yang dienkapsulasi dan tidak ada pembicaraan penyeimbangan - hanya sedikit orang yang dapat melihat begitu dalam di dalam paket.

Sampai suatu saat, router, jika mereka tahu cara menggunakan terowongan dinamis, hanya di MPLSoGRE, dan baru-baru ini, belajar di MPLSoUDP. Karena itu, Anda selalu harus membuat komentar tentang kemungkinan dua enkapsulasi yang berbeda.

Dalam keadilan, perlu dicatat bahwa TF sepenuhnya mendukung konektivitas L2 menggunakan VXLAN.


Anda berjanji untuk menggambar paralel dengan OpenFlow.
Mereka benar-benar memohon. vSwitch di OpenStack yang sama melakukan hal yang sangat mirip menggunakan VXLAN, yang, kebetulan, juga memiliki header UDP.

Di Data Plane mereka bekerja kurang lebih sama, Control Plane berbeda secara signifikan. Tungsten Fabric menggunakan XMPP untuk mengirimkan informasi rute ke vRouter, sementara Openflow bekerja di OpenStack.


Bisakah saya mendapat sedikit informasi tentang vRouter?
Ini dibagi menjadi dua bagian: Agen vRouter dan vRouter Forwarder.

Yang pertama diluncurkan di Ruang Pengguna OS host dan berkomunikasi dengan pengontrol SDN, bertukar informasi tentang rute, VRF, dan ACL.

Yang kedua mengimplementasikan Data Plane - biasanya di Kernel Space, tetapi juga dapat diluncurkan pada SmartNICs - kartu jaringan dengan CPU dan chip switching yang dapat diprogram terpisah, yang memungkinkan Anda untuk menghapus beban dari CPU mesin host, dan membuat jaringan lebih cepat dan lebih dapat diprediksi.

Skenario lain dimungkinkan ketika vRouter adalah aplikasi DPDK di Ruang Pengguna.

Agen vRouter menjatuhkan pengaturan pada vRouter Forwarder.


Apa itu Jaringan Virtual?
Saya sebutkan di awal artikel tentang VRF bahwa setiap penyewa melekat pada VRF-nya. Dan jika ini cukup untuk pemahaman yang dangkal tentang pekerjaan jaringan overlay, maka sudah pada iterasi berikutnya perlu untuk membuat klarifikasi.

Biasanya dalam mekanisme virtualisasi, entitas Jaringan Virtual (Anda dapat menganggapnya sebagai nama yang tepat) diperkenalkan secara terpisah dari klien / penyewa / mesin virtual - ini merupakan hal yang cukup independen. Dan Jaringan Virtual ini melalui antarmuka sudah dapat dihubungkan di satu penyewa, di yang lain, di dua, tapi setidaknya di mana. Jadi, misalnya, Service Chaining diimplementasikan, ketika lalu lintas harus dilewatkan melalui node tertentu dalam urutan yang diinginkan, cukup membuat dan menggunakan Jaringan Virtual dalam urutan yang benar.

Oleh karena itu, dengan demikian, tidak ada korespondensi langsung antara Jaringan Virtual dan penyewa.



Kesimpulan


Ini adalah deskripsi yang sangat dangkal dari operasi jaringan virtual dengan overlay dari host dan pengontrol SDN. Tetapi terlepas dari platform virtualisasi mana yang Anda gunakan hari ini, itu akan bekerja dengan cara yang sama, baik itu VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric atau Juniper Contrail. Mereka akan berbeda dalam jenis enkapsulasi dan header, protokol untuk mengirimkan informasi ke perangkat jaringan akhir, tetapi prinsip jaringan overlay yang disesuaikan dengan perangkat lunak yang bekerja di atas jaringan underlay yang relatif sederhana dan statis akan tetap sama.
Kita dapat mengatakan bahwa area menciptakan cloud pribadi hingga saat ini, SDN berdasarkan jaringan overlay telah dimenangkan. Namun, ini tidak berarti bahwa Openflow tidak memiliki tempat di dunia modern - ini digunakan di OpenStacke dan di VMWare NSX yang sama, sejauh yang saya tahu, Google menggunakannya untuk mengkonfigurasi jaringan yang mendasari.

Di bawah ini saya memberikan tautan ke materi yang lebih rinci, jika Anda ingin mempelajari masalah ini lebih dalam.

Dan apa yang mendasari kita?

Tetapi secara umum, tidak ada. Dia tidak berubah sepenuhnya. Yang perlu dia lakukan jika overlay dari tuan rumah adalah memperbarui rute dan ARP ketika vRouter / VNGW muncul dan menghilang dan menyeret paket di antara mereka.

Mari kita merumuskan daftar persyaratan untuk jaringan Underlay.

  1. Untuk dapat menggunakan beberapa protokol routing, dalam situasi kami - BGP.
  2. , , - .
  3. ECMP — .
  4. QoS, , ECN.
  5. NETCONF — .

Saya mencurahkan sangat sedikit waktu di sini untuk pekerjaan jaringan Underlay itu sendiri. Ini karena nanti dalam seri saya akan fokus padanya, dan kami akan menyentuh Overlay hanya secara sepintas.

Jelas, saya sangat membatasi kita semua, menggunakan sebagai contoh jaringan DC yang dibangun di pabrik Klose dengan routing IP murni dan overlay dari host.

Namun, saya yakin bahwa jaringan apa pun yang memiliki desain dapat dijelaskan secara formal dan otomatis. Hanya saja saya mengejar tujuan untuk memahami pendekatan untuk otomatisasi, dan tidak membingungkan semua orang, menyelesaikan masalah secara umum.

Sebagai bagian dari ADSM, Roman Gorge dan saya berencana untuk menerbitkan masalah terpisah tentang virtualisasi daya komputasi dan interaksinya dengan virtualisasi jaringan. Tetap berkomunikasi.


Tautan yang bermanfaat



Terima kasih

  • Roman Gorge , mantan pembawa acara utama podcast linkmeup, dan sekarang menjadi pakar di bidang platform cloud. Untuk komentar dan pengeditan. Nah, kami menantikan artikel yang lebih dalam tentang virtualisasi dalam waktu dekat.
  • Alexander Shalimov , kolega dan pakar saya dalam pengembangan jaringan virtual. Untuk komentar dan pengeditan.
  • Valentina Sinitsyna , kolega saya dan pakar Tungsten Fabric. Untuk komentar dan pengeditan.
  • Artyom Chernobay - ilustrator linkmeup. Untuk KDPV.
  • Alexander Limonov. Untuk meme "automato".

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

More articles:


All Articles