لماذا التقارب المفرط؟ نظرة عامة واختبارات Cisco HyperFlex

في تكنولوجيا المعلومات ، الشيء الرئيسي هو ثلاثة أحرف


تتمثل مهمة أي بنية تحتية لتكنولوجيا المعلومات في توفير منصة موثوقة لعمليات أعمال الشركة. يُعتقد تقليديًا أن جودة البنية التحتية لتكنولوجيا المعلومات يتم تقييمها وفقًا لثلاثة معايير رئيسية: إمكانية الوصول والأمن والموثوقية. ومع ذلك ، لا يرتبط التقييم لهذا الثلاثي بأي حال من الأحوال بالعمل والدخل / الخسارة المباشرة للشركة.

ثلاثة أحرف رئيسية تحكم تكنولوجيا المعلومات. إذا لم تكن الأحرف "RUB" على رأس التسلسل الهرمي لتكنولوجيا المعلومات ، فأنت تقوم ببناء البنية التحتية لتكنولوجيا المعلومات بشكل غير صحيح. بالطبع ، من الصعب بناء تكنولوجيا المعلومات بشكل مباشر ، بدءًا من الدخل / المصروفات فقط ، وبالتالي هناك تسلسل هرمي مكون من "ثلاثة أحرف" - من الأكثر أهمية إلى الأكثر خصوصية. SLA ، RPO ، RTO ، GRC - كل هذا معروف لخبراء الصناعة ويستخدم منذ فترة طويلة في بناء البنية التحتية. لسوء الحظ ، لا تربط هذه المؤشرات دائمًا بتسلسل هرمي من طرف إلى طرف.



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



سدس


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

حفزت التكلفة العالية والتعقيد إنشاء أنظمة تخزين البرامج على رأس أجهزة x86 المعتادة مع نظام تشغيل عام للأغراض العامة - Windows أو Linux أو FreeBSD أو Solaris. بقيت البرامج فقط من الأجهزة المخصصة المعقدة ، لا تعمل حتى في النواة ، ولكن على مستوى المستخدم. كانت أنظمة البرمجيات الأولى بالطبع بسيطة للغاية ومحدودة في الوظائف ، غالبًا ما كانت حلول متخصصة متخصصة ، ولكن الوقت مضى. والآن بدأ حتى بائعي أنظمة التخزين الكبيرة في التخلي عن حلول الأجهزة المتخصصة - لم تعد TTM لمثل هذه الأنظمة قادرة على تحمل المنافسة ، وأصبحت تكلفة الخطأ عالية جدًا. في الواقع ، مع استثناءات نادرة ، حتى أنظمة التخزين الكلاسيكية بحلول عام 2020 أصبحت خوادم x86 الأكثر شيوعًا ، فقط مع كمامات بلاستيكية جميلة ومجموعة من رفوف القرص.

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

تقارب مفرط


كانت الخطوة الأكثر وضوحًا في المستقبل هي توحيد نقاط تخزين ومعالجة البيانات المتباينة سابقًا. بمعنى آخر ، لماذا لا يتم تنفيذ التخزين الموزع ليس على خوادم منفصلة ، ولكن مباشرة على مضيفي المحاكاة الافتراضية ، وبالتالي رفض شبكة تخزين خاصة وأجهزة مخصصة ، وبالتالي الجمع بين الوظائف. استيقظ كراكن.
لكن دعني أقول ، لأن التلاقي هو التقارب. من أين أتت هذه البادئة الغبية؟
. + + . . , “ ”.

, , , . — SDS.

:

  • — , , , /. .
  • نظام متقارب - كل ذلك من مصدر واحد ، دعم واحد ، رقم شريك واحد. يجب عدم الخلط بينه وبين التجميع الذاتي من بائع واحد.

واتضح أن المصطلح لهندستنا المتقاربة مأخوذ بالفعل. بالضبط نفس الوضع كما هو الحال مع المشرف.

Hyperconverged System - نظام متقارب مع بنية متقاربة.

تم أخذ التعريفات من مقالة " النظرية العامة وعلم الآثار للمحاكاة الافتراضية " ، التي شاركت في كتابتها بحيوية.

ما الذي يعطي نهج التقارب المفرط في تطبيق الحروف الثلاثة المذكورة؟

  • ابدأ بالحجم الأدنى (والحد الأدنى للتكلفة)
  • تنمو سعة التخزين مع قوة الحوسبة
  • كل عقدة في النظام هي وحدة التحكم الخاصة بها - وتتم إزالة مشكلة "السقف الزجاجي" (يمكن للأقراص ، ولكن وحدة التحكم لم تعد موجودة)
  • تبسيط إدارة التخزين بشكل كبير

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

بمعنى آخر ، الغيوم فقط هي الأسرع من الأنظمة شديدة التقارب في إطلاق منتج ، ولكن الغيوم ليست مناسبة للجميع و / أو ليس دائمًا.

إذا كنت مسؤولًا فنيًا وقرأت حتى هنا - فابتهج ، فقد انتهت الكلمات العامة ، والآن سأخبرك عن وجهة نظري الشخصية لنظام Cisco Hyperflex ، الذي حصلت عليه في كفوف عنيدة لإجراء اختبارات مختلفة عليه.

Cisco Hyperflex


لماذا سيسكو


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

والمثير للدهشة أنه بحلول عام 2020 ، لا يزال هناك أشخاص: "خوادم Cisco؟ ومن من تأخذهم؟ "
بدأت Cisco في التعامل مع الخوادم بالفعل في عام 2009 ، باختيار مسار حلول الشفرة المتزايدة بنشاط في ذلك الوقت. كانت فكرة شركة Cisco هي تنفيذ نهج الآلات الحاسبة المجهولة. وكانت النتيجة نظام UCS (نظام الحوسبة الموحدة) الذي يتكون من مفتاحين متخصصين (كانا يطلقان عليه اسم الربط البيني) ، ومن 1 إلى 20 هيكل (8 شفرات نصف حجم) أو ما يصل إلى 160 خادمًا. في الوقت نفسه ، أصبح الهيكل غبيًا بشكل عام بقطعة من الحديد مع الطاقة ، وكل المنطق والتبديل مصنوع في النسيج المتداخل ؛ الشاسيه هو مجرد وسيلة لاستضافة الخوادم وربطها بالنظام. تعد Fabric Interconnect مسؤولة تمامًا عن جميع تفاعلات الخادم مع العالم الخارجي - Ethernet و FC والإدارة. يبدو أن الشفرات والشفرات ، ما هو موجود ، باستثناء التبديل الخارجي ، وليس مثل أي شخص آخر في الهيكل.

لحظة مهمة في تنفيذ نفس "الآلات الحاسبة المجهولة". كجزء من مفهوم Cisco UCS ، لا تتمتع الخوادم بأي شخصية بخلاف الرقم التسلسلي. لا MAC ، ولا WWN ، ولا أي شيء آخر. يعتمد نظام إدارة UCS المشغّل بواسطة Fabric Interconnect على ملفات تعريف وقوالب الخادم. بعد توصيل مجموعة من الخوادم في الهيكل ، يجب تعيين ملف تعريف مناسب ، يتم فيه تعيين جميع العناوين والمعرفات. بالطبع ، إذا كان لديك عشرة خوادم فقط ، فلن تكون اللعبة تستحق العناء. ولكن عندما يكون هناك ما لا يقل عن اثنين ، أو حتى عشرات منهم ، فإن هذه ميزة خطيرة. يصبح من السهل والسريع ترحيل التهيئة ، أو الأهم من ذلك ، تكرار تهيئات الخادم بالمبلغ الصحيح ، وتطبيق التغييرات فورًا على عدد كبير من الخوادم ،إدارة مجموعة من الخوادم بشكل أساسي (على سبيل المثال ، مزرعة افتراضية) ككيان واحد. يسمح النهج المقترح داخل نظام UCS ، مع النهج الصحيح ، بتبسيط حياة المديرين بشكل جدي ، وزيادة المرونة وتقليل المخاطر بشكل كبير ، لذلك أصبحت شفرات UCS حرفيا في غضون 2-3 سنوات المنصة الأكثر مبيعا في النصف الغربي من الكرة الأرضية ، وهي اليوم على مستوى العالم واحدة من منصتين مهيمنتين ، إلى جانب HPE.

أصبح من الواضح بسرعة أن نفس النهج القائم على مصنع عالمي مع إدارة متكاملة تستند إلى سياسات وقوالب مطلوب بالكامل ولا ينطبق فقط على الشفرات ، ولكن أيضًا على خوادم الرف. وبهذا المعنى ، تحصل خوادم Cisco القائمة على الحامل المتصلة بـ Fabric Interconnect على نفس الفوائد التي تجعل الشفرات شائعة جدًا.

اليوم سأتحدث عن HyperFlex ، وهو حل Cisco hyperconverged مبني على خوادم مثبتة على حامل متصلة بـ Fabric Interconnect. ما الذي يجعل HyperFlex مثيرًا للاهتمام ويستحق النظر في المراجعة:

  • Cisco , , «» – , HyperFlex; , , , HyperFlex ;
  • – ; HyperFlex , , ; , .
  • « » — « », , ;
  • Fabric Interconnect Cisco -, SAN , native FC;
  • “” – , , ;
  • Cisco , , , ;
  • , , Cisco HCI, , HyperFlex , , .


HyperFlex هو نظام حقيقي متقارب للغاية مع أجهزة تحكم مخصصة. اسمحوا لي أن أذكرك بأن الميزة الرئيسية لمثل هذه الهندسة هي قابليتها المحتملة لأجهزة hypervisors المختلفة. اليوم ، نفذت Cisco دعمًا لـ VMware ESXi و Microsoft Hyper-V ، ولكن من المحتمل أن يظهر أحد خيارات KVM مع تزايد شعبيتها في قطاع الشركات.

فكر في آلية العمل على مثال ESXi.

يتم طرح الأجهزة التي تستخدم تقنية VM_DIRECT_PATH - قرص التخزين المؤقت وأقراص مستوى التخزين - مباشرة إلى جهاز التحكم VM (المشار إليه فيما يلي باسم CVM). لذلك ، نستبعد تأثير رصة القرص hypervisor على الأداء. يتم تثبيت حزم VIB إضافية في برنامج Hypervisor نفسه:

  • IO Visor: يوفر نقطة التثبيت لمخزن بيانات NFS الخاص ببرنامج Hypervisor
  • VAAI: VMware API « »

يتم توزيع كتل الأقراص الظاهرية بالتساوي عبر جميع المضيفين في مجموعة مع دقة ضئيلة نسبيًا. عندما يقوم VM على المضيف ببعض عمليات القرص ، من خلال رصة القرص لبرنامج Hypervisor ، تذهب العملية إلى مخزن البيانات ، ثم إلى IO Visor ، ثم تتحول إلى CVM المسؤول عن هذه الكتل. في هذه الحالة ، يمكن وضع CVM على أي مضيف في المجموعة. بالنظر إلى الموارد المحدودة جدًا لـ IO Visor ، لا توجد بالطبع جداول بيانات وصفية ويتم تحديد الخيار حسابيًا. بعد ذلك ، يقوم CVM الذي جاء الطلب بمعالجته. في حالة القراءة ، يرسل البيانات إما من أحد مستويات ذاكرة التخزين المؤقت (ذاكرة الوصول العشوائي ، كتابة ذاكرة التخزين المؤقت ، قراءة ذاكرة التخزين المؤقت) أو من أقراص مضيفه. في حالة التسجيل ، تكتب إلى المجلة المحلية وتكرر العملية لـ CVM واحد (RF2) أو اثنين (RF3).



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

