در دو مقاله اول، موضوع اتوماسیون را مطرح کردم و چارچوب آن را ترسیم کردم، در دومی به مجازی سازی شبکه، به عنوان اولین رویکرد برای خودکارسازی پیکربندی خدمات، عقب نشینی کردم.
اکنون زمان ترسیم نموداری از شبکه فیزیکی است.

اگر با راه‌اندازی شبکه‌های مرکز داده آشنایی ندارید، اکیداً توصیه می‌کنم از آن شروع کنید مقالاتی در مورد آنها.

همه مسائل:

• 0. ADSM. قسمت صفر. برنامه ریزی
• 1. ADSM. قسمت اول (که بعد از صفر است). مجازی سازی شبکه
• 2. ADSM. بخش دوم. طراحی شبکه

شیوه‌های توصیف‌شده در این مجموعه باید برای هر نوع شبکه، هر اندازه، با هر نوع فروشنده (نه) قابل اجرا باشد. با این حال، توصیف یک مثال جهانی از کاربرد این رویکردها غیرممکن است. بنابراین، من بر روی معماری مدرن شبکه DC تمرکز خواهم کرد: کارخانه کلوز.
ما DCI را در MPLS L3VPN انجام خواهیم داد.

یک شبکه Overlay در بالای شبکه فیزیکی از میزبان اجرا می شود (این می تواند OpenStack VXLAN یا Tungsten Fabric یا هر چیز دیگری باشد که فقط به اتصال IP اولیه از شبکه نیاز دارد).

در این مورد، ما یک سناریوی نسبتا ساده برای اتوماسیون به دست می آوریم، زیرا تجهیزات زیادی داریم که به همین روش پیکربندی شده اند.

ما یک DC کروی را در خلاء انتخاب می کنیم:

• یک نسخه طراحی در همه جا.
• دو فروشنده که دو صفحه شبکه را تشکیل می دهند.
• یک DC مانند دیگری مانند دو نخود در یک غلاف است.

مقدار

• توپولوژی فیزیکی
• مسیریابی
• طرح IP
• لابا
• نتیجه
• لینک های مفید

به عنوان مثال، به ارائه دهنده خدمات ما LAN_DC اجازه دهید ویدیوهای آموزشی درباره زنده ماندن در آسانسورهای گیر کرده میزبانی کند.

در کلان شهرها این بسیار محبوب است، بنابراین شما به ماشین های فیزیکی زیادی نیاز دارید.

ابتدا شبکه را تقریباً همانطور که می خواهم توصیف می کنم. و سپس آن را برای آزمایشگاه ساده می کنم.

توپولوژی فیزیکی

مکانها

LAN_DC دارای 6 DC خواهد بود:

• روسیه (RU):
  • مسکو (msk)
  • کازان (kzn)

• اسپانیا (SP):
  • بارسلونا (bcn)
  • مالاگا (گروه ادبی مارکسیستی)

• چین (CN):
  • شانگهای (SHA)
  • شیان (هر دو)

DC داخلی (Intra-DC)

همه DCها دارای شبکه های اتصال داخلی یکسان بر اساس توپولوژی Clos هستند.
آنها چه نوع شبکه های Clos هستند و چرا در یک مجزا قرار دارند مقاله.

هر DC دارای 10 قفسه با ماشین آلات است، آنها به عنوان شماره گذاری می شوند A, B, C و به همین ترتیب.

هر قفسه دارای 30 دستگاه است. آنها به ما علاقه ای نخواهند داشت.

همچنین در هر قفسه سوئیچ وجود دارد که تمام ماشین ها به آن متصل هستند - این است بالای سوئیچ Rack - ToR یا در غیر این صورت از نظر کارخانه کلوس به آن می گوییم برگ.

نمودار کلی کارخانه.

ما با آنها تماس خواهیم گرفت XXX-برگYجایی که XXX - مخفف سه حرفی DC، و Y - شماره سریال. مثلا، kzn-leaf11.

