İlk iki məqalədə mən avtomatlaşdırma məsələsini qaldırdım və onun çərçivəsini təsvir etdim, ikincisində xidmət konfiqurasiyasının avtomatlaşdırılmasına ilk yanaşma kimi şəbəkənin virtuallaşdırılmasına nəzər saldım.
İndi fiziki şəbəkənin diaqramını çəkməyin vaxtı gəldi.

Əgər məlumat mərkəzi şəbəkələrinin təşkili ilə qısa bir yerdə deyilsinizsə, onda mən bundan başlamağı tövsiyə edirəm onlar haqqında məqalələr.

Bütün buraxılışlar:

• 0. ADSM. Sıfır hissə. Planlaşdırma
• 1. ADSM. Birinci hissə (sıfırdan sonra). Şəbəkə virtualizasiyası
• 2. ADSM. İkinci hissə. Şəbəkə dizaynı

Bu seriyada təsvir olunan təcrübələr istənilən şəbəkə növünə, istənilən miqyasda və istənilən müxtəlif satıcılara şamil edilməlidir (yox). Lakin bu yanaşmaların tətbiqinin universal nümunəsini təsvir etmək mümkün deyil. Buna görə də mən DC şəbəkəsinin müasir arxitekturasına diqqət yetirəcəyəm: Kloz fabriki.
MPLS L3VPN-də DCI edəcəyik.

Fiziki şəbəkənin üstündə, hostdan bir Overlay şəbəkəsi var (bu, OpenStack-in VXLAN və ya Volfram Parçası və ya şəbəkədən yalnız əsas IP bağlantısı tələb edən başqa bir şey ola bilər).

Bu halda, avtomatlaşdırma üçün nisbətən sadə bir ssenari əldə edirik, çünki bizdə eyni şəkildə konfiqurasiya edilmiş çoxlu avadanlıq var.

Vakuumda sferik DC seçəcəyik:

• Hər yerdə bir dizayn versiyası.
• İki şəbəkə təyyarəsini təşkil edən iki satıcı.
• Bir DC iki damcı su kimi digərinə bənzəyir.

Məzmun

• Fiziki topologiya
• Marşrutlaşdırma
• IP planı
• Laba
• Nəticə
• Faydalı linklər

Məsələn, bizim Xidmət Provayderimiz LAN_DC-yə tıxanmış liftlərin sağ qalması haqqında təlim videoları təqdim etsin.

Meqapolislərdə bu çox populyardır, ona görə də sizə çoxlu fiziki maşın lazımdır.

Əvvəlcə şəbəkəni görmək istədiyim kimi təsvir edəcəyəm. Və sonra laboratoriya üçün sadələşdirəcəyəm.

Fiziki topologiya

Yerlər

LAN_DC-də 6 DC olacaq:

• Rusiya (RU):
  • Moskva (msk)
  • Kazan (kzn)

• İspaniya (SP):
  • Barselona (bcn)
  • Malaga (mlg)

• Çin (CN):
  • Şanxay (şa)
  • Sian (sia)

DC daxilində (Daxili DC)

Bütün DC-lər Klose topologiyasına əsaslanan eyni daxili əlaqə şəbəkələrinə malikdir.
Kloz şəbəkələri nədir və niyə məhz onlardır - ayrıca məqalə.

Hər DC-də avtomobillərlə birlikdə 10 raf var, onlar kimi nömrələnəcəklər A, B, C Və s.

Hər rafda 30 maşın var. Bizi maraqlandırmayacaqlar.

Ayrıca, hər bir rafda bütün maşınların qoşulduğu bir keçid var - bu Rafın üstü açarı - ToR yoxsa Klose fabriki baxımından biz onu çağıracağıq Yarpaq.

Zavodun ümumi sxemi.

Onların adlarını çəkəcəyik XXX-yarpaqYHara XXX - üç hərfli abreviatura DC, və Y - seriya nömrəsi. Misal üçün, kzn-yarpaq11.