سؤال حول الاختبارات الاصطناعية



- الملاح والأجهزة المنزلية!
- 36!
- ما هو 36؟
- وماذا عن الأجهزة؟

شيء من هذا القبيل يبدو اليوم مثل معظم الاختبارات الاصطناعية لأنظمة التخزين. لماذا هذا؟

حتى وقت قريب نسبيا ، كانت معظم أنظمة التخزين مسطحة مع وصول موحد. ماذا يعني هذا؟

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

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

سؤال حول التحجيم


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

كما تعلمون ، بدون المعارف التقليدية واضحة - نتيجة HZ.



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


بمعنى آخر ، الوضع الكلاسيكي لـ GIGO - Garbage In Garbage Out - Garbage inlet = Garbage in the output.

يكاد يكون من الممكن أن يكون التحجيم العملي القابل للتطبيق للتقارب المفرط من نوعين: خذنا بهامش ، أو لفترة طويلة سنقود تجريبيًا ونأخذ مؤشرات.

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

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

وبعبارة أخرى ، حتى أكثر المهندسين المعماريين خبرة قبل البيع لن يخبرك بالمواصفات بشكل أكثر دقة من صياغة المتطلبات ، وبشكل أدق ، من "جيد ، في مكان ما SAM-VOSEM" بدون مشاريع تجريبية.



حول اللقطات


يمكن لـ HyperFlex إجراء لقطات أصلية للأجهزة الافتراضية باستخدام تقنية Redirect-on-Write. وهنا من الضروري التوقف بشكل منفصل للنظر في تقنيات مختلفة من اللقطات.
في البداية ، كانت هناك لقطات من نوع النسخ عند الكتابة (CoW) ؛ كمثال كلاسيكي ، يمكنك أخذ لقطات VMware vSphere الأصلية. مبدأ التشغيل ، مع vmdk عبر VMFS أو NFS ، مع أنظمة الملفات الأصلية مثل VSAN ، هو نفسه. بعد إنشاء لقطة CoW ، يتم تجميد البيانات الأصلية (كتل أو ملفات vmdk) ، وعندما تحاول الكتابة إلى كتل مجمدة ، يتم إنشاء نسخة ويتم كتابة البيانات إلى كتلة / ملف جديد (ملف دلتا لـ vmdk). ونتيجة لذلك ، مع نمو شجرة اللقطة ، يزداد عدد عمليات الوصول إلى القرص "الزائفة" التي لا تحمل أي معنى إنتاجي ، وينخفض ​​/ يتأخر الأداء .

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

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

وهنا يظهر تطبيق مثير للاهتمام من لقطات RoW - إسقاط RPO إلى قيم عشرات الدقائق. يكاد يكون من المستحيل إجراء نسخ احتياطية كل 30 دقيقة في الحالة العامة ، وفي معظم الحالات يتم إجراؤها مرة واحدة في اليوم ، مما يمنح RPO لمدة 24 ساعة. ولكن في الوقت نفسه ، يمكننا فقط عمل لقطات RoW وفقًا لجدول زمني ، وبذلك يصل الأمر بـ RPO إلى 15-30 دقيقة ، وتخزينها لمدة يوم أو يومين. لا عقوبة على الأداء ، والقدرة على الإنفاق فقط.

ولكن هناك بعض الفروق الدقيقة.

للتشغيل السليم للقطات الأصلية والتكامل مع VMware ، يتطلب HyperFlex لقطة رسمية تسمى Sentinel. يتم إنشاء لقطة الحارس تلقائيًا عند إنشاء لقطة لأول جهاز افتراضي معين من خلال HXConnect ، ولا يجب حذفها ، ولا يجب عليك "الرجوع" إليها ، ما عليك سوى طرح حقيقة أنه في الواجهة في قائمة اللقطات ، هذه هي أول لقطة خدمة في Sentinel.



