🕺🏻 👨🏼‍💻 🏴󠁧󠁢󠁳󠁣󠁴󠁿 حول مجموعة خادم 1C 🚐 🐨 🌸

الكتلة هي نوع من
النظام المتوازي أو الموزع الذي:
1. يتكون من العديد من
أجهزة الكمبيوتر المترابطة ؛
2. يستخدم كمورد
كمبيوتر موحد

Gregory F. Pfister ، "بحثًا عن التكتلات".

معطى: هناك تطبيق تجاري (على سبيل المثال ، نظام تخطيط موارد المؤسسات) يعمل معه آلاف (ربما عشرات الآلاف) من المستخدمين في وقت واحد.

مطلوب:

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

لحل هذه المشاكل ، نستخدم بنية المجموعة في منصة 1C: Enterprise.

لم نصل على الفور إلى النتيجة المرجوة.

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

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

مجموعات التجميع (HA ، مجموعات عالية التوفر)
مجموعات موازنة التحميل (LBC)
مجموعات الحوسبة (مجموعات الحوسبة عالية الأداء ، HPC)
(grid) , . grid- , . grid- HPC-, .

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

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

1C: Enterprise 8.0

ظهر الإصدار الأول من خادم تطبيقات 1C (ليس مجموعة بعد) في إصدار النظام الأساسي 8.0. قبل ذلك ، عمل 1C في إصدار خادم العميل ، وتم تخزين البيانات في ملف DBMS أو MS SQL ، وكان منطق الأعمال يعمل حصريًا على العميل. في الإصدار 8.0 ، تم إجراء انتقال إلى البنية ثلاثية المستويات "العميل - خادم التطبيق - DBMS".

خادم 1C في النظام الأساسي 8.0 كان COM +خادم يمكنه تنفيذ كود التطبيق في 1C. قدم لنا استخدام COM + وسيلة نقل جاهزة ، مما سمح لتطبيقات العميل بالاتصال بالخادم عبر الشبكة. تم تصميم الكثير من الأشياء في بنية كل من التفاعل بين العميل والخادم وكائنات التطبيق المتاحة لمطور 1C مع مراعاة استخدام COM +. في ذلك الوقت ، لم يتم تضمين التسامح مع الخطأ في البنية ، وتسبب تعطل الخادم في إيقاف تشغيل جميع العملاء. عندما تعطل تطبيق الخادم ، قام COM + برفعه عند وصول العميل الأول إليه ، وبدأ العملاء في عملهم من البداية - من الاتصال بالخادم. في ذلك الوقت ، تمت خدمة جميع العملاء بعملية واحدة.

1C: Enterprise 8.1

في الإصدار التالي ، أردنا:

توفير التسامح مع الأخطاء لعملائنا بحيث لا تؤدي حوادث وأخطاء بعض المستخدمين إلى حوادث وأخطاء مستخدمين آخرين.
تخلص من تقنية COM +. عمل COM + فقط على Windows ، وفي ذلك الوقت أصبحت إمكانية العمل مع Linux ذات صلة بالفعل.

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

لذلك في الإصدار 8.1 ظهرت المجموعة الأولى. قمنا بتطبيق بروتوكولنا لاستدعاء الإجراء عن بعد (في أعلى TCP) ، والذي يبدو في الظاهر مثل COM + تقريبًا للعميل النهائي للعميل (أي أننا لم نضطر عمليًا إلى إعادة كتابة الرمز المسؤول عن مكالمات العميل-الخادم). في الوقت نفسه ، جعلنا الخادم الذي تم تنفيذه في منصة C ++ مستقلاً ، وقادرًا على العمل على كل من Windows و Linux.

تم استبدال إصدار الخادم الأحادي الإصدار 8.0 بثلاثة أنواع من العمليات - عملية عمل تخدم العملاء ، وعمليتا خدمة تدعمان تشغيل المجموعة:

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

تحت القطع هو مخطط العملية لهذه العمليات الثلاث في الكتلة.

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

1C: Enterprise 8.2

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

قدم هذا الإصدار أيضًا العديد من الابتكارات المهمة - تحسين تحمل الخطأ ، وموازنة الحمل ، وآلية التكرار العنقودي.

التسامح مع الخطأ

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

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

توزيع الحمل

إن مهمة موازنة الحمل في حالتنا هي كما يلي: يدخل عميل جديد إلى النظام (أو يقوم عميل يعمل بالفعل بإجراء مكالمة أخرى). نحتاج إلى اختيار الخادم وسير العمل لإرسال مكالمة العميل إليه لتزويد العميل بأقصى سرعة.

هذه مهمة قياسية لكتلة متوازنة. هناك العديد من الخوارزميات النموذجية لحلها ، على سبيل المثال:

Round-Robin () – , , – . . . . , «» . ( ) .
Weighted Round Robin – Round-Robin: , ́ .
Least Connections: , .
Least Response Time: : , .

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

يتم توجيه الطلب من العميل الجديد إلى الخادم الأكثر إنتاجية في الوقت الحالي.

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

يتم نقل طلب من عميل موجود إلى سير عمل آخر في حالتين:

لم تعد هناك عملية: لم يعد سير العمل الذي تفاعل معه العميل متاحًا (سقطت العملية ، وأصبح الخادم غير متاح ، وما إلى ذلك).
: , , , , . , , – . – (.. ).

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

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

1C: Enterprise 8.3

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

« »: , , . , «» .
, , .
, , , , , :

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

ثلاث روابط للتسامح مع الخطأ

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

, HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
, .
- . 1, - . - . , . , – . - (, , , ) – .
, rmngr. 20 ( ) — , .. . 1: .

بفضل آلية التسامح مع الأخطاء ، نجحت التطبيقات التي تم إنشاؤها على 1C: النظام الأساسي للمؤسسات في النجاة من أنواع مختلفة من إخفاقات خوادم الإنتاج في المجموعة ، بينما استمر معظم العملاء في العمل دون إعادة التشغيل.

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

زادت موثوقية مجموعة خادم 1C في الإصدار 8.3 بشكل ملحوظ. لم يكن من غير المألوف منذ فترة طويلة تقديم منتجات 1C ، حيث يصل عدد المستخدمين العاملين في وقت واحد إلى عدة آلاف. هناك تطبيقات حيث يعمل كل من 5000 و 10000 مستخدم في وقت واحد - على سبيل المثال ، المقدمة في Beeline ، حيث يخدم تطبيق 1C: إدارة التجارة جميع منافذ مبيعات Beeline في روسيا ، أو تنفيذ خطوط الأعمال في شركة الشحن ، حيث يخدم التطبيق ، الذي تم إنشاؤه بشكل مستقل من قبل مطوري قسم تكنولوجيا المعلومات في Business Lines على منصة 1C: Enterprise ، الدورة الكاملة لنقل البضائع. تحاكي اختبارات تحميل الكتلة الداخلية لدينا التشغيل المتزامن لما يصل إلى 20000 مستخدم.

في الختام ، أود أن أذكر بإيجاز ما هو آخر مفيد في مجموعتنا (القائمة غير مكتملة):

, . , , .
– , , , ( – , ..) . , , (, ) , ERP, , ERP.
– , (, , ..). , , , , , .

حول مجموعة خادم 1C