في أول مقالتين ، طرحت مسألة الأتمتة ورسمت إطارها ، وفي الثانية قمت باستكشاف الوضع في الشبكة الافتراضية ، كطريقة أولى لأتمتة تكوين الخدمات.
والآن حان الوقت لرسم مخطط شبكة فعلي.

إذا لم تكن على مسافة قصيرة مع جهاز شبكات مركز البيانات ، فأنا أوصي بشدة بالبدء بمقال عنهم .

كل القضايا:

يجب أن تكون الممارسات الموضحة في هذه السلسلة قابلة للتطبيق على شبكة من أي نوع ، بأي مقياس ، مع أي مجموعة متنوعة من البائعين (لا). ومع ذلك ، لا يمكن وصف مثال عالمي لتطبيق هذه الأساليب. لذلك ، سأركز على الهندسة المعمارية الحديثة لشبكة DC: Klose Factory .
سوف DCI القيام به على MPLS L3VPN.

تعمل شبكة Overlay من المضيف أعلى الشبكة الفعلية (يمكن أن تكون OpenStack VXLAN أو Tungsten Fabric أو أي شيء آخر لا يتطلب سوى اتصال IP الأساسي من الشبكة).

في هذه الحالة ، لدينا سيناريو بسيط نسبيًا للأتمتة ، لأن لدينا الكثير من المعدات التي تم تكوينها بنفس الطريقة.

سنختار العاصمة الكروية في فراغ:

نسخة واحدة من التصميم في كل مكان.
اثنين من البائعين تشكيل طائرتين من الشبكة.
أحد DC يشبه الآخر مثل قطرتين من الماء.

محتوى

طوبولوجيا البدنية
التوجيه
خطة IP
ابا
استنتاج
روابط مفيدة

دع موفر خدمة LAN_DC الخاص بنا ، على سبيل المثال ، يستضيف مقاطع فيديو تدريبية حول البقاء في المصاعد المعلقة.

في المدن الكبرى ، هذا شائع بشكل كبير ، لذلك هناك الكثير من الآلات المادية.

أولاً ، سأصف الشبكة تقريبًا كما أرغب في رؤيتها. وبعد ذلك سأبسطه للمختبر.

طوبولوجيا البدنية

مواقع

سيكون لشبكة LAN_DC 6 وحدات:

روسيا (روسيا):
- موسكو ( مسك )
- كازان ( kzn )
اسبانيا ( SP ):
- برشلونة (قبل الميلاد )
- ملقة (ملغ)
الصين ( CN ):
- شنغهاي ( شا )
- شيان ( سيا )

داخل العاصمة (داخل العاصمة)

في جميع البلدان النامية ، شبكات اتصال داخلية متطابقة تعتمد على طوبولوجيا Clos.
أي نوع من الشبكات كلوزه ولماذا هم في مقال منفصل.

في كل العاصمة هناك 10 رفوف مع السيارات ، سيتم ترقيمها على أنها A ، B ، C وهلم جرا.

كل رف لديه 30 سيارة. لن تهمنا.

أيضًا ، يوجد في كل حامل مفتاح يتم توصيل جميع الآلات به - هذا هو مفتاح Top of the Rack - ToR أو آخر فيما يتعلق بمصنع Klose ، سوف نسميها Leaf .

المخطط العام للمصنع.

سوف نطلق عليها اسم XXX -leaf Y ، حيث XXX هو اختصار DC المكون من ثلاثة أحرف ، و Y هو الرقم التسلسلي. على سبيل المثال ، kzn-leaf11 .

في المقالات ، أسمح لنفسي باستخدام مصطلحات Leaf and ToR بشكل تافه للغاية ، كمرادفات. ومع ذلك ، يجب على المرء أن يتذكر أن هذا ليس كذلك.
ToR هو مفتاح مثبت على الحامل تتصل به الأجهزة.
Leaf هو دور الجهاز في شبكة فعلية أو تبديل المستوى الأول من حيث طوبولوجيا Clos.
وهذا هو ، ورقة!
لذلك يمكن أن تكون ورقة التبديل EndofRaw ، على سبيل المثال.
ومع ذلك ، في إطار هذه المقالة ، سنشير إليها على أنها مرادفات.

يرتبط كل مفتاح ToR بدوره بأربعة مفاتيح تجميع أولية - العمود الفقري . تحت Spine'y تخصيص رف واحد في العاصمة. سنسميها بنفس الطريقة: XXX- spine Y.

