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