В Mən şəbəkə avtomatlaşdırma çərçivəsini təsvir etdim. Bəzi insanların fikrincə, problemə belə ilk yanaşma belə artıq bəzi sualları rəflərdə qoyub. Və bu məni çox sevindirir, çünki dövrədə məqsədimiz Python skriptləri ilə ansible ləkələmək deyil, sistem qurmaqdır.
Eyni çərçivə məsələ ilə məşğul olacağımız sıranı təyin edir.
Və bu məsələnin həsr olunduğu şəbəkə virtualizasiyası, avtomatlaşdırmanı təhlil etdiyimiz ADSM mövzusuna həqiqətən uyğun gəlmir.
Amma gəlin buna başqa tərəfdən baxaq.
Bir çox xidmətlər uzun müddət eyni şəbəkədən istifadə edir. Telekommunikasiya operatoru vəziyyətində bunlar, məsələn, 2G, 3G, LTE, genişzolaqlı və B2B-dir. DC vəziyyətində: müxtəlif müştərilər üçün əlaqə, İnternet, blok saxlama, obyekt saxlama.
Və bütün xidmətlər bir-birindən təcrid tələb edir. Overlay şəbəkələri belə ortaya çıxdı.
Və bütün xidmətlər bir insanın onları əl ilə konfiqurasiya etməsini gözləmək istəmir. Orkestrlər və SDN belə ortaya çıxdı.
Şəbəkənin, daha doğrusu onun bir hissəsinin sistematik avtomatlaşdırılmasına ilk yanaşma bir çox yerlərdə çoxdan qəbul edilmiş və tətbiq edilmişdir: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Gəlin bu gün ona nəzər salaq.
Məzmun
- səbəbləri
- Terminologiya
- Alt qat - fiziki şəbəkə
- Overlay - virtual şəbəkə
- ToR ilə üst-üstə düşmə
- Hostdan üst-üstə düşmə
- Volfram parça nümunəsində
- Tək fiziki maşın daxilində ünsiyyət
- Müxtəlif fiziki maşınlarda yerləşən VM-lər arasında əlaqə
- Xarici dünyaya çıxmaq
- FAQ
- Nəticə
- Faydalı linklər
səbəbləri
Bu barədə danışdığımız üçün şəbəkə virtualizasiyası üçün ilkin şərtləri qeyd etməyə dəyər. Əslində bu proses dünən başlamadı.
Yəqin ki, siz bir neçə dəfə eşitmisiniz ki, şəbəkə həmişə istənilən sistemin ən inert hissəsi olub. Və bu hər mənada doğrudur. Şəbəkə hər şeyin arxalandığı əsasdır və ona dəyişiklik etmək olduqca çətindir - xidmətlər şəbəkənin dayandığı zaman dözmür. Çox vaxt tək bir qovşağın istismardan çıxarılması əksər tətbiqlərə əlavə oluna bilər və bir çox müştəriyə təsir edə bilər. Şəbəkə komandasının istənilən dəyişikliyə müqavimət göstərə bilməsinin qismən səbəbi budur - çünki indi bir şəkildə işləyir (necə olduğunu heç bilmirik) və burada yeni bir şey konfiqurasiya etməlisiniz və bunun şəbəkəyə necə təsir edəcəyi məlum deyil.
Şəbəkəçilərin VLAN-ları atmasını gözləməmək və hər bir şəbəkə qovşağında heç bir xidməti qeydiyyatdan keçirməmək üçün insanlar üst-üstə düşmələrdən - üst-üstə düşən şəbəkələrdən - istifadə etmək ideyası ilə gündəmə gəldilər: GRE, IPinIP, MPLS, MPLS L2 / L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE və s.
Onların cazibəsi iki sadə şeydədir:
- Yalnız son qovşaqlar konfiqurasiya edilir - tranzit qovşaqlarına toxunmaq lazım deyil. Bu, prosesi xeyli sürətləndirir və bəzən hətta şəbəkə infrastrukturu departamentini yeni xidmətlərin tətbiqi prosesindən kənarlaşdırmağa imkan verir.
- Yük başlıqların dərinliklərində gizlənir - tranzit qovşaqlarının bu barədə, hostlarda ünvanlama, overlay şəbəkəsinin marşrutları haqqında heç nə bilməsi lazım deyil. Və bu o deməkdir ki, cədvəllərdə daha az məlumat saxlamaq lazımdır, yəni daha sadə / daha ucuz bir cihaz götürmək deməkdir.
Bu kifayət qədər tam olmayan məsələdə mən bütün mümkün texnologiyaları təhlil etməyi planlaşdırmıram, əksinə DC-lərdə üst-üstə düşən şəbəkələrin işləməsi üçün çərçivəni təsvir edirəm.
Bütün seriya eyni server avadanlığının quraşdırıldığı eyni tipli rafların sıralarından ibarət məlumat mərkəzini təsvir edəcəkdir.
Bu avadanlıq xidmətləri həyata keçirən virtual maşınlar/konteynerlər/serversiz işləyir.
Terminologiya
Bir dövrədə server Müştəri-server əlaqəsinin server tərəfini həyata keçirən proqrama istinad edəcəyəm.
Raf serverlərində fiziki maşınlara zəng edin heç bir Biz edəcəyik.
fiziki maşın - x86 kompüteri rafda quraşdırılmışdır. Termini ən çox istifadə edirik ev sahibi. Buna görə də deyək"avtomobil"Ya da ev sahibi.
hipervizor — Virtual Maşınların işlədiyi fiziki resursları təqlid edən fiziki maşında işləyən proqram. Bəzən ədəbiyyatda və internetdə “hipervisor” sözü “host”un sinonimi kimi istifadə olunur.
Virtual maşın - hipervizorun üstündə fiziki maşında işləyən əməliyyat sistemi. Bu dövrədə bizim üçün onun əslində virtual maşın və ya sadəcə konteyner olması o qədər də vacib deyil. deyək"VM«
kirayəçi - bu məqalədə ayrıca bir xidmət və ya ayrıca müştəri kimi müəyyən edəcəyəm geniş bir anlayış.
Çox kirayəlik və ya çox kirayəlik - fərqli müştərilər / xidmətlər tərəfindən eyni proqramdan istifadə. Eyni zamanda, müştərilərin bir-birindən təcrid olunmasına ayrı-ayrılıqda işə salınmış nümunələr deyil, tətbiqin arxitekturası sayəsində nail olunur.
ToR - Rafın üstü açarı - bütün fiziki maşınların qoşulduğu rəfdə quraşdırılmış açar.
ToR topologiyasına əlavə olaraq, müxtəlif provayderlər Sıranın Sonu (EoR) və ya Sıranın Ortasını tətbiq edirlər (baxmayaraq ki, sonuncu aşağılayıcı nadir haldır və mən MoR abbreviaturalarını görməmişəm).
alt şəbəkə və ya əsas şəbəkə və ya alt qat - fiziki şəbəkə infrastrukturu: açarlar, marşrutlaşdırıcılar, kabellər.
üst-üstə düşən şəbəkə və ya overlay şəbəkə və ya overlay - fiziki birinin üstündə işləyən virtual tunel şəbəkəsi.
L3 fabriki və ya IP fabriki STP-ni təkrarlamamağa və müsahibələr üçün TRILL öyrənməməyə imkan verən bəşəriyyətin heyrətamiz ixtirasıdır. Giriş səviyyəsinə qədər bütün şəbəkənin VLAN-lar və müvafiq olaraq nəhəng uzanan yayım domenləri olmadan yalnız L3 olduğu bir konsepsiya. "Zavod" sözünün haradan gəldiyini növbəti hissədə anlayacağıq.
SDN — Proqram təminatı ilə müəyyən edilmiş şəbəkə. Təqdimata ehtiyac yoxdur. Şəbəkəyə dəyişikliklər şəxs tərəfindən deyil, proqram tərəfindən həyata keçirildikdə şəbəkənin idarə edilməsinə yanaşma. Adətən Nəzarət Təyyarəsini son şəbəkə cihazlarından kənara nəzarətçiyə köçürmək deməkdir.
NFV - Şəbəkə Funksiyasının Virtuallaşdırılması - şəbəkə funksiyalarının bir hissəsinin yeni xidmətlərin tətbiqini sürətləndirmək, Xidmət Zəncirləməsinin təşkilini və daha asan üfüqi genişlənməni sürətləndirmək üçün virtual maşınlar və ya konteynerlər kimi idarə oluna biləcəyini nəzərə alaraq, şəbəkə cihazlarının virtuallaşdırılması.
VNF — Virtual şəbəkə funksiyası. Xüsusi virtual cihaz: marşrutlaşdırıcı, keçid, firewall, NAT, IPS/IDS və s.
Oxucunu çox çaşdırmamaq üçün indi təsviri qəsdən konkret bir tətbiqə qədər sadələşdirirəm. Daha düşüncəli oxumaq üçün onu bölməyə istinad edirəm . Bundan əlavə, bu məqaləni qeyri-dəqiqliklərə görə tənqid edən Roma Gorge, server və şəbəkənin virtualizasiya texnologiyaları haqqında ayrıca, daha dərindən və detallara diqqətli şəkildə yazmağı vəd edir.
Bu gün əksər şəbəkələr açıq şəkildə iki hissəyə bölünə bilər:
Alt — sabit konfiqurasiyaya malik fiziki şəbəkə.
Yerleşimi - Kirayəçiləri təcrid etmək üçün alt qat üzərində abstraksiya.
Bu, həm DC işi (bu məqalədə təhlil edəcəyik), həm də ISP (təhlil etməyəcəyik, çünki o, artıq mövcud idi) üçün doğrudur. ). Müəssisə şəbəkələri ilə, əlbəttə ki, vəziyyət bir qədər fərqlidir.
Şəbəkə fokus şəkli:
Alt
Underlay fiziki şəbəkədir: aparat açarları və kabellər. Alt təbəqədəki cihazlar fiziki maşınlara necə çatmağı bilir.
Standart protokollara və texnologiyalara əsaslanır. Ən azı ona görə ki, bu günə qədər aparat cihazları nə çip proqramlaşdırmasına, nə də onların protokollarının həyata keçirilməsinə imkan verməyən xüsusi proqram təminatı üzərində işləyir, müvafiq olaraq digər təchizatçılarla uyğunluq və standartlaşdırma tələb olunur.
Lakin Google kimi kimsə öz açarlarını inkişaf etdirə və adi protokollardan imtina edə bilər. Lakin LAN_DC Google deyil.
Alt təbəqə nisbətən nadir hallarda dəyişir, çünki onun məqsədi fiziki maşınlar arasında əsas IP bağlantısıdır. Underlay onun üzərində işləyən xidmətlər, müştərilər, kirayəçilər haqqında heç nə bilmir - yalnız paketi bir maşından digərinə çatdırmaq lazımdır.
Alt örtük belə ola bilər:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Underlay şəbəkəsi klassik şəkildə konfiqurasiya edilmişdir: CLI/GUI/NETCONF.
Əl ilə, skriptlər, mülkiyyət proqramları.
Silsilənin növbəti məqaləsi daha ətraflı şəkildə Anderliyə həsr olunacaq.
Yerleşimi
Overlay, Underlay üzərində uzanan virtual tunellər şəbəkəsidir, bir müştərinin VM-lərinə digər müştərilərdən təcrid etməklə yanaşı, bir-biri ilə əlaqə saxlamağa imkan verir.
Müştəri məlumatları ictimai şəbəkə üzərindən ötürülmək üçün bir növ tunel başlığına daxil edilmişdir.
Beləliklə, bir müştərinin (bir xidmət) VM-ləri paketin əslində hansı yolu tutduğunu bilmədən də Overlay vasitəsilə bir-biri ilə əlaqə saxlaya bilər.
Məsələn, yuxarıda qeyd etdiyim kimi, örtük belə ola bilər:
- GRE tuneli
- VXLAN
- EVPN
- L3VPN
- GENVE
Overlay şəbəkəsi adətən mərkəzi nəzarətçi vasitəsilə konfiqurasiya edilir və saxlanılır. Ondan konfiqurasiya, İdarəetmə Təyyarəsi və Məlumat Təyyarəsi müştəri trafikinin yönləndirilməsi və əhatə olunması ilə məşğul olan cihazlara çatdırılır. bir az Buna misallarla baxaq.
Bəli, bu təmiz SDN-dir.
Overlay şəbəkəsini təşkil etmək üçün iki əsas fərqli yanaşma var:
- ToR ilə üst-üstə düşmə
- Hostdan üst-üstə düşmə
ToR ilə üst-üstə düşmə
Bindirmə, məsələn, VXLAN parçasında olduğu kimi, rafdakı giriş açarında (ToR) başlaya bilər.
Bu, ISP şəbəkələrində zamanla sınaqdan keçirilmiş mexanizmdir və şəbəkə avadanlıqlarının bütün təchizatçıları bunu dəstəkləyir.
Bununla belə, bu halda ToR keçidi müvafiq olaraq müxtəlif xidmətləri ayıra bilməli və şəbəkə inzibatçısı müəyyən dərəcədə virtual maşın administratorları ilə əməkdaşlıq etməli və cihazın konfiqurasiyasına dəyişikliklər (avtomatik də olsa) etməlidir.
Burada oxucunu haqqında bir məqaləyə istinad edəcəyəm köhnə dostumuz .
Bu EVPN VXLAN fabriki ilə DC şəbəkəsinin qurulmasına yanaşmalar ətraflı təsvir edilmişdir.
Və reallığa daha tam batırmaq üçün tsiskanın kitabını oxuya bilərsiniz .
Qeyd edim ki, VXLAN yalnız bir inkapsulyasiya üsuludur və tunelin dayandırılması, məsələn, OpenStack vəziyyətində olduğu kimi ToR-də deyil, hostda baş verə bilər.
Bununla belə, üst-üstə düşmənin ToR-də başladığı VXLAN fabriki yaxşı qurulmuş üst-üstə düşən şəbəkə dizaynlarından biridir.
Hostdan üst-üstə düşmə
Başqa bir yanaşma, son hostlarda tunelləri işə salmaq və bitirməkdir.
Bu halda, şəbəkə (Underlay) mümkün qədər sadə və statik olaraq qalır.
Və ev sahibi özü bütün lazımi encapsulation edir.
Bunu etmək üçün, əlbəttə ki, hostlarda xüsusi proqram işlətməli olacaqsınız, lakin buna dəyər.
Birincisi, müştərini linux maşınında idarə etmək daha asandır və ya deyək ki, hətta mümkündür, keçiddə olarkən, çox güman ki, indiyə qədər mülkiyyətçi SDN həllərinə müraciət etməli olacaqsınız ki, bu da multi -satıcı.
İkincisi, bu vəziyyətdə ToR açarı həm İdarəetmə Təyyarəsi, həm də Məlumat Təyyarəsi baxımından mümkün qədər sadə buraxıla bilər. Həqiqətən, o zaman SDN nəzarətçisi ilə əlaqə saxlamağa ehtiyac yoxdur və bütün qoşulmuş müştərilərin şəbəkələrini / ARP-lərini saxlamaq kifayətdir - kommutasiya / marşrutlaşdırmanı çox asanlaşdıran fiziki maşının IP ünvanını bilmək kifayətdir. masalar.
ADSM seriyasında mən hostdan üst-üstə düşmə yanaşmasını seçirəm - onda biz yalnız bu barədə danışacağıq və VXLAN fabrikinə qayıtmayacağıq.
Nümunələrə baxmaq ən asandır. Və test mövzusu olaraq, indi olaraq bilinən OpenSource SDN platforması OpenContrail-i götürəcəyik .
Məqalənin sonunda OpenFlow və OpenvSwitch ilə bənzətmə haqqında bəzi fikirlər verəcəyəm.
Volfram parça nümunəsində
Hər bir fiziki maşın var vRouter - ona qoşulmuş şəbəkələr və hansı müştərilərə aid olduqlarını bilən virtual marşrutlaşdırıcı - əslində - PE marşrutlaşdırıcısı. Hər bir müştəri üçün o, təcrid olunmuş marşrut cədvəlini saxlayır (VRF oxuyun). Və əslində vRouter Overlay tunel edir.
vRouter haqqında bir az daha çox məlumat məqalənin sonundadır.
Hipervizorda yerləşən hər bir VM həmin maşının vRouter-inə vasitəsilə qoşulur .
TAP - Terminal Giriş Nöqtəsi - linux nüvəsində şəbəkə qarşılıqlı əlaqəsinə imkan verən virtual interfeys.
vRouter-in arxasında bir neçə şəbəkə varsa, onların hər biri üçün bir IP ünvanı təyin edilmiş virtual interfeys yaradılır - bu, standart şlüz ünvanı olacaqdır.
Bir müştərinin bütün şəbəkələri bir yerdə yerləşdirilir VRF (bir masa), fərqli - fərqli.
Burada hər şeyin o qədər də sadə olmadığını qeyd edəcəyəm və maraqlanan oxucunu məqalənin sonuna göndərəcəyəm..
vRouter-lərin bir-biri ilə və müvafiq olaraq onların arxasındakı VM-lərlə əlaqə saxlaması üçün onlar marşrutlaşdırma məlumatlarını mübadilə edir. SDN nəzarətçi.
Xarici dünyaya çıxmaq üçün matrisdən çıxış nöqtəsi var - virtual şəbəkə şlüzü VNGW — Virtual Şəbəkə Gateway (mənim müddətim).
İndi ünsiyyət nümunələrinə baxaq - və aydınlıq olacaq.
Tək fiziki maşın daxilində ünsiyyət
VM0 VM2-yə paket göndərmək istəyir. Hələlik bunun tək müştəri VM olduğunu fərz edək.
Məlumat təyyarəsi
- VM-0-ın eth0 interfeysinə standart marşrutu var. Paket oraya göndərilir.
Bu eth0 interfeysi faktiki olaraq tap0 TAP interfeysi vasitəsilə virtual olaraq vRouter virtual marşrutlaşdırıcısına qoşulub. - vRouter paketin hansı interfeysdə gəldiyini, yəni hansı müştəriyə (VRF) aid olduğunu təhlil edir, bu müştərinin marşrut cədvəli ilə alıcının ünvanını yoxlayır.
- Alıcının fərqli portun arxasında eyni maşında olduğunu aşkar edərək, vRouter sadəcə paketi heç bir əlavə başlıq olmadan ona göndərir - bu halda vRouter artıq ARP girişinə malikdir.
Bu vəziyyətdə paket fiziki şəbəkəyə daxil deyil - vRouter daxilində yönləndirilir.
Nəzarət Planı
Virtual maşın işə salındıqda, hipervizor ona deyir:
- Öz IP ünvanı.
- Defolt marşrut vRouter-in bu şəbəkədəki IP ünvanıdır.
Hipervizor xüsusi API vasitəsilə vRouter-a hesabat verir:
- Virtual interfeys yaratmaq üçün nə lazımdır.
- Virtual şəbəkə yaratmaq üçün (VM) nə lazımdır.
- Hansı VRF-yə (VN) bağlanmalıdır.
- Bu VM üçün statik ARP girişi - onun IP ünvanı hansı interfeysdə yerləşir və hansı MAC ünvanına bağlıdır.
Və yenə də faktiki qarşılıqlı əlaqə proseduru konsepsiyanı başa düşmək üçün sadələşdirilmişdir.
Beləliklə, vRouter bu maşında bir müştərinin bütün VM-lərini birbaşa əlaqəli şəbəkələr kimi görür və özlərini onlar arasında marşrutlaşdıra bilir.
Lakin VM0 və VM1 müvafiq olaraq müxtəlif müştərilərə aiddir, müxtəlif vRouter cədvəllərindədir.
Onların bir-biri ilə birbaşa əlaqə qura bilməsi vRouter parametrlərindən və şəbəkə dizaynından asılıdır.
Məsələn, hər iki müştərinin VM-ləri ictimai ünvanlardan istifadə edirsə və ya NAT vRouter-in özündə baş verirsə, o zaman vRouter-ə birbaşa marşrutlaşdırma da edilə bilər.
Əks vəziyyətdə, ünvan boşluqlarının kəsişməsi mümkündür - ümumi ünvan əldə etmək üçün NAT serverindən keçmək lazımdır - bu, aşağıda müzakirə olunan xarici şəbəkələrə daxil olmağa bənzəyir.
Müxtəlif fiziki maşınlarda yerləşən VM-lər arasında əlaqə
Məlumat təyyarəsi
- Başlanğıc tam olaraq eynidir: VM-0 standart olaraq VM-7 (172.17.3.2) paketini göndərir.
- vRouter onu qəbul edir və bu dəfə təyinat yerinin başqa maşında olduğunu və Tunnel0 tuneli vasitəsilə əldə edilə biləcəyini görür.
- Birincisi, o, uzaqdan interfeysi müəyyən edən MPLS etiketini bağlayır ki, əks tərəfdə vRouter bu paketin hara qoyulacağını və əlavə axtarışlar olmadan müəyyən edə bilsin.
- Tunel0 mənbə 10.0.0.2, təyinat 10.0.1.2-yə malikdir.
vRouter orijinal paketə GRE (və ya UDP) başlıqlarını və yeni IP-ni əlavə edir. - vRouter marşrutlaşdırma cədvəlində ToR1 ünvanı 10.0.0.1 vasitəsilə defolt marşrut var. Oraya göndərir.
- ToR1, Underlay şəbəkəsinin üzvü kimi (məsələn, OSPF vasitəsilə) 10.0.1.2-yə necə çatmağı bilir və paketi marşrut boyunca göndərir. Qeyd edək ki, ECMP burada aktivdir. Təsvirdə iki növbəti hop var və müxtəlif axınlar hash vasitəsilə onlara parçalanacaq. Həqiqi bir fabrik vəziyyətində, daha çox 4 növbəti atlama olacaq.
Eyni zamanda, onun xarici IP başlığının altında nə olduğunu bilməsi lazım deyil. Yəni, əslində, IP altında IPv6-dan MPLS üzərindən Ethernet üzərindən MPLS üzərindən GRE üzərindən Yunanıstan üzərindən bir sendviç ola bilər.
- Müvafiq olaraq, qəbul edən tərəfdə vRouter GRE-ni silir və MPLS etiketindən istifadə edərək bu paketin hansı interfeysə göndərilməli olduğunu anlayır, onu ayırır və orijinal formada alıcıya göndərir.
Nəzarət Planı
Maşını işə saldığınız zaman hər şey yuxarıda göstərildiyi kimi baş verir.
Və əlavə olaraq aşağıdakılar:
- Hər bir müştəri üçün vRouter MPLS etiketi ayırır. Bu, müştərilərin eyni fiziki maşında ayrılacağı L3VPN xidmət etiketidir.
Əslində, MPLS etiketi həmişə vRouter tərəfindən ayrılır, çünki maşının yalnız eyni vRouter arxasındakı digər maşınlarla qarşılıqlı əlaqədə olacağı əvvəlcədən məlum deyil və bu, çox güman ki, belə deyil.
- vRouter BGP protokolu (və ya oxşar - TF halda, bu XMPP 0_o) vasitəsilə SDN nəzarətçisi ilə əlaqə qurur.
- Bu seans vasitəsilə vRouter SDN nəzarətçisinə qoşulmuş şəbəkələrə marşrutları bildirir:
- Şəbəkə ünvanı
- Enkapsulyasiya üsulu (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS müştəri etiketi
- Nexthop kimi IP ünvanınız
- SDN nəzarətçisi bütün qoşulmuş vRouterlərdən belə marşrutları alır və onları başqalarına əks etdirir. Yəni Marşrut Reflektoru kimi fəaliyyət göstərir.
Eyni şey tərsinə baş verir.
Overlay ən azı hər dəqiqə dəyişə bilər. Bu, müştərilər mütəmadi olaraq virtual maşınlarını işə saldıqda və bağladıqda ictimai buludlarda baş verənlərə bənzəyir.
Mərkəzi nəzarətçi vRouter-də kommutasiya/marşrutlaşdırma cədvəllərinin konfiqurasiyası və nəzarətinin saxlanmasının bütün mürəkkəbliyi ilə məşğul olur.
Təxminən desək, nəzarətçi özünü BGP (və ya oxşar protokol) vasitəsilə bütün vRouters ilə bağlayır və sadəcə marşrut məlumatlarını ötürür. Məsələn, BGP-də kapsullaşdırma metodunu daşımaq üçün artıq Ünvan-Ailəsi var və ya .
Eyni zamanda, Underlay şəbəkəsinin konfiqurasiyası heç bir şəkildə dəyişmir, yeri gəlmişkən, avtomatlaşdırılması daha çətin olan və yöndəmsiz bir hərəkətlə qırılması daha asan olan böyüklük sırasıdır.
Xarici dünyaya çıxmaq
Haradasa simulyasiya bitməlidir və siz virtual aləmdən real dünyaya çıxmalısınız. Və sizə taksofon şlüz lazımdır.
İki yanaşma tətbiq olunur:
- Aparat yönləndiricisi quraşdırılıb.
- Routerin funksiyalarını həyata keçirən hər hansı bir cihaz işə salınır (bəli, SDN-dən sonra biz də VNF ilə qarşılaşdıq). Gəlin onu virtual şlüz adlandıraq.
Ucuz üfüqi miqyasda ikinci yanaşmanın üstünlüyü - kifayət qədər güc yoxdur - biz şlüz ilə başqa bir virtual maşını işə saldıq. İstənilən fiziki maşında, pulsuz rəflər, aqreqatlar, elektrik rozetkaları axtarmadan, dəmir parçasının özü alın, daşıyın, quraşdırın, dəyişdirin, konfiqurasiya edin və sonra da nasaz komponentləri dəyişdirin.
Virtual şlüzün çatışmazlıqları ondan ibarətdir ki, fiziki marşrutlaşdırıcının vahidi hələ də çoxnüvəli virtual maşından daha güclüdür və onun öz aparat bazasına uyğunlaşdırılmış proqram təminatı daha stabil işləyir (нет). Proqram və aparat kompleksinin sadəcə konfiqurasiya tələb etməklə işlədiyini, virtual şlüzün işə salınması və saxlanmasının güclü mühəndislər üçün məşğuliyyət olduğunu inkar etmək də çətindir.
Bir ayağı ilə şluz adi Virtual Maşın kimi Overlay virtual şəbəkəsinə baxır və bütün digər VM-lərlə qarşılıqlı əlaqədə ola bilər. Eyni zamanda, bütün müştərilərin şəbəkələrini öz üzərində dayandıra və müvafiq olaraq, onlar arasında marşrutlaşdırma həyata keçirə bilər.
Digər ayağı ilə şlüz artıq magistral şəbəkəyə baxır və İnternetə necə çıxacağını bilir.
Məlumat təyyarəsi
Beləliklə, proses belə görünür:
- Eyni vRouter-də defolt olan VM-0, eth185.147.83.177 interfeysinə xarici aləmdə təyinatı olan paketi (0) göndərir.
- vRouter bu paketi qəbul edir və marşrutlaşdırma cədvəlində təyinat ünvanını axtarır - Tunel 1 vasitəsilə VNGW1 şlüzü vasitəsilə defolt marşrutu tapır.
O, həmçinin bunun SIP 10.0.0.2 və DIP 10.0.255.2 ilə GRE tuneli olduğunu görür və o, həmçinin VNGW1-in gözlədiyi bu müştəri üçün əvvəlcə MPLS etiketini asmalıdır. - vRouter ilkin paketi MPLS, GRE başlıqları və yeni IP-də paketləyir və onu standart olaraq ToR1 10.0.0.1 ünvanına göndərir.
- Əsas şəbəkə paketi VNGW1 şlüzinə çatdırır.
- VNGW1 şlüzü GRE və MPLS tunel başlıqlarını silir, təyinat ünvanını görür, onun marşrut cədvəlinə baxır və onun İnternetə yönəldildiyini başa düşür, yəni Tam Görünüş və ya Defolt vasitəsilə. Lazım gələrsə, NAT tərcüməsini həyata keçirir.
- VNGW-dən sərhədə qədər adi bir IP şəbəkəsi ola bilər, bu çətin deyil.
Bu klassik MPLS şəbəkəsi (IGP + LDP / RSVP TE) ola bilər, BGP LU ilə arxa zavod və ya VNGW-dən IP şəbəkəsi vasitəsilə sərhədə qədər GRE tuneli ola bilər.
Nə olursa olsun, VNGW1 lazımi inkapsulyasiyaları yerinə yetirir və ilkin paketi sərhədə göndərir.
Əks istiqamətdə hərəkət əks ardıcıllıqla eyni addımlardan keçir.
- Sərhəd paketi VNGW1-ə endirir
- Onu soyundurur, alıcının ünvanına baxır və onun Tunnel1 tuneli (MPLSoGRE və ya MPLSoUDP) vasitəsilə əlçatan olduğunu görür.
- Müvafiq olaraq, o, MPLS etiketini, GRE / UDP başlığını və yeni IP-ni bağlayır və onu ToR3 10.0.255.1-ə göndərir.
Tunelin təyinat ünvanı vRouter-in IP ünvanı və ardınca hədəf VM - 10.0.0.2-dir. - Alt qat şəbəkəsi paketi istədiyiniz vRouter-ə çatdırır.
- Hədəf vRouter GRE / UDP-ni silir, MPLS etiketindən istifadə edərək interfeysi müəyyənləşdirir və eth0 VM ilə əlaqəli TAP interfeysinə çılpaq IP paketini göndərir.
Nəzarət Planı
VNGW1, SDN nəzarətçisi ilə BGP məhəlləsi yaradır və buradan müştərilər haqqında bütün marşrutlaşdırma məlumatlarını alır: hansı müştəri hansı IP ünvanı (vRouter) arxasındadır və hansı MPLS etiketi ilə müəyyən edilir.
Eynilə, özü də bu müştərinin etiketi ilə standart marşrutu SDN nəzarətçisinə bildirir və özünü nexthop kimi göstərir. Və sonra bu standart vRouters-a gəlir.
VNGW-də adətən marşrutun yığılması və ya NAT tərcüməsi baş verir.
Və digər istiqamətdə, sərhədlər və ya Marşrut Reflektorları ilə bir seansda, tam olaraq bu cəmlənmiş marşrutu verir. Və onlardan standart marşrut və ya Tam Görünüş və ya başqa bir şey alır.
İnkapsulyasiya və trafik mübadiləsi baxımından VNGW vRouter-dən heç bir fərqi yoxdur.
Əgər əhatə dairəsini bir az genişləndirsəniz, o zaman VNGW-lərə və vRouter-lərə digər şəbəkə cihazları əlavə edilə bilər, məsələn, firewalllar, trafikin təmizlənməsi və ya zənginləşdirmə fermaları, IPS və s.
Ardıcıl VRF-lərin yaradılması və marşrutların düzgün elan edilməsinin köməyi ilə siz xidmət zəncirləmə adlanan trafik dövrəsini istədiyiniz şəkildə edə bilərsiniz.
Yəni burada SDN nəzarətçi VNGW, vRouters və digər şəbəkə cihazları arasında Route-Reflector rolunu oynayır.
Amma əslində, nəzarətçi ACL və PBR (Siyasətə əsaslanan marşrutlaşdırma) haqqında daha çox məlumat buraxaraq, fərdi trafik axınlarını marşrutun onlara bildirdiyindən fərqli getməyə məcbur edir.
FAQ
Niyə həmişə GRE / UDP qeyd edirsiniz?
Yaxşı, ümumiyyətlə, bunun Volfram Parçasına xas olduğunu söyləmək olar - bunu heç nəzərə ala bilməzsiniz.
Ancaq onu götürsəniz, TF-nin özü hələ də OpenContrail olmasına baxmayaraq, hər iki enkapsulyasiyanı dəstəklədi: GRE-də MPLS və UDP-də MPLS.
UDP yaxşıdır, çünki başlıqdakı Mənbə Portunda balanslaşdırmağa imkan verəcək orijinal IP + Proto + Port-dan hash funksiyasını kodlaşdırmaq çox asandır.
GRE vəziyyətində, təəssüf ki, bütün əhatə olunmuş trafik üçün eyni olan yalnız xarici IP və GRE başlıqları var və balanslaşdırmadan söhbət gedə bilməz - az adam paketə bu qədər dərindən baxa bilər.
Bir müddətə qədər marşrutlaşdırıcılar tunelləri necə dinamikləşdirməyi bilirdilərsə, onda yalnız MPLSoGRE-də və yalnız bu yaxınlarda MPLSoUDP-də öyrəndilər. Buna görə də, siz həmişə iki fərqli kapsulyasiyanın mümkünlüyü barədə qeyd etməlisiniz.
Ədalət naminə qeyd etmək lazımdır ki, TF VXLAN-dan istifadə edərək L2 bağlantısını tam dəstəkləyir.
Siz OpenFlow ilə paralellər aparacağınıza söz vermişdiniz.
Həqiqətən soruşurlar. Eyni OpenStack-dəki vSwitch, yeri gəlmişkən, UDP başlığına sahib olan VXLAN-dan istifadə edərək çox oxşar işlər görür.
Məlumat Planında onlar təxminən eyni işləyirlər, İdarəetmə Təyyarəsi əhəmiyyətli dərəcədə fərqlənir. Tungsten Fabric OpenStack-də Openflow işləyərkən marşrut məlumatlarını vRouter-a çatdırmaq üçün XMPP-dən istifadə edir.
vRouter haqqında bir az ətraflı məlumat verə bilərsinizmi?
O, iki hissəyə bölünür: vRouter Agent və vRouter Forwarder.
Birincisi host ƏS-nin İstifadəçi Məkanında işləyir və marşrutlar, VRF-lər və ACL-lər haqqında məlumat mübadiləsi edərək SDN nəzarətçisi ilə əlaqə saxlayır.
İkincisi Data Plane tətbiq edir - adətən Kernel Space-də, lakin SmartNIC-lərdə də işləyə bilər - CPU və ayrıca proqramlaşdırıla bilən kommutasiya çipi olan şəbəkə kartları, bu da host maşının CPU-dan yükü götürməyə və şəbəkəni daha sürətli etməyə imkan verir. və daha çox proqnozlaşdırıla bilən.
Başqa bir ssenari vRouter İstifadəçi Məkanında DPDK tətbiqi olduqda mümkündür.
vRouter Agent vRouter Forwarder-də parametrləri aşağı çəkir.
Virtual şəbəkə nədir?
VRF haqqında yazının əvvəlində qeyd etdim ki, deyirlər ki, hər kirayəçi öz VRF-yə bağlıdır. Və əgər bu, üst-üstə düşən şəbəkənin işini səthi başa düşmək üçün kifayət idisə, növbəti iterasiyada dəqiqləşdirmələr aparmaq lazımdır.
Adətən, virtuallaşdırma mexanizmlərində Virtual Şəbəkənin mahiyyəti (bunu uyğun bir ad hesab edə bilərsiniz) müştərilərdən / kirayəçilərdən / virtual maşınlardan ayrıca təqdim olunur - tamamilə müstəqil bir şey. Və bu Virtual Şəbəkə artıq interfeyslər vasitəsilə bir kirayəçiyə, digərinə, ikiyə, lakin heç olmasa harada bağlana bilər. Beləliklə, məsələn, Xidmət Zəncirləməsi trafikin müəyyən qovşaqlardan düzgün ardıcıllıqla keçməsi lazım olduqda həyata keçirilir, sadəcə olaraq düzgün ardıcıllıqla Virtual Şəbəkələr yaratmaq və qəbul etmək lazımdır.
Buna görə də, Virtual Şəbəkə ilə kirayəçi arasında birbaşa yazışma yoxdur.
Nəticə
Bu, ev sahibi və SDN nəzarətçisinin üst-üstə düşməsi ilə virtual şəbəkənin işinin çox səthi təsviridir. Ancaq bu gün hansı virtuallaşdırma platformasını seçsəniz, o, VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric və ya Juniper Contrail kimi oxşar şəkildə işləyəcək. Onlar kapsulların və başlıqların növləri, son şəbəkə cihazlarına məlumatın çatdırılması üçün protokollar ilə fərqlənəcəklər, lakin nisbətən sadə və statik altlıq şəbəkəsi üzərində işləyən proqram təminatı ilə konfiqurasiya edilə bilən üst-üstə düşən şəbəkənin prinsipi eyni qalacaq.
Deyə bilərik ki, bu gün xüsusi bulud yaratmaq sahəsində, bir overlay şəbəkəsinə əsaslanan SDN qalib gəldi. Ancaq bu, Openflow-un müasir dünyada yeri olmadığı anlamına gəlmir - o, OpenStacke-də və eyni VMWare NSX-də istifadə olunur, bildiyimə görə, Google onu alt şəbəkə qurmaq üçün istifadə edir.
Məsələni daha dərindən öyrənmək istəyirsinizsə, aşağıda daha ətraflı materiallara keçidlər vermişəm.
Bəs bizim Underlay haqqında nə demək olar?
Amma ümumiyyətlə, heç nə. O, tamamilə dəyişmədi. Ev sahibinin üst-üstə düşməsi halında etməli olduğu şey, marşrutları və ARP-ləri vRouter / VNGW göründükdə və yox olduqdan sonra yeniləmək və paketləri onların arasında sürükləməkdir.
Underlay şəbəkəsi üçün tələblərin siyahısını tərtib edək.
- Bir növ marşrutlaşdırma protokolundan istifadə edə bilmək üçün bizim vəziyyətimizdə - BGP.
- Paketlərin tıxac səbəbindən itirilməməsi üçün geniş bir banda sahib olun, tercihen həddindən artıq abunə olmadan.
- ECMP-nin dəstəklənməsi fabrikin ayrılmaz hissəsidir.
- ECN kimi çətin şeylər də daxil olmaqla QoS təmin etməyi bacarın.
- NETCONF-u dəstəkləyin - gələcək üçün ehtiyat.
Mən burada Underlay şəbəkəsinin işinə çox az vaxt ayırdım. Bunun səbəbi daha sonra serialda buna diqqət edəcəyəm və keçiddə yalnız Overlay-a toxunacağıq.
Aydındır ki, mən Klosenin fabrikində təmiz IP marşrutlaşdırması və hostun üst-üstə düşməsi ilə qurulmuş DC şəbəkəsini nümunə kimi istifadə edərək, hamımızı ciddi şəkildə məhdudlaşdırıram.
Bununla belə, əminəm ki, dizaynı olan hər hansı bir şəbəkə formal şəkildə təsvir edilə və avtomatlaşdırıla bilər. Sadəcə olaraq, mən burada məqsəd güdürəm ki, avtomatlaşdırmaya yanaşmaları başa düşək və ümumiyyətlə hamını çaşdırmayım, problemi ümumi şəkildə həll edək.
ADSM çərçivəsində Roman Gorge və mən hesablama gücünün virtuallaşdırılması və onun şəbəkə virtualizasiyası ilə qarşılıqlı əlaqəsi haqqında ayrıca buraxılış dərc etməyi planlaşdırırıq. Əlaqədə qal.
Faydalı linklər
- .
- . TF-də virtual şəbəkə də daxil olmaqla Yandex.Cloud haqqında 6 saat.
- .
- . Bu, Underlay, Overlay daxil olmaqla, bütün DC şəbəkəsindən, çoxlu evlərə və idarəetməyə yanaşmalardan bəhs edir.
təşəkkürlər
- Keçmiş linkmeup podcast aparıcısı və indi bulud platforması mütəxəssisi. Şərhlər və redaktələr üçün. Yaxşı, yaxın gələcəkdə onun virtuallaşdırma ilə bağlı daha dərin məqaləsini gözləyirik.
- - virtual şəbəkənin inkişafı sahəsində həmkarıma və ekspertə. Şərhlər və redaktələr üçün.
- — həmkarıma və volfram parça mütəxəssisinə. Şərhlər və redaktələr üçün.
- - illustrator linkmeup. KDPV üçün.
- Aleksandr Limonov. "Avtomat" mem üçün.
Mənbə: www.habr.com