تأثير فشل البنية التحتية على Shard في Amazon OpenSearch Service

أعاد نشره أفلاطون

المتابعون: 0

خدمة Amazon OpenSearch هي خدمة مُدارة تجعل من السهل تأمين ونشر وتشغيل OpenSearch ومجموعات Elasticsearch القديمة على نطاق واسع في سحابة AWS. توفر Amazon OpenSearch Service جميع الموارد لمجموعتك ، وتطلقها ، وتكتشف وتستبدل العقد الفاشلة تلقائيًا ، مما يقلل من عبء البنى التحتية المدارة ذاتيًا. تسهل لك الخدمة إجراء تحليلات تفاعلية للسجلات ، ومراقبة التطبيقات في الوقت الفعلي ، وعمليات البحث في مواقع الويب ، والمزيد من خلال تقديم أحدث إصدارات OpenSearch ، ودعم 19 إصدارًا من Elasticsearch (إصدارات من 1.5 إلى 7.10) ، وإمكانيات التصور المدعومة من لوحات تحكم OpenSearch و Kibana (من 1.5 إلى 7.10 إصدارات).

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

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

التحدي

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

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

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

يمكن تفسير سلوك المجال هذا في جزأين - أثناء الفشل وأثناء الاسترداد.

أثناء الفشل

يمكن أن يواجه المجال المنشور عبر مناطق توافر متعددة أنواعًا متعددة من الإخفاقات أثناء دورة حياته.

فشل كامل في المنطقة

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

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

فشل جزئي في المنطقة

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

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

التعافى

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

ما الذي تغير

لتحسين معالجة الفشل الشامل وتقليل تأثير الفشل على صحة المجال وأدائه ، تُجري Amazon OpenSearch Service التغييرات التالية:

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

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

باستخدام هذا التكوين كمثال ، إذا بدأت عقدتين بـ node.attr.zone تعيين إلى zone1 وإنشاء فهرس بخمسة أجزاء ونسخة متماثلة واحدة ، يقوم OpenSearch بإنشاء الفهرس وتخصيص الأجزاء الخمسة الأساسية ولكن بدون نسخ متماثلة. يتم تخصيص النسخ المتماثلة مرة واحدة فقط مع العقد node.attr.zone تعيين إلى zone2 متوفرة.

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

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

ملاحظات أن أي غير معين ابتدائي سيظل مسموحًا بالنسخ على العقدة المحملة بشكل زائد لمنع الكتلة من أي فقدان وشيك للبيانات.

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

تصور السلوك الحالي والجديد

على سبيل المثال ، تم تكوين مجال Amazon OpenSearch Service مع 3-AZ و 6 عقد بيانات و 12 جزء أساسي و 24 جزء نسخة متماثلة. يتم توفير المجال عبر AZ-1 و AZ-2 و AZ-3 ، مع عقدتين في كل منطقة.

تخصيص الجزء الحالي:
إجمالي عدد القطع: 12 أساسي + 24 نسخة متماثلة = 36 قطعة
عدد مناطق التوفر: 3
عدد القطع في كل منطقة (إدراك المنطقة صحيح): 36/3 = 12
عدد العقد لكل منطقة توافر: 2
عدد القطع لكل عقدة: 12/2 = 6

يوفر الرسم البياني التالي تمثيلًا مرئيًا لإعداد المجال. تشير الدوائر إلى عدد القطع المخصصة للعقدة. ستخصص Amazon OpenSearch Service ستة أجزاء لكل عقدة.

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

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

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

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

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

ما يمكن أن تتوقعه

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

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

قم بتحديث برنامج الخدمة الخاص بنطاق Amazon OpenSearch Service الخاص بك لتطبيق هذه التغييرات الجديدة على المجال الخاص بك. مزيد من التفاصيل حول عملية تحديث برنامج الخدمة في وثائق خدمة Amazon OpenSearch Service.

وفي الختام

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

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

عن المؤلفين

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

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

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

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

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

جون هاندلر مهندس حلول رئيسي ، متخصص في تقنيات بحث AWS - Amazon CloudSearch و Amazon OpenSearch Service. مقره في بالو ألتو ، يساعد مجموعة واسعة من العملاء في نشر أحمال عمل البحث وتحليلات السجلات بشكل صحيح ويعمل بشكل جيد.