أداء قاعدة بيانات Oracle على Azure NetApp Files وحدات تخزين متعددة

أصبح ترحيل قواعد بيانات Exadata عالية الأداء إلى السحابة أمرا ضروريا لعملاء Microsoft بشكل متزايد. عادة ما تعين مجموعات برامج سلسلة التوريد الشريط عاليا بسبب الطلبات المكثفة على إدخال/إخراج التخزين مع حمل عمل قراءة وكتابة مختلط مدفوع بعقدة حساب واحدة. البنية الأساسية ل Azure بالاشتراك مع Azure NetApp Files قادرة على تلبية احتياجات حمل العمل هذا الذي يتطلب طلبا كبيرا. تقدم هذه المقالة مثالا على كيفية تلبية هذا الطلب لعميل واحد وكيف يمكن ل Azure تلبية متطلبات أحمال عمل Oracle الهامة.

أداء Oracle على نطاق المؤسسة

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

حدث الاختبار على مرحلتين:

1. ركزت المرحلة الأولى على الاختبار باستخدام أداة SLOB2 لمعيار الصناعة الآن في كيفين كلوسون (معيار Oracle الصغير السخيف) - الإصدار 2.5.4. الهدف هو دفع أكبر قدر ممكن من إدخال/إخراج Oracle من جهاز ظاهري واحد (VM) إلى وحدات تخزين Azure NetApp Files متعددة، ثم توسيع نطاقها باستخدام المزيد من قواعد البيانات لإظهار التحجيم الخطي.
2. بعد اختبار حدود التحجيم، تمحور اختبارنا إلى E96ds_v5 الأقل تكلفة ولكن بالقدرة تقريبا لمرحلة العميل من الاختبار باستخدام حمل عمل تطبيق سلسلة التوريد الحقيقي وبيانات العالم الحقيقي.

أداء توسيع نطاق SLOB2

تلتقط المخططات التالية ملف تعريف الأداء لجهاز ظاهري واحد E104ids_v5 Azure يقوم بتشغيل قاعدة بيانات Oracle 19c واحدة مقابل ثماني وحدات تخزين Azure NetApp Files مع ثماني نقاط نهاية تخزين. تنتشر وحدات التخزين عبر ثلاث مجموعات أقراص ASM: البيانات والسجل والأرشيف. تم تخصيص خمسة وحدات تخزين لمجموعة أقراص البيانات، واثنين من وحدات التخزين لمجموعة قرص السجل، ووحدات تخزين واحدة لمجموعة أقراص الأرشيف. تم جمع جميع النتائج التي تم التقاطها خلال هذه المقالة باستخدام مناطق إنتاج Azure وخدمات Azure للإنتاج النشط.

لنشر Oracle على أجهزة Azure الظاهرية باستخدام وحدات تخزين Azure NetApp Files متعددة على نقاط نهاية تخزين متعددة، استخدم مجموعة وحدة تخزين التطبيق ل Oracle.

بنية مضيف واحد

يوضح الرسم التخطيطي التالي البنية التي تم إكمال الاختبار مقابلها؛ لاحظ أن قاعدة بيانات Oracle منتشرة عبر وحدات تخزين ونقاط نهاية Azure NetApp Files متعددة.

IO لتخزين مضيف واحد

يوضح الرسم التخطيطي التالي حمل عمل محدد عشوائيا بنسبة 100٪ مع نسبة إصابة مخزن مؤقت لقاعدة البيانات تبلغ حوالي 8٪. تمكنت SLOB2 من دفع ما يقرب من 850,000 طلب إدخال/إخراج في الثانية مع الحفاظ على زمن انتقال حدث قراءة متسلسلة لملف submillisecond DB. مع حجم كتلة قاعدة بيانات يبلغ 8K يصل إلى ما يقرب من 6800 ميجابايت/ ثانية من معدل نقل التخزين.

معدل نقل مضيف واحد

يوضح الرسم التخطيطي التالي أنه بالنسبة لأحمال عمل IO المتسلسلة المكثفة للنطاق الترددي مثل عمليات فحص الجدول الكامل أو أنشطة RMAN، يمكن ل Azure NetApp Files تقديم إمكانات النطاق الترددي الكامل للجهاز الظاهري E104ids_v5 نفسه.

إشعار

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

أداء توسيع نطاق SLOB2