يمكن تشغيل لقطات HyperFlex في وضع متوافق مع التعطل أو في وضع متوافق مع التطبيق. النوع الثاني يتضمن "مسح المخازن المؤقتة" داخل VM ، ويتطلب VMTools ، ويبدأ إذا تم تحديد خانة الاختيار "Quiesce" في قائمة لقطة HXConnect.
بالإضافة إلى لقطات HyperFlex ، لا أحد يمنع استخدام لقطات VMware "الأصلية". من المفيد لجهاز افتراضي معين تحديد اللقطات التي ستستخدمها ، وفي المستقبل للتركيز على هذه التقنية ، "عدم الإزعاج" لقطات مختلفة لـ VM واحد.

كجزء من الاختبار ، حاولت إنشاء لقطات والتحقق من معلومات FIO الخاصة بهم. ومع ذلك ، نعم ، يمكنني أن أؤكد أن اللقطات حقًا ، ولا تؤثر على الأداء. يتم إنشاء اللقطات بسرعة حقًا (بضع ثوان اعتمادًا على ملف تعريف التحميل وحجم مجموعة البيانات) ، يمكنني تقديم التوصية التالية استنادًا إلى النتائج: إذا كان التحميل الخاص بك يحتوي على الكثير من عمليات الكتابة العشوائية ، يجب أن تبدأ في إنشاء لقطة من واجهة HXConnect ، مع علامة الاختيار "Quiesce" ومع علامة اختيار أولية وجود لقطة خافرة.

الاختبارات


منصة الاختبار


سقطت المنصة التالية في الكفوف العنيدة:

  • 4 × C220 M4 (2630v4 10c x 2.20 جيجاهرتز ، 256 ، 800 + 6 * 960)
  • vSphere 6.7
  • HX Data Platform 4.0.2

اختبار التصحيح واضح


ما نوع الاختبار بدون CrystalDisk؟ هذا صحيح ، لا يمكن أن يكون هذا ، الرجال العاديون يبدأون دائمًا قرصًا بلوريًا! حسنًا ، إذا لزم الأمر ، فمن الضروري.



بالنسبة للقرص البلوري ، تم إنشاء VM تم إنشاؤه خصيصًا مع 2 vCPU 4GB و Windows 7 على اللوحة. أوه ، لقد سئمت من وضع التصحيحات عليه ، سأخبرك! تم إجراء الاختبار في أفضل تقاليد أفضل المنازل في لندن وباريس - أي تمت إضافة قرص افتراضي واحد فقط في النهاية التالية دون أي أفكار وتم إطلاق الاختبار. نعم ، وبالمناسبة ، بالطبع لا يشارك CrystalDiskMark نفسه في الاختبار ، فهو مجرد واجهة ، ولكنه يقوم بتحميل نظام القرص مباشرة مع حزمة DiskSpd المعروفة والمضمنة في المجموعة.



ما أذهلني حرفياً - لسبب ما ، تخطي جميعًا اختيار الوحدات في الزاوية اليمنى العليا. وكلها المرجع!



استمع بصراحة ، لم أكن أتوقع 75 ألف IOPS وأكثر من 1 غيغابايت في الثانية من الماكروماتين في وضع النهاية التالية!

بعبارة ملطفة ، ليس لدى كل شركة في روسيا أحمال تتجاوز هذه المؤشرات في المجموع.

تم إجراء المزيد من الاختبارات باستخدام VMware HCI Bench و Nutanix XRay ، باعتبارهما "عدائيين من الناحية الإيديولوجية" لـ HyperFlex ، وبالتالي كان من المتوقع ألا نأخذ سجناء. تبين أن الأرقام قريبة للغاية ، لذلك تم أخذ نتائج حزمة XRay كأساس لمجرد أنها تحتوي على نظام إبلاغ أكثر ملاءمة ونماذج تحميل جاهزة.

