يبلغ حجم شبكة Amazon Web Services 69 منطقة حول العالم في 22 منطقة: الولايات المتحدة الأمريكية وأوروبا وآسيا وأفريقيا وأستراليا. تحتوي كل منطقة على ما يصل إلى 8 مراكز بيانات - مراكز معالجة البيانات. يحتوي كل مركز بيانات على آلاف أو مئات الآلاف من الخوادم. تم تصميم الشبكة بطريقة تأخذ في الاعتبار جميع سيناريوهات الانقطاع غير المتوقعة. على سبيل المثال، يتم عزل جميع المناطق عن بعضها البعض، ويتم فصل مناطق الوصول على مسافات تصل إلى عدة كيلومترات. حتى إذا قمت بقطع الكابل، فسيتحول النظام إلى القنوات الاحتياطية، وسيصل فقدان المعلومات إلى عدد قليل من حزم البيانات. سيتحدث فاسيلي بانتيوخين عن المبادئ الأخرى التي بنيت عليها الشبكة وكيفية تنظيمها.
فاسيلي بانتيوخين بدأ كمدير Unix في شركات .ru، وعمل على أجهزة Sun Microsystem الكبيرة لمدة 6 سنوات، وبشر بعالم يتمحور حول البيانات لمدة 11 عامًا في EMC. تطورت بطبيعة الحال إلى سحابات خاصة، ثم انتقلت إلى سحابات عامة. والآن، باعتباره مهندسًا معماريًا لخدمات الويب في Amazon، فهو يقدم المشورة الفنية للمساعدة في العيش والتطوير في سحابة AWS.
في الجزء السابق من ثلاثية AWS، تعمق فاسيلي في تصميم الخوادم الفعلية وتوسيع قاعدة البيانات. بطاقات Nitro، وبرنامج Hypervisor المخصص القائم على KVM، وقاعدة بيانات Amazon Aurora - كل هذا موجود في المادة "" اقرأ للسياق أو شاهد كلمات.
سيركز هذا الجزء على توسيع نطاق الشبكة، وهو أحد الأنظمة الأكثر تعقيدًا في AWS. التطور من شبكة مسطحة إلى سحابة خاصة افتراضية وتصميمها، والخدمات الداخلية لـ Blackfoot وHyperPlane، ومشكلة الجار الصاخب، وفي النهاية - حجم الشبكة والعمود الفقري والكابلات المادية. عن كل هذا تحت الخفض.
إخلاء المسؤولية: كل ما هو مذكور أدناه هو رأي شخصي لفاسيلي وقد لا يتوافق مع موقف Amazon Web Services.
تحجيم الشبكة
تم إطلاق سحابة AWS في عام 2006. كانت شبكته بدائية للغاية - ذات هيكل مسطح. كان نطاق العناوين الخاصة مشتركًا بين جميع مستأجري السحابة. عند بدء تشغيل جهاز ظاهري جديد، فقد تلقيت عن طريق الخطأ عنوان IP متاحًا من هذا النطاق.
وكان هذا النهج سهل التنفيذ، ولكنه حد بشكل أساسي من استخدام السحابة. على وجه الخصوص، كان من الصعب جدًا تطوير حلول مختلطة تجمع بين الشبكات الخاصة الموجودة على الأرض وفي AWS. كانت المشكلة الأكثر شيوعًا هي تداخل نطاقات عناوين IP.
سحابة خاصة افتراضية
تبين أن السحابة مطلوبة. لقد حان الوقت للتفكير في قابلية التوسع وإمكانية استخدامه من قبل عشرات الملايين من المستأجرين. أصبحت الشبكة المسطحة عقبة رئيسية. لذلك، فكرنا في كيفية عزل المستخدمين عن بعضهم البعض على مستوى الشبكة حتى يتمكنوا من اختيار نطاقات IP بشكل مستقل.
ما هو أول ما يتبادر إلى ذهنك عندما تفكر في عزل الشبكة؟ بالتأكيد VLAN и VRF - التوجيه والتوجيه الظاهري.
لسوء الحظ، لم ينجح الأمر. يتكون معرف VLAN من 12 بت فقط، مما يمنحنا 4096 مقطعًا معزولًا فقط. حتى أكبر المفاتيح يمكنها استخدام ما يصل إلى 1-2 ألف VRFs كحد أقصى. إن استخدام VRF وVLAN معًا لا يمنحنا سوى بضعة ملايين من الشبكات الفرعية. وهذا بالتأكيد لا يكفي لعشرات الملايين من المستأجرين، الذين يجب أن يكون كل منهم قادرًا على استخدام شبكات فرعية متعددة.
نحن أيضًا لا نستطيع ببساطة شراء العدد المطلوب من الصناديق الكبيرة، على سبيل المثال، من Cisco أو Juniper. هناك سببان: أنها مكلفة للغاية، ونحن لا نريد أن نكون تحت رحمة سياسات التطوير والتصحيح الخاصة بهم.
هناك استنتاج واحد فقط - اصنع الحل الخاص بك.
في عام 2009 أعلنا VPC - سحابة خاصة افتراضية. تم تعليق الاسم والآن يستخدمه العديد من موفري الخدمات السحابية أيضًا.
VPC هي شبكة افتراضية SDN (الشبكة المعرفة بالبرمجيات). قررنا عدم اختراع بروتوكولات خاصة على المستويين L2 وL3. تعمل الشبكة على Ethernet وIP القياسيين. للإرسال عبر الشبكة، يتم تغليف حركة مرور الجهاز الظاهري في غلاف البروتوكول الخاص بنا. ويشير إلى المعرف الذي ينتمي إلى VPC الخاص بالمستأجر.
يبدو بسيطا. ومع ذلك، هناك العديد من التحديات التقنية الخطيرة التي يتعين التغلب عليها. على سبيل المثال، مكان وكيفية تخزين البيانات عند تعيين عناوين MAC/IP الافتراضية ومعرف VPC وMAC/IP الفعلي المقابل. على نطاق AWS، يعد هذا جدولًا ضخمًا يجب أن يعمل بأقل قدر من التأخير في الوصول. المسؤول عن هذا خدمة رسم الخرائط، والتي تنتشر في طبقة رقيقة في جميع أنحاء الشبكة.
في أجهزة الجيل الجديد، يتم تنفيذ التغليف بواسطة بطاقات Nitro على مستوى الأجهزة. في الحالات القديمة، يعتمد التغليف وإلغاء التغليف على البرامج.
دعونا معرفة كيف يعمل بشكل عام. لنبدأ بمستوى L2. لنفترض أن لدينا جهازًا افتراضيًا يحمل عنوان IP 10.0.0.2 على خادم فعلي 192.168.0.3. يرسل البيانات إلى الجهاز الظاهري 10.0.0.3، الذي يعيش على 192.168.1.4. يتم إنشاء طلب ARP وإرساله إلى بطاقة Nitro الخاصة بالشبكة. من أجل التبسيط، نفترض أن كلا الجهازين الظاهريين يعيشان في نفس VPC "الزرقاء".
تستبدل الخريطة عنوان المصدر بعنوانها الخاص وتعيد توجيه إطار ARP إلى خدمة التعيين.
تقوم خدمة التعيين بإرجاع المعلومات الضرورية للإرسال عبر شبكة L2 الفعلية.
تستبدل بطاقة Nitro في استجابة ARP عنوان MAC الموجود على الشبكة الفعلية بعنوان في VPC.
عند نقل البيانات، نقوم بتغليف MAC وIP المنطقيين في غلاف VPC. نقوم بنقل كل هذا عبر الشبكة الفعلية باستخدام بطاقات IP Nitro المصدر والوجهة المناسبة.
يقوم الجهاز الفعلي الذي سيتم توجيه الحزمة إليه بإجراء الفحص. يعد ذلك ضروريًا لمنع احتمالية انتحال العنوان. يرسل الجهاز طلبًا خاصًا إلى خدمة رسم الخرائط ويسأل: "من الجهاز الفعلي 192.168.0.3 تلقيت حزمة مخصصة لـ 10.0.0.3 في VPC الأزرق. هل هو شرعي؟
تتحقق خدمة التعيين من جدول تخصيص الموارد الخاص بها وتسمح للحزمة بالمرور أو ترفضها. في جميع الحالات الجديدة، يتم تضمين التحقق الإضافي في بطاقات Nitro. من المستحيل تجاوزه حتى من الناحية النظرية. ولذلك، لن ينجح انتحال الموارد الموجودة في VPC آخر.
بعد ذلك، يتم إرسال البيانات إلى الجهاز الظاهري الذي تم تخصيصه له.
تعمل خدمة التعيين أيضًا كموجه منطقي لنقل البيانات بين الأجهزة الافتراضية في شبكات فرعية مختلفة. كل شيء بسيط من الناحية المفاهيمية، ولن أخوض في التفاصيل.
اتضح أنه عند إرسال كل حزمة، تتحول الخوادم إلى خدمة التعيين. كيفية التعامل مع التأخير الحتمي؟ التخزين المؤقت، بالطبع.
الجميل هو أنك لست بحاجة إلى تخزين الجدول الضخم بالكامل مؤقتًا. يستضيف الخادم الفعلي أجهزة افتراضية من عدد صغير نسبيًا من VPCs. ما عليك سوى تخزين المعلومات مؤقتًا حول وحدات VPC هذه. لا يزال نقل البيانات إلى VPCs أخرى في التكوين "الافتراضي" غير قانوني. إذا تم استخدام وظيفة مثل VPC-peering، فسيتم أيضًا تحميل المعلومات حول VPCs المقابلة في ذاكرة التخزين المؤقت.
لقد قمنا بفرز نقل البيانات إلى VPC.
بلاكفوت
ما الذي يجب فعله في الحالات التي يلزم فيها نقل حركة المرور إلى الخارج، على سبيل المثال إلى الإنترنت أو عبر VPN إلى الأرض؟ يساعدنا هنا بلاكفوت — خدمة AWS الداخلية. تم تطويره من قبل فريقنا في جنوب أفريقيا. ولهذا السبب تم تسمية الخدمة على اسم بطريق يعيش في جنوب أفريقيا.
تقوم Blackfoot بتفكيك حركة المرور وتفعل ما هو مطلوب معها. يتم إرسال البيانات إلى الإنترنت كما هي.
يتم فك تغليف البيانات وإعادة تغليفها في IPsec عند استخدام VPN.
عند استخدام Direct Connect، يتم وضع علامة على حركة المرور وإرسالها إلى شبكة VLAN المناسبة.
هايبربلان
هذه خدمة التحكم في التدفق الداخلي. تتطلب العديد من خدمات الشبكة المراقبة حالات تدفق البيانات. على سبيل المثال، عند استخدام NAT، يجب أن يضمن التحكم في التدفق أن كل زوج من منافذ IP:destination له منفذ صادر فريد. في حالة الموازن NLB - موازن تحميل الشبكة، يجب دائمًا توجيه تدفق البيانات إلى نفس الجهاز الظاهري المستهدف. مجموعات الأمان هي جدار حماية ذو حالة. فهو يراقب حركة المرور الواردة ويفتح ضمنيًا المنافذ لتدفق الحزم الصادرة.
في سحابة AWS، تكون متطلبات زمن انتقال الإرسال مرتفعة للغاية. لهذا هايبربلان أمر بالغ الأهمية لأداء الشبكة بأكملها.
تم بناء Hyperplane على الأجهزة الافتراضية EC2. لا يوجد سحر هنا، فقط الماكرة. الحيلة هي أن هذه أجهزة افتراضية ذات ذاكرة وصول عشوائي كبيرة. العمليات عبارة عن معاملات ويتم تنفيذها حصريًا في الذاكرة. يتيح لك ذلك تحقيق تأخيرات تصل إلى عشرات الميكروثانية فقط. العمل مع القرص من شأنه أن يقتل كل الإنتاجية.
Hyperplane هو نظام موزع لعدد كبير من آلات EC2. يحتوي كل جهاز افتراضي على نطاق ترددي يبلغ 5 جيجابايت/ثانية. عبر الشبكة الإقليمية بأكملها، يوفر هذا تيرابايت من عرض النطاق الترددي المذهل ويسمح بالمعالجة ملايين الاتصالات في الثانية.
HyperPlane يعمل فقط مع التدفقات. تغليف حزم VPC شفاف تمامًا بالنسبة له. ستظل هناك ثغرة أمنية محتملة في هذه الخدمة الداخلية تمنع كسر عزل VPC. المستويات أدناه هي المسؤولة عن الأمن.
جار صاخب
لا تزال هناك مشكلة جار صاخب - جار صاخب. لنفترض أن لدينا 8 عقد. تعالج هذه العقد تدفقات جميع مستخدمي السحابة. يبدو أن كل شيء على ما يرام ويجب توزيع الحمل بالتساوي على جميع العقد. العقد قوية جدًا ومن الصعب زيادة التحميل عليها.
لكننا نبني بنيتنا بناءً على سيناريوهات غير محتملة.
الاحتمال المنخفض لا يعني المستحيل.
يمكننا أن نتخيل موقفًا يقوم فيه مستخدم واحد أو أكثر بتوليد حمل كبير جدًا. تشارك جميع عقد HyperPlane في معالجة هذا التحميل ومن المحتمل أن يواجه المستخدمون الآخرون نوعًا ما من نتائج الأداء. وهذا يكسر مفهوم السحابة، حيث لا يملك المستأجرون القدرة على التأثير على بعضهم البعض.
كيف تحل مشكلة الجار الصاخب؟ أول ما يتبادر إلى الذهن هو التقسيم. يتم تقسيم العقد الثمانية لدينا منطقيًا إلى 8 أجزاء مكونة من عقدتين لكل منهما. الآن سوف يزعج الجار الصاخب ربع المستخدمين فقط، لكنه سيزعجهم بشكل كبير.
دعونا نفعل الأشياء بشكل مختلف. سنخصص 3 عقد فقط لكل مستخدم.
الحيلة هي تعيين العقد بشكل عشوائي لمستخدمين مختلفين. في الصورة أدناه، يتقاطع المستخدم الأزرق مع العقد مع أحد المستخدمين الآخرين - الأخضر والبرتقالي.
مع 8 عقد و3 مستخدمين، فإن احتمال تقاطع جار صاخب مع أحد المستخدمين هو 54%. مع هذا الاحتمال، سيؤثر المستخدم الأزرق على المستأجرين الآخرين. وفي الوقت نفسه، فقط جزء من حمولتها. في مثالنا، سيكون هذا التأثير ملحوظا على الأقل ليس للجميع، ولكن ثلث جميع المستخدمين فقط. هذه بالفعل نتيجة جيدة.
عدد المستخدمين الذين سيتقاطعون
الاحتمال في المئة
0
18%
1
54%
2
26%
3
2%
دعونا نجعل الموقف أقرب إلى الواقع - لنأخذ 100 عقدة و5 مستخدمين لكل 5 عقد. في هذه الحالة، لن تتقاطع أي من العقد مع احتمال 77%.
عدد المستخدمين الذين سيتقاطعون
الاحتمال في المئة
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
في موقف حقيقي، مع وجود عدد كبير من عقد HyperPlane والمستخدمين، يكون التأثير المحتمل لجار صاخب على المستخدمين الآخرين ضئيلًا. هذه الطريقة تسمى خلط التقسيم - تقسيم خلط ورق اللعب. فهو يقلل من التأثير السلبي لفشل العقدة.
تم إنشاء العديد من الخدمات على أساس HyperPlane: Network Load Balancer، وNAT Gateway، وAmazon EFS، وAWS PrivateLink، وAWS Transit Gateway.
مقياس الشبكة
الآن دعونا نتحدث عن حجم الشبكة نفسها. في أكتوبر 2019، تقدم AWS خدماتها في 22 منطقة، ويتم التخطيط لـ 9 آخرين.
- تحتوي كل منطقة على العديد من مناطق توافر الخدمات. هناك 69 منهم في جميع أنحاء العالم.
- تتكون كل منطقة توافر خدمات من مراكز معالجة البيانات. لا يوجد أكثر من 8 منهم في المجموع.
- يضم مركز البيانات عددًا كبيرًا من الخوادم، بعضها يصل عدده إلى 300.
الآن دعونا نحسب متوسط كل هذا ونضربه ونحصل على رقم مثير للإعجاب ينعكس مقياس سحابة الأمازون.
توجد العديد من الروابط الضوئية بين مناطق توافر الخدمات ومركز البيانات. في واحدة من أكبر مناطقنا، تم وضع 388 قناة فقط للاتصال من الألف إلى الياء بين بعضها البعض ومراكز الاتصال مع المناطق الأخرى (مراكز العبور). في المجمل هذا يعطي الجنون 5000 تيرابايت.
تم تصميم Backbone AWS خصيصًا للسحابة وتحسينها. نحن نبنيها على القنوات 100 جيجا بايت / ثانية. نحن نسيطر عليها بشكل كامل، باستثناء مناطق في الصين. لا تتم مشاركة حركة المرور مع الكثير من الشركات الأخرى.
بالطبع، نحن لسنا المزود السحابي الوحيد الذي يتمتع بشبكة أساسية خاصة. المزيد والمزيد من الشركات الكبرى تتبع هذا المسار. وهذا ما يؤكده باحثون مستقلون، على سبيل المثال من .
يوضح الرسم البياني أن حصة موفري المحتوى وموفري الخدمات السحابية آخذة في النمو. ولهذا السبب، فإن حصة حركة مرور الإنترنت لمقدمي الخدمات الأساسية تتناقص باستمرار.
سأشرح لماذا يحدث هذا. في السابق، كان يمكن الوصول إلى معظم خدمات الويب واستهلاكها مباشرة من الإنترنت. في الوقت الحاضر، يوجد المزيد والمزيد من الخوادم في السحابة ويمكن الوصول إليها عبرها CDN - شبكة توزيع المحتوى. للوصول إلى أحد الموارد، ينتقل المستخدم عبر الإنترنت فقط إلى أقرب CDN PoP - نقطة الوصول. في أغلب الأحيان يكون في مكان قريب. ثم تترك شبكة الإنترنت العامة وتطير عبر عمود فقري خاص عبر المحيط الأطلسي، على سبيل المثال، وتصل مباشرة إلى المورد.
وأتساءل كيف سيتغير الإنترنت خلال 10 سنوات إذا استمر هذا الاتجاه؟
القنوات المادية
ولم يتوصل العلماء بعد إلى كيفية زيادة سرعة الضوء في الكون، لكنهم أحرزوا تقدما كبيرا في طرق نقله عبر الألياف الضوئية. نستخدم حاليًا 6912 كابل ألياف. وهذا يساعد على تحسين تكلفة تركيبها بشكل كبير.
في بعض المناطق يتعين علينا استخدام كابلات خاصة. على سبيل المثال، في منطقة سيدني نستخدم كابلات ذات طلاء خاص ضد النمل الأبيض.
لا أحد في مأمن من المشاكل وأحيانا تتضرر قنواتنا. الصورة على اليمين تظهر الكابلات الضوئية في إحدى المناطق الأمريكية والتي مزقها عمال البناء. ونتيجة للحادث، فقدت 13 حزمة بيانات فقط، وهو أمر مثير للدهشة. مرة أخرى - 13 فقط! تحول النظام حرفيًا على الفور إلى القنوات الاحتياطية - المقياس يعمل.
لقد بحثنا في بعض الخدمات والتقنيات السحابية الخاصة بأمازون. آمل أن يكون لديك على الأقل فكرة عن حجم المهام التي يتعين على مهندسينا حلها. شخصيا، أجد هذا مثيرا للغاية.
هذا هو الجزء الأخير من ثلاثية فاسيلي بانتيوخين حول جهاز AWS. في تصف الأجزاء تحسين الخادم وتوسيع نطاق قاعدة البيانات، وفي - وظائف بدون خادم والمفرقعات النارية.
في في نوفمبر، سيشارك فاسيلي بانتيوخين تفاصيل جديدة عن جهاز أمازون. هو حول أسباب الفشل وتصميم الأنظمة الموزعة في أمازون. 24 أكتوبر لا يزال ممكنا تذكرة بسعر جيد، والدفع في وقت لاحق. نحن في انتظارك في HighLoad++، تعال ودعنا نتحدث!
المصدر: www.habr.com