در مقاله‌هایم به خودم اجازه می‌دهم از اصطلاحات Leaf و ToR به‌طور بی‌اهمیت به عنوان مترادف استفاده کنم. با این حال، باید به یاد داشته باشیم که اینطور نیست.
ToR یک سوئیچ است که در یک قفسه نصب شده است که ماشین ها به آن متصل هستند.
Leaf نقش یک دستگاه در یک شبکه فیزیکی یا یک سوئیچ سطح اول از نظر توپولوژی Cloes است.
یعنی Leaf != ToR.
بنابراین Leaf می تواند برای مثال یک سوئیچ EndofRaw باشد.
با این حال، در چارچوب این مقاله، ما همچنان با آنها به عنوان مترادف برخورد خواهیم کرد.

هر سوئیچ ToR به نوبه خود به چهار سوئیچ تجمع سطح بالاتر متصل است - ستون فقرات. یک رک در DC برای Spines اختصاص داده شده است. ما آن را به طور مشابه نام گذاری می کنیم: XXX-ستون فقراتY.

همان رک شامل تجهیزات شبکه برای اتصال بین روترهای DC - 2 با MPLS روی برد خواهد بود. اما به طور کلی، اینها همان ToR ها هستند. یعنی از نظر سوئیچ های Spine ، ToR معمولی با ماشین های متصل یا روتر برای DCI اصلاً مهم نیست - فقط فوروارد کردن.

چنین ToR های ویژه ای نامیده می شوند لبه برگ. ما با آنها تماس خواهیم گرفت XXX-حاشیه، غیرمتمرکزY.

شبیه این خواهد شد.

در نمودار بالا، من در واقع لبه و برگ را در یک سطح قرار دادم. شبکه های سه لایه کلاسیک آنها به ما یاد دادند که uplinking (از این رو اصطلاح) را به عنوان uplink در نظر بگیریم. و در اینجا معلوم می شود که "uplink" DCI به پایین باز می گردد، که برای برخی کمی منطق معمول را زیر پا می گذارد. در مورد شبکه های بزرگ، زمانی که مراکز داده به واحدهای حتی کوچکتر تقسیم می شوند - POD's (نقطه تحویل)، جداگانه برجسته کنید Edge-PODبرای DCI و دسترسی به شبکه های خارجی است.

برای سهولت درک در آینده، من همچنان Edge را روی ستون فقرات ترسیم خواهم کرد، در حالی که در نظر داشته باشیم که هیچ هوشمندی روی ستون فقرات وجود ندارد و هنگام کار با برگ معمولی و Edge-leaf هیچ تفاوتی وجود ندارد (اگرچه ممکن است تفاوت های ظریف در اینجا وجود داشته باشد. ، اما به طور کلی این درست است).

طرح یک کارخانه با برگ های لبه ای.

تثلیث Leaf، Spine و Edge یک شبکه Underlay یا کارخانه را تشکیل می دهند.

وظیفه یک کارخانه شبکه (بخوانید Underlay)، همانطور که قبلاً در آن تعریف کردیم آخرین شماره، بسیار بسیار ساده - برای ارائه اتصال IP بین ماشین ها در یک DC و بین آنها.
به همین دلیل است که شبکه را کارخانه می نامند، درست مانند کارخانه سوئیچینگ در داخل جعبه های شبکه مدولار، که می توانید در مورد آن بیشتر بخوانید. SDSM14.

به طور کلی به چنین توپولوژی کارخانه ای گفته می شود، زیرا پارچه در ترجمه به معنای پارچه است. و مخالفت سخت است:

کارخانه کاملا L3 است. بدون VLAN، بدون Broadcast - ما برنامه نویسان فوق العاده ای در LAN_DC داریم، آنها می دانند که چگونه برنامه هایی بنویسند که در الگوی L3 زندگی می کنند و ماشین های مجازی به انتقال زنده با حفظ آدرس IP نیاز ندارند.

و بار دیگر: پاسخ به این سوال که چرا کارخانه و چرا L3 در یک جداگانه است مقاله.

DCI - اتصال مرکز داده (Inter-DC)

