Komputasi awan menembus semakin dalam ke dalam kehidupan kita, dan mungkin tidak ada satu orang pun yang belum menggunakan layanan awan setidaknya sekali. Namun, apa itu awan dan bagaimana cara kerjanya sebagian besar, hanya sedikit orang yang tahu bahkan pada tingkat gagasan. 5G sudah menjadi kenyataan dan infrastruktur telekomunikasi mulai beralih dari solusi pilar ke solusi cloud, seperti ketika ia beralih dari solusi besi sepenuhnya ke "pilar" virtual.
Hari ini kita akan berbicara tentang dunia dalam infrastruktur cloud, khususnya, kami akan menganalisis dasar-dasar bagian jaringan.
Apa itu awan? Virtualisasi yang sama - tampilan profil?
Lebih dari pertanyaan logis. Tidak - ini bukan virtualisasi, meskipun bukan tanpa itu. Pertimbangkan dua definisi:
Komputasi awan (selanjutnya disebut Cloud) adalah model untuk menyediakan akses yang mudah digunakan ke sumber daya komputasi terdistribusi yang harus diterapkan dan diluncurkan sesuai permintaan dengan latensi serendah mungkin dan biaya minimum dari penyedia layanan (terjemahan definisi dari NIST).
Virtualisasi- ini adalah kemampuan untuk membagi satu entitas fisik (misalnya, server) menjadi beberapa entitas virtual, sehingga meningkatkan pemanfaatan sumber daya (misalnya, Anda memiliki 3 server yang dimuat sebesar 25-30 persen, setelah virtualisasi Anda mendapatkan 1 server dimuat sebesar 80-90 persen). Secara alami, virtualisasi memakan beberapa sumber daya - Anda perlu memberi makan hypervisor, namun, seperti yang ditunjukkan oleh praktik, permainan ini sepadan. Contoh ideal virtualisasi adalah VMWare, yang menyiapkan mesin virtual dengan sempurna, atau misalnya KVM, yang saya sukai, tetapi ini sudah masalah selera.
Kami sendiri menggunakan virtualisasi tanpa menyadarinya, dan bahkan router besi sudah menggunakan virtualisasi - misalnya, dalam versi terbaru JunOS, sistem operasi diinstal sebagai mesin virtual di atas kit distribusi linux waktu nyata (Wind River 9). Tetapi virtualisasi bukanlah cloud, tetapi cloud tidak dapat ada tanpa virtualisasi.
Virtualisasi adalah salah satu blok bangunan tempat cloud dibangun.
Ini tidak akan berhasil untuk membuat cloud hanya dengan mengumpulkan beberapa hypervisor ke dalam satu domain L2, menambahkan beberapa buku pedoman yaml untuk mendaftarkan vlan secara otomatis melalui beberapa yang mungkin dan mengisinya dengan sesuatu seperti sistem orkestrasi untuk membuat mesin virtual secara otomatis. Lebih tepatnya, itu akan berubah, tetapi Frankenstein yang dihasilkan bukanlah awan yang kita butuhkan, meskipun sebagai orang lain, mungkin bagi seseorang ini adalah impian terakhir. Selain itu, jika Anda menggunakan Openstack yang sama - pada kenyataannya, itu masih Frankenstein, tapi oh baiklah, mari kita tidak membicarakannya dulu.
Tapi saya mengerti bahwa dari definisi di atas tidak sepenuhnya jelas apa yang sebenarnya bisa disebut awan.
Oleh karena itu, dokumen dari NIST (National Institute of Standards and Technology) mencantumkan 5 karakteristik utama yang harus dimiliki infrastruktur cloud:
Penyediaan layanan berdasarkan permintaan. Pengguna harus diberi akses gratis ke sumber daya komputer yang dialokasikan untuknya (seperti jaringan, disk virtual, memori, inti prosesor, dll.), Dan sumber daya ini harus disediakan secara otomatis - yaitu, tanpa intervensi dari penyedia layanan.
Ketersediaan layanan yang luas. Akses ke sumber daya harus disediakan oleh mekanisme standar untuk dapat menggunakan PC standar dan klien kecil serta perangkat seluler.
Pengumpulan sumber daya.Kumpulan sumber daya harus dapat menyediakan sumber daya untuk banyak klien pada saat yang sama, memastikan isolasi klien dan tidak adanya pengaruh timbal balik dan pertentangan untuk sumber daya. Jaringan juga termasuk dalam kumpulan, yang menunjukkan kemungkinan menggunakan pengalamatan yang tumpang tindih. Pool harus berskala sesuai permintaan. Penggunaan kumpulan memungkinkan penyediaan tingkat ketahanan sumber daya yang diperlukan dan abstraksi sumber daya fisik dan virtual - penerima layanan hanya diberikan kumpulan sumber daya yang diminta (di mana sumber daya ini ditempatkan secara fisik, pada berapa banyak server dan sakelar - klien tidak peduli). Namun, seseorang harus memperhitungkan fakta bahwa penyedia harus memastikan reservasi sumber daya ini secara transparan.
Adaptasi cepat untuk berbagai kondisi.Layanan harus fleksibel - penyediaan sumber daya yang cepat, realokasi mereka, penambahan atau pengurangan sumber daya atas permintaan klien, dan klien harus merasa bahwa sumber daya cloud tidak terbatas. Untuk memudahkan pemahaman, misalnya, Anda tidak melihat peringatan bahwa sebagian dari ruang disk di Apple iCloud Anda telah hilang karena hard drive di server rusak, dan disk rusak. Selain itu, dari sisi Anda, kemungkinan layanan ini hampir tidak terbatas - Anda perlu 2 TB - tidak masalah, Anda dibayar dan diterima. Demikian pula, Anda bisa memberi contoh dengan Google.Drive atau Yandex.Disk.
Kemampuan untuk mengukur layanan yang diberikan.Sistem cloud harus secara otomatis mengontrol dan mengoptimalkan sumber daya yang dikonsumsi, sementara mekanisme ini harus transparan bagi pengguna dan penyedia layanan. Artinya, Anda selalu dapat memeriksa berapa banyak sumber daya yang Anda dan pelanggan Anda konsumsi.
Perlu dipertimbangkan fakta bahwa persyaratan ini sebagian besar merupakan persyaratan untuk awan publik, oleh karena itu, untuk awan pribadi (yaitu, awan yang diluncurkan untuk kebutuhan internal perusahaan) persyaratan ini dapat sedikit disesuaikan. Namun, mereka masih harus dieksekusi, jika tidak kita tidak akan mendapatkan semua keuntungan dari komputasi awan.
Mengapa kita membutuhkan cloud?
Namun, teknologi baru atau yang sudah ada, protokol baru dibuat untuk sesuatu (yah, kecuali RIP-ng, tentu saja). Protokol demi protokol - tidak ada yang membutuhkannya (yah, kecuali untuk RIP-ng, tentu saja). Adalah logis bahwa Cloud dibuat untuk menyediakan beberapa jenis layanan kepada pengguna / klien. Kita semua sudah familiar dengan setidaknya beberapa layanan cloud, seperti Dropbox atau Google.Docs, dan saya yakin kebanyakan dari mereka berhasil menggunakannya - misalnya, artikel ini ditulis menggunakan layanan cloud Google.Docs. Namun layanan cloud yang kami tahu hanyalah sebagian dari kapabilitas cloud - lebih tepatnya, ini hanya layanan jenis SaaS. Kami dapat menyediakan layanan cloud dengan tiga cara: dalam bentuk SaaS, PaaS atau IaaS. Layanan apa yang Anda butuhkan tergantung pada keinginan dan kemampuan Anda.
Mari pertimbangkan masing-masing secara berurutan:
Software as a Service (SaaS) adalah model untuk menyediakan layanan lengkap kepada klien, misalnya, layanan email seperti Yandex.Mail atau Gmail. Dalam model penyampaian layanan seperti itu, Anda, sebagai klien, sebenarnya tidak melakukan apa pun kecuali menggunakan layanan - artinya, Anda tidak perlu memikirkan untuk menyiapkan layanan, toleransi kesalahannya, atau reservasi. Hal utama adalah jangan membahayakan kata sandi Anda, penyedia layanan ini akan melakukan sisanya untuk Anda. Dari sudut pandang penyedia layanan, ia bertanggung jawab penuh atas seluruh layanan - mulai dari perangkat keras server dan sistem operasi host hingga pengaturan basis data dan perangkat lunak.
Platform sebagai Layanan (PaaS)- saat menggunakan model ini, penyedia layanan menyediakan klien dengan template untuk layanan tersebut, misalnya, server Web. Penyedia layanan menyediakan klien dengan server virtual (pada kenyataannya, satu set sumber daya, seperti RAM / CPU / Storage / Nets, dll.), Dan bahkan menginstal OS dan perangkat lunak yang diperlukan di server ini, tetapi klien sendiri yang mengkonfigurasi semua hal ini dan untuk kinerja layanan sudah jawaban klien. Penyedia layanan, seperti dalam kasus sebelumnya, bertanggung jawab atas pengoperasian peralatan fisik, hypervisor, mesin virtual itu sendiri, ketersediaan jaringannya, dll., Tetapi layanan itu sendiri sudah berada di luar area tanggung jawabnya.
Infrastructure as a Service (IaaS)- pendekatan ini sudah lebih menarik, pada kenyataannya, penyedia layanan menyediakan klien dengan infrastruktur virtual yang lengkap - yaitu, beberapa jenis kumpulan (kumpulan) sumber daya, seperti CPU Core, RAM, Jaringan, dll. Segala sesuatu yang lain terserah klien - apa yang ingin dilakukan klien dengan ini sumber daya dalam kumpulan yang dialokasikan (kuota) - pemasok tidak terlalu penting. Klien ingin membuat vEPC sendiri atau bahkan membuat operator mini dan menyediakan layanan komunikasi - tidak perlu dipertanyakan lagi - lakukan. Dalam skenario seperti itu, penyedia layanan bertanggung jawab atas penyediaan sumber daya, toleransi kesalahan dan ketersediaan mereka, serta untuk OS yang memungkinkan Anda menggabungkan sumber daya ini ke dalam kumpulan dan menyediakannya kepada klien dengan kemampuan untuk menambah atau mengurangi sumber daya kapan saja atas permintaan klien. Klien mengkonfigurasi semua mesin virtual dan perada lain sendiri melalui portal dan konsol swalayan,termasuk pendaftaran jaringan (kecuali jaringan eksternal).
Apa itu OpenStack?
Di ketiga opsi tersebut, penyedia layanan memerlukan OS yang akan mengaktifkan infrastruktur cloud. Faktanya, dalam SaaS, tidak ada satu departemen pun yang bertanggung jawab atas seluruh tumpukan tumpukan teknologi ini - ada departemen yang bertanggung jawab atas infrastruktur - yaitu menyediakan IaaS ke departemen lain, departemen ini menyediakan klien SaaS. OpenStack adalah salah satu sistem operasi cloud yang memungkinkan Anda mengumpulkan sekumpulan sakelar, server, dan sistem penyimpanan ke dalam satu kumpulan sumber daya, membagi kumpulan umum ini menjadi sub-kumpulan (penyewa), dan menyediakan sumber daya ini kepada klien melalui jaringan.
OpenstackAdalah sistem operasi cloud yang memungkinkan Anda mengontrol kumpulan besar sumber daya komputasi, penyimpanan data, dan sumber daya jaringan, penyediaan dan pengelolaannya dilakukan melalui API menggunakan mekanisme otentikasi standar.
Dengan kata lain, ini adalah sekumpulan proyek perangkat lunak gratis yang dirancang untuk membuat layanan cloud (baik publik maupun privat) - yaitu, seperangkat alat yang memungkinkan Anda untuk menggabungkan server dan mengganti peralatan ke dalam satu kumpulan sumber daya, mengelola sumber daya ini, memberikan tingkat toleransi kesalahan yang diperlukan ...
Pada saat penulisan ini, struktur OpenStack terlihat seperti ini:
Gambar diambil dari openstack.org
Setiap komponen yang membentuk OpenStack melakukan fungsi tertentu. Arsitektur terdistribusi ini memungkinkan Anda untuk memasukkan kumpulan komponen fungsional yang Anda butuhkan ke dalam solusi. Namun, beberapa komponen adalah komponen root dan penghapusannya akan menyebabkan solusi seluruhnya atau sebagian tidak dapat dioperasikan secara keseluruhan. Merupakan kebiasaan untuk merujuk pada komponen-komponen seperti itu:
- Dashboard - GUI berbasis web untuk mengelola layanan OpenStack
- Keystone adalah layanan identitas terpusat yang menyediakan fungsi otentikasi dan otorisasi untuk layanan lain, serta mengelola kredensial dan peran pengguna.
- Neutron — , OpenStack ( VM )
- Cinder —
- Nova —
- Glance —
- Swift —
- Ceilometer — ,
- Heat —
Daftar lengkap semua proyek dan tujuannya dapat ditemukan di sini .
Setiap komponen OpenStack adalah layanan yang bertanggung jawab untuk fungsi tertentu dan menyediakan API untuk mengelola fungsi tersebut dan untuk mengkomunikasikan layanan tersebut dengan layanan sistem operasi cloud lainnya untuk membuat infrastruktur terpadu. Misalnya, Nova menyediakan manajemen sumber daya komputasi dan API untuk mengakses konfigurasi sumber daya ini, Glance menyediakan manajemen gambar dan API untuk mengelolanya, Cinder menyediakan penyimpanan blok dan API untuk mengelolanya, dan seterusnya. Semua fungsi saling berhubungan dengan sangat erat.
Namun, jika Anda menilai, maka semua layanan yang berjalan di OpenStack pada akhirnya adalah semacam mesin virtual (atau wadah) yang terhubung ke jaringan. Muncul pertanyaan - mengapa kita membutuhkan begitu banyak elemen?
Mari kita bahas algoritma untuk membuat mesin virtual dan menghubungkannya ke jaringan dan penyimpanan persisten di Openstack.
- Saat Anda membuat permintaan untuk membuat mesin, apakah itu permintaan melalui Horizon (Dasbor) atau permintaan melalui CLI, hal pertama yang terjadi adalah otorisasi permintaan Anda untuk Keystone - dapatkah Anda membuat mesin, memiliki atau hak untuk menggunakan jaringan ini, apakah Anda sudah cukup draf kuota, dll.
- Keystone mengautentikasi permintaan Anda dan menghasilkan token autentikasi dalam pesan respons, yang akan digunakan nanti. Setelah menerima respon dari Keystone, permintaan tersebut dikirim ke Nova (nova api).
- Nova-api , Keystone, auth-
- Keystone auth- .
- Nova-api nova-database VM nova-scheduler.
- Nova-scheduler ( ), VM , . VM nova-database.
- nova-scheduler nova-compute . Nova-compute nova-conductor (nova-conductor nova, nova-database nova-compute, nova-database ).
- Nova-conductor nova-database nova-compute.
- nova-compute glance ID . Glace Keystone .
- Nova-compute neutron . glance, neutron Keystone, database ( ), nova-compute.
- Nova-compute cinder volume. glance, cider Keystone, volume .
- Nova-compute libvirt .
Faktanya, operasi yang tampaknya sederhana untuk membuat mesin virtual sederhana berubah menjadi pusaran panggilan api antara elemen platform cloud. Selain itu, seperti yang Anda lihat, bahkan layanan yang telah ditetapkan sebelumnya juga terdiri dari komponen yang lebih kecil, yang di antaranya terjadi interaksi. Membuat mesin hanyalah sebagian kecil dari apa yang diberikan platform cloud kepada Anda - ada layanan yang bertanggung jawab untuk menyeimbangkan lalu lintas, layanan yang bertanggung jawab atas penyimpanan blok, layanan yang bertanggung jawab untuk DNS, layanan yang bertanggung jawab untuk menyediakan server logam kosong, dll. Cloud memungkinkan Anda memperlakukan mesin virtual Anda seperti sekawanan domba (bukan virtualisasi). Jika sesuatu terjadi pada mesin Anda di lingkungan virtual - Anda memulihkannya dari cadangan, dll., Aplikasi awan dibuat dengan cara ini,sehingga mesin virtual tidak memainkan peran penting - mesin virtual "mati" - tidak masalah - mesin baru hanya dibuat berdasarkan template dan, seperti yang mereka katakan, pasukan tidak menyadari hilangnya seorang prajurit. Biasanya, ini menyediakan mekanisme orkestrasi - menggunakan template Heat, Anda dapat dengan mudah menerapkan fungsi kompleks yang terdiri dari lusinan jaringan dan mesin virtual tanpa masalah.
Perlu diingat bahwa tidak ada infrastruktur cloud tanpa jaringan - setiap elemen dengan satu atau lain cara berinteraksi dengan elemen lain melalui jaringan. Selain itu, cloud memiliki jaringan yang sepenuhnya non-statis. Secara alami, jaringan underlay bahkan lebih atau kurang statis - node dan sakelar baru tidak ditambahkan setiap hari, namun, komponen overlay dapat dan pasti akan berubah terus-menerus - jaringan baru akan ditambahkan atau dihapus, mesin virtual baru muncul dan yang lama mati. Dan seperti yang Anda ingat dari definisi awan, yang diberikan di awal artikel, sumber daya harus dialokasikan ke pengguna secara otomatis dan dengan sedikit (atau lebih baik tanpa) intervensi dari penyedia layanan. Artinya, jenis penyediaan sumber daya jaringan,yang sekarang dalam bentuk frontend dalam bentuk akun pribadi Anda dapat diakses melalui http / https dan teknisi jaringan bertugas Vasily sebagai backend - ini bukan awan, meskipun Vasily memiliki delapan tangan.
Neutron, sebagai layanan jaringan, menyediakan API untuk mengelola porsi jaringan infrastruktur cloud. Layanan ini menyediakan kesehatan dan pengelolaan bagian jaringan Openstack dengan menyediakan lapisan abstraksi yang disebut Network-as-a-Service (NaaS). Artinya, jaringan adalah unit terukur virtual yang sama dengan, misalnya, inti virtual CPU atau RAM.
Tetapi sebelum beralih ke arsitektur jaringan OpenStack, mari kita lihat cara kerja jaringan OpenStack dan mengapa jaringan merupakan bagian penting dan integral dari awan.
Jadi, kami memiliki dua mesin virtual klien RED dan dua mesin virtual klien HIJAU. Misalkan mesin ini terletak di dua hypervisor seperti ini:
Saat ini, ini hanya virtualisasi 4 server dan tidak lebih, karena sejauh ini yang kami lakukan hanyalah virtualisasi 4 server, menempatkannya di dua server fisik. Dan sejauh ini mereka bahkan tidak terhubung ke jaringan.
Untuk mendapatkan cloud, kita perlu menambahkan beberapa komponen. Pertama, kami memvirtualisasikan bagian jaringan - kami perlu menghubungkan 4 mesin ini secara berpasangan, dan klien menginginkan koneksi L2. Anda dapat menggunakan sakelar dan mengatur trunk ke arahnya dan mengelola semuanya menggunakan jembatan linux, atau untuk pengguna openvswitch yang lebih mahir (kami akan kembali ke sana). Tetapi bisa ada banyak jaringan, dan terus-menerus mendorong L2 melalui sakelar bukanlah ide terbaik - divisi yang berbeda, meja layanan, menunggu berbulan-bulan untuk pelaksanaan aplikasi, berminggu-minggu pemecahan masalah - pendekatan ini tidak lagi berfungsi di dunia modern. Dan semakin cepat perusahaan menyadari hal ini, semakin mudah untuk bergerak maju. Oleh karena itu, di antara hypervisor, kami akan memilih jaringan L3 yang akan digunakan mesin virtual kami untuk berkomunikasi, dan di atas jaringan L3 ini kami akan membangun jaringan L2 (overlay) yang ditumpangkan secara virtual,tempat lalu lintas mesin virtual kami akan berjalan. GRE, Geneve, atau VxLAN dapat digunakan sebagai enkapsulasi. Mari kita bahas yang terakhir untuk saat ini, meskipun itu tidak terlalu penting.
Kita perlu mencari VTEP di suatu tempat (saya harap semua orang sudah familiar dengan terminologi VxLAN). Karena jaringan L3 segera meninggalkan server, tidak ada yang menghalangi kami untuk menempatkan VTEP di server itu sendiri, dan OVS (OpenvSwitch) dapat melakukannya dengan sempurna. Hasilnya, kami mendapatkan konstruksi berikut:
Karena lalu lintas antar VM harus dibagi, port menuju mesin virtual akan memiliki nomor vlan yang berbeda. Nomor tag hanya berperan dalam satu sakelar virtual, karena saat mengenkapsulasi di VxLAN kami dapat menghapusnya tanpa masalah, karena kami akan memiliki VNI.
Sekarang kita dapat membuat mesin dan jaringan virtual kita untuk mereka tanpa masalah.
Namun, bagaimana jika klien memiliki komputer lain, tetapi berada di jaringan yang berbeda? Kami membutuhkan rooting antar jaringan. Kami akan menganalisis opsi sederhana ketika rooting terpusat digunakan - yaitu, lalu lintas dialihkan melalui node jaringan khusus khusus (yah, sebagai aturan, mereka digabungkan dengan node kontrol, jadi kami akan memiliki hal yang sama).
Tampaknya tidak ada yang rumit - kami membuat antarmuka jembatan pada node kontrol, mengarahkan lalu lintas ke sana dan dari sana mengarahkannya ke tempat yang kami butuhkan. Tetapi masalahnya adalah bahwa klien RED ingin menggunakan jaringan 10.0.0.0/24 dan klien GREEN ingin menggunakan jaringan 10.0.0.0/24. Artinya, persimpangan ruang alamat dimulai. Selain itu, klien tidak ingin klien lain dirutekan ke jaringan internal mereka, yang logis. Untuk memisahkan jaringan dan lalu lintas data pelanggan, kami akan mengalokasikan namespace terpisah untuk masing-masing. Namespace sebenarnya adalah salinan dari tumpukan jaringan Linux, yaitu, klien di namespace RED sepenuhnya diisolasi dari klien dari namespace HIJAU (baik, perutean antara jaringan klien ini diizinkan melalui namespace default atau sudah ada di peralatan transportasi hulu).
Artinya, kami mendapatkan skema berikut:
Terowongan L2 bertemu dari semua node komputasi ke node kontrol. node tempat antarmuka L3 untuk jaringan ini berada, masing-masing dalam namespace khusus untuk isolasi.
Namun, kami telah melupakan hal terpenting. Mesin virtual harus menyediakan layanan kepada klien, yaitu harus memiliki setidaknya satu antarmuka eksternal yang dapat digunakan untuk menjangkaunya. Artinya, kita perlu pergi ke dunia luar. Ada beberapa opsi berbeda di sini. Mari buat opsi paling sederhana. Mari tambahkan klien di satu jaringan, yang akan valid di jaringan penyedia dan tidak akan tumpang tindih dengan jaringan lain. Jaringan juga dapat berpotongan dan melihat VRF yang berbeda di sisi jaringan penyedia. Jaringan ini juga akan hidup di ruang nama setiap klien. Namun, mereka masih akan pergi ke dunia luar melalui satu antarmuka fisik (atau ikatan, yang lebih logis). Untuk memisahkan lalu lintas klien, lalu lintas keluar akan diberi tag dengan tag VLAN yang ditetapkan ke klien.
Hasilnya, kami mendapatkan skema berikut:
Sebuah pertanyaan yang masuk akal - mengapa tidak membuat gateway pada node komputasi itu sendiri? Ini bukan masalah besar, apalagi ketika Anda menyalakan Distributed Router (DVR) akan berfungsi seperti itu. Dalam skenario ini, kami mempertimbangkan opsi paling sederhana dengan gateway terpusat, yang merupakan default di Openstack. Untuk fungsi beban tinggi, mereka akan menggunakan router terdistribusi dan teknologi akselerasi seperti SR-IOV dan Passthrough, tetapi seperti yang mereka katakan, ini adalah cerita yang sama sekali berbeda. Pertama, mari kita bahas bagian dasarnya, lalu masuk ke detailnya.
Sebenarnya, skema kami sudah beroperasi, tetapi ada beberapa nuansa:
- Kita perlu melindungi mesin kita, yaitu, menggantungkan filter pada antarmuka sakelar ke klien.
- Memungkinkan mesin virtual untuk mendapatkan alamat ip secara otomatis sehingga Anda tidak perlu memasukkannya setiap saat melalui konsol dan mendaftarkan alamatnya.
Mari kita mulai dengan melindungi mesin. Untuk ini, Anda dapat menggunakan iptables dangkal, mengapa tidak.
Artinya, sekarang topologi kita menjadi sedikit lebih rumit:
Mari melangkah lebih jauh. Kita perlu menambahkan server DHCP. Tempat paling ideal untuk lokasi server DHCP untuk setiap klien adalah node kontrol yang telah disebutkan di atas, di mana namespace berada:
Namun, ada sedikit masalah. Bagaimana jika semuanya reboot dan semua informasi sewa alamat DHCP menghilang. Adalah logis bahwa alamat baru akan diberikan ke mesin, yang sangat tidak nyaman. Ada dua cara di sini - baik menggunakan nama domain dan menambahkan server DNS untuk setiap klien, maka alamatnya tidak akan menjadi sangat penting bagi kami (dengan analogi dengan bagian jaringan di k8s) - tetapi ada masalah dengan jaringan eksternal, karena alamat juga dapat dikeluarkan di dalamnya melalui DHCP - Anda perlu melakukan sinkronisasi dengan server DNS di platform cloud dan server DNS eksternal, yang, menurut saya, tidak terlalu fleksibel, tetapi sangat mungkin. Atau opsi kedua adalah menggunakan metadata - yaitu, menyimpan informasi tentang alamat yang dikeluarkan untuk mesin sehingga server DHCP mengetahui alamat mana yang akan dikeluarkan untuk mesin jika mesin telah menerima sebuah alamat. Opsi kedua lebih sederhana dan lebih fleksibel, karena memungkinkan Anda menyimpan informasi tambahan tentang mobil.Sekarang tambahkan metadata agen ke skema:
Masalah lain yang juga harus dikuduskan adalah kemampuan untuk menggunakan satu jaringan eksternal untuk semua klien, karena jaringan eksternal, jika mereka ingin berlaku di seluruh jaringan, akan ada kerumitan - Anda harus terus mengalokasikan dan mengontrol alokasi jaringan ini. Kemampuan untuk menggunakan satu jaringan eksternal yang telah dikonfigurasi sebelumnya untuk semua klien akan sangat berguna saat membuat cloud publik. Ini akan mempermudah penerapan mesin, karena kita tidak perlu memeriksa database alamat dan memilih ruang alamat unik untuk setiap jaringan eksternal klien. Selain itu, kami dapat mendaftarkan jaringan eksternal sebelumnya dan pada saat penerapan kami hanya perlu mengaitkan alamat eksternal dengan mesin klien.
Dan di sini NAT datang untuk menyelamatkan - kami hanya memungkinkan klien untuk pergi ke dunia luar melalui namespace default menggunakan terjemahan NAT. Nah, inilah sedikit masalahnya. Baik jika server klien bertindak sebagai klien dan bukan sebagai server - yaitu, ia memulai daripada menerima koneksi. Tetapi bagi kami itu akan menjadi sebaliknya. Dalam hal ini, kita perlu melakukan NAT tujuan agar ketika menerima lalu lintas, node kontrol memahami bahwa lalu lintas ini ditujukan untuk mesin virtual A klien A, yang berarti kita perlu melakukan terjemahan NAT dari alamat eksternal, misalnya 100.1.1.1 ke alamat internal 10.0.0.1. Dalam kasus ini, meskipun semua klien akan menggunakan jaringan yang sama, isolasi internal sepenuhnya dipertahankan. Artinya, kita perlu membuat dNAT dan sNAT pada node kontrol.Gunakan satu jaringan dengan alokasi alamat mengambang atau jaringan eksternal, atau keduanya sekaligus - karena Anda ingin menyeret ke cloud. Kami tidak akan menambahkan alamat mengambang ke diagram, tetapi kami akan meninggalkan jaringan eksternal yang telah ditambahkan sebelumnya - setiap klien memiliki jaringan eksternal sendiri (dalam diagram, mereka ditetapkan sebagai vlan 100 dan 200 pada antarmuka eksternal).
Hasilnya, kami mendapatkan solusi yang menarik dan pada saat yang sama dipikirkan dengan matang, yang memiliki fleksibilitas tertentu, tetapi sejauh ini tidak memiliki mekanisme toleransi kesalahan.
Pertama, kami hanya memiliki satu node kontrol - kegagalannya akan menyebabkan runtuhnya semua sistem. Untuk memperbaiki masalah ini, Anda harus membuat setidaknya kuorum dari 3 node. Mari tambahkan ini ke diagram:
Secara alami, semua node disinkronkan dan ketika node aktif keluar, node lain akan mengambil alih tanggung jawabnya.
Masalah berikutnya adalah disk mesin virtual. Saat ini, mereka disimpan di hypervisor itu sendiri, dan jika terjadi masalah dengan hypervisor, kami kehilangan semua data - dan kehadiran penggerebekan tidak akan membantu dengan cara apa pun jika kami tidak kehilangan disk, tetapi seluruh server. Untuk melakukan ini, kita perlu membuat layanan yang akan bertindak sebagai antarmuka untuk beberapa penyimpanan. Jenis penyimpanan apa itu tidak terlalu penting bagi kami, tetapi itu harus melindungi data kami dari kegagalan disk dan node, dan mungkin seluruh kabinet. Ada beberapa opsi di sini - tentu saja, jaringan SAN dengan Fibre Channel, tetapi jujur saja - FC sudah menjadi peninggalan masa lalu - analog dari E1 dalam transportasi - ya, saya setuju, itu masih digunakan, tetapi hanya di tempat yang sama sekali tidak mungkin tanpanya. Oleh karena itu, saya tidak akan secara sukarela menerapkan jaringan FC pada tahun 2020, karena mengetahui ada alternatif lain yang lebih menarik.Meskipun untuk masing-masing miliknya dan mungkin akan ada orang yang percaya bahwa FC dengan segala keterbatasannya adalah yang kita butuhkan - saya tidak akan membantah, setiap orang memiliki pendapat mereka sendiri. Namun solusi yang paling menarik menurut saya adalah menggunakan SDS misalnya Ceph.
Ceph memungkinkan Anda membangun solusi penyimpanan vyskodostupnoe dengan sekumpulan opsi untuk redundansi, karena paritas kode (serangan analog 5 atau 6) diakhiri dengan replikasi penuh data melalui beberapa server lokasi disk berbasis disk, dan server di lemari dan sebagainya.
Untuk Perakitan Ceph membutuhkan 3 node lagi. Interaksi dengan penyimpanan juga akan dilakukan melalui jaringan menggunakan layanan penyimpanan blok, objek, dan file. Tambahkan penyimpanan ke skema:
: compute — — storage+compute — ceph storage. — SDS . — — storage ( ) — CPU SDS ( , , ). compute storage.Semua hal ini perlu dikelola entah bagaimana - kita membutuhkan sesuatu yang melaluinya kita dapat membuat mesin, jaringan, router virtual, dll. Untuk melakukan ini, tambahkan layanan ke node kontrol yang akan bertindak sebagai dasbor - klien akan dapat terhubung ke portal ini melalui http / https dan melakukan apa pun yang diperlukan (yah, hampir).
Akibatnya, kami sekarang memiliki sistem yang toleran terhadap kesalahan. Semua elemen infrastruktur ini harus dikelola. Telah dijelaskan sebelumnya bahwa Openstack adalah sekumpulan proyek, yang masing-masing menyediakan beberapa fungsi tertentu. Seperti yang bisa kita lihat, ada lebih dari cukup elemen yang perlu dikonfigurasi dan dikontrol. Hari ini kita akan berbicara tentang bagian jaringan.
Arsitektur neutron
Di OpenStack, Neutron yang bertanggung jawab untuk menghubungkan port mesin virtual ke jaringan L2 umum, memastikan perutean lalu lintas antara VM yang terletak di jaringan L2 yang berbeda, serta merutekan ke luar, menyediakan layanan seperti NAT, Floating IP, DHCP, dll.
Operasi tingkat tinggi dari layanan jaringan ( bagian dasar) dapat dijelaskan sebagai berikut.
Saat memulai VM, layanan jaringan:
- Membuat port untuk VM ini (atau port) dan memberi tahu layanan DHCP tentangnya;
- Perangkat jaringan virtual baru dibuat (melalui libvirt);
- VM terhubung ke port (port) yang dibuat pada langkah 1;
Anehnya, tetapi inti dari pekerjaan Neutron adalah mekanisme standar yang akrab bagi semua orang yang pernah terjun ke Linux - namespace, iptables, jembatan linux, openvswitch, conntrack, dll.
Harus segera diklarifikasi bahwa Neutron bukanlah pengontrol SDN.
Neutron terdiri dari beberapa komponen yang saling berhubungan:
Openstack-neutron-server adalah daemon yang bekerja dengan permintaan pengguna melalui API. Daemon ini tidak menentukan konektivitas jaringan apa pun, tetapi memberikan informasi yang diperlukan untuk ini ke pluginnya, yang kemudian mengkonfigurasi elemen jaringan yang diperlukan. Agen neutron pada node OpenStack mendaftar dengan server Neutron.
Neutron-server sebenarnya adalah aplikasi yang ditulis dengan python, terdiri dari dua bagian:
- Layanan REST
- Plugin Neutron (inti / layanan)
Layanan REST dirancang untuk menerima panggilan API dari komponen lain (misalnya, permintaan untuk memberikan beberapa informasi, dll.)
Plugin adalah komponen / modul perangkat lunak plug-in yang dipanggil atas permintaan API - yaitu, layanan ditetapkan melalui mereka. Plugin dibagi menjadi dua jenis - layanan dan root. Sebagai aturan, plugin horse terutama bertanggung jawab untuk mengelola ruang alamat dan koneksi L2 antara VM, dan plugin layanan sudah menyediakan fungsionalitas tambahan, seperti VPN atau FW.
Daftar plugin yang tersedia untuk hari ini dapat dilihat misalnya di sini
Mungkin ada beberapa plugin layanan, tetapi hanya ada satu plugin kuda.
Tumpukan terbuka-neutron-ml2Apakah plugin root Openstack standar. Plug-in ini memiliki arsitektur modular (tidak seperti pendahulunya) dan mengkonfigurasi layanan jaringan melalui driver yang terhubung dengannya. Kami akan mempertimbangkan plugin itu sendiri nanti, karena pada kenyataannya plugin ini memberikan fleksibilitas yang dimiliki OpenStack di bagian jaringan. Plugin root dapat diganti (misalnya, Contrail Networking membuat penggantinya).
Layanan RPC (rabbitmq-server) - Layanan yang menyediakan manajemen antrian dan komunikasi dengan layanan OpenStack lainnya, serta komunikasi antara agen layanan jaringan.
Agen jaringan - agen yang terletak di setiap node tempat layanan jaringan dikonfigurasi.
Agen terdiri dari beberapa jenis.
Agen utamanya adalahAgen L2 . Agen ini berjalan di setiap hypervisor, termasuk node kontrol (lebih tepatnya, di semua node yang menyediakan layanan apa pun untuk penyewa) dan fungsi utamanya adalah menghubungkan mesin virtual ke jaringan L2 umum, serta menghasilkan peringatan saat terjadi peristiwa apa pun (misalnya nonaktifkan / aktifkan port).
Agen berikutnya yang tidak kalah pentingnya adalah agen L3... Secara default, agen ini berjalan secara eksklusif pada node jaringan (seringkali node jaringan digabungkan dengan node kontrol) dan menyediakan perutean antara jaringan penyewa (antara jaringannya dan jaringan penyewa lain, dan tersedia untuk dunia luar, menyediakan layanan NAT dan DHCP). Namun, saat menggunakan DVR (router terdistribusi), kebutuhan akan plugin L3 juga muncul di node komputasi.
Agen L3 menggunakan namespace Linux untuk menyediakan satu set jaringan terisolasi mereka sendiri dan fungsionalitas router virtual yang merutekan lalu lintas dan menyediakan layanan gateway untuk jaringan Layer 2 kepada setiap penyewa.
Database - database pengenal jaringan, subnet, port, pool, dll.
Faktanya, Neutron menerima permintaan API dari pembuatan entitas jaringan apa pun, mengautentikasi permintaan, dan melalui RPC (jika ditujukan ke beberapa plugin atau agen) atau REST API (jika berkomunikasi di SDN) mengirimkan agen (melalui plugin) instruksi yang diperlukan untuk mengatur layanan yang diminta. ...
Sekarang mari kita beralih ke instalasi uji (bagaimana itu diterapkan dan apa isinya nanti di bagian praktis) dan lihat di mana komponen berada:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Sebenarnya, itulah keseluruhan struktur Neutron. Sekarang ada baiknya meluangkan waktu untuk plugin ML2.
Lapisan modular 2
Seperti yang dinyatakan di atas, plugin tersebut adalah plugin root OpenStack standar dan memiliki arsitektur modular.
Pendahulu plug-in ML2 memiliki struktur monolitik yang tidak memungkinkan, misalnya, menggunakan campuran beberapa teknologi dalam satu instalasi. Misalnya, Anda tidak dapat menggunakan openvswitch dan linuxbridge secara bersamaan - baik yang pertama maupun yang kedua. Untuk alasan ini, plugin ML2 dengan arsitekturnya dibuat.
ML2 memiliki dua komponen - dua jenis driver: Jenis driver dan Mekanisme driver.
Jenis driver menentukan teknologi yang akan digunakan untuk mengatur konektivitas jaringan, seperti VxLAN, VLAN, GRE. Dalam hal ini, driver memungkinkan Anda menggunakan teknologi yang berbeda. Teknologi standar adalah enkapsulasi VxLAN untuk jaringan overlay dan jaringan eksternal vlan.
Jenis driver mencakup jenis jaringan berikut:
Flat - jaringan tanpa menandai
VLAN - jaringan yang diberi tag
Lokal - jenis jaringan khusus untuk instalasi all-in-one (instalasi semacam itu diperlukan baik untuk pengembang atau untuk pelatihan)
GRE - jaringan overlay menggunakan terowongan GRE
VxLAN - jaringan overlay menggunakan terowongan VxLAN.
Driver mekanisme menentukan sarana yang menyediakan organisasi teknologi yang ditentukan dalam driver jenis - misalnya, openvswitch, sr-iov, opendaylight, OVN, dll.
Bergantung pada implementasi driver ini, agen yang dikontrol oleh Neutron akan digunakan, atau koneksi dengan pengontrol SDN eksternal akan digunakan, yang menangani semua masalah pengorganisasian jaringan L2, perutean, dll.
Contoh Jika kita menggunakan ML2 bersama dengan OVS, setiap node komputasi diatur dengan agen L2 yang mengelola OVS. Namun, jika kita menggunakan, misalnya, OVN atau OpenDayLight, maka kontrol OVS berada di bawah yurisdiksinya - Neutron memberikan perintah kepada pengontrol melalui plugin root, dan dia sudah melakukan apa yang diperintahkan.
Mari segarkan memori kita Buka vSwitch
Saat ini, salah satu komponen kunci OpenStack adalah Open vSwitch.
Saat menginstal OpenStack tanpa vendor tambahan SDN seperti Juniper Contrail atau Nokia Nuage, OVS adalah komponen jaringan utama dari jaringan cloud dan, bersama dengan iptables, conntrack, namespaces, memungkinkan Anda untuk mengatur jaringan overlay lengkap dengan multi-tenancy. Biasanya, komponen ini dapat diganti, misalnya, saat menggunakan solusi SDN milik pihak ketiga (vendor).
OVS adalah sakelar perangkat lunak sumber terbuka yang dirancang untuk digunakan dalam lingkungan tervirtualisasi sebagai penerusan lalu lintas virtual.
Saat ini, OVS memiliki fungsionalitas yang sangat baik, yang mencakup teknologi seperti QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, dll.
Catatan: awalnya OVS tidak dipahami sebagai tombol lunak untuk fungsi telekomunikasi beban tinggi dan lebih dirancang untuk fungsi TI yang tidak terlalu padat bandwidth seperti server WEB atau server email. Namun, OVS sedang diselesaikan dan implementasi OVS saat ini telah sangat meningkatkan kinerja dan kemampuannya, yang memungkinkannya untuk digunakan oleh operator telekomunikasi dengan fungsi beban tinggi, misalnya, ada implementasi OVS dengan dukungan akselerasi DPDK.
Ada tiga komponen OVS penting yang harus diperhatikan:
- Modul kernel - komponen yang terletak di ruang kernel yang memproses lalu lintas berdasarkan aturan yang diterima dari kontrol;
- vSwitch daemon (ovs-vswitchd) — , user space, kernel —
- Database server — , , OVS, . OVSDB SDN .
Semua ini juga disertai dengan seperangkat utilitas diagnostik dan manajemen, seperti ovs-vsctl, ovs-appctl, ovs-ofctl, dll.
Saat ini, Openstack banyak digunakan oleh operator telekomunikasi untuk memindahkan fungsi jaringan ke sana, seperti EPC, SBC, HLR dan seterusnya. Beberapa fungsi dapat hidup tanpa masalah dengan OVS dalam bentuknya, tetapi misalnya, EPC memproses lalu lintas pelanggan - yaitu, ia melewati sejumlah besar lalu lintas melalui dirinya sendiri (sekarang volume lalu lintas mencapai beberapa ratus gigabit per detik). Secara alami, mengarahkan lalu lintas seperti itu melalui ruang kernel (karena secara default forwarder berada di sana) bukanlah ide terbaik. Oleh karena itu, OVS sering digunakan seluruhnya di ruang pengguna menggunakan teknologi akselerasi DPDK untuk meneruskan lalu lintas dari NIC ke ruang pengguna yang melewati kernel.
Catatan: untuk cloud yang digunakan untuk fungsi telekomunikasi, dimungkinkan untuk mengeluarkan lalu lintas dari node komputasi yang melewati OVS langsung ke peralatan switching. Mekanisme SR-IOV dan Passthrough digunakan untuk tujuan ini.
Bagaimana cara kerjanya pada tata letak nyata?
Nah, sekarang mari beralih ke bagian praktik dan melihat bagaimana semuanya bekerja dalam praktik.
Mari kita mulai dengan menerapkan instalasi Openstack sederhana. Karena saya tidak memiliki seperangkat server untuk eksperimen, kami akan menyusun tata letak pada satu server fisik dari mesin virtual. Ya, tentu saja, solusi seperti itu tidak cocok untuk tujuan komersial, tetapi untuk melihat contoh bagaimana jaringan bekerja di Openstack, instalasi seperti itu sudah cukup untuk dilihat. Selain itu, instalasi seperti itu untuk tujuan pelatihan bahkan lebih menarik - karena Anda dapat menangkap lalu lintas, dll.
Karena kita hanya perlu melihat bagian dasar, kita tidak dapat menggunakan beberapa jaringan, tetapi meningkatkan semuanya hanya dengan menggunakan dua jaringan, dan jaringan kedua dalam tata letak ini akan digunakan secara eksklusif untuk mengakses server undercloud dan dns. Kami tidak akan menyentuh jaringan eksternal untuk saat ini - ini adalah topik untuk artikel besar yang terpisah.
Jadi mari kita mulai secara berurutan. Pertama, sedikit teori. Kami akan menginstal Openstack menggunakan TripleO (Openstack di Openstack). Inti dari TripleO adalah kita menginstal Openstack all-in-one (yaitu, pada satu node), yang disebut undercloud, dan kemudian menggunakan kemampuan Openstack yang diterapkan untuk menginstal Openstack yang ditujukan untuk eksploitasi, yang disebut overcloud. Undercloud akan menggunakan kemampuan inheren untuk mengelola server fisik (bare metal) - proyek Ironis - untuk menyediakan hypervisor yang akan bertindak sebagai node penghitung, kontrol, penyimpanan. Artinya, kami tidak menggunakan alat pihak ketiga untuk menerapkan Openstack - kami menerapkan Openstack dengan Openstack. Selanjutnya sepanjang proses instalasi akan menjadi lebih jelas, jadi jangan berhenti di situ dan lanjutkan.
: Openstack, . — , , . . ceph ( ) (Storage management Storage) , , QoS , . .
Catatan: Karena kita akan menjalankan mesin virtual dalam lingkungan virtual berdasarkan mesin virtual, pertama-tama kita perlu mengaktifkan virtualisasi bersarang.
Anda dapat memeriksa apakah virtualisasi bersarang diaktifkan atau tidak seperti ini:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#
Jika Anda melihat huruf N, maka kami mengaktifkan dukungan untuk virtualisasi bersarang sesuai dengan panduan apa pun yang Anda temukan di jaringan, misalnya yang ini .
Kita perlu menyusun skema berikut dari mesin virtual:
Dalam kasus saya, untuk konektivitas mesin virtual yang merupakan bagian dari instalasi di masa mendatang (dan saya mendapat 7 di antaranya, tetapi Anda dapat bertahan dengan 4 jika Anda tidak memiliki banyak sumber daya), saya menggunakan OpenvSwitch. Saya membuat satu jembatan ovs dan menghubungkan mesin virtual dengannya melalui grup port. Untuk melakukan ini, saya membuat file xml dengan bentuk berikut:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Tiga port dari grup dideklarasikan di sini - dua akses dan satu trunk (yang terakhir diperlukan untuk server DNS, tetapi Anda dapat melakukannya tanpa itu, atau meningkatkannya di mesin host - itulah yang lebih nyaman bagi Anda). Selanjutnya, menggunakan template ini, kami mendeklarasikan is melalui virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Sekarang mari kita edit konfigurasi port hypervisor:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Catatan: dalam skenario ini, alamat di port ovs-br1 tidak akan tersedia, karena tidak memiliki tag vlan. Untuk memperbaikinya, jalankan perintah sudo ovs-vsctl set port ovs-br1 tag = 100. Namun, setelah reboot, tag ini akan hilang (jika ada yang tahu bagaimana membuatnya tetap di tempatnya, saya akan sangat berterima kasih). Tetapi ini tidak terlalu penting, karena kita akan membutuhkan alamat ini hanya untuk saat instalasi dan tidak akan diperlukan saat Openstack sepenuhnya diterapkan.Selanjutnya, kami membuat mobil undercloud:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Selama instalasi, Anda mengatur semua parameter yang diperlukan, seperti nama mesin, kata sandi, pengguna, server ntp, dll., Anda dapat segera mengkonfigurasi port, tetapi setelah instalasi, lebih mudah bagi saya untuk masuk ke mesin melalui konsol dan memperbaiki file yang diperlukan. Jika Anda sudah memiliki gambar siap pakai, Anda dapat menggunakannya, atau lakukan seperti yang saya lakukan - unduh gambar minimal Centos 7 dan gunakan untuk menginstal VM.
Setelah instalasi berhasil, Anda akan memiliki mesin virtual di mana Anda dapat menginstal undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPertama, kami menginstal alat yang diperlukan selama proses instalasi:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Menginstal Undercloud
Buat pengguna stack, atur kata sandi, tambahkan ke sudoer dan berikan kemampuan untuk menjalankan perintah root melalui sudo tanpa harus memasukkan kata sandi:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackSekarang kami menentukan nama lengkap undercloud di file hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Selanjutnya, tambahkan repositori dan instal perangkat lunak yang kita butuhkan:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleCatatan: jika Anda tidak berencana untuk menginstal ceph, maka Anda tidak perlu memasukkan perintah terkait ceph. Saya menggunakan rilis Queens, tetapi Anda dapat menggunakan rilis lain yang Anda suka.Selanjutnya, salin file konfigurasi undercloud ke direktori home stack pengguna:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSekarang kita perlu memperbaiki file ini dengan menyesuaikannya dengan instalasi kita.
Tambahkan baris-baris ini ke awal file:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Jadi, melalui pengaturan:
undercloud_hostname - nama server undercloud lengkap harus sesuai dengan entri di server DNS
local_ip - alamat lokal undercloud menuju jaringan yang menyediakan
network_gateway - alamat lokal yang sama, yang akan berfungsi sebagai gateway untuk akses ke dunia luar selama instalasi node overcloud, juga cocok dengan ip lokal
undercloud_public_host - alamat API eksternal, menetapkan alamat gratis apa pun dari jaringan
bawaan undercloud_admin_host alamat API internal, menetapkan alamat gratis apa pun dari
undercloud_nameservers jaringan penyediaan - server DNS
generate_service_certificate- baris ini sangat penting dalam contoh saat ini, karena jika tidak disetel ke false Anda akan menerima kesalahan selama instalasi, masalahnya dijelaskan pada antarmuka pelacak bug
local_interface Red Hat di penyediaan jaringan. Antarmuka ini akan dikonfigurasi ulang selama penerapan undercloud, jadi Anda perlu memiliki dua antarmuka di undercloud - satu untuk mengaksesnya, yang kedua untuk penyediaan
local_mtu - MTU. Karena kami memiliki lab uji dan MTU, saya memiliki 1.500 port OVS Svicha, perlu untuk memasukkan nilai pada 1450, yang akan dienkapsulasi dalam paket VxLAN
network_cidr - penyediaan jaringan
masquerade - penggunaan NAT untuk mengakses jaringan eksternal
masquerade_network - jaringan yang akan NAT -sya
dhcp_start - alamat awal kumpulan alamat tempat alamat akan ditetapkan ke node selama penerapan overcloud
dhcp_end - alamat akhir kumpulan alamat tempat alamat akan ditetapkan ke node selama penerapan overcloud
inspeksi_iprange - kumpulan alamat yang diperlukan untuk introspeksi (tidak boleh tumpang tindih dengan kumpulan yang disebutkan di atas )
scheduler_max_attempts - jumlah percobaan maksimum untuk menginstal overcloud (harus lebih besar dari atau sama dengan jumlah node)
Setelah file dijelaskan, Anda dapat memberikan perintah untuk menyebarkan undercloud:
openstack undercloud install
Prosedur ini memakan waktu 10 hingga 30 menit, tergantung pada setrika Anda. Pada akhirnya, Anda akan melihat keluaran seperti ini:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Output ini mengatakan bahwa Anda telah berhasil menginstal undercloud dan sekarang Anda dapat memeriksa status undercloud dan melanjutkan untuk menginstal overcloud.
Jika Anda melihat output dari ifconfig, Anda akan melihat bahwa antarmuka bridge baru telah muncul
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Penerapan overcloud sekarang akan dilakukan melalui antarmuka ini.
Dari output di bawah ini dapat dilihat bahwa kita memiliki semua layanan dalam satu node:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Di bawah ini adalah konfigurasi bagian jaringan undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Instalasi overcloud
Saat ini, kami hanya memiliki undercloud, dan kami tidak memiliki cukup node untuk membangun overcloud. Oleh karena itu, pertama-tama, kami akan menerapkan mesin virtual yang kami butuhkan. Selama penyebaran, undercloud sendiri akan menginstal OS dan perangkat lunak yang diperlukan pada mesin overcloud - yaitu, kami tidak perlu menerapkan mesin sepenuhnya, tetapi hanya membuat disk (atau disk) untuk itu dan menentukan parameternya - yaitu, pada kenyataannya, kami mendapatkan server kosong tanpa OS diinstal di dalamnya ...
Buka folder dengan disk mesin virtual kami dan buat disk dengan ukuran yang diperlukan:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GKarena kami bertindak dari root, kami perlu mengubah pemilik disk ini agar tidak mendapatkan masalah dengan hak:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Catatan: jika Anda berencana menginstal ceph untuk mempelajarinya, buat minimal 3 node dengan setidaknya dua disk, dan dalam template tunjukkan bahwa disk virtual vda, vdb, dll. Akan digunakan.Bagus, sekarang kita perlu mendefinisikan semua mesin ini:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Di bagian akhir ada perintah --print-xml> /tmp/storage-1.xml, yang membuat file xml dengan deskripsi setiap mesin di folder / tmp /, jika Anda tidak menambahkannya, Anda tidak akan dapat menentukan mesin virtual.
Sekarang kita perlu mendefinisikan semua mesin ini di virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Sekarang sedikit nuansa - tripleO menggunakan IPMI untuk mengelola server selama instalasi dan introspeksi.
Introspeksi adalah proses pemeriksaan perangkat keras untuk mendapatkan parameternya yang diperlukan untuk penyediaan node lebih lanjut. Introspeksi dilakukan dengan ironis - layanan yang dirancang untuk bekerja dengan server bare metal.
Tapi di sini masalahnya - jika server besi IPMI memiliki port terpisah (atau port bersama, tapi ini tidak penting), maka mesin virtual tidak memiliki port tersebut. Di sini kruk bernama vbmc hadir untuk menyelamatkan kami - utilitas yang memungkinkan Anda meniru port IPMI. Nuansa ini patut diperhatikan terutama bagi mereka yang ingin meningkatkan laboratorium semacam itu pada hypervisor ESXI - jika, tentu saja, saya tidak tahu apakah itu memiliki analog dari vbmc, jadi Anda harus bingung dengan pertanyaan ini sebelum menerapkan semuanya.
Instal vbmc:
yum install yum install python2-virtualbmcJika OS Anda tidak dapat menemukan paketnya, tambahkan repositori:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSekarang kita mengkonfigurasi utilitasnya. Semuanya basi untuk aib di sini. Sekarang logis bahwa tidak ada server di daftar vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Agar muncul, mereka harus dideklarasikan secara manual dengan cara ini:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Saya pikir sintaks perintahnya jelas dan tanpa penjelasan. Namun, untuk saat ini, semua sesi kami dalam status TURUN. Agar mereka bisa pergi ke status UP, Anda harus mengaktifkannya:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Dan sentuhan terakhir - Anda perlu memperbaiki aturan firewall (baik, atau nonaktifkan semuanya):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Sekarang mari kita pergi ke undercloud dan periksa apakah semuanya berfungsi. Alamat mesin host adalah 192.168.255.200, kami menambahkan paket ipmitool yang diperlukan ke undercloud selama persiapan penerapan:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningSeperti yang Anda lihat, kami telah berhasil meluncurkan node kontrol melalui vbmc. Sekarang matikan dan lanjutkan:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Langkah selanjutnya adalah introspeksi node tempat overcloud akan dipasang. Untuk melakukan ini, kita perlu menyiapkan file json dengan deskripsi node kita. Perhatikan bahwa berbeda dengan penginstalan di server kosong, file menentukan port tempat vbmc dijalankan untuk setiap mesin.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Catatan: ada dua antarmuka pada node kontrol, tetapi dalam hal ini tidak masalah, dalam instalasi ini sudah cukup bagi kita.Sekarang kami sedang menyiapkan file json. Kita perlu menentukan alamat poppy dari port tempat penyediaan akan dilakukan, parameter node, beri nama dan tunjukkan cara mengakses ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Sekarang kita perlu menyiapkan gambar untuk ironis. Untuk melakukan ini, unduh melalui wget dan instal:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Mengupload gambar ke undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Periksa apakah semua gambar dimuat
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Satu sentuhan lagi - Anda perlu menambahkan server dns:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Sekarang kita bisa mengeluarkan perintah untuk introspeksi:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Seperti yang Anda lihat dari output, semuanya berakhir tanpa kesalahan. Mari kita periksa apakah semua node tersedia:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Jika node berada dalam status yang berbeda, sebagai aturan, dapat dikelola, maka ada yang tidak beres dan Anda perlu melihat log, cari tahu mengapa hal itu terjadi. Perlu diingat bahwa dalam skenario ini kami menggunakan virtualisasi dan mungkin ada bug yang terkait dengan penggunaan mesin virtual atau vbmc.
Selanjutnya, kita perlu menentukan node mana yang akan menjalankan fungsi mana - yaitu, menunjukkan profil yang akan digunakan node tersebut:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Kami menunjukkan profil untuk setiap node:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Kami memeriksa bahwa kami telah melakukan semuanya dengan benar:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Jika semuanya sudah benar, kami memberikan perintah untuk menerapkan overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuDalam instalasi nyata, templat khusus akan digunakan secara alami, dalam kasus kami ini akan sangat mempersulit proses, karena perlu menjelaskan setiap pengeditan dalam templat. Seperti yang tertulis sebelumnya - bahkan instalasi sederhana saja sudah cukup bagi kita untuk melihat cara kerjanya.
Catatan: variabel --libvirt-type qemu diperlukan dalam kasus ini, karena kita akan menggunakan virtualisasi bersarang. Jika tidak, Anda tidak akan menjalankan mesin virtual.
Sekarang Anda memiliki sekitar satu jam, atau mungkin lebih (tergantung pada kemampuan perangkat keras) dan Anda hanya dapat berharap setelah waktu ini Anda akan melihat tulisan berikut:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Sekarang Anda memiliki versi openstack yang hampir lengkap, di mana Anda dapat mempelajari, melakukan eksperimen, dll.
Mari kita periksa apakah semuanya berfungsi dengan baik. Dalam tumpukan direktori home pengguna ada dua file - satu stackrc (untuk mengelola undercloud) dan yang lainnya overcloudrc (untuk mengelola overcloud). File-file ini harus ditentukan sebagai sumber, karena berisi informasi yang diperlukan untuk otentikasi.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Dalam instalasi saya, satu sentuhan kecil diperlukan - untuk menambahkan rute pada pengontrol, karena mesin yang saya gunakan berada di jaringan yang berbeda. Untuk melakukan ini, buka control-1 di bawah akun heat-admin dan tulis rutenya
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Nah, sekarang Anda bisa pergi ke cakrawala. Semua informasi - alamat, nama pengguna dan kata sandi - ada di file / home / stack / overcloudrc. Skema terakhir terlihat seperti ini:
Omong-omong, dalam instalasi kami alamat mesin dikeluarkan melalui DHCP dan, seperti yang Anda lihat, mereka dikeluarkan "secara acak". Anda dapat membuat kode keras di template yang alamatnya harus dilampirkan ke mesin mana selama penerapan, jika Anda membutuhkannya.
Bagaimana arus lalu lintas antara mesin virtual?
Dalam artikel ini, kami akan mempertimbangkan tiga opsi untuk meneruskan lalu lintas
- Dua mesin pada satu hypervisor dalam satu jaringan L2
- Dua mesin di hypervisor berbeda dalam satu jaringan L2
- Dua mesin di jaringan yang berbeda (rooting antar jaringan)
Kasus dengan akses ke dunia luar melalui jaringan eksternal, menggunakan alamat mengambang, serta perutean terdistribusi, akan dipertimbangkan di lain waktu, untuk saat ini kami akan fokus pada lalu lintas internal.
Untuk mengujinya, mari kita
buat skema berikut: Kami telah membuat 4 mesin virtual - 3 dalam satu jaringan L2 - net-1, dan 1 lainnya di jaringan net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Mari kita lihat di mana hypervisor mesin yang dibuat berada:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |(overcloud) [stack @ undercloud ~] $
Machines vm-1 dan vm-3 berada di compute-0, mesin vm-2 dan vm-4 berada di node compute-1.
Selain itu, perute virtual telah dibuat untuk mengaktifkan perutean antara jaringan yang ditentukan:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Router memiliki dua port virtual yang berfungsi sebagai gateway untuk jaringan:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Tetapi sebelum melihat bagaimana lalu lintas berjalan, mari kita lihat apa yang kita miliki saat ini pada node kontrol (yang juga merupakan node jaringan) dan pada node komputasi. Mari kita mulai dengan node komputasi.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Saat ini, node memiliki tiga jembatan ovs - br-int, br-tun, br-ex. Di antara mereka, seperti yang bisa kita lihat, ada seperangkat antarmuka. Untuk memudahkan persepsi, kami akan meletakkan semua antarmuka ini pada diagram dan melihat apa yang terjadi.
Dari alamat tempat tunnel VxLAN dimunculkan, Anda dapat melihat bahwa satu tunnel dimunculkan pada compute-1 (192.168.255.26), tunnel kedua melihat control-1 (192.168.255.15). Tetapi yang paling menarik adalah br-ex tidak memiliki antarmuka fisik, dan jika Anda melihat aliran mana yang dikonfigurasi, Anda dapat melihat bahwa jembatan ini saat ini hanya dapat menurunkan lalu lintas.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Seperti yang Anda lihat dari output, alamat disekrup langsung ke port fisik, dan bukan ke antarmuka jembatan virtual.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ Menurut aturan pertama, semua yang berasal dari port phy-br-ex harus dibuang.
Sebenarnya tidak ada tempat lain untuk lalu lintas menuju jembatan ini, kecuali dari antarmuka ini (persimpangan dengan br-int), dan dilihat dari penurunannya, lalu lintas BUM sudah sampai di jembatan.
Artinya, lalu lintas dari node ini hanya dapat melalui terowongan VxLAN dan tidak ada yang lain. Namun, jika Anda menyalakan DVR, situasinya akan berubah, tetapi kami akan menanganinya lain kali. Saat menggunakan isolasi jaringan misalnya menggunakan vlan, Anda tidak akan memiliki satu antarmuka L3 di vlan ke-0, tetapi beberapa antarmuka. Namun, lalu lintas VxLAN akan keluar dari node dengan cara yang sama, tetapi juga dienkapsulasi menjadi beberapa jenis vlan khusus.
Kami menemukan node komputasi, pergi ke node kontrol.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Faktanya, kita dapat mengatakan bahwa semuanya sama, tetapi alamat ip tidak lagi pada antarmuka fisik, tetapi pada jembatan virtual. Hal ini dilakukan karena pelabuhan ini merupakan pelabuhan yang akan dilalui lalu lintas ke dunia luar.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Porta ini terkait dengan jembatan br-ex dan karena tidak ada tag vlan di atasnya, port ini adalah port trunk di mana semua vlan diizinkan, sekarang lalu lintas keluar tanpa tag, seperti yang ditunjukkan oleh vlan-id 0 pada keluaran di atas.
Segala sesuatu yang lain pada saat ini mirip dengan node komputasi - jembatan yang sama, terowongan yang sama menuju ke dua node komputasi.
Kami tidak akan mempertimbangkan node penyimpanan dalam artikel ini, tetapi untuk memahami harus dikatakan bahwa bagian jaringan dari node ini dangkal hingga titik aib. Dalam kasus kami, hanya ada satu port fisik (eth0) dengan alamat ip tergantung padanya dan hanya itu. Tidak ada terowongan VxLAN, jembatan terowongan, dll. - tidak ada ov sama sekali, karena tidak ada gunanya. Saat menggunakan isolasi jaringan - node ini akan memiliki dua antarmuka (port fisik, baud, atau hanya dua vlan - tidak masalah - tergantung pada apa yang Anda inginkan) - satu untuk manajemen, yang kedua untuk lalu lintas (menulis ke disk VM, membaca dari disk, dll.).
Kami menemukan apa yang kami miliki di node dengan tidak adanya layanan apa pun. Sekarang mari kita mulai 4 mesin virtual dan lihat bagaimana skema yang dijelaskan di atas berubah - kita harus memiliki port, router virtual, dll.
Sejauh ini, jaringan kami terlihat seperti ini:
Kami memiliki dua mesin virtual di setiap komputer. Mari kita lihat bagaimana semuanya disertakan menggunakan compute-0 sebagai contoh.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Mesin hanya memiliki satu antarmuka virtual - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Antarmuka ini melihat jembatan linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Seperti yang Anda lihat dari output, hanya ada dua antarmuka di brigade - tap95d96a75-a0 dan qvb95d96a75-a0.
Ada baiknya membahas sedikit tentang jenis perangkat jaringan virtual di OpenStack:Seperti yang Anda pahami, jika kita memiliki port qvb95d96a75-a0 di brigade, yang merupakan pasangan vEth, lalu di mana pasangannya, yang secara logis harus disebut qvo95d96a75-a0. Mari kita lihat port apa saja yang ada di OVS.
vtap - antarmuka virtual yang terhubung ke instance (VM)
qbr - Linux bridge
qvb dan qvo - pasangan vEth yang terhubung ke jembatan Linux dan Open vSwitch bridge
br-int, br-tun, br-vlan - Buka vSwitch bridge
patch-, int-br-, phy-br- - Buka vSwitch patch-interfaces yang menghubungkan jembatan
qg, qr, ha, fg, sg - Buka port vSwitch yang digunakan oleh perangkat virtual untuk terhubung ke OVS
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Seperti yang bisa kita lihat, portnya ada di br-int. Br-int bertindak sebagai sakelar yang menghentikan port mesin virtual. Selain qvo95d96a75-a0, output menunjukkan port qvo5bd37136-47. Ini adalah port ke mesin virtual kedua. Hasilnya, skema kami sekarang terlihat seperti ini:
Pertanyaan yang akan segera menarik perhatian pembaca yang penuh perhatian - mengapa linux menjembatani antara port mesin virtual dan port OVS? Faktanya adalah bahwa grup keamanan digunakan untuk melindungi mesin, yang tidak lebih dari iptables. OVS tidak bekerja dengan iptables, jadi "kruk" ini ditemukan. Namun, ini hidup lebih lama dari miliknya - digantikan oleh conntrack di rilis baru.
Artinya, akhirnya skemanya terlihat seperti ini:
Dua mesin pada satu hypervisor dalam satu jaringan L2
Karena kedua VM ini berada di jaringan L2 yang sama dan di hypervisor yang sama, lalu lintas di antara keduanya secara logis akan masuk secara lokal melalui br-int, karena kedua mesin akan berada di VLAN yang sama:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dua mesin pada hypervisor yang berbeda dalam jaringan L2 yang sama
Sekarang mari kita lihat bagaimana lalu lintas akan mengalir di antara dua mesin dalam jaringan L2 yang sama, tetapi terletak di hypervisor yang berbeda. Sejujurnya, tidak ada yang akan banyak berubah, hanya lalu lintas antara hypervisor yang akan melewati terowongan vxlan. Mari kita lihat contohnya.
Alamat mesin virtual tempat kita akan memantau lalu lintas:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Kami melihat tabel penerusan di br-int di compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Lalu lintas harus pergi ke port 2 - mari kita lihat apa port ini:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Ini adalah patch-tun - yaitu antarmuka untuk br-tun. Mari kita lihat apa yang terjadi pada paket di br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Paket dikemas ke dalam VxLAN dan dikirim ke port 2. Mari kita lihat ke mana port 2 mengarah:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ini adalah terowongan vxlan di compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Pergi ke compute-1 dan lihat apa yang terjadi selanjutnya dengan paket:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac ada di tabel penerusan br-int pada compute-1, dan seperti yang Anda lihat dari output di atas, Mac terlihat melalui port 2, yang merupakan port menuju br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Nah, kemudian kita lihat bahwa ada tujuan mac di br-int pada compute-1:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Artinya, paket yang diterima akan terbang ke port 3, di belakangnya mesin virtual instance-00000003 sudah berada.
Keindahan penerapan Openstack untuk pembelajaran di infrastruktur virtual adalah bahwa kita dapat dengan mudah menangkap lalu lintas antar hypervisor dan melihat apa yang terjadi padanya. Kami akan melakukan ini sekarang, jalankan tcpdump di port vnet menuju compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Baris pertama menunjukkan bahwa patch dengan alamat 10.0.1.85 menuju ke alamat 10.0.1.88 (lalu lintas ICMP), dan itu dibungkus dalam paket VxLAN dengan vni 22 dan paket berpindah dari host 192.168.255.19 (compute-0) ke host 192.168.255.26 ( compute-1). Kami dapat memeriksa apakah VNI cocok dengan yang ditentukan di ov.
Mari kembali ke baris ini tindakan = memuat: 0-> NXM_OF_VLAN_TCI [], memuat: 0x16-> NXM_NX_TUN_ID [], keluaran: 2. 0x16 adalah vni heksadesimal. Mari terjemahkan angka ini ke dalam sistem ke-10:
16 = 6*16^0+1*16^1 = 6+16 = 22Artinya, vni sesuai dengan kenyataan.
Baris kedua menunjukkan lalu lintas kembali, yah, tidak masuk akal untuk menjelaskannya di sana, dan semuanya jelas.
Dua mesin di jaringan yang berbeda (perutean antar jaringan)
Kasus terakhir untuk hari ini adalah perutean antar jaringan dalam satu proyek menggunakan router virtual. Kami sedang mempertimbangkan kasus tanpa DVR (kami akan melihatnya di artikel lain), jadi perutean terjadi pada node jaringan. Dalam kasus kami, node jaringan bukanlah entitas yang terpisah dan terletak di node kontrol.
Pertama, mari kita lihat bahwa perutean berfungsi:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msKarena dalam hal ini paket harus pergi ke gateway dan dialihkan ke sana, kita perlu mencari tahu alamat MAC dari gateway, yang akan kita lihat di tabel ARP dalam contoh:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Sekarang mari kita lihat kemana lalu lintas harus dikirim dengan tujuan (10.0.1.254) fa: 16: 3e: c4: 64: 70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Kami melihat ke mana port 2 mengarah:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Semuanya logis, lalu lintas menuju ke br-tun. Mari kita lihat terowongan vxlan mana yang akan dibungkusnya:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Port ketiga adalah terowongan vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Yang melihat node kontrol:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Lalu lintas mencapai node kontrol, jadi kita perlu pergi ke sana dan melihat bagaimana perutean akan dilakukan.
Seperti yang Anda ingat, node kontrol di dalamnya tampak persis seperti node komputasi - tiga jembatan yang sama, hanya br-ex yang memiliki port fisik tempat node dapat mengirim lalu lintas ke luar. Pembuatan instance mengubah konfigurasi pada node komputasi - linux bridge, iptables, dan antarmuka ditambahkan ke node. Pembuatan jaringan dan router virtual juga meninggalkan jejaknya pada konfigurasi node kontrol.
Jadi, jelas bahwa alamat poppy gateway harus ada di tabel penerusan br-int pada node kontrol. Mari kita periksa apakah itu ada dan di mana kelihatannya:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac terlihat dari port qr-0c52b15f-8f. Jika kita kembali ke daftar port virtual di Openstack, maka jenis port ini digunakan untuk menghubungkan berbagai perangkat virtual ke OVS. Lebih tepatnya qr adalah port menuju router virtual, yang direpresentasikan sebagai namespace.
Mari kita lihat namespace apa yang ada di server:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Sebanyak tiga eksemplar. Tapi dilihat dari namanya, Anda bisa menebak tujuan masing-masing. Kami akan kembali ke instance dengan ID 0 dan 1 nanti, sekarang kami tertarik dengan namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Namespace ini memiliki dua ruang internal yang kita buat sebelumnya. Kedua port virtual ditambahkan ke br-int. Mari kita periksa alamat massal port qr-0c52b15f-8f, karena lalu lintas, dilihat dari alamat poppy tujuan, langsung menuju ke antarmuka ini.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Artinya, dalam hal ini, semuanya bekerja sesuai dengan hukum perutean standar. Karena lalu lintas ditujukan untuk host 10.0.2.8, lalu lintas harus keluar melalui antarmuka kedua qr-92fa49b5-54 dan melalui terowongan vxlan ke node komputasi:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Semuanya logis, tidak ada kejutan. Kami melihat dari mana alamat poppy dari host 10.0.2.8 terlihat di br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Seperti yang diharapkan, lalu lintas menuju ke br-tun, mari kita lihat terowongan mana yang dilalui lalu lintas berikutnya:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Lalu lintas masuk ke terowongan untuk menghitung-1. Nah, di compute-1 semuanya sederhana - dari br-tun, paketnya menuju br-int dan dari sana ke antarmuka mesin virtual:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Mari kita periksa apakah ini memang antarmuka yang benar:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$Sebenarnya, kami sudah melalui semua paket. Saya pikir Anda memperhatikan bahwa lalu lintas melewati terowongan vxlan yang berbeda dan keluar dengan VNI yang berbeda. Mari kita lihat jenis VNI itu, setelah itu kita akan mengumpulkan dump di port kontrol node dan memastikan bahwa lalu lintas mengalir persis seperti yang dijelaskan di atas.
Jadi, terowongan untuk menghitung-0 memiliki tindakan berikut = memuat: 0-> NXM_OF_VLAN_TCI [], memuat: 0x16-> NXM_NX_TUN_ID [], keluaran: 3. Mengubah 0x16 menjadi notasi Desimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunnel untuk menghitung-1 memiliki VNI berikut: tindakan = memuat: 0-> NXM_OF_VLAN_TCI [], memuat: 0x63-> NXM_NX_TUN_ID [], keluaran: 2. Mengubah 0x63 dalam notasi Desimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nah, sekarang mari kita lihat dumpnya:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Paket pertama adalah paket vxlan dari host 192.168.255.19 (compute-0) ke host 192.168.255.15 (control-1) dengan vni 22, di dalamnya paket ICMP dikemas dari host 10.0.1.85 ke host 10.0.2.8. Seperti yang kami hitung di atas, vni sesuai dengan apa yang kami lihat di output.
Paket kedua adalah paket vxlan dari host 192.168.255.15 (control-1) ke host 192.168.255.26 (compute-1) dengan vni 99, di dalamnya paket ICMP dikemas dari host 10.0.1.85 ke host 10.0.2.8. Seperti yang kami hitung di atas, vni sesuai dengan apa yang kami lihat di output.
Dua paket berikutnya adalah lalu lintas balik dari 10.0.2.8 bukan 10.0.1.85.
Artinya, pada akhirnya, kami mendapat skema node kontrol berikut:
Suka semuanya? Kami lupa tentang dua ruang nama:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Saat kita berbicara tentang arsitektur platform cloud, alangkah baiknya jika mesin menerima alamat secara otomatis dari server DHCP. Ini adalah dua server DHCP untuk dua jaringan kami 10.0.1.0/24 dan 10.0.2.0/24.
Mari kita periksa apakah memang demikian. Namespace ini hanya berisi satu alamat - 10.0.1.1 - alamat server DHCP itu sendiri, dan juga termasuk dalam br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Mari kita lihat apakah proses yang berisi qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 dalam namanya di node kontrol:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Ada proses seperti itu, dan berdasarkan informasi yang disajikan dalam output di atas, kita dapat, misalnya, melihat apa yang kita sewa saat ini:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Sebagai hasilnya, kami mendapatkan serangkaian layanan pada node kontrol:
Perlu diingat - hanya - 4 mesin, 2 jaringan internal, dan satu router virtual ... Kami tidak memiliki jaringan eksternal di sini sekarang, banyak proyek berbeda, masing-masing dengan jaringannya sendiri (tumpang tindih ), dan kami mematikan router terdistribusi, tetapi pada akhirnya hanya ada satu node kontrol di bangku pengujian (untuk toleransi kesalahan, harus ada kuorum tiga node). Masuk akal bahwa dalam perdagangan semuanya "sedikit" lebih rumit, tetapi dalam contoh sederhana ini kami memahami cara kerjanya - jika Anda memiliki 3 atau 300 ruang nama, tentu saja, ini penting, tetapi dari sudut pandang pengoperasian seluruh struktur, tidak ada yang akan banyak berubah ... tetapi untuk saat ini tidak menempel beberapa jenis SDN vendor. Tapi itu cerita yang sama sekali berbeda.
Saya harap itu menarik. Jika ada komentar / tambahan baik, atau di suatu tempat saya berbohong secara terbuka (saya manusia dan pendapat saya akan selalu subjektif) - tulis apa yang perlu dikoreksi / ditambahkan - kami akan mengoreksi / menambahkan semuanya.
Sebagai kesimpulan, saya ingin mengatakan beberapa patah kata tentang membandingkan Openstack (baik vanilla dan vendor) dengan solusi cloud dari VMWare - terlalu sering saya ditanyai pertanyaan ini selama beberapa tahun terakhir dan, sejujurnya, saya bosan, tapi tetap saja. Menurut pendapat saya, kedua solusi ini sangat sulit untuk dibandingkan, tetapi kami dapat dengan tegas mengatakan bahwa ada kekurangan dari kedua solusi tersebut, dan ketika memilih solusi yang mana, seseorang harus mempertimbangkan pro dan kontra.
Jika OpenStack adalah solusi berbasis komunitas, maka VMWare memiliki hak untuk melakukan hanya apa yang diinginkannya (baca - apa yang menguntungkan untuknya) dan ini logis - karena ini adalah perusahaan komersial yang biasa menghasilkan uang dari kliennya. Tetapi ada satu yang besar dan gemuk TAPI - Anda dapat keluar dari OpenStack dari Nokia, misalnya, dan beralih ke solusi dari, misalnya, Juniper (Contrail Cloud), tetapi Anda tidak akan bisa keluar dari VMWare. Bagi saya, kedua solusi ini terlihat seperti ini - Openstack (vendor) adalah sangkar sederhana tempat Anda meletakkan, tetapi Anda memiliki kuncinya dan Anda dapat keluar kapan saja. VMWare adalah sangkar emas, pemiliknya memiliki kunci sangkar dan itu akan menghabiskan banyak biaya.
Saya tidak sedang berkampanye untuk produk pertama atau kedua - Anda memilih apa yang Anda butuhkan. Tetapi jika saya memiliki pilihan seperti itu, maka saya akan memilih kedua solusi - VMWare untuk cloud IT (beban rendah, manajemen yang nyaman), OpenStack dari beberapa vendor (Nokia dan Juniper memberikan solusi turnkey yang sangat bagus) - untuk cloud Telecom. Saya tidak akan menggunakan Openstack untuk IT murni - ini seperti menembak burung pipit dengan meriam, tetapi saya tidak melihat kontraindikasi untuk menggunakannya, kecuali untuk redundansi. Namun, menggunakan VMWare di telekomunikasi - cara mengangkut puing-puing di Ford Raptor - indah dari luar, tetapi pengemudi harus melakukan 10 perjalanan, bukan satu kali.
Menurut pendapat saya, kelemahan terbesar VMWare adalah penutupannya yang lengkap - perusahaan tidak akan memberi Anda informasi apa pun tentang cara kerjanya, misalnya, vSAN atau apa yang ada di inti hypervisor - itu sama sekali tidak menguntungkan untuk itu - yaitu, Anda tidak akan pernah menjadi ahli dalam VMWare - tanpa dukungan vendor, Anda dikutuk (sangat sering saya bertemu pakar VMWare yang bingung dengan pertanyaan dangkal). Bagi saya, VMWare membeli mobil dengan kap terkunci - ya, mungkin Anda memiliki spesialis yang dapat mengganti timing belt, tetapi hanya orang yang menjual solusi ini kepada Anda yang dapat membuka kapnya. Secara pribadi, saya tidak suka solusi yang tidak dapat saya sesuaikan. Anda akan mengatakan bahwa Anda mungkin tidak perlu pergi ke bawah tenda. Ya, ini mungkin, tetapi saya akan melihat Anda ketika Anda perlu mengumpulkan fungsi besar di cloud dari 20-30 mesin virtual, 40-50 jaringan,separuhnya ingin keluar, dan separuh lainnya meminta akselerasi SR-IOV, jika tidak, Anda akan membutuhkan beberapa lusin mesin ini - jika tidak, kinerjanya tidak akan cukup.
Ada sudut pandang lain, jadi hanya Anda yang bisa memutuskan apa yang akan dipilih dan yang terpenting, Anda akan bertanggung jawab atas pilihan Anda nanti. Ini hanya pendapat saya - seseorang yang telah melihat dan menyentuh setidaknya 4 produk - Nokia, Juniper, Red Hat, dan VMWare. Artinya, saya memiliki sesuatu untuk dibandingkan.