تلتقط المخططات التالية ملف تعريف الأداء لثلاثة أجهزة ظاهرية E104ids_v5 Azure تشغل كل منها قاعدة بيانات Oracle 19c واحدة ولكل منها مجموعة خاصة بها من وحدات تخزين Azure NetApp Files وتخطيط مجموعة قرص ASM متطابق كما هو موضح في قسم توسيع الأداء. تظهر الرسومات أنه مع ملفات Azure NetApp متعددة الحجم/نقطة نهاية متعددة، يتوسع الأداء بسهولة مع التناسق وإمكانية التنبؤ.

بنية متعددة المضيفين

يوضح الرسم التخطيطي التالي البنية التي تم إكمال الاختبار مقابلها؛ لاحظ قواعد بيانات Oracle الثلاث المنتشرة عبر وحدات تخزين ونقاط نهاية Azure NetApp Files متعددة. يمكن تخصيص نقاط النهاية لمضيف واحد كما هو موضح مع Oracle VM 1 أو مشاركتها بين المضيفين كما هو موضح مع Oracle VM2 وOracle VM 3.

تخزين متعدد المضيفين IO

يوضح الرسم التخطيطي التالي حمل عمل محدد عشوائيا بنسبة 100٪ مع نسبة إصابة مخزن مؤقت لقاعدة البيانات تبلغ حوالي 8٪. تمكن SLOB2 من قيادة حوالي 850,000 طلب إدخال/إخراج في الثانية عبر جميع المضيفين الثلاثة بشكل فردي. تمكن SLOB2 من تحقيق ذلك أثناء التنفيذ بالتوازي مع إجمالي جماعي يبلغ حوالي 2500000 طلب إدخال/إخراج في الثانية مع استمرار كل مضيف في الحفاظ على زمن انتقال حدث قراءة متسلسلة لملف submillisecond db. مع حجم كتلة قاعدة بيانات 8K، يصل هذا إلى حوالي 20000 ميجابايت/ثانية بين المضيفين الثلاثة.

معدل النقل متعدد المضيفين

يوضح الرسم التخطيطي التالي أنه بالنسبة لأحمال العمل المتسلسلة، لا يزال بإمكان Azure NetApp Files تقديم إمكانات النطاق الترددي الكامل للجهاز الظاهري E104ids_v5 نفسه حتى في أثناء توسعه إلى الخارج. تمكنت SLOB2 من قيادة الإدخال/الإخراج بإجمالي أكثر من 30000 ميجابايت/ثانية عبر المضيفين الثلاثة أثناء التشغيل بالتوازي.

أداء العالم الحقيقي

بعد اختبار حدود التحجيم مع SLOB2، أجريت الاختبارات مع مجموعة تطبيقات سلسلة التوريد في الكلمات الحقيقية مقابل Oracle على ملفات Azure NetApp مع نتائج ممتازة. البيانات التالية من تقرير Oracle Automatic Workload Repository (AWR) هي نظرة مميزة على كيفية أداء مهمة هامة محددة.

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

-	القراءة والكتابة في الثانية	القراءة في الثانية	الكتابة في الثانية
الإجمالي (ميغابايت)	4,988.1	1,395.2	3,592.9

على الرغم من حدث انتظار القراءة التسلسلية لملف db الذي يظهر زمن انتقال أعلى عند 2.2 مللي ثانية مما كان عليه في اختبار SLOB2، شهد هذا العميل انخفاضا لمدة 15 دقيقة في وقت تنفيذ المهمة القادمة من قاعدة بيانات RAC على Exadata إلى قاعدة بيانات مثيل واحدة في Azure.

قيود موارد Azure

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

الأجهزة الظاهرية

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

رقائق

الموضوع الأول الذي يهم هو تحديد مجموعة شرائح. تأكد من أن أيا كان VM SKU الذي تحدده مبني على مجموعة شرائح واحدة لأسباب تتعلق بالتناسق. يعمل متغير Intel للأجهزة الظاهرية E_v5 على تكوين Intel Xeon Platinum 8370C (Ice Lake) من الجيل الثالث. تأتي جميع الأجهزة الظاهرية في هذه العائلة مجهزة بواجهة شبكة واحدة بسرعة 100 جيجابت في الثانية. وعلى النقيض من ذلك، فإن سلسلة E_v3، المذكورة على سبيل المثال، مبنية على أربع مجموعات شرائح منفصلة، مع نطاقات ترددية فعلية مختلفة للشبكة. مجموعات الرقائق الأربعة المستخدمة في عائلة E_v3 (Broadwell، Skylake، Cascade Lake، Haswell) لها سرعات معالج مختلفة، والتي تؤثر على خصائص أداء الجهاز.

اقرأ وثائق Azure Compute بعناية مع الانتباه إلى خيارات مجموعة الشرائح. راجع أيضا أفضل ممارسات Azure VM SKUs ل Azure NetApp Files. اختيار جهاز ظاهري مع مجموعة شرائح واحدة هو الأفضل للحصول على أفضل تناسق.

النطاق الترددي للشبكة المتوفر

من المهم فهم الفرق بين النطاق الترددي المتاح لواجهة شبكة الجهاز الظاهري والنطاق الترددي المحدود المطبق على نفس الشيء. عندما تتحدث وثائق Azure Compute عن حدود النطاق الترددي للشبكة، يتم تطبيق هذه الحدود على الخروج (الكتابة) فقط. لا يتم قياس نسبة استخدام الشبكة للدخول (القراءة) وعلى هذا النحو يقتصر فقط على النطاق الترددي الفعلي ل NIC نفسه. يتجاوز النطاق الترددي للشبكة لمعظم الأجهزة الظاهرية حد الخروج المطبق على الجهاز.

نظرا لأن وحدات تخزين Azure NetApp Files مرفقة بالشبكة، يمكن فهم حد الخروج على أنه يتم تطبيقه على عمليات الكتابة على وجه التحديد بينما يتم تعريف الدخول على أنه قراءات وأحمال عمل تشبه القراءة. في حين أن حد الخروج لمعظم الأجهزة أكبر من عرض النطاق الترددي للشبكة ل NIC، لا يمكن قول الشيء نفسه بالنسبة E104_v5 المستخدمة في اختبار هذه المقالة. يحتوي E104_v5 على NIC 100 جيجابت في الثانية مع تعيين حد الخروج عند 100 جيجابت في الثانية أيضا. بالمقارنة، فإن E96_v5، مع بطاقة NIC 100 جيجابت في الثانية لديها حد خروج يبلغ 35 جيجابت في الثانية مع دخول غير مقيد عند 100 جيجابت في الثانية. مع انخفاض حجم الأجهزة الظاهرية، تنخفض حدود الخروج ولكن يظل الدخول غير مقيد بالحدود المفروضة منطقيا.

حدود الخروج هي على مستوى الجهاز الظاهري ويتم تطبيقها على هذا النحو على جميع أحمال العمل المستندة إلى الشبكة. عند استخدام Oracle Data Guard، تتم مضاعفة جميع عمليات الكتابة لأرشفة السجلات ويجب أخذها في الاعتبارات الحد من الخروج. ينطبق هذا أيضا على سجل الأرشيف ذي الوجهات المتعددة وRMAN، إذا تم استخدامه. عند تحديد الأجهزة الظاهرية، تعرفوا على أدوات ethtoolسطر الأوامر مثل ، والتي تعرض تكوين NIC لأن Azure لا يوثق تكوينات واجهة الشبكة.

تزامن الشبكة

تأتي وحدات تخزين Azure VMs وAzure NetApp Files مجهزة بكميات محددة من النطاق الترددي. كما هو موضح سابقا، طالما أن الجهاز الظاهري يحتوي على غرفة رأس CPU كافية، يمكن أن يستهلك حمل العمل نظريا النطاق الترددي المتاح له - وهذا يقع ضمن حدود بطاقة الشبكة أو حد الخروج المطبق. ومع ذلك، في الممارسة العملية، يتم تقييم مقدار الإنتاجية التي يمكن تحقيقها على تزامن حمل العمل على الشبكة، أي عدد تدفقات الشبكة ونقاط نهاية الشبكة.

اقرأ قسم حدود تدفق الشبكة في مستند النطاق الترددي لشبكة الجهاز الظاهري لفهم أكبر. الوجبات الجاهزة: كلما زادت تدفقات الشبكة التي تربط العميل بالتخزين كلما كان الأداء المحتمل أكثر ثراء.

تدعم Oracle اثنين من عملاء NFS المنفصلين، Kernel NFS وNFS المباشر (dNFS) . دعم Kernel NFS، حتى وقت متأخر، تدفق شبكة واحدة بين نقطتي نهاية (حساب - تخزين). يدعم NFS المباشر، الأكثر أداء من الاثنين، عددا متغيرا من تدفقات الشبكة - أظهرت الاختبارات مئات الاتصالات الفريدة لكل نقطة نهاية - زيادة أو تقليل مع متطلبات التحميل. نظرا لتحجيم تدفقات الشبكة بين نقطتي نهاية، يفضل NFS المباشر كثيرا على Kernel NFS، وعلى هذا النحو، التكوين الموصى به. لا توصي مجموعة منتجات Azure NetApp Files باستخدام Kernel NFS مع أحمال عمل Oracle. لمزيد من المعلومات، راجع فوائد استخدام Azure NetApp Files مع قاعدة بيانات Oracle.