DCI با استفاده از Edge-Leaf سازماندهی می شود، یعنی آنها نقطه خروج ما به بزرگراه هستند.
برای سادگی، فرض می کنیم که DC ها توسط لینک های مستقیم به یکدیگر متصل شده اند.
اجازه دهید اتصال خارجی را از بررسی حذف کنیم.

من می دانم که هر بار که یک جزء را حذف می کنم، شبکه را به طور قابل توجهی ساده می کنم. و وقتی شبکه انتزاعی خود را خودکار کنیم، همه چیز خوب خواهد بود، اما در شبکه واقعی عصا وجود خواهد داشت.
درست است. با این حال، هدف این سریال تفکر و کار روی رویکردها است، نه حل قهرمانانه مسائل خیالی.

در Edge-Leafs، لایه زیرین در VPN قرار می گیرد و از طریق ستون فقرات MPLS (همان پیوند مستقیم) منتقل می شود.

این نمودار سطح بالایی است که ما دریافت می کنیم.

مسیریابی

برای مسیریابی در DC از BGP استفاده خواهیم کرد.
در تنه MPLS OSPF+LDP.
برای DCI، یعنی سازماندهی اتصال در زیرزمین - BGP L3VPN از طریق MPLS.

طرح مسیریابی عمومی

هیچ OSPF یا ISIS (پروتکل مسیریابی ممنوع در فدراسیون روسیه) در کارخانه وجود ندارد.

این بدان معنی است که هیچ کشف خودکار یا محاسبه کوتاه‌ترین مسیرها وجود نخواهد داشت - فقط به صورت دستی (در واقع خودکار - در اینجا در مورد اتوماسیون صحبت می‌کنیم) تنظیم پروتکل، محله و خط‌مشی‌ها.

طرح مسیریابی BGP در DC

چرا BGP؟

در مورد این موضوع وجود دارد کل RFC به نام فیس بوک و آریستا، که نحوه ساخت را می گوید بسیار بزرگ شبکه های مرکز داده با استفاده از BGP تقریباً شبیه داستان می‌خواند، من آن را برای یک شب بی‌حال به شدت توصیه می‌کنم.

و همچنین یک بخش کامل در مقاله من به این موضوع اختصاص دارد. کجا ببرمت و دارم میفرستم.

اما با این حال، به طور خلاصه، هیچ IGP برای شبکه های مراکز داده بزرگ، جایی که تعداد دستگاه های شبکه به هزاران دستگاه می رسد، مناسب نیست.

علاوه بر این، استفاده از BGP در همه جا به شما این امکان را می دهد که وقت خود را برای پشتیبانی از چندین پروتکل مختلف و همگام سازی بین آنها تلف نکنید.

دست روی قلب، در کارخانه ما که با احتمال زیاد به سرعت رشد نمی کند، OSPF برای چشم ها کافی است. اینها در واقع مشکلات مگاسکیلرها و تایتان های ابری هستند. اما بیایید تصور کنیم که فقط برای چند نسخه به آن نیاز داریم و همانطور که پیوتر لاپوخوف وصیت کرده است از BGP استفاده خواهیم کرد.

سیاست های مسیریابی

در سوئیچ‌های Leaf، پیشوندها را از رابط‌های شبکه Underlay به BGP وارد می‌کنیم.
ما یک جلسه BGP بین آنها خواهیم داشت هر یک یک جفت Leaf-Spine، که در آن این پیشوندهای Underlay از طریق شبکه به صورت رفت و برگشت اعلام خواهند شد.

در یک مرکز داده، مشخصاتی را که به ToRe وارد کرده‌ایم توزیع می‌کنیم. در Edge-Leafs آنها را جمع می کنیم و به DC های راه دور اعلام می کنیم و به TOR ها ارسال می کنیم. یعنی هر ToR دقیقاً می‌داند که چگونه به ToR دیگری در همان DC برسد و نقطه ورودی کجاست که به ToR در یک DC دیگر برسد.