في نفس الحامل ، سيكون هناك معدات للشبكات للاتصال بين أجهزة التوجيه DC - 2 مع MPLS على متن الطائرة. ولكن إلى حد كبير - هذه هي نفس الشروط المرجعية. أي أنه من وجهة نظر محولات العمود الفقري ، لا يهم ما إذا كانت هناك ToR المعتادة مع الأجهزة المتصلة أو جهاز توجيه لـ DCI - شيء لعنة واحدة.

وتسمى هذه الشروط الخاصة الحافة ورقة . سوف ندعو لهم XXX- حافة Y.

سيبدو مثل هذا.

في الرسم البياني أعلاه الحافة وورقة أنا حقا وضعت على نفس المستوى. لقد علمتنا الشبكات الكلاسيكية من ثلاثة مستويات أن ننظر إلى الوصلة الصاعدة (المصطلح موجود بالفعل من هنا) ، كوصلات صاعدة. وهنا يتبين أن "الوصلة الصاعدة" لـ DCI تتراجع ، الأمر الذي يكسر إلى حد ما المنطق المعتاد. في حالة الشبكات الكبيرة ، عندما يتم تقسيم مراكز البيانات إلى وحدات أصغر - POD (نقطة التسليم) ، يتم تخصيص Edge-POD منفصل لـ DCI والوصول إلى الشبكات الخارجية.

من أجل الراحة ، في المستقبل ، ما زلت أرسم على Edge على Spine ، بينما نضع في اعتبارنا أنه لا توجد ذكاء حول العمود الفقري والاختلافات عند العمل مع أوراق عادية و Leaf-leaf (على الرغم من أنه قد يكون هناك فروق دقيقة ، ولكن بشكل عام إنه كذلك).

تخطيط المصنع مع أوراق الحافة.

تشكل أوراق Trinity و Spine و Edge شبكة أو مصنع Underlay.

إن مهمة مصنع الشبكة (اقرأ Underlay) ، كما حددناها بالفعل في العدد السابق ، مهمة بسيطة للغاية - لتوفير اتصال IP بين الأجهزة داخل نفس العاصمة وبينها.
هذا هو السبب في أن الشبكة تسمى المصنع ، مثل ، على سبيل المثال ، مصنع التبديل داخل صناديق الشبكة النمطية ، والتي يمكن العثور عليها بمزيد من التفصيل في SDSM14 .

بشكل عام ، يطلق على هذا الهيكل اسم المصنع ، لأن النسيج في الترجمة هو نسيج. ومن الصعب عدم الموافقة:

مصنع تماما L3. لا شبكات محلية ظاهرية ، أو بث إذاعي - فهذه مبررات رائعة في LAN_DC ، ويمكنها كتابة التطبيقات التي تعيش في نموذج L3 ، ولا تتطلب الأجهزة الظاهرية الترحيل المباشر مع حفظ عنوان IP.

ومرة أخرى: الجواب على السؤال لماذا المصنع ولماذا L3 - في مقال منفصل.

DCI - ربط مركز البيانات (Inter-DC)

سيتم تنظيم DCI باستخدام Edge-Leaf ، أي أنها نقطة خروجنا إلى الطريق السريع.
للبساطة ، نحن نفترض أن البلدان النامية متصلة بواسطة روابط مباشرة.
نستبعد الاتصال الخارجي من الاعتبار.

أدرك أنه في كل مرة أقوم بإزالة أحد المكونات ، أقوم بتبسيط الشبكة بشكل كبير. ومع أتمتة شبكتنا المجردة ، سيكون كل شيء على ما يرام ، لكن العكازات ستظهر على الشبكة الحقيقية.
هذا هو الحال. ومع ذلك ، فإن الهدف من هذه السلسلة هو التفكير والعمل على المناهج ، وليس حل المشاكل التخيلية بطوليًا.

على Edge-Leafs ، يتم وضع الطبقة السفلية في VPN ويتم إرسالها عبر العمود الفقري MPLS (نفس الرابط المباشر).

هنا هو مثل مخطط المستوى الأعلى.

التوجيه

للتوجيه داخل العاصمة ، سوف نستخدم BGP.
على OSPF + LDP MPLS الجذع
بالنسبة لـ DCI ، أي أن تنظيم الاتصال على الجانب السفلي هو BGP L3VPN عبر MPLS.

مخطط التوجيه العام

لا يوجد OSPF و ISIS في المصنع (بروتوكول التوجيه محظور في الاتحاد الروسي).

وهذا يعني أنه لن يكون هناك اكتشاف تلقائي وحسابات أقصر للمسارات - فقط يدوي (في الواقع تلقائي - نحن هنا حول الأتمتة) لإعداد البروتوكول والجوار والسياسات.

مخطط توجيه BGP داخل العاصمة

لماذا bgp؟