Məqalələrimdə Leaf və ToR terminlərini sinonim kimi istifadə etməyə icazə verəcəyəm. Ancaq bunun belə olmadığını xatırlamaq lazımdır.
ToR, maşınların qoşulduğu rafa quraşdırılmış açardır.
Leaf fiziki şəbəkədə cihazın və ya Klose topologiyası baxımından birinci səviyyəli keçidin roludur.
Yəni, Leaf != ToR.
Beləliklə, yarpaq, məsələn, EndofRaw açarı ola bilər.
Ancaq bu məqalə çərçivəsində biz yenə də onları sinonim kimi nəzərdən keçirəcəyik.

Hər bir ToR açarı öz növbəsində dörd daha yüksək aqreqasiya açarına qoşulur - bel. Onurğanın altında DC-də bir rack ayrılmışdır. Bunu belə adlandıracağıq: XXX- onurğaY.

Eyni rafda DC-lər arasında əlaqə üçün şəbəkə avadanlığı olacaq - bortda MPLS ilə 2 marşrutlaşdırıcı. Ancaq ümumilikdə bunlar eyni Torlardır. Yəni, Spine açarları baxımından bağlı maşınlarla adi ToR və ya DCI üçün marşrutlaşdırıcının əhəmiyyəti yoxdur - bir lənətə gəlmiş şey.

Belə xüsusi ToR adlanır Kənar yarpaq. Onların adlarını çəkəcəyik XXX- kənarY.

Bu belə görünəcək.

Yuxarıdakı diaqramda, həqiqətən, kənar və yarpağı eyni səviyyədə yerləşdirdim. Klassik üç qatlı şəbəkələr bizə uplink-i (əslində, termini) yuxarı bağlantılar kimi nəzərdən keçirməyi öyrətdi. Və buradan belə çıxır ki, DCI "yuxarı bağlantı" geri qayıdır ki, bu da bəziləri üçün adi məntiqi bir az pozur. Böyük şəbəkələr vəziyyətində, məlumat mərkəzləri daha kiçik bölmələrə bölündükdə - POD's (Çatdırılma Nöqtəsi), fərdi olaraq ayırın Edge-POD's DCI və xarici şəbəkələrə çıxış üçün.

Gələcəkdə qavrayış asanlığı üçün hələ də Edge-ni Onurğanın üzərinə çəkəcəyəm, eyni zamanda nəzərə alacağıq ki, onurğada heç bir kəşfiyyat yoxdur və adi Yarpaq və Kənar yarpaq ilə işləyərkən heç bir fərq yoxdur (baxmayaraq ki, nüanslar ola bilər). , lakin ümumilikdə bu doğrudur).

Kenar yarpaqları olan zavod diaqramı.

Yarpaq, Onurğa və Kənar üçlüyü alt qat şəbəkəsini və ya fabrikini təşkil edir.

Şəbəkə fabrikinin vəzifəsi (Underlay-ı oxuyun), artıq müəyyən etdiyimiz kimi son məsələ, çox, çox sadə - həm eyni DC daxilində, həm də onlar arasında maşınlar arasında IP bağlantısını təmin etmək.
Buna görə şəbəkə fabrik adlanır, məsələn, modul şəbəkə qutuları içərisindəki kommutasiya fabriki kimi, haqqında daha çox oxuya bilərsiniz. SDSM14.

Ümumiyyətlə, belə bir topologiya fabrik adlanır, çünki tərcümədə parça parçadır. Və bununla razılaşmamaq çətindir:

Zavod tam L3-dür. VLAN yoxdur, Yayım yoxdur - bunlar LAN_DC-də malik olduğumuz gözəl proqramçılardır, L3 paradiqmasında yaşayan proqramlar yaza bilirlər və virtual maşınlar IP ünvanını saxlamaqla Canlı Miqrasiya tələb etmir.