تزامن التنفيذ

استخدام NFS المباشر، مجموعة شرائح واحدة للاتساق، وفهم قيود النطاق الترددي للشبكة يأخذك فقط حتى الآن. في النهاية، يدفع التطبيق الأداء. كانت إثباتات المفهوم باستخدام SLOB2 وإثباتات المفهوم باستخدام مجموعة تطبيقات سلسلة التوريد في العالم الحقيقي مقابل بيانات العملاء الحقيقية قادرة على دفع كميات كبيرة من معدل النقل فقط لأن التطبيقات تعمل بدرجات عالية من التزامن؛ الأول الذي يستخدم عددا كبيرا من مؤشرات الترابط لكل مخطط، ويستخدم الأخير اتصالات متعددة من خوادم تطبيقات متعددة. باختصار، يدفع التزامن حمل العمل، والتزامن المنخفض - معدل النقل المنخفض، والتزامن العالي - معدل النقل العالي طالما أن البنية الأساسية موجودة لدعم نفس الشيء.

شبكات مسرعة

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

إشعار

تحتوي هذه المقالة على مراجع للمصطلح SLAVE، وهو مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، سنزيله من هذه المقالة.

يتم تمكين نهج موثوق للشبكات المتسارعة التالية ل NIC عبر محطة Linux الطرفية. إذا تم تمكين الشبكات المتسارعة ل NIC، فإن NIC الظاهري الثاني موجود مقترنا ب NIC الأول. يتم تكوين NIC الثاني هذا بواسطة النظام مع تمكين العلامة SLAVE . إذا لم يكن NIC موجودا مع العلامة SLAVE ، فلن يتم تمكين الشبكات المتسارعة لتلك الواجهة.

في السيناريو حيث يتم تكوين عدة بطاقات واجهة الشبكة، تحتاج إلى تحديد SLAVE الواجهة المقترنة ب NIC المستخدمة لتحميل وحدة تخزين NFS. لا تؤثر إضافة بطاقات واجهة الشبكة إلى الجهاز الظاهري على الأداء.

استخدم العملية التالية لتحديد التعيين بين واجهة الشبكة المكونة والواجهة الظاهرية المقترنة بها. تتحقق هذه العملية من تمكين الشبكات المتسارعة ل NIC معين على جهاز Linux الخاص بك وعرض سرعة الدخول الفعلية التي يمكن أن تحققها NIC.

1. ip a تنفيذ الأمر:
2. سرد /sys/class/net/ دليل معرف NIC الذي تتحقق من صحته (eth0 في المثال) وللكلمة grep أقل:

   ls /sys/class/net/eth0 | grep lower lower_eth1
   

3. ethtool تنفيذ الأمر مقابل جهاز ethernet الذي تم تعريفه على أنه الجهاز السفلي في الخطوة السابقة.

Azure VM: حدود النطاق الترددي للشبكة مقابل القرص

مطلوب مستوى من الخبرة عند قراءة وثائق حدود أداء جهاز Azure الظاهري. كن على علم بما يلي:

• تشير أرقام معدل نقل التخزين المؤقت وأرقام IOPS إلى قدرات أداء التخزين المؤقت في المربع المرفق مباشرة بالجهاز الظاهري.
• تشير أرقام الإدخال/الإخراج الخاصة بالقرص غير المخزن مؤقتا إلى قرص Azure (Premium وPremium v2 و Ultra) وليس لها تأثير على التخزين المرفق بالشبكة مثل Azure NetApp Files.
• لا يؤثر إرفاق بطاقات واجهة الشبكة الإضافية بالجهاز الظاهري على حدود الأداء أو قدرات الأداء للجهاز الظاهري (موثقة ومختبرة لتكون صحيحة).
• يشير الحد الأقصى لعرض النطاق الترددي للشبكة إلى حدود الخروج (أي عمليات الكتابة عند مشاركة Azure NetApp Files) المطبقة على النطاق الترددي لشبكة الجهاز الظاهري. لا يتم تطبيق حدود دخول (أي القراءة عند مشاركة ملفات Azure NetApp). نظرا إلى وحدة المعالجة المركزية الكافية، فإن تزامن الشبكة الكافي ونقاط النهاية الغنية بما يكفي يمكن للجهاز الظاهري نظريا دفع حركة مرور الدخول إلى حدود NIC. كما هو مذكور في قسم النطاق الترددي للشبكة المتوفرة، استخدم أدوات مثل ethtool لمشاهدة النطاق الترددي ل NIC.

