وكلاء سحابة AWS Amazon: يعلمك تكوين مناطق متعددة قابلة للاستخدام AWS (مناطق متعددة قابلة للاستخدام) وهندسة التأهب التلقائي للكوارث عبر المناطق

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

في بنية السحابة ، يعد وضع كل البيض في سلة واحدة أكبر المحرمات. اعتقدت العديد من الفرق أن كل شيء سيكون على ما يرام مع AWS (Amazon Cloud Technology). ونتيجة لذلك ، تم قطع كابل الألياف الضوئية في منطقة قابلة للاستخدام (AZ) ، أو بسبب الطقس القاسي ، تم قطع المنطقة بأكملها (المنطقة) وانقطعت الخدمة على الفور. في هذا الوقت ، اكتشفت أن ما يسمى بـ "التوافر العالي" هو مزحة في مواجهة بنية بدون تكوين صحيح.

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

البنية الذهبية للإنترنت التي تأخذ في الاعتبار "Multi-AZ" و "منطقة Cross-Region"

.

المرحلة الأولى: مناطق متعددة قابلة للاستخدام في نفس المنطقة (Multi-AZ)-إطفاء حريق نقطة واحدة

"منطقة Available Zone" هي المفهوم الأساسي لـ AWS. منطقة (مثل ولاية أوريغون

Us-west-2

) يحتوي على العديد من المناطق المتاحة (مثل

Us-west-2a

،

Us-west-2b

) ، يتم عزلها ماديًا بين كل منطقة قابلة للاستخدام (مصدر طاقة مستقل ، وتبديد الحرارة ، وشبكة) ، ولكن هناك ربط ألياف فائق السرعة بينهما.

هدفنا الأول هو:

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

1. VPC والتصميم المكرر للشبكة الفرعية (Subnet)

هذا هو الأساس. لا يمكنك رمي جميع الخوادم في شبكة فرعية.

العملية القياسية: في VPC الخاص بك ، اختر منطقتين مختلفتين على الأقل من المناطق المتاحة (على سبيل المثال ، AZ-A AZ-B).

في كل منطقة قابلة للاستخدام ، يتم إنشاء شبكة فرعية عامة (موازن التحميل) وشبكة فرعية خاصة (خادم أعمال EC2 وقاعدة بيانات). بهذه الطريقة لديك 4 شبكات فرعية تشكل بشكل طبيعي دفاعًا متقاطعًا.

2. طبقة الحساب: موازنة تحميل ALB Auto Scaling (مجموعة تلسكوبية)

توقف عن ربط عنوان IP العام الخاص بـ EC2.

قم بإنشاء تطبيق Load Balancer (ALB) ، ثم قم بتثمينه على الشبكة الفرعية العامة لمنطقتين متاحتين. يتحول ALB إلى بوابة ، وبعد أن تأتي حركة المرور ، فإنه سيوزع الطلبات بالتساوي على الخادم في النهاية الخلفية.

إنشاء مجموعة Auto Scaling (ASG): بدء تشغيل القالب واختيار مرآة الأعمال الخاصة بك. التكوين الرئيسي: عند اختيار الشبكة ، حدد جميع الشبكات الفرعية الخاصة في المنطقتين المتاحتين. قم بتعيين السعة المطلوبة على 2 (مما يعني الحفاظ على جهازين يديران الأعمال في الأوقات العادية). المنطق الأساسي: ستكون AWS ذكية جدًا لبدء EC2 في كل من AZ-A AZ-B. إذا فشل AZ-A يومًا ما ، فإن الآلة معلقة

بعد كل شيء ، ستدرك ASG ذلك على الفور ، وتسحب تلقائيًا آلة جديدة في AZ-B صحية لتعويضها ، وتتعاون مع ALB لإزالة الجهاز الميت تلقائيًا ، وتكون العملية برمتها تلقائيًا.

3. طبقة البيانات: RDS قاعدة بيانات مفتاح واحد Multi-AZ