در DCI، مسیرها به صورت VPNv4 منتقل می شوند. برای انجام این کار، در Edge-Leaf، رابط به سمت کارخانه در یک VRF قرار می گیرد، اجازه دهید آن را UNDERLAY بنامیم، و همسایگی با Spine در Edge-Leaf در VRF و بین Edge-Leafs در VPNv4- افزایش می یابد. خانواده.

ما همچنین اعلام مجدد مسیرهای دریافتی از spines را به آنها ممنوع خواهیم کرد.

در Leaf and Spine ما Loopback ها را وارد نمی کنیم. ما فقط به آنها برای تعیین شناسه روتر نیاز داریم.

اما در Edge-Leafs ما آن را به Global BGP وارد می کنیم. بین آدرس‌های Loopback، Edge-Leafs یک جلسه BGP در خانواده IPv4 VPN با یکدیگر برقرار می‌کند.

ما یک ستون فقرات OSPF+LDP بین دستگاه های EDGE خواهیم داشت. همه چیز در یک منطقه است. پیکربندی بسیار ساده

این تصویر با مسیریابی است.

BGP ASN

Edge-Leaf ASN

Edge-Leafs یک ASN در همه DCها خواهد داشت. مهم است که iBGP بین Edge-Leafs وجود داشته باشد، و ما درگیر تفاوت های ظریف eBGP نمی شویم. بگذارید 65535 باشد. در واقع، این می تواند تعداد یک AS عمومی باشد.

ستون فقرات ASN

در Spine ما یک ASN در هر DC خواهیم داشت. بیایید از اینجا با اولین شماره از محدوده AS خصوصی - 64512، 64513 و غیره شروع کنیم.

چرا ASN در DC؟

بیایید این سوال را به دو بخش تقسیم کنیم:

• چرا ASN ها در تمام ستون های یک DC یکسان هستند؟
• چرا آنها در DC های مختلف متفاوت هستند؟

چرا ASN های یکسان در تمام ستون های یک DC وجود دارد؟

مسیر AS-Path مسیر Underlay در Edge-Leaf به این صورت خواهد بود:
[leafX_ASN, spine_ASN, edge_ASN]
وقتی می‌خواهید آن را به Spine تبلیغ کنید، آن را کنار می‌گذارد زیرا AS آن (Spine_AS) قبلاً در لیست است.

با این حال، در داخل DC ما کاملاً راضی هستیم که مسیرهای Underlay که به Edge صعود می کنند قادر به پایین آمدن نخواهند بود. تمام ارتباطات بین میزبان ها در DC باید در سطح ستون فقرات انجام شود.

در همان زمان، مسیرهای جمع‌آوری شده سایر DCها در هر صورت به راحتی به ToRها می‌رسند - مسیر AS آنها فقط دارای ASN 65535 است - تعداد AS Edge-Leafs، زیرا در آنجا ایجاد شده‌اند.

چرا آنها در DC های مختلف متفاوت هستند؟

از نظر تئوری، ممکن است لازم باشد Loopback و برخی ماشین‌های مجازی سرویس را بین DCها بکشیم.

به عنوان مثال، در هاست Route Reflector یا را اجرا خواهیم کرد همان VNGW (Virtual Network Gateway) که با TopR از طریق BGP قفل می شود و لوپ بک خود را اعلام می کند که باید از همه DC ها قابل دسترسی باشد.

بنابراین AS-Path آن به این صورت است:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

و هیچ کجا نباید ASN های تکراری وجود داشته باشد.

یعنی Spine_DC1 و Spine_DC2 باید متفاوت باشند، درست مانند leafX_DC1 و leafY_DC2، که دقیقاً همان چیزی است که ما به آن نزدیک می شویم.

همانطور که احتمالاً می دانید، هک هایی وجود دارند که به شما امکان می دهند مسیرهایی با ASN های تکراری را با وجود مکانیسم جلوگیری از حلقه (مجاز ورود در سیسکو) بپذیرید. و حتی کاربردهای قانونی دارد. اما این یک شکاف بالقوه در پایداری شبکه است. و من شخصا چند بار در آن افتادم.

و اگر این فرصت را داشته باشیم که از چیزهای خطرناک استفاده نکنیم، از آن استفاده خواهیم کرد.

