أثناء عملك في مجال تكنولوجيا المعلومات، تبدأ في ملاحظة أن الأنظمة لها طابعها الخاص. يمكن أن تكون مرنة وصامتة وغريبة الأطوار وصارمة. يمكنهم جذب أو صد. بشكل أو بآخر، عليك «التفاوض» معهم، والمناورة بين «المزالق» وبناء سلاسل تفاعلهم.
لذلك كان لنا شرف بناء منصة سحابية، ولهذا كنا بحاجة إلى "إقناع" نظامين فرعيين للعمل معنا. لحسن الحظ، لدينا "لغة API"، وأيدي مباشرة والكثير من الحماس.
لن تكون هذه المقالة متطرفة من الناحية الفنية، ولكنها ستصف المشكلات التي واجهناها أثناء بناء السحابة. قررت أن أصف طريقنا في شكل خيال تقني خفيف حول كيفية بحثنا عن لغة مشتركة مع الأنظمة وما نتج عنها.
مرحبا بكم في القط.
بداية رحلة
منذ بعض الوقت، تم تكليف فريقنا بإطلاق منصة سحابية لعملائنا. كان لدينا دعم إداري، وموارد، ومجموعة أجهزة، وحرية في اختيار التقنيات اللازمة لتنفيذ الجزء البرمجي من الخدمة.
وكان هناك أيضًا عدد من المتطلبات:
- تحتاج الخدمة إلى حساب شخصي مناسب؛
- يجب دمج النظام الأساسي في نظام الفوترة الحالي؛
- البرامج والأجهزة: OpenStack + Tungsten Fabric (Open Contrail)، والذي تعلم مهندسونا كيفية "طهيه" جيدًا.
سنخبركم مرة أخرى عن كيفية تجميع الفريق، وتطوير واجهة الحساب الشخصي واتخاذ قرارات التصميم، إذا كان مجتمع هبرة مهتمًا بذلك.
الأدوات التي قررنا استخدامها:
- Python + Flask + Swagger + SQLAlchemy - مجموعة Python قياسية تمامًا؛
- Vue.js للواجهة الأمامية؛
- قررنا إجراء التفاعل بين المكونات والخدمات باستخدام Celery عبر AMQP.
سأشرح لك توقع الأسئلة حول اختيار بايثون. لقد وجدت اللغة مكانها المناسب في شركتنا وتطورت حولها ثقافة صغيرة، ولكن لا تزال قائمة. ولذلك تقرر البدء ببناء الخدمة عليه. علاوة على ذلك، فإن سرعة التطور في مثل هذه المشكلات غالبا ما تكون حاسمة.
لذلك، دعونا نبدأ التعارف.
الفاتورة الصامتة - الفواتير
لقد عرفنا هذا الرجل منذ وقت طويل. كان يجلس دائمًا بجواري ويحسب شيئًا ما بصمت. في بعض الأحيان، كان يقوم بإعادة توجيه طلبات المستخدم إلينا، وإصدار فواتير العملاء، وإدارة الخدمات. رجل عادي مجتهد. صحيح أنه كانت هناك صعوبات. إنه صامت، يفكر أحيانًا، وغالبًا ما يفكر في نفسه.
الفوترة هي أول نظام حاولنا تكوين صداقات معه. وكانت الصعوبة الأولى التي واجهناها عند معالجة الخدمات.
على سبيل المثال، عند إنشائها أو حذفها، تنتقل المهمة إلى قائمة انتظار الفوترة الداخلية. وبالتالي، يتم تنفيذ نظام العمل غير المتزامن مع الخدمات. لمعالجة أنواع خدماتنا، كنا بحاجة إلى "وضع" مهامنا في قائمة الانتظار هذه. وهنا واجهنا مشكلة: نقص التوثيق.
إذا حكمنا من خلال وصف واجهة برمجة تطبيقات البرنامج، فلا يزال من الممكن حل هذه المشكلة، لكن لم يكن لدينا الوقت للقيام بالهندسة العكسية، لذلك أخذنا المنطق إلى الخارج وقمنا بتنظيم قائمة انتظار مهام فوق RabbitMQ. يبدأ العميل عملية على الخدمة من حسابه الشخصي، وتتحول إلى "مهمة" Celery على الواجهة الخلفية ويتم تنفيذها على جانب الفوترة وOpenStack. يجعل الكرفس من السهل جدًا إدارة المهام وتنظيم التكرار ومراقبة الحالة. يمكنك قراءة المزيد عن "الكرفس"، على سبيل المثال، .
كما أن الفواتير لم توقف مشروعًا نفدت أمواله. من خلال التواصل مع المطورين، اكتشفنا أنه عند حساب الإحصائيات (ونحتاج إلى تنفيذ هذا النوع من المنطق بالضبط)، هناك علاقة معقدة بين قواعد الإيقاف. لكن هذه النماذج لا تتناسب بشكل جيد مع واقعنا. وقمنا أيضًا بتنفيذ ذلك من خلال المهام على Celery، مع نقل منطق إدارة الخدمة إلى الجانب الخلفي.
أدت كلتا المشكلتين المذكورتين أعلاه إلى أن تصبح التعليمات البرمجية منتفخة قليلاً وسيتعين علينا في المستقبل إعادة البناء من أجل نقل منطق العمل مع المهام إلى خدمة منفصلة. نحتاج أيضًا إلى تخزين بعض المعلومات حول المستخدمين وخدماتهم في جداولنا لدعم هذا المنطق.
مشكلة أخرى هي الصمت.
يجيب بيلي بصمت على بعض طلبات واجهة برمجة التطبيقات "موافق". كان هذا هو الحال، على سبيل المثال، عندما قمنا بسداد الدفعات الموعودة أثناء الاختبار (المزيد عن ذلك لاحقًا). تم تنفيذ الطلبات بشكل صحيح ولم نرى أي أخطاء.
اضطررت إلى دراسة السجلات أثناء العمل مع النظام من خلال واجهة المستخدم. اتضح أن الفوترة نفسها تنفذ طلبات مماثلة، وتغير النطاق إلى مستخدم معين، على سبيل المثال، المشرف، وتمريره في المعلمة su.
بشكل عام، على الرغم من الفجوات في الوثائق والعيوب البسيطة في واجهة برمجة التطبيقات، إلا أن كل شيء سار على ما يرام. يمكن قراءة السجلات حتى في ظل التحميل الثقيل إذا فهمت كيفية تنظيمها وما الذي تبحث عنه. هيكل قاعدة البيانات مزخرف، ولكنه منطقي تمامًا وجذاب في بعض النواحي.
لذا، لتلخيص، المشاكل الرئيسية التي واجهناها في مرحلة التفاعل تتعلق بميزات تنفيذ نظام معين:
- و"ملامح" غير موثقة أثرت علينا بشكل أو بآخر؛
- مصدر مغلق (الفوترة مكتوبة بلغة C++)، ونتيجة لذلك - من المستحيل حل المشكلة رقم 1 بأي طريقة أخرى غير "التجربة والخطأ".
لحسن الحظ، يحتوي المنتج على واجهة برمجة تطبيقات واسعة النطاق وقد قمنا بدمج الأنظمة الفرعية التالية في حسابنا الشخصي:
- وحدة الدعم الفني - يتم "توكيل" الطلبات الواردة من حسابك الشخصي لإعداد الفواتير بشفافية لعملاء الخدمة؛
- الوحدة المالية - تسمح لك بإصدار الفواتير للعملاء الحاليين، وإجراء عمليات الشطب وإنشاء مستندات الدفع؛
- وحدة التحكم في الخدمة - لهذا كان علينا تنفيذ المعالج الخاص بنا. لقد لعبت قابلية توسيع النظام دورًا في أيدينا وقمنا "بتعليم" بيلي نوعًا جديدًا من الخدمة.
لقد كان الأمر مزعجًا بعض الشيء، لكن بطريقة أو بأخرى، أعتقد أنني وبيلي سنتفق معًا.
المشي عبر حقول التنغستن – نسيج التنغستن
حقول التنغستن مليئة بمئات الأسلاك، وتمر عبرها آلاف البتات من المعلومات. يتم جمع المعلومات في "حزم"، وتحليلها، وبناء مسارات معقدة، كما لو كان ذلك عن طريق السحر.
هذا هو مجال النظام الثاني الذي كان علينا تكوين صداقات معه - Tungsten Fabric (TF)، المعروف سابقًا باسم OpenContrail. وتتمثل مهمتها في إدارة معدات الشبكة، وتوفير فكرة برمجية لنا كمستخدمين. TF - SDN، يلخص المنطق المعقد للعمل مع معدات الشبكة. هناك مقالة جيدة عن التكنولوجيا نفسها، على سبيل المثال، .
تم دمج النظام مع OpenStack (الموضح أدناه) عبر البرنامج الإضافي Neutron.
التفاعل بين خدمات OpenStack.
لقد عرّفنا رجال قسم العمليات على هذا النظام. نحن نستخدم واجهة برمجة التطبيقات (API) الخاصة بالنظام لإدارة حزمة الشبكة من خدماتنا. لم يسبب لنا أي مشاكل أو إزعاجات خطيرة حتى الآن (لا أستطيع التحدث نيابة عن الرجال من OE)، ولكن كانت هناك بعض الشذوذات في التفاعل.
بدا الأمر الأول على هذا النحو: الأوامر التي تتطلب إخراج كمية كبيرة من البيانات إلى وحدة تحكم المثيل عند الاتصال عبر SSH ببساطة "قطعت" الاتصال، بينما كان كل شيء يعمل بشكل صحيح عبر VNC.
بالنسبة لأولئك الذين ليسوا على دراية بالمشكلة، يبدو الأمر مضحكًا تمامًا: ls /root يعمل بشكل صحيح، بينما، على سبيل المثال، "يتجمد" الجزء العلوي تمامًا. ولحسن الحظ، واجهنا مشاكل مماثلة من قبل. تم تحديد ذلك من خلال ضبط وحدة الإرسال الكبرى (MTU) على المسار من عقد الحساب إلى أجهزة التوجيه. بالمناسبة، هذه ليست مشكلة TF.
وكانت المشكلة التالية قاب قوسين أو أدنى. وفي لحظة "جميلة" واحدة، اختفى سحر التوجيه، بهذه الطريقة. توقف TF عن إدارة التوجيه على الجهاز.
لقد عملنا مع Openstack من مستوى الإدارة وبعد ذلك انتقلنا إلى مستوى المستخدم المطلوب. يبدو أن SDN "يختطف" نطاق المستخدم الذي يتم تنفيذ الإجراءات بواسطته. الحقيقة هي أنه يتم استخدام نفس حساب المسؤول لتوصيل TF وOpenStack. وفي خطوة التحول إلى المستخدم اختفى "السحر". تقرر إنشاء حساب منفصل للعمل مع النظام. هذا سمح لنا بالعمل دون تعطيل وظيفة التكامل.
أشكال الحياة السيليكونية - OpenStack
يعيش مخلوق من السيليكون ذو شكل غريب بالقرب من حقول التنغستن. الأهم من ذلك كله، أنه يبدو وكأنه طفل متضخم يمكنه أن يسحقنا بضربة واحدة، ولكن لا يوجد عدوان واضح منه. إنها لا تسبب الخوف، لكن حجمها يبعث الخوف. كما هو الحال مع تعقيد ما يحدث حولها.
OpenStack هو جوهر منصتنا.
يحتوي OpenStack على العديد من الأنظمة الفرعية، والتي نستخدم منها حاليًا Nova وGlance وCinder بشكل أكثر نشاطًا. كل واحد منهم لديه API الخاص به. Nova مسؤولة عن حساب الموارد وإنشاء المثيلات، وCinder مسؤولة عن إدارة وحدات التخزين ولقطاتها، وGlance هي خدمة صور تدير قوالب نظام التشغيل والمعلومات التعريفية الخاصة بها.
تعمل كل خدمة في حاوية، ووسيط الرسائل هو "الأرنب الأبيض" - RabbitMQ.
لقد سبب لنا هذا النظام مشكلة غير متوقعة.
ولم تستغرق المشكلة الأولى وقتًا طويلاً عندما حاولنا توصيل وحدة تخزين إضافية بالخادم. رفضت Cinder API بشكل قاطع تنفيذ هذه المهمة. بتعبير أدق، إذا كنت تعتقد أن OpenStack نفسه، فقد تم إنشاء الاتصال، ولكن لا يوجد جهاز قرص داخل الخادم الظاهري.
قررنا أن نلتفت وطلبنا نفس الإجراء من Nova API. والنتيجة هي أن الجهاز يتصل بشكل صحيح ويمكن الوصول إليه من خلال الخادم. يبدو أن المشكلة تحدث عندما لا يستجيب تخزين الكتل لـ Cinder.
كانت هناك صعوبة أخرى تنتظرنا عند العمل مع الأقراص. لا يمكن فصل وحدة تخزين النظام عن الخادم.
مرة أخرى، "يقسم" OpenStack نفسه أنه دمر الاتصال ويمكنك الآن العمل بشكل صحيح مع وحدة التخزين بشكل منفصل. لكن واجهة برمجة التطبيقات (API) لم ترغب بشكل قاطع في إجراء العمليات على القرص.
وهنا قررنا ألا نتقاتل بشكل خاص، بل أن نغير نظرتنا لمنطق الخدمة. إذا كان هناك مثيل، فيجب أن يكون هناك أيضًا وحدة تخزين للنظام. لذلك، لا يمكن للمستخدم بعد إزالة أو تعطيل "قرص" النظام دون حذف "الخادم".
OpenStack عبارة عن مجموعة معقدة من الأنظمة ذات منطق التفاعل الخاص بها وواجهة برمجة التطبيقات المزخرفة. لقد ساعدنا التوثيق التفصيلي إلى حد ما وبالطبع التجربة والخطأ (أين سنكون بدونها).
اختبار المدى
لقد أجرينا إطلاقًا تجريبيًا في ديسمبر من العام الماضي. كانت المهمة الرئيسية هي اختبار مشروعنا في وضع القتال من الجانب الفني ومن جانب تجربة المستخدم. تمت دعوة الجمهور بشكل انتقائي وتم إغلاق الاختبار. ومع ذلك، فقد تركنا أيضًا خيار طلب الوصول إلى الاختبار على موقعنا.
الاختبار نفسه، بالطبع، لم يخلو من لحظات مضحكة، لأن هذا هو المكان الذي بدأت فيه مغامراتنا للتو.
أولاً، قمنا بتقييم الاهتمام بالمشروع بشكل غير صحيح إلى حد ما واضطررنا إلى إضافة عقد حسابية بسرعة أثناء الاختبار. حالة شائعة للكتلة، ولكن كانت هناك بعض الفروق الدقيقة هنا أيضًا. تشير الوثائق الخاصة بإصدار معين من TF إلى الإصدار المحدد من kernel الذي تم اختبار العمل مع vRouter عليه. قررنا إطلاق العقد بنواة أحدث. ونتيجة لذلك، لم يتلق فريق العمل مسارات من العقد. اضطررت إلى استعادة النواة بشكل عاجل.
هناك فضول آخر يتعلق بوظيفة زر "تغيير كلمة المرور" في حسابك الشخصي.
قررنا استخدام JWT لتنظيم الوصول إلى حسابنا الشخصي حتى لا نعمل مع الجلسات. نظرًا لأن الأنظمة متنوعة ومنتشرة على نطاق واسع، فإننا ندير الرمز المميز الخاص بنا، حيث نقوم "بتغليف" الجلسات من الفواتير ورمز مميز من OpenStack. عند تغيير كلمة المرور، فإن الرمز المميز، بالطبع، "يصبح سيئًا"، نظرًا لأن بيانات المستخدم لم تعد صالحة ويجب إعادة إصدارها.
لقد فقدنا هذه النقطة، وببساطة لم تكن هناك موارد كافية لإنهاء هذه المقالة بسرعة. كان علينا قطع الوظيفة قبل بدء الاختبار مباشرة.
نقوم حاليًا بتسجيل خروج المستخدم إذا تم تغيير كلمة المرور.
على الرغم من هذه الفروق الدقيقة، سارت الاختبارات بشكل جيد. وفي غضون أسبوعين، توقف حوالي 300 شخص. لقد تمكنا من النظر إلى المنتج من خلال عيون المستخدمين واختباره أثناء العمل وجمع تعليقات عالية الجودة.
أن تستمر
بالنسبة للكثيرين منا، هذا هو المشروع الأول بهذا الحجم. لقد تعلمنا عددًا من الدروس القيمة حول كيفية العمل كفريق واتخاذ القرارات المعمارية والتصميمية. كيفية دمج الأنظمة المعقدة بموارد قليلة ودمجها في الإنتاج.
بالطبع، هناك شيء يجب العمل عليه سواء من حيث التعليمات البرمجية أو من حيث واجهات تكامل النظام. المشروع لا يزال صغيرًا جدًا، ولكن لدينا طموحات كبيرة لتطويره ليصبح خدمة موثوقة ومريحة.
لقد تمكنا بالفعل من إقناع الأنظمة. يتعامل بيل بإخلاص مع طلبات العد والفواتير وطلبات المستخدم في خزانته. يوفر لنا "سحر" حقول التنغستن اتصالات مستقرة. وOpenStack فقط هو الذي يصبح متقلبًا في بعض الأحيان، ويصرخ بشيء مثل "لم تقم WSREP بعد بإعداد العقدة لاستخدام التطبيق." لكن تلك قصة مختلفة تماما..
أطلقنا الخدمة مؤخرًا.
يمكنك معرفة كافة التفاصيل على موقعنا .
فريق تطوير CLO
وصلات مفيدة
كومة مفتوحة
نسيج التنغستن
المصدر: www.habr.com