يتم عرض نموذج مخطط للرجوع إليه:

ملفات Azure NetApp

توفر خدمة تخزين Azure من الطرف الأول Azure NetApp Files حلا تخزينيا مدارا بالكامل متوفرا بشكل كبير وقادر على دعم أحمال عمل Oracle المطلوبة التي تم تقديمها سابقا.

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

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

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

هام

للنشر باستخدام Azure NetApp Files في multiple volume:multiple endpoint تكوين، تواصل مع أخصائي ملفات Azure NetApp أو مهندس حلول السحابة للحصول على المساعدة.

قاعدة البيانات

إصدار قاعدة بيانات Oracle 19c هو إصدار Oracle الحالي طويل المدى والإصدار المستخدم لإنتاج جميع نتائج الاختبار التي تمت مناقشتها في هذه الورقة.

للحصول على أفضل أداء، تم تحميل جميع وحدات تخزين قاعدة البيانات باستخدام NFS المباشر، يوصى باستخدام Kernel NFS بسبب قيود الأداء. لمقارنة الأداء بين العميلين، راجع أداء قاعدة بيانات Oracle على وحدات التخزين الفردية ل Azure NetApp Files. ملاحظة، تم تطبيق جميع تصحيحات dNFS ذات الصلة (معرف دعم Oracle 1495104)، كما تم تطبيق أفضل الممارسات الموضحة في تقرير Oracle Databases على Microsoft Azure باستخدام Azure NetApp Files .

بينما تدعم Oracle وAzure NetApp Files كلا من NFSv3 وNFSv4.1، حيث إن NFSv3 هو البروتوكول الأكثر نضجا الذي ينظر إليه بشكل عام على أنه يحتوي على أكبر قدر من الاستقرار وهو الخيار الأكثر موثوقية للبيئات الحساسة للغاية للتعطيل. تم إكمال الاختبار الموضح في هذه المقالة عبر NFSv3.

هام

بعض التصحيحات الموصى بها التي مستندات Oracle في معرف الدعم 1495104 ضرورية للحفاظ على تكامل البيانات عند استخدام dNFS. ينصح بشدة بتطبيق مثل هذه التصحيحات لبيئات الإنتاج.

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

تم استخدام ASM عبر تكوين dNFS لإنتاج جميع نتائج الاختبار التي تمت مناقشتها في هذه المقالة. يوضح الرسم التخطيطي التالي تخطيط ملف ASM داخل وحدات تخزين Azure NetApp Files وتخصيص الملف لمجموعات أقراص ASM.

هناك بعض القيود مع استخدام ASM عبر وحدات التخزين المثبتة على Azure NetApp Files NFS عندما يتعلق الأمر بلقطات التخزين التي يمكن التغلب عليها مع بعض الاعتبارات المعمارية. اتصل بأخصائي Azure NetApp Files أو مهندس حلول السحابة للحصول على مراجعة متعمقة لهذه الاعتبارات.

أدوات الاختبار الاصطناعية والقابلة للضبط

يصف هذا القسم بنية الاختبار والضبط وتفاصيل التكوين في التفاصيل. بينما يركز القسم السابق على أسباب اتخاذ قرارات التكوين، يركز هذا القسم بشكل خاص على "ماذا" قرارات التكوين.

النشر بشكل تلقائي

• يتم نشر قاعدة البيانات VMs باستخدام البرامج النصية bash المتوفرة على GitHub.
• يتم إكمال تخطيط وتخصيص وحدات تخزين ونقاط نهاية Azure NetApp Files المتعددة يدويا. تحتاج إلى العمل مع أخصائي ملفات Azure NetApp أو مهندس حلول السحابة للحصول على المساعدة.
• يتم تكوين تثبيت الشبكة وتكوين ASM وإنشاء قاعدة البيانات وتكوينها وبيئة SLOB2 على كل جهاز باستخدام Ansible للتناسق.
• يتم أيضا إكمال عمليات تنفيذ اختبار SLOB2 المتوازية عبر مضيفين متعددين باستخدام Ansible للتناسق والتنفيذ المتزامن.

تكوين