Və bir daha: niyə fabrik və niyə L3 ayrıdır sualına cavab məqalə.

DCI - Data Center Interconnect (İnter-DC)

DCI Edge-Leaf köməyi ilə təşkil ediləcək, yəni magistral yola çıxış nöqtəmizdir.
Sadəlik üçün, DC-lərin birbaşa bağlantılarla bir-birinə bağlı olduğunu güman edirik.
Xarici əlaqəni nəzərə almayaq.

Bilirəm ki, hər dəfə komponenti siləndə şəbəkəni çox sadələşdirirəm. Mücərrəd şəbəkəmizi avtomatlaşdırarkən hər şey yaxşı olacaq, amma realda qoltuqaltılar görünəcək.
Bu doğrudur. Və yenə də bu seriyanın məqsədi uydurma problemləri qəhrəmancasına həll etmək deyil, yanaşmalar üzərində düşünmək və işləməkdir.

Edge-Leafs-də altlıq VPN-ə yerləşdirilir və MPLS magistralından (eyni birbaşa keçid) ötürülür.

Budur, belə bir yüksək səviyyəli sxem əldə edilir.

Marşrutlaşdırma

DC daxilində marşrutlaşdırma üçün BGP istifadə edəcəyik.
OSPF+LDP MPLS onurğasında.
DCI üçün, yəni alt təbəqədə əlaqənin təşkili - MPLS üzərindən BGP L3VPN.

Ümumi marşrutlaşdırma sxemi

Zavodda OSPF və İŞİD yoxdur (Rusiya Federasiyasında marşrutlaşdırma protokolu qadağandır).

Və bu o deməkdir ki, ən qısa yolların avtomatik kəşfi və hesablanması olmayacaq - yalnız əl ilə (əslində avtomatik - burada avtomatlaşdırmadan danışırıq) protokol, qonşuluq və siyasət parametrləri.

DC daxilində BGP marşrutlaşdırma sxemi

Niyə BGP?

Var bütün RFC necə qurulacağını izah edən Facebook və Arista adlı çox böyük BGP istifadə edərək məlumat mərkəzi şəbəkələri. Demək olar ki, fantastika kimi oxunur, onu yorğun bir axşam üçün çox tövsiyə edirəm.

Mənim məqaləmdə də buna həsr olunmuş bütöv bir bölmə var. Səni hara apara bilərəm və göndər.

Ancaq yenə də, bir sözlə, şəbəkə cihazlarının sayının minlərlə olduğu böyük məlumat mərkəzlərinin şəbəkələri üçün heç bir IGP uyğun deyil.

Bundan əlavə, BGP-nin hər yerdə istifadəsi bir neçə fərqli protokolun dəstəyinə və onlar arasında sinxronizasiyaya səpilməməyə imkan verəcəkdir.

Çox güman ki, sürətlə inkişaf etməyəcək fabrikimizdə əl-ələ, OSPF gözümüzə bəs edərdi. Bu, əslində meqa skalerlərin və bulud titanlarının problemidir. Ancaq gəlin bizə lazım olan bir neçə məsələ üçün fantaziya edək və Peter Lapuxovun vəsiyyət etdiyi kimi BGP-dən istifadə edəcəyik.

Marşrutlaşdırma Siyasətləri

Yarpaq açarlarında biz alt şəbəkə interfeyslərindən prefiksləri BGP-yə idxal edirik.
arasında BGP sessiyamız olacaq hər bu Underlay prefikslərinin şəbəkə üzərindən burada və orada elan ediləcəyi bir cüt Leaf-Spine.

Bir məlumat mərkəzinin içərisində Tor-a idxal etdiyimiz xüsusiyyətləri yayacağıq. Edge-Leafs-də biz onları birləşdirib uzaq DC-lərə elan edəcəyik və Tors-a göndərəcəyik. Yəni, hər bir Tor eyni DC-də başqa Tor-a necə çatacağını və başqa DC-də Tor-a çatmaq üçün giriş nöqtəsinin harada olduğunu dəqiq biləcək.