يمكن إعادة تشغيل الخادم إذا تم تعليق الخادم ، وإذا تم تعليق البيانات أو تعطلت ، فستفتح الشركة الطاولة مباشرة.

عند إنشاء AWS RDS (مثل MySQL) ، يوجد مفتاح ذهبي يسمى "Multi-AZ deployment" ، والذي يتم وضعه دون تردد.

القصة الداخلية للعملية: ستقوم AWS بإنشاء مكتبة رئيسية في المنطقة القابلة للاستخدام الرئيسية (AZ-A) ، وفي نفس الوقت إنشاء مكتبة نسخ متزامنة بالكامل في المنطقة الاحتياطية (AZ-B). ستتم مزامنة جميع البيانات المكتوبة في المكتبة الرئيسية إلى المكتبة الاحتياطية في الوقت الفعلي على مستوى الكتلة.

بمجرد حدوث كارثة في AZ-A ، ستبدأ RDS تلقائيًا في تجاوز الفشل (Failover) ، وترفع الاحتياطي إلى المكتبة الرئيسية ، وتحلل تلقائيًا اسم المجال المتصل بقاعدة البيانات (Endpoint) إلى المكتبة الرئيسية الجديدة. لا يحتاج الرمز الخلفي إلى تعديل أي سطر من عناوين IP ، وعادة ما يتم إحيائه تلقائيًا في غضون 30 ثانية.

المرحلة الثانية: الاستعداد للكوارث عبر المناطق-الدفاع عن العدو على بعد آلاف الأميال

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

التأهب التلقائي للكوارث عبر المناطق

.

نحن نفترض:

منطقة الإنتاج (Primary) في طوكيو (ap-northeast-1) ومنطقة الاستعداد للكوارث (DR) في سنغافورة (ap-southeast-1).

1-الاستنساخ الجغرافي للبيانات

لمزامنة بيانات طوكيو إلى سنغافورة في الوقت الفعلي.

مستوى قاعدة البيانات: في مكتبة RDS الرئيسية في طوكيو ، انقر فوق الإجراء-> "إنشاء نسخة مقروءة عبر المناطق" ، حدد المنطقة سنغافورة. ستستخدم AWS شبكتها الأساسية العالمية لنسخ بيانات طوكيو بشكل غير متزامن إلى سنغافورة.

مستوى تخزين الملفات: إذا كنت تستخدم دلو S3 لتخزين صور أو ملفات المستخدم ، فافتح وظيفة "CRR ، Cross Region Replication" في دلو التخزين ، واترك الملفات الموجودة في دلو طوكيو تطير تلقائيًا إلى دلو سنغافورة.

2. البنية التحتية في منطقة الاستعداد للكوارث (سنغافورة) باردة

في منطقة سنغافورة ، يتم أيضًا نشر مجموعة من مجموعات VPC و ALB و Auto Scaling.

خدعة لتوفير المال: من أجل توفير المال ، يمكنك ضبط "الحد الأدنى من السعة" و "السعة المتوقعة" لمجموعة Auto Scaling في سنغافورة على 0 (أو آلة منخفضة التكلفة لاختبار ضربات القلب). في هذا الوقت ، لا تتكبد سنغافورة مبلغًا كبيرًا من رسوم حساب EC2.

لا يوجد سوى رسوم تخزين رخيصة ورسوم مزامنة قاعدة البيانات.

3. قائد الروح: Route 53 التوجيه الذكي والتبديل الخاطئ

كيف يمكن تحويل حركة المستخدمين العالميين من طوكيو إلى سنغافورة بنقرة واحدة عند وقوع كارثة ؟ وهذا يتطلب خدمة DNS AWS --

الطريق 53

.

في Route 53 ، قم بتكوين "سياسة توجيه الفشل" لنطاق موقع الويب الخاص بك (مثل api.yourcompany.com).

قم بتكوين سجلين: السجل الرئيسي: موازن تحميل ALB يشير إلى طوكيو. السجل الثانوي: موازن تحميل ALB يشير إلى سنغافورة.

