إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تنبيه
تشير هذه المقالة إلى CentOS، وهو توزيع Linux هو نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.
توضح هذه المقالة اعتبارات الأداء لتشغيل Apache Cassandra على أجهزة Azure الظاهرية.
تستند هذه التوصيات إلى نتائج اختبارات الأداء، والتي يمكنك العثور عليها على GitHub. يجب عليك استخدام هذه التوصيات كأساس ثم اختبارها مقابل حمل العمل الخاص بك.
Azure Managed Instance لـ Apache Cassandra
إذا كنت تبحث عن خدمة أكثر تلقائية لتشغيل Apache Cassandra على أجهزة Azure الظاهرية، ففكر في استخدام Azure Managed Instance ل Apache Cassandra. تعمل هذه الخدمة على أتمتة توزيع العقد وإدارتها (تصحيحها وصحة العقدة) وتوسيع نطاقها داخل نظام مجموعة Apache Cassandra. كما توفر إمكانية أنظمة المجموعات المختلطة، بحيث يمكن لمراكز بيانات Apache Cassandra الموزعة في Azure الانضمام إلى حلقة Cassandra محلية أو خارجية مستضافة. يتم نشر الخدمة باستخدام Azure Virtual Machine Scale Sets. تم اعتماد التوصيات التالية أثناء تطوير هذه الخدمة.
أحجام أجهزة Azure الظاهرية وأنواع الأقراص
تستخدم أحمال عمل Cassandra على Azure عادة إما Standard_DS14_v2 أو Standard_DS13_v2 أو Standard_D16s_v5 أو الأجهزة الظاهرية Standard_E16s_v5. تستفيد أحمال عمل Cassandra من وجود المزيد من الذاكرة في الجهاز الظاهري، لذا ضع في اعتبارك أحجام الجهاز الظاهري المحسنة للذاكرة، مثل Standard_DS14_v2 أو Standard_E16s_v5 أو أحجام التخزين المحلية المحسنة مثل Standard_L16s_v3.
لأغراض القدرة على الصمود، يتم تخزين البيانات وسجلات التثبيت عادة على مجموعة شريطية مكونة من قرصين إلى أربعة أقراص مدارة متميزة بحجم 1 تيرابايت (P30).
لا ينبغي أن تكون عقد Cassandra كثيفة البيانات للغاية. نوصي بوجود 1 - 2 تيرابايت على الأكثر من البيانات لكل جهاز ظاهري ومساحة حرة كافية للضغط. لتحقيق أعلى قدر ممكن من معدل النقل المجمعة وعملية إدخال / إخراج في الثانية باستخدام الأقراص المتميزة المُدارة، نوصي بإنشاء مجموعة شرائط من عدد قليل من الأقراص سعة 1 تيرابايت، بدلاً من استخدام قرص واحد بسعة 2 تيرابايت أو 4 تيرابايت. على سبيل المثال، على جهاز ظاهري DS14_v2، تحتوي 4 أقراص بسعة 1 تيرابايت على عمليات الإدخال / الإخراج في الثانية بحد أقصى 4 × 5000 = 20 ألف، مقابل 7.5 آلاف لقرص واحد بسعة 4 تيرابايت.
تقييم أقراص Azure Ultra لأحمال عمل Cassandra التي تحتاج إلى سعة قرص أصغر. يمكن أن توفر معدل نقل/عمليات الإدخال والإخراج في الإخراج في السعة أعلى وزمن انتقال أقل على أحجام الأجهزة الظاهرية مثل Standard_E16s_v5 Standard_D16s_v5.
بالنسبة لأحمال عمل Cassandra التي لا تحتاج إلى تخزين دائم - أي حيث يمكن إعادة بناء البيانات بسهولة من وسيط تخزين آخر - فكر في استخدام Standard_L16s_v3 أو Standard_L16s_v2 VMs. تحتوي أحجام الأجهزة الظاهرية هذه على أقراص NVM Express (NVMe) مؤقتة محلية كبيرة وسريعة.
لمزيد من المعلومات، راجع مقارنة أداء الأقراص المحلية/المؤقتة في Azure مقابل الأقراص المرفقة/الثابتة (GitHub).
تسريع الشبكات
تستخدم عقد Cassandra الشبكة بشكل مكثف لإرسال البيانات وتلقيها من الجهاز الظاهري للعميل وللتواصل بين العقد للنسخ المتماثل. للحصول على الأداء الأمثل، تستفيد أجهزة Cassandra الظاهرية من معدل النقل العالي وشبكة زمن الانتقال المنخفض.
نوصي بتمكين الشبكات المتسارعة على NIC لعقدة Cassandra وعلى الأجهزة الظاهرية التي تشغل تطبيقات العميل التي تصل إلى Cassandra.
تتطلب الشبكات المتسارعة توزيع Linux حديث مع أحدث برامج التشغيل، مثل Cent OS 7.5+ أو Ubuntu 16.x/18.x. لمزيد من المعلومات، راجع إنشاء جهاز ظاهري Linux باستخدام الشبكات المتسارعة.
التخزين المؤقت لقرص بيانات جهاز Azure الظاهري
أداء أحمال عمل قراءة Cassandra بشكل أفضل عندما يكون زمن انتقال القرص العشوائي منخفضاً. نوصي باستخدام الأقراص المدارة من Azure مع تمكين التخزين المؤقت ReadOnly. يوفر التخزين المؤقت ReadOnly زمن انتقال أقل، لأن البيانات تتم قراءتها من ذاكرة التخزين المؤقت على المضيف بدلاً من الانتقال إلى تخزين الخلفية.
تستفيد أحمال العمل كثيفة القراءة والقراءة العشوائية، مثل Cassandra من زمن انتقال القراءة المنخفض على الرغم من أن الوضع المخزن مؤقتاً له حدود معدل نقل أقل من الوضع غير المخزن مؤقتاً. (على سبيل المثال، DS14_v2 الأجهزة الظاهرية لديها الحد الأقصى لمعدل النقل المخزن مؤقتا من 512 ميغابت في الثانية مقابل 768 ميغابت في الثانية.)
يعد التخزين المؤقت ReadOnly مفيدا بشكل خاص للسلسلة الزمنية Cassandra وأحمال العمل الأخرى حيث تناسب مجموعة بيانات العمل في ذاكرة التخزين المؤقت للمضيف ولا تتم الكتابة فوق البيانات باستمرار. على سبيل المثال، يوفر DS14_v2 حجم ذاكرة التخزين المؤقت 512 غيغابايت، والتي يمكن أن تخزن ما يصل إلى 50% من البيانات من عقدة Cassandra بكثافة بيانات تبلغ 1-2 تيرابايت.
لا توجد عقوبة أداء كبيرة من أخطاء ذاكرة التخزين المؤقت عند تمكين التخزين المؤقت ReadOnly، لذلك يوصى بوضع التخزين المؤقت لجميع أحمال العمل باستثناء أحمال العمل الأكثر كثافة في الكتابة.
لمزيد من المعلومات، راجع مقارنة تكوينات التخزين المؤقت لقرص بيانات Azure VM (GitHub).
القراءة المسبقة لـ Linux
في معظم توزيعات Linux في Azure Marketplace، يكون إعداد القراءة المسبقة لجهاز الكتلة الافتراضي هو 4096 كيلوبايت. قراءة Cassandra I/OS عادة ما تكون عشوائية وصغيرة نسبيا. لذلك، فإن وجود معدل نقل كبير للقراءة المسبقة يضيع عن طريق قراءة أجزاء من الملفات غير المطلوبة.
لتقليل رأس البحث غير الضروري، قم بتعيين إعداد القراءة المسبقة لجهاز كتلة Linux إلى 8 كيلوبايت. (راجع إعدادات الإنتاج الموصى بها في وثائق DataStax.)
تكوين القراءة المسبقة 8 كيلوبايت لجميع أجهزة الكتلة في مجموعة الشريط وعلى جهاز الصفيف نفسه (على سبيل المثال، /dev/md0).
لمزيد من المعلومات، راجع مقارنة تأثير إعدادات القراءة المسبقة للقرص (GitHub).
حجم مجموعة مصفوفة القرص mdadm
عند تشغيل Cassandra على Azure، من الشائع إنشاء مجموعة شريطية mdadm (أي RAID 0) لأقراص بيانات متعددة لزيادة معدل النقل الإجمالي للقرص ومعدل الإدخال / الإخراج في الثانية الأقرب إلى حدود الجهاز الظاهري. الحجم الأمثل لشريط القرص هو إعداد خاص بالتطبيق. على سبيل المثال، بالنسبة لأحمال عمل OLTP لـ SQL Server، فإن التوصية هي 64 كيلوبايت. بالنسبة لأحمال عمل مستودع البيانات، فإن التوصية هي 256 كيلوبايت.
لم تجد اختباراتنا فرقاً كبيراً بين أحجام المجموعات التي تبلغ 64 ألف و128 ألف و256 ألف لأحمال عمل قراءة Cassandra. يبدو أن هناك ميزة صغيرة، ملحوظة إلى حد ما، لحجم المجموعة البالغ 128 ألف. لذلك، نوصي بما يلي:
إذا كنت تستخدم بالفعل حجم مجموعة من 64 K أو 256 K، فلا معنى لإعادة إنشاء صفيف القرص لاستخدام حجم 128 كيلوبايت.
لتكوين جديد، من المنطقي استخدام 128 كيلوبايت من البداية.
لمزيد من المعلومات، راجع قياس تأثير أحجام مجموعات mdadm على أداء Cassandra (GitHub).
تثبيت نظام ملفات السجل
تقوم كتابات Cassandra بأداء أفضل عندما تكون سجلات التثبيت على أقراص ذات معدل نقل عالٍ وزمن انتقال منخفض. في التكوين الافتراضي، تقوم Cassandra 3.x بمسح البيانات من الذاكرة إلى ملف سجل التثبيت كل ~10 ثوانٍ، ولا تلمس القرص لكل كتابة. في هذا التكوين، يكون أداء الكتابة متطابقًا تقريباً سواء أكان سجل التثبيت على الأقراص المرفقة المتميزة مقابل الأقراص المحلية/سريعة الزوال.
يجب أن تكون سجلات التثبيت دائمة، بحيث يمكن للعقدة التي تمت إعادة تشغيلها إعادة إنشاء أي بيانات غير موجودة بعد في ملفات البيانات من سجلات التثبيت المتدفقة. للحصول على قدرة أفضل على الصمود، قم بتخزين سجلات التثبيت على الأقراص المدارة المتميزة وليس على مساحة التخزين المحلية، والتي يمكن فقدها إذا تم ترحيل الجهاز الظاهري إلى مضيف آخر.
استناداً إلى اختباراتنا، قد يكون لدى Cassandra على CentOS 7.x أداء كتابة أقل عندما تكون سجلات التثبيت على نظام ملفات xfs مقابل ext4. يؤدي تشغيل ضغط سجل التثبيت إلى تحقيق أداء xfs تماشياً مع ext4. تعمل xfs المضغوطة بالإضافة إلى ext4 المضغوطة وغير المضغوطة في اختباراتنا.
لمزيد من المعلومات، راجع الملاحظات على أنظمة ملفات ext4 وxfs وسجلات التثبيت المضغوطة (GitHub).
قياس أداء الجهاز الظاهري الأساسي
بعد توزيع الأجهزة الظاهرية لحلقة Cassandra، قم بإجراء بعض الاختبارات الاصطناعية لإنشاء شبكة أساسية وأداء القرص. استخدم هذه الاختبارات للتأكد من أن الأداء يتماشى مع التوقعات، استناداً إلى حجم الجهاز الظاهري.
في وقت لاحق، عند تشغيل حمل العمل الفعلي، فإن معرفة أساس الأداء يجعل من السهل التحقيق في الاختناقات المحتملة. على سبيل المثال، يمكن أن تساعد معرفة الأداء الأساسي للخروج من الشبكة على الجهاز الظاهري في استبعاد الشبكة كاختناق.
لمزيد من المعلومات حول تشغيل اختبارات الأداء، راجع التحقق من صحة أداء جهاز Azure الظاهري الأساسي (GitHub).
حجم المستند
يعتمد أداء القراءة والكتابة في Cassandra على حجم المستند. يمكنك أن تتوقع رؤية زمن انتقال أعلى وعمليات أقل/في الثانية عند القراءة أو الكتابة باستخدام مستندات أكبر.
لمزيد من المعلومات، راجع مقارنة الأداء النسبي لمختلف أحجام مستندات Cassandra (GitHub).
عامل النسخ المتماثل
تستخدم معظم أحمال عمل Cassandra عامل النسخ المتماثل (RF) من 3 عند استخدام الأقراص المتميزة المرفقة وحتى 5 عند استخدام أقراص محلية مؤقتة/سريعة الزوال. يجب أن يكون عدد العقد في حلقة Cassandra مضاعفاً لعامل النسخ المتماثل. على سبيل المثال، يتضمن RF 3 حلقة من 3 أو 6 أو 9 أو 12 عقدة، بينما سيكون لـ RF 5 5 أو 10 أو 15 أو 20 عقدة. عند استخدام RF أكبر من 1 ومستوى تناسق LOCAL_QUORUM، من الطبيعي أن يكون أداء القراءة والكتابة أقل من نفس حمل العمل الذي يعمل مع RF 1.
لمزيد من المعلومات، راجع مقارنة الأداء النسبي لمختلف عوامل النسخ المتماثل (GitHub).
التخزين المؤقت لصفحة Linux
عندما تقرأ التعليمات البرمجية Java الخاصة ب Cassandra ملفات البيانات، فإنها تستخدم إدخال/إخراج ملف عادي وفوائد من التخزين المؤقت لصفحة Linux. بعد قراءة أجزاء من الملف مرة واحدة، يتم تخزين محتوى القراءة في ذاكرة التخزين المؤقت لصفحة نظام التشغيل. يعد الوصول للقراءة اللاحقة إلى نفس البيانات أسرع بكثير.
لهذا السبب، عند تنفيذ اختبارات أداء القراءة مقابل نفس البيانات، ستظهر القراءات الثانية واللاحقة أسرع بكثير من القراءة الأصلية، والتي تحتاج إلى الوصول إلى البيانات على قرص البيانات البعيد أو من ذاكرة التخزين المؤقت للمضيف عند تمكين ReadOnly. للحصول على قياسات أداء مماثلة على عمليات التشغيل اللاحقة، قم بإلغاء تحديد ذاكرة التخزين المؤقت لصفحة Linux وإعادة تشغيل خدمة Cassandra لمسح ذاكرتها الداخلية. عند تمكين التخزين المؤقت ReadOnly، قد تكون البيانات في ذاكرة التخزين المؤقت للمضيف، وستكون القراءات اللاحقة أسرع حتى بعد مسح ذاكرة التخزين المؤقت لصفحة نظام التشغيل وإعادة تشغيل خدمة Cassandra.
لمزيد من المعلومات، راجع الملاحظات حول استخدام Cassandra للتخزين المؤقت لصفحة Linux (GitHub).
النسخ المتماثل متعدد مراكز البيانات
يدعم Cassandra في الأصل مفهوم مراكز البيانات المتعددة، ما يجعل من السهل تكوين حلقة Cassandra واحدة عبر مناطق Azure متعددة أو عبر مناطق التوفر داخل منطقة واحدة.
بالنسبة للتوزيع متعدد المناطق، استخدم تناظر الشبكات الظاهرية العمومية من Azure لتوصيل الشبكات الظاهرية في المناطق المختلفة. عند توزيع الأجهزة الظاهرية في نفس المكان ولكن في مناطق توفر منفصلة، يمكن أن تكون الأجهزة الظاهرية في نفس الشبكة الظاهرية.
من المهم قياس زمن انتقال البيانات الأساسية بين المناطق. يمكن أن يكون زمن انتقال الشبكة بين المناطق أعلى من زمن الانتقال داخل المنطقة بـ 10 إلى 100 مرة. توقع حدوث تأخير بين البيانات التي تظهر في المنطقة الثانية عند استخدام تناسق الكتابة LOCAL_QUORUM، أو انخفاض أداء عمليات الكتابة بشكل ملحوظ عند استخدام EACH_QUORUM.
عند تشغيل Apache Cassandra على نطاق واسع، وتحديدا في بيئة متعددة DC، يصبح إصلاح العقدة أمرا صعبا. يمكن أن تساعد أدوات مثل ريبر في تنسيق الإصلاحات على نطاق واسع (على سبيل المثال، عبر جميع العقد في مركز البيانات، مركز بيانات واحد في كل مرة، للحد من الحمل على المجموعة بأكملها). ومع ذلك، فإن إصلاح العقدة للمجموعات الكبيرة ليس مشكلة تم حلها بالكامل حتى الآن وينطبق في جميع البيئات، سواء في الموقع أو في السحابة.
عند إضافة العقد إلى منطقة ثانوية، لا يتم قياس الأداء خطيا، لأنه يتم إنفاق بعض النطاق الترددي وموارد وحدة المعالجة المركزية/القرص على تلقي وإرسال حركة مرور النسخ المتماثل عبر المناطق.
لمزيد من المعلومات، راجع قياس تأثير النسخ المتماثل متعدد مراكز البيانات عبر المناطق (GitHub).
تكوين التسليم المزود بتلميحات
في حلقة Cassandra متعددة المناطق، قد تفقد أحمال عمل الكتابة بمستوى تناسق LOCAL_QUORUM البيانات في المنطقة الثانوية. بشكل افتراضي، يتم تقييد التسليم الذي ألمح إليه Cassandra إلى معدل نقل أقصى منخفض نسبيا ومدة بقاء تلميح لمدة ثلاث ساعات. بالنسبة لأحمال العمل ذات عمليات الكتابة الثقيلة، نوصي بزيادة وقت نافذة التسليم والتلميح الملمح لضمان عدم إسقاط التلميحات قبل نسخها نسخا متماثلا.
لمزيد من المعلومات، راجع الملاحظات حول التسليم المزود بتلميحات في النسخ المتماثل عبر المناطق (GitHub).
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- آرسن فلاديميرسكي | مهندس العملاء الرئيسي
المساهم الآخر:
- يتو فان كراي | مدير أول للبرنامج
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
لمزيد من المعلومات حول نتائج الأداء هذه، راجع Cassandra على تجارب أداء أجهزة Azure الظاهرية.
للحصول على معلومات حول إعدادات Cassandra العامة، غير الخاصة بـ Azure، راجع: