Komputasi awan semakin masuk ke dalam kehidupan kita dan mungkin tidak ada satu orang pun yang belum pernah menggunakan layanan cloud setidaknya sekali. Namun, hanya sedikit orang yang mengetahui apa sebenarnya cloud dan cara kerjanya, bahkan pada tingkat ide. 5G sudah menjadi kenyataan dan infrastruktur telekomunikasi mulai beralih dari solusi pilar ke solusi cloud, seperti yang terjadi ketika beralih dari solusi perangkat keras ke βpilarβ tervirtualisasi.
Hari ini kita akan berbicara tentang dunia infrastruktur cloud, khususnya kita akan melihat dasar-dasar bagian jaringan.
Apa itu awan? Virtualisasi yang sama - tampilan profil?
Lebih dari sekedar pertanyaan logis. Tidak - ini bukan virtualisasi, meskipun tidak mungkin dilakukan tanpanya. Mari kita lihat dua definisi:
Komputasi awan (selanjutnya disebut Cloud) adalah model untuk menyediakan akses ramah pengguna ke sumber daya komputasi terdistribusi yang harus diterapkan dan diluncurkan sesuai permintaan dengan latensi serendah mungkin dan biaya minimal bagi penyedia layanan.
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 dengan kecepatan 25-30 persen, setelah virtualisasi Anda mendapatkan 1 server dimuat pada 80-90 persen). Tentu saja, virtualisasi menghabiskan sebagian sumber daya - Anda perlu memberi makan hypervisor, namun, seperti yang telah ditunjukkan oleh praktik, game ini sepadan dengan usahanya. Contoh ideal virtualisasi adalah VMWare, yang menyiapkan mesin virtual dengan sempurna, atau misalnya KVM, yang saya sukai, tapi ini masalah selera.
Kami menggunakan virtualisasi tanpa menyadarinya, dan bahkan router besi pun sudah menggunakan virtualisasi - misalnya, di JunOS versi terbaru, sistem operasi diinstal sebagai mesin virtual di atas distribusi Linux real-time (Wind River 9). Namun virtualisasi bukanlah cloud, tetapi cloud tidak dapat ada tanpa virtualisasi.
Virtualisasi adalah salah satu blok bangunan di mana cloud dibangun.
Membuat cloud hanya dengan mengumpulkan beberapa hypervisor ke dalam satu domain L2, menambahkan beberapa buku pedoman yaml untuk mendaftarkan vlan secara otomatis melalui beberapa jenis kemungkinan dan memasukkan sesuatu seperti sistem orkestrasi ke dalamnya semua untuk membuat mesin virtual secara otomatis tidak akan berfungsi. Ini akan lebih akurat, tetapi Frankenstein yang dihasilkan bukanlah cloud yang kita butuhkan, meskipun mungkin merupakan impian utama bagi orang lain. Terlebih lagi, jika Anda menggunakan Openstack yang sama, pada dasarnya masih Frankenstein, tapi oh baiklah, mari kita tidak membicarakannya untuk saat ini.
Namun saya memahami bahwa dari definisi yang disajikan di atas belum sepenuhnya jelas apa yang sebenarnya bisa disebut dengan cloud.
Oleh karena itu, dokumen dari NIST (National Institute of Standards and Technology) memberikan 5 karakteristik utama yang harus dimiliki oleh infrastruktur cloud:
Memberikan layanan berdasarkan permintaan. Pengguna harus diberikan akses gratis ke sumber daya komputer yang dialokasikan kepadanya (seperti jaringan, disk virtual, memori, inti prosesor, dll.), dan sumber daya ini harus disediakan secara otomatis - yaitu, tanpa campur tangan penyedia layanan.
Ketersediaan layanan yang luas. Akses ke sumber daya harus disediakan melalui mekanisme standar untuk memungkinkan penggunaan PC standar dan klien tipis serta perangkat seluler.
Menggabungkan sumber daya ke dalam kumpulan. Kumpulan sumber daya harus dapat menyediakan sumber daya ke banyak klien pada saat yang sama, memastikan bahwa klien terisolasi dan bebas dari pengaruh timbal balik dan persaingan untuk mendapatkan sumber daya. Jaringan juga termasuk dalam kumpulan, yang menunjukkan kemungkinan penggunaan pengalamatan yang tumpang tindih. Kumpulan harus dapat disesuaikan dengan permintaan. Penggunaan kumpulan memungkinkan untuk memberikan tingkat toleransi kesalahan sumber daya yang diperlukan dan abstraksi sumber daya fisik dan virtual - penerima layanan hanya diberikan kumpulan sumber daya yang dia minta (di mana sumber daya ini berada secara fisik, berapa banyak server dan switch - tidak masalah bagi klien). Namun, kita harus mempertimbangkan fakta bahwa penyedia harus memastikan reservasi sumber daya ini secara transparan.
Adaptasi cepat terhadap kondisi yang berbeda. Layanan harus fleksibel - penyediaan sumber daya dengan cepat, redistribusinya, penambahan atau pengurangan sumber daya atas permintaan klien, dan di pihak klien harus ada perasaan bahwa sumber daya cloud tidak terbatas. Untuk memudahkan pemahaman, misalnya, Anda tidak melihat peringatan bahwa sebagian ruang disk Anda di Apple iCloud telah hilang karena hard drive di server rusak, dan drive memang rusak. Selain itu, di pihak Anda, kemungkinan layanan ini hampir tidak terbatas - Anda memerlukan 2 TB - tidak masalah, Anda membayar dan menerimanya. Contoh serupa dapat diberikan dengan Google.Drive atau Yandex.Disk.
Kemungkinan mengukur layanan yang diberikan. Sistem cloud harus secara otomatis mengontrol dan mengoptimalkan sumber daya yang dikonsumsi, dan mekanisme ini harus transparan bagi pengguna dan penyedia layanan. Artinya, Anda selalu dapat memeriksa berapa banyak sumber daya yang Anda dan klien Anda gunakan.
Perlu dipertimbangkan fakta bahwa sebagian besar persyaratan ini merupakan persyaratan untuk cloud publik, jadi untuk cloud pribadi (yaitu, cloud yang diluncurkan untuk kebutuhan internal perusahaan), persyaratan ini dapat sedikit disesuaikan. Namun, hal tersebut tetap harus dilakukan, jika tidak kita tidak akan mendapatkan semua manfaat dari komputasi awan.
Mengapa kita membutuhkan awan?
Namun, setiap teknologi baru atau yang sudah ada, setiap protokol baru dibuat untuk sesuatu (yah, kecuali untuk RIP-ng, tentu saja). Tidak ada yang membutuhkan protokol demi sebuah protokol (yah, kecuali RIP-ng, tentu saja). Masuk akal jika Cloud diciptakan untuk menyediakan semacam layanan kepada pengguna/klien. Kita semua akrab dengan setidaknya beberapa layanan cloud, misalnya Dropbox atau Google.Docs, dan saya yakin kebanyakan orang berhasil menggunakannya - misalnya, artikel ini ditulis menggunakan layanan cloud Google.Docs. Namun layanan cloud yang kita ketahui hanyalah sebagian dari kemampuan cloudβlebih tepatnya, layanan tersebut hanyalah layanan jenis SaaS. Kami dapat menyediakan layanan cloud dalam tiga cara: dalam bentuk SaaS, PaaS atau IaaS. Layanan apa yang Anda butuhkan tergantung keinginan dan kemampuan Anda.
Mari kita lihat masing-masing secara berurutan:
Software sebagai Service (SaaS) adalah model untuk menyediakan layanan lengkap kepada klien, misalnya layanan email seperti Yandex.Mail atau Gmail. Dalam model pemberian layanan ini, Anda, sebagai klien, sebenarnya tidak melakukan apa pun kecuali menggunakan layanan - yaitu, Anda tidak perlu memikirkan pengaturan layanan, toleransi kesalahan, atau redundansinya. Hal utama adalah jangan mengkompromikan 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 database dan perangkat lunak.
Platform sebagai Layanan (PaaS) β saat menggunakan model ini, penyedia layanan menyediakan benda kerja untuk layanan tersebut kepada klien, misalnya, mari kita ambil server Web. Penyedia layanan menyediakan server virtual kepada klien (sebenarnya, sekumpulan sumber daya, seperti RAM/CPU/Penyimpanan/Jaringan, dll.), dan bahkan menginstal OS dan perangkat lunak yang diperlukan di server ini, namun konfigurasinya semua hal ini dilakukan oleh klien sendiri dan untuk kinerja layanan klien bertanggung jawab. Penyedia layanan, seperti dalam kasus sebelumnya, bertanggung jawab atas kinerja peralatan fisik, hypervisor, mesin virtual itu sendiri, ketersediaan jaringannya, dll., tetapi layanan itu sendiri tidak lagi berada dalam wilayah tanggung jawabnya.
Infrastruktur sebagai Layanan (IaaS) - pendekatan ini sudah lebih menarik, pada kenyataannya, penyedia layanan menyediakan infrastruktur virtual yang lengkap kepada klien - yaitu, beberapa kumpulan (kumpulan) sumber daya, seperti Inti CPU, RAM, Jaringan, dll. klien - apa yang ingin dilakukan klien dengan sumber daya ini dalam kumpulan yang dialokasikan (kuota) - tidak terlalu penting bagi pemasok. Apakah klien ingin membuat vEPC sendiri atau bahkan membuat operator mini dan menyediakan layanan komunikasi - tidak ada pertanyaan - lakukanlah. Dalam skenario seperti itu, penyedia layanan bertanggung jawab atas penyediaan sumber daya, toleransi kesalahan dan ketersediaannya, serta OS yang memungkinkan mereka mengumpulkan sumber daya ini dan membuatnya tersedia bagi klien dengan kemampuan untuk menambah atau mengurangi sumber daya kapan saja. atas permintaan klien. Klien mengonfigurasi sendiri semua mesin virtual dan perada lainnya melalui portal dan konsol layanan mandiri, termasuk menyiapkan jaringan (kecuali untuk jaringan eksternal).
Apa itu OpenStack?
Dalam ketiga opsi tersebut, penyedia layanan memerlukan OS yang memungkinkan pembuatan infrastruktur cloud. Faktanya, dengan SaaS, lebih dari satu divisi bertanggung jawab atas seluruh tumpukan teknologi - ada divisi yang bertanggung jawab atas infrastruktur - yaitu, ia menyediakan IaaS ke divisi lain, divisi ini menyediakan SaaS kepada klien. OpenStack adalah salah satu sistem operasi cloud yang memungkinkan Anda mengumpulkan sekumpulan switch, server, dan sistem penyimpanan ke dalam satu kumpulan sumber daya, membagi kumpulan umum ini menjadi subkumpulan (penyewa) dan menyediakan sumber daya ini kepada klien melalui jaringan.
OpenStack adalah sistem operasi cloud yang memungkinkan Anda mengontrol kumpulan besar sumber daya komputasi, penyimpanan data, dan sumber daya jaringan, yang disediakan dan dikelola melalui API menggunakan mekanisme autentikasi standar.
Dengan kata lain, ini adalah serangkaian proyek perangkat lunak gratis yang dirancang untuk membuat layanan cloud (baik publik maupun pribadi) - yaitu, seperangkat alat yang memungkinkan Anda menggabungkan server dan peralatan switching ke dalam satu kumpulan sumber daya, mengelola sumber daya ini, memberikan tingkat toleransi kesalahan yang diperlukan.
Pada saat artikel ini ditulis, struktur OpenStack terlihat seperti ini:
Gambar diambil dari
Masing-masing komponen yang termasuk dalam OpenStack menjalankan fungsi tertentu. Arsitektur terdistribusi ini memungkinkan Anda untuk memasukkan kumpulan komponen fungsional yang Anda perlukan ke dalam solusi. Namun, beberapa komponen merupakan komponen akar dan penghapusannya akan menyebabkan tidak dapat dioperasikannya sebagian atau seluruh solusi secara keseluruhan. Komponen-komponen ini biasanya diklasifikasikan menjadi:
- Menu Utama β GUI berbasis web untuk mengelola layanan OpenStack
- Keystone adalah layanan identitas terpusat yang menyediakan fungsionalitas otentikasi dan otorisasi untuk layanan lain, serta mengelola kredensial pengguna dan peran mereka.
- neutron - layanan jaringan yang menyediakan konektivitas antara antarmuka berbagai layanan OpenStack (termasuk konektivitas antara VM dan aksesnya ke dunia luar)
- Abu β menyediakan akses ke penyimpanan blok untuk mesin virtual
- Nova β manajemen siklus hidup mesin virtual
- Sekilas β gudang image dan snapshot mesin virtual
- cepat β menyediakan akses ke objek penyimpanan
- langit-langit β layanan yang menyediakan kemampuan untuk mengumpulkan telemetri dan mengukur sumber daya yang tersedia dan dikonsumsi
- Panas β orkestrasi berdasarkan templat untuk pembuatan dan penyediaan sumber daya secara otomatis
Daftar lengkap semua proyek dan tujuannya dapat dilihat .
Setiap komponen OpenStack adalah layanan yang menjalankan fungsi tertentu dan menyediakan API untuk mengelola fungsi tersebut dan berinteraksi dengan layanan sistem operasi cloud lainnya untuk menciptakan infrastruktur terpadu. Misalnya, Nova menyediakan manajemen sumber daya komputasi dan API untuk akses untuk mengonfigurasi sumber daya ini, Glance menyediakan manajemen gambar dan API untuk mengelolanya, Cinder menyediakan penyimpanan blok dan API untuk mengelolanya, dll. Semua fungsi saling berhubungan sangat erat.
Namun, jika Anda melihatnya, semua layanan yang berjalan di OpenStack pada akhirnya adalah semacam mesin virtual (atau container) yang terhubung ke jaringan. Timbul pertanyaan β mengapa kita membutuhkan begitu banyak elemen?
Mari kita lihat algoritma untuk membuat mesin virtual dan menghubungkannya ke jaringan dan penyimpanan persisten di Openstack.
- Saat Anda membuat permintaan untuk membuat mesin, baik itu permintaan melalui Horizon (Dasbor) atau permintaan melalui CLI, hal pertama yang terjadi adalah otorisasi permintaan Anda di Keystone - dapatkah Anda membuat mesin, apakah mesin tersebut memiliki hak untuk menggunakan jaringan ini, apakah draf kuota Anda, dll.
- Keystone mengautentikasi permintaan Anda dan menghasilkan token autentikasi dalam pesan respons, yang akan digunakan lebih lanjut. Setelah mendapat respon dari Keystone, permintaan dikirim ke Nova (nova api).
- Nova-api memeriksa validitas permintaan Anda dengan menghubungi Keystone menggunakan token autentikasi yang dibuat sebelumnya
- Keystone melakukan autentikasi dan memberikan informasi tentang izin dan batasan berdasarkan token autentikasi ini.
- Nova-api membuat entri untuk VM baru di nova-database dan meneruskan permintaan untuk membuat mesin ke nova-scheduler.
- Nova-scheduler memilih host (node ββkomputer) tempat VM akan disebarkan berdasarkan parameter, bobot, dan zona yang ditentukan. Catatan ini dan ID VM ditulis ke database nova.
- Selanjutnya, nova-scheduler menghubungi nova-compute dengan permintaan untuk menerapkan sebuah instance. Nova-compute menghubungi nova-conductor untuk mendapatkan informasi tentang parameter mesin (nova-conductor adalah elemen nova yang bertindak sebagai server proxy antara nova-database dan nova-compute, membatasi jumlah permintaan ke nova-database untuk menghindari masalah dengan database pengurangan beban konsistensi).
- Nova-conductor menerima informasi yang diminta dari nova-database dan meneruskannya ke nova-compute.
- Selanjutnya, panggilan nova-compute sekilas untuk mendapatkan ID gambar. Glace memvalidasi permintaan di Keystone dan mengembalikan informasi yang diminta.
- Nova-hitung kontak neutron untuk mendapatkan informasi tentang parameter jaringan. Mirip dengan sekilas, neutron memvalidasi permintaan di Keystone, setelah itu membuat entri dalam database (pengidentifikasi port, dll.), membuat permintaan untuk membuat port, dan mengembalikan informasi yang diminta ke nova-compute.
- Nova-compute kontak cinder dengan permintaan untuk mengalokasikan volume ke mesin virtual. Mirip dengan sekilas, cider memvalidasi permintaan di Keystone, membuat permintaan pembuatan volume, dan mengembalikan informasi yang diminta.
- Nova-compute menghubungi libvirt dengan permintaan untuk menggunakan mesin virtual dengan parameter yang ditentukan.
Faktanya, operasi pembuatan mesin virtual sederhana yang tampaknya sederhana berubah menjadi pusaran panggilan API antar elemen platform cloud. Selain itu, seperti yang Anda lihat, bahkan layanan yang ditunjuk sebelumnya juga terdiri dari komponen-komponen yang lebih kecil di mana interaksi terjadi. Membuat mesin hanyalah sebagian kecil dari apa yang dapat Anda lakukan oleh platform cloud - ada layanan yang bertanggung jawab untuk menyeimbangkan lalu lintas, layanan yang bertanggung jawab untuk penyimpanan blok, layanan yang bertanggung jawab untuk DNS, layanan yang bertanggung jawab untuk menyediakan server bare metal, dll. Cloud memungkinkan Anda memperlakukan mesin virtual Anda seperti kawanan domba (bukan virtualisasi). Jika sesuatu terjadi pada mesin Anda di lingkungan virtual - Anda memulihkannya dari cadangan, dll., tetapi aplikasi cloud dibuat sedemikian rupa sehingga mesin virtual tidak memainkan peran penting - mesin virtual "mati" - tidak ada masalah - kendaraan baru dibuat berdasarkan templat dan, seperti yang mereka katakan, pasukan tidak menyadari hilangnya petarung tersebut. Tentu saja, hal ini memerlukan adanya mekanisme orkestrasi - menggunakan templat Heat, Anda dapat dengan mudah menerapkan fungsi kompleks yang terdiri dari lusinan jaringan dan mesin virtual.
Perlu diingat bahwa tidak ada infrastruktur cloud tanpa jaringan - setiap elemen berinteraksi dengan elemen lain melalui jaringan dengan satu atau lain cara. Selain itu, cloud memiliki jaringan yang benar-benar non-statis. Secara alami, jaringan underlay bahkan lebih atau kurang statis - node dan switch baru tidak ditambahkan setiap hari, namun komponen overlay dapat dan pasti akan terus berubah - jaringan baru akan ditambahkan atau dihapus, mesin virtual baru akan muncul dan yang lama akan muncul. mati. Dan seperti yang Anda ingat dari definisi cloud yang diberikan di awal artikel, sumber daya harus dialokasikan kepada pengguna secara otomatis dan dengan intervensi paling sedikit (atau lebih baik lagi, tanpa) dari penyedia layanan. Artinya, jenis penyediaan sumber daya jaringan yang sekarang ada dalam bentuk front-end dalam bentuk akun pribadi Anda dapat diakses melalui http/https dan network engineer yang bertugas Vasily sebagai backend bukanlah cloud, bahkan jika Vasily memiliki delapan tangan.
Neutron, sebagai layanan jaringan, menyediakan API untuk mengelola bagian jaringan infrastruktur cloud. Layanan ini memberdayakan dan mengelola bagian jaringan Openstack dengan menyediakan lapisan abstraksi yang disebut Network-as-a-Service (NaaS). Artinya, jaringan adalah unit pengukuran virtual yang sama dengan, misalnya, inti CPU virtual atau jumlah RAM.
Namun sebelum beralih ke arsitektur bagian jaringan OpenStack, mari kita pertimbangkan bagaimana jaringan ini bekerja di OpenStack dan mengapa jaringan merupakan bagian penting dan integral dari cloud.
Jadi kami memiliki dua VM klien MERAH dan dua VM klien HIJAU. Mari kita asumsikan bahwa mesin-mesin ini ditempatkan pada dua hypervisor dengan cara ini:
Saat ini baru virtualisasi 4 server dan tidak lebih, karena sejauh ini yang kami lakukan hanyalah memvirtualisasikan 4 server, menempatkannya di dua server fisik. Dan sejauh ini mereka bahkan belum terhubung ke jaringan.
Untuk membuat cloud, kita perlu menambahkan beberapa komponen. Pertama, kita memvirtualisasikan bagian jaringan - kita perlu menghubungkan 4 mesin ini secara berpasangan, dan klien menginginkan koneksi L2. Anda dapat menggunakan switch dan mengkonfigurasi trunk ke arahnya dan menyelesaikan semuanya menggunakan linux bridge atau, untuk pengguna yang lebih mahir, openvswitch (kita akan membahasnya lagi nanti). Tapi bisa ada banyak jaringan, dan terus-menerus menekan L2 melalui saklar bukanlah ide terbaik - ada departemen yang berbeda, meja layanan, berbulan-bulan menunggu aplikasi diselesaikan, berminggu-minggu pemecahan masalah - di dunia modern ini pendekatan tidak lagi berfungsi. Dan semakin cepat sebuah perusahaan memahami hal ini, semakin mudah bagi perusahaan tersebut untuk bergerak maju. Oleh karena itu, di antara hypervisor kami akan memilih jaringan L3 yang melaluinya mesin virtual kami akan berkomunikasi, dan di atas jaringan L3 ini kami akan membangun jaringan overlay L2 virtual tempat lalu lintas mesin virtual kami akan berjalan. Anda dapat menggunakan GRE, Geneve atau VxLAN sebagai enkapsulasi. Mari kita fokus pada yang terakhir untuk saat ini, walaupun itu tidak terlalu penting.
Kita perlu menemukan VTEP di suatu tempat (saya harap semua orang familiar dengan terminologi VxLAN). Karena kami memiliki jaringan L3 yang datang langsung dari server, tidak ada yang menghalangi kami untuk menempatkan VTEP di server itu sendiri, dan OVS (OpenvSwitch) sangat baik dalam melakukan hal ini. Hasilnya, kami mendapatkan desain ini:
Karena lalu lintas antar VM harus dibagi, port menuju mesin virtual akan memiliki nomor vlan yang berbeda. Nomor tag hanya berperan dalam satu saklar virtual, karena ketika dienkapsulasi dalam VxLAN kita dapat dengan mudah menghapusnya, karena kita akan memiliki VNI.
Sekarang kami dapat membuat mesin dan jaringan virtual untuk mereka tanpa masalah.
Namun, bagaimana jika klien memiliki mesin lain, namun berada di jaringan yang berbeda? Kita perlu rooting antar jaringan. Kami akan melihat opsi sederhana ketika perutean terpusat digunakan - yaitu, lalu lintas dirutekan melalui node jaringan khusus khusus (biasanya, mereka digabungkan dengan node kontrol, jadi kita akan mendapatkan hal yang sama).
Sepertinya tidak ada yang rumit - kami membuat antarmuka jembatan pada node kontrol, mengarahkan lalu lintas ke sana dan dari sana kami mengarahkannya ke tempat yang kami butuhkan. Namun masalahnya klien RED ingin menggunakan jaringan 10.0.0.0/24, dan klien HIJAU ingin menggunakan jaringan 10.0.0.0/24. Artinya, kita mulai melintasi ruang alamat. Selain itu, klien tidak ingin klien lain dapat melakukan rute ke jaringan internal mereka, dan hal ini masuk akal. Untuk memisahkan jaringan dan lalu lintas data klien, kami akan mengalokasikan namespace terpisah untuk masing-masing jaringan. Namespace sebenarnya adalah salinan tumpukan jaringan Linux, yaitu klien di namespace RED sepenuhnya diisolasi dari klien dari namespace HIJAU (baik, perutean antara jaringan klien ini diperbolehkan melalui namespace default atau pada peralatan transportasi hulu).
Artinya, kita mendapatkan diagram berikut:
Terowongan L2 berkumpul dari semua node komputasi ke node kontrol. node tempat antarmuka L3 untuk jaringan ini berada, masing-masing dalam namespace khusus untuk isolasi.
Namun, kami 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 keluar ke dunia luar. Ada pilihan berbeda di sini. Mari kita lakukan opsi paling sederhana. Kami akan menambahkan satu jaringan ke setiap klien, yang akan valid di jaringan penyedia dan tidak akan tumpang tindih dengan jaringan lain. Jaringan juga dapat berpotongan dan melihat VRF berbeda di sisi jaringan penyedia. Data jaringan juga akan berada di namespace setiap klien. Namun, mereka tetap akan keluar ke dunia luar melalui satu antarmuka fisik (atau ikatan, yang lebih logis). Untuk memisahkan lalu lintas klien, lalu lintas yang menuju ke luar akan ditandai dengan tag VLAN yang dialokasikan untuk klien.
Hasilnya, kami mendapatkan diagram ini:
Pertanyaan yang masuk akal adalah mengapa tidak membuat gateway pada node komputasi itu sendiri? Ini bukan masalah besar, apalagi jika Anda mengaktifkan router terdistribusi (DVR), ini akan berhasil. Dalam skenario ini, kami mempertimbangkan opsi paling sederhana dengan gateway terpusat, yang digunakan secara default di Openstack. Untuk fungsi beban tinggi, mereka akan menggunakan router terdistribusi dan teknologi akselerasi seperti SR-IOV dan Passthrough, namun seperti yang mereka katakan, itu adalah cerita yang sama sekali berbeda. Pertama, mari kita bahas bagian dasarnya, lalu kita akan membahas detailnya.
Sebenarnya skema kami sudah bisa diterapkan, tetapi ada beberapa perbedaan:
- Kita perlu melindungi mesin kita, yaitu memasang filter pada antarmuka saklar ke arah klien.
- Memungkinkan mesin virtual memperoleh alamat IP secara otomatis, sehingga Anda tidak perlu masuk ke dalamnya melalui konsol setiap saat dan mendaftarkan alamatnya.
Mari kita mulai dengan melindungi mesin. Untuk ini Anda bisa menggunakan iptables dangkal, mengapa tidak.
Artinya, sekarang topologi kita menjadi sedikit lebih rumit:
Mari kita lanjutkan. Kita perlu menambahkan server DHCP. Tempat paling ideal untuk menemukan server DHCP untuk setiap klien adalah node kontrol yang telah disebutkan di atas, di mana namespace berada:
Namun ada masalah kecil. Bagaimana jika semuanya reboot dan semua informasi tentang menyewa alamat di DHCP hilang. Masuk akal jika mesin akan diberi alamat baru, yang sangat tidak nyaman. Ada dua cara di sini - gunakan nama domain dan tambahkan server DNS untuk setiap klien, maka alamatnya tidak akan terlalu penting bagi kami (mirip dengan bagian jaringan di k8s) - tetapi ada masalah dengan jaringan eksternal, karena alamat juga dapat dikeluarkan di dalamnya melalui DHCP - Anda memerlukan 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 diberikan ke mesin jika mesin telah menerima alamat. Opsi kedua lebih sederhana dan fleksibel, karena memungkinkan Anda menyimpan informasi tambahan tentang mobil. Sekarang mari tambahkan metadata agen ke diagram:
Masalah lain yang juga patut didiskusikan adalah kemampuan untuk menggunakan satu jaringan eksternal oleh semua klien, karena jaringan eksternal, jika harus valid di seluruh jaringan, akan sulit - 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. Hal ini akan mempermudah penerapan mesin karena kita tidak perlu berkonsultasi dengan database alamat dan memilih ruang alamat unik untuk setiap jaringan eksternal klien. Selain itu, kita dapat mendaftarkan jaringan eksternal terlebih dahulu dan pada saat penerapan kita hanya perlu mengaitkan alamat eksternal dengan mesin klien.
Dan di sinilah NAT membantu kami - kami hanya akan memungkinkan klien untuk mengakses dunia luar melalui namespace default menggunakan terjemahan NAT. Nah, ini masalah kecil. Ini bagus jika server klien bertindak sebagai klien dan bukan sebagai server - yaitu, server memulai daripada menerima koneksi. Namun bagi kami, hal itu akan terjadi sebaliknya. Dalam hal ini kita perlu melakukan NAT tujuan agar ketika menerima trafik, node kontrol memahami bahwa trafik ini ditujukan untuk mesin virtual A klien A, artinya kita perlu melakukan penerjemahan NAT dari alamat eksternal, misalnya 100.1.1.1 .10.0.0.1, ke alamat internal 100. Dalam hal ini, meskipun semua klien akan menggunakan jaringan yang sama, isolasi internal tetap terjaga. Artinya, kita perlu melakukan dNAT dan sNAT pada node kontrol. Apakah akan menggunakan satu jaringan dengan alamat mengambang atau jaringan eksternal, atau keduanya sekaligus, bergantung pada apa yang ingin Anda bawa ke cloud. Kami tidak akan menambahkan alamat mengambang ke diagram, tetapi akan meninggalkan jaringan eksternal yang sudah ditambahkan sebelumnya - setiap klien memiliki jaringan eksternalnya sendiri (dalam diagram mereka ditunjukkan sebagai vlan 200 dan XNUMX pada antarmuka eksternal).
Hasilnya, kami menerima solusi yang menarik dan sekaligus bijaksana, yang memiliki fleksibilitas tertentu namun belum memiliki mekanisme toleransi kesalahan.
Pertama, kita hanya memiliki satu node kontrol - kegagalannya akan menyebabkan runtuhnya semua sistem. Untuk memperbaiki masalah ini, Anda perlu membuat setidaknya kuorum 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 selanjutnya adalah disk mesin virtual. Saat ini, mereka disimpan di hypervisor itu sendiri, dan jika ada masalah dengan hypervisor, kami kehilangan semua data - dan adanya serangan tidak akan membantu di sini jika kami tidak kehilangan disk, tetapi seluruh server. Untuk melakukan hal ini, kita perlu membuat layanan yang akan bertindak sebagai ujung depan untuk beberapa jenis penyimpanan. Jenis penyimpanan apa yang akan digunakan tidak terlalu penting bagi kami, namun harus melindungi data kami dari kegagalan disk dan node, dan mungkin seluruh kabinet. Ada beberapa opsi di sini - tentu saja ada jaringan SAN dengan Fibre Channel, tapi jujur ββββsaja - FC sudah menjadi peninggalan masa lalu - analog dari E1 dalam transportasi - ya, saya setuju, masih digunakan, tapi hanya di tempat yang mustahil tanpanya. Oleh karena itu, saya tidak akan secara sukarela menyebarkan jaringan FC pada tahun 2020, karena mengetahui bahwa ada alternatif lain yang lebih menarik. Meskipun bagi masing-masing orang, mungkin ada yang percaya bahwa FC dengan segala keterbatasannya adalah yang kita butuhkan - saya tidak akan membantah, setiap orang memiliki pendapatnya masing-masing. Namun solusi yang paling menarik menurut saya adalah menggunakan SDS seperti Ceph.
Ceph memungkinkan Anda membangun solusi penyimpanan data dengan ketersediaan tinggi dengan banyak kemungkinan opsi pencadangan, dimulai dengan kode dengan pemeriksaan paritas (analog dengan serangan 5 atau 6) diakhiri dengan replikasi data penuh ke disk yang berbeda, dengan mempertimbangkan lokasi disk di server, dan server di lemari, dll.
Untuk membangun Ceph Anda memerlukan 3 node lagi. Interaksi dengan penyimpanan juga akan dilakukan melalui jaringan menggunakan layanan penyimpanan blok, objek, dan file. Mari tambahkan penyimpanan ke diagram:
Catatan: Anda juga dapat membuat node komputasi hiperkonvergensi - ini adalah konsep menggabungkan beberapa fungsi pada satu node - misalnya, penyimpanan+komputasi - tanpa mendedikasikan node khusus untuk penyimpanan ceph. Kami akan mendapatkan skema toleransi kesalahan yang sama - karena SDS akan mencadangkan data dengan tingkat reservasi yang kami tentukan. Namun, node hiperkonvergensi selalu merupakan kompromi - karena node penyimpanan tidak hanya memanaskan udara seperti yang terlihat pada pandangan pertama (karena tidak ada mesin virtual di dalamnya) - ia menghabiskan sumber daya CPU untuk melayani SDS (pada kenyataannya, ia melakukan segalanya replikasi dan pemulihan setelah kegagalan node, disk, dll.). Artinya, Anda akan kehilangan sebagian kekuatan node komputasi jika Anda menggabungkannya dengan penyimpanan.
Semua hal ini perlu dikelola entah bagaimana caranya - kita memerlukan sesuatu yang melaluinya kita dapat membuat mesin, jaringan, router virtual, dll. Untuk melakukan ini, kita akan menambahkan layanan ke node kontrol yang akan bertindak sebagai dasbor - the klien akan dapat terhubung ke portal ini melalui http/https dan melakukan semua yang dia butuhkan (hampir).
Hasilnya, kami sekarang memiliki sistem yang toleran terhadap kesalahan. Semua elemen infrastruktur ini harus dikelola dengan cara apa pun. Telah dijelaskan sebelumnya bahwa Openstack adalah sekumpulan proyek yang masing-masing menyediakan fungsi tertentu. Seperti yang bisa kita lihat, ada lebih dari cukup elemen yang perlu dikonfigurasi dan dikendalikan. Hari ini kita akan berbicara tentang bagian jaringan.
Arsitektur neutron
Di OpenStack, Neutron-lah yang bertanggung jawab untuk menghubungkan port mesin virtual ke jaringan L2 umum, memastikan perutean lalu lintas antara VM yang terletak di jaringan L2 berbeda, serta perutean keluar, menyediakan layanan seperti NAT, Floating IP, DHCP, dll.
Pada tingkat tinggi, pengoperasian layanan jaringan (bagian dasar) dapat digambarkan sebagai berikut.
Saat memulai VM, layanan jaringan:
- Membuat port untuk VM (atau port) tertentu dan memberi tahu layanan DHCP tentang hal itu;
- Perangkat jaringan virtual baru dibuat (melalui libvirt);
- VM terhubung ke port yang dibuat pada langkah 1;
Anehnya, pekerjaan Neutron didasarkan pada mekanisme standar yang akrab bagi semua orang yang pernah terjun ke Linux - namespace, iptables, linux bridge, openvswitch, conntrack, dll.
Perlu 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. Setan ini tidak terlibat dalam mendaftarkan koneksi jaringan apa pun, tetapi memberikan informasi yang diperlukan ke pluginnya, yang kemudian mengonfigurasi elemen jaringan yang diinginkan. Agen neutron pada node OpenStack mendaftar ke server Neutron.
Neutron-server sebenarnya adalah aplikasi yang ditulis dengan python, terdiri dari dua bagian:
- layanan istirahat
- 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 selama permintaan API - yaitu, atribusi layanan terjadi melalui plugin tersebut. Plugin dibagi menjadi dua jenis - layanan dan root. Biasanya, plugin kuda terutama bertanggung jawab untuk mengelola ruang alamat dan koneksi L2 antar VM, dan plugin layanan sudah menyediakan fungsionalitas tambahan seperti VPN atau FW.
Daftar plugin yang tersedia saat ini dapat dilihat misalnya
Mungkin ada beberapa plugin layanan, tetapi hanya ada satu plugin kuda.
openstack-neutron-ml2 adalah plugin root Openstack standar. Plugin ini memiliki arsitektur modular (tidak seperti pendahulunya) dan mengkonfigurasi layanan jaringan melalui driver yang terhubung dengannya. Kita akan melihat plugin itu sendiri nanti, karena sebenarnya plugin ini memberikan fleksibilitas yang dimiliki OpenStack di bagian jaringan. Plugin root dapat diganti (misalnya, Contrail Networking melakukan penggantian seperti itu).
Layanan RPC (server kelincimq) β layanan yang menyediakan manajemen antrian dan interaksi dengan layanan OpenStack lainnya, serta interaksi antara agen layanan jaringan.
Agen jaringan β agen yang berlokasi di setiap node, yang melaluinya layanan jaringan dikonfigurasi.
Ada beberapa jenis agen.
Agen utamanya adalah Agen 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, dan juga menghasilkan peringatan ketika ada peristiwa yang terjadi ( misalnya menonaktifkan/mengaktifkan 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 antar jaringan penyewa (baik antara jaringannya dan jaringan penyewa lainnya, dan dapat diakses oleh dunia luar, menyediakan NAT, serta layanan DHCP). Namun, saat menggunakan DVR (router terdistribusi), kebutuhan akan plugin L3 juga muncul di node komputasi.
Agen L3 menggunakan namespace Linux untuk menyediakan setiap penyewa satu set jaringan terisolasinya sendiri dan fungsionalitas router virtual yang merutekan lalu lintas dan menyediakan layanan gateway untuk jaringan Layer 2.
Basis Data β database pengidentifikasi jaringan, subnet, port, kumpulan, dll.
Faktanya, Neutron menerima permintaan API dari pembuatan entitas jaringan apa pun, mengautentikasi permintaan tersebut, dan melalui RPC (jika mengakses beberapa plugin atau agen) atau REST API (jika berkomunikasi di SDN) mengirimkan ke agen (melalui plugin) instruksi yang diperlukan untuk mengatur layanan yang diminta.
Sekarang mari kita beralih ke instalasi pengujian (bagaimana penerapannya dan apa saja yang termasuk di dalamnya, kita akan lihat nanti di bagian praktis) dan melihat di mana setiap 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 mempelajari plugin ML2.
Lapisan Modular 2
Seperti disebutkan di atas, plugin ini adalah plugin root OpenStack standar dan memiliki arsitektur modular.
Pendahulu plugin ML2 memiliki struktur monolitik, yang tidak memungkinkan, misalnya, penggunaan campuran beberapa teknologi dalam satu instalasi. Misalnya, Anda tidak dapat menggunakan openvswitch dan linuxbridge secara bersamaan - baik yang pertama maupun yang kedua. Untuk itulah plugin ML2 dengan arsitekturnya dibuat.
ML2 memiliki dua komponen - dua jenis driver: Tipe driver dan driver Mekanisme.
Ketik driver menentukan teknologi yang akan digunakan untuk mengatur koneksi jaringan, misalnya VxLAN, VLAN, GRE. Pada saat yang sama, pengemudi mengizinkan penggunaan teknologi yang berbeda. Teknologi standarnya adalah enkapsulasi VxLAN untuk jaringan overlay dan jaringan eksternal vlan.
Tipe driver mencakup tipe jaringan berikut:
Datar - jaringan tanpa penandaan
VLAN - jaringan yang ditandai
Bahan Makanan Lokal β jenis jaringan khusus untuk instalasi all-in-one (instalasi tersebut diperlukan baik untuk pengembang atau untuk pelatihan)
GRE β overlay jaringan menggunakan terowongan GRE
VxLAN β overlay jaringan menggunakan terowongan VxLAN
Penggerak mekanisme tentukan alat yang memastikan pengorganisasian teknologi yang ditentukan dalam driver tipe - misalnya, openvswitch, sr-iov, opendaylight, OVN, dll.
Bergantung pada implementasi driver ini, agen yang dikendalikan oleh Neutron akan digunakan, atau koneksi ke pengontrol SDN eksternal akan digunakan, yang menangani semua masalah terkait pengorganisasian jaringan L2, perutean, dll.
Contoh: jika kita menggunakan ML2 bersama dengan OVS, maka agen L2 diinstal pada setiap node komputasi yang mengelola OVS. Namun, jika kita menggunakan, misalnya, OVN atau OpenDayLight, maka kendali OVS berada di bawah yurisdiksi mereka - Neutron, melalui plugin root, memberikan perintah kepada pengontrol, dan ia sudah melakukan apa yang diperintahkan.
Mari memoles Open vSwitch
Saat ini, salah satu komponen kunci OpenStack adalah Open vSwitch.
Saat menginstal OpenStack tanpa vendor SDN tambahan seperti Juniper Contrail atau Nokia Nuage, OVS adalah komponen jaringan utama dari jaringan cloud dan, bersama dengan iptables, conntrack, namespace, memungkinkan Anda mengatur jaringan overlay multi-tenancy yang lengkap. Tentu saja, komponen ini dapat diganti, misalnya, saat menggunakan solusi SDN milik pihak ketiga (vendor).
OVS adalah saklar perangkat lunak sumber terbuka yang dirancang untuk digunakan dalam lingkungan tervirtualisasi sebagai penerus lalu lintas virtual.
Saat ini, OVS memiliki fungsionalitas yang sangat baik, yang mencakup teknologi seperti QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, dll.
Catatan: OVS pada awalnya tidak dipahami sebagai saklar lunak untuk fungsi telekomunikasi dengan beban tinggi dan lebih dirancang untuk fungsi TI yang membutuhkan bandwidth lebih sedikit seperti server WEB atau server email. Namun OVS terus dikembangkan dan implementasi OVS saat ini telah sangat meningkatkan kinerja dan kemampuannya sehingga memungkinkan untuk digunakan oleh operator telekomunikasi dengan fungsi yang sarat muatan, misalnya ada implementasi OVS dengan dukungan akselerasi DPDK.
Ada tiga komponen penting OVS yang perlu Anda waspadai:
- Modul kernel β komponen yang terletak di ruang kernel yang memproses lalu lintas berdasarkan aturan yang diterima dari elemen kontrol;
- vBeralih daemon (ovs-vswitchd) adalah proses yang diluncurkan di ruang pengguna yang bertanggung jawab untuk memprogram modul kernel - yaitu, secara langsung mewakili logika operasi switch
- Server basis data - database lokal yang terletak di setiap host yang menjalankan OVS, tempat konfigurasi disimpan. Pengontrol SDN dapat berkomunikasi melalui modul ini menggunakan protokol OVSDB.
Semua ini disertai dengan serangkaian utilitas diagnostik dan manajemen, seperti ovs-vsctl, ovs-appctl, ovs-ofctl, dll.
Saat ini, Openstack banyak digunakan oleh operator telekomunikasi untuk memigrasikan fungsi jaringan ke dalamnya, seperti EPC, SBC, HLR, dll. Beberapa fungsi dapat berjalan tanpa masalah dengan OVS apa adanya, tetapi misalnya, EPC memproses lalu lintas pelanggan - kemudian melewatinya lalu lintas dalam jumlah besar (sekarang volume lalu lintas mencapai beberapa ratus gigabit per detik). Tentu saja, mengarahkan lalu lintas seperti itu melalui ruang kernel (karena penerusnya terletak di sana secara default) bukanlah ide terbaik. Oleh karena itu, OVS sering kali diterapkan seluruhnya di ruang pengguna menggunakan teknologi akselerasi DPDK untuk meneruskan lalu lintas dari NIC ke ruang pengguna tanpa melewati kernel.
Catatan: untuk cloud yang diterapkan untuk fungsi telekomunikasi, dimungkinkan untuk mengeluarkan lalu lintas dari node komputasi yang melewati OVS secara langsung ke peralatan switching. Mekanisme SR-IOV dan Passthrough digunakan untuk tujuan ini.
Bagaimana cara kerjanya pada tata letak sebenarnya?
Nah, sekarang mari kita beralih ke bagian praktis dan melihat bagaimana semuanya bekerja dalam praktik.
Pertama, mari kita terapkan instalasi Openstack sederhana. Karena saya tidak memiliki seperangkat server untuk eksperimen, kami akan merakit prototipe pada satu server fisik dari mesin virtual. Ya, tentu saja, solusi seperti itu tidak cocok untuk tujuan komersial, tetapi untuk melihat contoh cara kerja jaringan di Openstack, instalasi seperti itu sudah cukup untuk dilihat. Selain itu, instalasi seperti itu bahkan lebih menarik untuk tujuan pelatihan - karena Anda dapat mengetahui lalu lintas, dll.
Karena kita hanya perlu melihat bagian dasarnya, 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 akses ke 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 on Openstack). Inti dari TripleO adalah kita menginstal Openstack all-in-one (yaitu, pada satu node), yang disebut undercloud, dan kemudian menggunakan kemampuan Openstack yang dikerahkan untuk menginstal Openstack yang dimaksudkan untuk operasi, yang disebut overcloud. Undercloud akan menggunakan kemampuan bawaannya untuk mengelola server fisik (bare metal) - proyek Ironis - untuk menyediakan hypervisor yang akan menjalankan peran komputasi, kontrol, dan node penyimpanan. Artinya, kami tidak menggunakan alat pihak ketiga mana pun untuk menerapkan Openstack - kami menerapkan Openstack menggunakan Openstack. Ini akan menjadi lebih jelas seiring berjalannya instalasi, jadi kami tidak akan berhenti di situ dan melanjutkan.
Catatan: Pada artikel ini, demi kesederhanaan, saya tidak menggunakan isolasi jaringan untuk jaringan internal Openstack, tetapi semuanya di-deploy hanya menggunakan satu jaringan. Namun, ada atau tidaknya isolasi jaringan tidak mempengaruhi fungsionalitas dasar solusi - semuanya akan bekerja sama persis seperti saat menggunakan isolasi, namun lalu lintas akan mengalir di jaringan yang sama. Untuk instalasi komersial, tentu saja perlu menggunakan isolasi menggunakan vlan dan antarmuka yang berbeda. Misalnya, lalu lintas manajemen penyimpanan ceph dan lalu lintas data itu sendiri (akses mesin ke disk, dll.) ketika diisolasi menggunakan subnet yang berbeda (Manajemen Penyimpanan dan Penyimpanan) dan ini memungkinkan Anda membuat solusi lebih toleran terhadap kesalahan dengan membagi lalu lintas ini, misalnya , melintasi port yang berbeda, atau menggunakan profil QoS yang berbeda untuk lalu lintas yang berbeda sehingga lalu lintas data tidak menekan lalu lintas sinyal. Dalam kasus kami, mereka akan berada di jaringan yang sama dan faktanya ini tidak membatasi kami dengan cara apa pun.
Catatan: Karena kita akan menjalankan mesin virtual di lingkungan virtual berdasarkan mesin virtual, pertama-tama kita harus 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 .
Kita perlu merakit sirkuit berikut dari mesin virtual:
Dalam kasus saya, untuk menghubungkan mesin virtual yang merupakan bagian dari instalasi di masa depan (dan saya mendapatkan 7 mesin virtual, tetapi Anda dapat menggunakan 4 mesin virtual jika Anda tidak memiliki banyak sumber daya), saya menggunakan OpenvSwitch. Saya membuat satu jembatan ovs dan menghubungkan mesin virtual ke sana melalui grup port. Untuk melakukan ini, saya membuat file xml seperti ini:
[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 grup port dideklarasikan di sini - dua akses dan satu trunk (yang terakhir diperlukan untuk server DNS, tetapi Anda dapat melakukannya tanpanya, atau menginstalnya di mesin host - mana yang lebih nyaman bagi Anda). Selanjutnya, dengan menggunakan template ini, kami mendeklarasikan milik kami melalui virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Sekarang kita mengedit 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 pada port ovs-br1 tidak akan dapat diakses karena tidak memiliki tag vlan. Untuk memperbaikinya, Anda perlu mengeluarkan perintah sudo ovs-vsctl set port ovs-br1 tag=100. Namun, setelah reboot, tag ini akan hilang (jika ada yang tahu cara membuatnya tetap di tempatnya, saya akan sangat berterima kasih). Tapi ini tidak begitu penting, karena kita hanya memerlukan alamat ini saat instalasi dan tidak memerlukannya saat Openstack sudah di-deploy sepenuhnya.
Selanjutnya, kita membuat mesin 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 bagi saya pribadi, setelah instalasi, lebih mudah untuk masuk ke mesin melalui konsol dan perbaiki file yang diperlukan. Jika Anda sudah memiliki image yang sudah jadi, Anda dapat menggunakannya, atau lakukan apa yang saya lakukan - unduh image minimal Centos 7 dan gunakan untuk menginstal VM.
Setelah instalasi berhasil, Anda akan memiliki mesin virtual tempat Anda dapat menginstal di bawah cloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPertama, instal alat yang diperlukan untuk proses instalasi:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalasi di bawah awan
Kami membuat pengguna tumpukan, menetapkan kata sandi, menambahkannya ke sudoer dan memberinya 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 kita tentukan nama lengkap undercloud di file host:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Selanjutnya, kita menambahkan repositori dan menginstal 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 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 tumpukan direktori home pengguna:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSekarang kita perlu memperbaiki file ini, menyesuaikannya dengan instalasi kita.
Anda perlu menambahkan 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, mari kita lihat pengaturannya:
undercloud_hostname β nama lengkap server undercloud, harus sesuai dengan entri di server DNS
local_ip β alamat undercloud lokal menuju penyediaan jaringan
network_gateway β alamat lokal yang sama, yang akan bertindak sebagai pintu gerbang untuk akses ke dunia luar selama instalasi node overcloud, juga bertepatan dengan ip lokal
undercloud_public_host β alamat API eksternal, alamat gratis apa pun dari jaringan penyedia akan ditetapkan
undercloud_admin_host alamat API internal, alamat gratis apa pun dari jaringan penyediaan akan ditetapkan
undercloud_nameservers - Server DNS
menghasilkan_layanan_sertifikat - baris ini sangat penting dalam contoh saat ini, karena jika Anda tidak menyetelnya ke false Anda akan menerima kesalahan selama instalasi, masalahnya dijelaskan pada pelacak bug Red Hat
antarmuka_lokal antarmuka dalam penyediaan jaringan. Antarmuka ini akan dikonfigurasi ulang selama penerapan undercloud, jadi Anda harus memiliki dua antarmuka di undercloud - satu untuk mengaksesnya, yang kedua untuk provisi
lokal_mtu βMTU. Karena kami memiliki laboratorium pengujian dan saya memiliki MTU 1500 pada port switch OVS, maka perlu diatur ke 1450 agar paket yang dienkapsulasi dalam VxLAN dapat melewatinya.
jaringan_cidr β jaringan penyediaan
menyamar β menggunakan NAT untuk mengakses jaringan eksternal
masquerade_network - jaringan yang akan di-NAT
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 di atas)
penjadwal_max_attempts β jumlah maksimum upaya untuk menginstal overcloud (harus lebih besar 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 menyatakan bahwa Anda telah berhasil menginstal undercloud dan sekarang Anda dapat memeriksa status undercloud dan melanjutkan untuk menginstal overcloud.
Jika Anda melihat keluaran ifconfig, Anda akan melihat antarmuka jembatan 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 0Penyebaran overcloud sekarang akan dilakukan melalui antarmuka ini.
Dari keluaran di bawah ini Anda dapat melihat bahwa kami memiliki semua layanan pada 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 melalui awan
Saat ini kami hanya memiliki undercloud, dan kami tidak memiliki cukup node untuk merakit overcloud. Oleh karena itu, pertama-tama, mari kita terapkan mesin virtual yang kita perlukan. Selama penerapan, undercloud sendiri akan menginstal OS dan perangkat lunak yang diperlukan pada mesin overcloud - yaitu, kita tidak perlu menerapkan mesin sepenuhnya, tetapi hanya membuat disk (atau disk) untuknya dan menentukan parameternya - yaitu , pada kenyataannya, kami mendapatkan server kosong tanpa OS yang diinstal di dalamnya.
Mari buka folder dengan disk mesin virtual kita 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 beroperasi sebagai root, kami perlu mengubah pemilik disk ini agar tidak mendapat masalah 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 tidak berencana menginstal ceph untuk mempelajarinya, maka perintah tidak membuat setidaknya 3 node dengan setidaknya dua disk, tetapi dalam templat menunjukkan 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 Pada akhirnya 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 mampu mengidentifikasi 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 ada sedikit nuansa - tripleO menggunakan IPMI untuk mengelola server selama instalasi dan introspeksi.
Introspeksi adalah proses pemeriksaan perangkat keras untuk mendapatkan parameter yang diperlukan untuk penyediaan node lebih lanjut. Introspeksi dilakukan dengan menggunakan ironic, sebuah layanan yang dirancang untuk bekerja dengan server bare metal.
Namun inilah masalahnya - meskipun server IPMI perangkat keras memiliki port terpisah (atau port bersama, tetapi ini tidak penting), mesin virtual tidak memiliki port tersebut. Di sini kruk bernama vbmc membantu kami - sebuah utilitas yang memungkinkan Anda meniru port IPMI. Nuansa ini patut diperhatikan terutama bagi mereka yang ingin mendirikan laboratorium seperti itu pada hypervisor ESXI - sejujurnya, saya tidak tahu apakah itu memiliki analog dari vbmc, jadi ada baiknya memikirkan masalah 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 kami menyiapkan utilitasnya. Segala sesuatu di sini dangkal sampai-sampai memalukan. Sekarang logis bahwa tidak ada server dalam daftar vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Agar dapat muncul, mereka harus dideklarasikan secara manual seperti 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 ~]#Menurut saya sintaks perintahnya jelas tanpa penjelasan. Namun untuk saat ini semua sesi kita berstatus DOWN. Agar dapat berpindah 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 (atau menonaktifkannya sepenuhnya):
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 memeriksa apakah semuanya berfungsi. Alamat mesin host adalah 192.168.255.200, di undercloud kami menambahkan paket ipmitool yang diperlukan 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 mari kita 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 yang akan dipasang overcloud. Untuk melakukan ini, kita perlu menyiapkan file json dengan deskripsi node kita. Harap dicatat bahwa, tidak seperti instalasi pada server kosong, file tersebut menunjukkan port tempat vbmc berjalan 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: node kontrol memiliki dua antarmuka, tetapi dalam hal ini ini tidak penting, dalam instalasi ini satu saja sudah cukup bagi kami.
Sekarang kita siapkan file jsonnya. Kita perlu menunjukkan alamat poppy dari port yang melaluinya penyediaan akan dilakukan, parameter node, memberi nama dan menunjukkan cara menuju ke 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 gambaran untuk ironi. 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 ~]$Mengunggah 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 ~]$Memeriksa apakah semua gambar telah 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 hal 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 dapat memberikan 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 selesai tanpa kesalahan. Mari kita periksa apakah semua node berada dalam status 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 keadaan yang berbeda, biasanya dapat dikelola, berarti ada yang tidak beres dan Anda perlu melihat log dan mencari tahu mengapa hal ini terjadi. Ingatlah bahwa dalam skenario ini kami menggunakan virtualisasi dan mungkin ada bug yang terkait dengan penggunaan mesin virtual atau vbmc.
Selanjutnya, kita perlu menunjukkan node mana yang akan menjalankan fungsi apa - 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 ~]$Tentukan 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-d9afb69d1167Mari kita periksa apakah kita 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 menyebarkan 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 sebenarnya, templat yang disesuaikan secara alami akan digunakan, dalam kasus kami ini akan sangat mempersulit proses, karena setiap pengeditan pada templat harus dijelaskan. Seperti yang telah ditulis sebelumnya, 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 dapat menjalankan mesin virtual.
Sekarang Anda memiliki waktu sekitar satu jam, atau mungkin lebih (tergantung pada kemampuan perangkat keras) dan Anda hanya dapat berharap setelah waktu tersebut Anda akan melihat pesan 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, tempat Anda dapat belajar, bereksperimen, dll.
Mari kita periksa apakah semuanya berfungsi dengan baik. Di tumpukan direktori home pengguna ada dua file - satu stackrc (untuk mengelola undercloud) dan yang kedua 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 ~]$Instalasi saya masih memerlukan satu sentuhan kecil - menambahkan rute pada pengontrol, karena mesin yang saya gunakan berada di jaringan yang berbeda. Untuk melakukan ini, buka kontrol-1 di bawah akun heat-admin dan daftarkan rutenya
(undercloud) [stack@undercloud ~]$ ssh [email protected]
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 masuk ke cakrawala. Semua informasi - alamat, login dan kata sandi - ada di file /home/stack/overcloudrc. Diagram terakhir terlihat seperti ini:
Omong-omong, dalam instalasi kami, alamat mesin dikeluarkan melalui DHCP dan, seperti yang Anda lihat, alamat tersebut dikeluarkan "secara acak". Anda dapat secara ketat menentukan di templat alamat mana yang harus dilampirkan ke mesin mana selama penerapan, jika Anda memerlukannya.
Bagaimana arus lalu lintas antar mesin virtual?
Pada artikel ini kita akan melihat tiga opsi untuk lalu lintas yang lewat
- Dua mesin di satu hypervisor di satu jaringan L2
- Dua mesin pada hypervisor berbeda di jaringan L2 yang sama
- Dua mesin di jaringan berbeda (rooting lintas jaringan)
Kasus dengan akses ke dunia luar melalui jaringan eksternal, menggunakan alamat mengambang, serta perutean terdistribusi, akan kami pertimbangkan lain kali, untuk saat ini kami akan fokus pada lalu lintas internal.
Untuk memeriksanya, mari kita buat diagram berikut:
Kami telah membuat 4 mesin virtual - 3 di satu jaringan L2 - net-1, dan 1 lagi 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 hypervisor mana 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) [tumpukan@undercloud ~]$
Mesin vm-1 dan vm-3 terletak di komputasi-0, mesin vm-2 dan vm-4 terletak di node komputasi-1.
Selain itu, router virtual telah dibuat untuk memungkinkan perutean antara jaringan tertentu:
(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 bertindak 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 ~]$ Namun sebelum kita melihat bagaimana lalu lintas mengalir, mari kita lihat apa yang saat ini kita miliki 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 tersebut memiliki tiga jembatan ovs - br-int, br-tun, br-ex. Di antara mereka, seperti yang bisa kita lihat, ada serangkaian antarmuka. Untuk memudahkan pemahaman, mari gambarkan semua antarmuka ini pada diagram dan lihat apa yang terjadi.
Melihat alamat terowongan VxLAN yang dimunculkan, terlihat bahwa satu terowongan dinaikkan ke komputasi-1 (192.168.255.26), terowongan kedua mengarah ke kontrol-1 (192.168.255.15). Namun yang paling menarik adalah br-ex tidak memiliki antarmuka fisik, dan jika Anda melihat aliran apa yang dikonfigurasi, Anda dapat melihat bahwa jembatan ini hanya dapat menghentikan lalu lintas saat ini.
[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 tersebut 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, segala sesuatu yang berasal dari port phy-br-ex harus dibuang.
Sebenarnya, saat ini tidak ada tempat lain bagi lalu lintas untuk masuk ke jembatan ini kecuali dari antarmuka ini (antarmuka dengan br-int), dan dilihat dari penurunannya, lalu lintas BUM sudah mengalir ke jembatan.
Artinya, lalu lintas dapat meninggalkan node ini hanya melalui terowongan VxLAN dan tidak melalui yang lain. Namun, jika Anda menyalakan DVR, situasinya akan berubah, tapi kita akan membahasnya lain kali. Saat menggunakan isolasi jaringan, misalnya menggunakan vlan, Anda tidak akan memiliki satu antarmuka L3 di vlan 0, tetapi beberapa antarmuka. Namun, lalu lintas VxLAN akan meninggalkan node dengan cara yang sama, tetapi juga dienkapsulasi dalam beberapa jenis vlan khusus.
Kita telah memilah node komputasi, mari beralih 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 ada di antarmuka fisik tetapi di jembatan virtual. Hal ini dilakukan karena pelabuhan ini merupakan pelabuhan yang akan dilalui lalu lintas menuju 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 ~]$ Port ini terikat ke jembatan br-ex dan karena tidak ada tag vlan di dalamnya, port ini adalah port trunk di mana semua vlan diperbolehkan, sekarang lalu lintas keluar tanpa tag, seperti yang ditunjukkan oleh vlan-id 0 di keluaran di atas.
Segala sesuatu yang lain 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 memahaminya perlu dikatakan bahwa bagian jaringan dari node ini dangkal hingga memalukan. Dalam kasus kami, hanya ada satu port fisik (eth0) dengan alamat IP yang ditetapkan padanya dan hanya itu. Tidak ada terowongan VxLAN, jembatan terowongan, dll. - tidak ada ovs sama sekali, karena tidak ada gunanya. Saat menggunakan isolasi jaringan, node ini akan memiliki dua antarmuka (port fisik, bodi, atau hanya dua vlan - tidak masalah - tergantung 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 tanpa adanya layanan apa pun. Sekarang mari kita luncurkan 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 node komputer. Dengan menggunakan komputasi-0 sebagai contoh, mari kita lihat bagaimana semuanya disertakan.
[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 terlihat di 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 jembatan - tap95d96a75-a0 dan qvb95d96a75-a0.
Di sini ada baiknya memikirkan sedikit tentang jenis perangkat jaringan virtual di OpenStack:
vtap - antarmuka virtual yang dilampirkan ke sebuah instance (VM)
qbr - jembatan Linux
qvb dan qvo - pasangan vEth terhubung ke jembatan Linux dan jembatan Open vSwitch
br-int, br-tun, br-vlan β Buka jembatan vSwitch
patch-, int-br-, phy-br- - Buka antarmuka patch vSwitch yang menghubungkan jembatan
qg, qr, ha, fg, sg - Buka port vSwitch yang digunakan oleh perangkat virtual untuk terhubung ke OVS
Seperti yang Anda pahami, jika kita memiliki port qvb95d96a75-a0 di bridge, yang merupakan pasangan vEth, maka di suatu tempat ada pasangannya, yang secara logis disebut qvo95d96a75-a0. Mari kita lihat port apa saja yang ada di 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 saklar yang mengakhiri port mesin virtual. Selain qvo95d96a75-a0, port qvo5bd37136-47 terlihat di output. Ini adalah port ke mesin virtual kedua. Hasilnya, diagram kita sekarang terlihat seperti ini:
Sebuah pertanyaan yang seharusnya segera menarik minat pembaca yang penuh perhatian - apa jembatan linux antara port mesin virtual dan port OVS? Faktanya adalah untuk melindungi mesin, grup keamanan digunakan, yang tidak lebih dari iptables. OVS tidak bekerja dengan iptables, jadi βkrukβ ini diciptakan. Namun, ini menjadi usang - digantikan oleh conntrack di rilis baru.
Artinya, skema akhirnya terlihat seperti ini:
Dua mesin di satu hypervisor di satu jaringan L2
Karena kedua VM ini terletak di jaringan L2 yang sama dan pada hypervisor yang sama, lalu lintas di antara keduanya secara logis akan mengalir 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 berbeda di jaringan L2 yang sama
Sekarang mari kita lihat bagaimana lalu lintas akan terjadi antara dua mesin di jaringan L2 yang sama, tetapi terletak di hypervisor yang berbeda. Sejujurnya, tidak banyak yang berubah, hanya lalu lintas antar hypervisor yang akan melalui terowongan vxlan. Mari kita lihat sebuah contoh.
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 pada komputasi-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 menuju ke port 2 - mari kita lihat jenis portnya:
[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 patch-tun - yaitu antarmuka di 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 dalam VxLAN dan dikirim ke port 2. Mari kita lihat ke mana arah port 2:
[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 komputasi-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 ~]$Mari kita pergi ke komputasi-1 dan melihat apa yang terjadi selanjutnya dengan paket tersebut:
[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 komputasi-1, dan seperti terlihat dari output di atas, 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 melihat bahwa di br-int pada komputasi-1 ada poppy tujuan:
[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 sudah terdapat mesin virtual instance-00000003.
Keunggulan penerapan Openstack untuk pembelajaran pada infrastruktur virtual adalah kita dapat dengan mudah menangkap lalu lintas antar hypervisor dan melihat apa yang terjadi dengannya. Inilah yang akan kita lakukan sekarang, jalankan tcpdump di port vnet menuju komputasi-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 Patek dari alamat 10.0.1.85 menuju ke alamat 10.0.1.88 (lalu lintas ICMP), dan dibungkus dalam paket VxLAN dengan vni 22 dan paket berpindah dari host 192.168.255.19 (komputasi-0) ke host 192.168.255.26 .1 (komputasi-XNUMX). Kita dapat memeriksa apakah VNI cocok dengan yang ditentukan di ovs.
Mari kita kembali ke baris ini action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 adalah vni dalam sistem bilangan heksadesimal. Mari kita ubah bilangan ini ke sistem ke-16:
16 = 6*16^0+1*16^1 = 6+16 = 22Artinya, vni sesuai dengan kenyataan.
Baris kedua menunjukkan lalu lintas kembali, tidak ada gunanya menjelaskannya, semuanya jelas di sana.
Dua mesin di jaringan berbeda (perutean antar jaringan)
Kasus terakhir hari ini adalah routing antar jaringan dalam satu proyek menggunakan router virtual. Kami sedang mempertimbangkan kasus tanpa DVR (kami akan melihatnya di artikel lain), sehingga perutean terjadi pada node jaringan. Dalam kasus kami, node jaringan tidak ditempatkan di entitas terpisah dan terletak di node kontrol.
Pertama, mari kita lihat apakah 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 menuju ke gateway dan diarahkan ke sana, kita perlu mengetahui alamat MAC gateway tersebut, untuk itu kita melihat 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 ke mana lalu lintas dengan tujuan (10.0.1.254) fa:16:3e:c4:64:70 harus dikirim:
[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 ~]$ Mari kita lihat ke mana arah port 2:
[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 br-tun. Mari kita lihat terowongan vxlan mana yang akan dibungkus:
[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 terlihat pada 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 telah mencapai node kontrol, jadi kita perlu pergi ke sana dan melihat bagaimana perutean akan terjadi.
Seperti yang Anda ingat, node kontrol di dalamnya tampak persis sama dengan node komputasi - tiga jembatan yang sama, hanya br-ex yang memiliki port fisik yang melaluinya node tersebut dapat mengirimkan lalu lintas ke luar. Pembuatan instance mengubah konfigurasi pada node komputasi - jembatan linux, iptables, dan antarmuka ditambahkan ke node. Pembuatan jaringan dan router virtual juga meninggalkan jejaknya pada konfigurasi node kontrol.
Jadi, jelas bahwa alamat MAC gateway harus ada di tabel penerusan br-int pada node kontrol. Mari kita periksa apakah itu ada di sana dan di mana mencarinya:
[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, port jenis ini digunakan untuk menghubungkan berbagai perangkat virtual ke OVS. Lebih tepatnya, qr adalah port ke 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. Namun dilihat dari namanya, Anda sudah bisa menebak tujuan masing-masingnya. Kami akan kembali ke instance dengan ID 0 dan 1 nanti, sekarang kami tertarik pada 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 berisi dua namespace internal yang kita buat sebelumnya. Kedua port virtual telah ditambahkan ke br-int. Mari kita periksa alamat mac dari port qr-0c52b15f-8f, karena lalu lintas, dilihat dari alamat mac tujuan, 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 melewati 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. Mari kita lihat di mana alamat poppy 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 selanjutnya:
[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 ke komputasi-1. Nah, di komputasi-1 semuanya sederhana - dari br-tun paket menuju ke 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 memeriksa seluruh paketnya. Saya rasa Anda memperhatikan bahwa lalu lintas melewati terowongan vxlan yang berbeda dan keluar dengan VNI yang berbeda. Mari kita lihat jenis VNI apa ini, setelah itu kita akan mengumpulkan dump di port kontrol node dan memastikan bahwa lalu lintas mengalir persis seperti yang dijelaskan di atas.
Jadi, terowongan ke komputasi-0 memiliki tindakan berikut=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Mari kita ubah 0x16 ke sistem bilangan desimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Terowongan ke komputasi-1 memiliki VNI berikut:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Mari kita ubah 0x63 ke sistem bilangan 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 (komputasi-0) ke host 192.168.255.15 (kontrol-1) dengan vni 22, di dalamnya dikemas paket ICMP dari host 10.0.1.85 ke host 10.0.2.8. Seperti yang kita hitung di atas, vni cocok dengan apa yang kita lihat di output.
Paket kedua adalah paket vxlan dari host 192.168.255.15 (kontrol-1) ke host 192.168.255.26 (komputasi-1) dengan vni 99, di dalamnya dipaketkan paket ICMP dari host 10.0.1.85 ke host 10.0.2.8. Seperti yang kita hitung di atas, vni cocok dengan apa yang kita lihat di output.
Dua paket berikutnya adalah lalu lintas balik dari 10.0.2.8 bukan 10.0.1.85.
Artinya, pada akhirnya kami mendapatkan skema node kontrol berikut:
Sepertinya itu saja? Kami lupa tentang dua namespace:
[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 ini benar. Hanya ada satu alamat di namespace ini - 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 mengandung qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 pada namanya ada 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 pada output di atas, kita dapat, misalnya, melihat apa yang saat ini kita sewa:
[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 ~]$Hasilnya, kami mendapatkan kumpulan layanan berikut di node kontrol:
Perlu diingat - ini 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 punya router terdistribusi dimatikan, dan pada akhirnya, hanya ada satu node kontrol di bangku pengujian (untuk toleransi kesalahan harus ada kuorum tiga node). Masuk akal bahwa segala sesuatunya "sedikit" lebih rumit dalam perdagangan, tetapi dalam contoh sederhana ini kami memahami cara kerjanya - apakah Anda memiliki 3 atau 300 namespace tentu saja penting, tetapi dari sudut pandang pengoperasian keseluruhan strukturnya, tidak ada yang akan banyak berubah... meskipun sampai Anda tidak akan menyambungkan beberapa vendor SDN. Tapi itu cerita yang sama sekali berbeda.
Saya harap itu menarik. Jika Anda mempunyai komentar/tambahan, atau di suatu tempat saya langsung berbohong (saya manusia dan pendapat saya akan selalu subyektif) - tulis apa yang perlu dikoreksi/ditambahkan - kami akan mengoreksi/menambahkan semuanya.
Sebagai kesimpulan, saya ingin menyampaikan beberapa patah kata tentang membandingkan Openstack (baik vanilla maupun vendor) dengan solusi cloud dari VMWare - Saya sudah terlalu sering ditanyai pertanyaan ini selama beberapa tahun terakhir dan, sejujurnya, saya sudah bosan, tapi tetap saja. Menurut pendapat saya, sangat sulit untuk membandingkan kedua solusi ini, tetapi kita dapat dengan pasti mengatakan bahwa kedua solusi tersebut memiliki kelemahan dan ketika memilih salah satu solusi, Anda perlu mempertimbangkan pro dan kontra.
Jika OpenStack adalah solusi berbasis komunitas, maka VMWare berhak melakukan hanya apa yang diinginkannya (baca - apa yang menguntungkannya) dan ini logis - karena ini adalah perusahaan komersial yang terbiasa menghasilkan uang dari kliennya. Namun ada satu TETAPI yang besar dan gemuk - Anda dapat keluar dari OpenStack, misalnya dari Nokia, dan dengan sedikit biaya beralih ke solusi, misalnya, Juniper (Contrail Cloud), tetapi kemungkinan besar Anda tidak akan bisa keluar dari VMWare . Bagi saya, kedua solusi ini terlihat seperti ini - Openstack (vendor) adalah kandang sederhana tempat Anda ditempatkan, tetapi Anda memiliki kuncinya dan Anda dapat keluar kapan saja. VMWare adalah sangkar emas, pemiliknya memiliki kunci sangkar tersebut dan biayanya akan mahal.
Saya tidak mempromosikan produk pertama atau kedua - Anda memilih apa yang Anda butuhkan. Tetapi jika saya punya pilihan seperti itu, saya akan memilih kedua solusi - VMWare untuk cloud IT (beban rendah, manajemen mudah), OpenStack dari beberapa vendor (Nokia dan Juniper memberikan solusi turnkey yang sangat baik) - untuk cloud Telecom. Saya tidak akan menggunakan Openstack untuk IT murni - ini seperti menembak burung pipit dengan meriam, tapi saya tidak melihat adanya kontraindikasi untuk menggunakannya selain redundansi. Namun, menggunakan VMWare di bidang telekomunikasi seperti mengangkut batu pecah dengan Ford Raptor - terlihat indah dari luar, tetapi pengemudi harus melakukan 10 perjalanan, bukan satu perjalanan.
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 kernel hypervisor - itu tidak menguntungkan - yaitu, Anda akan melakukannya jangan pernah menjadi ahli di VMWare - tanpa dukungan vendor, Anda akan hancur (sangat sering saya bertemu pakar VMWare yang bingung dengan pertanyaan sepele). Bagi saya, VMWare membeli mobil dengan kap mesin terkunci - ya, Anda mungkin memiliki spesialis yang dapat mengganti timing belt, tetapi hanya orang yang menjual solusi ini kepada Anda yang dapat membuka kap mesin. Secara pribadi, saya tidak menyukai solusi yang tidak dapat saya sesuaikan. Anda akan mengatakan bahwa Anda mungkin tidak perlu bersembunyi. Ya, ini mungkin, tetapi saya akan melihat Anda ketika Anda perlu merakit 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 memerlukan lebih banyak beberapa lusin mobil ini - jika tidak, performanya tidak akan cukup.
Ada sudut pandang lain, jadi hanya Anda yang dapat memutuskan apa yang harus dipilih dan, yang terpenting, Anda akan bertanggung jawab atas pilihan Anda. Ini hanya pendapat saya - seseorang yang telah melihat dan menyentuh setidaknya 4 produk - Nokia, Juniper, Red Hat dan VMWare. Artinya, saya punya sesuatu untuk dibandingkan.
Sumber: www.habr.com