فوائد استخدام Azure NetApp Files لتوزيع SQL Server
تقلل Azure NetApp Files من التكلفة الإجمالية للملكية (TCO) ل SQL Server مقارنة بحلول التخزين المحظورة. مع تخزين الكتلة، فرضت الأجهزة الظاهرية حدودا على الإدخال/الإخراج وعرض النطاق الترددي لعمليات القرص. يتم تطبيق حدود النطاق الترددي للشبكة فقط مقابل Azure NetApp Files، وعند الخروج فقط في ذلك. بمعنى آخر، لا يتم تطبيق حدود الإدخال/الإخراج على مستوى الجهاز الظاهري على ملفات Azure NetApp. بدون حدود الإدخال/الإخراج هذه، يمكن أن يؤدي SQL Server الذي يعمل على أجهزة ظاهرية أصغر متصلة ب Azure NetApp Files بالإضافة إلى SQL Server الذي يعمل على أجهزة ظاهرية أكبر بكثير. يقلل تغيير حجم المثيلات على هذا النحو من تكلفة الحساب إلى 25٪ من علامة السعر السابقة. يمكنك تقليل تكاليف الحوسبة باستخدام Azure NetApp Files.
ومع ذلك، فإن تكاليف الحوسبة صغيرة مقارنة بتكاليف ترخيص SQL Server. يرتبط ترخيص Microsoft SQL Server بعدد الذاكرة الأساسية الفعلية. على هذا النحو، يؤدي تقليل حجم المثيل إلى توفير أكبر في التكاليف لترخيص البرامج. يمكنك تقليل تكاليف ترخيص البرامج باستخدام Azure NetApp Files.
تعرض هذه المقالة تحليلا مفصلا للتكلفة وفوائد الأداء حول استخدام Azure NetApp Files لتوزيع SQL Server. لا تحتوي المثيلات الأصغر على وحدة معالجة مركزية كافية فقط للقيام بقاعدة البيانات للعمل الممكن فقط مع كتلة على مثيلات أكبر، وفي كثير من الحالات، تكون المثيلات الأصغر أكثر أداء من نظيراتها الأكبر المستندة إلى القرص بسبب Azure NetApp Files.
تحليل مُفصّل للتكاليف
تعرض مجموعتا الرسومات في هذا القسم مثال TCO. تم تحديد عدد ونوع الأقراص المدارة، ومستوى خدمة Azure NetApp Files، والسعة لكل سيناريو لتحقيق أفضل أداء لسعة السعر. يتكون كل رسم من أجهزة مجمعة (D16 مع Azure NetApp Files، مقارنة ب D64 مع القرص المدار على سبيل المثال)، ويتم تقسيم الأسعار لكل نوع جهاز.
تعرض المجموعة الأولى من الرسم التكلفة الإجمالية للحل باستخدام حجم قاعدة بيانات 1 تيرابايت، ومقارنة D16s_v4 ب D64 وD8 إلى D32 وD4 إلى D16. تتم الإشارة إلى عمليات الإدخال/الإخراج في الثانية (IOPs) المتوقعة لكل تكوين بخط أخضر أو أصفر وتتوافق مع المحور Y في الجانب الأيمن.
تعرض المجموعة الثانية من الرسم التكلفة الإجمالية باستخدام قاعدة بيانات 50 تيرابايت. المقارنات هي نفسها بخلاف ذلك - D16 مقارنة ب Azure NetApp Files مقابل D64 مع الكتلة حسب المثال.
الأداء، والكثير منه
يتطلب التسليم تأكيد تقليل التكلفة الكبير الكثير من الأداء - أكبر مثيلات في دعم مخزون Azure العام 80000 قرص IOPS على سبيل المثال. يمكن أن يحقق وحدة تخزين Azure NetApp Files واحدة 80000 عملية إدخال وإخراج في الملفات في قاعدة البيانات، ويمكن لمثيلات مثل D16 استهلاك نفس الشيء. D16، القادرة عادة على 25600 قرص IOPS، هو 25٪ حجم D64. D64s_v4 قادر على 80,000 قرص IOPS، وعلى هذا النحو، يقدم نقطة مقارنة مستوى أعلى ممتازة.
يمكن D16s_v4 محرك وحدة تخزين Azure NetApp Files إلى 80000 قاعدة بيانات IOPS. كما أثبتت أداة قياس معيار تخزين SQL (SSB)، حقق مثيل D16 حمل عمل أكبر بنسبة 125٪ من ذلك الذي يمكن تحقيقه على القرص من مثيل D64. راجع قسم أداة اختبار SSB للحصول على تفاصيل حول الأداة.
باستخدام حجم مجموعة عمل 1-TiB وقراءة بنسبة 80٪، تم قياس 20٪ تحديث حمل عمل SQL Server، وقدرات الأداء لمعظم المثيلات في فئة مثيل D؛ معظم، وليس كل، كما تم استبعاد مثيلات D2 وD64 نفسها من الاختبار. تم ترك الأول لأنه لا يدعم الشبكات المتسارعة، والأخير لأنه نقطة المقارنة. راجع الرسم البياني التالي لفهم حدود D4s_v4 D8s_v4 D16s_v4 D32s_v4 على التوالي. لا تظهر اختبارات تخزين القرص المدارة في الرسم البياني. يتم رسم قيم المقارنة مباشرة من جدول حدود جهاز Azure الظاهري لنوع مثيل الفئة D.
باستخدام Azure NetApp Files، يمكن لكل مثيل من المثيلات في الفئة D تلبية قدرات أداء القرص للمثيلات أكبر مرتين أو تجاوزها. يمكنك تقليل تكاليف ترخيص البرامج بشكل كبير باستخدام Azure NetApp Files.
- تطابق D4 عند استخدام وحدة المعالجة المركزية بنسبة 75٪ مع قدرات القرص ل D16.
- معدل D16 محدود عند 25600 قرص IOPS.
- تطابق D8 عند استخدام وحدة المعالجة المركزية بنسبة 75٪ مع قدرات القرص ل D32.
- معدل D32 محدود عند 51200 قرص IOPS.
- تطابق D16 عند استخدام وحدة المعالجة المركزية بنسبة 55٪ مع قدرات القرص ل D64.
- معدل D64 محدود عند 80,000 قرص IOPS.
- تطابق استخدام وحدة المعالجة المركزية D32 بنسبة 15٪ مع قدرات القرص ل D64 أيضا.
- D64 كما هو مذكور أعلاه هو معدل محدود عند 80000 قرص IOPS.
اختبار حدود وحدة المعالجة المركزية S3B - الأداء مقابل قوة المعالجة
يلخص الرسم التخطيطي التالي اختبار حدود وحدة المعالجة المركزية S3B:
قابلية التوسع ليست سوى جزء من القصة. الجزء الآخر هو زمن الانتقال. إنه شيء واحد للأجهزة الظاهرية الأصغر أن يكون لديها القدرة على دفع معدلات إدخال/إخراج أعلى بكثير، وهو شيء آخر للقيام بذلك مع زمن انتقال منخفض مكون من رقم واحد كما هو موضح أدناه.
- قاد D4 26,000 IOPS مقابل Azure NetApp Files في زمن انتقال 2.3 مللي ثانية.
- قاد D8 51,000 IOPS مقابل Azure NetApp Files في زمن انتقال 2.0 مللي ثانية.
- قاد D16 88,000 IOPS مقابل Azure NetApp Files في زمن انتقال 2.8 مللي ثانية.
- قاد D32 80,000 IOPS مقابل Azure NetApp Files في زمن انتقال 2.4 مللي ثانية.
نتائج زمن انتقال نوع S3B لكل مثيل
يوضح الرسم التخطيطي التالي زمن انتقال SQL Server أحادي المثيل عبر Azure NetApp Files:
أداة اختبار SSB
أداة قياس TPC-E، حسب التصميم، تشدد على الحوسبة بدلا من التخزين. تستند نتائج الاختبار الموضحة في هذا القسم إلى أداة اختبار الإجهاد المسماة SQL Storage Benchmark (SSB). يمكن أن يدفع معيار تخزين SQL Server تنفيذ SQL على نطاق واسع مقابل قاعدة بيانات SQL Server لمحاكاة حمل عمل OLTP، على غرار أداة قياس SLOB2 Oracle.
تنشئ أداة SSB حمل عمل يستند إلى SELECT و UPDATE يصدر العبارات المذكورة مباشرة إلى قاعدة بيانات SQL Server التي تعمل داخل الجهاز الظاهري Azure. بالنسبة لهذا المشروع، تكثفت أحمال عمل SSB من 1 إلى 100 مستخدم SQL Server، مع 10 أو 12 نقطة وسيطة عند 15 دقيقة لكل عدد مستخدمين. كانت جميع مقاييس الأداء من هذه التشغيلات من وجهة نظر perfmon، لقابلية التكرار SSB تم تشغيلها ثلاث مرات لكل سيناريو.
تم تكوين الاختبارات نفسها على أنها عبارة SELECT بنسبة 80٪ و20٪ UPDATE، وبالتالي قراءة عشوائية بنسبة 90٪. قاعدة البيانات نفسها، التي أنشأها SSB، كان حجمها 1000 غيغابايت. وهي تتكون من 15 جدول مستخدم و9000000 صف لكل جدول مستخدم و8192 بايت لكل صف.
معيار SSB هو أداة مفتوحة المصدر. وهي متاحة بحرية في صفحة SQL Storage Benchmark GitHub.
وخلاصة القول
باستخدام Azure NetApp Files، يمكنك زيادة أداء خادم SQL مع تقليل التكلفة الإجمالية للملكية بشكل كبير.