توفر عالٍ حسب مستوى الخدمة

مكتمل

لفهم خيارات التوفر والقدرات في Azure SQL، تحتاج إلى فهم مستويات الخدمة. سيتم تحديد مستوى الخدمة الذي يحدده التصميم الأساسي لقاعدة البيانات أو المثيل المُدار الذي تقوم تستخدمه.

هناك اثنان من نماذج الشراء التي يمكنك التفكير بها: DTU و vCore. ستركز هذه الوحدة على مستويات الخدمة vCore وبنيتها للتوفر العالي. يمكنك مقارنة المستويات Basic و Standard لنموذج DTU مع General Purpose ومستويات Premium الخاصة به إلى Business Critical

General Purpose

قواعد البيانات والمثيلات المدارة في مستوى خدمة General Purpose لها نفس تصميم التوفر. باستخدام الشكل التالي كدليل، انظر أولاً في التطبيق وحلقة التحكم. يتصل التطبيق باسم الخادم، والذي يتصل بعد ذلك ببوابة (GW)، والتي تشير إلى اتصال التطبيق بالخادم الصحيح، الذي يعمل على جهاز ظاهري. باستخدام General Purpose، تستخدم النسخة المتماثلة الأساسية SSD المرفقة محليا ل tempdb. يتم تخزين ملفات البيانات والسجل في Azure Premium Storage، والذي هو تخزين احتياطي محليًا (نسخ متعددة في منطقة واحدة). ثم يتم تخزين ملفات النسخ الاحتياطي في Azure Standard Storage وهو RA-GRS بشكل افتراضي. RA-GRS هو تخزين متكرر عالميا، مع نسخ في مناطق متعددة.

كما ناقشنا في وحدة سابقة في هذا المسار التعليمي، تم بناء Azure SQL بأكملها على Azure Service Fabric، الذي يعمل بمثابة العمود الفقري لـ Azure. إذا حدد Azure Service Fabric أنه يجب حدوث تجاوز فشل، فإن تجاوز الفشل سيكون مشابهًا لمثيل نظام مجموعة تجاوز الفشل (FCI). سوف يبحث service fabric عن عقدة ذات سعة إضافية وانتقاء مثيل SQL Server جديد. سيتم بعد ذلك إرفاق ملفات قاعدة البيانات، وسيتم تشغيل الاسترداد، وسيتم تحديث البوابات لتوجيه التطبيقات إلى العقدة الجديدة. لا تحتاج إلى شبكة ظاهرية أو وحدة إصغاء أو تحديثات. هذه الإمكانية مدمجة.

Screenshot that shows the General Purpose architecture.

Business Critical

مستوى الخدمة التالي الذي يجب مراعاته هو Business General، والتي يمكنه بشكل عام تحقيق أعلى مستوى من الأداء والتوفر بين جميع مستويات خدمة Azure SQL (General Purpose، Hyperscale، Business Critical). تم تصميم Business Critical للتطبيقات الضرورية للمهمة، والتي تحتاج إلى زمن انتقال منخفض ووقت تعطل أدنى.

Screenshot that shows the Business Critical architecture.

إن استخدام Business Critical يشبه نشر مجموعة توفر Always On (AG) في الخلفية على عكس مستوى الأغراض العامة، يتم تشغيل ملفات البيانات والسجلات في Business Critical على SSD المرفق مباشرة، ما يقلل بشكل كبير من زمن انتقال الشبكة. (يستخدم General Purpose التخزين عن بعد.) في مجموعة التوفر هذه، هناك ثلاث نسخ متماثلة ثانوية. يمكنك استخدام واحدة منها كنقطة نهاية للقراءة فقط (دون أي رسوم إضافية). يمكن أن تقوم العملية بإكمال تثبيت في حين تقوم واحدة على الأقل من النسخ المتماثلة الثانوية بتصعيب التغيير لسجل المعاملة الخاصة بها.

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

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

مقياس فائق

تتوفر طبقة خدمة Hyperscale فقط في قاعدة بيانات Azure SQL. يحتوي مستوى الخدمة هذا على تصميم فريد لأنه يستخدم طبقة متدرجة من ذاكرات التخزين المؤقت وخادمات الصفحة لتوسيع القدرة على الوصول بسرعة إلى صفحات قاعدة البيانات دون الحاجة إلى الوصول إلى ملف البيانات مباشرة.

Screenshot that shows the Hyperscale architecture.

لأن هذا التصميم يستخدم خادمات الصفحة المقترنة، يمكنك التحجيم أفقيًا لوضع كافة البيانات في طبقات التخزين المؤقت. يسمح هذا التصميم الجديد أيضًا لـ Hyperscale بدعم قواعد البيانات التي يصل حجمها إلى 100 تيرابايت. لأنه يستخدم لقطات، يمكن أن تحدث النسخ الاحتياطية الفورية تقريبًا لقاعدة بيانات بغض النظر عن الحجم. تستغرق استعادة قاعدة البيانات دقائق بدلاً من الساعات أو الأيام. يمكنك أيضًا التوسيع أو خفض الحجم في وقت ثابت لاستيعاب أحمال العمل خاصتك.

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

كما هو الحال في مستويات الخدمة الأخرى، سيحدث تجاوز الفشل التلقائي إذا حدد نسيج الخدمة أنه يحتاج إلى ذلك، ولكن وقت الاسترداد سيعتمد على وجود النسخ المتماثلة الثانوية. على سبيل المثال، إذا لم تكن لديك نسخ متماثلة وحدث تجاوز الفشل، فالسيناريو سيكون مشابهًا لمستوى الخدمة General Purpose: يحتاج service fabric أولاً إلى العثور على سعة احتياطية. إذا كانت لديك نسخة متماثلة واحدة أو أكثر، يكون الاسترداد أسرع ويشابه ذاك الموجود في مستوى الخدمة Business Critical.

يحافظ Business Critical على أعلى أداء وتوافر لأحمال العمل مع عمليات كتابة السجل الصغيرة التي تحتاج إلى زمن انتقال منخفض، ولكن مستوى خدمة Hyperscale يسمح لك بالحصول على معدل نقل أعلى للسجل من حيث MB/second، ويوفر أكبر أحجام قاعدة البيانات، ويوفر ما يصل إلى أربع نسخ متماثلة ثانوية لمستويات أعلى من مقياس القراءة. لذلك، ستحتاج إلى مراعاة حمل العمل الخاص بك عند الاختيار بين الاثنين.

‏اختبر معلوماتك

1.

ما مستوى الخدمة الذي يضع البيانات وملفات السجل على Azure Premium Storage؟

2.

ما مستوى الخدمة الذي يحتوي على مجموعة توفر Always On التي تم نشرها في الخلفية؟