تصميم معماري عالي التوافر لمحطة Amazon Cloud International: القدرة على تحمل الكوارث عبر المناطق المتاحة (AZ) وموازنة تحميل ELB
في عصر الحوسبة السحابية ، فإن كلمة "High Availability (HA)" هي كلمة يتحدث عنها العديد من المهندسين المعماريين تقريبًا. يعتقد الكثير من الناس أنه طالما تم نقل النظام إلى Amazon Cloud (AWS) ، تم شراء EC2 ، وتم تجهيزه بموازنة التحميل ، فسيكون متاحًا بشكل طبيعي.
ومع ذلك ، فإن بيئة الإنتاج الحقيقية غالبًا ما تصفع هذا التفاؤل الأعمى.
عندما تكون منطقة استخدام AWS (AZ) مشلولة بسبب كبل الألياف الضوئية الأساسي الذي تم حفره أو تعطل الطاقة أو شبكة تعريف البرامج (SDN) غير الطبيعية ، هل سيتم تبديل خدمتك تلقائيًا وبسلاسة ، أو سيتم إيقاف خدمة العملاء معًا ؟
حقيقي
لم يتم شراء الهيكل القابل للاستخدام العالي ، ولكن تم تصميمه
. ستتخلى هذه المقالة تمامًا عن الكلمات السوداء المعقدة لـ PPT وتستخدم "اللغة العامية الكبيرة" الأكثر سهولة في الفهم لنقلك إلى تفكيك المقترحين الأساسيين المتاحين للغاية في محطة Amazon Cloud International:
عبور المناطق المتاحة (Cross-AZ)
مع
ELB موازنة التحميل
.
1. إعادة تعريف "قابلية الاستخدام العالية": الحقيقة الأساسية للمنطقة و AZ
قبل تصميم الهندسة المعمارية ، يجب علينا أولاً التعرف على البنية التحتية المادية الأساسية لـ AWS. هذا هو أساس جميع التصاميم عالية المتاحة.
المنطقة: منطقة معزولة جغرافيًا تمامًا (مثل طوكيو وفيرجينيا وأيرلندا). المسافة بين المناطق بعيدة للغاية ، وما لم تحدث كارثة على المستوى الجيوسياسي ، فإن انقطاع التيار الكهربائي في منطقة واحدة لا يؤثر بأي حال على الآخر.
المنطقة المتاحة (AZ): تحتوي على عدة مناطق قابلة للاستخدام داخل منطقة واحدة. تذكر: AZ لا يساوي مركز البيانات. قد تتكون AZ من عدة مجموعات من مراكز البيانات قريبة من بعضها البعض ولكنها مستقلة تمامًا عن الكهرباء والشبكة.
💡نقطة الألم الأساسية: لماذا يجب أن تموت بنية AZ واحدة ؟ من أجل توفير المال ، تترك العديد من الشركات البحرية جميع خوادم الويب وقواعد البيانات في نفس AZ (مثل ap-northeast-1a). هذا يعادل وضع كل البيض في سلة يمكن أن تظل تتسرب على الرغم من أنها "مضادة للرصاص". بمجرد فشل AZ في العمود الفقري ، سيفقد عملك الاتصال على الفور.
لذلك ، فإن الهندسة المعمارية عبر AZ(Multi-AZ) ليست "خيارًا متقدمًا" ، ولكنها بيئة إنتاج
خلاصة القول الصعبة
.
2. حركة مرور المرور: طريقة الفتح الصحيحة لـ ELB (موازنة التحميل المرنة)
لتحقيق التسامح عبر AZ ، يجب أن يكون هناك "شرطة مرور" في الخطوة الأولى ، حيث يتم توزيع الطلبات من المستخدمين العالميين بالتساوي وذكاء على الخوادم في مناطق الاستخدام المختلفة. في AWS ، هذه الشخصية من قبل
ELB(Elastic Load Balancing)
خدم.
تقدم AWS مجموعة متنوعة من موازن التحميل ، ولكن في بنية الويب الحديثة ، نركز بشكل أساسي على
ALB(Application Load Balancer)
و
NLB(Network Load Balancer)
.
1. ALB vs NLB: لا تختار
سلاح خاطئ
الخصائص
ALB (تطبيق موازن الحمل)
NLB (موازن تحميل الشبكة)
مستوى العمل OSI
الطبقة 7 (طبقة التطبيق: HTTP/HTTPS)
الطبقة 4 (طبقة النقل: TCP/UDP/TLS)
الميزة الأساسية
ذكي. يمكنه التعرف على مسارات URL وملفات تعريف الارتباط و HTTP Header للتوجيه المتقدم. يدعم إلغاء تثبيت شهادة SSL.
سريع للغاية. تأخير منخفض للغاية ، قادر على معالجة عشرات الملايين من الطلبات المتزامنة في الثانية ، ويدعم IP الثابت.
السيناريوهات المناسبة
الغالبية العظمى من تطبيقات الويب وواجهات برمجة التطبيقات للخدمات المصغرة ومواقع التجارة الإلكترونية.
بوابة اللعبة ، طرف استقبال إنترنت الأشياء (IoT) ، خدمة TCP الأصلية غير بروتوكول HTTP.
بالنسبة للغالبية العظمى من الشركات التي تذهب إلى البحر ،
ALB
هو الخيار الأكثر الموصى بها.
2. موازنة التحميل عبر المناطق المتاحة (Cross-Zone Load Balancing)
هذا هو المكان الأكثر سهولة في تصميم ELB.
بشكل افتراضي ، فإن توازن التحميل عبر المناطق القابلة للاستخدام لـ ALB هو
فتح
، في حين أن NLB الافتراضي هو
إغلاق
الخاص. ما الفرق بين هذا ؟
في حالة إيقاف التشغيل: إذا قام DNS بتخصيص 50 ٪ من حركة المرور إلى عقدة موازنة التحميل AZ-A ، و 50 ٪ إلى عقدة موازنة التحميل AZ-B. حتى لو كان هناك خادم واحد فقط في AZ-A و 4 خوادم في AZ-B ، فإن الخادم AZ-A سيكون مرهقًا بنسبة 50 ٪ من حركة المرور.
الحالة قيد التشغيل: بغض النظر عن عقدة موازنة التحميل AZ التي تصل إليها حركة المرور أولاً ، ستقوم ELB بتوزيع الطلبات بالتساوي على جميع المثيلات الخلفية في جميع AZ خلفها.
الخلاصة:
ما لم يكن لديك متطلبات تأخير صعبة للغاية (مستوى ميكروثانية) ، وإلا
يوصى بشدة بالحفاظ على توازن التحميل عبر المناطق المتاحة
، تأكد من أن الضغط الخلفي متوسط تمامًا.
3. المثلث الحديدي عبر AZ لمواجهة الكوارث: الحوسبة والشبكة والتخزين
لا يكفي أن يكون لديك شرطة مرور ELB. يجب أن يكون للممر الخلفي (الحساب) وشبكة الطرق (الشبكة) والمستودع (التخزين) القدرة على عبور AZ من أجل تحقيق "التبديل غير الحسي" عندما يكون هناك موت عنيف لـ AZ.
1. طبقة الحساب: Auto Scaling (مجموعة الامتداد التلقائي) هي الموقف الصحيح الوحيد
لا تذهب يدويا لإنشاء جهازين ووضع اثنين من AZ. يجب عليك استخدام
AWS Auto Scaling Group (ASG)
.
تحتاج فقط إلى تكوين قالب بدء التشغيل لإخبار ASG: "أحتاج إلى جهازين على الأقل وما يصل إلى 10. الرجاء مساعدتي في النشر
Ap-northeast-1a
و
Ap-northeast-1b
في اثنين من AZ."
الفحص الصحي: لا تدع ELB يتحقق فقط مما إذا كان EC2 قيد التشغيل (Ping). لتكوين ELB لطلب واجهة معينة في الكود الخاص بك (مثل/health). إذا عادت هذه الواجهة إلى 500 ، أو فشل اتصال قاعدة البيانات ، فسيقف ELB
تم تحديد الحالة على أنها "غير صحية" وتوقف عن إرسال حركة المرور إليها.
قدرة الشفاء الذاتي: بمجرد تعليق AZ معين وفقدت جميع الأجهزة الموجودة في AZ الاتصال ، سيقوم ASG على الفور بتشغيل إنذار وفتح جهاز جديد تلقائيًا في AZ صحي آخر لملء الفجوة.
2. طبقة الشبكة: القاعدة الذهبية للشبكة الفرعية والتوجيه
في تصميم الشبكات الخاصة (VPC) ، يرتكب الكثير من الناس أخطاء في الفوضى الهيكلية. يجب أن تتبع بنية الشبكة القياسية عالية المتاحة مبدأ "الظهور في أزواج والعزلة المطلقة".
الشبكة الفرعية العامة (Subnet العامة): ضع بوابات الإنترنت وبوابات ELB و NAT. كل AZ يأتي مع واحد.
الشبكة الفرعية الخاصة: ضع خادم تطبيق EC2 الحقيقي. لا تحتاج هذه الأجهزة إلى عنوان IP للشبكة العامة ويجب ألا تتعرض مباشرة للإنترنت. كل AZ يأتي مع واحد.
مصيدة بوابة NAT عالية المتاحة: من أجل توفير المال ، قامت العديد من الفرق ببناء بوابة NAT واحدة فقط في AZ-A VPC بالكامل ، بحيث يمكن لـ EC2 الخاص AZ-B أيضًا تجاوز AZ للوصول إلى الإنترنت. بمجرد تعليق AZ-A ، على الرغم من أن الخادم AZ-B على قيد الحياة ، إلا أنه يتم إلغاؤه لأنه لا يمكنه الوصول إلى الإنترنت (لا يمكنه الوصول إلى واجهات برمجة التطبيقات الخارجية ، ولا يمكنه تنزيل الاعتماد). الشيء الصحيح الذي يجب قوله: كل AZ لديه بوابة NAT منفصلة.
3. طبقة التخزين وقاعدة البيانات: وداعًا للنقاط الفردية ، احتضان Multi-AZ
العقد الحسابية عديمة الحالة ويمكن إعادة فتحها في أي وقت إذا ماتت. لكن
البيانات لها حالة ويجب ألا تضيع البيانات.
قاعدة البيانات العلائقية (RDS / Aurora): قم بتشغيل نشر Multi-AZ بقوة. تقوم AWS تلقائيًا بإنشاء مثيل احتياطي (Standby) متزامن بالكامل في AZ آخر. عند فشل AZ حيث توجد المكتبة الرئيسية ، سيقوم RDS تلقائيًا بالانجراف إلى DNS ، ورفع المكتبة الاحتياطية إلى المكتبة الرئيسية في غضون بضع ثوانٍ إلى عشرات ثانية. لا يحتاج رمز التطبيق حتى إلى تعديل سلسلة الاتصال (Endpoint).
تخزين الملفات (EFS vs EBS):EBS (القرص الصلب السحابي): إنه مرتبط بـ AZ معين. هذا يعني أن EC2 AZ-A معلقة ، ولا يمكنك تحميل EBS مباشرة على EC2. AZ-B. EFS (نظام الملفات المرنة): الدعم الأصلي عبر AZ. يمكن للعديد من EC2 AZ قراءة وكتابة نفس EFS في نفس الوقت. إذا كان عملك يتطلب تخزين الملفات المشتركة (مثل دليل تحميل الصور في Wordpress) ، لا تتردد في اختيار EFS.
4. القتال الفعلي النهائي: تمرين معماري قياسي متعدد AZ عالي المتاح
من أجل أن يكون لديك شعور أكثر بديهية ، دعونا نحاكي كيف يتم تداول طلب مستخدم قياسي في بنية عالية متاحة عبر AWS AZ.
المشهد: يزور المستخدم موقع التجارة الإلكترونية [https://example.com]
تحليل اسم المجال: يبدأ المستخدم طلبًا ، يحلل AWS Route 53 (Smart DNS) اسم المجال. بسبب التكوين
مع استراتيجية التأخير أو الاقتراع ، يشير Route 53 إلى حركة المرور إلى ALB المنتشرة على الشبكة الفرعية العامة.
توزيع حركة المرور: يتلقى ALB طلب HTTPS ، ويكمل فك تشفير شهادة SSL (ضغط إلغاء التثبيت) محليًا ، ثم يقوم بإعادة توجيه الطلب إلى مثيلات EC2 الموجودة في AZ-A أو الشبكات الفرعية الخاصة AZ-B وفقًا لاستراتيجية موازنة التحميل عبر المناطق المتاحة.
معالجة الأعمال وقراءة البيانات: أعمال معالجة التطبيقات على EC2. إذا كنت بحاجة إلى قراءة وكتابة قاعدة البيانات ، فإنه يتصل بمكتبة RDS الرئيسية (الموجودة في AZ-A). في هذا الوقت ، يقوم RDS تلقائيًا بنسخ البيانات بشكل متزامن إلى مكتبة RDS (الموجودة في AZ-B).
حدوث كارثة (تم فصل AZ-A المحاكاة تمامًا عن الشبكة): رد فعل ELB: وجد ALB أن حالة EC2 في AZ-A قد توقفت عن ضربات القلب ، أو فشل الفحص الصحي بشكل مستمر ، وأزال AZ-A على الفور من قائمة إعادة التوجيه. يتم استيراد 100 ٪ من حركة المرور على الفور إلى EC2 AZ-B. الشفاء الذاتي لـ RDS: تراقب AWS فقدان الاتصال في مكتبة RDS الرئيسية ، وتبدأ تلقائيًا في تجاوز الفشل (Failover). تمت ترقية المكتبة الاحتياطية AZ-B إلى المكتبة الرئيسية الجديدة في غضون 30 ثانية ، ويقوم Route 53 تلقائيًا بتحديث Endpoint الداخلي لـ RDS. استأنف EC2 AZ-B القراءة والكتابة العادية بعد الإبلاغ لفترة وجيزة عن الأخطاء. توسيع ASG: وجدت مجموعة Auto Scaling Group أن عدد الآلات الباقية حاليًا أقل من الحد الأدنى للقيمة المتوقعة المحددة ، وظهرت على الفور EC2 جديدة تمامًا في AZ-B صحية وتم تسجيلها تلقائيًا خلف ALB.
النتائج:
في العملية برمتها ، باستثناء عدد قليل جدًا من المستخدمين الذين بدأوا الطلب في لحظة التبديل ، قد يواجهون إعادة المحاولة (502/504) ، 99 ٪ من المستخدمين لا يدركون تمامًا أن الخلفية قد شهدت كارثة على مستوى غرفة الكمبيوتر "سرعة الحياة والموت".
5. دليل تجنب الحفرة: ثلاثة أخطاء قاتلة يرتكبها المهندسون المعماريين في كثير من الأحيان
عند الهبوط الفعلي على هذا الهيكل ، بناءً على عدد كبير من حالات الانقلاب ، قمت بتلخيص الشعاب المرجانية الثلاثة التالية التي يمكن تجاهلها بسهولة:
1. رسوم النقل عبر AZ (Cross-AZ Data Transfer Costs)
حركة المرور الواردة من AWS (القادمة من الإنترنت) مجانية ، ولكن داخل نفس المنطقة ،
يتم فرض رسوم على حركة المرور عبر عمليات نقل AZ المختلفة
(عادة 0.01 دولار/GB).
إذا تم تفكيك الخدمة المصغرة الخاصة بك كثيرًا ، فإن الخدمة A(AZ-A) تستدعي الخدمة B(AZ-B) بشكل متكرر من خلال RPC. في نهاية الشهر ، ستتلقى فاتورة شبكة مخيفة للغاية.
خطة التحسين: حاول أن تدع حركة المرور تكمل الحلقة المغلقة للإنترانت في نفس AZ ، ولا تعبر AZ إلا عند تبديل الاستجابة للكوارث.
2. قاعدة البيانات "كسر الدماغ" وتأخير التزامن
على الرغم من أن RDS Multi-AZ يتم تكراره في وقت واحد ، إلا أن الأداء جيد جدًا ، ولكن إذا كنت عبارة عن مجموعة قاعدة بيانات مبنية ذاتيًا (مثل MySQL MHA التي تم تغييرها بواسطة شيطان صلب) ، فمن السهل جدًا أن تحدث عند الاهتزاز عبر شبكة AZ ، حيث تعتبر كلتا العقدة نفسها ظاهرة "تشقق الدماغ" في المكتبة الرئيسية ، مما يؤدي إلى فوضى كتابة البيانات.
خطة التحسين: يتم تسليم الأمور المهنية إلى الأدوات المهنية ، وبيئة الإنتاج قوية
يوصى باستخدام RDS أو Aurora أولاً ، وترك مشكلة الاتساق الموزع الأساسية لـ AWS لحلها.
3. نسيان الاختبار: ارتفاع توافر على الورق ليس مرتفعًا
تم تصميم العديد من هياكل الفريق بشكل مثالي ، لكنهم لم يجروا تدريبات على التعافي من الكوارث منذ ثلاث سنوات. عندما فشلت النتيجة ، وجدت أن عنوان IP الخاص بقاعدة البيانات مكتوب في الكود ، أو أن مجموعة الأمان نسيت الإفراج عن جزء شبكة AZ آخر.
برنامج التحسين: تنفيذ Chaos Engineering بانتظام. في فترة الذروة المنخفضة ، انتقل يدويًا إلى وحدة التحكم RDS وانقر على "Failover" ، أو قم بإيقاف تشغيل جميع EC2 من AZ عن عمد لمعرفة ما إذا كان النظام يمكنه شفاء نفسه كما هو متوقع.
خاتمة
في عصر السحابة الأصلية ،
لا ينبغي أن تكون القدرة على تحمل الكوارث مهمة بدنية باهظة الثمن ومرهقة ، ولكن حدس التصميم.
من خلال سوف
التوزيع الذكي ELB
،
Auto Scaling الشفاء الذاتي بدون حالة
وأيضًا
النسخ المتماثل المتزامن عبر AZ من RDS
معًا ، استخدمنا فقط عدد قليل من خدمات محطة Amazon Cloud الدولية القياسية لبناء هيكل فولاذي كافٍ لمقاومة الكوارث على مستوى غرفة الكمبيوتر.
تذكر أن أعلى مستوى من التوافر العالي لا يعني أن الفشل لن يحدث أبدًا ؛ ولكن عندما يأتي الفشل كما هو مقرر ، فإن نظامك يهتز قليلاً ويستمر في المضي قدمًا بثبات في الرياح والأمطار.
