عمليات الإدارة في مثيل Azure المُدار لـ Apache Cassandra

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

الضغط

  • هناك أنواع مختلفة من الضغط. نقوم حاليا بإجراء ضغط بسيط عبر الإصلاح (راجع الصيانة). يؤدي هذا إلى ضغط شجرة Merkle، وهو نوع خاص من الضغط.
  • اعتمادا على استراتيجية الضغط التي تم تعيينها على الجدول باستخدام CQL (على سبيل المثال WITH compaction = { 'class' : 'LeveledCompactionStrategy' })، يضغط Cassandra تلقائيا عندما يصل الجدول إلى حجم معين. نوصي بتحديد استراتيجية ضغط بعناية لحمل العمل الخاص بك، ولا تقم بأي ضغط يدوي خارج الاستراتيجية.

التصحيح

  • يتم إجراء تصحيحات على مستوى نظام التشغيل تلقائياً في إيقاع أسبوعين تقريباً.

  • يتم إجراء التصحيحات على مستوى برنامج Apache Cassandra عند التعرف على نقاط الضعف الأمنية. قد يختلف إيقاع التصحيح.

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

  • الإصدار في Apache Cassandra بتنسيق X.Y.Z. يمكنك التحكم في نشر الإصدارات الرئيسية (س) والثانوية (ث) يدوياً عبر أدوات الخدمة. في حين أن تصحيحات Cassandra (Z) التي قد تكون مطلوبة لهذا المزيج الرئيسي/الثانوي يتم إصدار تلقائياً.

إشعار

تدعم الخدمة حاليا إصداري Cassandra 3.11 و4.0. كلا الإصدارين هما GA. راجع التشغيل السريع ل Azure CLI (الخطوة 5) لتحديد إصدار Cassandra أثناء نشر نظام المجموعة.

صيانة

  • يتم تشغيل إصلاح Nodetool تلقائياً من قبل الخدمة باستخدام ريبر. يتم تشغيل هذه الأداة مرة واحدة كل أسبوع. قد ترغب في تعطيله إذا كنت تستخدم الخدمة الخاصة بك للنشر المختلط.

  • تتكون مراقبة صحة العقدة من:

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

يدعم

يوفر مثيل Azure المدار ل Apache Cassandra اتفاقية مستوى الخدمة لتوفر مراكز البيانات في نظام مجموعة مدار. إذا واجهت أي مشكلات في استخدام الخدمة، فقدم طلب دعم في مدخل Microsoft Azure.

تشمل مزايا الدعم لدينا ما يلي:

  • نقطة اتصال واحدة لمشكلات البنية الأساسية Cassandra - لا حاجة لرفع حالات الدعم مع فرق IaaS (القرص والحوسبة والشبكات) بشكل منفصل.
  • تقديم المشورة المحترفة عبر البريد الإلكتروني حول رقبة زجاجة الأداء والتحجيم وغيرها من مشكلات قيود الموارد.
  • تغطية دعم 24x7، بما في ذلك الحوادث التي تم إنشاؤها تلقائيا لأي مشكلات انقطاع شديدة.
  • دعم التصحيح المعتمد من المجتمع (راجع التصحيح).
  • دعم فريق هندسة Java JDK/JVM الداخلي.
  • دعم نظام تشغيل Linux مع أمان سلسلة توريد البرامج.

هام

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

ومن الأمثلة على هذه المشكلات ما يلي:

  • عمليات الاستعلام غير فعالة.
  • الإنتاجية التي تتجاوز السعة.
  • استيعاب البيانات التي تتجاوز سعة التخزين.
  • إعدادات تكوين مساحة المفتاح غير صحيحة.
  • نموذج بيانات ضعيف أو إستراتيجية مفتاح القسم.

في حالة التحقيق في حالة دعم واكتشاف أن السبب الجذري للمشكلة هو على مستوى تكوين Apache Cassandra (وليس أي جوانب أساسية على مستوى النظام الأساسي نحتفظ بها)، سنظل نقدم توصيات وإرشادات حول المعالجة، أو التخفيف (عندما يكون ذلك ممكنا)، قبل إغلاق الحالة.

نوصي بتمكين المقاييس و/أو التعرف على تكامل مراقبة Azure لمنع مشكلات مستوى التطبيق/التكوين الشائعة في Apache Cassandra، مثل ما سبق.

تحذير

يتيح لك Azure Managed Instance ل Apache Cassandra أيضا تشغيل nodetool وأوامر sstable لإدارة DBA الروتينية - راجع المقالة هنا. يمكن لبعض هذه الأوامر زعزعة نظام مجموعة cassandra ويجب تشغيلها بعناية فقط وبعد اختبارها في بيئات غير إنتاجية. حيثما أمكن، --dry-run يجب نشر خيار أولا. لا يمكن لشركة Microsoft تقديم أي اتفاقية مستوى خدمة أو دعم بشأن المشكلات المتعلقة بتشغيل الأوامر التي تغير تكوين قاعدة البيانات الافتراضية و/أو الجداول.

النسخ الاحتياطي والاستعادة

يتم تمكين النسخ الاحتياطية للقطة بشكل افتراضي ويتم أخذها كل 24 ساعة. يتم تخزين النسخ الاحتياطية في حساب تخزين Azure Blob داخلي ويتم الاحتفاظ بها لمدة تصل إلى يومين (48 ساعة). لا توجد تكلفة للنسخ الاحتياطية الأولية 2. يتم فرض رسوم على النسخ الاحتياطية الإضافية، راجع التسعير. لتغيير الفاصل الزمني للنسخ الاحتياطي أو فترة الاستبقاء، يمكنك تحرير النهج في المدخل:

Screenshot of backup schedule configuration page.

للاستعادة من نسخة احتياطية موجودة، قم بتقديم طلب دعم في مدخل Microsoft Azure. عند تقديم حالة الدعم، تحتاج إلى:

  1. قم بتوفير معرف النسخ الاحتياطي من المدخل للنسخة الاحتياطية التي تريد استعادتها. يمكن العثور على هذا في المدخل:

    Screenshot of backup schedule configuration page highlighting backup ID.

  2. إذا لم تكن استعادة المجموعة بأكملها مطلوبة، فوفر مساحة المفتاح والجدول (إن أمكن) التي تحتاج إلى استعادة.

  3. تقديم المشورة ما إذا كنت تريد استعادة النسخة الاحتياطية في نظام المجموعة الحالي، أو في نظام مجموعة جديد.

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

  5. يمكنك أيضا تحديد ما إذا كنت تريد الاحتفاظ system_auth بمساحة المفاتيح في نظام المجموعة الهدف الجديد أو السماح للاستعادة بالكتابة فوقها بالبيانات من النسخة الاحتياطية. system_auth تحتوي مساحة المفتاح في Cassandra على بيانات التخويل والمصادقة الداخلية، بما في ذلك الأدوار وأذونات الدور وكلمات المرور. لاحظ أن عملية الاستعادة الافتراضية system_auth الخاصة بنا تستبدل مساحة المفتاح.

إشعار

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

تحذير

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

الأمان

يوفر مثيل Azure المُدار لـ Apache Cassandra العديد من عناصر التحكم والميزات الأمنية الصريحة المضمنة:

  • تصلب صور الأجهزة الظاهرية التي تعمل بنظام Linux مع سلسلة الإمدادات التي تسيطر عليها.
  • مراقبة الثغرات الأمنية والتعرض للهجمات (CVE) الشائعة على مستوى نظام التشغيل.
  • تناوب شهادة لكل من برنامجي Apache Cassandra وPrometheus المستضافين على الأجهزة الظاهرية المُدارة.
  • مسح الثغرة الأمنية النشطة.
  • فحص الفيروسات النشطة.
  • ممارسات ترميز آمنة.

لمزيد من المعلومات حول ميزات الأمان، راجع مقالتنا هنا.

الدعم المختلط

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

الخطوات التالية

اشرع في العمل من خلال إحدى بداياتنا السريعة: