تمتلك شبكة Amazon Web Services 69 موقعًا حول العالم في 22 منطقة: الولايات المتحدة الأمريكية وأوروبا وآسيا وإفريقيا وأستراليا. يوجد في كل منطقة ما يصل إلى 8 مراكز بيانات - مراكز معالجة البيانات. يحتوي كل مركز بيانات على آلاف أو مئات الآلاف من الخوادم. تم بناء الشبكة بطريقة تؤخذ في الاعتبار كافة سيناريوهات انقطاع التيار غير المحتمل. على سبيل المثال ، يتم عزل جميع المناطق عن بعضها البعض ، وتباعد مناطق الوصول على بعد عدة كيلومترات. حتى إذا قمت بقطع الكبل ، فسوف يتحول النظام إلى قنوات النسخ الاحتياطي ، وستكون خسارة المعلومات بمثابة وحدات من حزم البيانات. حول المبادئ الأخرى التي بنيت عليها الشبكة وكيف يتم بناؤها ، سيخبر Vasily Pantyukhin.
بدأ
Vasily Pantyukhin كمسؤول عن يونكس في شركات .ru ، وأمضى 6 سنوات في الغدد الكبيرة لشركة Sun Microsystem ، وطالب لمدة 11 عامًا بمركزية البيانات في العالم في EMC. تطورت بشكل طبيعي إلى غيوم خاصة ، ثم أصبحت عامة. الآن ، كمهندس لخدمات Amazon Web Services ، تساعدك المشورة الفنية على العيش والنمو في سحابة AWS.
في الجزء السابق من ثلاثية أجهزة AWS ، قام Vasily بالبحث في جهاز الخوادم الفعلية وتوسيع نطاق قاعدة البيانات. Nitro-cards ، برنامج hypervisor المخصص المستند إلى KVM ، قاعدة بيانات Amazon Aurora - كل هذا في المقالة "
How AWS" cooks "services services". توسيع نطاق الخادم وقاعدة البيانات . " اقرأ لتغوص في السياق ، أو شاهد
مقطع فيديو للعرض التقديمي.
في هذا الجزء ، سوف نركز على توسيع نطاق الشبكة - أحد أكثر الأنظمة تعقيدًا في AWS. تطور من شبكة مسطحة إلى Virtual Private Cloud وجهازها ، وخدمات Blackfoot و HyperPlane الداخلية ، ومشكلة أحد الجيران الصاخبين ، وفي النهاية - نطاق الشبكة والعمود الفقري والكابلات المادية. حول كل هذا تحت الخفض.
إخلاء المسئولية: كل ما هو أسفل هو رأي فاسيلي الشخصي ، وقد لا يتطابق مع موقع Amazon Web Services.تحجيم الشبكة
تم إطلاق AWS Cloud في عام 2006. وكانت شبكته بدائية للغاية - مع بنية مسطحة. كان نطاق العناوين الخاصة مشتركًا بين جميع مستأجري السحابة. عند بدء تشغيل جهاز ظاهري جديد ، تلقيت عن طريق الخطأ عنوان IP متاحًا من هذا النطاق.
كان هذا النهج سهل التنفيذ ، ولكنه حد بشكل أساسي من استخدام السحابة. على وجه الخصوص ، كان من الصعب للغاية تطوير حلول هجينة تجمع بين الشبكات الخاصة على الأرض وفي AWS. كانت المشكلة الأكثر شيوعًا هي تقاطع نطاقات عناوين IP.
سحابة خاصة افتراضية
السحابة كانت في الطلب. حان الوقت للتفكير في قابلية التوسع وإمكانية استخدامه من قبل عشرات الملايين من المستأجرين. أصبحت شبكة مسطحة عقبة رئيسية. لذلك ، فكرنا في كيفية عزل المستخدمين عن بعضهم البعض على مستوى الشبكة حتى يتمكنوا من تحديد نطاقات IP بشكل مستقل.
ما الذي يتبادر إلى الذهن أولاً عند التفكير في عزل الشبكة؟ بالطبع
VLAN و
VRF هما التوجيه الظاهري وإعادة التوجيه .
لسوء الحظ ، هذا لم ينجح. معرّف شبكة محلية ظاهرية (VLAN) هو 12 بت فقط ، مما يعطينا 4096 قطعة معزولة فقط. حتى في أكبر المحولات ، يمكنك استخدام 1-2000 VRF بحد أقصى. يمنحنا الاستخدام المشترك لـ VRF و VLAN بضعة ملايين من الشبكات الفرعية. هذا بالتأكيد لا يكفي لعشرات الملايين من المستأجرين ، وكل واحد منهم يجب أن يكون قادرًا على استخدام عدة شبكات فرعية.
ومع ذلك ، لا يمكننا ببساطة شراء العدد المطلوب من الصناديق الكبيرة ، على سبيل المثال ، من Cisco أو Juniper. هناك سببان: إنه مكلف للغاية ، ونحن لا نريد أن نعتمد على سياسات التطوير والتصحيح الخاصة بهم.
هناك استنتاج واحد فقط - لطهي قرارك الخاص.
في عام 2009 ، أعلنا
VPC -
Virtual Private Cloud . الاسم قد ترسخت والآن العديد من مقدمي السحابة أيضا استخدامه.
VPC هي شبكة افتراضية للبرامج المحددة (
SDN ). قررنا عدم اختراع بروتوكولات خاصة على المستويين L2 و L3. تعمل الشبكة على معيار Ethernet و IP. للنقل عبر شبكة ، يتم تغليف حركة مرور الجهاز الظاهري في غلاف بروتوكول خاص بنا. يشير إلى المعرف الذي ينتمي إلى Vant Vant.
هذا يبدو سهلا. ومع ذلك ، فمن الضروري حل العديد من المشاكل الفنية الخطيرة. على سبيل المثال ، مكان وكيفية تخزين بيانات التعيين لعناوين 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 تعيش على خادم فعلي. يجب أن يتم تخزين المعلومات مؤقتًا فقط حول هذه VPCs. لا يزال نقل البيانات إلى أجهزة VPC الأخرى في التكوين "الافتراضي" غير مشروع. إذا تم استخدام وظيفة مثل نظير VPC ، يتم إضافة معلومات حول VPCs المقابلة في ذاكرة التخزين المؤقت.
مع نقل البيانات إلى VPC برزت.
بلاكفوت
ما الذي يجب فعله في الحالات التي تحتاج فيها حركة المرور إلى الخارج ، على سبيل المثال ، على الإنترنت أو عبر VPN على الأرض؟ هنا يساعدنا
Blackfoot ، الخدمة الداخلية لـ AWS. تم تصميمه من قبل فريق جنوب أفريقيا لدينا. لذلك ، تم تسمية الخدمة باسم البطريق الذي يعيش في جنوب إفريقيا.
يقوم برنامج Blackfoot بإلغاء حركة المرور ويقوم بما يحتاج إليه. يتم إرسال بيانات الإنترنت كما هي.
يتم فك البيانات ولفها مرة أخرى في غلاف IPsec عند استخدام VPN.
عند استخدام Direct Connect ، يتم تمييز حركة المرور وإرسالها إلى شبكة VLAN المقابلة.
الفائق
هذه هي خدمة التحكم في التدفق الداخلي. تتطلب العديد من خدمات الشبكة مراقبة
حالة دفق البيانات . على سبيل المثال ، عند استخدام NAT ، يجب أن يضمن التحكم في التدفق أن كل زوج من "IP: وجهة منفذ" لديه منفذ صادر فريد. في حالة موازن
NLB -
Network Load Balancer ، يجب توجيه دفق البيانات دائمًا إلى نفس الجهاز الظاهري الهدف. مجموعات الأمان عبارة عن جدار حماية فعال. يراقب حركة المرور الواردة ويفتح ضمنياً منافذ دفق الحزمة الصادرة.
في سحابة AWS ، متطلبات زمن انتقال الإرسال عالية للغاية. لذلك ،
تعتبر HyperPlane ضرورية لصحة الشبكة بالكامل.
بنيت Hyperplane على الأجهزة الافتراضية EC2. لا يوجد سحر هنا ، فقط الماكرة. الحيلة هي أنها أجهزة افتراضية مع ذاكرة الوصول العشوائي الكبيرة. المعاملات هي المعاملات وتنفذ حصرا في الذاكرة. هذا يسمح للتأخير عشرات فقط من microseconds. العمل مع قرص سيقتل كل الأداء.
Hyperplane هو نظام موزع من عدد كبير من آلات EC2. كل آلة افتراضية لديها عرض النطاق الترددي من 5 غيغابايت / ثانية. عبر الشبكة الإقليمية بالكامل ، ينتج عن ذلك تيرابايت برية من النطاق الترددي ويسمح لك بمعالجة
ملايين الاتصالات في الثانية .
HyperPlane يعمل فقط مع مؤشرات الترابط. تغليف حزمة VPC شفاف تمامًا بالنسبة إليه. لن تسمح مشكلة عدم الحصانة المحتملة في هذه الخدمة الداخلية باختراق عزل VPC. للسلامة ، المستويات أدناه هي المسؤولة.
جار صاخب
هناك أيضا
مشكلة الجار صاخبة . لنفترض أن لدينا 8 عقد. هذه العقد معالجة المواضيع لجميع المستخدمين سحابة. يبدو أن كل شيء على ما يرام ويجب توزيع الحمل بشكل متساوٍ على جميع العقد. العقد قوية للغاية ويصعب تحميلها.
لكننا نبني الهندسة المعمارية لدينا بناء على سيناريوهات غير مرجحة.
الاحتمال المنخفض لا يعني الاستحالة.
يمكننا أن نتخيل موقفًا يؤدي فيه مستخدم واحد أو أكثر إلى توليد الكثير من الحمل. تشارك جميع العقد HyperPlane في معالجة هذا الحمل ، ويمكن أن يشعر المستخدمون الآخرون بنوع من تدهور الأداء. هذا يدمر مفهوم السحابة ، حيث المستأجرين ليس لديهم وسيلة للتأثير على بعضهم البعض.
كيف يمكن حل مشكلة الجار الصاخب؟ أول ما يتبادر إلى الذهن هو التقسيم. لدينا 8 العقد تنقسم منطقيا إلى 4 قطع مع 2 العقد في كل منهما. الآن ، سيتم إعاقة جار مجاور من قبل ربع المستخدمين فقط ، ولكن أكثر من ذلك بكثير.
دعونا نفعل ذلك بشكل مختلف. يتم تخصيص كل مستخدم 3 نقاط فقط.
الحيلة هي تعيين العقد لمختلف المستخدمين بشكل عشوائي. في الصورة أدناه ، يتقاطع المستخدم الأزرق مع أحد المستخدمين الآخرين - الأخضر والبرتقالي.
مع 8 عقد و 3 مستخدمين ، يكون احتمال عبور جار صاخب مع أحد المستخدمين هو 54٪. بهذا الاحتمال سيؤثر المستخدم الأزرق على المستأجرين الآخرين. علاوة على ذلك ، فقط جزء من حموله. في مثالنا ، سيكون هذا التأثير على الأقل غير ملحوظ للجميع ، ولكن ثلث جميع المستخدمين فقط. هذه بالفعل نتيجة جيدة.
لنجعل الموقف أقرب إلى الواقع الحقيقي - خذ 100 عقدة و 5 مستخدمين في 5 عقد. في هذه الحالة ، تتقاطع أي من العقد مع احتمال 77 ٪.
في حالة حقيقية مع وجود عدد كبير من عقد HyperPlane والمستخدمين ، يكون التأثير المحتمل لجارة صاخبة على المستخدمين الآخرين ضئيلًا. وتسمى هذه الطريقة
خلط ورق اللعب . أنه يقلل من التأثير السلبي لفشل العقدة.
يتم إنشاء العديد من الخدمات على أساس HyperPlane: Network Load Balancer ، NAT Gateway ، Amazon EFS ، AWS PrivateLink ، AWS Transit Gateway.
مقياس الشبكة
الآن دعنا نتحدث عن حجم الشبكة نفسها. لشهر أكتوبر 2019 ، تقدم AWS خدماتها في
22 منطقة ، ومن المخطط لها 9
مناطق أخرى.
- تحتوي كل منطقة على العديد من مناطق التوفر. هناك 69 منهم في العالم.
- يتكون كل AZ من مراكز معالجة البيانات. لا يوجد أكثر من 8 منهم.
- يوجد في مركز البيانات عدد كبير من الخوادم ، بعضها يصل إلى 300000.
الآن كل هذا تم حسابه متوسطًا ، ومضاعفًا ، واحصل على شخصية رائعة تعرض
مقياس سحابة أمازون .
بين مناطق الوصول ومركز البيانات ، يتم وضع العديد من القنوات البصرية. في واحدة من أكبر مناطقنا ، تم تخصيص 388 قناة فقط للاتصال من الألف إلى الياء فيما بينها ومراكز الاتصال مع المناطق الأخرى (مراكز العبور). في المجموع ، وهذا يعطي جنون
5000 Tbit .
تم تصميم العمود الفقري AWS خصيصًا للسحابة وتحسينه للعمل به. نحن نبنيها على
100 جيجابايت / ثانية القنوات. نحن نسيطر عليها بشكل كامل ، باستثناء المناطق في الصين. لا تتم مشاركة حركة المرور مع الكثير من الشركات الأخرى.
بالطبع ، لسنا المزود السحابي الوحيد الذي يتمتع بشبكة أساسية خاصة. المزيد والمزيد من الشركات الكبيرة تسير بهذه الطريقة. وهذا ما أكده باحثون مستقلون ، على سبيل المثال ، من
Telegeography .
يوضح الرسم البياني أن حصة موفري المحتوى وموفري السحابة في تزايد. وبسبب هذا ، فإن نسبة حركة الإنترنت من مزودي العمود الفقري تتناقص باستمرار.
ساوضح لماذا يحدث هذا. في السابق ، كانت معظم خدمات الويب متاحة وتستهلك مباشرة من الإنترنت. توجد الآن المزيد والمزيد من الخوادم في السحابة ومتاحة من خلال
شبكة توزيع المحتوى CDN . للوصول إلى المورد ، ينتقل المستخدم عبر الإنترنت فقط إلى أقرب
نقطة CDN PoP -
Point of Presence . غالبا ما يكون في مكان ما في مكان قريب. ثم يترك الإنترنت العام ويطير عبر المحيط الأطلسي عبر العمود الفقري الخاص ، على سبيل المثال ، ويصل مباشرة إلى المورد.
أتساءل كيف سيتغير الإنترنت خلال 10 سنوات إذا استمر هذا الاتجاه؟
القنوات المادية
لم يتوصل العلماء بعد إلى كيفية زيادة سرعة الضوء في الكون ، لكنهم حققوا تطورات كبيرة في طرق نقله عبر الألياف الضوئية. نحن نستخدم حاليا 6912 كابلات الألياف. هذا يساعد على تحسين تكلفة التثبيت بشكل كبير.
في بعض المناطق ، يتعين علينا استخدام الكابلات الخاصة. على سبيل المثال ، في منطقة سيدني ، نستخدم الكابلات ذات الطلاء الخاص ضد النمل الأبيض.
لا أحد في مأمن من المشاكل وأحيانًا تتعرض قنواتنا للتلف. تُظهر الصورة الموجودة على اليمين الكابلات الضوئية في إحدى المناطق الأمريكية التي مزقها بناة. كنتيجة للحادث ، فقد 13 حزمة بيانات فقط ، وهو أمر مثير للدهشة. مرة أخرى - فقط 13! تحول النظام حرفيًا على الفور إلى قنوات احتياطية - يعمل النطاق.
راكضنا على بعض الخدمات والتقنيات السحابية من Amazon. آمل أن يكون لديك على الأقل فكرة عن حجم المهام التي يتعين على مهندسينا حلها. أنا شخصياً مهتم جدًا بهذا.
هذا هو الجزء الأخير من ثلاثية من Vasily Pantyukhin حول جهاز AWS. يصف الجزء الأول تحسين الخادم وتوسيع نطاق قاعدة البيانات ، بينما يصف الجزء الثاني وظائف الخادم وخادم الألعاب النارية.
في HighLoad ++ في نوفمبر ، ستشارك Vasily Pantyukhin تفاصيل جهاز Amazon الجديد. سيتحدث عن أسباب الفشل وتصميم الأنظمة الموزعة في أمازون. في 24 أكتوبر ، لا يزال بإمكانك حجز تذكرة بسعر جيد والدفع لاحقًا. نحن في انتظارك على HighLoad ++ ، تعال وتحدث!