DCI-də marşrutlar VPNv4 kimi ötürüləcək. Bunun üçün Edge-Leaf-də fabrikə doğru interfeys VRF-də yerləşdiriləcək, gəlin onu UNDERLAY adlandıraq və Kənar-Yarpaqda Onurğa ilə qonşuluq VRF daxilində və Kənar-Yarpaqlar arasında yüksələcək. VPNv4 ailəsində.

Biz həmçinin onurğalardan alınan marşrutların onlara geri qaytarılmasını qadağan edəcəyik.

Leaf və Spine-də biz Loopbackləri idxal etməyəcəyik. Bizə yalnız Router ID-ni müəyyən etmək üçün lazım olacaq.

Ancaq Edge-Leafs-də onu Global BGP-yə idxal edirik. Geri dönmə ünvanları arasında Edge-Leafs bir-biri ilə IPv4 VPN ailəsində BGP seansı quracaq.

EDGE cihazları arasında OSPF + LDP-yə qədər uzanan bir magistralımız olacaq. Hamısı bir zonada. Son dərəcə sadə konfiqurasiya.

Budur marşrutlaşdırma ilə bir şəkil.

BGP ASN

Edge Leaf ASN

Edge-Leafs-də bütün DC-lərdə bir ASN olacaq. Edge-Leafs arasında iBGP olması vacibdir və biz eBGP nüanslarına rast gəlmirik. 65535 olsun. Əslində bu, ictimai AS nömrəsi ola bilər.

Onurğa ASN

Onurğada hər DC üçün bir ASN olacaq. Burada özəl AS diapazonundan ilk nömrədən başlayaq - 64512, 64513 Və s.

Niyə DC-də ASN?

Bu sualı iki yerə bölək:

• Niyə bir DC-nin bütün onurğalarında eyni ASN?
• Fərqli DC-lərdə niyə fərqlidirlər?

Niyə bir DC-nin bütün onurğalarında eyni ASN

Kənar-Yarpaqdakı Yeraltı Marşrutun AS-Yol belə görünəcək:
[leafX_ASN, spine_ASN, edge_ASN]
Onu yenidən Spine-a elan etməyə çalışarkən, onun AS (Spine_AS) artıq siyahıda olduğu üçün atılacaq.

Bununla belə, DC daxilində, Edge-ə yüksəlmiş Underlay marşrutlarının aşağı enə bilməyəcəyindən tamamilə razıyıq. DC daxilində ev sahibləri arasında bütün əlaqə onurğalar səviyyəsində baş verməlidir.

Eyni zamanda, digər DC-lərin cəmlənmiş marşrutları istənilən halda Tors-a sərbəst çatacaq - onların AS-Yolunda yalnız ASN 65535 olacaq - AS Edge-Leafs sayı, çünki onlar yaradılmışdır.

Fərqli DC-lərdə niyə fərqlidirlər

Teorik olaraq, biz DC-lər arasında Loopback və bəzi xidmət virtual maşınlarını sürükləməyimiz lazım ola bilər.

Məsələn, hostda biz Route Reflector və ya işlədəcəyik eyni VNGW (Virtual Şəbəkə Gateway), BGP vasitəsilə Tor ilə özünü bağlayacaq və bütün DC-lərdən əldə edilməli olan geri döngəsini elan edəcək.

Beləliklə, onun AS-Path belə görünəcək:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Və heç bir yerdə təkrarlanan ASN-lər olmamalıdır.

Yəni, Spine_DC1 və Spine_DC2 fərqli olmalıdır, eynilə leafX_DC1 və leafY_DC2 kimi, məhz bizim yaxınlaşdığımız şeydir.

