Pengkomputeran awan menembusi lebih dalam dan lebih dalam ke dalam kehidupan kita dan mungkin tidak ada seorang pun yang tidak menggunakan sebarang perkhidmatan awan sekurang-kurangnya sekali. Walau bagaimanapun, apa sebenarnya awan dan cara ia berfungsi, hanya sedikit orang yang tahu, walaupun pada tahap idea. 5G sudah menjadi kenyataan dan infrastruktur telekom mula beralih daripada penyelesaian tiang kepada penyelesaian awan, sama seperti yang berlaku apabila ia beralih daripada penyelesaian perkakasan sepenuhnya kepada "tiang" maya.
Hari ini kita akan bercakap tentang dunia dalaman infrastruktur awan, khususnya kita akan melihat asas bahagian rangkaian.
Apakah awan? Maya yang sama - paparan profil?
Lebih daripada soalan logik. Tidak - ini bukan virtualisasi, walaupun ia tidak boleh dilakukan tanpanya. Mari kita lihat dua definisi:
Pengkomputeran awan (selepas ini dirujuk sebagai Awan) ialah model untuk menyediakan akses mesra pengguna kepada sumber pengkomputeran teragih yang mesti digunakan dan dilancarkan atas permintaan dengan kependaman serendah mungkin dan kos minimum kepada pembekal perkhidmatan.
Virtualisasi - ini ialah keupayaan untuk membahagikan satu entiti fizikal (contohnya, pelayan) kepada beberapa yang maya, dengan itu meningkatkan penggunaan sumber (contohnya, anda mempunyai 3 pelayan dimuatkan pada 25-30 peratus, selepas virtualisasi anda mendapat 1 pelayan dimuatkan pada 80-90 peratus). Sememangnya, virtualisasi memakan beberapa sumber - anda perlu memberi makan kepada hypervisor, walau bagaimanapun, seperti yang ditunjukkan oleh amalan, permainan ini berbaloi. Contoh virtualisasi yang ideal ialah VMWare, yang menyediakan mesin maya dengan sempurna, atau sebagai contoh KVM, yang saya lebih suka, tetapi ini adalah soal rasa.
Kami menggunakan virtualisasi tanpa disedari, malah penghala besi sudah pun menggunakan virtualisasi - contohnya, dalam versi terkini JunOS, sistem pengendalian dipasang sebagai mesin maya di atas pengedaran Linux masa nyata (Wind River 9). Tetapi virtualisasi bukanlah awan, tetapi awan tidak boleh wujud tanpa virtualisasi.
Maya adalah salah satu blok bangunan di mana awan dibina.
Membuat awan dengan hanya mengumpulkan beberapa hypervisor ke dalam satu domain L2, menambah beberapa buku main yaml untuk mendaftarkan vlan secara automatik melalui beberapa jenis ansible dan menyekat sesuatu seperti sistem orkestrasi pada semuanya untuk mencipta mesin maya secara automatik tidak akan berfungsi. Ia akan menjadi lebih tepat, tetapi Frankenstein yang terhasil bukanlah awan yang kita perlukan, walaupun ia mungkin impian muktamad untuk orang lain. Lebih-lebih lagi, jika anda menggunakan Openstack yang sama, ia pada asasnya masih Frankenstein, tetapi oh baiklah, mari kita tidak bercakap tentang itu buat masa ini.
Tetapi saya faham bahawa dari definisi yang dibentangkan di atas tidak sepenuhnya jelas apa yang sebenarnya boleh dipanggil awan.
Oleh itu, dokumen daripada NIST (Institut Piawaian dan Teknologi Kebangsaan) menyediakan 5 ciri utama yang perlu ada pada infrastruktur awan:
Menyediakan perkhidmatan atas permintaan. Pengguna mesti diberi akses percuma kepada sumber komputer yang diperuntukkan kepadanya (seperti rangkaian, cakera maya, memori, teras pemproses, dll.), dan sumber ini mesti disediakan secara automatik - iaitu, tanpa campur tangan daripada pembekal perkhidmatan.
Ketersediaan perkhidmatan yang luas. Akses kepada sumber mesti disediakan oleh mekanisme standard untuk membenarkan penggunaan kedua-dua PC standard dan thin client serta peranti mudah alih.
Menggabungkan sumber ke dalam kolam. Kumpulan sumber mesti dapat menyediakan sumber kepada berbilang pelanggan pada masa yang sama, memastikan pelanggan diasingkan dan bebas daripada pengaruh dan persaingan bersama untuk mendapatkan sumber. Rangkaian juga disertakan dalam kumpulan, yang menunjukkan kemungkinan menggunakan pengalamatan bertindih. Kolam mesti boleh berskala atas permintaan. Penggunaan pool memungkinkan untuk menyediakan tahap toleransi kesalahan sumber yang diperlukan dan abstraksi sumber fizikal dan maya - penerima perkhidmatan hanya disediakan dengan set sumber yang dimintanya (di mana sumber ini terletak secara fizikal, pada berapa banyak pelayan dan suis - ia tidak penting kepada pelanggan). Walau bagaimanapun, kita mesti mengambil kira hakikat bahawa pembekal mesti memastikan tempahan telus bagi sumber-sumber ini.
Penyesuaian pantas kepada keadaan yang berbeza. Perkhidmatan mestilah fleksibel - peruntukan pantas sumber, pengagihan semula mereka, menambah atau mengurangkan sumber atas permintaan pelanggan, dan di pihak pelanggan harus ada perasaan bahawa sumber awan tidak berkesudahan. Untuk memudahkan pemahaman, sebagai contoh, anda tidak melihat amaran bahawa sebahagian daripada ruang cakera anda dalam Apple iCloud telah hilang kerana cakera keras pada pelayan telah rosak dan pemacu rosak. Di samping itu, di pihak anda, kemungkinan perkhidmatan ini hampir tidak terhad - anda memerlukan 2 TB - tiada masalah, anda membayar dan menerimanya. Contoh yang sama boleh diberikan dengan Google.Drive atau Yandex.Disk.
Kemungkinan mengukur perkhidmatan yang disediakan. Sistem awan mesti mengawal dan mengoptimumkan sumber yang digunakan secara automatik, dan mekanisme ini mesti telus kepada pengguna dan pembekal perkhidmatan. Iaitu, anda sentiasa boleh menyemak jumlah sumber yang anda dan pelanggan anda gunakan.
Perlu dipertimbangkan fakta bahawa keperluan ini kebanyakannya adalah keperluan untuk awan awam, jadi untuk awan peribadi (iaitu, awan yang dilancarkan untuk keperluan dalaman syarikat), keperluan ini boleh diselaraskan sedikit. Walau bagaimanapun, ia masih perlu dilakukan, jika tidak, kita tidak akan mendapat semua faedah pengkomputeran awan.
Mengapa kita memerlukan awan?
Walau bagaimanapun, mana-mana teknologi baru atau sedia ada, mana-mana protokol baru dicipta untuk sesuatu (baik, kecuali untuk RIP-ng, sudah tentu). Tiada siapa yang memerlukan protokol demi protokol (baik, kecuali untuk RIP-ng, sudah tentu). Adalah logik bahawa Cloud dicipta untuk menyediakan beberapa jenis perkhidmatan kepada pengguna/pelanggan. Kita semua sudah biasa dengan sekurang-kurangnya beberapa perkhidmatan awan, contohnya Dropbox atau Google.Docs, dan saya percaya kebanyakan orang berjaya menggunakannya - contohnya, artikel ini ditulis menggunakan perkhidmatan awan Google.Docs. Tetapi perkhidmatan awan yang kami ketahui hanyalah sebahagian daripada keupayaan awanβlebih tepat lagi, perkhidmatan tersebut hanyalah perkhidmatan jenis SaaS. Kami boleh menyediakan perkhidmatan awan dalam tiga cara: dalam bentuk SaaS, PaaS atau IaaS. Perkhidmatan yang anda perlukan bergantung pada keinginan dan keupayaan anda.
Mari lihat setiap satu mengikut urutan:
Perisian sebagai Perkhidmatan (SaaS) ialah model untuk menyediakan perkhidmatan sepenuhnya kepada pelanggan, contohnya, perkhidmatan e-mel seperti Yandex.Mail atau Gmail. Dalam model penyampaian perkhidmatan ini, anda, sebagai pelanggan, sebenarnya tidak melakukan apa-apa kecuali menggunakan perkhidmatan - iaitu, anda tidak perlu memikirkan tentang menyediakan perkhidmatan, toleransi kesalahan atau redundansinya. Perkara utama bukanlah untuk menjejaskan kata laluan anda; pembekal perkhidmatan ini akan melakukan yang lain untuk anda. Dari sudut pandangan penyedia perkhidmatan, beliau bertanggungjawab sepenuhnya untuk keseluruhan perkhidmatan - daripada perkakasan pelayan dan sistem pengendalian hos kepada tetapan pangkalan data dan perisian.
Platform sebagai Perkhidmatan (PaaS) β apabila menggunakan model ini, pembekal perkhidmatan menyediakan pelanggan dengan bahan kerja untuk perkhidmatan itu, sebagai contoh, mari ambil pelayan Web. Pembekal perkhidmatan menyediakan pelanggan dengan pelayan maya (sebenarnya, satu set sumber, seperti RAM/CPU/Storage/Nets, dll.), malah memasang OS dan perisian yang diperlukan pada pelayan ini, bagaimanapun, konfigurasi semua perkara ini dilakukan oleh pelanggan sendiri dan untuk prestasi perkhidmatan yang dijawab oleh pelanggan. Pembekal perkhidmatan, seperti dalam kes sebelumnya, bertanggungjawab untuk prestasi peralatan fizikal, hypervisor, mesin maya itu sendiri, ketersediaan rangkaiannya, dll., tetapi perkhidmatan itu sendiri tidak lagi berada dalam bidang tanggungjawabnya.
Infrastruktur sebagai Perkhidmatan (IaaS) - pendekatan ini sudah lebih menarik, sebenarnya, pembekal perkhidmatan menyediakan pelanggan dengan infrastruktur maya yang lengkap - iaitu, beberapa set (kumpulan) sumber, seperti Teras CPU, RAM, Rangkaian, dll. Segala-galanya terpulang kepada pelanggan - perkara yang pelanggan mahu lakukan dengan sumber ini dalam kumpulan yang diperuntukkan (kuota) - ia tidak begitu penting untuk pembekal. Sama ada pelanggan ingin mencipta vEPC sendiri atau mencipta pengendali mini dan menyediakan perkhidmatan komunikasi - tidak ada soalan - lakukannya. Dalam senario sedemikian, pembekal perkhidmatan bertanggungjawab untuk menyediakan sumber, toleransi kesalahan dan ketersediaan mereka, serta OS yang membolehkan mereka mengumpulkan sumber ini dan menyediakannya kepada pelanggan dengan keupayaan untuk menambah atau mengurangkan sumber pada bila-bila masa. atas permintaan pelanggan. Pelanggan mengkonfigurasi sendiri semua mesin maya dan tinsel lain melalui portal dan konsol layan diri, termasuk menyediakan rangkaian (kecuali untuk rangkaian luaran).
Apakah OpenStack?
Dalam ketiga-tiga pilihan, pembekal perkhidmatan memerlukan OS yang akan membolehkan penciptaan infrastruktur awan. Malah, dengan SaaS, lebih daripada satu bahagian bertanggungjawab untuk keseluruhan timbunan teknologi - terdapat bahagian yang bertanggungjawab untuk infrastruktur - iaitu, ia menyediakan IaaS kepada bahagian lain, bahagian ini menyediakan SaaS kepada pelanggan. OpenStack ialah salah satu sistem pengendalian awan yang membolehkan anda mengumpul sekumpulan suis, pelayan dan sistem storan ke dalam kumpulan sumber tunggal, memisahkan kumpulan biasa ini kepada subkolam (penyewa) dan menyediakan sumber ini kepada pelanggan melalui rangkaian.
OpenStack ialah sistem pengendalian awan yang membolehkan anda mengawal kumpulan besar sumber pengkomputeran, storan data dan sumber rangkaian, diperuntukkan dan diuruskan melalui API menggunakan mekanisme pengesahan standard.
Dalam erti kata lain, ini ialah satu set projek perisian percuma yang direka bentuk untuk mencipta perkhidmatan awan (awam dan swasta) - iaitu, satu set alat yang membolehkan anda menggabungkan pelayan dan menukar peralatan ke dalam kumpulan sumber tunggal, mengurus sumber ini, menyediakan tahap toleransi kesalahan yang diperlukan.
Pada masa menulis bahan ini, struktur OpenStack kelihatan seperti ini:
Gambar diambil dari
Setiap komponen yang disertakan dalam OpenStack melaksanakan fungsi tertentu. Seni bina teragih ini membolehkan anda memasukkan dalam penyelesaian set komponen berfungsi yang anda perlukan. Walau bagaimanapun, sesetengah komponen adalah komponen akar dan penyingkirannya akan membawa kepada ketidakupayaan penyelesaian yang lengkap atau separa secara keseluruhan. Komponen ini biasanya dikelaskan sebagai:
- Papan Pemuka β GUI berasaskan web untuk mengurus perkhidmatan OpenStack
- Keystone ialah perkhidmatan identiti berpusat yang menyediakan fungsi pengesahan dan kebenaran untuk perkhidmatan lain, serta mengurus kelayakan pengguna dan peranan mereka.
- neutron - perkhidmatan rangkaian yang menyediakan sambungan antara antara muka pelbagai perkhidmatan OpenStack (termasuk sambungan antara VM dan akses mereka ke dunia luar)
- Cinder β menyediakan akses untuk menyekat storan untuk mesin maya
- Nova β pengurusan kitaran hayat mesin maya
- Sekilas β repositori imej mesin maya dan syot kilat
- Swift β menyediakan akses kepada objek storan
- Siilometer β perkhidmatan yang menyediakan keupayaan untuk mengumpul telemetri dan mengukur sumber yang ada dan digunakan
- Haba β orkestrasi berdasarkan templat untuk penciptaan automatik dan peruntukan sumber
Senarai lengkap semua projek dan tujuannya boleh dilihat .
Setiap komponen OpenStack ialah perkhidmatan yang melaksanakan fungsi tertentu dan menyediakan API untuk mengurus fungsi tersebut dan berinteraksi dengan perkhidmatan sistem pengendalian awan lain untuk mencipta infrastruktur bersatu. Contohnya, Nova menyediakan pengurusan sumber pengkomputeran dan API untuk akses kepada mengkonfigurasi sumber ini, Glance menyediakan pengurusan imej dan API untuk mengurusnya, Cinder menyediakan storan blok dan API untuk mengurusnya, dsb. Semua fungsi saling berkaitan dengan cara yang sangat rapat.
Walau bagaimanapun, jika anda melihatnya, semua perkhidmatan yang dijalankan dalam OpenStack akhirnya adalah sejenis mesin maya (atau bekas) yang disambungkan ke rangkaian. Timbul persoalan - mengapa kita memerlukan begitu banyak elemen?
Mari kita lihat algoritma untuk mencipta mesin maya dan menyambungkannya ke rangkaian dan storan berterusan dalam Openstack.
- Apabila anda membuat permintaan untuk mencipta mesin, sama ada permintaan melalui Horizon (Papan Pemuka) atau permintaan melalui CLI, perkara pertama yang berlaku ialah kebenaran permintaan anda pada Keystone - bolehkah anda mencipta mesin, adakah ia mempunyai hak untuk menggunakan rangkaian ini, adakah draf kuota anda, dsb.
- Keystone mengesahkan permintaan anda dan menjana token pengesahan dalam mesej respons, yang akan digunakan selanjutnya. Setelah menerima maklum balas daripada Keystone, permintaan dihantar ke Nova (nova api).
- Nova-api menyemak kesahihan permintaan anda dengan menghubungi Keystone menggunakan token pengesahan yang dijana sebelum ini
- Keystone melakukan pengesahan dan memberikan maklumat tentang kebenaran dan sekatan berdasarkan token pengesahan ini.
- Nova-api mencipta entri untuk VM baharu dalam pangkalan data nova dan menghantar permintaan untuk mencipta mesin kepada penjadual nova.
- Nova-scheduler memilih hos (nod komputer) yang mana VM akan digunakan berdasarkan parameter, berat dan zon yang ditentukan. Rekod ini dan ID VM ditulis ke pangkalan data nova.
- Seterusnya, penjadual nova menghubungi nova-compute dengan permintaan untuk menggunakan tika. Nova-compute menghubungi nova-conductor untuk mendapatkan maklumat tentang parameter mesin (nova-conductor ialah elemen nova yang bertindak sebagai pelayan proksi antara nova-database dan nova-compute, mengehadkan bilangan permintaan kepada nova-database untuk mengelakkan masalah dengan pangkalan data pengurangan beban konsisten).
- Nova-konduktor menerima maklumat yang diminta daripada pangkalan data nova dan menghantarnya ke nova-compute.
- Seterusnya, nova-compute panggilan sepintas lalu untuk mendapatkan ID imej. Glace mengesahkan permintaan dalam Keystone dan mengembalikan maklumat yang diminta.
- Nova-compute menghubungi neutron untuk mendapatkan maklumat tentang parameter rangkaian. Sama seperti pandangan, neutron mengesahkan permintaan dalam Keystone, selepas itu ia mencipta entri dalam pangkalan data (pengecam port, dll.), mencipta permintaan untuk mencipta port dan mengembalikan maklumat yang diminta kepada nova-compute.
- Nova-compute menghubungi cinder dengan permintaan untuk memperuntukkan volum ke mesin maya. Sama seperti pandangan, cider mengesahkan permintaan dalam Keystone, mencipta permintaan pembuatan volum dan mengembalikan maklumat yang diminta.
- Nova-compute menghubungi libvirt dengan permintaan untuk menggunakan mesin maya dengan parameter yang ditentukan.
Malah, operasi yang kelihatan mudah untuk mencipta mesin maya ringkas bertukar menjadi pusaran panggilan API antara elemen platform awan. Lebih-lebih lagi, seperti yang anda lihat, malah perkhidmatan yang ditetapkan sebelum ini juga terdiri daripada komponen yang lebih kecil di antara interaksi yang berlaku. Mencipta mesin hanyalah sebahagian kecil daripada apa yang platform awan membenarkan anda lakukan - terdapat perkhidmatan yang bertanggungjawab untuk mengimbangi trafik, perkhidmatan yang bertanggungjawab untuk penyimpanan blok, perkhidmatan yang bertanggungjawab untuk DNS, perkhidmatan yang bertanggungjawab untuk menyediakan pelayan logam kosong, dsb. Awan membolehkan anda merawat mesin maya anda seperti sekumpulan kambing biri-biri (berbanding dengan virtualisasi). Jika sesuatu berlaku pada mesin anda dalam persekitaran maya - anda memulihkannya daripada sandaran, dsb., tetapi aplikasi awan dibina sedemikian rupa sehingga mesin maya tidak memainkan peranan penting - mesin maya "mati" - tiada masalah - yang baru hanya dibuat kenderaan berdasarkan templat dan, seperti yang mereka katakan, skuad tidak menyedari kehilangan pejuang. Sememangnya, ini menyediakan kehadiran mekanisme orkestra - menggunakan templat Heat, anda boleh dengan mudah menggunakan fungsi kompleks yang terdiri daripada berpuluh-puluh rangkaian dan mesin maya.
Perlu diingat bahawa tiada infrastruktur awan tanpa rangkaian - setiap elemen dalam satu cara atau yang lain berinteraksi dengan elemen lain melalui rangkaian. Di samping itu, awan mempunyai rangkaian yang sama sekali tidak statik. Sememangnya, rangkaian sandaran adalah lebih kurang statik - nod dan suis baharu tidak ditambah setiap hari, tetapi komponen tindanan boleh dan pasti akan berubah secara berterusan - rangkaian baharu akan ditambah atau dipadamkan, mesin maya baharu akan muncul dan yang lama akan mati. Dan seperti yang anda ingat dari definisi awan yang diberikan pada awal artikel, sumber harus diperuntukkan kepada pengguna secara automatik dan dengan sekurang-kurangnya (atau lebih baik lagi, tanpa) campur tangan daripada pembekal perkhidmatan. Iaitu, jenis penyediaan sumber rangkaian yang kini wujud dalam bentuk front-end dalam bentuk akaun peribadi anda yang boleh diakses melalui http/https dan jurutera rangkaian bertugas Vasily sebagai backend bukanlah awan, malah jika Vasily mempunyai lapan tangan.
Neutron, sebagai perkhidmatan rangkaian, menyediakan API untuk mengurus bahagian rangkaian infrastruktur awan. Perkhidmatan ini berkuasa dan mengurus bahagian rangkaian Openstack dengan menyediakan lapisan abstraksi yang dipanggil Network-as-a-Service (NaaS). Iaitu, rangkaian adalah unit terukur maya yang sama seperti, sebagai contoh, teras CPU maya atau jumlah RAM.
Tetapi sebelum beralih kepada seni bina bahagian rangkaian OpenStack, mari kita pertimbangkan cara rangkaian ini berfungsi dalam OpenStack dan sebab rangkaian adalah bahagian penting dan penting dalam awan.
Jadi kami mempunyai dua VM pelanggan RED dan dua VM pelanggan HIJAU. Mari kita anggap bahawa mesin ini terletak pada dua hypervisor dengan cara ini:
Pada masa ini, ini hanyalah virtualisasi 4 pelayan dan tidak lebih, kerana setakat ini semua yang kami lakukan ialah memayakan 4 pelayan, meletakkannya pada dua pelayan fizikal. Dan setakat ini mereka tidak disambungkan ke rangkaian.
Untuk membuat awan, kita perlu menambah beberapa komponen. Pertama, kita memayakan bahagian rangkaian - kita perlu menyambungkan 4 mesin ini secara berpasangan, dan pelanggan mahukan sambungan L2. Anda boleh menggunakan suis dan mengkonfigurasi batang ke arahnya dan menyelesaikan segala-galanya menggunakan jambatan linux atau, untuk pengguna yang lebih maju, openvswitch (kami akan kembali kepada perkara ini kemudian). Tetapi mungkin terdapat banyak rangkaian, dan sentiasa menolak L2 melalui suis bukanlah idea terbaik - terdapat jabatan yang berbeza, meja perkhidmatan, berbulan-bulan menunggu permohonan untuk diselesaikan, minggu penyelesaian masalah - dalam dunia moden ini pendekatan tidak lagi berfungsi. Dan lebih cepat syarikat memahami perkara ini, lebih mudah untuk ia bergerak ke hadapan. Oleh itu, antara hypervisor kami akan memilih rangkaian L3 yang melaluinya mesin maya kami akan berkomunikasi, dan di atas rangkaian L3 ini kami akan membina rangkaian tindanan L2 maya di mana trafik mesin maya kami akan berjalan. Anda boleh menggunakan GRE, Geneve atau VxLAN sebagai enkapsulasi. Mari kita fokus pada yang terakhir buat masa ini, walaupun ia tidak begitu penting.
Kita perlu mencari VTEP di suatu tempat (saya harap semua orang sudah biasa dengan terminologi VxLAN). Memandangkan kami mempunyai rangkaian L3 yang datang terus dari pelayan, tiada apa yang menghalang kami daripada meletakkan VTEP pada pelayan itu sendiri, dan OVS (OpenvSwitch) sangat baik dalam melakukan ini. Hasilnya, kami mendapat reka bentuk ini:
Oleh kerana trafik antara VM mesti dibahagikan, port ke arah mesin maya akan mempunyai nombor vlan yang berbeza. Nombor tag hanya memainkan peranan dalam satu suis maya, kerana apabila terkandung dalam VxLAN kita boleh mengeluarkannya dengan mudah, kerana kita akan mempunyai VNI.
Kini kami boleh mencipta mesin dan rangkaian maya kami untuk mereka tanpa sebarang masalah.
Walau bagaimanapun, bagaimana jika pelanggan mempunyai mesin lain, tetapi berada pada rangkaian yang berbeza? Kami memerlukan pengakaran antara rangkaian. Kami akan melihat pilihan mudah apabila penghalaan berpusat digunakan - iaitu, lalu lintas dihalakan melalui nod rangkaian khusus khas (baik, sebagai peraturan, ia digabungkan dengan nod kawalan, jadi kita akan mempunyai perkara yang sama).
Nampaknya tiada yang rumit - kami membuat antara muka jambatan pada nod kawalan, memandu trafik ke sana dan dari situ kami menghalakannya ke tempat yang kami perlukan. Tetapi masalahnya ialah klien RED mahu menggunakan rangkaian 10.0.0.0/24, dan klien HIJAU mahu menggunakan rangkaian 10.0.0.0/24. Iaitu, kita mula bersilang dengan ruang alamat. Selain itu, pelanggan tidak mahu pelanggan lain dapat membuat laluan ke rangkaian dalaman mereka, yang masuk akal. Untuk memisahkan rangkaian dan trafik data pelanggan, kami akan memperuntukkan ruang nama yang berasingan untuk setiap satu daripadanya. Ruang nama sebenarnya adalah salinan susunan rangkaian Linux, iaitu, pelanggan dalam ruang nama RED diasingkan sepenuhnya daripada pelanggan daripada ruang nama HIJAU (baik, sama ada penghalaan antara rangkaian pelanggan ini dibenarkan melalui ruang nama lalai atau pada peralatan pengangkutan huluan).
Iaitu, kita mendapat rajah berikut:
Terowong L2 menumpu dari semua nod pengkomputeran ke nod kawalan. nod di mana antara muka L3 untuk rangkaian ini terletak, setiap satu dalam ruang nama khusus untuk pengasingan.
Namun, kita terlupa perkara yang paling penting. Mesin maya mesti menyediakan perkhidmatan kepada pelanggan, iaitu, ia mesti mempunyai sekurang-kurangnya satu antara muka luaran yang boleh dicapai. Maksudnya, kita perlu keluar ke dunia luar. Terdapat pilihan yang berbeza di sini. Mari kita lakukan pilihan yang paling mudah. Kami akan menambah satu rangkaian pada setiap pelanggan, yang akan sah dalam rangkaian pembekal dan tidak akan bertindih dengan rangkaian lain. Rangkaian juga boleh bersilang dan melihat VRF yang berbeza di sisi rangkaian pembekal. Data rangkaian juga akan hidup dalam ruang nama setiap pelanggan. Walau bagaimanapun, mereka masih akan keluar ke dunia luar melalui satu antara muka fizikal (atau ikatan, yang lebih logik). Untuk memisahkan trafik pelanggan, trafik ke luar akan ditag dengan teg VLAN yang diperuntukkan kepada pelanggan.
Hasilnya, kami mendapat rajah ini:
Soalan yang munasabah ialah mengapa tidak membuat get laluan pada nod pengiraan itu sendiri? Ini bukan masalah besar; lebih-lebih lagi, jika anda menghidupkan penghala teragih (DVR), ini akan berfungsi. Dalam senario ini, kami sedang mempertimbangkan pilihan paling mudah dengan gerbang berpusat, yang digunakan secara lalai dalam Openstack. Untuk fungsi beban tinggi, mereka akan menggunakan kedua-dua penghala yang diedarkan dan teknologi pecutan seperti SR-IOV dan Passthrough, tetapi seperti yang mereka katakan, itu cerita yang sama sekali berbeza. Mula-mula, mari kita berurusan dengan bahagian asas, dan kemudian kita akan pergi ke butiran.
Sebenarnya, skema kami sudah boleh dilaksanakan, tetapi terdapat beberapa nuansa:
- Kami perlu melindungi mesin kami, iaitu, meletakkan penapis pada antara muka suis ke arah pelanggan.
- Jadikan mesin maya untuk mendapatkan alamat IP secara automatik, supaya anda tidak perlu log masuk ke dalamnya melalui konsol setiap kali dan mendaftarkan alamat tersebut.
Mari kita mulakan dengan perlindungan mesin. Untuk ini, anda boleh menggunakan iptables banal, mengapa tidak.
Iaitu, sekarang topologi kami telah menjadi sedikit lebih rumit:
Jom teruskan. Kita perlu menambah pelayan DHCP. Tempat yang paling sesuai untuk mencari pelayan DHCP bagi setiap pelanggan ialah nod kawalan yang telah disebutkan di atas, di mana ruang nama terletak:
Walau bagaimanapun, terdapat masalah kecil. Bagaimana jika semuanya but semula dan semua maklumat tentang menyewa alamat pada DHCP hilang. Adalah logik bahawa mesin akan diberikan alamat baru, yang tidak begitu mudah. Terdapat dua jalan keluar di sini - sama ada menggunakan nama domain dan menambah pelayan DNS untuk setiap pelanggan, maka alamat itu tidak akan menjadi sangat penting kepada kami (serupa dengan bahagian rangkaian dalam k8s) - tetapi terdapat masalah dengan rangkaian luaran, kerana alamat juga boleh dikeluarkan di dalamnya melalui DHCP - anda memerlukan penyegerakan dengan pelayan DNS dalam platform awan dan pelayan DNS luaran, yang pada pendapat saya tidak begitu fleksibel, tetapi agak mungkin. Atau pilihan kedua ialah menggunakan metadata - iaitu menyimpan maklumat tentang alamat yang dikeluarkan kepada mesin supaya pelayan DHCP mengetahui alamat yang hendak dikeluarkan kepada mesin jika mesin telah menerima alamat. Pilihan kedua adalah lebih mudah dan lebih fleksibel, kerana ia membolehkan anda menyimpan maklumat tambahan tentang kereta. Sekarang mari tambah metadata ejen pada rajah:
Isu lain yang juga patut dibincangkan ialah keupayaan untuk menggunakan satu rangkaian luaran oleh semua pelanggan, kerana rangkaian luaran, jika ia mesti sah di seluruh rangkaian, akan menjadi sukar - anda perlu sentiasa memperuntukkan dan mengawal peruntukan rangkaian ini. Keupayaan untuk menggunakan rangkaian pra-konfigurasi luaran tunggal untuk semua pelanggan akan sangat berguna apabila mencipta awan awam. Ini akan memudahkan untuk menggunakan mesin kerana kami tidak perlu merujuk pangkalan data alamat dan memilih ruang alamat unik untuk setiap rangkaian luaran pelanggan. Selain itu, kami boleh mendaftarkan rangkaian luaran terlebih dahulu dan pada masa penggunaan kami hanya perlu mengaitkan alamat luaran dengan mesin pelanggan.
Dan di sini NAT datang untuk membantu kami - kami hanya akan membolehkan pelanggan mengakses dunia luar melalui ruang nama lalai menggunakan terjemahan NAT. Nah, inilah masalah kecil. Ini bagus jika pelayan pelanggan bertindak sebagai pelanggan dan bukan sebagai pelayan - iaitu, ia memulakan dan bukannya menerima sambungan. Tetapi bagi kami ia akan menjadi sebaliknya. Dalam kes ini, kita perlu melakukan NAT destinasi supaya apabila menerima trafik, nod kawalan memahami bahawa trafik ini bertujuan untuk mesin maya A klien A, yang bermaksud kita perlu melakukan terjemahan NAT dari alamat luaran, contohnya 100.1.1.1 .10.0.0.1, ke alamat dalaman 100. Dalam kes ini, walaupun semua pelanggan akan menggunakan rangkaian yang sama, pengasingan dalaman dipelihara sepenuhnya. Iaitu, kita perlu melakukan dNAT dan sNAT pada nod kawalan. Sama ada hendak menggunakan rangkaian tunggal dengan alamat terapung atau rangkaian luaran, atau kedua-duanya sekali, bergantung pada perkara yang anda ingin bawa ke dalam awan. Kami tidak akan menambah alamat terapung pada rajah, tetapi akan meninggalkan rangkaian luaran yang telah ditambahkan sebelum ini - setiap pelanggan mempunyai rangkaian luarannya sendiri (dalam rajah ia ditunjukkan sebagai vlan 200 dan XNUMX pada antara muka luaran).
Hasilnya, kami menerima penyelesaian yang menarik dan pada masa yang sama yang difikirkan dengan baik, yang mempunyai fleksibiliti tertentu tetapi belum mempunyai mekanisme toleransi kesalahan.
Pertama, kita hanya mempunyai satu nod kawalan - kegagalannya akan membawa kepada keruntuhan semua sistem. Untuk menyelesaikan masalah ini, anda perlu membuat sekurang-kurangnya kuorum 3 nod. Mari tambahkan ini pada rajah:
Sememangnya, semua nod disegerakkan dan apabila nod aktif keluar, nod lain akan mengambil alih tanggungjawabnya.
Masalah seterusnya ialah cakera mesin maya. Pada masa ini, ia disimpan pada hypervisor itu sendiri, dan sekiranya berlaku masalah dengan hypervisor, kami kehilangan semua data - dan kehadiran serbuan tidak akan membantu di sini jika kami kehilangan bukan cakera, tetapi keseluruhan pelayan. Untuk melakukan ini, kita perlu membuat perkhidmatan yang akan bertindak sebagai bahagian hadapan untuk beberapa jenis storan. Jenis storan itu tidak begitu penting kepada kami, tetapi ia harus melindungi data kami daripada kegagalan kedua-dua cakera dan nod, dan mungkin keseluruhan kabinet. Terdapat beberapa pilihan di sini - sudah tentu terdapat rangkaian SAN dengan Fiber Channel, tetapi jujurlah - FC sudah menjadi peninggalan masa lalu - analog E1 dalam pengangkutan - ya, saya bersetuju, ia masih digunakan, tetapi hanya di mana ia adalah mustahil tanpanya. Oleh itu, saya tidak akan menggunakan rangkaian FC secara sukarela pada tahun 2020, kerana mengetahui bahawa terdapat alternatif lain yang lebih menarik. Walaupun untuk masing-masing, mungkin ada yang percaya bahawa FC dengan segala batasannya adalah yang kita perlukan - Saya tidak akan membantah, setiap orang mempunyai pendapat mereka sendiri. Walau bagaimanapun, penyelesaian yang paling menarik pada pendapat saya ialah menggunakan SDS, seperti Ceph.
Ceph membolehkan anda membina penyelesaian storan data yang sangat tersedia dengan sekumpulan pilihan sandaran yang mungkin, bermula dengan kod dengan semakan pariti (serupa dengan serbuan 5 atau 6) berakhir dengan replikasi data penuh ke cakera yang berbeza, dengan mengambil kira lokasi cakera dalam pelayan, dan pelayan dalam kabinet, dsb.
Untuk membina Ceph anda memerlukan 3 lagi nod. Interaksi dengan storan juga akan dijalankan melalui rangkaian menggunakan perkhidmatan storan blok, objek dan fail. Mari tambahkan storan pada skema:
Nota: anda juga boleh membuat nod pengiraan hiperconverged - ini ialah konsep menggabungkan beberapa fungsi pada satu nod - contohnya, storan+kira - tanpa mendedikasikan nod khas untuk storan ceph. Kami akan mendapat skim toleransi kesalahan yang sama - memandangkan SDS akan menempah data dengan tahap tempahan yang kami tentukan. Walau bagaimanapun, nod hiperkonvergen sentiasa menjadi kompromi - kerana nod storan tidak hanya memanaskan udara seperti yang kelihatan pada pandangan pertama (kerana tiada mesin maya padanya) - ia membelanjakan sumber CPU untuk menservis SDS (sebenarnya, ia melakukan semua replikasi dan pemulihan selepas kegagalan nod, cakera, dsb.). Iaitu, anda akan kehilangan sebahagian daripada kuasa nod pengiraan jika anda menggabungkannya dengan storan.
Semua perkara ini perlu diuruskan entah bagaimana - kami memerlukan sesuatu yang melaluinya kami boleh mencipta mesin, rangkaian, penghala maya, dll. Untuk melakukan ini, kami akan menambah perkhidmatan pada nod kawalan yang akan bertindak sebagai papan pemuka - pelanggan akan dapat menyambung ke portal ini melalui http/ https dan melakukan semua yang dia perlukan (baik, hampir).
Akibatnya, kita kini mempunyai sistem toleransi kesalahan. Semua elemen infrastruktur ini mesti diuruskan entah bagaimana. Sebelum ini telah diterangkan bahawa Openstack ialah satu set projek, setiap satunya menyediakan fungsi tertentu. Seperti yang kita lihat, terdapat lebih daripada cukup elemen yang perlu dikonfigurasikan dan dikawal. Hari ini kita akan bercakap tentang bahagian rangkaian.
Seni bina neutron
Dalam OpenStack, Neutronlah yang bertanggungjawab untuk menyambungkan port mesin maya ke rangkaian L2 biasa, memastikan penghalaan trafik antara VM yang terletak pada rangkaian L2 yang berbeza, serta penghalaan keluar, menyediakan perkhidmatan seperti NAT, IP Terapung, DHCP, dsb.
Pada tahap yang tinggi, pengendalian perkhidmatan rangkaian (bahagian asas) boleh diterangkan seperti berikut.
Apabila memulakan VM, perkhidmatan rangkaian:
- Mencipta port untuk VM (atau port) tertentu dan memberitahu perkhidmatan DHCP mengenainya;
- Peranti rangkaian maya baharu dicipta (melalui libvirt);
- VM bersambung ke port yang dibuat dalam langkah 1;
Anehnya, kerja Neutron adalah berdasarkan mekanisme standard yang biasa kepada semua orang yang pernah menyelami Linux - ruang nama, iptables, jambatan linux, openvswitch, conntrack, dll.
Ia harus segera dijelaskan bahawa Neutron bukan pengawal SDN.
Neutron terdiri daripada beberapa komponen yang saling berkaitan:
Openstack-neutron-server ialah daemon yang berfungsi dengan permintaan pengguna melalui API. Syaitan ini tidak terlibat dalam mendaftarkan sebarang sambungan rangkaian, tetapi memberikan maklumat yang diperlukan untuk ini kepada pemalamnya, yang kemudiannya mengkonfigurasi elemen rangkaian yang dikehendaki. Ejen neutron pada nod OpenStack mendaftar dengan pelayan Neutron.
Pelayan-neutron sebenarnya adalah aplikasi yang ditulis dalam python, yang terdiri daripada dua bahagian:
- perkhidmatan REHAT
- Pemalam Neutron (teras/perkhidmatan)
Perkhidmatan REST direka untuk menerima panggilan API daripada komponen lain (contohnya, permintaan untuk memberikan beberapa maklumat, dsb.)
Pemalam ialah komponen/modul perisian pemalam yang dipanggil semasa permintaan API - iaitu, atribusi sesuatu perkhidmatan berlaku melaluinya. Pemalam dibahagikan kepada dua jenis - perkhidmatan dan akar. Sebagai peraturan, pemalam kuda bertanggungjawab terutamanya untuk mengurus ruang alamat dan sambungan L2 antara VM, dan pemalam perkhidmatan sudah menyediakan fungsi tambahan seperti VPN atau FW.
Senarai pemalam yang tersedia hari ini boleh dilihat sebagai contoh
Terdapat beberapa pemalam perkhidmatan, tetapi hanya terdapat satu pemalam kuda.
Openstack-neutron-ml2 ialah pemalam akar Openstack standard. Pemalam ini mempunyai seni bina modular (tidak seperti pendahulunya) dan mengkonfigurasi perkhidmatan rangkaian melalui pemacu yang disambungkan kepadanya. Kami akan melihat pemalam itu sendiri sedikit kemudian, kerana sebenarnya ia memberikan fleksibiliti yang OpenStack ada dalam bahagian rangkaian. Plugin root boleh diganti (contohnya, Contrail Networking melakukan penggantian sedemikian).
Perkhidmatan RPC (rabbitmq-server) β perkhidmatan yang menyediakan pengurusan baris gilir dan interaksi dengan perkhidmatan OpenStack lain, serta interaksi antara ejen perkhidmatan rangkaian.
Ejen rangkaian β ejen yang terletak dalam setiap nod, yang melaluinya perkhidmatan rangkaian dikonfigurasikan.
Terdapat beberapa jenis ejen.
Ejen utama ialah ejen L2. Ejen ini dijalankan pada setiap hipervisor, termasuk nod kawalan (lebih tepat, pada semua nod yang menyediakan sebarang perkhidmatan untuk penyewa) dan fungsi utamanya adalah untuk menyambungkan mesin maya ke rangkaian L2 biasa, dan juga menjana makluman apabila sebarang peristiwa berlaku ( contohnya lumpuhkan/dayakan port).
Agen seterusnya, tidak kurang pentingnya ialah ejen L3. Secara lalai, ejen ini berjalan secara eksklusif pada nod rangkaian (selalunya nod rangkaian digabungkan dengan nod kawalan) dan menyediakan penghalaan antara rangkaian penyewa (kedua-duanya antara rangkaiannya dan rangkaian penyewa lain, dan boleh diakses oleh dunia luar, menyediakan NAT, serta perkhidmatan DHCP). Walau bagaimanapun, apabila menggunakan DVR (penghala teragih), keperluan untuk pemalam L3 juga muncul pada nod pengiraan.
Ejen L3 menggunakan ruang nama Linux untuk menyediakan setiap penyewa satu set rangkaian terpencilnya sendiri dan kefungsian penghala maya yang menghalakan trafik dan menyediakan perkhidmatan get laluan untuk rangkaian Lapisan 2.
Pangkalan Data β pangkalan data pengecam rangkaian, subnet, port, pool, dsb.
Malah, Neutron menerima permintaan API daripada penciptaan mana-mana entiti rangkaian, mengesahkan permintaan dan melalui RPC (jika ia mengakses beberapa pemalam atau ejen) atau REST API (jika ia berkomunikasi dalam SDN) menghantar kepada ejen (melalui pemalam) arahan yang diperlukan untuk mengatur perkhidmatan yang diminta.
Sekarang mari kita beralih kepada pemasangan ujian (bagaimana ia digunakan dan apa yang disertakan di dalamnya, kita akan lihat kemudian dalam bahagian praktikal) dan lihat di mana setiap komponen terletak:
(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. Kini anda berbaloi untuk meluangkan sedikit masa pada pemalam ML2.
Lapisan Modular 2
Seperti yang dinyatakan di atas, pemalam itu ialah pemalam akar OpenStack standard dan mempunyai seni bina modular.
Pendahulu pemalam ML2 mempunyai struktur monolitik, yang tidak membenarkan, contohnya, menggunakan gabungan beberapa teknologi dalam satu pemasangan. Sebagai contoh, anda tidak boleh menggunakan kedua-dua openvswitch dan linuxbridge pada masa yang sama - sama ada yang pertama atau yang kedua. Atas sebab ini, pemalam ML2 dengan seni binanya telah dicipta.
ML2 mempunyai dua komponen - dua jenis pemacu: Jenis pemacu dan pemacu Mekanisme.
Jenis pemandu tentukan teknologi yang akan digunakan untuk mengatur sambungan rangkaian, contohnya VxLAN, VLAN, GRE. Pada masa yang sama, pemandu membenarkan penggunaan teknologi yang berbeza. Teknologi standard ialah enkapsulasi VxLAN untuk rangkaian tindanan dan rangkaian luaran vlan.
Pemacu jenis termasuk jenis rangkaian berikut:
Flat - rangkaian tanpa tag
VLAN - rangkaian bertanda
Tempatan β jenis rangkaian khas untuk pemasangan semua-dalam-satu (pemasangan sedemikian diperlukan sama ada untuk pembangun atau untuk latihan)
GrΔ β rangkaian tindanan menggunakan terowong GRE
VxLAN β rangkaian tindanan menggunakan terowong VxLAN
Pemacu mekanisme tentukan alat yang memastikan organisasi teknologi yang dinyatakan dalam pemacu jenis - contohnya, openvswitch, sr-iov, opendaylight, OVN, dsb.
Bergantung pada pelaksanaan pemacu ini, sama ada ejen yang dikawal oleh Neutron akan digunakan, atau sambungan kepada pengawal SDN luaran akan digunakan, yang mengurus semua isu yang berkaitan dengan mengatur rangkaian L2, penghalaan, dsb.
Contoh: jika kita menggunakan ML2 bersama-sama dengan OVS, maka ejen L2 dipasang pada setiap nod pengkomputeran yang menguruskan OVS. Walau bagaimanapun, jika kita menggunakan, sebagai contoh, OVN atau OpenDayLight, maka kawalan OVS berada di bawah bidang kuasa mereka - Neutron, melalui pemalam root, memberikan arahan kepada pengawal, dan ia sudah melakukan apa yang diberitahu.
Mari kita teliti pada Open vSwitch
Pada masa ini, salah satu komponen utama OpenStack ialah Open vSwitch.
Apabila memasang OpenStack tanpa sebarang SDN vendor tambahan seperti Juniper Contrail atau Nokia Nuage, OVS ialah komponen rangkaian utama rangkaian awan dan, bersama-sama dengan iptables, conntrack, ruang nama, membolehkan anda mengatur rangkaian tindanan berbilang penyewaan sepenuhnya. Sememangnya, komponen ini boleh diganti, contohnya, apabila menggunakan penyelesaian SDN proprietari (vendor) pihak ketiga.
OVS ialah suis perisian sumber terbuka yang direka untuk digunakan dalam persekitaran maya sebagai pemaju trafik maya.
Pada masa ini, OVS mempunyai fungsi yang sangat baik, termasuk teknologi seperti QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, dll.
Nota: OVS pada mulanya tidak difikirkan sebagai suis lembut untuk fungsi telekom yang sangat dimuatkan dan lebih direka untuk fungsi IT yang kurang memerlukan lebar jalur seperti pelayan WEB atau pelayan mel. Walau bagaimanapun, OVS sedang dibangunkan lagi dan pelaksanaan semasa OVS telah banyak meningkatkan prestasi dan keupayaannya, yang membolehkan ia digunakan oleh pengendali telekom dengan fungsi yang sangat sarat, contohnya, terdapat pelaksanaan OVS dengan sokongan untuk pecutan DPDK.
Terdapat tiga komponen penting OVS yang perlu anda ketahui:
- Modul kernel β komponen yang terletak dalam ruang kernel yang memproses trafik berdasarkan peraturan yang diterima daripada elemen kawalan;
- vSwitch daemon (ovs-vswitchd) ialah proses yang dilancarkan dalam ruang pengguna yang bertanggungjawab untuk pengaturcaraan modul kernel - iaitu, ia secara langsung mewakili logik operasi suis
- Pelayan pangkalan data - pangkalan data tempatan yang terletak pada setiap hos yang menjalankan OVS, di mana konfigurasi disimpan. Pengawal SDN boleh berkomunikasi melalui modul ini menggunakan protokol OVSDB.
Semua ini disertakan dengan set utiliti diagnostik dan pengurusan, seperti ovs-vsctl, ovs-appctl, ovs-ofctl, dsb.
Pada masa ini, Openstack digunakan secara meluas oleh operator telekom untuk memindahkan fungsi rangkaian kepadanya, seperti EPC, SBC, HLR, dll. Sesetengah fungsi boleh hidup tanpa masalah dengan OVS sebagaimana adanya, tetapi sebagai contoh, EPC memproses trafik pelanggan - kemudian ia melalui jumlah trafik yang besar (kini volum trafik mencecah beberapa ratus gigabit sesaat). Sememangnya, memandu trafik sedemikian melalui ruang kernel (memandangkan penghantar terletak di sana secara lalai) bukanlah idea terbaik. Oleh itu, OVS sering digunakan sepenuhnya dalam ruang pengguna menggunakan teknologi pecutan DPDK untuk memajukan trafik dari NIC ke ruang pengguna memintas kernel.
Nota: untuk awan yang digunakan untuk fungsi telekom, adalah mungkin untuk mengeluarkan trafik daripada nod pengiraan yang memintas OVS terus kepada peralatan menukar. Mekanisme SR-IOV dan Passthrough digunakan untuk tujuan ini.
Bagaimanakah ini berfungsi pada susun atur sebenar?
Nah, sekarang mari kita beralih ke bahagian praktikal dan lihat bagaimana semuanya berfungsi dalam amalan.
Mula-mula, mari kita gunakan pemasangan Openstack yang mudah. Memandangkan saya tidak mempunyai set pelayan di tangan untuk eksperimen, kami akan memasang prototaip pada satu pelayan fizikal daripada mesin maya. Ya, secara semula jadi, penyelesaian sedemikian tidak sesuai untuk tujuan komersial, tetapi untuk melihat contoh bagaimana rangkaian berfungsi dalam Openstack, pemasangan sedemikian sudah cukup untuk mata. Lebih-lebih lagi, pemasangan sedemikian lebih menarik untuk tujuan latihan - kerana anda boleh menangkap lalu lintas, dsb.
Oleh kerana kita hanya perlu melihat bahagian asas, kita tidak boleh menggunakan beberapa rangkaian tetapi menaikkan segala-galanya menggunakan hanya dua rangkaian, dan rangkaian kedua dalam susun atur ini akan digunakan secara eksklusif untuk akses kepada pelayan bawah awan dan DNS. Kami tidak akan menyentuh rangkaian luaran buat masa ini - ini adalah topik untuk artikel besar yang berasingan.
Jadi, mari kita mulakan mengikut urutan. Pertama, sedikit teori. Kami akan memasang Openstack menggunakan TripleO (Openstack pada Openstack). Intipati TripleO ialah kami memasang Openstack all-in-one (iaitu, pada satu nod), dipanggil undercloud, dan kemudian menggunakan keupayaan Openstack yang digunakan untuk memasang Openstack bertujuan untuk operasi, dipanggil overcloud. Undercloud akan menggunakan keupayaan sedia ada untuk mengurus pelayan fizikal (logam kosong) - projek Ironic - untuk menyediakan hypervisor yang akan melaksanakan peranan pengiraan, kawalan, nod storan. Iaitu, kami tidak menggunakan sebarang alatan pihak ketiga untuk menggunakan Openstack - kami menggunakan Openstack menggunakan Openstack. Ia akan menjadi lebih jelas apabila pemasangan berlangsung, jadi kami tidak akan berhenti di situ dan bergerak ke hadapan.
Nota: Dalam artikel ini, demi kesederhanaan, saya tidak menggunakan pengasingan rangkaian untuk rangkaian Openstack dalaman, tetapi semuanya digunakan hanya menggunakan satu rangkaian. Walau bagaimanapun, kehadiran atau ketiadaan pengasingan rangkaian tidak menjejaskan fungsi asas penyelesaian - semuanya akan berfungsi sama seperti semasa menggunakan pengasingan, tetapi trafik akan mengalir pada rangkaian yang sama. Untuk pemasangan komersial, secara semula jadi perlu menggunakan pengasingan menggunakan vlan dan antara muka yang berbeza. Contohnya, trafik pengurusan storan ceph dan trafik data itu sendiri (akses mesin kepada cakera, dsb.) apabila diasingkan menggunakan subnet yang berbeza (Pengurusan storan dan Storan) dan ini membolehkan anda menjadikan penyelesaian lebih tahan terhadap kesalahan dengan membahagikan trafik ini, contohnya , merentasi port yang berbeza, atau menggunakan profil QoS yang berbeza untuk trafik yang berbeza supaya trafik data tidak memerah trafik isyarat. Dalam kes kami, mereka akan menggunakan rangkaian yang sama dan sebenarnya ini tidak mengehadkan kami dalam apa jua cara.
Nota: Memandangkan kita akan menjalankan mesin maya dalam persekitaran maya berdasarkan mesin maya, kita perlu mendayakan virtualisasi bersarang terlebih dahulu.
Anda boleh menyemak sama ada virtualisasi bersarang didayakan 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 membolehkan sokongan untuk virtualisasi bersarang mengikut mana-mana panduan yang anda temui di rangkaian, contohnya .
Kita perlu memasang litar berikut dari mesin maya:
Dalam kes saya, untuk menyambungkan mesin maya yang merupakan sebahagian daripada pemasangan masa hadapan (dan saya mendapat 7 daripadanya, tetapi anda boleh bertahan dengan 4 jika anda tidak mempunyai banyak sumber), saya menggunakan OpenvSwitch. Saya mencipta satu jambatan ovs dan menyambungkan mesin maya kepadanya melalui kumpulan port. Untuk melakukan ini, saya mencipta fail 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 kumpulan port diisytiharkan di sini - dua akses dan satu batang (yang terakhir diperlukan untuk pelayan DNS, tetapi anda boleh melakukannya tanpanya, atau memasangnya pada mesin hos - yang mana lebih mudah untuk anda). Seterusnya, menggunakan templat ini, kami mengisytiharkan 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 ~]# Nota: dalam senario ini, alamat pada port ovs-br1 tidak akan dapat diakses kerana ia tidak mempunyai teg vlan. Untuk membetulkannya, anda perlu mengeluarkan arahan sudo ovs-vsctl set port ovs-br1 tag=100. Walau bagaimanapun, selepas but semula, tag ini akan hilang (jika sesiapa tahu cara untuk memastikan ia kekal di tempatnya, saya akan sangat berterima kasih). Tetapi ini tidak begitu penting, kerana kami hanya memerlukan alamat ini semasa pemasangan dan tidak memerlukannya apabila Openstack digunakan sepenuhnya.
Seterusnya, kami mencipta 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=ttyS0Semasa pemasangan, anda menetapkan semua parameter yang diperlukan, seperti nama mesin, kata laluan, pengguna, pelayan ntp, dll., anda boleh segera mengkonfigurasi port, tetapi bagi saya secara peribadi, selepas pemasangan, lebih mudah untuk log masuk ke mesin melalui konsol dan betulkan fail yang diperlukan. Jika anda sudah mempunyai imej sedia, anda boleh menggunakannya, atau lakukan apa yang saya lakukan - muat turun imej Centos 7 yang minimum dan gunakannya untuk memasang VM.
Selepas pemasangan berjaya, anda sepatutnya mempunyai mesin maya di mana anda boleh memasang undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPertama, pasang alat yang diperlukan untuk proses pemasangan:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Pemasangan Undercloud
Kami mencipta pengguna tindanan, menetapkan kata laluan, menambahnya pada sudoer dan memberinya keupayaan untuk melaksanakan arahan root melalui sudo tanpa perlu memasukkan kata laluan:
useradd stack
passwd stack
echo βstack ALL=(root) NOPASSWD:ALLβ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackSekarang kami menentukan nama undercloud penuh dalam fail hos:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Seterusnya, kami menambah repositori dan memasang perisian yang kami perlukan:
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-ansibleNota: jika anda tidak bercadang untuk memasang ceph, maka anda tidak perlu memasukkan arahan berkaitan ceph. Saya menggunakan keluaran Queens, tetapi anda boleh menggunakan mana-mana yang anda suka.
Seterusnya, salin fail konfigurasi undercloud ke timbunan direktori rumah pengguna:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSekarang kita perlu membetulkan fail ini, menyesuaikannya dengan pemasangan kita.
Anda perlu menambah baris ini pada permulaan fail:
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 pergi melalui tetapan:
undercloud_hostname β nama penuh pelayan undercloud, mesti sepadan dengan entri pada pelayan DNS
local_ip β alamat bawah awan tempatan ke arah penyediaan rangkaian
network_gateway β alamat setempat yang sama, yang akan bertindak sebagai pintu masuk untuk akses ke dunia luar semasa pemasangan nod awan mendung, juga bertepatan dengan ip tempatan
undercloud_public_host β alamat API luaran, sebarang alamat percuma daripada rangkaian peruntukan diberikan
undercloud_admin_host alamat API dalaman, sebarang alamat percuma daripada rangkaian peruntukan diberikan
undercloud_nameservers β pelayan DNS
generate_service_certificate - baris ini sangat penting dalam contoh semasa, kerana jika anda tidak menetapkannya kepada palsu, anda akan menerima ralat semasa pemasangan, masalah diterangkan pada penjejak pepijat Red Hat
antara muka_tempatan antara muka dalam penyediaan rangkaian. Antara muka ini akan dikonfigurasikan semula semasa penggunaan undercloud, jadi anda perlu mempunyai dua antara muka pada undercloud - satu untuk mengaksesnya, yang kedua untuk peruntukan
local_mtu - MTU. Oleh kerana kami mempunyai makmal ujian dan saya mempunyai MTU sebanyak 1500 pada port suis OVS, adalah perlu untuk menetapkannya kepada 1450 supaya paket yang terkandung dalam VxLAN boleh melalui
network_cidr - rangkaian peruntukan
penyamaran β menggunakan NAT untuk mengakses rangkaian luaran
rangkaian_penyamaran - rangkaian yang akan NATed
dhcp_start β alamat permulaan kumpulan alamat dari mana alamat akan diberikan kepada nod semasa penggunaan awan berlebihan
dhcp_end β alamat akhir kumpulan alamat yang alamatnya akan diberikan kepada nod semasa penggunaan awan berlebihan
inspection_iprange β kumpulan alamat yang diperlukan untuk introspeksi (tidak boleh bertindih dengan kumpulan di atas)
penjadual_maks_percubaan β bilangan maksimum percubaan untuk memasang overcloud (mesti lebih besar daripada atau sama dengan bilangan nod)
Selepas fail diterangkan, anda boleh memberikan arahan untuk menggunakan undercloud:
openstack undercloud install
Prosedur mengambil masa dari 10 hingga 30 minit bergantung pada seterika anda. Akhirnya anda akan melihat output seperti ini:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Output ini mengatakan bahawa anda telah berjaya memasang undercloud dan kini anda boleh menyemak status undercloud dan meneruskan untuk memasang overcloud.
Jika anda melihat pada output ifconfig, anda akan melihat bahawa antara muka jambatan baharu 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 0Penggunaan overcloud kini akan dijalankan melalui antara muka ini.
Daripada output di bawah anda dapat melihat bahawa kami mempunyai semua perkhidmatan pada satu nod:
(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 ialah konfigurasi bahagian rangkaian bawah awan:
(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 ~]$Pemasangan overcloud
Pada masa ini kami hanya mempunyai undercloud, dan kami tidak mempunyai nod yang mencukupi dari mana overcloud akan dipasang. Oleh itu, pertama sekali, mari kita gunakan mesin maya yang kita perlukan. Semasa penggunaan, undercloud sendiri akan memasang OS dan perisian yang diperlukan pada mesin overcloud - iaitu, kita tidak perlu menggunakan mesin sepenuhnya, tetapi hanya mencipta cakera (atau cakera) untuknya dan menentukan parameternya - iaitu , sebenarnya, kami mendapat pelayan kosong tanpa OS dipasang padanya.
Mari pergi ke folder dengan cakera mesin maya kami dan buat cakera dengan saiz 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 160GMemandangkan kami beroperasi sebagai root, kami perlu menukar pemilik cakera ini supaya tidak mendapat masalah dengan hak:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Nota: jika anda tidak bercadang untuk memasang ceph untuk mengkajinya, maka arahan tidak membuat sekurang-kurangnya 3 nod dengan sekurang-kurangnya dua cakera, tetapi dalam templat menunjukkan bahawa cakera maya vda, vdb, dll. akan digunakan.
Hebat, sekarang kita perlu mentakrifkan 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 penghujungnya terdapat arahan -print-xml > /tmp/storage-1.xml, yang mencipta fail xml dengan penerangan setiap mesin dalam folder /tmp/; jika anda tidak menambahnya, anda tidak akan dapat mengenal pasti mesin maya.
Sekarang kita perlu menentukan semua mesin ini dalam 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 ~]#Kini nuansa kecil - tripleO menggunakan IPMI untuk mengurus pelayan semasa pemasangan dan introspeksi.
Introspeksi ialah proses memeriksa perkakasan untuk mendapatkan parameternya yang diperlukan untuk penyediaan nod selanjutnya. Introspeksi dijalankan menggunakan ironik, perkhidmatan yang direka untuk berfungsi dengan pelayan logam kosong.
Tetapi inilah masalahnya - sementara pelayan IPMI perkakasan mempunyai port yang berasingan (atau port yang dikongsi, tetapi ini tidak penting), maka mesin maya tidak mempunyai port sedemikian. Di sini tongkat yang dipanggil vbmc datang untuk membantu kami - utiliti yang membolehkan anda meniru port IPMI. Nuansa ini patut diberi perhatian terutamanya bagi mereka yang ingin menubuhkan makmal sedemikian pada hipervisor ESXI - jujur, saya tidak tahu sama ada ia mempunyai analog vbmc, jadi patutlah tertanya-tanya tentang isu ini sebelum menggunakan segala-galanya .
Pasang vbmc:
yum install yum install python2-virtualbmcJika OS anda tidak dapat mencari pakej, kemudian tambahkan repositori:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSekarang kami menyediakan utiliti. Segala-galanya di sini adalah cetek sehingga memalukan. Sekarang adalah logik bahawa tiada pelayan dalam senarai vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Untuk mereka muncul, mereka mesti diisytiharkan 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 ~]#Saya fikir sintaks arahan adalah jelas tanpa penjelasan. Namun, buat masa ini semua sesi kami dalam status DOWN. Untuk mereka beralih ke status UP, anda perlu mendayakannya:
[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 membetulkan peraturan firewall (atau melumpuhkannya 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 pergi ke undercloud dan semak sama ada semuanya berfungsi. Alamat mesin hos ialah 192.168.255.200, di bawah awan kami menambah pakej ipmitool yang diperlukan semasa penyediaan untuk penggunaan:
[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 berjaya melancarkan nod kawalan melalui vbmc. Sekarang mari kita matikan dan teruskan:
[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 seterusnya ialah introspeksi nod di mana overcloud akan dipasang. Untuk melakukan ini, kami perlu menyediakan fail json dengan penerangan nod kami. Sila ambil perhatian bahawa, tidak seperti pemasangan pada pelayan kosong, fail tersebut menunjukkan port yang vbmc dijalankan untuk setiap mesin.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Nota: nod kawalan mempunyai dua antara muka, tetapi dalam kes ini ini tidak penting, dalam pemasangan ini satu akan cukup untuk kita.
Sekarang kami menyediakan fail json. Kita perlu menunjukkan alamat popi pelabuhan yang melaluinya peruntukan akan dijalankan, parameter nod, beri nama dan tunjukkan cara untuk sampai 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 menyediakan imej untuk ironis. Untuk melakukan ini, muat turunnya melalui wget dan pasang:
(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 ~]$Memuat naik imej ke bawah awan:
(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 ~]$Menyemak bahawa semua imej telah dimuatkan
(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 lagi perkara - anda perlu menambah pelayan 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 boleh memberikan arahan 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 ralat. Mari semak sama ada semua nod berada dalam keadaan 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 nod berada dalam keadaan yang berbeza, biasanya boleh diurus, maka sesuatu telah berlaku dan anda perlu melihat log dan mengetahui mengapa ini berlaku. Perlu diingat bahawa dalam senario ini kami menggunakan virtualisasi dan mungkin terdapat pepijat yang dikaitkan dengan penggunaan mesin maya atau vbmc.
Seterusnya, kita perlu menunjukkan nod mana yang akan melaksanakan fungsi mana - iaitu, menunjukkan profil yang mana nod akan digunakan:
(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 nod:
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 semak sama ada kami melakukan semuanya dengan betul:
(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 betul, kami memberikan arahan untuk menggunakan 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 pemasangan sebenar, templat tersuai secara semula jadi akan digunakan, dalam kes kami ini akan merumitkan prosesnya, kerana setiap pengeditan dalam templat perlu dijelaskan. Seperti yang telah ditulis sebelum ini, pemasangan yang mudah pun sudah cukup untuk kita melihat bagaimana ia berfungsi.
Nota: pembolehubah qemu --libvirt-type diperlukan dalam kes ini, kerana kami akan menggunakan virtualisasi bersarang. Jika tidak, anda tidak akan dapat menjalankan mesin maya.
Kini anda mempunyai kira-kira sejam, atau mungkin lebih (bergantung pada keupayaan perkakasan) dan anda hanya boleh berharap selepas masa ini anda akan melihat mesej 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 ~]$Kini anda mempunyai versi openstack yang hampir lengkap, di mana anda boleh belajar, mencuba, dsb.
Mari periksa sama ada semuanya berfungsi dengan baik. Dalam timbunan direktori rumah pengguna terdapat dua fail - satu stackrc (untuk menguruskan undercloud) dan overcloudrc kedua (untuk menguruskan overcloud). Fail ini mesti dinyatakan sebagai sumber, kerana ia mengandungi maklumat yang diperlukan untuk pengesahan.
(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 ~]$Pemasangan saya masih memerlukan satu sentuhan kecil - menambah laluan pada pengawal, kerana mesin yang saya gunakan adalah pada rangkaian yang berbeza. Untuk melakukan ini, pergi ke control-1 di bawah akaun heat-admin dan daftarkan laluan
(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 boleh pergi ke kaki langit. Semua maklumat - alamat, log masuk dan kata laluan - terdapat dalam fail /home/stack/overcloudrc. Gambar rajah akhir kelihatan seperti ini:
Dengan cara ini, dalam pemasangan kami, alamat mesin telah dikeluarkan melalui DHCP dan, seperti yang anda lihat, ia dikeluarkan "secara rawak". Anda boleh menentukan secara tegar dalam templat alamat mana yang harus dilampirkan pada mesin mana semasa penggunaan, jika anda memerlukannya.
Bagaimanakah aliran trafik antara mesin maya?
Dalam artikel ini kita akan melihat tiga pilihan untuk lalu lintas lalu lintas
- Dua mesin pada satu hipervisor pada satu rangkaian L2
- Dua mesin pada hypervisor berbeza pada rangkaian L2 yang sama
- Dua mesin pada rangkaian berbeza (perakaran merentas rangkaian)
Kes dengan akses kepada dunia luar melalui rangkaian luaran, menggunakan alamat terapung, serta penghalaan teragih, kami akan pertimbangkan kali seterusnya, buat masa ini kami akan memberi tumpuan kepada trafik dalaman.
Untuk menyemak, mari kita susun rajah berikut:
Kami telah mencipta 4 mesin maya - 3 pada satu rangkaian L2 - net-1, dan 1 lagi pada rangkaian 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 hipervisor apa yang terdapat pada mesin yang dicipta:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Mesin vm-1 dan vm-3 terletak pada compute-0, mesin vm-2 dan vm-4 terletak pada nod compute-1.
Di samping itu, penghala maya telah dicipta untuk membolehkan penghalaan antara rangkaian yang ditentukan:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Penghala mempunyai dua port maya, yang bertindak sebagai pintu masuk untuk rangkaian:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Tetapi sebelum kita melihat bagaimana trafik mengalir, mari kita lihat apa yang kita ada pada nod kawalan (yang juga nod rangkaian) dan pada nod pengiraan. Mari kita mulakan dengan nod pengiraan.
[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 ~]$Pada masa ini, nod mempunyai tiga jambatan ovs - br-int, br-tun, br-ex. Di antara mereka, seperti yang kita lihat, terdapat satu set antara muka. Untuk memudahkan pemahaman, mari kita plot semua antara muka ini pada rajah dan lihat apa yang berlaku.
Melihat kepada alamat di mana terowong VxLAN dinaikkan, dapat dilihat bahawa satu terowong dinaikkan untuk mengira-1 (192.168.255.26), terowong kedua kelihatan kepada kawalan-1 (192.168.255.15). Tetapi perkara yang paling menarik ialah br-ex tidak mempunyai antara muka fizikal, dan jika anda melihat aliran yang dikonfigurasikan, anda dapat melihat bahawa jambatan ini hanya boleh menjatuhkan trafik pada masa 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 boleh lihat dari output, alamat diskrukan terus ke port fizikal, dan bukan ke antara muka jambatan maya.
[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 ~]$
Mengikut peraturan pertama, semua yang datang dari port phy-br-ex mesti dibuang.
Sebenarnya, pada masa ini tiada tempat lain untuk trafik masuk ke jambatan ini kecuali dari antara muka ini (antara muka dengan br-int), dan berdasarkan titisan, trafik BUM telah pun masuk ke dalam jambatan.
Iaitu, trafik boleh meninggalkan nod ini hanya melalui terowong VxLAN dan tiada yang lain. Walau bagaimanapun, jika anda menghidupkan DVR, keadaan akan berubah, tetapi kami akan menanganinya di lain masa. Apabila menggunakan pengasingan rangkaian, contohnya menggunakan vlan, anda tidak akan mempunyai satu antara muka L3 dalam vlan 0, tetapi beberapa antara muka. Walau bagaimanapun, trafik VxLAN akan meninggalkan nod dengan cara yang sama, tetapi juga terkandung dalam beberapa jenis vlan khusus.
Kami telah menyusun nod pengiraan, mari kita beralih ke nod kawalan.
[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 ~]$Malah, kita boleh mengatakan bahawa semuanya adalah sama, tetapi alamat IP tidak lagi pada antara muka fizikal tetapi pada jambatan maya. Ini dilakukan kerana pelabuhan ini adalah pelabuhan yang melaluinya trafik akan keluar ke dunia luar.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Pelabuhan ini diikat pada jambatan br-ex dan memandangkan tiada teg vlan padanya, pelabuhan ini ialah pelabuhan batang di mana semua vlan dibenarkan, kini lalu lintas keluar tanpa teg, seperti yang ditunjukkan oleh vlan-id 0 dalam keluaran di atas.
Semua yang lain pada masa ini adalah serupa dengan nod pengiraan - jambatan yang sama, terowong yang sama pergi ke dua nod pengiraan.
Kami tidak akan mempertimbangkan nod storan dalam artikel ini, tetapi untuk memahami adalah perlu untuk mengatakan bahawa bahagian rangkaian nod ini adalah cetek sehingga memalukan. Dalam kes kami, hanya terdapat satu port fizikal (eth0) dengan alamat IP yang diberikan kepadanya dan itu sahaja. Tiada terowong VxLAN, jambatan terowong, dsb. - tiada ovs sama sekali, kerana tiada gunanya. Apabila menggunakan pengasingan rangkaian, nod ini akan mempunyai dua antara muka (port fizikal, bodny, atau hanya dua vlan - tidak mengapa - ia bergantung pada apa yang anda mahu) - satu untuk pengurusan, yang kedua untuk trafik (menulis ke cakera VM , membaca daripada cakera, dsb.)
Kami mengetahui apa yang kami ada pada nod tanpa adanya sebarang perkhidmatan. Sekarang mari kita lancarkan 4 mesin maya dan lihat bagaimana skema yang diterangkan di atas berubah - kita sepatutnya mempunyai port, penghala maya, dsb.
Setakat ini rangkaian kami kelihatan seperti ini:
Kami mempunyai dua mesin maya pada setiap nod komputer. Menggunakan compute-0 sebagai contoh, mari 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 mempunyai satu antara muka maya - 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 ~]$
Antara muka ini kelihatan dalam jambatan 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 daripada output, terdapat hanya dua antara muka dalam jambatan - tap95d96a75-a0 dan qvb95d96a75-a0.
Di sini anda perlu memikirkan sedikit tentang jenis peranti rangkaian maya dalam OpenStack:
vtap - antara muka maya yang dilampirkan pada contoh (VM)
qbr - jambatan Linux
qvb dan qvo - pasangan vEth disambungkan ke jambatan Linux dan jambatan vSwitch Buka
br-int, br-tun, br-vlan β Buka jambatan vSwitch
patch-, int-br-, phy-br- - Buka antara muka patch vSwitch yang menyambungkan jambatan
qg, qr, ha, fg, sg - Buka port vSwitch yang digunakan oleh peranti maya untuk menyambung ke OVS
Seperti yang anda faham, jika kita mempunyai port qvb95d96a75-a0 dalam jambatan, yang merupakan pasangan vEth, maka di suatu tempat terdapat rakan sejawatannya, yang secara logiknya harus dipanggil qvo95d96a75-a0. Mari lihat port apa yang ada pada 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 kita dapat lihat, pelabuhan berada dalam br-int. Br-int bertindak sebagai suis yang menamatkan port mesin maya. Selain qvo95d96a75-a0, port qvo5bd37136-47 kelihatan dalam output. Ini adalah port ke mesin maya kedua. Akibatnya, rajah kami kini kelihatan seperti ini:
Soalan yang sepatutnya menarik minat pembaca yang prihatin - apakah jambatan linux antara port mesin maya dan port OVS? Hakikatnya ialah untuk melindungi mesin, kumpulan keselamatan digunakan, yang tidak lebih daripada iptables. OVS tidak berfungsi dengan iptables, jadi "tongkat" ini dicipta. Walau bagaimanapun, ia menjadi usang - ia digantikan dengan conntrack dalam keluaran baharu.
Iaitu, akhirnya skema kelihatan seperti ini:
Dua mesin pada satu hipervisor pada satu rangkaian L2
Memandangkan kedua-dua VM ini terletak pada rangkaian L2 yang sama dan pada hypervisor yang sama, trafik antara mereka secara logik akan mengalir secara tempatan melalui br-int, kerana kedua-dua mesin akan berada pada 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 berbeza pada rangkaian L2 yang sama
Sekarang mari kita lihat bagaimana trafik akan pergi antara dua mesin pada rangkaian L2 yang sama, tetapi terletak pada hypervisor yang berbeza. Sejujurnya, tiada apa yang akan berubah, cuma trafik antara hypervisor akan melalui terowong vxlan. Mari kita lihat satu contoh.
Alamat mesin maya di antaranya kami akan menonton trafik:
[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 jadual pemajuan dalam br-int pada compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Trafik harus pergi ke port 2 - mari lihat jenis port itu:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Ini adalah patch-tun - iaitu antara muka dalam br-tun. Mari lihat apa yang berlaku kepada pakej pada 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 dibungkus dalam VxLAN dan dihantar ke port 2. Mari lihat ke mana port 2 membawa:
[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 ialah terowong vxlan pada compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Mari pergi ke compute-1 dan lihat apa yang berlaku seterusnya dengan pakej:
[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 berada dalam jadual pemajuan br-int pada compute-1, dan seperti yang dapat dilihat daripada output di atas, ia boleh dilihat melalui port 2, iaitu port ke arah 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 bahawa dalam br-int pada compute-1 terdapat popi destinasi:
[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 ~]$ Iaitu, paket yang diterima akan terbang ke port 3, di belakangnya sudah ada mesin maya contoh-00000003.
Keindahan menggunakan Openstack untuk pembelajaran pada infrastruktur maya ialah kita boleh menangkap trafik antara hypervisor dengan mudah dan melihat apa yang berlaku dengannya. Inilah yang akan kita lakukan sekarang, jalankan tcpdump pada port vnet ke arah compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Baris pertama menunjukkan bahawa Patek dari alamat 10.0.1.85 pergi ke alamat 10.0.1.88 (trafik ICMP), dan ia dibungkus dalam paket VxLAN dengan vni 22 dan paket pergi dari hos 192.168.255.19 (komputasi-0) ke hos 192.168.255.26 .1 ( hitung-XNUMX). Kita boleh menyemak sama ada VNI sepadan dengan yang dinyatakan dalam ovs.
Mari kembali ke baris ini actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 ialah vni dalam sistem nombor heksadesimal. Mari tukar nombor ini kepada sistem ke-16:
16 = 6*16^0+1*16^1 = 6+16 = 22Iaitu, vni sepadan dengan realiti.
Baris kedua menunjukkan trafik balik, baik, tidak ada gunanya menjelaskannya, semuanya jelas di sana.
Dua mesin pada rangkaian yang berbeza (penghalaan antara rangkaian)
Kes terakhir untuk hari ini ialah penghalaan antara rangkaian dalam satu projek menggunakan penghala maya. Kami sedang mempertimbangkan kes tanpa DVR (kami akan melihatnya dalam artikel lain), jadi penghalaan berlaku pada nod rangkaian. Dalam kes kami, nod rangkaian tidak diletakkan dalam entiti yang berasingan dan terletak pada nod kawalan.
Mula-mula, mari kita lihat bahawa penghalaan 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 msOleh kerana dalam kes ini, paket mesti pergi ke gerbang dan dihalakan ke sana, kita perlu mengetahui alamat popi gerbang, yang mana kita melihat jadual 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 trafik dengan destinasi (10.0.1.254) fa:16:3e:c4:64:70 harus dihantar:
[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 lihat di mana port 2 membawa:
[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 logik, lalu lintas pergi ke br-tun. Mari lihat terowong vxlan yang mana ia 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 ialah terowong vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Yang melihat pada nod kawalan:
[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 ~]$ Trafik telah mencapai nod kawalan, jadi kita perlu pergi ke sana dan melihat cara penghalaan akan berlaku.
Seperti yang anda ingat, nod kawalan di dalam kelihatan betul-betul sama dengan nod pengiraan - tiga jambatan yang sama, hanya br-ex mempunyai port fizikal yang melaluinya nod boleh menghantar trafik ke luar. Penciptaan contoh telah mengubah konfigurasi pada nod pengiraan - jambatan linux, iptables dan antara muka telah ditambahkan pada nod. Penciptaan rangkaian dan penghala maya juga meninggalkan tanda pada konfigurasi nod kawalan.
Jadi, adalah jelas bahawa alamat MAC get laluan mesti berada dalam jadual pemajuan br-int pada nod kawalan. Mari semak sama ada ia ada di sana dan di mana ia mencari:
[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 boleh dilihat dari port qr-0c52b15f-8f. Jika kita kembali ke senarai port maya dalam Openstack, port jenis ini digunakan untuk menyambungkan pelbagai peranti maya ke OVS. Untuk menjadi lebih tepat, qr ialah port ke penghala maya, yang diwakili sebagai ruang nama.
Mari lihat apa ruang nama pada pelayan:
[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 salinan. Tetapi berdasarkan nama, anda boleh meneka tujuan setiap daripada mereka. Kami akan kembali kepada kejadian dengan ID 0 dan 1 kemudian, sekarang kami berminat dengan ruang nama 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 ~]$ Ruang nama ini mengandungi dua ruang dalaman yang kami buat sebelum ini. Kedua-dua port maya telah ditambahkan pada br-int. Mari semak alamat mac port qr-0c52b15f-8f, kerana trafik, berdasarkan alamat mac destinasi, pergi ke antara muka 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 ~]$ Iaitu, dalam kes ini, semuanya berfungsi mengikut undang-undang penghalaan standard. Memandangkan trafik ditakdirkan untuk hos 10.0.2.8, ia mesti keluar melalui antara muka kedua qr-92fa49b5-54 dan melalui terowong vxlan ke nod pengiraan:
[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 logik, tiada kejutan. Mari lihat di mana alamat popi hos 10.0.2.8 kelihatan dalam 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 dijangkakan, trafik pergi ke br-tun, mari lihat terowong mana yang lalu lintas masuk seterusnya:
[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 ~]$ Trafik masuk ke dalam terowong untuk mengira-1. Nah, pada compute-1 semuanya mudah - dari br-tun pakej pergi ke br-int dan dari sana ke antara muka mesin maya:
[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 sama ada ini adalah antara muka yang betul:
[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 telah melalui pakej tersebut. Saya rasa anda perasan bahawa trafik melalui terowong vxlan yang berbeza dan keluar dengan VNI yang berbeza. Mari lihat jenis VNI ini, selepas itu kami akan mengumpul pembuangan pada port kawalan nod dan memastikan bahawa trafik mengalir betul-betul seperti yang diterangkan di atas.
Jadi, terowong untuk mengira-0 mempunyai tindakan berikut=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Mari tukar 0x16 kepada sistem nombor perpuluhan:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Terowong untuk mengira-1 mempunyai VNI berikut:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Mari tukar 0x63 kepada sistem nombor perpuluhan:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nah, sekarang mari kita lihat tempat pembuangan:
[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 ialah paket vxlan dari hos 192.168.255.19 (compute-0) ke hos 192.168.255.15 (control-1) dengan vni 22, di dalamnya paket ICMP dibungkus dari hos 10.0.1.85 ke hos 10.0.2.8. Seperti yang kita kira di atas, vni sepadan dengan apa yang kita lihat dalam output.
Paket kedua ialah paket vxlan daripada hos 192.168.255.15 (kawalan-1) kepada hos 192.168.255.26 (hitung-1) dengan vni 99, di dalamnya paket ICMP dibungkus daripada hos 10.0.1.85 kepada hos 10.0.2.8. Seperti yang kita kira di atas, vni sepadan dengan apa yang kita lihat dalam output.
Dua paket seterusnya ialah trafik pemulangan daripada 10.0.2.8 bukan 10.0.1.85.
Iaitu, pada akhirnya kami mendapat skema nod kawalan berikut:
Nampak macam tu ke? Kami terlupa tentang dua ruang nama:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Semasa kita bercakap tentang seni bina platform awan, adalah baik jika mesin menerima alamat secara automatik daripada pelayan DHCP. Ini ialah dua pelayan DHCP untuk dua rangkaian kami 10.0.1.0/24 dan 10.0.2.0/24.
Mari kita periksa sama ada ini benar. Terdapat hanya satu alamat dalam ruang nama ini - 10.0.1.1 - alamat pelayan DHCP itu sendiri, dan ia juga disertakan 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 lihat jika proses yang mengandungi qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 dalam nama mereka pada nod kawalan:
[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 ~]$ Terdapat proses sedemikian dan berdasarkan maklumat yang dibentangkan dalam output di atas, kita boleh, sebagai contoh, melihat apa yang kita sediakan untuk disewa pada masa ini:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Akibatnya, kami mendapat set perkhidmatan berikut pada nod kawalan:
Nah, perlu diingat - ini hanya - 4 mesin, 2 rangkaian dalaman dan satu penghala maya... Kami tidak mempunyai rangkaian luaran di sini sekarang, sekumpulan projek yang berbeza, masing-masing dengan rangkaian mereka sendiri (bertindih), dan kami mempunyai penghala teragih dimatikan, dan pada akhirnya Lagipun, terdapat hanya satu nod kawalan dalam bangku ujian (untuk toleransi kesalahan mesti ada kuorum tiga nod). Adalah logik bahawa dalam perdagangan segala-galanya "sedikit" lebih rumit, tetapi dalam contoh mudah ini kita faham bagaimana ia harus berfungsi - sama ada anda mempunyai 3 atau 300 ruang nama sudah tentu penting, tetapi dari sudut pandangan operasi keseluruhan struktur, tiada apa yang akan berubah banyak... walaupun anda Anda tidak akan memasangkan beberapa vendor SDN. Tetapi itu cerita yang sama sekali berbeza.
Saya harap ia menarik. Jika anda mempunyai sebarang komen/tambahan, atau di suatu tempat saya berbohong secara terang-terangan (saya manusia dan pendapat saya akan sentiasa subjektif) - tulis apa yang perlu diperbetulkan/tambah - kami akan betulkan/tambah segalanya.
Sebagai kesimpulan, saya ingin mengatakan beberapa perkataan tentang membandingkan Openstack (kedua-dua vanila dan vendor) dengan penyelesaian awan daripada VMWare - Saya telah ditanya soalan ini terlalu kerap sejak beberapa tahun lalu dan, terus terang, saya sudah bosan dengannya, tetapi masih. Pada pendapat saya, sangat sukar untuk membandingkan kedua-dua penyelesaian ini, tetapi kita pasti boleh mengatakan bahawa terdapat kelemahan dalam kedua-dua penyelesaian dan apabila memilih satu penyelesaian anda perlu menimbang kebaikan dan keburukan.
Jika OpenStack ialah penyelesaian yang didorong oleh komuniti, maka VMWare berhak untuk melakukan hanya apa yang ia mahu (baca - apa yang menguntungkan untuknya) dan ini adalah logik - kerana ia adalah syarikat komersial yang biasa menjana wang daripada pelanggannya. Tetapi ada satu yang besar dan gemuk TETAPI - anda boleh keluar dari OpenStack, contohnya dari Nokia, dan dengan sedikit perbelanjaan beralih kepada penyelesaian daripada, contohnya, Juniper (Contrail Cloud), tetapi anda tidak mungkin dapat keluar dari VMWare . Bagi saya, kedua-dua penyelesaian ini kelihatan seperti ini - Openstack (vendor) ialah sangkar mudah di mana anda diletakkan, tetapi anda mempunyai kunci dan anda boleh pergi pada bila-bila masa. VMWare adalah sangkar emas, pemiliknya mempunyai kunci sangkar dan ia akan menelan belanja yang banyak.
Saya tidak mempromosikan sama ada produk pertama atau kedua - anda pilih apa yang anda perlukan. Tetapi jika saya mempunyai pilihan sedemikian, saya akan memilih kedua-dua penyelesaian - VMWare untuk awan IT (beban rendah, pengurusan mudah), OpenStack daripada beberapa vendor (Nokia dan Juniper menyediakan penyelesaian turnkey yang sangat baik) - untuk awan Telecom. Saya tidak akan menggunakan Openstack untuk IT tulen - ia seperti menembak burung pipit dengan meriam, tetapi saya tidak nampak sebarang kontraindikasi untuk menggunakannya selain daripada redundansi. Walau bagaimanapun, menggunakan VMWare dalam telekom adalah seperti mengangkut batu hancur dalam Ford Raptor - ia cantik dari luar, tetapi pemandu perlu membuat 10 perjalanan dan bukannya satu.
Pada pendapat saya, kelemahan terbesar VMWare ialah ketertutupannya sepenuhnya - syarikat tidak akan memberi anda sebarang maklumat tentang cara ia berfungsi, contohnya, vSAN atau apa yang ada dalam kernel hypervisor - ia tidak menguntungkan untuknya - iaitu, anda akan tidak pernah menjadi pakar dalam VMWare - tanpa sokongan vendor, anda ditakdirkan (sangat kerap saya bertemu pakar VMWare yang bingung dengan soalan remeh). Bagi saya, VMWare sedang membeli kereta dengan hud berkunci - ya, anda mungkin mempunyai pakar yang boleh menukar tali pinggang masa, tetapi hanya orang yang menjual anda penyelesaian ini boleh membuka hud. Secara peribadi, saya tidak suka penyelesaian yang saya tidak boleh muat. Anda akan mengatakan bahawa anda mungkin tidak perlu pergi di bawah tudung. Ya, ini mungkin, tetapi saya akan melihat anda apabila anda perlu memasang fungsi besar dalam awan daripada 20-30 mesin maya, 40-50 rangkaian, separuh daripadanya ingin keluar, dan separuh kedua meminta Pecutan SR-IOV, jika tidak, anda memerlukan lebih beberapa dozen kereta ini - jika tidak prestasinya tidak akan mencukupi.
Terdapat sudut pandangan lain, jadi hanya anda yang boleh memutuskan apa yang perlu dipilih dan, yang paling penting, anda akan bertanggungjawab untuk pilihan anda. Ini hanyalah pendapat saya - seorang yang telah melihat dan menyentuh sekurang-kurangnya 4 produk - Nokia, Juniper, Red Hat dan VMWare. Iaitu, saya mempunyai sesuatu untuk dibandingkan.
Sumber: www.habr.com