يوجد RFC بالكامل باسم Facebook و Arista حول هذا الموضوع ، والذي يوضح كيفية إنشاء شبكات كبيرة جدًا من مراكز البيانات باستخدام BGP. يقرأ تقريبا مثل الفن ، نوصي بشدة لأمسية قاتمة.

ويخصص قسم كامل في مقالي لهذا الغرض. أين سأرسل لك ؟

ولكن ، باختصار ، لا يوجد IGP مناسب لشبكات مراكز البيانات الكبيرة ، حيث يتم حساب الآلاف من أجهزة الشبكة.

بالإضافة إلى ذلك ، يتيح لك استخدام BGP في كل مكان عدم الرش على دعم العديد من البروتوكولات المختلفة والتزامن بينهما.

جنبًا إلى جنب ، في مصنعنا ، الذي بدرجة كبيرة من الاحتمال لن ينمو بسرعة ، فإن OSPF سيكون كافياً للعيون. هذه هي في الواقع مشاكل megascalers وجبابرة سحابة. ولكن دعنا نتخيل فقط بعض المشكلات التي نحتاجها ، وسوف نستخدم BGP ، كما تم توريث بيتر لابوخوف.

سياسات التوجيه

على رموز التبديل Leaf ، نستورد إلى بادئات BGP من واجهات Underlay مع الشبكات.
سنحصل على جلسة BGP بين كل زوج من أوراق Leaf-Spine حيث سيتم الإعلان عن بادئات Underlay هذه على شبكة من البرك.

داخل مركز بيانات واحد ، سنقوم بتوزيع التفاصيل التي تم استيرادها إلى ToRe. في Edge-Leafs ، سنقوم بتجميعها وإعلانها في وحدات تحكم عن بُعد عن بُعد ونخفضها إلى ToRs. بمعنى أن كل ToR سيعرف بالضبط كيفية الوصول إلى ToR آخر في نفس العاصمة وأين هي نقطة الدخول للوصول إلى ToR في DC أخرى.

في DCI ، سيتم نقل المسارات كـ VPNv4. للقيام بذلك ، على Edge-Leaf ، سيتم وضع الواجهة الخاصة بالمصنع في VRF ، دعنا نسميها في الوقت الحالي ، وسوف يرتفع الحي مع Spine on the Edge-Leaf داخل VRF ، وبين Edge-Leafs في عائلة VPNv4.

وسنحظر أيضًا إعادة الإعلان عن الطرق المستلمة من العمود الفقري ، وإعادتها إليها.

على الأوراق والعمود الفقري ، لن نقوم باستيراد الاسترجاع. نحن في حاجة إليها فقط لتحديد معرف جهاز التوجيه.

لكن على Edge-Leafs ، نستوردها إلى Global BGP. بين عناوين Loopback ، ستقوم Edge Leafs بإنشاء جلسة BGP في عائلة IPv4 VPN مع بعضها البعض.

بين الأجهزة EDGE ، سيكون لدينا العمود الفقري OSPF + LDP. كل ذلك في منطقة واحدة. التكوين بسيط للغاية.

هذه صورة للتوجيه.

BGP ASN

حافة ورقة ASN

على Edge-Leafs ، سيكون هناك ASN واحد في جميع البلدان النامية. من المهم أن يكون هناك iBGP بين Edge-Leafs ، وأننا لا نواجه الفروق الدقيقة في eBGP. فليكن 65535. في الواقع ، يمكن أن يكون رقم AS عام.

العمود الفقري ASN

في Spine ، سيكون لدينا ASN واحد لكل DC. لنبدأ من الرقم الأول من مجموعة AS الخاصة - 64512 ، 64513 وهكذا.

لماذا ASN على العاصمة؟

نحلل هذا السؤال إلى قسمين:

لماذا هي نفس ASNs على جميع أشواك العاصمة نفسها؟
لماذا تختلف في مختلف البلدان النامية؟

لماذا هي نفس ASNs على جميع أشواك العاصمة واحد

إليك ما سيبدو عليه مسار AS-Path Anderlay على Edge-Leaf:
[leafX_ASN, spine_ASN , edge_ASN]
إذا حاولت الإعلان عنها مرة أخرى إلى Spine ، فسوف تسقطها لأن AS (Spine_AS) موجودة بالفعل في القائمة.

ومع ذلك ، نحن داخل العاصمة نشعر بالرضا التام لأن طرق Underlay التي صعدت إلى Edge لن تكون قادرة على النزول. يجب أن تحدث جميع الاتصالات بين المضيفين داخل العاصمة داخل مستوى العمود الفقري.