الفحص الصحي المرتبط (الفحص الصحي): قم بتجهيز ALB في طوكيو بفحص صحة Route 53 ، مما يسمح لـ AWS باكتشاف الصفحة الرئيسية لموقع طوكيو على الويب كل 10 ثوانٍ.

منطق تمرين الكارثة: إذا تم تفجير منطقة طوكيو بأكملها ، فإن الفحص الصحي لـ Route 53 سيضيء الضوء الأحمر بعد عدة إخفاقات متتالية. سيقوم على الفور بتنشيط آلية الانصهار وقطع تحليل اسم المجال مباشرة إلى ALB في سنغافورة.

المرحلة الثالثة: عملية القيامة الحية الحقيقية في حالة وقوع كارثة

بمجرد أن تفقد منطقة طوكيو الاتصال حقًا ، قام Route 53 بنقل حركة المرور تلقائيًا إلى سنغافورة. في هذا الوقت ، يحتاج موظفو التشغيل والصيانة فقط إلى تنفيذ الخطوتين الأخيرتين من إجراءات "رفع الحقوق" ، ويمكن للنظام استئناف الإنتاج تمامًا:

Promote: قم بتسجيل الدخول إلى وحدة التحكم AWS في سنغافورة ، وحدد النسخة للقراءة فقط التي تمت مزامنتها من طوكيو ، وانقر فوق "الترقية إلى قاعدة بيانات مستقلة". سيفصل الارتباط المتزامن مع طوكيو في غضون دقائق ويصبح مكتبة رئيسية قياسية قابلة للقراءة والكتابة.

إيقاظ طبقة الحوسبة بنقرة واحدة: قم بتغيير السعة المتوقعة لمجموعة Auto Scaling في سنغافورة من 0 إلى كمية الإنتاج التي تحتاجها (مثل 10). في غضون دقائق قليلة ، ظهر عدد كبير من خوادم EC2 في سنغافورة لقراءة قاعدة البيانات الجديدة التي تمت ترقيتها تلقائيًا.

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

المرحلة الرابعة: تكلفة الهياكل عالية المتاحة وتاريخ تجنب الدماء والدموع

رسوم التدفق عبر المناطق القابلة للاستخدام (Data Transfer Fee): تنص AWS على أن نقل البيانات عبر المناطق القابلة للاستخدام داخل نفس جهاز VPC هو رسوم (وإن كان رخيصًا جدًا). لذلك ، حاول أن تجعل EC2 الأمامي الخاص بك وخدمة الإنرانت الخلفية تتفاعل داخل نفس AZ. فقط عند إجراء مزامنة قاعدة البيانات ، أو مزامنة عقدة الكتلة الموزعة ، ثم عبور حركة مرور AZ.

المفاضلة بين RPO و RTO: RPO (في اللحظة التي يمكن فيها استعادة البيانات): لأن قاعدة البيانات عبر المناطق "مختلفة

"النسخ التدريجي" ، في اللحظة التي سقطت فيها طوكيو ، قد يكون هناك ثانية أو ثانيتين من البيانات قبل أن يتم نقلها إلى سنغافورة ، وسيبقى هذا الجزء من البيانات مؤقتًا. يجب أن تكون الشركات مستعدة لتسوية البيانات. RTO (كم من الوقت يستغرق التعافي): باستخدام بنية هذه المقالة ، يمكن للأتمتة والتدخل اليدوي الضئيل التحكم في RTO في غضون 5 إلى 15 دقيقة.

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

الخلاصة

لا يعتمد فشل نقطة الصفر على الحظ ، ولكن على التصميم المعماري العلمي.

يتم حل العديد من المناطق المتاحة في نفس المنطقة "عالية الاستخدام (HA)" لضمان عدم فقدان الاتصال اليومي ؛ الحل التلقائي للكوارث عبر المناطق هو "التعافي من الكوارث (DR)" ، مما يضمن أن الشركة يمكن أن تعيش في الحالات القصوى.

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