Yəqin ki, bildiyiniz kimi, döngələrin qarşısının alınması mexanizminə (Cisco-da icazə verilir) baxmayaraq, dublikat ASN-lərlə marşrutları qəbul etməyə imkan verən hacklər var. Və hətta qanuni istifadələri var. Ancaq bu, şəbəkənin sabitliyində potensial bir boşluqdur. Və şəxsən mən bir neçə dəfə buna düşdüm.

Və əgər təhlükəli şeylərdən istifadə etməmək imkanımız olsa, ondan istifadə edəcəyik.

Yarpaq ASN

Bütün şəbəkə daxilində hər Leaf keçidində fərdi ASN-imiz olacaq.
Biz bunu yuxarıda göstərilən səbəblərə görə edirik: Döngələrsiz AS-Path, əlfəcinsiz BGP konfiqurasiyası.

Yarpaqlar arasındakı marşrutların rəvan keçməsi üçün AS-Path belə görünməlidir:
[leafX_ASN, spine_ASN, leafY_ASN]
burada leafX_ASN və leafY_ASN fərqli olsaydı yaxşı olardı.

Bu, DC-lər arasında VNF geri döngəsinin elanı ilə bağlı vəziyyət üçün də tələb olunur:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Biz 4 baytlıq ASN-dən istifadə edəcəyik və onu Onurğanın ASN-si və Yarpaq keçidinin nömrəsi əsasında yaradacağıq, yəni: Onurğa_ASN.0000X.

Budur ASN ilə belə bir şəkil.

IP planı

Əsasən, aşağıdakı bağlantılar üçün ünvanlar ayırmalıyıq:

1. ToR və maşın arasında alt şəbəkə ünvanları. Onlar bütün şəbəkə daxilində unikal olmalıdırlar ki, istənilən maşın digəri ilə əlaqə saxlaya bilsin. Əla uyğun 10/8. Hər bir rəf üçün / 26 bir kənar ilə. Biz DC üçün /19 və region üçün /17 ayıracağıq.
2. Leaf/Tor və Spine arasında əlaqə ünvanları.

   Onları alqoritmik olaraq təyin etmək, yəni qoşulması lazım olan cihazların adlarından hesablamaq istərdim.

   Olsun... 169.254.0.0/16.
   Yəni 169.254.00X.Y/31Hara X - Onurğa nömrəsi, Y — P2P şəbəkəsi /31.
   Bu, DC-də 128-ə qədər rack və 10-a qədər Spine işlətməyə imkan verəcək. Bağlantı ünvanları DC-dən DC-yə təkrarlana bilər (və olacaq).

3. Birgə onurğa - Edge-Leaf alt şəbəkələrdə təşkil edilir 169.254.10X.Y/31, harada tam eyni X - Onurğa nömrəsi, Y — P2P şəbəkəsi /31.
4. Edge-Leaf-dan MPLS magistralına keçid ünvanları. Burada vəziyyət bir qədər fərqlidir - bütün parçaların bir pasta ilə birləşməsi, buna görə də eyni ünvanları təkrar istifadə edə bilməyəcəksiniz - növbəti pulsuz alt şəbəkəni seçməlisiniz. Ona görə də əsas götürürük 192.168.0.0/16 və biz ondan azad olacağıq.
5. Geri dönmə ünvanları. Gəlin onlara bütün diapazonu verək 172.16.0.0/12.
   • Yarpaq - / DC-də hər biri 25 - eyni 128 raf. Bölgəyə /23 ayırın.
   • Onurğa - DC-də /28 ilə - 16 Onurğaya qədər. Bölgəyə /26 ayırın.
   • Edge-Leaf - DC-də /29 - 8 qutuya qədər. Bölgəyə /27 ayırın.

Əgər DC-də kifayət qədər ayrılmış diapazonlarımız yoxdursa (və bizdə olmayacaq - biz özümüzü hiperskaler kimi göstəririk), sadəcə növbəti bloku seçirik.

Budur IP ünvanlı bir şəkil.

Geri dönmələr:

Prefiks
Cihazın rolu
Rayon
DC

172.16.0.0/23
kənar
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
mlg