بالنسبة لأولئك الذين لا يثقون في أي شخص ويريدون السيطرة الكاملة على العملية ، أذكركم بمقالتي حول بناء نظامك الخاص لتوليد الحمل على منصة شديدة التقارب - "اختبار أداء أنظمة giperkonvergentnyh و SDS بأيديهم "

Achtung! Uwaga! Pozor!


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

علامة FourCorners Microbenchmark


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









الأرقام النهائية: 280 كيلوبايت / 174 ألفًا IOPS ، 3.77 / 1.72 غيغابايت في الثانية (قراءة / كتابة)

كيف تصرفت وحدات التحكم لدينا؟





يمكن من خلاله ملاحظة أن إجمالي استهلاك الموارد لـ 4 وحدات تحكم و 4 أحمال VM كان 49 نوى من 2.2. وفقًا لإحصاءات VMware ، كان استخدام وحدة التحكم في وحدات التحكم لوحدة المعالجة المركزية يصل إلى 80 ٪ ، أي في الواقع ، كان الأداء محدودًا بأداء وحدات التحكم ، وعلى وجه التحديد المعالجات. استندت سرعة العمليات المتسلسلة على وجه التحديد إلى سرعة شبكة 10G.

لنجرب مجددا. يبلغ الحد الأقصى للأداء على مجموعة صغيرة من 4 عقدة لا تحتوي على أسرع المعالجات بسرعة 2.2 جيجا هرتز ما يقرب من 300 ألف IOPS عند ارتفاع 4U.

المحادثة "هنا لدينا 10 أو 20 أو حتى 40٪ أكثر / أقل" عمليا لا معنى لها بسبب ترتيب الأرقام. نفس البدء في قياس "ويمكنني الحصول على سيارة 240 ، لدي 280" على الرغم من أن الحد الأقصى هو 80.

توفر عقد 280 كيلو / 4 أعلى أداء يبلغ 70 كيلو / عقدة ، والذي يتجاوز على سبيل المثال الأرقام من آلة حاسبة VMware VSAN ، والتي تعتبر أن عقدة AF لا تصدر أكثر من 46 كيلو لكل مجموعة قرص. في حالتنا ، هنا في مصطلحات VMware هناك مجموعة قرص واحدة فقط ، والتي تعمل فعليًا في x1.8.

تأثير حجم كتلة مخزن البيانات


عند إنشاء مخزن بيانات HyperFlex ، يمكنك اختيار حجم كتلة البيانات - 4 كيلو أو 8 كيلو.

ماذا سيؤثر؟ قم بإجراء نفس الاختبار رباعي الزوايا.





إذا كانت الصورة متطابقة تقريبًا مع القراءة ، فحينئذٍ يكون السجل في الأمور المعاكسة. يستخدم الاختبار رباعي الزوايا حمولة 8 كيلو.

العدد الإجمالي: 280 ألفًا / 280 ألفًا ، 172-158 ألفًا / 200-180 ألفًا (4K 8 ألفًا). عندما يتطابق حجم الكتلة ، يتم الحصول على + 15٪ من أداء الكتابة. إذا كنت تتوقع كمية كبيرة من التسجيل مع كتلة صغيرة (4 كيلو) في الحمل - قم بإنشاء مخزن بيانات لهذا الحمل المحدد مع كتلة 4 كيلو ، وإلا استخدم 8 كيلو.

محاكي OLTP


يتم إعطاء صورة أقرب إلى الواقع من خلال اختبار آخر. كجزء من ذلك ، تم إطلاق مولدين مع ملف تعريف قريب من DBMS للمعاملات ومستوى تحميل 6000 + 400 IOPS. هنا ، يتم قياس التأخير ، والذي يجب أن يبقى عند مستوى منخفض ثابت.









كان التأخير لتحميل VM 1.07 / 1.08 مللي ثانية. الكل في الكل نتيجة رائعة ، لكن دعنا نضيف بعض الحرارة!

قاعدة بيانات الموقع: كثافة عالية


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









