شعار زيفيرنت

حقق التوفر العالي في Amazon OpenSearch Multi-AZ مع المجالات الممكّنة في وضع الاستعداد: نظرة عميقة على عمليات تجاوز الفشل | خدمات الويب الأمازون

التاريخ:

خدمة Amazon OpenSearch قدم مؤخرا Multi-AZ مع وضع الاستعداد، وهو خيار نشر مصمم لتزويد الشركات بتوفر محسّن وأداء متسق لأحمال العمل المهمة. باستخدام هذه الميزة، يمكن للمجموعات المُدارة تحقيق توفر بنسبة 99.99% مع الحفاظ على مرونتها في مواجهة حالات فشل البنية التحتية للمنطقة.

في هذا المنشور، نستكشف كيفية عمل البحث والفهرسة مع Multi-AZ مع Standby ونتعمق في الآليات الأساسية التي تساهم في موثوقيتها وبساطتها وتحمل الأخطاء.

خلفيّة

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

أثناء العمليات العادية، تتعامل المنطقة النشطة مع حركة مرور المنسق لكل من طلبات القراءة والكتابة، بالإضافة إلى حركة مرور الاستعلام الجزئي. منطقة الاستعداد، من ناحية أخرى، تتلقى فقط حركة مرور النسخ المتماثل. تستخدم خدمة OpenSearch بروتوكول النسخ المتماثل المتزامن لطلبات الكتابة. يتيح ذلك للخدمة ترقية منطقة الاستعداد على الفور إلى الحالة النشطة في حالة حدوث فشل (متوسط ​​وقت تجاوز الفشل <= 1 دقيقة)، والمعروف باسم تجاوز فشل المنطقة. يتم بعد ذلك تخفيض المنطقة النشطة سابقًا إلى وضع الاستعداد، وتبدأ عمليات الاسترداد لاستعادة حالتها الصحية.

ابحث في توجيه حركة المرور وتجاوز الفشل لضمان التوفر العالي

في مجال خدمة OpenSearch، أ منسق هي أي عقدة تتعامل مع طلبات HTTP(S)، وخاصة طلبات الفهرسة والبحث. في مناطق توافر الخدمات المتعددة ذات المجال الاحتياطي، تعمل عقد البيانات الموجودة في المنطقة النشطة كمنسقين لطلبات البحث.

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

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

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

يتم تخزين الأوزان في البيانات التعريفية لحالة المجموعة ككائن JSON:

"weighted_shard_routing": {
    "awareness": {
        "zone": {
            "us-east-1b": 0,
            "us-east-1d": 1,
            "us-east-1c": 1
         }
     },
     "_version": 3
}

كما هو موضح في الصورة التالية ، فإن ملف us-east-1b المنطقة لها وضع المنطقة الخاص بها StandBy، للإشارة إلى أن عقد البيانات في منطقة توافر الخدمات هذه في حالة الاستعداد ولا تتلقى طلبات البحث أو الفهرسة من موازن التحميل.

حالة منطقة توافر الخدمات في وحدة تحكم AWS

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

تشغيل الحالة المستقرة

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

في مجموعة خدمة OpenSearch Service، يمكن التحقق من المناطق النشطة والاستعداد في أي وقت باستخدام مقاييس دوران منطقة توافر الخدمات، كما هو موضح في لقطة الشاشة التالية.

مقاييس تناوب منطقة توافر الخدمات

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

قراءة تجاوز الفشل أثناء فشل المنطقة

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

كيف يضمن تجاوز الفشل توفرًا عاليًا أثناء ضعف الكتابة

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

تستخدم خدمة OpenSearch بروتوكول اتصال داخلي من عقدة إلى عقدة لتكرار حركة مرور الكتابة وتنسيق تحديثات البيانات التعريفية من خلال قائد منتخب. وبالتالي، فإن وضع المنطقة التي تعاني من الضغط في وضع الاستعداد لن يعالج بشكل فعال مشكلة ضعف الكتابة.

تجاوز فشل الكتابة المنطقي: قطع حركة النسخ المتماثل بين المناطق

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

رشيقة الكتابة الفشل

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

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

كتابة تجاوز الفشل أثناء حدث التواصل

في عملية تنفيذ تجاوز فشل الكتابة لعقدة رائدة، تتبع خدمة OpenSearch الخطوات الأساسية التالية:

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

يتم تخزين البيانات التعريفية المتعلقة بمنطقة تجاوز فشل الكتابة داخل حالة المجموعة، ويتم نشر هذه المعلومات على جميع العقد في مجموعة خدمة OpenSearch الموزعة على النحو التالي:

"decommissionedAttribute": {
    "awareness": {
        "zone": "us-east-1c"
     },
     "status": "successful",
     "requestID": "FLoyf5v9RVSsaAquRNKxIw"
}

توضح لقطة الشاشة التالية أنه أثناء تباطؤ الشبكة في منطقة ما، يساعد تجاوز فشل الكتابة في استعادة التوفر.

يساعد تجاوز فشل الكتابة على استعادة التوفر

استرداد المنطقة بعد فشل الكتابة

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

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

وفي الختام

يوفر تقديم خدمة OpenSearch Service Multi-AZ مع وضع الاستعداد للشركات حلاً قويًا لتحقيق التوفر العالي والأداء المتسق لأحمال العمل المهمة. باستخدام خيار النشر هذا، يمكن للشركات تعزيز مرونة بنيتها التحتية، وتبسيط تكوين المجموعة وإدارتها، وفرض أفضل الممارسات. بفضل ميزات مثل اختيار نسخ الأجزاء الموزونة، وآليات تجاوز الفشل الاستباقية، ومناطق توافر الاستعداد الاحتياطية غير المفتوحة، تضمن خدمة OpenSearch Service Multi-AZ مع وضع الاستعداد تجربة بحث موثوقة وفعالة لبيئات المؤسسات كثيرة المتطلبات.

لمزيد من المعلومات حول Multi-AZ مع وضع الاستعداد، راجع Amazon OpenSearch Service تحت الغطاء: Multi-AZ مع وضع الاستعداد.


عن المؤلف


أنشو أغاروال
 هو مهندس برمجيات أول يعمل على AWS OpenSearch في Amazon Web Services. إنها متحمسة لحل المشكلات المتعلقة ببناء أنظمة قابلة للتطوير وموثوقة للغاية.


ريشاب نحاتة
 هو مهندس برمجيات يعمل على OpenSearch في Amazon Web Services. إنه مفتون بحل المشكلات في الأنظمة الموزعة. هو مساهم نشط في OpenSearch.


بختيار خان
هو مهندس رئيسي يعمل في Amazon OpenSearch Service. إنه مهتم بالأنظمة الموزعة والمستقلة. وهو مساهم نشط في OpenSearch.


رانجيث راماتشاندرا
هو مدير هندسة يعمل على Amazon OpenSearch Service في Amazon Web Services.

بقعة_صورة

أحدث المعلومات الاستخباراتية

بقعة_صورة