برگ ASN

ما یک ASN مجزا روی هر سوئیچ Leaf در سراسر شبکه خواهیم داشت.
ما این کار را به دلایل ذکر شده در بالا انجام می دهیم: AS-Path بدون حلقه، پیکربندی BGP بدون نشانک.

برای اینکه مسیرهای بین Leafs به راحتی عبور کنند، مسیر AS-Path باید به شکل زیر باشد:
[leafX_ASN, spine_ASN, leafY_ASN]
جایی که leafX_ASN و leafY_ASN متفاوت هستند.

این نیز برای وضعیت با اعلام یک حلقه بک VNF بین DCها لازم است:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

ما از یک ASN 4 بایتی استفاده می کنیم و آن را بر اساس ASN ستون فقرات و شماره سوئیچ برگ تولید می کنیم، یعنی مانند زیر: ستون فقرات_ASN.0000X.

این عکس با ASN است.

طرح IP

اساسا، ما باید آدرس هایی را برای اتصالات زیر اختصاص دهیم:

1. آدرس های شبکه را بین ToR و ماشین قرار دهید. آنها باید در کل شبکه منحصر به فرد باشند تا هر ماشینی بتواند با ماشین دیگری ارتباط برقرار کند. تناسب عالی 10/8. برای هر قفسه /26 با ذخیره وجود دارد. به ازای هر DC 19/ و هر منطقه 17/ را تخصیص می دهیم.
2. پیوند آدرس بین Leaf/Tor و Spine.

   من می خواهم آنها را به صورت الگوریتمی تخصیص بدهم، یعنی آنها را از روی نام دستگاه هایی که باید متصل شوند محاسبه کنم.

   بگذار... 169.254.0.0/16.
   برای مثال 169.254.00X.Y/31جایی که X - شماره ستون فقرات، Y — شبکه P2P /31.
   این به شما امکان می دهد تا 128 رک و تا 10 Spine را در DC راه اندازی کنید. آدرس های پیوند می توانند (و خواهند شد) از DC به DC تکرار شوند.

3. ما محل اتصال Spine-Edge-Leaf را در زیر شبکه ها سازماندهی می کنیم 169.254.10X.Y/31، جایی که دقیقاً همینطور است X - شماره ستون فقرات، Y — شبکه P2P /31.
4. آدرس‌ها را از Edge-Leaf به ستون فقرات MPLS پیوند دهید. در اینجا وضعیت تا حدودی متفاوت است - جایی که همه قطعات به یک پای متصل می شوند، بنابراین استفاده مجدد از همان آدرس ها کار نخواهد کرد - باید زیر شبکه رایگان بعدی را انتخاب کنید. بنابراین، بیایید به عنوان مبنا قرار دهیم 192.168.0.0/16 و ما رایگان ها را از آن جدا خواهیم کرد.
5. آدرس های Loopback ما کل محدوده را برای آنها خواهیم داد 172.16.0.0/12.
   • برگ - /25 در هر DC - همان 128 قفسه. ما به ازای هر منطقه 23/ را اختصاص خواهیم داد.
   • ستون فقرات - /28 در هر DC - تا 16 ستون فقرات. بیایید / 26 را به هر منطقه اختصاص دهیم.
   • Edge-Leaf - /29 در هر DC - تا 8 جعبه. ما به ازای هر منطقه 27/XNUMX را اختصاص خواهیم داد.

اگر محدوده های اختصاص داده شده کافی در DC نداشته باشیم (و وجود نخواهد داشت - ادعا می کنیم که هایپراسکیلزر هستیم)، به سادگی بلوک بعدی را انتخاب می کنیم.

این تصویر با آدرس IP است.

Loopbacks:

پیشوند
نقش دستگاه
منطقه
دی سی

172.16.0.0/23
لبه
 
 

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
گروه ادبی مارکسیستی

172.16.0.64/27
cn
 

172.16.0.64/29
SHA

172.16.0.72/29
هر دو