التكوين	القيمة‬
منطقة Azure	أوروبا الغربية
VM SKU	E104ids_v5
عدد NIC	1 ملاحظة: إضافة vNICs ليس له أي تأثير على عدد النظام
الحد الأقصى لعرض النطاق الترددي لشبكة الخروج (ميغابت في الثانية)	100,000
تخزين درجة الحرارة (SSD) جيبي	3,800

تكوين النظام

تم تنفيذ جميع إعدادات تكوين النظام المطلوبة من Oracle للإصدار 19c وفقا لوثائق Oracle.

تمت إضافة المعلمات التالية إلى /etc/sysctl.conf ملف نظام Linux:

• sunrpc.max_tcp_slot_table_entries: 128
• sunrpc.tcp_slot_table_entries = 128

ملفات Azure NetApp

تم تحميل جميع وحدات تخزين Azure NetApp Files مع خيارات تحميل NFS التالية.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

معلمات قاعدة البيانات

المعلمات	القيمة‬
db_cache_size	2g
large_pool_size	2g
pga_aggregate_target	3g
pga_aggregate_limit	3g
sga_target	25غ
shared_io_pool_size	500 م
shared_pool_size	5g
db_files	500
filesystemio_options	SETALL
job_queue_processes	1
db_flash_cache_size	1
_cursor_obsolete_threshold	130
_db_block_prefetch_limit	1
_db_block_prefetch_quota	0
_db_file_noncontig_mblock_read_count	1

تكوين SLOB2

تم إكمال إنشاء جميع أحمال العمل للاختبار باستخدام الإصدار 2.5.4 من أداة SLOB2.

تم تحميل 14 مخطط SLOB2 في مساحة جدول Oracle القياسية وتنفيذها مقابل، والتي بالاشتراك مع إعدادات ملف تكوين slob المدرجة، ضع مجموعة بيانات SLOB2 في 7 تيرابايت. تعكس الإعدادات التالية تنفيذ قراءة عشوائي ل SLOB2. تم تغيير معلمة SCAN_PCT=0 التكوين إلى SCAN_PCT=100 أثناء الاختبار التسلسلي.

• UPDATE_PCT=0
• SCAN_PCT=0
• RUN_TIME=600
• SCALE=450G
• SCAN_TABLE_SZ=50G
• WORK_UNIT=32
• REDO_STRESS=LITE
• THREADS_PER_SCHEMA=1
• DATABASE_STATISTICS_TYPE=awr

لاختبار القراءة العشوائية، تم تنفيذ تسع عمليات تنفيذ SLOB2. تم زيادة عدد مؤشرات الترابط بمقدار ستة مع كل تكرار اختبار يبدأ من واحد.

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

مقاييس AWR

تم الإبلاغ عن جميع مقاييس الأداء من خلال مستودع حمل العمل التلقائي من Oracle (AWR). فيما يلي المقاييس المقدمة في النتائج:

• معدل النقل: مجموع متوسط معدل نقل القراءة والكتابة من قسم ملف تعريف تحميل AWR
• متوسط طلبات الإدخال/الإخراج للقراءة من قسم ملف تعريف تحميل AWR
• متوسط انتظار حدث القراءة التسلسلية لملف db من قسم AWR Foreground Wait Events

الترحيل من أنظمة مصممة لهذا الغرض ومهندسة إلى السحابة

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

عندما يتعلق الأمر بتشغيل Oracle على Exadata، هناك بعض الأسباب الشائعة لاختيار Exadata:

• 1-2 أحمال عمل الإدخال/الإخراج العالية التي تناسب ميزات Exadata بشكل طبيعي، وكما تتطلب أحمال العمل هذه ميزات هندسية كبيرة من Exadata، تم دمج بقية قواعد البيانات التي تعمل معها في Exadata.
• أحمال عمل OLTP المعقدة أو الصعبة التي تتطلب RAC لتوسيع نطاقها ويصعب تصميمها باستخدام أجهزة خاصة دون معرفة عميقة بتحسين Oracle أو قد تكون ديونا تقنية غير قادرة على التحسين.
• Exadata الموجودة غير المستخدمة بشكل جيد مع أحمال العمل المختلفة: هذا موجود إما بسبب عمليات الترحيل السابقة، أو انتهاء العمر الافتراضي على Exadata سابقة، أو بسبب الرغبة في العمل/اختبار Exadata داخليا.

من الضروري فهم أي ترحيل من نظام Exadata من منظور أحمال العمل ومدى بساطة الترحيل أو تعقيده. الحاجة الثانوية هي فهم سبب شراء Exadata من منظور الحالة. مهارات Exadata وRAC في ارتفاع الطلب وربما دفعت التوصية لشراء واحدة من قبل المساهمين التقنيين.

