تكامل Rosplatform شديد التقارب على HPE Synergy مع أنظمة تخزين 3PAR



بطريقة ما كان من الضروري دمج Rosplatform (R-Virtualization و R-Storage) مع نظام تخزين الأجهزة ( 3PAR ) ، ويمكن أن يكون هذا مفيدًا جدًا في سيناريوهات مختلفة.



تكوين التآزر



في السابق ، تم اختبار هذا النوع من التكامل على الشفرات (Blade CH121 v5) لمركز Huawei Blade مع نظام تخزين Dorado 5000 v3 ، حيث أظهر SDS (التخزين المحدد بالبرمجيات) R-Storage من Rosplatforma أعلى نظام التخزين نفسه جيدًا بسبب كل الفلاش ، ولكن مع Synergy ، إذا كان متاحًا أقراص JBOD من الوحدة النمطية D3940 ، كل شيء أكثر إثارة للاهتمام ومرونة.



3 شفرات خادم (Synergy 480 Gen10 (871940-B21)):



  • يحتوي كل منها على وحدتي CPU Intel® Xeon® Platinum 8270.
  • شبكة منفذين 20 جيجابت / ثانية.
  • رام 256 جيجا.
  • لا توجد محركات أقراص صلبة في الشفرات.
  • في وحدة قرص Synergy 2HDD ، 900 جيجا بايت في RAID1 لكل نظام تشغيل / برنامج مراقبة و 3 SSD HPE VK0960GFDKK 960 جيجا بايت لدور البيانات الوصفية + ذاكرة التخزين المؤقت (لكل خادم واحد) ، بالإضافة إلى 9HDD EG0900JFCKB لـ 900 جيجا بايت.


تم تحميل نظام التشغيل عبر قناة عبر وحدة تحكم RAID من وحدة قرص Synergy.

تم نشر SDS المحلي عبر قناة JBOD من وحدة قرص التآزر.



تكوين 3PAR



3PAR (FC16 جيجابت / ثانية) متصلة بـ Synergy:

واحد LUN (واحد إلى كثير) RAID6 من SSD بسعة 200 جيجابايت. 9 LUN RAID6 من محرك الأقراص الثابتة ، سعة كل منها 150 جيجابايت (ثلاث وحدات LUN لكل شفرة).





الشكل: 1 مخطط منصة الاختبار.





وصف السيناريوهات



اختبرنا عدة خيارات للتكامل مع 3PAR ، والتي يمكن استخدامها أيضًا في نفس الوقت في تكوين مختلط.



السيناريو مع نشر SDS لـ Rosplatform على LUNs منفصلة سعة 150 جيجابايت لكل منها من 3PAR:





الشكل. تم تقديم سيناريو 2 مع نشر SDS لـ Rosplatform على LUNs منفصلة

مع أنظمة تخزين لكل عقدة من الثلاثة FC مع 3 LUNs سعة 150 جيجابايت .




في أنظمة التخزين ، تم تكوينها في RAID6 من أقراص HDD. في التين. 2 يظهر بشكل تخطيطي 10 جيجا بايت والتبديل ، ولكن التنفيذ كان على مستوى محول Synergy مع منافذ 20 جيجا بايت ، حيث تكون إحدى الواجهات للإدارة والمحاكاة الافتراضية ، والأخرى لتخزين SDS.



تم اختبار هذا السيناريو للتحقق من أن الخيارات التالية تعمل:



  • يعمل SDS Rosplatform فوق 3PAR.
  • تعزيز SDS لـ Rosplatforma عبر 3PAR من خلال إضافة ذاكرة تخزين SSD محلية.
  • من خلال إنشاء SDS Rosplatform صغير لتخزين ملفات تكوين VM ، حيث يتم إنشاء VMs نفسها على LUN 3PAR.
  • اختبار SDS Rosplatforma أعلى 3PAR ، وتحديد اندفاعة أبطأ قليلاً من اندفاعة من الأقراص المحلية.


2) سيناريو إنشاء VM على LUN من 3PAR:





الشكل. 3 سيناريو إنشاء VM على LUN من 3PAR.



تم تقديم LUN 200GB RAID6 من SSD لـ VM مع التخزين. تكوين LUN هو واحد إلى العديد.