لذا ، فإن قاعدة OLTP على العقدة 1 تولد 4200 IOPS بتأخير 0.85 مللي ثانية. ماذا يحدث بعد أن يبدأ نظام DSS فجأة في استهلاك الموارد في العمليات التسلسلية؟
يقوم مولدان على العقدين 2 و 3 بتحميل النظام الأساسي بسرعة 1.18 / 1.08 غيغابايت في الثانية ، على التوالي ، أي 2.26 غيغابايت في الثانية. من المؤكد أن التأخير في OLTP ينمو ويصبح أقل ثباتًا ، ولكن القيمة المتوسطة تبقى 1.85 مللي ثانية ، وتتلقى القاعدة 4200 IOPS دون أي مشاكل.

تأثير اللقطة






يأخذ النظام بالتتابع عدة لقطات مرة كل ساعة على قاعدة OLTP. لا يوجد شيء مفاجئ في الجدول الزمني ، علاوة على ذلك ، هذا عمومًا مؤشر على كيفية عمل اللقطات الكلاسيكية من VMware ، نظرًا لأن Nutanix XRay لا يعرف كيفية العمل مع اللقطات الأصلية باستثناء تلك الخاصة به. لا تحتاج إلى استخدام لقطات vSphere بشكل منتظم ، لأنه ليس كل الزبادي مفيدًا بنفس القدر.

تعمل اللقطات الأصلية من HyperFlex بشكل أفضل بكثير ، واستخدمها وسيصبح شعرك ناعمًا وحريريًا!

ابتلاع البيانات الضخمة


كيف سيقوم HyperFlex بهضم كمية كبيرة من البيانات التي يتم تحميلها بالتسلسل؟ دعونا نقول 1 تيرابايت.





استغرق الاختبار 27 دقيقة ، بما في ذلك الاستنساخ والضبط وبدء تشغيل المولدات.

قابلية التوسع



الآن ، قم بتحميل الكتلة بأكملها تدريجيًا وانظر إلى الأرقام الثابتة. لتبدأ بالقراءة العشوائية ثم الكتابة.











نحن نرى صورة مستقرة مع انخفاض تدريجي في أداء حمولة الماكينة من 78 كيلو إلى 55-57 ألف IOPS ، مع أرفف ناعمة. في الوقت نفسه ، هناك زيادة مطردة في الأداء العام من 78 إلى 220 ألف IOPS.











التسجيل أقل سلاسة ، ولكن لا تزال أرفف مستقرة من 64 كيلو إلى 19 إلى 21 ألف لكل سيارة. في نفس الوقت ، الحمل على وحدات التحكم أقل بكثير. إذا زاد مستوى تحميل المعالج الكلي من القراءة من 44 إلى 109 ، عند التسجيل من 57 إلى 73 جيجا هرتز.

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

كسر OLTP


وبحلول هذا الوقت ، أصبح الأمر مملاً حتى كيف كان HyperFlex الذي يمكن التنبؤ به. حاجة ملحة لكسر شيء!





تشير النقطة الحمراء إلى اللحظة التي يتم فيها إغلاق جهاز التحكم VM على أحد المضيفين بحمل.

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

login as: admin
 HyperFlex StorageController 4.0(2a)
admin@192.168.***.***'s password:
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 0
    rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance start -f
msgstr: Successfully started rebalance
params:
msgid: Successfully started rebalance
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 16
    rebalanceState: cluster_rebalance_ongoing
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b>



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

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

كسر لي تماما!


كسر - كسر. حمولة كاملة. في هذه الحالة ، أنشأت اختبارًا بملف شخصي يشبه إلى حد ما حملًا حقيقيًا (قراءة 70٪ ، 20٪ عشوائية ، 8 كيلو ، 6d 128q).



تخمين أين تم إيقاف تشغيل CVM ، وأين بدأت إعادة البناء؟



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

الموجودات


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

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

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

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

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

All Articles