هام

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

هناك العديد من الأدوات التي يمكن استخدامها لتقييم فرص حمل العمل هذه:

• مستودع حمل العمل التلقائي (AWR):
  • يتم ترخيص جميع قواعد بيانات Exadata لاستخدام تقارير AWR وميزات الأداء والتشخيص المتصلة.
  • يعمل دائما ويجمع البيانات التي يمكن استخدامها لعرض معلومات حمل العمل التاريخية وتقييم الاستخدام. يمكن لقيم الذروة تقييم الاستخدام العالي على النظام،
  • يمكن لتقارير AWR للنافذة الأكبر تقييم حمل العمل الإجمالي، ما يوفر نظرة ثاقبة قيمة حول استخدام الميزات وكيفية ترحيل حمل العمل إلى غير Exadata بشكل فعال. تقارير الذروة AWR في المقابل هي الأفضل لتحسين الأداء واستكشاف الأخطاء وإصلاحها.
• يتضمن تقرير AWR العمومي (RAC-Aware) ل Exadata أيضا قسما خاصا ب Exadata، والذي يتنقل لأسفل في استخدام ميزة Exadata محدد ويوفر ذاكرة تخزين مؤقت لفلاش معلومات التحليلات القيمة وتسجيل الفلاش والإخراج والإخراج واستخدام الميزات الأخرى بواسطة قاعدة البيانات وعقدة الخلية.

الفصل عن Exadata

عند تحديد أحمال عمل Oracle Exadata للترحيل إلى السحابة، ضع في اعتبارك الأسئلة ونقاط البيانات التالية:

• هل يستهلك حمل العمل ميزات Exadata متعددة، خارج مزايا الأجهزة؟
  • عمليات الفحص الذكية
  • فهارس التخزين
  • ذاكرة التخزين المؤقت الفلاش
  • التسجيل الفلاش
  • ضغط عمودي مختلط
• هل حمل العمل باستخدام تفريغ Exadata بكفاءة؟ في الأحداث الأمامية للوقت العلوي، ما هي النسبة (أكثر من 10٪ من وقت قاعدة البيانات) من حمل العمل باستخدام:
  • فحص الجدول الذكي للخلية (الأمثل)
  • قراءة فعلية متعددة القفل للخلية (أقل مثالية)
  • قراءة فعلية للكتلة المفردة للخلية (الأقل مثالية)
• ضغط العمود المختلط (HCC/EHCC): ما هي النسب المضغوطة مقابل النسب غير المضغوطة:
  • هل تنفق قاعدة البيانات أكثر من 10٪ من وقت قاعدة البيانات على ضغط البيانات وفك ضغطها؟
  • فحص مكاسب الأداء للمؤشرات باستخدام الضغط في الاستعلامات: هل القيمة المكتسبة تستحق ذلك مقابل المبلغ المحفوظ مع الضغط؟
• الإدخال/الإخراج الفعلي للخلية: افحص المدخرات المقدمة من:
  • المبلغ الموجه إلى عقدة DB لموازنة وحدة المعالجة المركزية.
  • تحديد عدد وحدات البايت التي يتم إرجاعها بواسطة الفحص الذكي. يمكن طرح هذه القيم في الإدخال/الإخراج للنسبة المئوية للقراءات الفعلية للكتلة المفردة للخلية بمجرد ترحيلها من Exadata.
• لاحظ عدد القراءات المنطقية من ذاكرة التخزين المؤقت. حدد ما إذا كانت ذاكرة التخزين المؤقت السريعة ستكون مطلوبة في حل IaaS السحابي لحمل العمل.
• قارن إجمالي وحدات البايت الفعلية للقراءة والكتابة بالمقدار الذي تم تنفيذه في ذاكرة التخزين المؤقت. هل يمكن رفع الذاكرة للقضاء على متطلبات القراءة المادية (من الشائع أن يتقلص البعض SGA لفرض إلغاء التحميل ل Exadata)؟
• في إحصائيات النظام، حدد الكائنات التي تتأثر بالإحصاءات. إذا كان ضبط SQL، فقد يؤدي المزيد من الفهرسة أو التقسيم أو الضبط المادي الآخر إلى تحسين حمل العمل بشكل كبير.
• فحص معلمات التهيئة للتسطير السفلي (_) أو المعلمات المهملة، والتي يجب تبريرها بسبب تأثير مستوى قاعدة البيانات التي قد تسببها على الأداء.

تكوين خادم Exadata

