ما هي أفضل الممارسات لمستويات Enterprise وEnterprise Flash
فيما يلي أفضل الممارسات عند استخدام مستويات Enterprise وEnterprise Flash في ذاكرة التخزين المؤقت Azure ل Redis.
التكرار في المنطقة
نوصي بشدة بنشر ذاكرات التخزين المؤقت الجديدة في تكوين المنطقة المكرر . يضمن التكرار في المنطقة انتشار عقد Redis Enterprise بين ثلاث مناطق توفر، ما يعزز التكرار من الانقطاعات على مستوى مركز البيانات. يؤدي استخدام التكرار في المنطقة إلى زيادة التوفر. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة (SLA) للخدمات عبر الإنترنت.
يعد التكرار في المنطقة مهما على مستوى المؤسسة لأن مثيل ذاكرة التخزين المؤقت يستخدم دائما ثلاث عقد على الأقل. عقدتان هما عقد البيانات، التي تحتفظ ببياناتك، وعقدة الحصة. زيادة السعة تحجيم عدد عقد البيانات بزيادات زوجية العدد.
هناك أيضا عقدة أخرى تسمى عقدة الحصة. تراقب هذه العقدة عقد البيانات وتختار تلقائيا العقدة الأساسية الجديدة إذا كان هناك تجاوز فشل. يضمن التكرار في المنطقة توزيع العقد بالتساوي عبر ثلاث مناطق توفر، ما يقلل من احتمال فقدان الحصة. لا يتم فرض رسوم على العملاء مقابل عقدة الحصة ولا توجد رسوم أخرى لاستخدام تكرار المنطقة بعد رسوم النطاق الترددي داخل المناطق.
تغير الحجم
في مستويات Enterprise وEnterprise Flash من ذاكرة التخزين المؤقت Azure ل Redis، نوصي بتحديد أولويات التحجيم على توسيع النطاق. تحديد أولويات التحجيم لأن مستويات المؤسسة مبنية على Redis Enterprise، والتي يمكنها استخدام المزيد من مراكز وحدة المعالجة المركزية في أجهزة ظاهرية أكبر.
وعلى العكس من ذلك، فإن التوصية المعاكسة صحيحة للمستويات الأساسية والقياسية والمتميزة، والتي تم إنشاؤها على Redis مفتوحة المصدر. في هذه المستويات، يوصى بتحديد أولويات التوسع على التحجيم لأعلى في معظم الحالات.
التقسيم واستخدام وحدة المعالجة المركزية
في المستويات الأساسية والقياسية والمتميزة من Azure Cache for Redis، يكون تحديد عدد وحدات المعالجة المركزية الظاهرية (vCPUs) المستخدمة أمرا مباشرا. تعمل كل عقدة Redis على جهاز ظاهري مخصص. عملية خادم Redis ذات ترابط واحد، باستخدام وحدة معالجة مركزية ظاهرية واحدة على كل عقدة أساسية وكل عقدة نسخة متماثلة. لا تزال وحدات المعالجة المركزية الظاهرية الأخرى على الجهاز الظاهري تستخدم لأنشطة أخرى، مثل تنسيق سير العمل للمهام المختلفة، ومراقبة الصحة، وتحميل TLS، من بين مهام أخرى.
عند استخدام نظام المجموعة، يكون التأثير هو نشر البيانات عبر المزيد من العقد مع جزء واحد لكل عقدة. من خلال زيادة عدد الأجزاء، يمكنك زيادة عدد وحدات المعالجة المركزية الظاهرية التي تستخدمها خطيا، استنادا إلى عدد الأجزاء في نظام المجموعة.
من ناحية أخرى، يمكن ل Redis Enterprise استخدام وحدات vCPUs متعددة لمثيل Redis نفسه. بمعنى آخر، يمكن لجميع مستويات Azure Cache for Redis استخدام وحدات vCPUs متعددة لمهام الخلفية والمراقبة، ولكن فقط طبقات Enterprise وEnterprise Flash قادرة على استخدام وحدات vCPUs متعددة لكل جهاز ظاهري لأجزاء Redis. يعرض الجدول عدد وحدات المعالجة المركزية الظاهرية الفعالة المستخدمة لكل تكوين SKU وسعة (أي توسيع النطاق).
تعرض الجداول عدد وحدات المعالجة المركزية الظاهرية المستخدمة للأجزاء الأساسية، وليس أجزاء النسخ المتماثلة. لا تقوم الأجزاء بتعيين واحد إلى واحد إلى عدد وحدات المعالجة المركزية الظاهرية. توضح الجداول وحدات المعالجة المركزية الظاهرية فقط، وليس الأجزاء. تستخدم بعض التكوينات أجزاء أكثر من وحدات المعالجة المركزية الظاهرية المتاحة لتعزيز الأداء في بعض سيناريوهات الاستخدام.
E5
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| السعة | وحدات المعالجة المركزية الظاهرية الفعالة |
|---|---|
| 3 | 30 |
| 9 | 90 |
تكوين أنظمة المجموعات على المؤسسة
يتم تجميع مستويات Enterprise وEnterprise Flash بطبيعتها، على النقيض من المستويات الأساسية والقياسية والمتميزة. يعتمد التنفيذ على نهج التجميع المحدد. توفر مستويات المؤسسة خيارين لنهج التجميع: OSS وEnterprise. يوصى بنهج نظام مجموعة OSS لمعظم التطبيقات لأنه يدعم أقصى معدل نقل أعلى، ولكن هناك مزايا وعيوب لكل إصدار.
ينفذ نهج نظام المجموعة OSS نفس واجهة برمجة تطبيقات نظام مجموعة Redis مثل Redis مفتوحة المصدر. تسمح واجهة برمجة تطبيقات نظام مجموعة Redis لعميل Redis بالاتصال مباشرة بكل عقدة Redis، ما يقلل من زمن الانتقال وتحسين معدل نقل الشبكة. ونتيجة لذلك، يتم الحصول على قابلية التوسع شبه الخطية عند توسيع نظام المجموعة بمزيد من العقد. يوفر نهج تجميع OSS بشكل عام أفضل زمن انتقال ومعدل نقل، ولكنه يتطلب مكتبة العميل لدعم Redis Clustering. لا يمكن أيضا استخدام نهج تجميع OSS مع الوحدة النمطية RediSearch.
نهج تجميع المؤسسة هو تكوين أبسط يستخدم نقطة نهاية واحدة لجميع اتصالات العميل. يؤدي استخدام نهج تجميع المؤسسة إلى توجيه جميع الطلبات إلى عقدة Redis واحدة يتم استخدامها بعد ذلك كوكيل، وتوجيه الطلبات داخليا إلى العقدة الصحيحة في نظام المجموعة. تتمثل ميزة هذا النهج في أن مكتبات عميل Redis لا تحتاج إلى دعم Redis Clustering للاستفادة من عقد متعددة. الجانب السلبي هو أن وكيل العقدة الواحدة يمكن أن يكون ازدحاما، إما في استخدام الحساب أو معدل نقل الشبكة. نهج تجميع المؤسسة هو النهج الوحيد الذي يمكن استخدامه مع الوحدة النمطية RediSearch.
أوامر متعددة المفاتيح
نظرا لأن مستويات المؤسسة تستخدم تكوينا متفاوت المسافات، فقد ترى CROSSSLOT استثناءات على الأوامر التي تعمل على مفاتيح متعددة. يختلف السلوك اعتمادا على نهج التجميع المستخدم. إذا كنت تستخدم نهج تجميع OSS، تتطلب الأوامر متعددة المفاتيح تعيين جميع المفاتيح إلى نفس فتحة التجزئة.
قد ترى CROSSSLOT أيضا أخطاء في نهج تجميع المؤسسات. يسمح فقط بالأوامر متعددة المفاتيح التالية عبر الفتحات مع تجميع المؤسسة: DELوEXISTSUNLINKMSETMGET.TOUCH
في قواعد البيانات Active-Active، يمكن تشغيل أوامر الكتابة متعددة المفاتيح (DEL، ، MSETUNLINK) فقط على المفاتيح الموجودة في نفس الفتحة. ومع ذلك، يسمح بالأوامر متعددة المفاتيح التالية عبر الفتحات في قواعد البيانات Active-Active: MGETو EXISTSو TOUCH. لمزيد من المعلومات، راجع تجميع قاعدة البيانات.
أفضل ممارسات Enterprise Flash
تستخدم طبقة Enterprise Flash كلا من تخزين NVMe Flash وذاكرة الوصول العشوائي. نظرا لأن تخزين Flash أقل تكلفة، فإن استخدام طبقة Enterprise Flash يسمح لك بمقايضة بعض الأداء لكفاءة السعر.
في مثيلات Enterprise Flash، توجد 20٪ من مساحة ذاكرة التخزين المؤقت على ذاكرة الوصول العشوائي، بينما تستخدم نسبة 80٪ الأخرى تخزين Flash. يتم تخزين جميع المفاتيح على ذاكرة الوصول العشوائي، بينما يمكن تخزين القيم إما في تخزين Flash أو RAM. يتم تحديد موقع القيم بذكاء بواسطة برنامج Redis. يتم تخزين القيم "الساخنة" التي يتم الوصول إليها بشكل فعال على ذاكرة الوصول العشوائي، بينما يتم الاحتفاظ بالقيم "الباردة" الأقل استخداما على Flash. قبل قراءة البيانات أو كتابتها، يجب نقلها إلى ذاكرة الوصول العشوائي، لتصبح بيانات "فعالة".
نظرا لأن Redis سيختار أفضل أداء، سيقوم المثيل أولا بتعبئة ذاكرة الوصول العشوائي المتوفرة قبل إضافة العناصر إلى تخزين Flash. وهذا له بعض الآثار على الأداء:
- عند الاختبار باستخدام ذاكرة منخفضة، قد يكون الأداء وزمن الانتقال أفضل بكثير من مثيل ذاكرة التخزين المؤقت الكامل لأنه يتم استخدام ذاكرة الوصول العشوائي فقط.
- أثناء كتابة المزيد من البيانات إلى ذاكرة التخزين المؤقت، ستنخفض نسبة البيانات في ذاكرة الوصول العشوائي مقارنة بتخزين Flash، مما يؤدي عادة إلى انخفاض زمن الانتقال وأداء معدل النقل أيضا.
أحمال العمل مناسبة تماما لطبقة Enterprise Flash
غالبا ما يكون لأحمال العمل التي من المحتمل أن تعمل بشكل جيد على مستوى Enterprise Flash الخصائص التالية:
- قراءة ثقيلة، مع نسبة عالية من أوامر القراءة لكتابة الأوامر.
- يركز Access على مجموعة فرعية من المفاتيح التي يتم استخدامها بشكل متكرر أكثر من بقية مجموعة البيانات.
- قيم كبيرة نسبيا مقارنة بأسماء المفاتيح. (نظرا لأنه يتم تخزين أسماء المفاتيح دائما في ذاكرة الوصول العشوائي، يمكن أن يصبح هذا ازدحاما لنمو الذاكرة.)
أحمال العمل غير المناسبة تماما لطبقة Enterprise Flash
بعض أحمال العمل لها خصائص وصول أقل تحسينا لتصميم طبقة Flash:
- كتابة أحمال العمل الثقيلة.
- الوصول العشوائي أو الموحد للبيانات للأبوين عبر معظم مجموعة البيانات.
- أسماء مفاتيح طويلة ذات أحجام قيمة صغيرة نسبيا.
معالجة سيناريوهات المنطقة لأسفل باستخدام النسخ المتماثل الجغرافي النشط
النسخ المتماثل الجغرافي النشط هو ميزة قوية لتعزيز التوفر بشكل كبير عند استخدام مستويات المؤسسة من ذاكرة التخزين المؤقت Azure ل Redis. ومع ذلك، يجب عليك اتخاذ خطوات لإعداد ذاكرات التخزين المؤقت إذا كان هناك انقطاع إقليمي.
على سبيل المثال، ضع في اعتبارك هذه التلميحات:
- حدد مسبقا ذاكرة التخزين المؤقت الأخرى في مجموعة النسخ المتماثل الجغرافي للتبديل إليها في حالة تعطل المنطقة.
- تأكد من تعيين جدران الحماية بحيث يمكن لأي تطبيقات وعملاء الوصول إلى ذاكرة التخزين المؤقت للنسخ الاحتياطي المحددة.
- كل ذاكرة تخزين مؤقت في مجموعة النسخ المتماثل الجغرافي لها مفتاح الوصول الخاص بها. حدد كيفية تبديل التطبيق إلى مفاتيح وصول مختلفة عند استهداف ذاكرة التخزين المؤقت للنسخ الاحتياطي.
- إذا تعطل ذاكرة التخزين المؤقت في مجموعة النسخ المتماثل الجغرافي، يبدأ تراكم بيانات التعريف في الحدوث في جميع ذاكرة التخزين المؤقت في مجموعة النسخ المتماثل الجغرافي. لا يمكن تجاهل بيانات التعريف حتى يمكن مزامنة عمليات الكتابة مرة أخرى إلى جميع ذاكرات التخزين المؤقت. يمكنك منع إنشاء بيانات التعريف عن طريق فرض إلغاء ربط ذاكرة التخزين المؤقت المعطلة. ضع في اعتبارك مراقبة الذاكرة المتوفرة في ذاكرة التخزين المؤقت وإلغاء الارتباط إذا كان هناك ضغط على الذاكرة، خاصة بالنسبة لأحمال العمل كثيفة الكتابة.
من الممكن أيضا استخدام نمط قاطع الدائرة. استخدم النمط لإعادة توجيه نسبة استخدام الشبكة تلقائيا بعيدا عن ذاكرة التخزين المؤقت التي تواجه انقطاعا في المنطقة، ونحو ذاكرة تخزين مؤقت للنسخ الاحتياطي في نفس مجموعة النسخ المتماثل الجغرافي. استخدم خدمات Azure مثل Azure Traffic Manager أو Azure Load Balancer لتمكين إعادة التوجيه.
استمرار البيانات مقابل النسخ الاحتياطي للبيانات
تم تصميم ميزة استمرارية البيانات في مستويي Enterprise وEnterprise Flash لتوفير نقطة استرداد سريعة للبيانات تلقائيا عند تعطل ذاكرة التخزين المؤقت. يتم جعل الاسترداد السريع ممكنا عن طريق تخزين ملف RDB أو AOF في قرص مدار يتم تحميله إلى مثيل ذاكرة التخزين المؤقت. لا يمكن للمستخدمين الوصول إلى ملفات الثبات على القرص.
يرغب العديد من العملاء في استخدام الثبات لأخذ نسخ احتياطية دورية من البيانات على ذاكرة التخزين المؤقت الخاصة بهم. لا نوصي باستخدام استمرارية البيانات بهذه الطريقة. بدلا من ذلك، استخدم ميزة الاستيراد/التصدير . يمكنك تصدير نسخ من بيانات ذاكرة التخزين المؤقت بتنسيق RDB مباشرة إلى حساب التخزين الذي اخترته وتشغيل تصدير البيانات بشكل متكرر كما تحتاج. يمكن تشغيل التصدير إما من المدخل أو باستخدام أدوات CLI أو PowerShell أو SDK.