في الآونة الأخيرة ، قام VTB بتغيير بعض مكونات الأجهزة والبرامج لنظام سير العمل. كانت التغييرات مهمة للغاية بحيث لا تتمكن من مواصلة العمل دون إجراء اختبار شامل للحمل: أي مشكلة في نظام دعم المستندات (LMS) محفوفة بخسائر هائلة.
قام خبراء Intertrust باختبار VTB SDO على معدات Huawei - وهي مجموعة من مزرعة الخوادم وشبكة البيانات والتخزين استنادًا إلى محركات الأقراص ذات الحالة الصلبة. للاختبارات ، أنشأنا بيئة استنسخت سيناريوهات حقيقية بأقصى قدر ممكن من الحمل. النتائج والاستنتاجات - تحت الخفض.
لماذا نحتاج إلى نظام سير عمل في أحد البنوك ولماذا نختبره
LMS in VTB عبارة عن حزمة برامج معقدة ، ترتبط بها جميع عمليات الإدارة الرئيسية. يوفر النظام خدمات التوثيق العامة والتفاعل الإلكتروني والتحليلات. إن تعميم الوثائق جيد التنظيم يسرع من اتخاذ القرارات الإدارية ، ويجعل إجراءات تبنيها شفافة ومراقبة ، ويحسن من جودة الإدارة ويعزز القدرة التنافسية للبنك.
يجب أن تضمن LMS التنفيذ الواضح للقرارات وفقًا للوائح المعمول بها. وهذا يتطلب الأداء العالي ، والتسامح مع الخطأ ، والتحجيم مرنة. يحتوي النظام على متطلبات عالية للتحكم في الوصول ، وحجم المستندات التي تتم معالجتها في وقت واحد ، وعدد المستخدمين. الآن هناك 65 ألف منهم في VTB SDO ، وهذا الرقم مستمر في النمو.
يتطور النظام باستمرار: الهندسة المعمارية تتغير ، يتم استبدال التقنيات القديمة بالتقنيات الحديثة. ومؤخراً ، تم استبدال بعض مكونات النظام بمكونات مستقلة عن الاستيراد ، بدون برامج خاصة. هل ستتعامل بنية SDO الجديدة القائمة على برنامج CompanyMedia ومجمّع أجهزة Huawei مع زيادة الحمل؟ الإجابة بشكل لا لبس فيه على هذا السؤال ، دون انتظار موقف مماثل في الواقع ، كان ذلك ممكنا فقط بمساعدة اختبار الإجهاد.
بالإضافة إلى اختبار منتج البرنامج الجديد لمقاومة الإجهاد ، كان لدينا المهام التالية:
- تحديد المعلمات الدقيقة للتحجيم الأفقي والرأسي للخوادم لملف تعريف حمل البنك ؛
- تحقق مكونات التسامح مع الخطأ في ظل ظروف تحميل عالية ؛
- لتحديد معامل الانتروبيا للتفاعل المتداخل مع القياس الأفقي ؛
- حاول تغيير حجم قراءة الطلبات عند استخدام موازن النظام الأساسي ؛
- تحديد عامل التحجيم الأفقي لجميع العقد ومكونات النظام ؛
- تحديد الحد الأقصى لمعلمات الأجهزة الممكنة للخوادم لأغراض وظيفية مختلفة (القياس الرأسي) ؛
- لدراسة ملف تعريف تحميل التطبيق على البنية التحتية التقنية ، لتقريب النتائج للتخطيط لتطوير نظام المعلومات ؛
- تحقق من تأثير دمج بيانات التطبيق على نظام تخزين بيانات واحد على تحسين الموارد ، وتحسين الموثوقية والأداء.
المنهجية والمعدات
غالبًا ما يتم إجراء اختبار تحميل أنظمة إدارة المستندات الإلكترونية وفقًا لسيناريوهات مبسطة. إنها تحاكي الاكتشاف السريع وفتح بطاقات المستندات غير المرتبطة بالملفات الأخرى وليس لها تاريخ دورة حياة. في هذه الحالة ، كقاعدة عامة ، لا يأخذ أي شخص في الاعتبار حقوق الوصول والعوامل الأخرى المستهلكة للموارد المميزة للظروف الحقيقية.
في كثير من الأحيان ، يتم إجراء هذه الاختبارات المطلقة بواسطة موفري الحلول. إنه أمر مفهوم: من المهم أن يوضح البائع أداءً محتملاً عاليًا وسرعة للنظام. ليس من المستغرب أن تعرض نماذج الاختبار المبسطة أوقات استجابة لنظام السجلات ، حتى إذا زاد عدد المستخدمين والمستندات بشكل ملحوظ.
نحن بحاجة إلى إعادة إنتاج ظروف التشغيل الفعلية. لذلك ، في البداية ، قمنا بجمع إحصائيات لمدة شهر: سجلنا نشاط المستخدم ، وشاهدنا عمل الخلفية لجميع الخدمات. أصبحت أنظمة المراقبة المدمجة في LMS مساعدة كبيرة في هذا الصدد. ساعد موظفو البنك في تصحيح البيانات الناتجة عن تدفقات المستندات ، بينما قمنا بإجراء تعديلات على النمو المتوقع في التدفقات.
وكانت النتيجة منهجية للاختبار ، بمساعدة كان من الممكن محاكاة العمليات التي تحدث في النظام ، مع مراعاة جميع الأحمال الحقيقية. في منصة الاختبار ، قمنا بإعادة إنتاج - بشكل فردي وفي مجموعات مختلفة - العمليات التجارية الأكثر شيوعًا ، وكذلك الطلبات الأكثر استهلاكا للوقت. أثناء اختبار الأداء ، تعرضت جميع المكونات للتوتر. تم تنفيذ العمليات لحساب حقوق وصول المستخدم إلى كائنات النظام ، وفتح المستندات ذات تسلسل هرمي متفرع معقد وعدد كبير من الروابط ، والبحث في النظام ، وما إلى ذلك.
تحميل اختبار الملف الشخصي:
- المستخدمون المسجلون: 65 ألف بزيادة تصل إلى 150 ألف ؛
- عدد مرات تسجيل دخول المستخدم (المصادقة): 50 ألف في الساعة ؛
- المستخدمين الذين يعملون في وقت واحد في النظام: 10 ألف ؛
- الوثائق المسجلة: 10 مليون في السنة ؛
- حجم مرفقات الملفات: 1 تيرابايت في السنة ؛
- عمليات الموافقة على المستندات: 1.5 مليون في السنة ؛
- تأشيرات أطراف الاتفاقية: 7.5 مليون دولار في السنة ؛
- القرارات والتعليمات: 15 مليون في السنة ؛
- تقارير عن القرارات والتعليمات: 15 مليون في السنة ؛
- مهام المستخدم: 18 مليون دولار في السنة.
تم دمج هذه التطبيقات على نظام تخزين واحد Huawei OceanStor Dorado 6000 V3 مع 117 محرك أقراص SSD بسعة 3.6 تيرابايت لكل منهما ، ويبلغ إجمالي حجم الاستخدام أكثر من 300 تيرابايت. وضعت قوة الحوسبة على نظام الخادم المعياري من Huawei E9000 ، وتم نقل البيانات عبر الشبكة بناءً على مفاتيح مستوى مركز البيانات في سلسلة Huawei CE. خلال الاختبار ، لاحظنا على مدار الساعة جميع مؤشرات النظام. تم تسجيل جميع النتائج ، بما في ذلك البيانات التاريخية ، في شكل رسوم بيانية وجداول للتحليل اللاحق.
تحميل اختبار الأجهزة خوادم البنية التحتية
نظرًا للأداء العالي لنظام تخزين Huawei OceanStor Dorado 6000 V3 ، فإن التأخير عند تنفيذ أي طلبات مستخدم نادراً ما يتجاوز 1 مللي ثانية. ألهمتنا سرعة النظام الفرعي للقرص الخاص بالتطبيق لإجراء مزيد من البحث. قررنا ، من خلال تحليل البيانات التاريخية ، تحديد تأثير أنواع مختلفة من أعباء العمل على البنية التحتية التقنية. تسمح لنا النتائج التي تم الحصول عليها بالتخطيط المرن والدقة لتطوير النظام وفقًا لمتطلبات النظام الأساسي للأجهزة.
من حيث التحجيم ، فحصنا:
- حد التوسع الرأسي لخادم التطبيق (CMJ) ، موارد الأهمية الحرجة: عدد النوى والتردد ، مقدار ذاكرة الوصول العشوائي ؛
- دعم القياس الأفقي لخادم التطبيق (CMJ) من خلال تكرار خدمات متطابقة وظيفيا والتوازن بينهما ؛
- حدود التوسع الرأسي والأفقي لخادم العميل (Web-GUI) ؛
- حدود التوسع الرأسي لتخزين الملفات (FS) ، موارد الأهمية الحيوية: عرض النطاق الترددي للشبكة ، سرعة القرص ؛
- دعم القياس الأفقي لتخزين الملفات (FS) بسبب نظام الملفات الموزعة - CEPH ، GLUSTERFS ؛
- حدود التوسع الرأسي لقاعدة البيانات (PostgreSQL) ، والموارد وفقًا لدرجة الأهمية: سعة ذاكرة الوصول العشوائي ، وسرعة القرص ، وعدد النوى والتردد ؛
- دعم توسيع نطاق قاعدة البيانات الأفقية (PostgreSQL) : زيادة حجم القراءة على خوادم الرقيق ، وتوسيع نطاق عبء الكتابة على مبدأ التقسيم إلى وحدات وظيفية ؛
- حدود التوسع الرأسي والأفقي لسمسار الرسائل (Apache Artemis) ؛
- حدود التوسع الرأسي والأفقي لخادم البحث (Apache Solr) .
المشاكل والحلول
كانت إحدى المهام الرئيسية تحديد المشكلات المحتملة في أداء نظام إدارة التعلم (LMS). أثناء العمل ، تم تحديد الاختناقات التالية وتم العثور على طرق لمعالجتها.
أقفال تسجيل متزامن. يتم إجراء عمليات التسجيل في تكوين WildFly القياسي بشكل متزامن ويؤثر بشكل كبير على الأداء. تقرر التبديل إلى مسجل غير متزامن ، وفي نفس الوقت لا تكتب إلى قرص ، ولكن إلى نظام تجميع سجل ELK.
تهيئة الجلسات غير الضرورية عند العمل مع مستودع بيانات. تهيئة كل مؤشر ترابط الذي تلقى البيانات من المخزون مرتين جلسة للمصادقة في وضع SSO. هذه العملية كثيفة الاستخدام للموارد وتزيد بشكل كبير من وقت تنفيذ طلب المستخدم ، كما تقلل من الإنتاجية الإجمالية للخادم.
أقفال عند العمل مع كائنات ذاكرة التخزين المؤقت للتطبيق. استخدم التطبيق أقفال reentrantLock الثقيلة (Java 7) ، مما أثر سلبًا على سرعة تنفيذ الاستعلام. تم تغيير نوع القفل إلى stampedLock ، مما أدى إلى تقليل الوقت المستغرق في العمل مع كائنات ذاكرة التخزين المؤقت بشكل ملحوظ.
بعد ذلك ، أطلقنا مرة أخرى اختبار الحمل لتحديد متوسط وقت العمليات النموذجية في نظام LMS مع تخزين علائقي في ملف تعريف البنك. حصلنا على النتائج التالية:
- إذن المستخدم في النظام - 400 مللي ثانية ؛
- عرض التقدم في المتوسط - 2.5 ثانية ؛
- إنشاء بطاقة تسجيل ومراقبة - 1.4 ثانية ؛
- تسجيل ومراقبة بطاقة التسجيل - 600 مللي ثانية ؛
- إنشاء قرار - 1 ص.
النتائج
بالإضافة إلى تحديد المشكلات ، أكد اختبار الإجهاد بعض افتراضاتنا.
- يعمل النظام بشكل أفضل على عائلة نظام التشغيل Linux.
- تعمل المبادئ المعلنة لضمان التسامح مع الخطأ على مستوى كل مكون في وضع "ساخن".
- يحتوي المكون الأساسي - خدمة منطق الأعمال (قبول طلبات المستخدم) - على قياس أفقي "متطابق" وقياس خطي تقريبي للإنتاجية مع زيادة في عدد الحالات.
- التحجيم الأمثل لخدمة منطق الأعمال لـ 1200 مستخدم في وقت واحد - 8 وحدات تحكم في وحدة الخدمة للخدمة و 1.5 وحدة تحكم في وحدة التحكم في إدارة قواعد البيانات.
- دمج بيانات التطبيق على نظام تخزين واحد يزيد بشكل كبير من الإنتاجية والموثوقية ، ويزيد من قابلية التوسع.
سنكون سعداء بالإجابة على أسئلتك في التعليقات - ربما تكون مهتمًا بمعرفة المزيد عن بعض جوانب الاختبار.