في الوقت نفسه ، ستصل الطرق المجمعة لوحدات تحكم المجال الأخرى في أي حال بحرية إلى ToRs - في AS-Path سيكون هناك ASN 65535 فقط - رقم AS Edge-Leafs ، لأنه تم إنشاءها عليها.

لماذا تختلف في العاصمة المختلفة

من الناحية النظرية ، قد نحتاج إلى سحب Loopbacks وبعض الأجهزة الظاهرية للخدمة بين وحدات تحكم المجال DC.

على سبيل المثال ، على مضيف ، سنقوم بتشغيل Route Reflector أو نفس VNGW (بوابة الشبكة الافتراضية) ، والتي سيتم قفلها بواسطة ToR عبر BGP وسوف نعلن عن استرجاعها ، والذي يجب أن يكون متاحًا من جميع البلدان النامية.

لذلك هنا هو ما سوف يبدو عليه AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN , edge_ASN, spine_DC2_ASN , leafY_DC2_ASN]

وهنا لا ينبغي أن يكون هناك ASNs مكررة في أي مكان.

وهذا يعني أن Spine_DC1 و Spine_DC2 يجب أن يكونا مختلفين ، تمامًا مثل leafX_DC1 و leafY_DC2 ، وهو ما نقترب منه تمامًا.

كما تعلم ربما ، هناك اختراقات تسمح لك بقبول طرق مع تكرار ASNs على الرغم من آلية منع استرجاع Cisco. ولها حتى الاستخدامات المشروعة تماما. لكن هذا اختراق محتمل في مرونة الشبكة. وأنا شخصيا سقطت فيه عدة مرات.

وإذا كانت لدينا الفرصة لعدم استخدام الأشياء الخطرة ، فسنستخدمها.

ورقة 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 بايتات وننشئها استنادًا إلى رقم Spn الخاص بـ ASN و Leaf-switch ، وبالتحديد مثل هذا: Spine_ASN.0000X .

هنا صورة مع ASN.

خطة IP

في الأساس ، نحتاج إلى تخصيص عناوين للاتصالات التالية:

عناوين الشبكة الأساسية بين ToR والجهاز. يجب أن تكون فريدة عبر الشبكة حتى يتمكن أي جهاز من التواصل مع أي جهاز آخر. عظيم ل 10/8 . لكل رف / 26 بهامش. سنخصص / 19 لـ DC و / 17 للمنطقة.
ربط العناوين بين ليف / تور والعمود الفقري.

أرغب في تعيينها حسابيًا ، أي حساب من أسماء الأجهزة التي تحتاج إلى الاتصال.

فليكن ... 169.254.0.0/16.
وهي 169.254.00X.Y / 31 ، حيث X هي رقم العمود الفقري ، Y هي شبكة P2P / 31.
سيتيح لك ذلك تشغيل ما يصل إلى 128 رفًا ، وما يصل إلى 10 رفوف في العاصمة. يمكن (وسوف) تتكرر عناوين الارتباط من العاصمة إلى العاصمة.
ننظم مفصل Spine - Edge-Leaf على الشبكات الفرعية 169.254.10X.Y / 31 ، حيث X هي بنفس طريقة رقم Spine ، Y هي شبكة P2P / 31.
ربط العناوين من Edge-Leaf إلى العمود الفقري MPLS. هنا يختلف الوضع إلى حد ما - مكان توصيل جميع القطع بفطيرة واحدة ، لذلك لن تعمل إعادة استخدام نفس العناوين - تحتاج إلى تحديد الشبكة الفرعية المجانية التالية. لذلك ، سوف نأخذ 192.168.0.0/16 كأساس وسنعمل على التخلص منها.
عناوين الاسترجاع. منحهم مجموعة كاملة 172.16.0.0/12 .
- ورقة - في / 25 لكل العاصمة - نفس 128 رفوف. تخصيص بحلول / 23 إلى المنطقة.
- العمود الفقري - بحلول / 28 في العاصمة - ما يصل إلى 16 العمود الفقري. تخصيص بحلول / 26 إلى المنطقة.
- Edge-Leaf - by / 29 on DC - حتى 8 صناديق. تخصيص بحلول / 27 إلى المنطقة.

إذا لم يكن لدينا في العاصمة ما يكفي من النطاقات المحددة (لكنها لن تكون هناك - نتظاهر بأنها skeylerostvo شديدة) ، ما عليك سوى اختيار الكتلة التالية.

هنا صورة مع عنونة IP.

Loopback'i:

