أفضل الممارسات لقابلية الوصول العالية والتعافي من الكوارث
Azure Managed Instance ل Apache Cassandra هي خدمة مدارة بالكامل لمجموعات Apache Cassandra مفتوحة المصدر فقط. تسمح الخدمة أيضا بتجاوز التكوينات، اعتمادا على الاحتياجات المحددة لكل حمل عمل، ما يسمح بأقصى قدر من المرونة والتحكم عند الحاجة.
يعد Apache Cassandra خيارا رائعا لبناء تطبيقات مرنة للغاية نظرا إلى طبيعتها الموزعة وهندستها بلا إتقان - يمكن لأي عقدة في قاعدة البيانات أن توفر نفس الوظائف تماما مثل أي عقدة أخرى - مما يساهم في قوة Cassandra ومرونتها. توفر هذه المقالة تلميحات حول كيفية تحسين قابلية الوصول العالية وكيفية التعامل مع التعافي من الكوارث.
هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO)
RPO (هدف نقطة الاسترداد) وRTO (هدف وقت الاسترداد)، سيكون كلاهما منخفضا (قريبا من الصفر) ل Apache Cassandra طالما لديك:
- نشر متعدد المناطق مع النسخ المتماثل عبر المناطق، وعامل النسخ المتماثل من 3.
- مناطق التوفر الممكنة (حدد الخيار عند إنشاء نظام مجموعة في المدخل أو عبر Azure CLI).
- تجاوز الفشل على مستوى التطبيق المكون باستخدام نهج موازنة التحميل في برنامج تشغيل العميل و/أو تجاوز الفشل على مستوى موازنة التحميل باستخدام مدير حركة المرور/الباب الأمامي Azure.
سيكون RTO ("المدة التي تستغرقها في الانقطاع") منخفضا لأن نظام المجموعة سيكون مرنا عبر كل من المناطق والمناطق، ولأن Apache Cassandra نفسه هو نظام متسامح للغاية مع الأخطاء وبلا إتقان (يمكن لجميع العقد الكتابة) بشكل افتراضي. سيكون RPO ("مقدار البيانات التي يمكن أن تفقدها في الانقطاع") منخفضا لأنه سيتم مزامنة البيانات بين جميع العقد ومراكز البيانات، لذلك سيكون فقدان البيانات في الانقطاع ضئيلا.
إشعار
ليس من الممكن نظريا تحقيق كل من RTO=0 وRPO =0 لكل نظرية Cap. ستحتاج إلى تقييم المفاضلة بين التناسق والتوافر/الأداء الأمثل - سيبدو هذا مختلفا لكل تطبيق. على سبيل المثال، إذا كان تطبيقك ثقيل القراءة، فقد يكون من الأفضل التعامل مع زمن الانتقال المتزايد للكتابات عبر المناطق لتجنب فقدان البيانات (تفضيل التناسق). إذا كانت appplication ثقيلة الكتابة، وعلى ميزانية زمن انتقال ضيق، فقد يكون خطر فقدان بعض عمليات الكتابة الأخيرة في انقطاع إقليمي كبير مقبولا (يفضل التوفر).
مجموعات التوافر
توفر بنية Cassandra بلا إتقان التسامح مع الخطأ من الألف إلى الياء، ويوفر Azure Managed Instance ل Apache Cassandra الدعم لمناطق التوفر في مناطق محددة لتعزيز المرونة على مستوى البنية الأساسية. نظرا لعامل النسخ المتماثل 3، يضمن دعم منطقة التوفر أن كل نسخة متماثلة في منطقة توفر مختلفة، وبالتالي منع انقطاع المنطقة من التأثير على قاعدة البيانات/التطبيق الخاص بك. نوصي بتمكين مناطق التوفر حيثما أمكن ذلك.
التكرار متعدد المناطق
تمنحك بنية Cassandra، إلى جانب دعم مناطق توفر Azure، مستوى من التسامح مع الخطأ والمرونة. ومع ذلك، من المهم مراعاة تأثير الانقطاعات الإقليمية لتطبيقاتك. نوصي بشدة بنشر مجموعات متعددة المناطق للحماية من الانقطاعات على مستوى المنطقة. على الرغم من أنها نادرة، فإن التأثير المحتمل شديد.
لاستمرارية الأعمال، لا يكفي فقط جعل قاعدة البيانات متعددة المناطق. يجب أيضا توزيع أجزاء أخرى من تطبيقك بنفس الطريقة إما عن طريق توزيعها أو باستخدام آليات كافية للفشل. إذا كان المستخدمون منتشرين عبر العديد من المواقع الجغرافية، فإن نشر مركز بيانات متعدد المناطق لقاعدة البيانات الخاصة بك له فائدة إضافية تتمثل في تقليل زمن الانتقال، حيث يمكن لجميع العقد في جميع مراكز البيانات عبر نظام المجموعة بعد ذلك تقديم عمليات القراءة والكتابة من المنطقة الأقرب إليها. ومع ذلك، إذا تم تكوين التطبيق ليكون "نشط-نشط"، فمن المهم مراعاة كيفية تطبيق نظرية CAP على تناسق البيانات بين النسخ المتماثلة (العقد)، والمفاضلات المطلوبة لتقديم قابلية وصول عالية.
في مصطلحات نظرية CAP، Cassandra هو بشكل افتراضي نظام قاعدة بيانات AP (متسامح مع القسم المتوفر)، مع تناسق قابل للضبط للغاية. بالنسبة لمعظم حالات الاستخدام، نوصي باستخدام local_quorum للقراءات.
- في active-passive للكتابات هناك مفاضلة بين الموثوقية والأداء: للموثوقية نوصي QUORUM_EACH ولكن بالنسبة لمعظم المستخدمين LOCAL_QUORUM أو QUORUM هو حل وسط جيد. ومع ذلك، لاحظ أنه في حالة انقطاع إقليمي، قد يتم فقدان بعض الكتابات في LOCAL_QUORUM.
- في حالة تشغيل تطبيق بالتوازي QUORUM_EACH يفضل الكتابة لمعظم الحالات لضمان الاتساق بين مركزي البيانات.
- إذا كان هدفك هو تفضيل التناسق (RPO أقل) بدلا من زمن الانتقال أو التوفر (RTO أقل)، يجب أن ينعكس هذا في إعدادات التناسق وعامل النسخ المتماثل. كقاعدة عامة، يجب أن يكون عدد عقد الحصة المطلوبة للقراءة بالإضافة إلى عدد عقد الحصة المطلوبة للكتابة أكبر من عامل النسخ المتماثل. على سبيل المثال، إذا كان لديك عامل النسخ المتماثل 3، quorum_one على القراءات (عقدة واحدة)، يجب عليك القيام quorum_all على عمليات الكتابة (ثلاث عقد)، بحيث يكون الإجمالي 4 أكبر من عامل النسخ المتماثل 3.
إشعار
سيتم نشر عامل تشغيل وحدة التحكم لمثيل Azure المدار ل Apache Cassandra فقط في منطقة واحدة (المنطقة المحددة عند نشر مركز البيانات الأول في البداية). في حالة حدوث انقطاع إجمالي للمنطقة غير محتمل، نلتزم بوقت استرداد لمدة 3 ساعات للفشل في وحدة التحكم إلى منطقة أخرى. لا يؤثر هذا على توفر اتفاقية مستوى الخدمة للخدمة، حيث يجب أن تستمر مراكز البيانات في العمل. ومع ذلك، خلال هذه الفترة، قد لا يكون من الممكن إجراء تغييرات على تكوين قاعدة البيانات من المدخل أو أدوات موفر الموارد.
النسخ المتماثل
نوصي بالتدقيق keyspaces وإعدادات النسخ المتماثل الخاصة بها من وقت لآخر لضمان تكوين النسخ المتماثل المطلوب بين مراكز البيانات. في المراحل المبكرة من التطوير، نوصي باختبار أن كل شيء يعمل كما هو متوقع من خلال إجراء اختبارات بسيطة باستخدام cqlsh. على سبيل المثال، إدراج قيمة أثناء الاتصال بمركز بيانات واحد وقراءتها من الآخر.
على وجه الخصوص، عند إعداد مركز بيانات ثان حيث يحتوي مركز بيانات موجود بالفعل على بيانات، من المهم تحديد أن جميع البيانات قد تم نسخها نسخا متماثلا وأن النظام جاهز. نوصي بمراقبة تقدم النسخ المتماثل من خلال أوامر DBA الخاصة بنا باستخدام nodetool netstats. سيكون النهج البديل هو حساب الصفوف في كل جدول، ولكن ضع في اعتبارك أنه مع أحجام البيانات الضخمة، نظرا للطبيعة الموزعة ل Cassandra، يمكن أن يعطي هذا تقديرا تقريبيا فقط.
موازنة تكلفة التعافي من الكوارث
إذا كان تطبيقك "نشط-سلبي"، فلا نزال نوصي عموما بنشر نفس السعة في كل منطقة بحيث يمكن أن يفشل تطبيقك على الفور في مركز بيانات "الاستعداد السريع" في منطقة ثانوية. وهذا يضمن عدم تدهور الأداء في حالة انقطاع التيار الكهربائي الإقليمي. توفر معظم برامج تشغيل عميل Cassandra خيارات لبدء تجاوز الفشل على مستوى التطبيق. بشكل افتراضي، يفترضون انقطاع إقليمي يعني أن التطبيق أيضا معطلة، وفي هذه الحالة يجب أن يحدث تجاوز الفشل على مستوى موازن التحميل.
ومع ذلك، لتقليل تكلفة توفير مركز بيانات ثان، قد تفضل نشر SKU أصغر وعقد أقل، في منطقتك الثانوية. عند حدوث انقطاع، يصبح التحجيم أسهل في Azure Managed Instance ل Apache Cassandra عن طريق التحجيم العمودي والأفقي الجاهز. بينما تفشل تطبيقاتك في منطقتك الثانوية، يمكنك توسيع نطاق العقد وتوسيع نطاقها يدويا في مركز البيانات الثانوي. في هذه الحالة، يعمل مركز البيانات الثانوي كإعداد احتياطي منخفض التكلفة. يجب أن يكون اتباع هذا النهج متوازنا مع الوقت المطلوب لاستعادة نظامك إلى السعة الكاملة في حالة انقطاع التيار الكهربائي. من المهم اختبار ما يحدث عند فقدان منطقة وممارسته.
إشعار
زيادة حجم العقد أسرع بكثير من التوسع. ضع هذا في اعتبارك عند النظر في التوازن بين المقياس العمودي والأفقي، وعدد العقد المراد نشرها في نظام المجموعة.
جداول النسخ الاحتياطي
النسخ الاحتياطية تلقائية في Azure Managed Instance ل Apache Cassandra، ولكن يمكنك اختيار جدولك الزمني للنسخ الاحتياطية اليومية. نوصي باختيار الأوقات ذات الحمل الأقل. على الرغم من تكوين النسخ الاحتياطية لاستهلاك وحدة المعالجة المركزية الخاملة فقط، إلا أنها يمكن أن تؤدي في بعض الحالات إلى ضغطات في Cassandra، ما يمكن أن يؤدي إلى زيادة في استخدام وحدة المعالجة المركزية. يمكن أن تحدث الضغطات في أي وقت باستخدام Cassandra، وتعتمد على حمل العمل واستراتيجية الضغط المختارة.
هام
الهدف من النسخ الاحتياطي هو مجرد التخفيف من فقدان البيانات العرضي أو تلف البيانات. لا نوصي بالنسخ الاحتياطية كاستراتيجية للتعافي من الكوارث. النسخ الاحتياطية ليست متكررة جغرافيا، وحتى لو كانت كذلك، فقد يستغرق استرداد قاعدة بيانات من النسخ الاحتياطية وقتا طويلا جدا. لذلك، نوصي بشدة بإجراء عمليات نشر متعددة المناطق، إلى جانب تمكين مناطق التوفر حيثما أمكن، للتخفيف من سيناريوهات الكوارث، والقدرة على التعافي منها بفعالية. هذا مهم بشكل خاص في السيناريوهات النادرة حيث لا يمكن تغطية المنطقة الفاشلة، حيث قد تفقد جميع البيانات دون النسخ المتماثل متعدد المناطق.
الخطوات التالية
في هذه المقالة، وضعنا بعض أفضل الممارسات لبناء تطبيقات مرنة باستخدام Cassandra.