172.16.2.0/23
ستون فقرات
 
 

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
گروه ادبی مارکسیستی

172.16.2.128/26
cn
 

172.16.2.128/28
SHA

172.16.2.144/28
هر دو

172.16.8.0/21
برگ
 
 

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
گروه ادبی مارکسیستی

172.16.12.0/23
cn
 

172.16.12.0/25
SHA

172.16.12.128/25
هر دو

زیرانداز:

پیشوند
منطقه
دی سی

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
گروه ادبی مارکسیستی

10.1.0.0/17
cn
 

10.1.0.0/19
SHA

10.1.32.0/19
هر دو

لابا

دو فروشنده یک شبکه ADSM.

ارس + آریستا. اوبونتو حوای قدیمی خوب

میزان منابع سرور مجازی ما در میرانا هنوز محدود است، بنابراین برای تمرین از شبکه ای استفاده می کنیم که تا حد امکان ساده شده است.

دو مرکز داده: کازان و بارسلونا.

• هر کدام دو خار: عرعر و آریستا.
• یک چنبره (برگ) در هر کدام - Juniper و Arista، با یک میزبان متصل (بیایید یک IOL سبک وزن Cisco را برای این کار در نظر بگیریم).
• هر گره Edge-Leaf (در حال حاضر فقط Juniper).
• یک سوئیچ سیسکو برای کنترل همه آنها.
• علاوه بر جعبه های شبکه، یک ماشین کنترل مجازی نیز در حال اجرا است. در حال اجرا اوبونتو
  به همه دستگاه‌ها دسترسی دارد، سیستم‌های IPAM/DCIM، مجموعه‌ای از اسکریپت‌های پایتون، Ansible و هر چیز دیگری که ممکن است نیاز داشته باشیم را اجرا می‌کند.

پیکربندی کامل از تمام دستگاه های شبکه، که ما سعی خواهیم کرد با استفاده از اتوماسیون آنها را بازتولید کنیم.

نتیجه

آیا آن هم پذیرفته شده است؟ آیا باید در زیر هر مقاله یک نتیجه گیری کوتاه بنویسم؟

بنابراین ما انتخاب کردیم سه سطحی شبکه Kloz در داخل DC، از آنجایی که ما انتظار ترافیک زیادی از شرق به غرب را داریم و ECMP را می خواهیم.

شبکه به دو دسته فیزیکی (زیر لایه) و مجازی (پوشش) تقسیم شد. در همان زمان، روکش از میزبان شروع می شود - در نتیجه الزامات زیرانداز را ساده می کند.

ما BGP را به عنوان پروتکل مسیریابی برای شبکه های شبکه به دلیل مقیاس پذیری و انعطاف پذیری خط مشی آن انتخاب کردیم.

ما گره های جداگانه ای برای سازماندهی DCI - Edge-leaf خواهیم داشت.
ستون فقرات دارای OSPF+LDP خواهد بود.
DCI بر اساس MPLS L3VPN پیاده سازی خواهد شد.
برای پیوندهای P2P، آدرس های IP را به صورت الگوریتمی بر اساس نام دستگاه محاسبه می کنیم.
ما با توجه به نقش دستگاه ها و مکان آنها به ترتیب لوپ بک ها را اختصاص می دهیم.
پیشوندهای زیرین - فقط در سوئیچ های برگ به طور متوالی بر اساس مکان آنها.

بیایید فرض کنیم که در حال حاضر تجهیزات را هنوز نصب نکرده ایم.
بنابراین، گام های بعدی ما اضافه کردن آنها به سیستم ها (IPAM، موجودی)، سازماندهی دسترسی، ایجاد یک پیکربندی و استقرار آن خواهد بود.

در مقاله بعدی به نت باکس - موجودی و سیستم مدیریت فضای IP در DC خواهیم پرداخت.

متشکرم

• آندری گلازکوف با نام مستعار @glazgoo برای تصحیح و تصحیح
• Alexander Klimenko با نام مستعار @v00lk برای تصحیح و ویرایش
• آرتیوم چرنوبای برای KDPV

منبع: www.habr.com