بادئة	دور الجهاز	منطقة	DC
172.16.0.0/23	حافة
172.16.0.0/27		رو
172.16.0.0/29			MSK
172.16.0.8/29			KZN
172.16.0.32/27		س
172.16.0.32/29			BCN
172.16.0.40/29			MLG
172.16.0.64/27		CN
172.16.0.64/29			شاء
172.16.0.72/29			سيا
172.16.2.0/23	العمود الفقري
172.16.2.0/26		رو
172.16.2.0/28			MSK
172.16.2.16/28			KZN
172.16.2.64/26		س
172.16.2.64/28			BCN
172.16.2.80/28			MLG
172.16.2.128/26		CN
172.16.2.128/28			شاء
172.16.2.144/28			سيا
172.16.8.0/21	ورق
172.16.8.0/23		رو
172.16.8.0/25			MSK
172.16.8.128/25			KZN
172.16.10.0/23		س
172.16.10.0/25			BCN
172.16.10.128/25			MLG
172.16.12.0/23		CN
172.16.12.0/25			شاء
172.16.12.128/25			سيا

الأساس الذي تقوم عليه:

بادئة	منطقة	DC
10.0.0.0/17	رو
10.0.0.0/19		MSK
10.0.32.0/19		KZN
10.0.128.0/17	س
10.0.128.0/19		BCN
10.0.160.0/19		MLG
10.1.0.0/17	CN
10.1.0.0/19		شاء
10.1.32.0/19		سيا

ابا

اثنين من البائعين. شبكة واحدة. أبوظبي للأوراق المالية.

العرعر + أريستا. أوبونتو. حواء قديم جيد.

لا يزال حجم الموارد على موقعنا الافتراضي في ميران محدودًا ، لذلك من أجل الممارسة ، سنستخدم مثل هذه الشبكة المبسطة إلى الحد الأقصى.

مركزين للبيانات: كازان وبرشلونة.

عمودان في كل منهما: جونيبر وأريستا.
torus واحد (Leaf) في كل - Juniper و Arista ، مع مضيف واحد متصل (لنأخذ Cisco IOL خفيفة الوزن لهذا).
عقدة Edge-Leaf واحدة (فقط العرعر حتى الآن).
واحد سيسكو التبديل للحكم عليهم جميعا.
بالإضافة إلى صناديق الشبكة ، تم إطلاق جهاز إدارة افتراضي. تشغيل أوبونتو.
لديه إمكانية الوصول إلى جميع الأجهزة وأنظمة IPAM / DCIM ومجموعة من البرامج النصية بيثون ، ansible وأي شيء آخر قد نحتاجه سيكون الغزل.

التكوين الكامل لجميع أجهزة الشبكة التي سنحاول إعادة إنتاجها باستخدام التشغيل الآلي.

استنتاج

مقبول أيضا؟ تحت كل مادة لجعل خاتمة قصيرة؟

لذلك ، اخترنا شبكة Klose ثلاثية المستويات داخل العاصمة ، لأننا نتوقع الكثير من حركة المرور بين الشرق والغرب ونريد ECMP.

قمنا بتقسيم الشبكة إلى شبكة فعلية (طبقة أساسية) وظاهرية (تراكب). في هذه الحالة ، يبدأ التراكب من المضيف - وبالتالي تبسيط متطلبات الأساس الذي تقوم عليه.

اخترنا BGP كبروتوكول توجيه للشبكات غير المنقولة لقابلية التوسع والمرونة للسياسات.

سيكون لدينا عقد منفصلة لتنظيم DCI - Edge-leaf.
سيكون هناك OSPF + LDP على الجذع.
سيتم تنفيذ DCI على أساس MPLS L3VPN.
بالنسبة إلى روابط P2P ، سنقوم بحساب عناوين IP خوارزميًا استنادًا إلى أسماء الأجهزة.
سيتم تعيين Lupbacks بواسطة دور الأجهزة وموقعها بالتتابع.
البادئات الأساسية - فقط على مفاتيح الأوراق بالتتابع بناءً على موقعها.

لنفترض أننا لا نملك المعدات المثبتة الآن.
لذلك ، ستكون الخطوات التالية هي إدخالها في الأنظمة (IPAM ، المخزون) ، وتنظيم الوصول ، وإنشاء التكوين ونشره.

في المقالة التالية ، سوف نتعامل مع Netbox ونظام إدارة المخزون والمساحة IP في العاصمة.

شكرا

أندريه جلازكوف ويعرف أيضًا باسم @ glazgoo للتدقيق والمراجعة
ألكسندر كليمنكو الملقب @ v00lk لتصحيح التجارب المطبعية والتحرير
أرتيوم تشيرنوباي ل KDPV

أتمتة أصغر. الجزء الثاني. تصميم الشبكات