تم اختبار هذا السيناريو للتحقق من القدرات:



  • تعلق على VM LUN من 3PAR مباشرة.
  • استخدام VM LUN المرفق كقرص أساسي دون استخدام qcow2.
  • استخدام أجهزة VM متعددة مع نفس 200GB LUN المرفقة للتثبيت اللاحق لنظام ملفات مجموعة الضيف.
  • ترحيل جهاز افتراضي بسعة 200 غيغابايت من LUN من 3PAR وفشل العقد مع إعادة تشغيل جهاز VM على العقد المتبقية.
  • استخدام SDS من 3PAR كتخزين لملفات تكوين VM ، ونظام التشغيل الضيف مع النشر إلى LUNs من 3PAR مباشرة.
  • استخدام SDS على الأقراص المحلية لوحدة Synergy كتخزين لملفات تكوين VM ، ونظام التشغيل الضيف مع النشر على LUN 200GB من 3PAR مباشرة.


وصف الإعدادات



بالنسبة لجميع السيناريوهات الموجودة على كل عقدة ، قبل النشر المعتاد للمجموعة ، تم إجراء نفس الإعدادات مسبقًا ، والتي تم إجراؤها مباشرةً بعد تثبيت ثلاث عقد من صور Rosplatform. تتوفر تعليمات موجزة لتثبيت وتكوين الكتلة نفسها في المقالة السابقة .



1.تمكين خدمة متعدد المسارات من التحميل التلقائي:



#chkconfig multipathd on


2- تمكين تحميل الوحدات:



#modprobe dm-multipath
#modprobe dm-round-robin


3. نسخ قالب التكوين إلى المجلد لتكوين العمل:



#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/


4- تحقق من نمط التضمين أسفل المعلمات التالية:



defaults {
        user_friendly_names yes
        find_multipaths yes
}


5.إضافة اسم مستعار لقرص مشترك لجهاز افتراضي:



multipaths {
        multipath {
#               wwid                    3600508b4000156d700012000000b0000
#               alias                   yellow
#               path_grouping_policy    multibus
#               path_selector           "round-robin 0"
#               failback                manual
#               rr_weight               priorities
#               no_path_retry           5
#       }
        multipath {
                wwid                    360002ac0000000000000000f000049f4
                alias                   test3par
        }
}


6- تحقق من بدء الخدمة:



#systemctl start multipathd


7. فحص الخدمة وعرض الأجهزة باستخدام mpath:



#multipath –ll


8. إعادة التشغيل الإلزامي:



#reboot


9. فحص الخدمة وعرض الأجهزة باستخدام mpath:



#multipath –ll


بعد ذلك ، تم تنفيذ إعدادات الكتلة القياسية.





الشكل: 4 واجهة مستخدم الويب قبل تمكين خدمة متعددة المسارات.





الشكل: 5 بعد تمكين خدمة متعددة المسارات ، ظهرت أجهزة dm.



لقطة شاشة بعد إنشاء مجموعة Rosplatforma ، حيث يكون 200GB LUN لأجهزة VM بشكل خاص مع دور غير مخصص:





الشكل. 6 لقطة شاشة بعد إنشاء مجموعة Rosplatforma.



تُظهر لقطة الشاشة مستويين 0 و 1 ، حيث المستوى 0 هو SDS المحلي ، والمستوى 1 هو SDS على 3PAR:





الشكل. 7 SDS المحلية وأكثر من 3PAR.



بعد ذلك ، تم إنشاء VM بدون قرص محلي مع 200GB LUN من 3PAR المرفقة بدلاً من ذلك:



#prlctl set testVM --device-add hdd --device /dev/mapper/ test3par


تم إنشاء الجهاز الظاهري بالمعلمات التالية:



  • اكتب - CentOS Linux
  • vCPU - 4
  • ذاكرة الوصول العشوائي - 8
  • Guest OS - Centos 7 (1908)


اختبارات الهجرة



تم إجراء اختبارات الترحيل مع تثبيت أدوات الضيف أو بدونها.

في جميع الحالات ، تم ترحيل الجهاز الظاهري بنجاح دون توقف.





الشكل: 8 نتيجة ووقت ترحيل VM.



Test1 - جهاز افتراضي عادي مع نفس المعلمات فقط مع صورة قرص محلي QCOW2 64 جيجابايت وترحيل مباشر لاختبار 10 VM مع 200 جيجابايت LUN من 3PAR



وقت الترحيل أقل بسبب حقيقة أنه أثناء العملية لا توجد خطوة للتبديل إلى نسخة من صورة قرص VM على عقدة أخرى ، يتم نسخ ملف التكوين فقط مع ارتباط إلى LUN 200GB ، والذي يكون مرئيًا من أي عقدة من الكتلة.





الشكل: 9 نتائج بينغ.



أثناء الترحيل المباشر ، تم إجراء اختبار ping على الجهاز الظاهري بسعة 200 غيغابايت LUN من 3PAR.



تم تسجيل فقدان حزمة واحدة فقط ، ويحدث نفس الشيء مع جهاز افتراضي عادي على SDS ، ولكن يظل الجهاز الظاهري متاحًا عبر الشبكة ويستمر في العمل.



اختبارات الاغلاق في حالات الطوارئ



عندما تم إيقاف تشغيل الخادم ، حيث كان هناك جهاز افتراضي به 200 جيجابايت LUN من 3PAR ، وبعد أن اكتشفت خدمة HA العقدة المفقودة ، تمت إعادة تشغيل الجهاز الظاهري قيد الاختبار بنجاح على عقدة أخرى تم تحديدها وفقًا لخوارزمية drs الافتراضية ، round robin ، ومواصلة العمل. أثناء اختبار ping ، فقدت 7 حزم. عند التبديل ، تم تشغيل ملف تكوين VM فقط ، وكان يمكن الوصول إلى نظام التشغيل الضيف دائمًا عبر المسار المرفق بـ LUN.



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







اختبارات الكتابة التسلسلية إلى VM مع 200GB LUN من 3PAR ، والتي أظهرت أداء LUN هذا من 3PAR ، حيث لم يكن Rosplatforma طبقة وسيطة ، ويظهر الاختبار تشغيل نظام التشغيل الضيف وأنظمة التخزين 3PAR.



معلمات fio المستخدمة داخل VM مع 200GB LUN من 3PAR:



[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/


الاختبارات باستخدام نظام ملفات مجمع داخل نظام التشغيل الضيف





الشكل: 10 نظام ملفات مجمعة داخل نظام التشغيل الضيف.



تم بنجاح اختبار سيناريو به وحدة تخزين LUN بسعة 200 جيجابايت متصلة بجهازي VM ، حيث يتم تثبيت نظام ملفات مجموعة GFS2 داخل الجهاز الظاهري باستخدام نظام التشغيل الضيف. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة الافتراضية أو المضيف ، وبعد ذلك واصل الجهاز الظاهري الآخر العمل مع LUN وكتابة / قراءة الملفات من هناك. يوجد أدناه لقطة شاشة لإعدادات GFS2 داخل الجهاز الظاهري ، كما تظهر مخرجات أوامر منظم ضربات القلب:







SDS إضافي لنظام Rosplatforma أعلى LUN:





الشكل. 11 التكوين باستخدام SDS Rosplatform المنشور على 3PAR LUN.



تم اختبار نفس السيناريو بنجاح مع وحدة LUN بسعة 200 جيجابايت متصلة بجهازي VM ، حيث تم تثبيت نظام ملفات الكتلة داخل الجهاز الظاهري عن طريق نظام التشغيل الضيف ، ولكن تم استخدام مخزن البيانات من SDS Rosplatforma الذي تم إنشاؤه على LUN من 3PAR كموقع VM. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة الافتراضية أو المضيف ، وبعد ذلك واصل الجهاز الظاهري الآخر العمل مع LUN وكتابة / قراءة الملفات من هناك.





الشكل: 12 اختبار مع إضافة SSD لدور ذاكرة التخزين المؤقت من وحدة قرص Synergy.



تم اختبار نفس السيناريو بنجاح مع وحدة LUN بسعة 200 جيجا بايت متصلة بجهازي VM ، حيث تم تثبيت نظام ملفات الكتلة داخل الجهاز الظاهري باستخدام نظام التشغيل الضيف ، ولكن تم استخدام مخزن البيانات من SDS Rosplatforma الذي تم إنشاؤه على LUN من 3PAR كموقع VM. بالإضافة إلى ذلك ، تم تحسين أداء مخزن البيانات هذا عن طريق إضافة SSD كذاكرة تخزين مؤقت من وحدة قرص Synergy. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة الافتراضية أو المضيف ، وبعد ذلك واصل الجهاز الظاهري الآخر العمل مع LUN وكتابة / قراءة الملفات من هناك.



اختبارات نظام ملفات الكتلة على عقد Rosplatform





الشكل: تم تقديم 13 اختبارًا باستخدام ملفات تكوين VM الموجودة على SDS Rosplatforma ، من 3PAR LUN 200GB.



تم اختبار سيناريو مع التخزين المشترك من 3PAR لصور قرص VM على نظام ملفات الكتلة ، والذي تم تثبيته على عقد Rosplatforma ، وكانت ملفات التكوين لهذه الأجهزة الظاهرية موجودة على SDS لـ Rosplatforma. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة المضيفة ، وبعد ذلك اضطرت الأجهزة الافتراضية إلى مواصلة العمل مع صور القرص الخاصة بها بسبب عمل مضيفين آخرين وفقًا للنسخة المتماثلة 3 على مجموعة SDS لملفات تكوين VM و 3 سجلات لنظام ملفات الكتلة لصور قرص VM.





الشكل: يتم إحضار 14 SDS إلى LUN من 3PAR.



تم اختبار سيناريو مع التخزين المشترك من 3PAR لصور قرص VM على نظام ملفات الكتلة ، والذي تم تثبيته على عقد Rosplatforma ، وكانت ملفات التكوين لهذه الأجهزة الافتراضية موجودة على SDS من Rosplatforma ، حيث تم رفع SDS إلى LUN من 3PAR. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة المضيفة ، وبعد ذلك كان على الأجهزة الافتراضية الاستمرار في العمل مع صور القرص الخاصة بهم بسبب عمل مضيفين آخرين وفقًا للنسخة المتماثلة 3 على مجموعة SDS لملفات تكوين VM و 3 سجلات لنظام الملفات العنقودية لصور قرص VM.





الشكل: 15 SDS من المستوى 0 على LUNs من 3PAR ، SDS من المستوى 1 على الأقراص من وحدة التآزر.



تم اختبار سيناريو مع التخزين المشترك من 3PAR لصور قرص VM على نظام ملفات الكتلة ، والذي تم تثبيته على عقد Rosplatforma ، وكانت ملفات التكوين لهذه الأجهزة الافتراضية موجودة على SDS Rosplatforma ، حيث تم رفع SDS tier0 على LUN من 3PAR و SDS المستوى 1 على الأقراص من الوحدة النمطية التعاضد. أثناء الاختبار ، تم إيقاف تشغيل أحد الأجهزة المضيفة ، وبعد ذلك كان على الأجهزة الافتراضية العمل مع صور القرص الخاصة بهم بسبب عمل مضيفين آخرين وفقًا للنسخة المتماثلة 3 على مجموعة SDS لملفات تكوين VM و 3 سجلات لنظام الملفات العنقودية لصور قرص VM. ولكن كانت هناك مشاكل في عمل kvm-qemu مع GFS2 ، بعد تحقيق طويل ، فشل مدير القفل من GFS2 ولم يتمكن Rosplatforma من بدء تشغيل VM على مضيف آخر للكتلة بسبب هذا. السؤال لا يزال مفتوحا. الشيء نفسه مع الخيارات في الشكل 13 و 14.تكمن المشكلة المحتملة في هذا السيناريو في الطريقة التي يعمل بها kvm-qemu مع qcow2 والصورة الأولية ، حيث تكون عمليات الكتابة متزامنة ، ويكون مدير قفل GFS2 محدودًا لمثل هذه العمليات.



خاتمة



تعمل الخيارات من SDS إلى LUN من 3PAR و LUN من 3PAR بشكل جيد ويمكن استخدامها للعمل في البنية التحتية ، ولكن بالطبع لها بعض العيوب.



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



السيناريوهات ذات العرض التقديمي LUN للأجهزة الافتراضية ، لأنظمة الضيف مع نظام المجموعة الخاص بها هي أيضًا ذات صلة. في حالة تقديم LUNs لكل جهاز افتراضي على حدة ، تظهر عيوب مثل عدم وجود أتمتة أثناء دورة حياة عدد كبير من الأجهزة الظاهرية ، والتي قد تكون بسبب نظام الملفات العنقودية على عقد Rosplatform ، لكن GFS2 مع kvm-qemu في هذه الحالة فشل ، إذا كان استخدم مع أي ملفات أخرى ، فكل شيء يعمل حتى في اختبارات الطوارئ على Rosplatform ، ولكن بمجرد وضع صور VM هناك ، لا يتعامل مدير قفل GFS2 مع اختبارات الطوارئ. ربما سيتم حل هذه المشكلة.



يمكن أن تكون السيناريوهات أعلاه لاستخدام متعدد المسارات مفيدة لربط مكتبات الأشرطة. يحتوي Rosplatform على نظام نسخ احتياطي مدمج (SRK) ، والذي يمكنه كتابة نسخ إلى مجلد مجموعة P-storage أو مجلد محلي ، ولكن لا يمكنه العمل مع أجهزة الشريط حتى تكتب نصًا بنفسك ، أو لهذه الأغراض يمكنك استخدام SRK خارجي على سبيل المثال rubackup ، والذي بالإضافة إلى العمل مع الشريط ، فإنه سيساعد في عمل نسخ من الأجهزة الافتراضية مع LUNs المرفقة ، وهو أمر مهم عند الدمج مع أنظمة التخزين



All Articles