Bulud hesablamaları həyatımıza getdikcə daha dərindən nüfuz edir və yəqin ki, heç olmasa bir dəfə bulud xidmətindən istifadə etməyən bir nəfər yoxdur. Bununla belə, bulud nədir və onun necə işlədiyini çox az adam hətta ideya səviyyəsində bilir. 5G reallığa çevrilir və telekommunikasiya infrastrukturu bütün aparat həllərindən virtuallaşdırılmış “sütunlara” keçdiyi zaman olduğu kimi qütb həllərindən bulud həllərinə keçməyə başlayır.
Bu gün biz bulud infrastrukturunun daxili dünyası haqqında danışacağıq, xüsusən də şəbəkə hissəsinin əsaslarını təhlil edəcəyik.
Bulud nədir? Eyni virtuallaşdırma - profil görünüşü?
Məntiqi sualdan daha çox. Xeyr - bu virtuallaşdırma deyil, baxmayaraq ki, onsuz edə bilməzdi. İki tərifi nəzərdən keçirin:
Cloud Computing (bundan sonra Bulud adlandırılacaq) tətbiq edilməli və tələb əsasında mümkün olan ən aşağı gecikmə və xidmət təminatçısı üçün minimum xərclə işlədilməli olan paylanmış hesablama resurslarına istifadəçi dostu girişi təmin etmək üçün bir modeldir.
Virtuallaşdırma - bu, bir fiziki varlığı (məsələn, serveri) bir neçə virtuala bölmək və bununla da resurslardan istifadəni artırmaq qabiliyyətidir (məsələn, sizdə 3-25 faiz yüklənmiş 30 server var idi, virtuallaşdırmadan sonra 1 server yüklənir. 80-90 faiz). Təbii ki, virtuallaşdırma bəzi resursları yeyir - hipervizoru qidalandırmaq lazımdır, lakin təcrübənin göstərdiyi kimi, oyun şama dəyər. Virtuallaşdırmanın ideal nümunəsi virtual maşınların hazırlanmasında əla olan VMWare və ya mənim üstünlük verdiyim KVM-dir, lakin bu artıq zövq məsələsidir.
Biz fərqinə varmadan virtuallaşdırmadan istifadə edirik və hətta dəmir marşrutlaşdırıcılar artıq virtuallaşdırmadan istifadə edirlər - məsələn, JunOS-un son versiyasında əməliyyat sistemi real vaxt rejimində linux paylanmasının (Wind River 9) üstündə virtual maşın kimi quraşdırılıb. Lakin virtuallaşdırma bulud deyil, lakin bulud virtuallaşdırma olmadan mövcud ola bilməz.
Virtuallaşdırma buludun qurulduğu tikinti bloklarından biridir.
Sadəcə bir L2 domenində bir neçə hipervizoru toplamaq, vlanların avtomatik qeydiyyatı üçün bir neçə yaml kitabçası əlavə etmək və virtual maşınları avtomatik yaratmaq üçün orkestrasiya sistemi kimi bir şey doldurmaqla bulud yaratmaq işləməyəcək. Daha doğrusu, ortaya çıxacaq, amma ortaya çıxan Frankenstein ehtiyac duyduğumuz bulud deyil, baxmayaraq ki, kimsə üçün, bəlkə də kimsə üçün bu, son xəyaldır. Bundan əlavə, eyni Openstack-i götürsəniz, əslində bu hələ də Frankenstein-dir, amma yaxşı, hələlik bu barədə danışmayaq.
Ancaq başa düşürəm ki, yuxarıda təqdim olunan tərifdən əslində nəyin bulud adlandırıla biləcəyi tam aydın deyil.
Buna görə də, NIST-in (Milli Standartlar və Texnologiya İnstitutu) sənədi bulud infrastrukturunun malik olmalı olduğu 5 əsas xüsusiyyəti sadalayır:
Müraciət əsasında xidmət göstərmək. İstifadəçiyə ona ayrılmış kompüter resurslarına (məsələn, şəbəkələr, virtual disklər, yaddaş, prosessor nüvələri və s.) sərbəst giriş imkanı verilməli və bu resurslar avtomatik olaraq – yəni xidmət təminatçısının müdaxiləsi olmadan təmin edilməlidir.
Geniş xidmət əlçatanlığı. Həm standart fərdi kompüterlərdən, həm də nazik müştərilərdən və mobil cihazlardan istifadə etmək üçün resurslara giriş standart mexanizmlərlə təmin edilməlidir.
Resursları hovuzlara birləşdirmək. Resurs hovuzları müştərilərin təcrid olunmalarını və bir-birlərinə müdaxilə etməmələrini və resurslar uğrunda rəqabət aparmamasını təmin edərək eyni vaxtda bir neçə müştəriyə resurslar təqdim etməlidir. Hovuzlara şəbəkələr də daxildir ki, bu da çarpaz ünvanlamanın istifadəsinin mümkünlüyünü göstərir. Hovuzlar tələb üzrə miqyaslaşdırmanı dəstəkləməlidir. Hovuzların istifadəsi resurs qüsurlarına qarşı dözümlülüyün lazımi səviyyəsini və fiziki və virtual resursların abstraksiyasını təmin etməyə imkan verir - xidmətin alıcısına sadəcə onun tələb etdiyi resurslar dəsti verilir (bu resurslar fiziki olaraq harada yerləşir, neçə serverdə yerləşir) və açarları - müştəri əhəmiyyət vermir). Bununla belə, nəzərə almaq lazımdır ki, provayder bu resursların şəffaf rezervasiyasını təmin etməlidir.
Müxtəlif şərtlərə tez uyğunlaşma. Xidmətlər çevik olmalıdır—resursları tez təmin etməli, onları yenidən bölüşdürməli, müştərinin tələbi ilə resursları əlavə etməli və ya azaltmalı və müştəri bulud resurslarının sonsuz olduğunu hiss etməlidir. Anlamaq asanlığı üçün, məsələn, serverdəki sabit diskin xarab olması və disklərin xarab olması səbəbindən disk yerinizin bir hissəsinin Apple iCloud-da itdiyi barədə xəbərdarlıq görmürsünüz. Bundan əlavə, sizin tərəfinizdən bu xidmətin imkanları demək olar ki, sonsuzdur - sizə 2 TB lazımdır - problem yoxdur, ödəmisiniz və aldınız. Eynilə, Google.Drive və ya Yandex.Disk ilə bir nümunə verə bilərsiniz.
Göstərilən xidməti ölçmək imkanı. Bulud sistemləri istehlak olunan resurslara avtomatik nəzarət etməli və optimallaşdırmalı, eyni zamanda bu mexanizmlər həm istifadəçi, həm də xidmət təminatçısı üçün şəffaf olmalıdır. Yəni, siz həmişə sizin və müştərilərinizin nə qədər resurs istehlak etdiyini yoxlaya bilərsiniz.
Bu tələblərin əksər hallarda ictimai bulud üçün tələblər olduğunu nəzərə almağa dəyər, buna görə də şəxsi bulud (yəni şirkətin daxili ehtiyacları üçün işə salınan bulud) üçün bu tələblər bir qədər tənzimlənə bilər. Bununla belə, onlar hələ də yerinə yetirilməlidir, əks halda biz bulud hesablamasının bütün üstünlüklərini əldə etməyəcəyik.
Niyə bizə bulud lazımdır?
Bununla belə, hər hansı yeni və ya mövcud texnologiya, hər hansı yeni protokol bir şey üçün yaradılır (yaxşı, RIP-ng istisna olmaqla, əlbəttə). Protokol naminə protokol heç kimə lazım deyil (əlbəttə ki, RIP-ng istisna olmaqla). Buludun istifadəçiyə/müştəriyə bir növ xidmət göstərmək üçün yaradılması məntiqlidir. Biz hamımız Dropbox və ya Google.Docs kimi ən azı bir neçə bulud xidməti ilə tanışıq və inanıram ki, onların əksəriyyəti onlardan uğurla istifadə edir – məsələn, bu məqalə Google.Docs bulud xidmətindən istifadə etməklə yazılmışdır. Ancaq bizə məlum olan bulud xidmətləri buludun imkanlarının yalnız bir hissəsidir - daha dəqiq desək, bu, yalnız SaaS tipli xidmətdir. Bulud xidmətini üç yolla təqdim edə bilərik: SaaS, PaaS və ya IaaS şəklində. Hansı xidmətə ehtiyacınız sizin istəklərinizdən və imkanlarınızdan asılıdır.
Hər birini ardıcıllıqla nəzərdən keçirək:
Bir xidmət olaraq proqram (SaaS) müştəriyə tam hüquqlu xidmət göstərmək üçün bir modeldir, məsələn, Yandex.Mail və ya Gmail kimi poçt xidməti. Bu xidmətin çatdırılması modelində siz müştəri olaraq xidmətlərdən istifadə etməkdən başqa heç nə etmirsiniz - yəni xidmətin konfiqurasiyası, onun nasazlıqlara dözümlülüyü və ya artıqlığı barədə düşünmək məcburiyyətində deyilsiniz. Əsas odur ki, parolunuzu pozmayın, qalanını bu xidmətin provayderi sizin üçün edəcək. Xidmət provayderi nöqteyi-nəzərindən o, bütün xidmət üçün tam məsuliyyət daşıyır - server aparatlarından və host əməliyyat sistemlərindən tutmuş verilənlər bazası və proqram təminatı parametrlərinə qədər.
Bir xidmət olaraq platforma (PaaS) - bu modeldən istifadə edərkən xidmət provayderi müştəriyə xidmət üçün iş parçası təqdim edir, məsələn, Veb serveri götürək. Xidmət provayderi müştərini virtual serverlə təmin etdi (əslində RAM / CPU / Saxlama / Şəbəkələr kimi bir sıra resurslar və s.) və hətta bu serverdə ƏS və lazımi proqram təminatı quraşdırdı, lakin müştəri özü bütün bu yaxşılığı konfiqurasiya edir və xidmətin performansı üçün müştəri cavab verir. Xidmət təminatçısı, əvvəlki vəziyyətdə olduğu kimi, fiziki avadanlıqların, hipervizorların, virtual maşının özünə, şəbəkənin mövcudluğuna və s. performansına görə məsuliyyət daşıyır, lakin xidmətin özü artıq məsuliyyət zonasından kənardadır.
Xidmət kimi infrastruktur (IaaS) - bu yanaşma artıq daha maraqlıdır, əslində xidmət provayderi müştərini tam virtuallaşdırılmış infrastrukturla təmin edir - yəni CPU nüvələri, RAM, şəbəkələr və s. kimi bir növ resurslar dəsti (hovuzu) müştəriyə qədər - müştəri ona ayrılmış hovuz (kvota) daxilində bu resurslarla nə etmək istəyir - təchizatçı üçün xüsusilə vacib deyil. Müştəri öz vEPC yaratmaq və ya hətta mini operator etmək və rabitə xidmətləri göstərmək istəyirsə - sual yoxdur - bunu edin. Belə bir ssenaridə xidmət provayderi resursların təmin edilməsinə, onların nasazlıqlara qarşı dözümlülüyünə və mövcudluğuna, həmçinin bu resursları birləşdirməyə və müştəriyə istənilən vaxt resursları artırmaq və ya azaltmaq imkanı verən OS üçün cavabdehdir. müştərinin tələbi. Müştəri bütün virtual maşınları və digər tinselləri özünəxidmət portalı və konsollar vasitəsilə, o cümlədən şəbəkələrin təyin edilməsini (xarici şəbəkələr istisna olmaqla) konfiqurasiya edir.
OpenStack nədir?
Hər üç variantda xidmət təminatçısına bulud infrastrukturu yaratmağa imkan verən ƏS lazımdır. Əslində, SaaS ilə birdən çox departament bütün texnoloji yığına cavabdehdir - infrastruktura cavabdeh olan bir departament var - yəni IaaS-i başqa bir departamentə təqdim edir, bu şöbə müştəriyə SaaS təqdim edir. OpenStack, bir çox açarları, serverləri və saxlama sistemlərini vahid resurs hovuzuna toplamağa, bu ümumi hovuzu subpoollara (icarəçilərə) bölməyə və bu resursları şəbəkə üzərindən müştərilərə təqdim etməyə imkan verən bulud əməliyyat sistemlərindən biridir.
OpenStack standart autentifikasiya mexanizmlərindən istifadə etməklə API vasitəsilə təmin edilən və idarə olunan hesablama resurslarının, məlumatların saxlanması və şəbəkə resurslarının böyük hovuzlarını idarə etməyə imkan verən bulud əməliyyat sistemidir.
Başqa sözlə, bu, bulud xidmətləri (həm ictimai, həm də özəl) yaratmaq üçün nəzərdə tutulmuş pulsuz proqram layihələri toplusudur - yəni server və kommutasiya avadanlığını vahid resurslar hovuzunda birləşdirməyə, idarə etməyə imkan verən alətlər toplusudur. Bu qaynaqlar, lazımi səviyyədə səhv dözümlülüyü təmin edir.
Bu yazı zamanı OpenStack strukturu belə görünür:
Şəkildən götürülüb
OpenStack-i təşkil edən komponentlərin hər biri müəyyən funksiyanı yerinə yetirir. Bu paylanmış arxitektura sizə lazım olan funksional komponentlər dəstini həllə daxil etməyə imkan verir. Bununla belə, bəzi komponentlər kök komponentləridir və onların çıxarılması bütövlükdə həllin tam və ya qismən işləməməsinə səbəb olacaqdır. Bu komponentlər adətən belə adlandırılır:
- İdarə paneli - OpenStack xidmətlərini idarə etmək üçün veb-əsaslı GUI
- Məhək daşı - digər xidmətlər üçün autentifikasiya və avtorizasiya funksionallığını təmin edən, həmçinin istifadəçi etimadnaməsini və onların rollarını idarə edən mərkəzləşdirilmiş şəxsiyyət xidməti.
- Neutron - müxtəlif OpenStack xidmətlərinin interfeysləri arasında əlaqəni təmin edən şəbəkə xidməti (VM-lər arasında əlaqə və onların xarici dünyaya çıxışı daxil olmaqla)
- Cinder - virtual maşınlar üçün blok yaddaşına girişi təmin edir
- Yeni — virtual maşınların həyat dövrünün idarə edilməsi
- Baxış - virtual maşın şəkillərinin və anlıq görüntülərin deposu
- Cəld - obyektin saxlanmasına girişi təmin edir
- Seilometr - telemetriya toplamaq və mövcud və istehlak resurslarını ölçmək imkanı verən xidmət
- Istilik — resursların avtomatik yaradılması və təmin edilməsi üçün şablonlara əsaslanan orkestrasiya
Bütün layihələrin tam siyahısına və onların məqsədinə baxa bilərsiniz .
OpenStack komponentlərinin hər biri müəyyən bir funksiyaya cavabdeh olan xidmətdir və vahid infrastruktur yaratmaq üçün bu funksiyanı idarə etmək və bulud əməliyyat sisteminin digər xidmətləri ilə qarşılıqlı əlaqə yaratmaq üçün API təmin edir. Məsələn, Nova hesablama resursunun idarə edilməsini və resurs məlumatlarının konfiqurasiyasına daxil olmaq üçün API təqdim edir, Glance təsvirin idarə edilməsini və onları idarə etmək üçün API təqdim edir, Cinder blok yaddaşını və onu idarə etmək üçün API təqdim edir və s. Bütün funksiyalar çox sıx şəkildə bir-birinə bağlıdır.
Bununla belə, mühakimə etsək, OpenStack-də işləyən bütün xidmətlər son nəticədə şəbəkəyə qoşulmuş bir növ virtual maşındır (və ya konteynerdir). Sual yaranır - niyə bu qədər elementə ehtiyacımız var?
Virtual maşın yaratmaq və onu şəbəkəyə və Openstack-də davamlı yaddaşa qoşmaq üçün alqoritmdən keçək.
- Avtomobil yaratmaq üçün sorğu yaratdığınız zaman, istər Horizon (İdarəetmə Paneli) vasitəsilə sorğu, istərsə də CLI vasitəsilə sorğu olsun, ilk baş verən şey Keystone-da sorğunuzun avtorizasiyasıdır - siz avtomobil yarada bilərsiniz, var və ya hüququ var. bu şəbəkədən istifadə etmək, kvota layihənizi edir və s.
- Keystone sorğunuzu təsdiqləyir və sonradan istifadə olunacaq cavab mesajında auth token yaradır. Keystone-dan cavab aldıqdan sonra sorğu Novaya (nova api) göndərilir.
- Nova-api, əvvəllər yaradılmış auth tokenindən istifadə edərək Keystone ilə əlaqə saxlayaraq sorğunuzun etibarlılığını yoxlayır.
- Keystone autentifikasiyanı həyata keçirir və bu doğrulama nişanı əsasında icazələr və məhdudiyyətlər haqqında məlumat verir.
- Nova-api nova-verilənlər bazasında yeni VM girişi yaradır və nova-planlaşdırıcıya maşın yaratmaq üçün sorğu göndərir.
- Nova-planlaşdırıcı, verilmiş parametrlər, çəkilər və zonalar əsasında VM-nin yerləşdiriləcəyi hostu (qovşaq kompüteri) seçir. Bunun qeydi və VM ID-si nova verilənlər bazasına yazılır.
- Sonra, nova-planlayıcı nümunəni yerləşdirmək tələbi ilə nova-compute zəng edir. Nova-compute maşın parametrləri haqqında məlumat əldə etmək üçün nova-dirijoru çağırır (nova-dirijor, problemlərin qarşısını almaq üçün nova-verilənlər bazasına sorğuların sayını məhdudlaşdıran, nova-verilənlər bazası və nova-compute arasında proxy server kimi çıxış edən nova elementidir. verilənlər bazası ardıcıllığı yükünün azaldılması ilə).
- Nova-dirijor tələb olunan məlumatı nova-verilənlər bazasından alır və nova-compute-ə ötürür.
- Sonra, nova-compute görüntü identifikatorunu əldə etmək üçün nəzər salır. Glace Keystone-da sorğunu təsdiqləyir və tələb olunan məlumatı qaytarır.
- Nova-compute şəbəkə parametrləri haqqında məlumat üçün neytron çağırır. Baxışa bənzər olaraq, neytron Keystone-da sorğunu təsdiqləyir, sonra verilənlər bazasında giriş yaradır (port id və s.), port yaratmaq üçün sorğu yaradır və tələb olunan məlumatı nova-compute-a qaytarır.
- Nova-compute virtual maşına həcm ayırmaq tələbi ilə cinder çağırır. Baxış kimi, sidr Keystone-da sorğunu təsdiqləyir, həcm yaratmaq üçün sorğu yaradır və tələb olunan məlumatı qaytarır.
- Nova-compute, verilmiş parametrlərlə virtual maşını yerləşdirmək tələbi ilə libvirt-ə zəng edir.
Əslində, sadə virtual maşın yaratmaq üçün sadə görünən əməliyyat bulud platformasının elementləri arasında belə api çağırışları burulğanına çevrilir. Üstəlik, gördüyünüz kimi, hətta əvvəllər təyin edilmiş xidmətlər də daha kiçik komponentlərdən ibarətdir və onların arasında qarşılıqlı əlaqə baş verir. Maşın yaratmaq bulud platformasının sizə imkan verdiyi işlərin yalnız kiçik bir hissəsidir - trafikin balanslaşdırılmasına cavabdeh olan xidmət, blokun saxlanmasına cavabdeh olan xidmət, DNS üçün cavabdeh olan xidmət, çılpaq metal serverlərin təmin edilməsinə cavabdeh olan xidmət və s. Bulud virtual maşınlarınızı qoyun sürüsü kimi qəbul etməyə imkan verir (virtuallaşdırmadan fərqli olaraq). Əgər virtual mühitinizdə maşına nəsə baş veribsə - siz onu ehtiyat nüsxələrdən bərpa edirsiniz və s., bulud proqramları elə qurulur ki, virtual maşın o qədər də mühüm rol oynamır - virtual maşın "öldü" - bu edir. fərqi yoxdur - şablon əsasında sadəcə yeni avtomobil yaradılıb və necə deyərlər, heyət bir döyüşçünün itkisini hiss etməyib. Təbii ki, bu, orkestr mexanizmlərinin mövcudluğunu təmin edir - İstilik şablonlarından istifadə edərək, onlarla şəbəkə və virtual maşından ibarət mürəkkəb funksiyanı heç bir problem olmadan yerləşdirə bilərsiniz.
Həmişə yadda saxlamağa dəyər ki, şəbəkəsiz bulud infrastrukturu yoxdur - hər bir element bu və ya digər şəkildə şəbəkə vasitəsilə digər elementlərlə qarşılıqlı əlaqədə olur. Bundan əlavə, bulud tamamilə qeyri-statik şəbəkəyə malikdir. Təbii ki, alt qat şəbəkəsi daha az və ya çox statikdir - hər gün yeni qovşaqlar və açarlar əlavə edilmir, lakin üst-üstə düşmə komponenti daim dəyişə bilər və qaçılmaz olaraq dəyişəcək - yeni şəbəkələr əlavə olunacaq və ya silinəcək, yeni virtual maşınlar görünəcək və köhnələri ölmək. Məqalənin əvvəlində verilən bulud tərifindən xatırladığınız kimi, resurslar istifadəçiyə avtomatik olaraq və xidmət təminatçısının ən az (yaxud daha yaxşı) müdaxiləsi ilə bölüşdürülməlidir. Yəni, hazırda http / https və şəbəkə mühəndisi Vasili vasitəsilə mövcud şəxsi hesabınız şəklində frontend şəklində olan şəbəkə resurslarının təmin edilməsi növü, Vasili olsa belə, bulud deyil. səkkiz əl.
Neytron şəbəkə xidməti olmaqla bulud infrastrukturunun şəbəkə hissəsini idarə etmək üçün API təmin edir. Xidmət Network-as-a-Service (NaaS) adlı abstraksiya qatını təmin etməklə Openstack-in şəbəkə hissəsinin sağlamlığını və idarə olunmasını təmin edir. Yəni, şəbəkə eyni virtual ölçü vahididir, məsələn, CPU-nun virtual nüvələri və ya RAM miqdarı.
Lakin OpenStack-in şəbəkə hissəsinin arxitekturasına keçməzdən əvvəl gəlin bu şəbəkənin OpenStack-də necə işlədiyinə və nə üçün şəbəkənin buludun vacib və ayrılmaz hissəsi olduğuna baxaq.
Beləliklə, bizdə iki RED müştəri virtual maşını və iki YAŞIL müştəri virtual maşını var. Tutaq ki, bu maşınlar bu şəkildə iki hipervizorda yerləşir:
Hal-hazırda, bu, sadəcə 4 serverin virtuallaşdırılmasıdır və başqa heç nə yoxdur, çünki indiyə qədər etdiyimiz hər şey 4 serveri virtuallaşdıraraq onları iki fiziki serverə yerləşdirməkdir. Və hələ də onlar şəbəkəyə qoşulmayıblar.
Bulud əldə etmək üçün bir neçə komponent əlavə etməliyik. Birincisi, biz şəbəkə hissəsini virtuallaşdırırıq - bu 4 maşını cüt-cüt birləşdirməliyik və müştərilər məhz L2 bağlantısını istəyirlər. Siz əlbəttə ki, keçiddən istifadə edə və onun istiqamətində magistral qura və hər şeyi linux körpüsündən istifadə edərək həll edə bilərsiniz və ya daha təkmil openvswitch istifadəçiləri üçün (daha sonra ona qayıdacağıq). Ancaq çox sayda şəbəkə ola bilər və L2-ni daim bir keçid vasitəsilə itələmək ən yaxşı fikir deyil - belə ki, müxtəlif şöbələr, xidmət masası, ərizənin tamamlanmasını gözləmək, həftələrlə problemlərin aradan qaldırılması - müasir dünyada bu yanaşma artıq işləmir. Və şirkət bunu nə qədər tez başa düşsə, irəliləmək bir o qədər asan olar. Buna görə də, hipervizorlar arasında virtual maşınlarımızın əlaqə saxlayacağı L3 şəbəkəsini seçəcəyik və bu L3 şəbəkəsinin üstündə virtual maşınlarımızın trafikinin işləyəcəyi virtual overlay L2 (overlay) şəbəkələri quracağıq. İnkapsulyasiya GRE, Geneve və ya VxLAN ola bilər. Hələlik gəlin diqqəti sonuncuya yönəldək, baxmayaraq ki, bu xüsusilə vacib deyil.
Biz VTEP-in yerini müəyyən etməliyik (ümid edirəm ki, hər kəs VxLAN terminologiyası ilə tanışdır). L3 şəbəkəsi dərhal serverlərimizi tərk etdiyi üçün VTEP-ni serverlərin özlərində yerləşdirməyə heç nə mane olmur və OVS (OpenvSwitch) bunu mükəmməl şəkildə yerinə yetirir. Nəticədə aşağıdakı strukturu əldə etdik:
VM-lər arasındakı trafik ayrılmalı olduğundan, virtual maşınlara gedən portların fərqli vlan nömrələri olacaq. Teq nömrəsi yalnız bir virtual keçiddə rol oynayır, çünki VxLAN-da kapsullaşdırarkən biz onu asanlıqla silə bilərik, çünki VNI-yə sahib olacağıq.
İndi biz heç bir problem olmadan maşınlarımızı və virtual şəbəkələrimizi onlar üçün yarada bilərik.
Bununla belə, əgər müştərinin başqa maşını varsa, lakin başqa şəbəkədədirsə? Bizə şəbəkələr arasında köklənmə lazımdır. Mərkəzləşdirilmiş kökləmə istifadə edildikdə sadə bir variantı təhlil edəcəyik - yəni trafik xüsusi ayrılmış şəbəkə qovşaqları vasitəsilə yönləndirilir (yaxşı, bir qayda olaraq, onlar idarəetmə qovşaqları ilə birləşdirilir, buna görə də eyni şeyə sahib olacağıq).
Göründüyü kimi, mürəkkəb bir şey yoxdur - biz idarəetmə qovşağında körpü interfeysi düzəldirik, trafiki ona yönəldirik və oradan onu lazım olan yerə yönləndiririk. Amma problem ondadır ki, RED müştəri 10.0.0.0/24 şəbəkəsindən, YAŞIL müştəri isə 10.0.0.0/24 şəbəkəsindən istifadə etmək istəyir. Yəni ünvan fəzalarının kəsişməsinə başlayırıq. Bundan əlavə, müştərilər digər müştərilərin öz daxili şəbəkələrinə marşrutlaşdıra bilmələrini istəmirlər, bu məntiqlidir. Bu müştərilərin şəbəkələrini və trafikini ayırmaq üçün onların hər biri üçün ayrıca ad sahəsi ayıracağıq. Ad məkanı əslində Linux şəbəkə yığınının surətidir, yəni RED ad məkanındakı müştərilər müştərilərdən GREEN ad məkanından tamamilə təcrid olunublar (yaxşı, ya bu müştəri şəbəkələri arasında marşrutlaşdırma standart ad məkanı vasitəsilə və ya artıq daha yüksək nəqliyyat avadanlığında icazə verilir).
Yəni aşağıdakı sxemi alırıq:
L2 tunelləri bütün hesablama qovşaqlarından idarəetmə qovşaqlarına yaxınlaşır. bu şəbəkələr üçün L3 interfeysinin yerləşdiyi node, hər biri təcrid üçün ayrılmış ad məkanında.
Ancaq ən vacib şeyi unutduq. Virtual maşın müştəriyə xidmət göstərməlidir, yəni ona çatmaq üçün ən azı bir xarici interfeysə malik olmalıdır. Yəni biz xarici aləmə getməliyik. Burada müxtəlif variantlar var. Ən sadə variantı edək. Provayderin şəbəkəsində etibarlı olacaq və digər şəbəkələrlə üst-üstə düşməyəcək bir şəbəkəyə müştərilər əlavə edək. Şəbəkələr də kəsişə bilər və provayder şəbəkəsinin tərəfində müxtəlif VRF-lərə baxa bilər. Şəbəkə məlumatları müştərilərin hər birinin ad məkanında da yaşayacaq. Bununla belə, onlar hələ də bir fiziki (yaxud daha məntiqli olan bağ) vasitəsilə xarici dünyaya gedəcəklər. Müştəri trafikini ayırmaq üçün xaricə gedən trafik müştəriyə ayrılmış etiketlə işarələnmiş VLAN olacaq.
Nəticədə aşağıdakı sxemi əldə etdik:
Ağlabatan sual budur ki, niyə hesablama qovşaqlarının özlərində şlüzlər yaratmayaq? Bu böyük problem deyil, üstəlik, paylanmış marşrutlaşdırıcını (DVR) işə saldıqda, o, belə işləyəcək. Bu ssenaridə biz Openstack-də standart olaraq istifadə olunan mərkəzləşdirilmiş şlüzlə ən sadə variantı nəzərdən keçiririk. Yüksək yüklü funksiyalar üçün onlar həm paylanmış marşrutlaşdırıcıdan, həm də SR-IOV və Passthrough kimi sürətləndirmə texnologiyalarından istifadə edəcəklər, lakin necə deyərlər, bu tamamilə fərqli bir hekayədir. Əvvəlcə əsas hissə ilə məşğul olaq, sonra detallara keçək.
Əslində, sxemimiz artıq işləyir, lakin bir neçə nüans var:
- Maşınlarımızı birtəhər qorumalıyıq, yəni keçid interfeysində müştəriyə doğru filtr asmalıyıq.
- Virtual maşın vasitəsilə avtomatik olaraq IP ünvanını əldə etməyə imkan yaradın ki, hər dəfə onu konsol vasitəsilə daxil etməyə və ünvanı təyin etməyə ehtiyac qalmasın.
Avtomobilin qorunması ilə başlayaq. Bunun üçün banal iptables istifadə edə bilərsiniz, niyə olmasın.
Yəni, indi topologiyamız bir az daha mürəkkəbləşib:
Gəlin daha da irəli gedək. DHCP server əlavə etməliyik. Müştərilərin hər biri üçün DHCP serverlərini tapmaq üçün ən ideal yer ad fəzalarının yerləşdiyi yuxarıda qeyd olunan idarəetmə qovşağıdır:
Bununla belə, kiçik bir problem var. Hər şey yenidən başlasa və bütün DHCP icarə məlumatları yox olarsa nə olacaq. Maşınlara yeni ünvanların verilməsi məntiqlidir ki, bu da çox rahat deyil. İki çıxış yolu var - ya domen adlarından istifadə edin və hər bir müştəri üçün DNS serveri əlavə edin, onda ünvan bizim üçün çox vacib olmayacaq (k8s-dəki şəbəkə hissəsinə bənzər) - ancaq xarici şəbəkələrdə problem var, çünki ünvanlar onlarda DHCP vasitəsilə də verilə bilər - bulud platformasındakı DNS serverləri və xarici DNS serveri ilə sinxronizasiya lazımdır, mənim fikrimcə, çox çevik deyil, lakin bu, olduqca mümkündür. Və ya ikinci seçim metadatadan istifadə etməkdir - yəni maşına verilən ünvan haqqında məlumatı saxlamaq üçün DHCP serveri maşın artıq ünvanı aldıqda maşına hansı ünvanın veriləcəyini bilsin. İkinci seçim daha sadə və daha çevikdir, çünki bu, avtomobil haqqında əlavə məlumatı saxlamağa imkan verir. İndi isə agentin metadatasını sxemə əlavə edək:
Təqdis etməyə dəyər olan başqa bir məsələ bütün müştərilər tərəfindən bir xarici şəbəkədən istifadə etmək imkanıdır, çünki xarici şəbəkələr bütün şəbəkədə etibarlı olmalıdırsa, çətin olacaq - bu şəbəkələrin ayrılmasını daim seçmək və nəzarət etmək lazımdır. Bütün müştərilər üçün əvvəlcədən konfiqurasiya edilmiş bir xarici şəbəkədən istifadə etmək imkanı ictimai bulud yaratarkən çox faydalı olacaqdır. Bu, maşınların yerləşdirilməsini asanlaşdıracaq, çünki biz ünvan verilənlər bazasına müraciət etməli və hər bir müştərinin xarici şəbəkəsi üçün unikal ünvan məkanı seçməli deyilik. Bundan əlavə, biz əvvəlcədən xarici şəbəkə təyin edə bilərik və yerləşdirmə zamanı yalnız xarici ünvanları müştəri maşınları ilə əlaqələndirməliyik.
Və burada NAT köməyə gəlir - biz sadəcə olaraq müştərilərin NAT tərcüməsindən istifadə edərək standart ad məkanı vasitəsilə xarici dünyaya çıxışını mümkün edəcəyik. Yaxşı, burada bir az problem var. Müştəri serveri server kimi deyil, müştəri kimi işləyirsə, bu yaxşıdır - yəni əlaqələri işə salır və qəbul etmir. Amma bizim üçün hər şey əksinə olacaq. Bu halda, təyinat NAT-ı elə etməliyik ki, trafik qəbul edildikdə, idarəetmə qovşağı bu trafikin A müştərisinin virtual maşını A üçün nəzərdə tutulduğunu başa düşsün, bu o deməkdir ki, biz xarici ünvandan, məsələn, 100.1.1.1-dən NAT tərcüməsi etməliyik. 10.0.0.1 daxili ünvana 100. Bu halda, bütün müştərilər eyni şəbəkədən istifadə etsə də, daxili izolyasiya tamamilə qorunur. Yəni idarəetmə qovşağında dNAT və sNAT etməliyik. Üzən ünvanların və ya xarici şəbəkələrin və ya hər ikisinin eyni vaxtda ayrılması ilə bir şəbəkədən istifadə edin - bu, onu buludda sıxışdırmaq istəməyinizlə müəyyən edilir. Diaqramda üzən ünvanları da qoymayacağıq, lakin əvvəllər əlavə edilmiş xarici şəbəkələri tərk edəcəyik - hər bir müştərinin öz xarici şəbəkəsi var (diaqramda onlar xarici interfeysdə vlan 200 və XNUMX kimi göstərilmişdir).
Nəticədə, biz maraqlı və eyni zamanda yaxşı düşünülmüş müəyyən bir çevikliyə malik olan, lakin bu günə qədər qüsurlara dözümlülük mexanizmlərinə malik olmayan bir həll əldə etdik.
Birincisi, bizdə yalnız bir nəzarət node var - onun uğursuzluğu bütün sistemlərin dağılmasına səbəb olacaq. Bu problemi həll etmək üçün ən azı 3 qovşaqdan ibarət kvorum yaratmalısınız. Bunu diaqrama əlavə edək:
Təbii ki, bütün qovşaqlar sinxronlaşdırılır və aktiv qovşaq çıxdıqda, başqa bir qovşaq öz vəzifələrini yerinə yetirir.
Növbəti məsələ virtual maşın diskləridir. Hazırda onlar hipervizorların özlərində saxlanılır və hipervizorla bağlı problemlər yaranarsa, biz bütün məlumatları itiririk - və diski deyil, bütün serveri itirsək, reydin olması burada kömək etməyəcək. Bunu etmək üçün hər hansı bir saxlama üçün frontend rolunu oynayacaq bir xidmət etməliyik. Nə cür saxlama olacağı bizim üçün xüsusilə vacib deyil, lakin o, məlumatlarımızı həm diskin, həm də qovşağın və bəlkə də bütün kabinetin nasazlığından qorumalıdır. Burada bir neçə variant var - əlbəttə ki, Fiber Kanallı SAN şəbəkələri var, amma düzünü desək - FC artıq keçmişin yadigarıdır - nəqliyyatda E1-in analoqudur - bəli, razıyam, hələ də istifadə olunur, ancaq yalnız onsuz mümkün olmadığı yerdə. Buna görə də, başqa daha maraqlı alternativlərin olduğunu bildiyim üçün 2020-ci ildə FC şəbəkəsini könüllü olaraq yerləşdirməzdim. Baxmayaraq ki, hər birinin özünə məxsus və bəlkə də FK-nın bütün məhdudiyyətləri ilə bizə lazım olduğuna inananlar var - mübahisə etməyəcəyəm, hər kəsin öz fikri var. Ancaq mənim fikrimcə ən maraqlı həll Ceph kimi SDS-nin istifadəsidir.
Ceph, disklərin serverlərdə və serverlərdə yerləşməsini nəzərə alaraq, paritet kodlarından (reyd 5 və ya 6-ya bənzər) müxtəlif disklərə məlumatların tam təkrarlanmasına qədər mümkün ehtiyat seçimləri ilə yüksək əlçatan saxlama həlli yaratmağa imkan verir. kabinetlərdə və s.
Ceph qurmaq üçün daha 3 node lazımdır. Yaddaşla qarşılıqlı əlaqə həmçinin blok, obyekt və fayl saxlama xidmətlərindən istifadə etməklə şəbəkə vasitəsilə həyata keçiriləcək. Sxemə yaddaş əlavə edək:
Qeyd: hiperkonverged hesablama qovşaqlarını da edə bilərsiniz - bu, bir qovşaqda bir neçə funksiyanın birləşdirilməsi konsepsiyasıdır - məsələn, saxlama + kompüter - ceph saxlama üçün xüsusi qovşaqlar ayırmayın. Eyni xətaya dözümlü sxemi əldə edəcəyik - çünki SDS məlumatları qeyd etdiyimiz ehtiyat səviyyəsi ilə qoruyacaq. Bununla belə, hiper birləşmiş qovşaqlar həmişə bir kompromisdir - saxlama qovşağı ilk baxışdan göründüyü kimi yalnız havanı qızdırmır (çünki orada virtual maşınlar yoxdur) - CPU resurslarını SDS-yə xidmət göstərməyə sərf edir (əslində, hər şeyi edir. fonda təkrarlamalar, qovşaqların, disklərin və s. uğursuzluqlardan sonra bərpa olunur). Yəni, onu yaddaşla birləşdirsəniz, düyünün hesablama gücünün bir hissəsini itirəcəksiniz.
Bütün bunları bir şəkildə idarə etmək lazımdır - bizə maşın, şəbəkə, virtual marşrutlaşdırıcı və s. yarada biləcəyimiz bir şeyə ehtiyacımız var. Bunu etmək üçün idarəetmə qovşağına tablosunun rolunu oynayacaq bir xidmət əlavə edin - müştəri http/ https vasitəsilə bu portala qoşula və ehtiyacı olan hər şeyi edə bil (yaxşı, demək olar).
Nəticə etibarı ilə indi bizdə qüsurlara dözümlü bir sistem var. Bu infrastrukturun bütün elementləri bir şəkildə idarə olunmalıdır. Daha əvvəl təsvir edilmişdir ki, Openstack hər biri müəyyən bir funksiyanı təmin edən layihələr toplusudur. Gördüyümüz kimi, konfiqurasiya edilməli və idarə edilməli olan kifayət qədər elementlər var. Bu gün biz şəbəkə hissəsi haqqında danışacağıq.
Neytron memarlığı
OpenStack-də Neutron virtual maşın portlarını ümumi L2 şəbəkəsinə qoşmaq, müxtəlif L2 şəbəkələrində yerləşən VM-lər arasında trafik marşrutunu təmin etmək, həmçinin xaricə yönləndirmə, NAT, Floating IP, DHCP və s.
Şəbəkə xidmətinin yüksək səviyyədə işləməsini (əsas hissəsi) aşağıdakı kimi təsvir etmək olar.
VM işə salındıqda şəbəkə xidməti:
- Bu VM (və ya portlar) üçün port yaradır və bu barədə DHCP xidmətinə məlumat verir;
- Yeni virtual şəbəkə cihazı yaradılır (libvirt vasitəsilə);
- VM 1-ci addımda yaradılmış port(lar)a qoşulur;
Qəribədir ki, Neytron Linux-a girmiş hər kəsə tanış olan standart mexanizmlərə əsaslanır - bunlar ad məkanları, iptables, linux körpüləri, openvswitch, conntrack və s.
Dərhal aydınlaşdırmaq lazımdır ki, Neytron SDN nəzarətçisi deyil.
Neytron bir-biri ilə əlaqəli bir neçə komponentdən ibarətdir:
openstack-neytron-server API vasitəsilə istifadəçi sorğuları ilə işləyən daemondur. Bu daemon heç bir şəbəkə bağlantısı yazmır, lakin bunun üçün lazım olan məlumatları öz plaginlərinə təqdim edir, sonra isə istədiyiniz şəbəkə elementini konfiqurasiya edir. OpenStack qovşaqlarındakı neytron agentləri Neytron serverində qeydiyyata alınır.
Neytron-server əslində iki hissədən ibarət olan python-da yazılmış proqramdır:
- REST xidməti
- Neytron Plugin (əsas/xidmət)
REST xidməti digər komponentlərdən API zənglərini qəbul etmək üçün nəzərdə tutulmuşdur (məsələn, bəzi məlumatların təqdim edilməsi sorğusu və s.)
Pluginlər API sorğuları əsasında çağırılan plug-in proqram komponentləri / modullarıdır - yəni bir növ xidmətin təyin edilməsi onların vasitəsilə baş verir. Pluginlər iki növə bölünür - xidmət və kök. Bir qayda olaraq, kök plagin əsasən ünvan sahəsinin və VM-lər arasında L2 əlaqələrinin idarə edilməsinə cavabdehdir, xidmət plaginləri isə artıq VPN və ya FW kimi əlavə funksionallıq təmin edir.
Məsələn, hazırda mövcud olan plaginlərin siyahısına baxmaq olar
Bir neçə xidmət plaginləri ola bilər, lakin yalnız bir kök plagin ola bilər.
openstack-neytron-ml2 standart Openstack kök plaginidir. Bu plug-in modul arxitekturaya malikdir (sələfindən fərqli olaraq) və ona qoşulmuş sürücülər vasitəsilə şəbəkə xidmətini konfiqurasiya edir. Biz plaqinin özünü bir az sonra nəzərdən keçirəcəyik, çünki əslində o, OpenStack-in şəbəkə hissəsində olan çevikliyi verir. Kök plagini dəyişdirilə bilər (məsələn, Contrail Networking belə bir dəyişdirmə edir).
RPC xidməti (rabbitmq-server) - növbənin idarə edilməsini və digər OpenStack xidmətləri ilə qarşılıqlı əlaqəni, həmçinin şəbəkə xidməti agentləri arasında qarşılıqlı əlaqəni təmin edən xidmət.
şəbəkə agentləri - şəbəkə xidmətlərinin konfiqurasiya olunduğu hər bir qovşaqda yerləşən agentlər.
Agentlər bir neçə növə malikdir.
Əsas agentdir L2 agent. Bu agentlər hipervizorların hər birində, o cümlədən nəzarət qovşaqlarında (daha doğrusu, kirayəçilər üçün hər hansı bir xidmət göstərən bütün qovşaqlarda) işləyir və onların əsas funksiyası virtual maşınları ümumi L2 şəbəkəsinə qoşmaq, həmçinin hər hansı hadisə baş verdikdə xəbərdarlıq yaratmaqdır. (məsələn, portu söndürmək/aktiv etmək).
Növbəti, heç də az vacib olmayan agentdir L3 agent. Varsayılan olaraq, bu agent yalnız şəbəkə qovşağında işləyir (çox vaxt şəbəkə qovşağı nəzarət qovşağı ilə birləşdirilir) və icarəçi şəbəkələri (həm öz şəbəkələri, həm də digər kirayəçilərin şəbəkələri arasında) arasında marşrutlaşdırmanı təmin edir və NAT təmin etməklə xarici dünya üçün əlçatandır. , həmçinin DHCP xidməti). Bununla belə, DVR (paylanmış marşrutlaşdırıcı) istifadə edərkən, L3 plagininə ehtiyac hesablama qovşaqlarında da görünür.
L3 agenti hər bir icarəçiyə öz təcrid olunmuş şəbəkələri dəsti və trafiki yönləndirən və Layer 2 şəbəkələri üçün şlüz xidmətləri göstərən virtual marşrutlaşdırıcıların funksionallığı ilə təmin etmək üçün Linux ad məkanlarından istifadə edir.
Database - şəbəkələr, alt şəbəkələr, portlar, hovuzlar və s. üçün identifikatorların verilənlər bazası.
Əslində, Neytron hər hansı bir şəbəkə obyektinin yaradılmasından API sorğularını qəbul edir, sorğunu autentifikasiya edir və RPC (bir növ plagin və ya agentə aiddirsə) və ya REST API (əgər SDN-də əlaqə saxlayırsa) vasitəsilə agentlərə ötürür (vasitəsilə). plaginlər) tələb olunan xidməti təşkil etmək üçün lazım olan təlimatlar.
İndi test quraşdırmasına keçək (onun necə yerləşdirildiyini və nəyi ehtiva etdiyini daha sonra praktik hissədə görəcəyik) və hansı komponentin harada yerləşdiyini görək:
(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 ~]$
Əslində, bu, Neytronun bütün quruluşudur. İndi ML2 plagininə bir az vaxt sərf etməyə dəyər.
Modul qat 2
Yuxarıda qeyd edildiyi kimi, plagin standart OpenStack kök plaginidir və modul arxitekturaya malikdir.
ML2 plagininin sələfi, məsələn, bir quraşdırmada bir neçə texnologiyanın qarışığından istifadə etməyə imkan verməyən monolit bir quruluşa sahib idi. Məsələn, siz həm openvswitch, həm də linuxbridge-dən eyni vaxtda istifadə edə bilməzdiniz - istər birinci, istərsə də ikinci. Bu səbəbdən öz arxitekturası ilə ML2 plagini yaradılmışdır.
ML2 iki komponentdən ibarətdir - iki növ sürücü: Tip sürücülər və Mexanizm sürücüləri.
Sürücüləri yazın VxLAN, VLAN, GRE kimi şəbəkə bağlantısını təşkil etmək üçün istifadə olunacaq texnologiyaların müəyyən edilməsi. Bu halda, sürücü müxtəlif texnologiyalardan istifadə etməyə imkan verir. Standart texnologiya overlay şəbəkələri və vlan xarici şəbəkələri üçün VxLAN inkapsulyasiyasıdır.
Tipli sürücülər aşağıdakı şəbəkə növləridir:
Mənzil - etiketləmədən şəbəkə
VLAN - etiketlənmiş şəbəkə
Yerli - hamısı bir yerdə quraşdırmalar üçün xüsusi şəbəkə növü (belə qurğular ya tərtibatçılar, ya da təlim üçün lazımdır)
GRE - GRE tunellərindən istifadə edən overlay şəbəkəsi
VxLAN - VxLAN tunellərindən istifadə edən overlay şəbəkəsi
Mexanizm sürücüləri tipli drayverdə göstərilən texnologiyaların təşkilini təmin edən vasitələri müəyyən edin - məsələn, openvswitch, sr-iov, opendaylight, OVN və s.
Bu drayverin həyata keçirilməsindən asılı olaraq, ya Neytron tərəfindən idarə olunan agentlər istifadə olunacaq, ya da L2 şəbəkələrinin təşkili, marşrutlaşdırma və s. bütün məsələləri həll edən xarici SDN nəzarətçisinə qoşulmalardan istifadə olunacaq.
Məsələn, OVS ilə birlikdə ML2-dən istifadə etsək, OVS-ni idarə edən hər bir hesablama qovşağında L2 agenti quraşdırılır. Bununla belə, məsələn, OVN və ya OpenDayLight istifadə etsək, onda OVS nəzarəti onların yurisdiksiyasına keçir - Neytron kök plagini vasitəsilə nəzarətçiyə əmrlər verir və o, artıq deyilənləri edir.
Open vSwitch yaddaşını təzələyək
Hal-hazırda, OpenStack-in əsas komponentlərindən biri Open vSwitch-dir.
Juniper Contrail və ya Nokia Nuage kimi hər hansı əlavə təchizatçı SDN olmadan OpenStack quraşdırarkən, OVS bulud şəbəkəsinin əsas şəbəkə komponentidir və iptables, conntrack, ad məkanları ilə birlikdə tam hüquqlu multi-icarə şəbəkəsini təşkil etməyə imkan verir. Təbii ki, bu komponent, məsələn, üçüncü tərəfin mülkiyyət (satıcı) SDN həllərindən istifadə edərkən dəyişdirilə bilər.
OVS virtual trafik ekspeditoru kimi virtuallaşdırılmış mühitlərdə istifadə üçün nəzərdə tutulmuş açıq mənbə proqram təminatı açarıdır.
Hal-hazırda OVS çox layiqli funksionallığa malikdir, o cümlədən QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK və s.
Qeyd: Başlanğıcda, OVS yüksək yüklü telekommunikasiya funksiyaları üçün softswitch kimi düşünülməmişdi və daha çox WEB server və ya poçt serveri kimi daha az bant genişliyi tələb edən İT funksiyaları üçün nəzərdə tutulmuşdu. Bununla belə, OVS yekunlaşdırılır və mövcud OVS tətbiqləri onun performansını və imkanlarını xeyli yaxşılaşdırıb, bu da onu yüksək yüklənmiş funksiyaları olan telekommunikasiya operatorları tərəfindən istifadə etməyə imkan verir, məsələn, DPDK sürətləndirmə dəstəyi ilə OVS tətbiqi mövcuddur.
Xəbərdar olmaq üçün üç mühüm OVS komponenti var:
- Kernel modulu - idarəetmə elementindən alınan qaydalar əsasında trafiki emal edən nüvə məkanında yerləşən komponent;
- v keçid daemon (ovs-vswitchd) istifadəçi məkanında işləyən, nüvə modulunun proqramlaşdırılmasına cavabdeh olan bir prosesdir - yəni birbaşa keçidin məntiqini təmsil edir.
- Verilənlər bazası serveri konfiqurasiyanı saxlayan OVS ilə işləyən hər bir hostda yerləşən yerli verilənlər bazasıdır. Bu modul vasitəsilə SDN nəzarətçiləri OVSDB protokolundan istifadə edərək əlaqə saxlaya bilərlər.
Bütün bunlar ovs-vsctl, ovs-appctl, ovs-ofctl və s. kimi diaqnostika və idarəetmə proqramlarının dəsti ilə müşayiət olunur.
Hal-hazırda, Openstack, EPC, SBC, HLR və s. kimi şəbəkə funksiyalarını ona köçürmək üçün telekommunikasiya operatorları tərəfindən geniş istifadə olunur. Bəzi funksiyalar olduğu formada OVS ilə problemsiz yaşaya bilər, lakin məsələn, EPC prosesləri abunəçi trafiki - sonra böyük miqdarda trafikdən keçir (indi trafik həcmi saniyədə bir neçə yüz giqabitə çatır). Təbii ki, bu cür trafikin nüvə məkanı vasitəsilə aparılması (çünki ekspeditor default olaraq orada yerləşir) ən yaxşı fikir deyil. Buna görə də, OVS tez-tez DPDK sürətləndirmə texnologiyasından istifadə edərək, nüvəni keçərək NIC-dən istifadəçi məkanına trafik yönləndirmək üçün tamamilə istifadəçi məkanında yerləşdirilir.
Qeyd: telekommunikasiya funksiyaları üçün yerləşdirilmiş bulud üçün OVS-dən yan keçərək hesablama qovşaqlarından trafiki birbaşa keçid avadanlığına çıxarmaq mümkündür. Bu məqsədlə SR-IOV və Passthrough mexanizmlərindən istifadə olunur.
Həqiqi tərtibatda necə işləyir?
Yaxşı, indi praktik hissəyə keçək və bunların hamısının praktikada necə işlədiyini görək.
Əvvəlcə sadə Openstack quraşdırmasını yerləşdirək. Təcrübələr üçün əlimdə bir sıra server olmadığına görə, biz virtual maşınlardan bir fiziki serverdə tərtibatı yığacağıq. Bəli, əlbəttə ki, belə bir həll kommersiya məqsədləri üçün uyğun deyil, lakin Openstack-də şəbəkənin necə işlədiyini görmək üçün belə bir quraşdırma gözlər üçün kifayətdir. Üstəlik, təlim məqsədləri üçün belə bir quraşdırma daha maraqlıdır - çünki trafiki tuta bilərsiniz və s.
Yalnız əsas hissəni görmək lazım olduğundan, biz bir neçə şəbəkədən istifadə edə bilmərik, ancaq yalnız iki şəbəkədən istifadə edərək hər şeyi qaldırırıq və bu layoutdakı ikinci şəbəkə yalnız bulud və dns serverinə daxil olmaq üçün istifadə olunacaq. Hələlik xarici şəbəkələrə toxunmayacağıq - bu ayrı bir böyük məqalənin mövzusudur.
Beləliklə, sıra ilə başlayaq. Birincisi, bir az nəzəriyyə. TripleO (Openstack on Openstack) istifadə edərək Openstack quraşdıracağıq. TripleO-nun mahiyyəti ondan ibarətdir ki, biz undercloud adlanan Openstack all-in-one-ni (yəni bir qovşaqda) quraşdırırıq və sonra yerləşdirilmiş Openstack-in imkanlarından istifadə edərək overcloud adlanan istismar üçün nəzərdə tutulmuş Openstack-i quraşdırırıq. Undercloud fiziki serverləri (çılpaq metal) idarə etmək qabiliyyətindən istifadə edəcək - Ironic layihəsi - hesablama, nəzarət, saxlama qovşaqları kimi çıxış edəcək hipervizorları təmin etmək üçün. Yəni, biz Openstack-i yerləşdirmək üçün heç bir üçüncü tərəf alətindən istifadə etmirik - Openstack-i Openstack istifadə edərək yerləşdiririk. Quraşdırma zamanı daha aydın olacaq, buna görə də orada dayanmayacağıq və davam edəcəyik.
Qeyd: Bu məqalədə sadəlik üçün mən Openstack-in daxili şəbəkələri üçün şəbəkə izolyasiyasından istifadə etməmişəm, lakin hər şey yalnız bir şəbəkədən istifadə etməklə yerləşdirilib. Bununla belə, şəbəkə izolyasiyasının olması və ya olmaması həllin əsas funksionallığına təsir göstərmir - hər şey izolyasiyadan istifadə edərkən olduğu kimi işləyəcək, lakin trafik eyni şəbəkədə gedəcək. Kommersiya quraşdırma üçün, təbii olaraq müxtəlif vlan və interfeyslərdən istifadə edərək izolyasiyadan istifadə etmək lazımdır. Məsələn, ceph yaddaş idarəetmə trafiki və birbaşa məlumat trafiki (disklərə maşın girişi və s.) izolyasiya zamanı müxtəlif alt şəbəkələrdən istifadə edir (Storage Management and Storage) və bu, bu trafiki bölmək yolu ilə həlli səhvlərə daha dözümlü etməyə imkan verir. məsələn, müxtəlif portlara daxil olun və ya fərqli trafik üçün fərqli QoS profillərindən istifadə edin ki, məlumat trafiki siqnal trafikini sıxmasın. Bizim vəziyyətimizdə onlar eyni şəbəkəyə gedəcəklər və əslində bu, bizi heç bir şəkildə məhdudlaşdırmır.
Qeyd: Virtual maşınları virtual maşın-əsaslı mühitdə işlədəcəyimiz üçün əvvəlcə iç içə virtuallaşdırmanı aktivləşdirməliyik.
Daxili virtuallaşdırmanın aktiv olub olmadığını yoxlaya bilərsiniz:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#N hərfini görürsünüzsə, məsələn, şəbəkədə tapdığınız hər hansı bələdçiyə uyğun olaraq daxili virtualizasiya dəstəyini aktivləşdirin. .
Virtual maşınlardan aşağıdakı sxemi yığmalıyıq:
Mənim vəziyyətimdə, gələcək quraşdırmanın bir hissəsi olan virtual maşınların qoşulması üçün (və onlardan 7-si məndə var, lakin çoxlu resursunuz yoxdursa, 4 ilə əldə edə bilərsiniz) OpenvSwitch-dən istifadə etdim. Mən bir ovs körpüsü yaratdım və ona virtual maşınları port qrupları vasitəsilə bağladım. Bunun üçün aşağıdakı formada xml faylı yaratdım:
[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>Burada üç port qrupu elan edilmişdir - iki giriş və bir magistral (sonuncu DNS serveri üçün lazım idi, lakin siz onsuz edə bilərsiniz və ya host maşınında qaldıra bilərsiniz - hansı sizin üçün daha əlverişlidir). Sonra, bu şablondan istifadə edərək, virsh net-define vasitəsilə özümüzü elan edirik:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 İndi hipervizor portlarının konfiqurasiyasını redaktə edirik:
[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 ~]# Qeyd: bu ssenaridə ovs-br1 portundakı ünvan mövcud olmayacaq, çünki onun vlan teqi yoxdur. Bunu düzəltmək üçün sudo ovs-vsctl set port ovs-br1 tag=100 əmrini verməlisiniz. Bununla belə, yenidən başladıqdan sonra bu etiket yox olacaq (əgər kimsə onun yerində qalmasını bilirsə, mən çox minnətdar olacağam). Amma bu o qədər də vacib deyil, çünki bu ünvan bizə yalnız quraşdırma zamanı lazım olacaq və Openstack tam yerləşdirildikdə ehtiyac olmayacaq.
Sonra, buludsuz maşın yaradın:
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=ttyS0Quraşdırma zamanı siz maşın adı, parollar, istifadəçilər, ntp serverləri və s. kimi bütün lazımi parametrləri təyin edirsiniz. Siz dərhal portları konfiqurasiya edə bilərsiniz, lakin quraşdırmadan sonra konsol vasitəsilə maşına daxil olmaq və lazımi parametrləri düzəltmək şəxsən mənim üçün daha asandır. fayllar. Əgər artıq hazır şəkliniz varsa, ondan istifadə edə bilərsiniz və ya mənim etdiyim kimi edə bilərsiniz - minimum Centos 7 şəklini yükləyin və ondan VM-i quraşdırmaq üçün istifadə edin.
Uğurlu quraşdırmadan sonra, alt bulud quraşdıra biləcəyiniz bir virtual maşınınız olmalıdır
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningƏvvəlcə quraşdırma prosesi zamanı lazımi alətləri quraşdırırıq:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Bulud altında quraşdırma
Biz stack istifadəçisi yaradırıq, parol təyin edirik, onu sudoer-ə əlavə edirik və ona parol daxil etmədən sudo vasitəsilə root əmrlərini yerinə yetirmək imkanı veririk:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackİndi host faylında alt buludun tam adını təyin edirik:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Sonra, depoları əlavə edin və bizə lazım olan proqramı quraşdırın:
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-ansibleQeyd: ceph quraşdırmağı planlaşdırmırsınızsa, o zaman ceph ilə əlaqəli əmrləri daxil etməyə ehtiyac yoxdur. Mən Queens buraxılışını istifadə etdim, amma istədiyinizi istifadə edə bilərsiniz.
Sonra, bulud konfiqurasiya faylını yığın istifadəçisinin ev kataloquna kopyalayın:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confİndi bu faylı quraşdırmamıza uyğunlaşdıraraq düzəltməliyik.
Faylın əvvəlinə aşağıdakı sətirləri əlavə edin:
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 = 10Beləliklə, parametrlərə keçək:
undercloud_hostname - alt bulud serverinin tam adı, DNS serverindəki girişə uyğun olmalıdır
yerli_ip - yerli ünvan şəbəkənin təmin edilməsi istiqamətində bulud altındadır
şəbəkə_gateway - həddindən artıq buludlu qovşaqların quraşdırılması zamanı xarici dünyaya giriş qapısı rolunu oynayacaq eyni yerli ünvan da yerli IP-yə uyğun gəlir.
undercloud_public_host - xarici API ünvanı, təminat şəbəkəsindən istənilən pulsuz ünvan təyin edilir
undercloud_admin_host daxili API ünvanı, təminat şəbəkəsindən istənilən pulsuz ünvan təyin edilir
undercloud_nameservers - DNS server
xidmət_sertifikatı yaradın - bu xətt cari nümunədə çox vacibdir, çünki onu yanlış olaraq təyin etməsəniz, quraşdırma xətası alacaqsınız, problem Red Hat bug izləyicisində təsvir edilmişdir
yerli_interfeys təminat şəbəkəsinə interfeys. Bu interfeys yeraltı buludda yerləşdirmə zamanı yenidən konfiqurasiya ediləcək, ona görə də siz buludda iki interfeysə malik olmalısınız - biri ona daxil olmaq üçün, ikincisi isə təchizat üçün
local_mtu - MTU. Sınaq laboratoriyamız olduğundan və keçidin OVS portlarında MTU 1500 olduğu üçün VxLAN-da kapsullaşdırılmış paketlərin keçməsi üçün onu 1450-yə təyin etmək lazımdır.
şəbəkə_sidr - təminat şəbəkəsi
maskarad - xarici şəbəkəyə daxil olmaq üçün NAT-dan istifadə
maskarad_şəbəkəsi - NAT-Xia olacaq bir şəbəkə
dhcp_start - həddindən artıq buludlu yerləşdirmə zamanı qovşaqlara ünvanların təyin ediləcəyi ünvan hovuzunun başlanğıc ünvanı
dhcp_end - həddindən artıq buludlu yerləşdirmə zamanı ünvanların qovşaqlara təyin ediləcəyi ünvan hovuzunun son ünvanı
inspection_iprange - introspeksiya üçün tələb olunan ünvanlar hovuzu (yuxarıdakı hovuzla üst-üstə düşməməlidir)
planlayıcı_max_cəhdləri - həddindən artıq bulud quraşdırmaq cəhdlərinin maksimum sayı (qovşaqların sayından çox və ya ona bərabər olmalıdır)
Fayl təsvir edildikdən sonra, buludun yerləşdirilməsi üçün əmr verə bilərsiniz:
openstack undercloud install
Prosedur ütüdən asılı olaraq 10-30 dəqiqə çəkir. Nəhayət, belə bir çıxış görməlisiniz:
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.
#############################################################################Bu çıxışda deyilir ki, siz undercloud-u uğurla quraşdırmısınız və indi siz buludun vəziyyətini yoxlaya və overcloud-un quraşdırılmasına keçə bilərsiniz.
ifconfig çıxışına baxsanız, yeni körpü interfeysinin göründüyünü görəcəksiniz
[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 0Bu interfeys vasitəsilə artıq buludun yerləşdirilməsi üçün işlər görüləcək.
Aşağıdakı çıxışdan görə bilərsiniz ki, bizim bütün xidmətlərimiz eyni qovşaqdadır:
(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 |
+--------------------------+-----------+----------+Aşağıda buludlu şəbəkə hissəsinin konfiqurasiyası verilmişdir:
(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 ~]$buludlu quraşdırma
Hal-hazırda bizdə yalnız alt bulud var və buludun qurulacağı kifayət qədər qovşaqlarımız yoxdur. Buna görə də ilk addım bizə lazım olan virtual maşınları yerləşdirməkdir. Yerləşdirmə zamanı undercloud özü OS və lazımi proqramı maşının həddindən artıq buludunda quraşdıracaq - yəni maşını tam yerləşdirməyə ehtiyacımız yoxdur, ancaq bunun üçün bir disk (və ya disklər) yaradıb onun parametrlərini müəyyənləşdirin - yəni əslində biz üzərində OS quraşdırılmamış çılpaq server alırıq.
Virtual maşınlarımızın diskləri olan qovluğa keçin və lazımi ölçüdə disklər yaradın:
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 160GKök kimi fəaliyyət göstərdiyimiz üçün hüquqlarla bağlı problem yaşamamaq üçün bu disklərin sahibini dəyişdirməliyik:
[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]# Qeyd: əgər siz onu öyrənmək üçün ceph quraşdırmağı planlaşdırmırsınızsa, o zaman əmrlər ən azı iki diskli ən azı 3 qovşaq yaratmır, lakin şablonda vda, vdb və s. virtual disklərdən istifadə ediləcəyini göstərir.
Əla, indi bütün bu maşınları müəyyən etməliyik:
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 Sonda əmrlər var - print-xml > /tmp/storage-1.xml, bu /tmp/ qovluğunda hər bir maşının təsviri ilə xml faylı yaradır, onu əlavə etməsəniz, edə bilməyəcəksiniz. virtual maşınları müəyyən etmək.
İndi bütün bu maşınları virsh-də müəyyən etməliyik:
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 ~]#İndi bir az nüans - tripleO quraşdırma və introspeksiya zamanı serverləri idarə etmək üçün IPMI istifadə edir.
İntrospeksiya, qovşaqların sonrakı təmin edilməsi üçün lazım olan parametrləri əldə etmək üçün aparatın yoxlanılması prosesidir. İntrospeksiya çılpaq metal serverlərlə işləmək üçün nəzərdə tutulmuş ironic xidmətinin köməyi ilə həyata keçirilir.
Ancaq problem buradadır - əgər IPMI dəmir serverlərinin ayrıca portu varsa (və ya paylaşılan port, lakin bu vacib deyil), virtual maşınlarda belə portlar yoxdur. Burada vbmc adlı qoltuqağacı köməyimizə gəlir - IPMI portunu təqlid etməyə imkan verən bir yardım proqramı. Bu nüansa xüsusilə ESXI hipervizorunda belə bir laboratoriya qurmaq istəyənlər üçün diqqət yetirməyə dəyər - düzünü desəm, onun vbmc analoqunun olub-olmadığını bilmirəm, ona görə də yerləşdirmədən əvvəl bu sual sizi çaşdırmalıdır. hər şey.
vbmc quraşdırın:
yum install yum install python2-virtualbmcƏgər OS paketi tapa bilmirsə, deponu əlavə edin:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmİndi köməkçi proqramı quraq. Burada hər şey biabır etmək üçün banaldır. İndi məntiqlidir ki, vbmc siyahısında heç bir server yoxdur
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Onların görünməsi üçün əl ilə bu şəkildə elan edilməlidir:
[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 ~]#Məncə, əmrin sintaksisi izahatsız aydındır. Bununla belə, hələlik bütün seanslarımız AŞAĞI vəziyyətdədir. Onların UP statusuna keçməsi üçün onları aktivləşdirməlisiniz:
[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 ~]#Və son toxunuş - firewall qaydalarını düzəltmək lazımdır (yaxşı və ya tamamilə söndürün):
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
İndi buludlara gedək və hər şeyin işlədiyini yoxlayaq. Əsas maşının ünvanı 192.168.255.200-dir, yerləşdirməyə hazırlıq zamanı lazımi ipmitool paketini alt buluda əlavə etdik:
[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 runningGördüyünüz kimi, vbmc vasitəsilə idarəetmə qovşağını uğurla işə saldıq. İndi onu söndürün və davam edin:
[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 ~]#Növbəti addım buludun yerləşdiriləcəyi qovşaqların introspeksiyasıdır. Bunun üçün qovşaqlarımızın təsviri ilə json faylı hazırlamalıyıq. Nəzərə alın ki, çılpaq serverlərdə quraşdırmadan fərqli olaraq, fayl maşınların hər biri üçün vbmc-nin işlədiyi portu müəyyən edir.
[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:27Qeyd: idarəetmə qovşağında iki interfeys var, lakin bu halda fərq etməz, bu quraşdırmada biri bizim üçün kifayətdir.
İndi json faylını hazırlayırıq. Təminatın aparılacağı portun xaşxaş ünvanını, qovşaqların parametrlərini, onlara adlar verməli və ipmi-yə necə çatacağımızı göstərməliyik:
{
"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"
}
]
}İndi biz şəkilləri istehzaya hazırlamalıyıq. Bunu etmək üçün onları wget vasitəsilə yükləyin və quraşdırın:
(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 ~]$Şəkilləri buludlara yükləyin:
(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 ~]$Bütün şəkillərin yükləndiyini yoxlayın
(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 ~]$Daha bir toxunuş - bir dns server əlavə etməlisiniz:
(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 ~]$İndi introspeksiyaya əmr verə bilərik:
(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 ~]$Çıxışdan göründüyü kimi, hər şey səhvsiz tamamlandı. Bütün qovşaqların mövcud vəziyyətdə olduğunu yoxlayın:
(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 ~]$ Düyünlər fərqli bir vəziyyətdədirsə, adətən idarə oluna bilər, onda bir şey səhv oldu və bunun niyə baş verdiyini anlamaq üçün jurnala baxmaq lazımdır. Nəzərə alın ki, bu ssenaridə biz virtuallaşdırmadan istifadə edirik və virtual maşınlardan və ya vbmc-dən istifadə ilə bağlı səhvlər ola bilər.
Sonra, hansı qovşağın hansı funksiyanı yerinə yetirəcəyini müəyyən etməliyik - yəni qovşağın yerləşdirəcəyi profili göstərin:
(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 ~]$Hər qovşaq üçün profil təyin edin:
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-d9afb69d1167Hər şeyi düzgün etdiyimizi yoxlayırıq:
(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 ~]$Hər şey düzgündürsə, biz buludun yerləşdirilməsi əmrini veririk:
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 qemuHəqiqi quraşdırmada onlar təbii olaraq fərdiləşdirilmiş şablonlardan istifadə edəcəklər, bizim vəziyyətimizdə bu, prosesi xeyli çətinləşdirəcək, çünki şablonda hər bir redaktəni izah etmək lazım gələcək. Daha əvvəl yazıldığı kimi, bunun necə işlədiyini görmək üçün sadə bir quraşdırma belə kifayət edəcəkdir.
Qeyd: --libvirt tipli qemu dəyişəni bu halda lazımdır, çünki biz iç içə virtuallaşdırmadan istifadə edəcəyik. Əks halda virtual maşınları işlətməyəcəksiniz.
İndi təxminən bir saat və ya bəlkə də daha çox vaxtınız var (ütün imkanlarından asılı olaraq) və yalnız bu müddətdən sonra bu yazını görəcəyinizə ümid edə bilərsiniz:
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 ~]$İndi açıq yığının demək olar ki, tam hüquqlu bir versiyası var, onun üzərində öyrənmək, sınaqdan keçirmək və s.
Hər şeyin yaxşı işlədiyini yoxlayaq. İstifadəçinin əsas kataloq yığınında iki fayl var - biri stackrc (buludun idarə edilməsi üçün) və ikincisi overcloudrc (buludun idarə edilməsi üçün). Bu fayllar mənbə kimi göstərilməlidir, çünki onlar autentifikasiya üçün lazım olan məlumatları ehtiva edir.
(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 ~]$Quraşdırmağım hələ də kiçik bir toxunuşa ehtiyac duyur - nəzarətçiyə marşrut əlavə etmək üçün, çünki işlədiyim maşın başqa şəbəkədədir. Bunu etmək üçün istilik-admin hesabının altında nəzarət-1-ə keçin və marşrutu yazın
(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.254Yaxşı, indi üfüqə gedə bilərsiniz. Bütün məlumatlar - ünvanlar, giriş və şifrə - /home/stack/overcloudrc faylındadır. Son sxem belə görünür:
Yeri gəlmişkən, quraşdırmamızda maşın ünvanları DHCP vasitəsilə verilirdi və gördüyünüz kimi, onlar "hər halda" verilir. Lazım gələrsə, yerləşdirmə zamanı hansı ünvanın hansı maşına əlavə olunacağını şablonda kodlaşdıra bilərsiniz.
Virtual maşınlar arasında trafik axını necə olur?
Bu yazıda trafikin keçməsi üçün üç variantı nəzərdən keçirəcəyik
- Bir L2 şəbəkəsində bir hipervizorda iki maşın
- Eyni L2 şəbəkəsində müxtəlif hipervizorlarda iki maşın
- Müxtəlif şəbəkələrdə iki maşın (şəbəkələrarası kökləmə)
Xarici şəbəkə vasitəsilə xarici aləmə çıxış, üzən ünvanlar, həmçinin paylanmış marşrutlaşdırma ilə bağlı hallara növbəti dəfə baxılacaq, hələlik biz daxili trafikə diqqət yetirəcəyik.
Test etmək üçün aşağıdakı sxemi birləşdirək:
Biz 4 virtual maşın yaratdıq - 3-ü eyni L2 şəbəkəsində - net-1 və daha 1 ədəd net-2 şəbəkəsində
(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 ~]$ Yaradılan maşınların hansı hipervizorlarda yerləşdiyinə baxaq:
(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 |
(overbulud) [stack@undercloud ~]$
Vm-1 və vm-3 maşınları hesablama-0, vm-2 və vm-4 maşınları hesablama-1-də yerləşir.
Bundan əlavə, göstərilən şəbəkələr arasında marşrutlaşdırmanı təmin etmək üçün virtual marşrutlaşdırıcı yaradılmışdır:
(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 ~]$ Routerdə şəbəkələr üçün şlüz rolunu oynayan iki virtual port var:
(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 ~]$ Amma trafikin necə getdiyinə nəzər salmazdan əvvəl gəlin nəzarət qovşağında (bu həm də şəbəkə qovşağıdır) və hesablama qovşağında hazırda nələrə sahib olduğumuza baxaq. Hesablama qovşağından başlayaq.
[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 ~]$Hal-hazırda qovşaqda üç ovs körpüsü var - br-int, br-tun, br-ex. Onların arasında, gördüyümüz kimi, bir sıra interfeyslər var. Qavrama asanlığı üçün gəlin bütün bu interfeysləri diaqrama yerləşdirək və nə baş verdiyini görək.
VxLAN tunellərinin qaldırıldığı ünvanlardan bir tunelin hesablama-1 (192.168.255.26), ikinci tunelin idarəetmə-1 (192.168.255.15) üzərində qaldırıldığını görmək olar. Amma ən maraqlısı odur ki, br-ex-in fiziki interfeysləri yoxdur və hansı axınların konfiqurasiya edildiyinə baxsanız, bu körpünün hazırda yalnız trafiki azalda biləcəyini görə bilərsiniz.
[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 ~]$ Çıxışdan göründüyü kimi, ünvan virtual körpü interfeysinə deyil, birbaşa fiziki porta vidalanır.
[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 ~]$
Birinci qaydaya görə, phy-br-ex portundan gələn hər şey atılmalıdır.
Əslində, bu interfeysdən (br-int ilə qovşaq) başqa bu körpüyə trafik əldə etmək üçün hələ başqa yer yoxdur və azalmalara görə, BUM trafiki artıq körpüyə çatıb.
Yəni, bu qovşaqdan gələn trafik yalnız VxLAN tunelindən keçə bilər və başqa heç nə yoxdur. Bununla belə, DVR-ni yandırsanız, vəziyyət dəyişəcək, lakin biz bununla başqa vaxt məşğul olacağıq. Şəbəkə izolyasiyasından istifadə edərkən, məsələn, vlanlardan istifadə edərkən, 3-cı vlanda bir L0 interfeysi yox, bir neçə interfeys olacaq. Bununla belə, VxLAN trafiki qovşaqdan tam eyni şəkildə çıxacaq, həm də bəzi xüsusi vlan-da əhatə olunacaq.
Hesablama qovşağını anladıq, idarəetmə qovşağına keçin.
[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 ~]$Əslində hər şeyin eyni olduğunu deyə bilərik, bununla belə, ip ünvanı artıq fiziki interfeysdə deyil, virtual körpüdədir. Bu, bu limanın trafikin xarici dünyaya keçəcəyi liman olduğu üçün edilir.
[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 ~]$ Bu port br-ex körpüsünə bağlıdır və heç bir vlan teqləri olmadığı üçün bu port bütün vlanlara icazə verilən magistral portdur, indi vlan-id 0 ilə göstərildiyi kimi trafik etiketsiz çıxır. yuxarıdakı çıxış.
Hazırda hər şey hesablama qovşağına bənzəyir - eyni körpülər, iki hesablama qovşağına gedən eyni tunellər.
Bu yazıda saxlama qovşaqlarını nəzərdən keçirməyəcəyik, lakin başa düşmək üçün bu qovşaqların şəbəkə hissəsinin rüsvay etmək üçün banal olduğunu söyləmək lazımdır. Bizim vəziyyətimizdə ona təyin edilmiş ip ünvanı olan yalnız bir fiziki port (eth0) var, vəssalam. VxLAN tunelləri, tunel körpüləri və s. yoxdur - ümumiyyətlə ovs yoxdur, çünki bunun mənası yoxdur. Şəbəkə izolyasiyasından istifadə edərkən - bu node iki interfeysə sahib olacaq (fiziki portlar, bodnlar və ya sadəcə iki vlan - fərq etməz - nə istədiyinizdən asılıdır) - biri nəzarət üçün, ikincisi trafik üçün (VM diskinə yazma) , diskdən oxumaq və s.).
Heç bir xidmət olmadıqda qovşaqlarda nə olduğunu anladıq. İndi gəlin 4 virtual maşını işə salaq və yuxarıda təsvir edilən sxemin necə dəyişdiyini görək - portlarımız, virtual marşrutlaşdırıcılarımız və s.
İndiyə qədər şəbəkəmiz belə görünür:
Hər kompüter qovşağında iki virtual maşınımız var. Nümunə olaraq hesablama-0-dan istifadə edərək, hər şeyin necə daxil edildiyini görək.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Maşının yalnız bir virtual interfeysi var - 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 ~]$
Bu interfeys linux körpüsündə görünür:
[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 ~]$ Çıxışdan göründüyü kimi, körpüdə yalnız iki interfeys var - tap95d96a75-a0 və qvb95d96a75-a0.
Burada OpenStack-də virtual şəbəkə cihazlarının növləri üzərində bir az dayanmağa dəyər:
vtap nümunəyə (VM) qoşulmuş virtual interfeysdir.
qbr - Linux körpüsü
qvb və qvo - vEth cütü Linux körpüsünə və Open vSwitch körpüsünə qoşulub
br-int, br-tun, br-vlan - vSwitch körpülərini açın
patch-, int-br-, phy-br- — körpüləri birləşdirən vSwitch patch interfeyslərini açın
qg, qr, ha, fg, sg - OVS-ə qoşulmaq üçün virtual cihazlar tərəfindən istifadə edilən vSwitch portlarını açın
Anladığınız kimi, əgər körpüdə vEth cütü olan qvb95d96a75-a0 portumuz varsa, deməli, haradasa məntiqi olaraq qvo95d96a75-a0 adlandırılmalı olan həmkarı var. OVS-də hansı portların olduğuna baxırıq.
[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 ~]$ Gördüyümüz kimi liman br-int-dədir. Br-int virtual maşın portlarını dayandıran keçid rolunu oynayır. Qvo95d96a75-a0 ilə yanaşı, çıxışda qvo5bd37136-47 portu görünür. Bu, ikinci virtual maşın üçün bir portdur. Nəticədə, sxemimiz indi belə görünür:
Diqqətli oxucunu dərhal maraqlandıran sual virtual maşın portu ilə OVS portu arasında hansı linux körpüsüdür? Fakt budur ki, iptables-dən başqa bir şey olmayan maşını qorumaq üçün təhlükəsizlik qrupları istifadə olunur. OVS iptables ilə işləmir, buna görə də belə bir "köpək" icad edilmişdir. Bununla belə, o, köhnəlir - onu yeni buraxılışlarda conntrack əvəz edir.
Yəni, sonda sxem belə görünür:
Bir L2 şəbəkəsində bir hipervizorda iki maşın
Bu iki VM eyni L2 şəbəkəsində və eyni hipervizorda olduğundan, hər iki maşın eyni VLAN-da olacağından, aralarındakı trafikin yerli olaraq br-int vasitəsilə getməsi məntiqli olacaq:
[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 ~]$ Eyni L2 şəbəkəsində müxtəlif hipervizorlarda iki maşın
İndi eyni L2 şəbəkəsindəki, lakin fərqli hipervizorlarda yerləşən iki maşın arasında trafikin necə gedəcəyini görək. Düzünü desəm, heç nə çox dəyişməyəcək, sadəcə olaraq hipervizorlar arasında trafik vxlan tunelindən keçəcək. Bir nümunəyə baxaq.
Trafiki izləyəcəyimiz virtual maşınların ünvanları:
[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 ~]$ Hesablama-0-da br-int-də yönləndirmə cədvəlinə baxırıq:
[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 2-ci porta getməlidir - onun hansı port olduğuna baxın:
[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 ~]$Bu patch-tun - yəni br-tun-dakı interfeysdir. Gəlin br-tun-da paketlə nə baş verdiyinə baxaq:
[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 VxLAN-a yığılır və 2-ci porta göndərilir. Biz 2-ci portun hara apardığına baxırıq:
[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 ~]$Bu, hesablama-1-dəki vxlan tunelidir:
[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 ~]$Hesablama-1-ə gedirik və paketlə sonra nə baş verdiyini görürük:
[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 ~]$ Xaşxaş, hesablama-1-də br-int yönləndirmə cədvəlindədir və yuxarıdakı çıxışdan da göründüyü kimi, br-tun istiqamətində olan portlar olan 2-ci port vasitəsilə görünür:
[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:46Yaxşı, onda biz hesablama-1-də br-int-də xaşxaş təyinatının olduğuna baxırıq:
[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 ~]$ Yəni, alınan paket 3-cü porta uçacaq, bunun arxasında artıq virtual maşın nümunəsi-00000003 var.
Virtual infrastrukturda öyrənmək üçün Openstack tətbiqinin gözəlliyi ondadır ki, biz hipervizorlar arasında trafiki asanlıqla tuta və onunla nə baş verdiyini görə bilərik. İndi edəcəyimiz şey budur, vnet portunda tcpdump-u hesablama-0 istiqamətində işə salın:
[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*******************Birinci sətir göstərir ki, 10.0.1.85 ünvanından olan paket 10.0.1.88 ünvanına (ICMP trafiki) gedir və o, vni 22 ilə VxLAN paketinə bükülür və paket 192.168.255.19 (hesablama-0) hostundan hosta keçir. 192.168.255.26 (hesablama-1). VNI-nin ovs-də göstərilənə uyğun olduğunu yoxlaya bilərik.
Bu sətirə qayıdaq actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],çıxış:2. 0x16 onaltılıq say sistemində vni-dir. Bu ədədi 16-cu sistemə çevirək:
16 = 6*16^0+1*16^1 = 6+16 = 22Yəni vni doğrudur.
İkinci sətir əks trafiki göstərir, yaxşı, orada izah etməyin mənası yoxdur və buna görə də hər şey aydındır.
Müxtəlif şəbəkələrdə iki maşın (şəbəkələr arasında marşrutlaşdırma)
Bu gün üçün son hal virtual marşrutlaşdırıcıdan istifadə edərək eyni layihə daxilində şəbəkələr arasında marşrutlaşdırmadır. İşi DVR olmadan nəzərdən keçiririk (bunu başqa bir məqalədə nəzərdən keçirəcəyik), buna görə marşrutlaşdırma şəbəkə qovşağında baş verir. Bizim vəziyyətimizdə şəbəkə nodu ayrıca bir obyekt deyil və idarəetmə qovşağında yerləşir.
Əvvəlcə marşrutlaşdırmanın işlədiyini görək:
$ 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 msBu halda paket şlüzə getməli və oraya yönləndirilməli olduğundan, şlüzün xaşxaş ünvanını tapmalıyıq, bunun üçün misal olaraq ARP cədvəlinə baxacağıq:
$ 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 eth0İndi gəlin görək trafik təyinat (10.0.1.254) fa:16:3e:c4:64:70 ilə hara göndərilməlidir:
[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 ~]$ 2-ci portun hara apardığına baxırıq:
[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 ~]$ Hər şey məntiqlidir, trafik br-tuna gedir. Görək hansı vxlan tunelinə büküləcək:
[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 ~]$ Üçüncü liman vxlan tunelidir:
[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 ~]$ Nəzarət qovşağına baxan:
[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 idarəetmə qovşağına uçdu, ona görə də ona getməliyik və marşrutlaşdırmanın necə baş verəcəyini görməliyik.
Xatırladığınız kimi, içəridəki idarəetmə qovşağı hesablama qovşağı ilə tam olaraq eyni görünürdü - eyni üç körpü, yalnız br-ex-də qovşağın kənara trafik göndərə biləcəyi fiziki port var idi. Nümunələrin yaradılması hesablama qovşaqlarında konfiqurasiyanı dəyişdirdi - linux körpüsü, iptables və interfeyslər qovşaqlara əlavə edildi. Şəbəkələrin və virtual marşrutlaşdırıcının yaradılması da idarəetmə qovşağının konfiqurasiyasında öz izini buraxdı.
Belə ki, açıq-aydın, gateway xaşxaş ünvanı nəzarət node üzrə br-int yönləndirmə cədvəlində olmalıdır. Onun orada olduğunu və harada göründüyünü yoxlayaq:
[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 qr-0c52b15f-8f portundan görünür. Openstack-də virtual portların siyahısına qayıdaraq, bu port növü müxtəlif virtual cihazları OVS-yə qoşmaq üçün istifadə olunur. Daha dəqiq desək, qr ad məkanı kimi təqdim olunan virtual marşrutlaşdırıcıya doğru olan portdur.
Serverdə hansı ad sahəsinin olduğuna baxaq:
[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 ~]$ Üç nüsxə var. Ancaq adlara əsasən, onların hər birinin məqsədini təxmin edə bilərsiniz. Daha sonra ID 0 və 1 olan nümunələrə qayıdacağıq, indi qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ad sahəsi ilə maraqlanırıq:
[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 ~]$ Bu ad məkanında əvvəllər yaratdığımız iki daxili ad var. Hər iki virtual port br-int-ə əlavə olunur. MAC port ünvanını yoxlayaq qr-0c52b15f-8f, çünki təyinat MAC ünvanına görə trafik bu interfeysə keçdi.
[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 ~]$ Yəni, bu halda hər şey standart marşrutlaşdırma qanunlarına uyğun işləyir. Trafik 10.0.2.8 host üçün nəzərdə tutulduğundan o, ikinci qr-92fa49b5-54 interfeysindən çıxmalı və vxlan tunelindən hesablama qovşağına getməlidir:
[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 ~]$ Hər şey məntiqlidir, sürpriz yoxdur. Biz br-int-də host 10.0.2.8-in xaşxaş ünvanının göründüyü yerdən baxırıq:
[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 ~]$ Gözlənildiyi kimi, trafik br-tun istiqamətinə gedir, görək trafik daha sonra hansı tunelə gedəcək:
[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 hesablama-1 üçün tunelə daxil olur. Yaxşı, compute-1-də hər şey sadədir - br-tun-dan paket br-int-ə və oradan virtual maşının interfeysinə keçir:
[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 ~]$ Bunun həqiqətən düzgün interfeys olduğunu yoxlayaq:
[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 ~]$
Əslində, paketin bütün yolunu getdik. Düşünürəm ki, trafikin müxtəlif vxlan tunellərindən keçdiyini və fərqli VNI-lərlə çıxdığını fərq etdiniz. VNI-lərin nə olduğunu görək, bundan sonra qovşağın idarəetmə portunda bir zibil toplayacağıq və trafikin yuxarıda göstərildiyi kimi getdiyinə əmin olacağıq.
Beləliklə, hesablama-0 üçün tunel aşağıdakı hərəkətlərə malikdir=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],çıxış:3. 0x16-nı onluq say sisteminə çevirək:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Hesablama-1 üçün tunel aşağıdakı VNI-yə malikdir: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],çıxış:2. 0x63-ü onluq say sisteminə çevirək:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Yaxşı, indi zibilliyə baxaq:
[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*******************Birinci paket 192.168.255.19 (hesablama-0) hostundan vni 192.168.255.15 ilə 1 (nəzarət-22) host üçün vxlan paketidir, daxilində ICMP paketi 10.0.1.85 hostdan 10.0.2.8 host üçün qablaşdırılır. Yuxarıda hesabladığımız kimi, vni çıxışda gördüyümüzə uyğun gəlir.
İkinci paket 192.168.255.15 (nəzarət-1) hostundan vni 192.168.255.26 ilə 1 (hesablama-99) üçün vxlan paketidir, içərisində ICMP paketi 10.0.1.85 hostdan 10.0.2.8 host üçün qablaşdırılır. Yuxarıda hesabladığımız kimi, vni çıxışda gördüyümüzə uyğun gəlir.
Növbəti iki paket 10.0.2.8 deyil, 10.0.1.85-dən geri qayıdan trafikdir.
Yəni, sonda aşağıdakı nəzarət node sxemini əldə etdik:
Deyəsən, belədir? Biz iki ad sahəsini unutmuşuq:
[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 ~]$ Bulud platformasının arxitekturasından bəhs etdiyimiz kimi, maşınlar DHCP serverindən ünvanları avtomatik alsa, yaxşı olardı. Bu, 10.0.1.0/24 və 10.0.2.0/24 iki şəbəkəmiz üçün iki DHCP serveridir.
Bunun belə olduğunu yoxlayaq. Bu ad məkanında yalnız bir ünvan var - 10.0.1.1 - DHCP serverinin özünün ünvanı və o da br-int-ə daxildir:
[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 0Proseslərin idarəetmə qovşağında adlarında qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 olub olmadığını görək:
[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 ~]$ Belə bir proses var və yuxarıdakı çıxışda təqdim olunan məlumatlara əsaslanaraq, məsələn, hazırda kirayədə nəyə sahib olduğumuzu görə bilərik:
[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 ~]$Nəticədə idarəetmə qovşağında aşağıdakı xidmətlər dəstini alırıq:
Yaxşı, unutmayın - bu sadəcə - 4 maşın, 2 daxili şəbəkə və bir virtual marşrutlaşdırıcı ... İndi burada xarici şəbəkələrimiz yoxdur, hər birinin öz şəbəkələri (kəsişən) olan müxtəlif layihələrin yığınları və bizdə var. paylanmış bir marşrutlaşdırıcı söndürüldü, lakin sonda sınaq dəzgahında yalnız bir nəzarət qovşağı var idi (nöqsanlara dözümlülük üçün üç qovşaqdan ibarət kvorum olmalıdır). Ticarətdə hər şeyin "bir az" daha mürəkkəb olması məntiqlidir, lakin bu sadə nümunədə biz bunun necə işləməli olduğunu başa düşürük - 3 və ya 300 ad sahəsinin olub-olmaması, əlbəttə ki, vacibdir, lakin əməliyyat baxımından. bütün struktur, heç bir şey çox dəyişməyəcək ... baxmayaraq ki, hələlik bəzi satıcı SDN-ni bağlamırsınız. Amma bu tamam başqa hekayədir.
Ümid edirəm maraqlı oldu. Şərhlər / əlavələr varsa və ya bir yerdə açıq şəkildə yalan danışmışamsa (mən bir insanam və fikrim həmişə subyektiv olacaq) - nəyi düzəltmək / əlavə etmək lazım olduğunu yazın - hər şeyi düzəldəcəyik / əlavə edəcəyik.
Sonda, Openstack-i (həm vanil, həm də satıcı) VMWare-dən bulud həlli ilə müqayisə etmək haqqında bir neçə söz demək istərdim - son bir neçə il ərzində bu sualı mənə çox tez-tez verirlər və mən artıq düzünü desəm, bundan bezmişəm. , ancaq hələ də. Fikrimcə, bu iki həlli müqayisə etmək çox çətindir, amma qəti şəkildə deyə bilərik ki, hər iki həlldə çatışmazlıqlar var və bir həlli seçərkən müsbət və mənfi cəhətləri ölçmək lazımdır.
OpenStack icma tərəfindən idarə olunan bir həlldirsə, onda VMWare yalnız istədiyini etmək hüququna malikdir (oxu - onun üçün nə faydalıdır) və bu məntiqlidir - çünki o, müştərilərindən pul qazanmağa öyrəşmiş kommersiya şirkətidir. Ancaq bir böyük və yağlı AMMA var - siz OpenStack-dən, məsələn, Nokia-dan çıxa və məsələn, Juniper (Contrail Cloud) həllinə keçə bilərsiniz, lakin VMWare-dən çıxmağınız çətin olacaq. Mənə görə bu iki həll yolu belə görünür - Openstack (satıcı) sizi içəri salan sadə qəfəsdir, lakin açar sizdədir və istədiyiniz vaxt tərk edə bilərsiniz. VMWare qızıl qəfəsdir, qəfəsin açarı sahibinin yanındadır və bu sizə çox baha başa gələcək.
Mən nə birinci, nə də ikinci məhsul üçün kampaniya aparmıram - sizə lazım olanı seçirsiniz. Ancaq belə bir seçimim olsaydı, mən hər iki həlli seçərdim - İT bulud üçün VMWare (yüngül yüklər, rahat idarəetmə), bəzi satıcılardan OpenStack (Nokia və Juniper çox yaxşı açar təslim həllər təqdim edir) - Telecom bulud üçün. Mən Openstack-dən təmiz İT üçün istifadə etməzdim - bu, topdan sərçə atmağa bənzəyir, lakin ehtiyatdan başqa istifadə etmək üçün heç bir əks göstəriş görmürəm. Bununla belə, telekommunikasiyada VMWare-dən istifadə - Ford Raptor-da dağıntı daşımaq kimi - kənardan gözəldir, lakin sürücü bir yox, 10 səfər etməlidir.
Fikrimcə, VMWare-in ən böyük çatışmazlığı onun tam yaxınlığıdır - şirkət sizə onun necə işlədiyi, məsələn, vSAN və ya hipervizorun nüvəsində nə olduğu barədə heç bir məlumat verməyəcək - bu, sadəcə olaraq, onun üçün sərfəli deyil - yəni, siz heç vaxt VMWare-də ekspert olmayacaqsınız - satıcı dəstəyi olmadan, siz məhvə məhkumsunuz (çox tez-tez VMWare ekspertləri ilə rastlaşıram ki, onlar bayağı suallara cavab verirlər). Mənim üçün VMWare kapotu kilidli avtomobil alır - bəli, vaxt kəmərini dəyişə biləcək mütəxəssisləriniz ola bilər, ancaq kapotu yalnız sizə bu həlli satan şəxs aça biləcək. Şəxsən mən sığmadığım qərarları sevmirəm. Deyəcəksiniz ki, başlıq altına girmək lazım olmaya bilər. Bəli, bu mümkündür, amma buludda 20-30 virtual maşından, 40-50 şəbəkədən, yarısı çölə çıxmaq istəyən, digər yarısı isə SR istəyəndə böyük bir funksiya toplamaq lazım olduqda sizə baxacağam. -IOV sürətləndirilməsi, əks halda sizə daha bir neçə onlarla bu maşına ehtiyacınız olacaq - əks halda performans kifayət etməyəcək.
Başqa nöqteyi-nəzərlər də var, ona görə də nəyi seçəcəyinizə qərar vermək sizin ixtiyarınızdadır və ən əsası, seçiminizə görə məsuliyyət daşıyacaqsınız. Bu, sadəcə mənim fikrimdir - ən azı 4 məhsulu - Nokia, Juniper, Red Hat və VMWare-ni görüb əlinə toxunan adam. Beləliklə, müqayisə edəcəyim bir şey var.
Mənbə: www.habr.com