توضح هذه المقالة خيار ضمان توفر خدمة ويب تم نشرها في السحابة في حالة حدوث خلل في مركز البيانات. يعتمد الحل المقترح على حل وسط يتكون من
تكرار جزئي : يتم نشر نظام نسخ احتياطي في مركز بيانات آخر ، والذي يمكن أن يعمل في وضع محدود الوظائف عندما يكون مركز البيانات الرئيسي غير متوفر. يهدف هذا المخطط أساسًا إلى تطبيق الإخفاقات قصيرة الأجل ، ولكنه يوفر أيضًا القدرة على تحويل نظام النسخ الاحتياطي بسرعة إلى النظام الرئيسي في حالة حدوث مشكلات واسعة النطاق.
وصف المشكلة
في العام الماضي ، تأثرنا بحادث وقع في مركز البيانات لمزود سحابة مشهور - إحدى خدماتنا لم تكن متاحة للمستخدمين لمدة نصف ساعة. ثم رأينا بأعيننا أنه في حالة وجود مشاكل في مركز البيانات السحابية ، لا توجد أي أدوات لاستعادة صحة التطبيق ، ولم يتبق للفريق المسؤول عن التطبيق سوى الانتظار والانتظار. هذه التجربة جعلتنا نفكر بجدية في استخدام السحب لمنتجاتنا.
ما حدث بالضبط في ذلك اليوم لم يكتشف قط. لقد اعتدنا أن نرى الغيوم على أنها بؤرة استيطانية غير قابلة للتدمير ، لكن هذا ليس كذلك. الحقيقة هي أنه لا يوجد ضمان مائة بالمائة لتوافر الخدمة في السحابة ، كما في أي مكان آخر. الغيوم عبارة عن تجريد يتم من خلاله إخفاء كل نفس الرفوف بالحديد في مراكز البيانات والعامل البشري. فشل أي جهاز عاجلاً أو آجلاً (على الرغم من أن فشل الأجهزة لمراكز البيانات من المرجح أن يكون موقفًا عاديًا). بالإضافة إلى ذلك ، هناك
حالات لمشاكل أكثر خطورة تؤدي إلى عدم إمكانية الوصول إلى مراكز البيانات: الحرائق ، هجمات DDoS ، الكوارث الطبيعية ، انقطاع التيار الكهربائي والإنترنت ، إلخ.
إذا تحدثنا عن العامل البشري ، فهذا ليس السبب الأخير للحوادث:
"وفقًا للإحصاءات ، في 80٪ من حالات فشل البنية التحتية للشبكة ، يتحمل الناس المسؤولية" . الناس ، بغض النظر عن مدى حسن نواياهم الموجهة ، لا يعول عليهم. حتى أنت وزملاؤك - الأشخاص المهتمون مباشرة باستقرار المنتجات المدعومة - ربما ارتكبت أخطاء ، ناهيك عن موظفي شركة شخص آخر ، الذين لا تختلف مثلك عنهم عن الآخرين. أيا كان الفريق المحترف وراء البنية التحتية ، فإن خلل جديد هو مسألة وقت.
كل شيء له ثمن. عندما تنتقل إلى السحابة ، تحصل على تجريد بسيط ، ملائم للعمل ، اعتماد ضعيف على قسم العمليات في مقابل السيطرة الكاملة على الموقف. في هذه الحالة ، إذا لم تهتم بنفسك مقدمًا ، بعد أن توقعت احتمال حدوث أخطاء لدى الآخرين ، فلن يقوم أحد بذلك.
خيارات الحل
بالنسبة لنا ، يعد عدم توفر الخدمة ، حتى لعدة دقائق ، أمرًا بالغ الأهمية بالفعل. لذلك ، قررنا إيجاد طريقة لتأمين أنفسنا من مشاكل مماثلة في المستقبل ، دون التخلي عن السحب.
عند البدء في حل مشكلة توفر الخدمة في السحابة ، يجب أن يؤخذ في الاعتبار أن إمكانية الوصول مفهوم واسع إلى حد ما ، واعتمادًا على المقصود به ، يتم النظر في سيناريوهات مختلفة لتوفيره. على الرغم من أن هذه المقالة تناقش فقط مشكلة إمكانية الوصول كنتيجة لفشل مركز البيانات ، إلا أنه سيكون من المناسب قول بضع كلمات عن حلول مشاكل إمكانية الوصول الأخرى.
التوفر كفرصة تقنية لتوفير الوصول إلى مورد لفترة محددة عند تحميل معين. تنشأ المشكلة عند تشغيل الخدمة ، ولكن بسبب محدودية الموارد والإطار المعماري للنظام ، لا يمكن لجميع المستخدمين الوصول إليها في وقت استجابة معين. غالبًا ما يتم حل المهمة عن طريق نشر مثيلات إضافية مع التطبيق. مع هذا القياس ، تقوم الغيوم بعمل رائع.
إمكانية الوصول مثل توفر خدمة الويب للمستخدمين من منطقة معينة. الحل الواضح هنا هو التقسيم. بمعنى آخر ، تقسيم النظام إلى عدة تطبيقات مستقلة في مراكز بيانات مختلفة مع بياناته الخاصة وتعيين كل مستخدم لمثيل نظامه ، على سبيل المثال ، استنادًا إلى موقعه الجغرافي. عند المشاركة ، سيؤدي فشل مركز بيانات واحد في أسوأ الحالات إلى عدم توفر الخدمة لجزء من المستخدمين المرتبطين بمركز البيانات هذا. ليست الحجة الأخيرة لصالح التقاسم - فهذه هي الفترة الزمنية المختلفة لمركز البيانات في المناطق المختلفة.
ومع ذلك ، غالبًا ما تكون القيود المفروضة على العمل مع السحابة والحاجة إلى اللامركزية من المتطلبات التشريعية التي عادة ما تؤخذ في الاعتبار حتى في مرحلة تصميم النظام. تتضمن هذه المتطلبات: قانون Yarovaya - تخزين البيانات الشخصية (PD) للمستخدمين في روسيا ؛ اللائحة العامة لحماية البيانات (GDPR) - القيود المفروضة على نقل PD لمستخدمي الاتحاد الأوروبي عبر الحدود إلى بعض البلدان ؛ والرقابة الصينية على الإنترنت ، حيث يجب أن تكون جميع الاتصالات وجميع أجزاء التطبيق موجودة في الصين ، ويفضل ، على خوادمهم.
يتم حل مشكلة عدم إمكانية الوصول التقني لمركز البيانات عن طريق تكرار الخدمة في مركز بيانات آخر. هذه ليست مهمة تقنية سهلة. العقبة الرئيسية أمام النشر الموازي للخدمات في مراكز البيانات المختلفة هي قاعدة البيانات. عادةً ما تستخدم الأنظمة الصغيرة بنية أحادية المعالج. في هذه الحالة ، فإن فشل مركز البيانات مع الرئيسي يجعل النظام بأكمله غير فعال. نظام النسخ المتماثل الرئيسي ممكن ، لكنه يفرض قيودًا قوية لا يفهمها الجميع. في الواقع ، لا تقوم بتوسيع نطاق السجل إلى قاعدة البيانات ، ولكن حتى يتم فرض غرامة زمنية صغيرة ، لأنه من الضروري تأكيد جميع العقد التي تم قبول المعاملة. يزيد وقت تشغيل الكتابة أكثر عندما يجب أن تكون المسافات متباعدة في مراكز بيانات مختلفة.
تبرير القرار
أظهر تحليل الحمل على خدمتنا أن حوالي 70٪ من مكالمات واجهة برمجة التطبيقات يتم إجراؤها بواسطة طرق GET. تستخدم هذه الطرق قاعدة بيانات للقراءة فقط.
خدمة استدعاء HTTP على شبكة الإنترنتأعتقد أن هذه النتائج تعكس الصورة الكاملة لخدمات الويب المتاحة عمومًا. لذلك ، يمكننا القول أنه
في واجهة برمجة تطبيقات خدمة الويب المتوسطة ، يتم استدعاء أساليب القراءة في كثير من الأحيان أكثر من أساليب الكتابة .
البيان الثاني الذي أود طرحه هو أنه
إذا تحدثنا عن إمكانية الوصول المطلقة ، فإن عملاء الخدمة سيحتاجون حقًا إلى مثل هذا الوصول ليس فقط من مجموعة كبيرة من أساليب واجهة برمجة التطبيقات المتاحة ، ولكن فقط تلك الضرورية لمواصلة العمل "المعتاد" مع النظام وتنفيذ استفسارات "طبيعية" . لن ينزعج أحد إذا كانت الطريقة التي يتم الوصول إليها بضع مرات في الشهر غير متوفرة لعدة دقائق. غالبًا ما يتم تغطية التدفق "العادي" بطرق القراءة.
لذلك ، يمكن اعتبار ضمان التوافر المطلق لطرق القراءة فقط كخيار ممكن لحل قصير المدى لمشكلة توفر النظام في حالة فشل مركز البيانات.ماذا نريد أن ننفذ؟
في حالة حدوث أعطال في مركز البيانات ، نود تحويل حركة المرور إلى نظام النسخ الاحتياطي في مركز بيانات آخر. في نظام النسخ الاحتياطي ، يجب أن تكون جميع أساليب القراءة متاحة ، وعند استدعاء الأساليب المتبقية ، إذا كان من المستحيل القيام بذلك دون الكتابة إلى قاعدة البيانات ، يجب أن يتم عرض الخطأ الصحيح.
في التشغيل العادي ، يتم إرسال طلب المستخدم إلى الموازن ، والذي بدوره يعيد توجيهه إلى API الرئيسية. في حالة عدم توفر الخدمة الرئيسية ، يحدد الموازن هذه الحقيقة ويعيد توجيه الطلبات إلى نظام النسخ الاحتياطي الذي يعمل في وضع الأداء الوظيفي المحدود. في هذا الوقت ، يقوم الفريق بتحليل المشكلة ويقرر الانتظار لاستعادة مركز البيانات أو تبديل نظام النسخ الاحتياطي إلى الوضع الرئيسي.
خوارزمية التنفيذ
تغييرات البنية التحتية اللازمة
- إنشاء قاعدة بيانات النسخ المتماثل الرقيق في مركز بيانات آخر.
- إعداد نشر خدمة ويب ، وجمع السجلات والمقاييس في مركز البيانات الثاني.
- تكوين الموازن لتحويل الحركة إلى مركز بيانات احتياطي في حالة عدم توفر الأول.
تغييرات الكود:
- إضافة اتصال منفصل إلى النسخة المتماثلة في خدمة الويب.
- ترحيل جميع طرق واجهة برمجة التطبيقات للقراءة فقط إلى نسخة متماثلة.
- بالنسبة للطرق المتبقية ، فإن إدخال وضع القراءة فقط من خلال متغير بيئة أو مشغل آخر ، والذي بدلاً من الكتابة إلى قاعدة البيانات ، سينجح جزئياً أو ، في حالة توقف وظائفهم دون الكتابة إلى قاعدة البيانات ، يعطي خطأ صحيحًا.
- تحسينات على الواجهة الأمامية لعرض الخطأ الصحيح عند استدعاء طرق التسجيل.
إيجابيات وسلبيات الحل الموصوف
الفوائد
- الميزة الرئيسية للمخطط المقترح هي أن هناك دائمًا خدمة مكررة ، جاهزة في أي وقت لخدمة المستخدمين. في حالة حدوث مشاكل في مركز البيانات الرئيسي ، لن تضطر إلى كتابة نصوص نشر على بعض البنية الأساسية الأخرى وتشغيل كل شيء على عجل.
- الحل رخيص لتنفيذ وصيانة. إذا كان لديك بنية خدمات ميكروية وكان المنتج لا يحتاج إلى خدمات واحدة ولكن العديد من الخدمات ، في هذه الحالة لا ينبغي أن يكون هناك أي مشاكل خاصة في نقل جميع الخدمات المصغرة إلى هذا المخطط.
- لا يوجد أي تهديد بفقدان البيانات ، حيث يوجد دائمًا نسخة كاملة من قاعدة البيانات على النسخة المتماثلة في مركز بيانات آخر.
- الحل مخصص بشكل أساسي للتبديل المؤقت لحركة المرور ، حتى نصف ساعة. هذا نصف ساعة لا يكفي للتنقل في حالة وجود مشاكل في البنية التحتية. إذا لم تتم استعادة مركز البيانات الأول خلال هذه الفترة ، فإن نسخة طبق الأصل من قاعدة البيانات تتحول إلى رئيسية ، وتصبح الخدمة المكررة هي الخدمة الرئيسية.
- في المخطط المقترح ، يوجد التطبيق وقاعدة البيانات في نفس مركز البيانات. إذا كان لديك واجهة برمجة تطبيقات وقاعدة بيانات في مراكز بيانات مختلفة ، فمن الأفضل نقلها إلى واحد: سيؤدي ذلك إلى تقليل وقت تنفيذ الاستعلام بشكل كبير. على سبيل المثال ، أظهرت قياساتنا أنه بالنسبة إلى Google Cloud ، يكون الطلب من واجهة برمجة التطبيقات (API) إلى قاعدة البيانات في أحد مراكز البيانات في المتوسط 6 مللي ثانية ، وعند الانتقال للبيانات إلى مركز بيانات آخر ، يزداد الوقت بعشرات الميلي ثانية.
العيوب
- العيب الرئيسي في المخطط برمته هو أنه بالنسبة للتبديل الفوري لحركة المرور ، يلزم وجود موازن غير موجود في نفس مركز البيانات مع الخدمة الرئيسية. الموازن هو نقطة الفشل: في حالة فشل مركز البيانات مع الموازن ، تصبح خدمتك غير متوفرة في أي حال.
- الحاجة إلى نشر الكود على خادم آخر ، ومراقبة الموارد الإضافية - على سبيل المثال ، مراقبة النسخة المتماثلة حتى لا يكون هناك تأخير.
الخاتمة
لا يمكنك إنشاء نظام مقاوم لجميع أنواع الإخفاقات. ومع ذلك ، فإن حماية نفسك من أنواع معينة مهمة ممكنة. يمكن أن يكون الحل الموصوف في المقالة ، والذي يسمح بضمان توفر التطبيق في حالة حدوث أعطال في مركز البيانات ، مفيدًا ومفيدًا في التطبيقات العملية في العديد من الحالات.
تحويل خدمة ويب منتظمة إلى نظام موزع بالكامل من أجل الحماية ضد الإخفاقات الافتراضية في مركز البيانات هو أمر غير عملي على الأرجح. للوهلة الأولى ، حتى المخطط المقترح يبدو زائداً و "ثقيلاً" ، ولكن هذه العيوب تتداخل أكثر من مزاياه وسهولة التنفيذ. يمكنك وضع تشابه مع التأمين ضد الحوادث: هناك احتمال كبير أنك لن تحتاج أبدًا إلى مثل هذا التأمين ، ولكن إذا حدث أي حادث ، فسيكون موضع ترحيب كبير. مع المخطط المقترح ، ستكون متأكدًا من أن لديك دائمًا نظام نسخ احتياطي جاهز ، والذي سيضمن ، على المدى القصير ، توفر معظم أساليب الخدمة ، وفي حالة الإخفاقات الطويلة ، يمكن أن يتحول بالكامل إلى النظام الرئيسي في غضون دقائق. سيوافق الكثيرون على دفع هذا الثمن مقابل هذه الثقة.
كل نظام له معلمات تحميل فريدة ومتطلبات إمكانية الوصول. لهذا السبب لا توجد إجابة صحيحة أو خاطئة على السؤال: "هل يمكنك الوثوق بـ Google Cloud أو AWS تمامًا؟" - في كل موقف معين سيكون هو نفسه.