مرحبا ، خابروفشان! ما زلنا على اطلاعك على نظام AERODISK vAIR الروسي المفرط التحمل. سوف تركز هذه المقالة على بنية هذا النظام. في المقالة الأخيرة ، قمنا بتحليل نظام ملفات ARDFS الخاص بنا ، وسنتناول في هذه المقالة جميع مكونات البرامج الرئيسية التي تشكل vAIR ومهامها.
نبدأ في وصف البنية من الأسفل إلى الأعلى - من التخزين إلى الإدارة.
ARDFS + الطوافة نظام ملفات برنامج تشغيل الكتلة
أساس vAIR هو نظام الملفات الموزع ARDFS ، الذي يجمع بين الأقراص المحلية لجميع عقد الكتلة في تجمع منطقي واحد ، على أساسه يتم إنشاء أقراص افتراضية مع واحد أو آخر نظام التسامح مع الخطأ (عامل النسخ المتماثل أو ترميز المحو) من كتل افتراضية 4 ميجابايت. ويرد وصف أكثر تفصيلا لعمل ARDFS في المادة السابقة.
Raft Cluster Driver هي خدمة ARDFS داخلية تعمل على حل مشكلة التخزين الموزع والموثوق للبيانات التعريفية لنظام الملفات.
البيانات الوصفية ARDFS تنقسم تقليديًا إلى فئتين.
- الإخطارات - معلومات حول العمليات مع كائنات التخزين ومعلومات حول الكائنات نفسها ؛
- معلومات الخدمة - إعداد الأقفال ومعلومات التكوين لعقد التخزين.
يتم استخدام خدمة RCD لتوزيع هذه البيانات. تقوم تلقائيًا بتعيين عقدة مع دور القائد الذي تتمثل مهمته في الحصول على البيانات التعريفية ونشرها عبر العقد. القائد هو المصدر الحقيقي الوحيد لهذه المعلومات. بالإضافة إلى ذلك ، يقوم القائد بتنظيم نبضات قلبية ، أي يتحقق من توفر جميع عقد التخزين (لا علاقة لذلك بتوفر الأجهزة الظاهرية ، RCD هي مجرد خدمة للتخزين).
إذا أصبح القائد غير متاح لأي سبب من الأسباب لأي من العقد العادية لأكثر من ثانية واحدة ، فإن هذه العقدة العادية تنظم إعادة انتخاب القائد ، وتطلب إتاحة القائد من العقد العادية الأخرى. إذا كان هناك النصاب القانوني ، يتم إعادة انتخاب القائد. بعد "استيقظ" الزعيم السابق ، يصبح تلقائيًا عقدة عادية ، لأنه القائد الجديد يرسل له الفريق المناسب.
منطق التجمع الكونغولي من أجل الديمقراطية ليس بالأمر الجديد. يسترشد هذا المنطق أيضًا بالعديد من الحلول الخارجية والتجارية والحلول المجانية ، لكن هذه الحلول لا تناسبنا (مثل FS مفتوحة المصدر الحالية) ، لأنها ثقيلة للغاية ، ومن الصعب للغاية تحسينها لمهامنا البسيطة ، لذلك كتبنا للتو خدمة التجمع الدستوري الديمقراطي.
قد يبدو أن الزعيم هو "رقبة ضيقة" يمكنها أن تبطئ العمل في مجموعات كبيرة بمئات العقد ، لكن هذا ليس كذلك. تحدث العملية الموصوفة على الفور تقريبًا و "تزن" القليل جدًا لأننا كتبناها بأنفسنا وشملنا أكثر الوظائف الضرورية. بالإضافة إلى ذلك ، يحدث ذلك تلقائيًا تمامًا ، مع ترك الرسائل فقط في السجلات.
MasterIO - خدمة إدارة I / O متعددة مؤشرات الترابط
بمجرد تنظيم تجمع ARDFS مع الأقراص الافتراضية ، يمكن استخدامه للإدخال / الإخراج. في هذه المرحلة ، يطرح السؤال على وجه التحديد للأنظمة شديدة الارتباط ، وهي: ما مقدار موارد النظام (CPU / RAM) التي يمكننا التبرع بها من أجل IO؟
في أنظمة التخزين الكلاسيكية ، ليس هذا السؤال حادًا ، لأن مهمة التخزين هي فقط لتخزين البيانات (ومعظم موارد تخزين النظام يمكن توفيرها بأمان تحت IO) ، ومهام التقارب المفرط ، بالإضافة إلى التخزين ، تشمل أيضًا تنفيذ الأجهزة الظاهرية. وفقًا لذلك ، يتطلب GCS استخدام موارد وحدة المعالجة المركزية وذاكرة الوصول العشوائي بشكل أساسي للأجهزة الافتراضية. حسنا ، ماذا عن I / O؟
لحل هذه المشكلة ، تستخدم vAIR خدمة إدارة I / O: MasterIO. مهمة الخدمة بسيطة - "خذ كل شيء وشارك" إنه مضمون لالتقاط العدد التاسع من موارد النظام للإدخال والإخراج ، وبدءًا منها ، ابدأ العدد التاسع من تدفقات الإدخال / الإخراج.
في البداية ، أردنا توفير آلية "ذكية جدًا" لتخصيص الموارد لإدخال / إخراج. على سبيل المثال ، إذا لم يكن هناك حمل على وحدة التخزين ، فيمكن استخدام موارد النظام للأجهزة الافتراضية ، وإذا ظهر الحمل ، تتم إزالة هذه الموارد "بهدوء" من الأجهزة الافتراضية ضمن حدود محددة مسبقًا. لكن هذه المحاولة انتهت بفشل جزئي. أوضحت الاختبارات أنه إذا تم زيادة الحمل تدريجيًا ، فكل شيء على ما يرام ، يتم سحب الموارد (المحددة للإزالة المحتملة) تدريجياً من VM لصالح I / O. لكن الاندفاع الحاد في أحمال التخزين يثير سحبًا غير "سهل" للموارد من الأجهزة الظاهرية ، ونتيجة لذلك ، تتراكم قوائم الانتظار على المعالجات ، ونتيجة لذلك ، والذئاب جائعة والخراف ميتة و virtualka شنق ، وليس هناك IOPS.
ربما سنعود في المستقبل إلى هذه المشكلة ، لكن في الوقت الحالي ، قمنا بتنفيذ إصدار الموارد من أجل IO بطريقة الجد القديم.
استنادًا إلى بيانات تغيير الحجم ، يقوم المسؤول مسبقًا بتخصيص الرقم الأساسي لوحدات CPU وذاكرة الوصول العشوائي لخدمة MasterIO. يتم تخصيص هذه الموارد الاحتكار ، أي لا يمكن استخدامها بأي طريقة لتلبية احتياجات VM حتى يسمح المسؤول بذلك. يتم تخصيص الموارد بالتساوي ، أي يتم أخذ نفس مقدار موارد النظام من كل عقدة من الكتلة. بادئ ذي بدء ، تعتبر موارد المعالج موضع اهتمام MasterIO (ذاكرة الوصول العشوائي أقل أهمية) ، خاصةً إذا استخدمنا ترميز Erasure.
إذا حدث خطأ في التحجيم ، وقمنا بإعطاء MasterIO الكثير من الموارد ، فسيتم حل الموقف بسهولة عن طريق إزالة هذه الموارد مرة أخرى إلى تجمع موارد VM. إذا كانت الموارد في وضع الخمول ، فستعود على الفور إلى تجمع موارد VM ، ولكن إذا تم التخلص من هذه الموارد ، فسيتعين عليك الانتظار بعض الوقت حتى يقوم MasterIO بإصدارها بسهولة.
الوضع العكسي هو أكثر تعقيدا. إذا احتجنا إلى زيادة عدد النوى في MasterIO ، وكانت مشغولة بالظاهريات الافتراضية ، فعلينا "التفاوض" مع الصور الافتراضية ، أي تحديدها باستخدام المقابض ، لأنه في الوضع التلقائي في حالة انفجار حاد ، تكون هذه العملية محفوفة بتجميد VM وغيره من السلوك المتقلبة.
وفقًا لذلك ، يجب إيلاء الكثير من الاهتمام لتغيير حجم أداء أنظمة الإدخال والإخراج الفائق (وليس فقط نظامنا). بعد فترة وجيزة في أحد المقالات ، نعدك بالنظر في هذه المسألة بمزيد من التفصيل.
هبرفيسر
Hypervisor Aist مسؤول عن تشغيل الأجهزة الافتراضية في vAIR. ويستند هذا المشرف على المشرف KVM اختبارها الزمن. من حيث المبدأ ، لقد كتب الكثير عن أعمال KVM ، لذلك ليست هناك حاجة خاصة لطلائها ، فقط قم بالإشارة إلى أن جميع الوظائف القياسية لـ KVM مخزنة في Stork وتعمل بشكل جيد.
لذلك ، سنقوم هنا بوصف الاختلافات الرئيسية عن KVM القياسية ، والتي قمنا بتطبيقها في ستورك. اللقلق هو جزء من النظام (برنامج Hypervisor المثبت مسبقًا) ويتم التحكم فيه من وحدة التحكم المشتركة vAIR عبر Web-GUI (الإصدارات الروسية والإنجليزية) و SSH (من الواضح ، الإنجليزية فقط).
بالإضافة إلى ذلك ، يتم تخزين تكوينات برنامج Hypervisor في قاعدة بيانات ConfigDB الموزعة (حولها لاحقًا) ، والتي تعد أيضًا نقطة تحكم واحدة. أي ، يمكنك الاتصال بأي عقدة في الكتلة وإدارة كل شيء دون الحاجة إلى خادم إدارة منفصل.
إضافة هامة إلى وظيفة KVM القياسية هي وحدة HA التي طورناها. هذا هو أبسط تطبيق لمجموعة من الأجهزة الظاهرية عالية التوفر ، والتي تسمح لك بإعادة تشغيل الجهاز الظاهري تلقائيًا على عقدة كتلة أخرى في حالة فشل العقدة.
ميزة أخرى مفيدة هي النشر الشامل للأجهزة الافتراضية (ذات الصلة ببيئات VDI) ، والتي ستعمل تلقائيًا على نشر الأجهزة الافتراضية مع توزيعها التلقائي بين العقد اعتمادًا على الحمل عليها.
توزيع VM بين العقد هو الأساس لموازنة التحميل التلقائي (علاء DRS). هذه الوظيفة غير متوفرة بعد في الإصدار الحالي ، لكننا نعمل بنشاط على ذلك وستظهر بالتأكيد في أحد التحديثات التالية.
يتم دعم برنامج Hypervisor VMware ESXi اختياريًا ، ويتم تنفيذه حاليًا باستخدام بروتوكول iSCSI ، كما يتم تخطيط دعم NFS في المستقبل.
مفاتيح افتراضية
لتنفيذ برامج التبديل ، يتم توفير مكون منفصل - كسورية. كما هو الحال في المكونات الأخرى لدينا ، ننتقل من البسيط إلى المعقد ، لذلك في الإصدار الأول ، يتم تنفيذ التبديل البسيط ، في حين يتم إعطاء التوجيه وجدار الحماية لأجهزة خارجية. مبدأ العملية هو المعيار. يتم توصيل الواجهة الفعلية للملقم بواسطة جسر إلى كائن Fractal - مجموعة من المنافذ. مجموعة من المنافذ ، بدورها ، مع الأجهزة الافتراضية المطلوبة في الكتلة. يتم دعم تنظيم شبكات VLAN ، وسيتم إضافة دعم VxLAN في أحد الإصدارات التالية. يتم توزيع جميع رموز التبديل التي تم إنشاؤها افتراضيًا ، أي يتم توزيعها على جميع عقد نظام المجموعة ، وبالتالي فإن الأجهزة الافتراضية التي تقوم بالتبديل للاتصال بـ VM لا تعتمد على عقدة الموقع ، فهذا أمر يتعلق بقرار المسؤول فقط.
الرصد والإحصاء
المكون المسؤول عن المراقبة والإحصاء (عنوان العمل مونيكا) هو ، في الواقع ، استنساخ أعيد تصميمه من نظام تخزين المحرك. في وقت واحد ، أوصى بنفسه بشكل جيد وقررنا استخدامه مع vAIR مع ضبط سهل. مثل جميع المكونات الأخرى ، يتم تنفيذ مونيكا وتخزينها على جميع عقد الكتلة في نفس الوقت.
يمكن تحديد مسؤوليات مونيكا الصعبة على النحو التالي:
جمع البيانات:
- من أجهزة استشعار الأجهزة (التي يمكن أن تعطي الحديد أكثر من IPMI) ؛
- من كائنات منطقية vAIR (ARDFS ، ستورك ، فركتل ، ماسترو وغيرها من الكائنات).
جمع البيانات في قاعدة بيانات موزعة ؛
تفسير البيانات في شكل:
التفاعل الخارجي مع أنظمة الجهات الخارجية عن طريق بروتوكولات SMTP (إرسال تنبيهات البريد الإلكتروني) و SNMP (التفاعل مع أنظمة مراقبة الجهات الخارجية).
قاعدة التكوين الموزعة
في الفقرات السابقة ، تم ذكر أنه يتم تخزين العديد من البيانات على جميع عقد الكتلة في نفس الوقت. لتنظيم طريقة التخزين هذه ، يتم توفير قاعدة بيانات ConfigDB موزعة خاصة. كما يوحي الاسم ، تقوم قاعدة البيانات بتخزين تكوينات كافة كائنات الكتلة: برنامج Hypervisor والأجهزة الظاهرية ووحدة HA والمفاتيح ونظام الملفات (يجب عدم الخلط بينه وبين قاعدة بيانات بيانات تعريف FS ، هذه قاعدة بيانات أخرى) ، بالإضافة إلى الإحصائيات. يتم تخزين هذه البيانات بشكل متزامن على جميع العقد وتناسق هذه البيانات هو شرط أساسي لعملية مستقرة من vAIR.
نقطة مهمة: على الرغم من أن تشغيل ConfigDB أمر حيوي لتشغيل vAIR ، إلا أن فشله ، على الرغم من أنه سيوقف الكتلة ، لا يؤثر على اتساق البيانات المخزنة في ARDFS ، والذي يعتبر في نظرنا إضافة إلى موثوقية الحل ككل.
يعد ConfigDB أيضًا نقطة إدارة واحدة ، بحيث يمكنك الانتقال إلى أي عقدة من الكتلة عن طريق عنوان IP وإدارة جميع العقد الخاصة بالكتلة بشكل كامل وهو أمر مناسب تمامًا.
بالإضافة إلى ذلك ، للوصول إلى الأنظمة الخارجية ، يوفر ConfigDB واجهة برمجة تطبيقات مريحة من خلالها يمكنك تكوين التكامل مع أنظمة الجهات الخارجية. على سبيل المثال ، لقد توصلنا مؤخرًا إلى تكامل تجريبي مع العديد من الحلول الروسية في مجالات VDI وأمن المعلومات. عند اكتمال المشاريع ، سنكون سعداء بكتابة التفاصيل الفنية هنا.
الصورة كاملة
نتيجة لذلك ، لدينا نسختان من بنية النظام.
في الحالة الأولى - يتم استخدام برنامج Hypervisor Aist القائم على KVM ومفاتيح برمجية Fractal.
السيناريو 1. صحيح
في الخيار الثاني - اختياري - عندما تريد استخدام برنامج ESXi hypervisor ، يكون المخطط معقدًا إلى حد ما. لاستخدام ESXi ، يجب تثبيته بالطريقة القياسية على محركات الأقراص المحلية من الكتلة. بعد ذلك ، على كل عقدة ESXi ، يتم تثبيت الجهاز الظاهري vAIR MasterVM ، والذي يحتوي على توزيع vAIR خاص لتشغيله كجهاز ظاهري لبرنامج VMware.
يوفر ESXi جميع الأقراص المحلية المجانية عن طريق إعادة التوجيه المباشر إلى MasterVM. داخل MasterVM ، يتم بالفعل تنسيق هذه الأقراص بشكل قياسي في ARDFS وتسليمها إلى الخارج (أو بالأحرى ، العودة إلى ESXi) باستخدام بروتوكول iSCSI (وفي المستقبل سيكون هناك NFS) من خلال واجهات مخصصة في ESXi. وفقًا لذلك ، يتم توفير الأجهزة الافتراضية وشبكة البرامج في هذه الحالة بواسطة ESXi.
السيناريو 2. ESXi
لذلك ، قمنا بتفكيك جميع المكونات الرئيسية للهيكل vAIR ومهامها. في المقالة التالية سنتحدث عن الوظائف والخطط المطبقة بالفعل في المستقبل القريب.
نحن في انتظار التعليقات والاقتراحات.