172.16.0.64/27
cn
 

172.16.0.64/29
şa

172.16.0.72/29
sia

172.16.2.0/23
bel
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
mlg

172.16.2.128/26
cn
 

172.16.2.128/28
şa

172.16.2.144/28
sia

172.16.8.0/21
yarpaq
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
mlg

172.16.12.0/23
cn
 

172.16.12.0/25
şa

172.16.12.128/25
sia

Alt örtük:

Prefiks
Rayon
DC

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
mlg

10.1.0.0/17
cn
 

10.1.0.0/19
şa

10.1.32.0/19
sia

Laba

İki satıcı. Bir şəbəkə. ADSM.

Ardıc + Arista. Ubuntu. Yaxşı köhnə Həvva.

Mirandakı virtual maşınımızdakı resursların miqdarı hələ də məhduddur, buna görə də təcrübə üçün belə sadələşdirilmiş şəbəkədən limitə qədər istifadə edəcəyik.

İki məlumat mərkəzi: Kazan və Barselona.

• Hər biri iki fırlanma: Juniper və Arista.
• Hər birində bir torus (Yarpaq) - Juniper və Arista, bir bağlı host ilə (bunun üçün yüngül Cisco IOL götürək).
• Hər biri bir Edge-Leaf node (indiyə qədər yalnız Juniper).
• Onların hamısını idarə etmək üçün bir Cisco açarı.
• Şəbəkə qutularına əlavə olaraq, virtual maşın meneceri işə salındı. Ubuntu altında.
  Bütün cihazlara çıxışı var, o, IPAM / DCIM sistemlərini, bir dəstə Python skriptini, ansible və ehtiyac duya biləcəyimiz hər şeyi işlədəcək.

Tam konfiqurasiya avtomatlaşdırmadan istifadə edərək çoxaltmağa çalışacağımız bütün şəbəkə cihazları.

Nəticə

O da qəbul olunur? Qısa bir nəticə çıxarmaq üçün hər məqalənin altında?

Beləliklə, biz seçdik üç səviyyəli DC daxilində Kloz şəbəkəsi, çünki biz çoxlu Şərq-Qərb trafikini gözləyirik və ECMP istəyirik.

Şəbəkəni fiziki (astar) və virtual (overlay) olaraq ayırdıq. Eyni zamanda, üst-üstə düşmə ev sahibindən başlayır - bununla da astar üçün tələbləri sadələşdirir.

Ölçeklenebilirliği və siyasət çevikliyi üçün marşrutlaşdırıcının marşrutlaşdırma protokolu kimi BGP-ni seçdi.

DCI - Edge-leaf təşkil etmək üçün ayrıca qovşaqlarımız olacaq.
Onurğa sütununda OSPF+LDP olacaq.
DCI MPLS L3VPN əsasında həyata keçiriləcək.
P2P bağlantıları üçün biz IP ünvanlarını cihaz adlarına əsasən alqoritmik olaraq hesablayacağıq.
Geri dönmələr cihazların roluna və ardıcıl olaraq yerləşməsinə görə təyin ediləcək.
Alt qat prefiksləri - yalnız yerləşdikləri yerə görə sıra ilə yarpaq açarlarında.

Tutaq ki, hazırda bizdə heç bir avadanlıq quraşdırılmayıb.
Buna görə də, növbəti addımlarımız onları sistemlərə (IPAM, inventar) daxil etmək, girişi təşkil etmək, konfiqurasiya yaratmaq və yerləşdirmək olacaq.

Növbəti məqalədə biz DC-də IP məkanı üçün inventar və idarəetmə sistemi olan Netbox ilə məşğul olacağıq.

təşəkkürlər

• Andrey Qlazkov aka @glazgoo korrektə və redaktə üçün
• Alexandru Klimenko aka @v00lk korrektə və redaktə üçün
• KDPV üçün Artyom Chernobay

Mənbə: www.habr.com