في Oracle الإصدار 12.2 والإصدارات الأحدث، سيتم تضمين إضافة خاصة ل Exadata في التقرير العالمي ل AWR. يحتوي هذا التقرير على أقسام توفر قيمة استثنائية للترحيل من Exadata.

• إصدار Exadata وتفاصيل النظام

• تفاصيل تنبيهات عقدة الخلية

• أقراص Exadata غير الخطية

• بيانات خارجية لأي إحصائيات نظام تشغيل Exadata

  • أصفر / وردي : من القلق. لا يعمل Exadata على النحو الأمثل.

  • أحمر: يتأثر أداء Exadata بشكل كبير.

  • إحصائية Exadata OS CPU: أعلى الخلايا

    • يتم تجميع هذه الإحصائيات بواسطة نظام التشغيل على الخلايا ولا تقتصر على قاعدة البيانات هذه أو المثيلات
    • v تشير خلفية أ وصفراء داكنة إلى قيمة أعلى أسفل النطاق المنخفض
    • ^ تشير خلفية أ وصفراء فاتحة إلى قيمة خارجية أعلى النطاق العالي
    • يتم عرض الخلايا العلوية حسب النسبة المئوية لوحدة المعالجة المركزية وهي بترتيب تنازلي للنسبة المئوية لوحدة المعالجة المركزية
    • المتوسط: 39.34٪ من وحدة المعالجة المركزية، 28.57٪ مستخدم، 10.77٪ sys

    

• قراءة كتلة فعلية أحادية الخلية

• استخدام ذاكرة التخزين المؤقت الفلاش

• Temp IO

• كفاءة ذاكرة التخزين المؤقت العمودية

أعلى قاعدة بيانات حسب معدل نقل IO

على الرغم من إمكانية إجراء تقييمات تغيير الحجم، هناك بعض الأسئلة حول المتوسطات وذرى المحاكاة المضمنة في هذه القيم لأحمال العمل الكبيرة. هذا القسم، الذي تم العثور عليه في نهاية تقرير AWR، ذو قيمة استثنائية لأنه يظهر متوسط استخدام الفلاش والقرص لقواعد البيانات العشرة الأولى على Exadata. على الرغم من أن الكثيرين قد يفترضون أنهم يريدون تغيير حجم قواعد البيانات لأقصى أداء في السحابة، فإن هذا ليس منطقيا لمعظم عمليات التوزيع (أكثر من 95٪ في النطاق المتوسط؛ مع حساب ذروة محاكاة، يكون متوسط النطاق أكبر من 98٪). من المهم أن تدفع مقابل ما هو مطلوب، حتى بالنسبة لأعلى أحمال عمل الطلب في Oracle، ويمكن أن يكون فحص أعلى قواعد البيانات بواسطة معدل نقل الإدخال والإخراج مستنيرا لفهم احتياجات الموارد لقاعدة البيانات.

Oracle بالحجم الصحيح باستخدام AWR على Exadata

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

إحدى فوائد السحابة هي تحجيم الموارد في مضيف الجهاز الظاهري ويمكن تنفيذ التخزين مع زيادة الطلبات. يساعد هذا في الحفاظ على تكاليف السحابة وتكاليف الترخيص المرفقة باستخدام المعالج (ذات الصلة ب Oracle).

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

قدر خبراء موضوع Microsoft Oracle أن أكثر من 80٪ من قواعد بيانات Oracle يتم توفيرها بشكل مفرط وتختبر إما نفس التكلفة أو الوفورات التي تذهب إلى السحابة إذا كانت تستغرق وقتا في الحجم الصحيح لحمل عمل قاعدة بيانات Oracle قبل الترحيل إلى السحابة. يتطلب هذا التقييم من المتخصصين في قاعدة البيانات في الفريق تغيير عقليتهم حول كيفية تنفيذهم لتخطيط السعة في الماضي، ولكن الأمر يستحق استثمار المساهم في السحابة واستراتيجية السحابة للأعمال.

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

• تشغيل أحمال عمل Oracle الأكثر تطلبا في Azure دون التضحية بالأداء أو قابلية التوسع
• تصميمات الحلول باستخدام Azure NetApp Files - Oracle
• تصميم قاعدة بيانات Oracle وتنفيذها في Azure
• أداة تقدير لتحجيم أحمال عمل Oracle إلى أجهزة Azure IaaS الظاهرية
• البنيات المرجعية ل Oracle Database Enterprise Edition على Azure
• فهم مجموعات وحدات تخزين تطبيق Azure NetApp Files ل SAP HANA