تحسين جهاز Linux الظاهري الخاص بك على Azure
من السهل إنشاء جهاز ظاهري Linux (VM) من سطر الأوامر أو من البوابة الإلكترونية. يوضح لك هذا البرنامج التعليمي كيفية التأكد من إعداده لتحسين أدائه على النظام الأساسي Microsoft Azure. يستخدم هذا الموضوع جهاز ظاهري Ubuntu Server ، ولكن يمكنك أيضا إنشاء جهاز ظاهري Linux باستخدام صورك الخاصة كقوالب.
المتطلبات الأساسية
يفترض هذا الموضوع أن لديك بالفعل اشتراك Azure يعمل (اشتراك تجريبي مجاني) وقمت بالفعل بتوفير جهاز ظاهري في اشتراك Azure الخاص بك. تأكد من تثبيت أحدث إصدار من Azure CLI وتسجيل الدخول إلى اشتراكك في Azure باستخدام تسجيل الدخول إلى az قبل إنشاء جهاز ظاهري.
Azure OS Disk
بمجرد إنشاء جهاز ظاهري Linux في Azure ، فإنه يحتوي على قرصين مقترنين به. /dev/sda هو قرص نظام التشغيل الخاص بك، /dev/sdb هو القرص المؤقت الخاص بك. لا تستخدم قرص نظام التشغيل الرئيسي (/dev/sda) لأي شيء باستثناء نظام التشغيل لأنه محسن لوقت تمهيد VM السريع ولا يوفر أداء جيدا لأحمال العمل الخاصة بك. تريد إرفاق قرص واحد أو أكثر بالجهاز الظاهري للحصول على مساحة تخزين ثابتة ومحسنة لبياناتك.
إضافة أقراص لأهداف الحجم والأداء
استنادا إلى حجم الجهاز الظاهري، يمكنك توصيل ما يصل إلى 16 قرصا إضافيا على الفئة A و32 قرصا على الفئة D و64 قرصا على جهاز من الفئة G - يصل حجم كل منها إلى 32 تيرابايت. يمكنك إضافة أقراص إضافية حسب الحاجة وفقا لمتطلبات المساحة و IOps. يحتوي كل قرص على هدف أداء يبلغ 500 IOps للتخزين القياسي وما يصل إلى 20000 IOps لكل قرص لتخزين Premium.
لتحقيق أعلى IOps على أقراص التخزين Premium حيث تم تعيين إعدادات ذاكرة التخزين المؤقت الخاصة بهم إما للقراءة فقط أو لا شيء، يجب تعطيل الحواجز أثناء تركيب نظام الملفات في Linux. لا تحتاج إلى حواجز لأن الأقراص المدعومة بالكتابة إلى Premium التخزين متينة لإعدادات ذاكرة التخزين المؤقت هذه.
- إذا كنت تستخدم reiserFS، فقم بتعطيل الحواجز باستخدام خيار
barrier=none
التركيب (لتمكين الحواجز، استخدمbarrier=flush
) - إذا كنت تستخدم ext3 / ext4 ، فقم بتعطيل الحواجز باستخدام خيار
barrier=0
التركيب (لتمكين الحواجز ، استخدمbarrier=1
) - إذا كنت تستخدم XFS ، فقم بتعطيل الحواجز باستخدام خيار
nobarrier
التركيب (لتمكين الحواجز ، استخدم الخيارbarrier
)
اعتبارات حساب التخزين غير المدار
الإجراء الافتراضي عند إنشاء جهاز ظاهري باستخدام Azure CLI هو استخدام أقراص Azure المدارة. تتم معالجة هذه الأقراص بواسطة النظام الأساسي Azure ولا تتطلب أي إعداد أو موقع لتخزينها. تتطلب الأقراص غير المدارة حساب تخزين ولها بعض اعتبارات الأداء الإضافية. لمزيد من المعلومات حول الأقراص المدارة، راجع نظرة عامة على الأقراص المدارة في Azure. يوضح القسم التالي اعتبارات الأداء فقط عند استخدام الأقراص غير المدارة. مرة أخرى ، حل التخزين الافتراضي والموصى به هو استخدام الأقراص المدارة.
إذا قمت بإنشاء جهاز ظاهري مع أقراص غير مدارة، فتأكد من إرفاق الأقراص من حسابات التخزين الموجودة في نفس المنطقة مثل الجهاز الظاهري لضمان القرب وتقليل زمن انتقال الشبكة. يحتوي كل حساب تخزين قياسي على 20 ألف IOps كحد أقصى وسعة بحجم 500 تيرابايت. يعمل هذا الحد على ما يقرب من 40 قرصا مستخدما بكثافة بما في ذلك كل من قرص نظام التشغيل وأي أقراص بيانات تقوم بإنشائها. بالنسبة Premium حسابات التخزين، لا يوجد حد أقصى لعمليات IOps ولكن هناك حد أقصى لحجم 32 تيرابايت.
عند التعامل مع أحمال عمل IOps عالية واخترت التخزين القياسي لأقراصك، قد تحتاج إلى تقسيم الأقراص عبر حسابات تخزين متعددة للتأكد من أنك لم تصل إلى حد 20000 IOps لحسابات التخزين القياسية. يمكن أن يحتوي الجهاز الظاهري على مزيج من الأقراص من مختلف حسابات التخزين وأنواع حسابات التخزين لتحقيق التكوين الأمثل.
محرك الأقراص المؤقت VM الخاص بك
بشكل افتراضي عند إنشاء جهاز ظاهري، يوفر لك Azure قرص نظام تشغيل (/dev/sda) وقرص مؤقت (/dev/sdb). تظهر جميع الأقراص الإضافية التي تضيفها ك /dev/sdc و/dev/sdd و/dev/sde وما إلى ذلك. جميع البيانات الموجودة على القرص المؤقت (/dev/sdb) ليست دائمة، ويمكن فقدانها إذا كانت أحداث محددة مثل تغيير حجم الجهاز الظاهري أو إعادة نشره أو صيانته تفرض إعادة تشغيل الجهاز الظاهري. يرتبط حجم القرص المؤقت ونوعه بحجم الجهاز الظاهري الذي اخترته في وقت النشر. يتم دعم جميع الأجهزة الظاهرية ذات الحجم المتميز (سلسلة DS و G و DS_V2) محرك الأقراص المؤقت بواسطة SSD محلي للحصول على أداء إضافي يصل إلى 48k IOps.
قسم مبادلة لينكس
إذا كان جهاز Azure الظاهري الخاص بك من صورة Ubuntu أو CoreOS ، فيمكنك استخدام CustomData لإرسال تكوين سحابي إلى cloud-init. إذا قمت بتحميل صورة Linux مخصصة تستخدم السحابة init، فيمكنك أيضا تكوين أقسام المبادلة باستخدام cloud-init.
لا يمكنك استخدام الملف / etc/waagent.conf لإدارة المبادلة لجميع الصور التي يتم توفيرها ودعمها بواسطة cloud-init. للحصول على القائمة الكاملة للصور، راجع استخدام السحابة init.
أسهل طريقة لإدارة المبادلة لهذه الصور هي إكمال الخطوات التالية:
في المجلد / var/lib/cloud/scripts/per-boot ، قم بإنشاء ملف يسمى create_swapfile.sh:
$ سودو تاتش / فار / ليب / سحابة / البرامج النصية / لكل تمهيد / create_swapfile.sh
إضافة الأسطر التالية إلى الملف:
$ سودو السادس / var / lib / سحابة / البرامج النصية / لكل تمهيد / create_swapfile.sh
#!/bin/sh if [ ! -f '/mnt/swapfile' ]; then fallocate --length 2GiB /mnt/swapfile chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile swapon -a ; fi
ملاحظة
يمكنك تغيير القيمة وفقا لحاجتك واستنادا إلى المساحة المتوفرة في قرص المورد الخاص بك، والتي تختلف بناء على حجم الجهاز الظاهري المستخدم.
اجعل الملف قابلا للتنفيذ:
$ سودو chmod +x / var / lib / cloud / scripts / per boot / create_swapfile.sh
لإنشاء ملف المبادلة ، قم بتنفيذ البرنامج النصي مباشرة بعد الخطوة الأخيرة:
$ سودو / var / lib / سحابة / البرامج النصية / لكل تمهيد / ./create_swapfile.sh
بالنسبة للصور التي لا تحتوي على دعم سحابي ، يجب أن تحتوي صور VM التي يتم نشرها من Azure Marketplace على عامل VM Linux مدمج مع نظام التشغيل. يسمح هذا العامل للجهاز الظاهري بالتفاعل مع خدمات Azure المختلفة. على افتراض أنك قمت بنشر صورة قياسية من Azure Marketplace ، فستحتاج إلى القيام بما يلي لتكوين إعدادات ملف مبادلة Linux بشكل صحيح:
حدد موقع إدخالين وتعديلهما في الملف /etc/waagent.conf. أنها تتحكم في وجود ملف مبادلة مخصص وحجم ملف المبادلة. المعلمات التي تحتاج إلى التحقق منها هي ResourceDisk.EnableSwap
و ResourceDisk.SwapSizeMB
لتمكين قرص ممكن بشكل صحيح وملف مبادلة مثبت، تأكد من أن المعلمات تحتوي على الإعدادات التالية:
- ResourceDisk.EnableSwap=Y
- ResourceDisk.SwapSizeMB={size in MB لتلبية احتياجاتك}
بمجرد إجراء التغيير ، تحتاج إلى إعادة تشغيل waagent أو إعادة تشغيل جهاز Linux الظاهري ليعكس هذه التغييرات. أنت تعلم أنه تم تنفيذ التغييرات وتم إنشاء ملف مبادلة عند استخدام free
الأمر لعرض المساحة الحرة. يحتوي المثال التالي على ملف مبادلة 512 ميجابايت تم إنشاؤه نتيجة لتعديل الملف waagent.conf :
azuseruser@myVM:~$ free
total used free shared buffers cached
Mem: 3525156 804168 2720988 408 8428 633192
-/+ buffers/cache: 162548 3362608
Swap: 524284 0 524284
خوارزمية جدولة الإدخال/الإخراج لتخزين Premium
باستخدام نواة Linux 2.6.18 ، تم تغيير خوارزمية جدولة الإدخال / الإخراج الافتراضية من الموعد النهائي إلى CFQ (خوارزمية الانتظار العادلة تماما). بالنسبة لأنماط الإدخال/الإخراج للوصول العشوائي، هناك فرق ضئيل في اختلافات الأداء بين CFQ والموعد النهائي. بالنسبة للأقراص المستندة إلى SSD حيث يكون نمط الإدخال/الإخراج على القرص متسلسلا في الغالب، يمكن أن يؤدي التبديل مرة أخرى إلى خوارزمية NOOP أو Deadline إلى تحقيق أداء إدخال/إخراج أفضل.
عرض جدولة الإدخال/الإخراج الحالية
استخدم الأمر التالي:
cat /sys/block/sda/queue/scheduler
تشاهد الإخراج التالي ، والذي يشير إلى المجدول الحالي.
noop [deadline] cfq
تغيير الجهاز الحالي (/dev/sda) لخوارزمية جدولة الإدخال/الإخراج
استخدم الأوامر التالية:
azureuser@myVM:~$ sudo su -
root@myVM:~# echo "noop" >/sys/block/sda/queue/scheduler
root@myVM:~# sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"/g' /etc/default/grub
root@myVM:~# update-grub
ملاحظة
تطبيق هذا الإعداد ل / dev/sda وحده ليس مفيدا. قم بتعيينه على جميع أقراص البيانات حيث يهيمن الإدخال/الإخراج المتسلسل على نمط الإدخال/الإخراج.
يجب أن تشاهد الإخراج التالي ، مما يشير إلى أنه تم إعادة إنشاء grub.cfg بنجاح وأنه تم تحديث المجدول الافتراضي إلى NOOP.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-34-generic
Found initrd image: /boot/initrd.img-3.13.0-34-generic
Found linux image: /boot/vmlinuz-3.13.0-32-generic
Found initrd image: /boot/initrd.img-3.13.0-32-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
بالنسبة لعائلة توزيع Red Hat ، تحتاج فقط إلى الأمر التالي:
echo 'echo noop >/sys/block/sda/queue/scheduler' >> /etc/rc.local
يستخدم Ubuntu 18.04 مع النواة المضبوطة بواسطة Azure برامج جدولة إدخال/إخراج متعددة قوائم الانتظار. في هذا السيناريو ، none
هو الاختيار المناسب بدلا من noop
. لمزيد من المعلومات، راجع جداول إدخال/إخراج Ubuntu.
استخدام تقنية RAID البرمجية لتحقيق عمليات إدخال/تشغيل أعلى
إذا كانت أحمال العمل تتطلب عمليات IOps أكثر مما يمكن أن يوفره قرص واحد، فأنت بحاجة إلى استخدام تكوين RAID برمجي لأقراص متعددة. نظرا لأن Azure يقوم بالفعل بتنفيذ مرونة القرص في طبقة النسيج المحلية، فإنك تحقق أعلى مستوى من الأداء من تكوين شريط RAID-0. يمكنك توفير الأقراص وإنشائها في بيئة Azure وإرفاقها بجهاز Linux الظاهري قبل تقسيم محركات الأقراص وتنسيقها وتركيبها. يمكن العثور على مزيد من التفاصيل حول تكوين إعداد RAID للبرنامج على جهاز Linux VM في azure في مستند تكوين برنامج RAID على Linux .
كبديل لتكوين RAID التقليدي، يمكنك أيضا اختيار تثبيت إدارة وحدات التخزين المنطقية (LVM) لتكوين عدد من الأقراص الفعلية في وحدة تخزين منطقية مخططة واحدة. في هذا التكوين، يتم توزيع عمليات القراءة والكتابة على أقراص متعددة مضمنة في مجموعة وحدات التخزين (على غرار RAID0). لأسباب تتعلق بالأداء ، من المحتمل أنك ستحتاج إلى تخطيط وحدات التخزين المنطقية الخاصة بك بحيث تستخدم عمليات القراءة والكتابة جميع أقراص البيانات المرفقة. يمكن العثور على مزيد من التفاصيل حول تكوين وحدة تخزين منطقية مخططة على جهاز Linux الظاهري في Azure في تكوين LVM على جهاز ظاهري Linux في مستند Azure .
الخطوات التالية
تذكر ، كما هو الحال مع جميع مناقشات التحسين ، تحتاج إلى إجراء اختبارات قبل وبعد كل تغيير لقياس تأثير التغيير. التحسين هو عملية خطوة بخطوة لها نتائج مختلفة عبر أجهزة مختلفة في بيئتك. ما يصلح لتكوين واحد قد لا يعمل مع الآخرين.
بعض الروابط المفيدة لموارد إضافية: