جربت URUS Kubernetes بأشكال مختلفة: عملية نشر معدنية مستقلة في Google Cloud ، ثم نقلت نظامها الأساسي إلى Mail.ru Cloud Solutions (MCS). يقول Igor Shishkin (
t3ran ) ، مسؤول النظام الأقدم في URUS: كيفية اختيار موفر سحابة جديد وكيفية إدارة الترحيل إليه في غضون ساعتين.
ماذا يفعل أوروس؟
هناك العديد من الطرق لتحسين جودة البيئة الحضرية ، أحدها جعلها صديقة للبيئة. هذا هو بالضبط ما تعمل عليه شركة URUS - Smart Digital Services. تنفذ الحلول التي تساعد الشركات على مراقبة المؤشرات البيئية الهامة وتقليل الآثار البيئية السلبية. تقوم المستشعرات بجمع البيانات حول تكوين الهواء ومستوى الضوضاء والمعلمات الأخرى ، ثم ترسلها إلى منصة واحدة "Urus-Ekomon" لتحليل وإعداد التوصيات.
كيف يتم عمل "أورس" بالداخل
العميل النموذجي لـ URUS هي شركة تقع في منطقة سكنية أو بالقرب منها. يمكن أن يكون مصنع أو ميناء أو مستودع للسكك الحديدية أو أي منشأة أخرى. إذا تلقى عميلنا بالفعل تحذيرًا ، أو تم تغريمه بسبب التلوث البيئي ، أو كان يريد تقليل الضوضاء ، وتقليل كمية الانبعاثات الضارة ، فإنه يأتي إلينا ، ونقدم له حلاً جاهزًا للمراقبة البيئية.
يُظهر رسم بياني لرصد تركيز H2S انبعاثات ليلية منتظمة من منشأة قريبةتحتوي الأجهزة التي نستخدمها في URUS على العديد من أجهزة الاستشعار التي تجمع معلومات حول محتوى بعض الغازات ومستويات الضوضاء وغيرها من البيانات لتقييم الوضع البيئي. يتم تحديد العدد الدقيق لأجهزة الاستشعار دائمًا بواسطة مهمة محددة.
اعتمادًا على القياس المحدد ، يمكن وضع الأجهزة المزودة بأجهزة استشعار على جدران المباني والأعمدة وغيرها من الأماكن التعسفية. يقوم كل جهاز من هذا القبيل بجمع المعلومات وتجميعها وإرسالها إلى بوابة استلام البيانات. هناك نقوم بحفظ البيانات للتخزين طويل الأجل والمعالجة المسبقة للتحليل اللاحق. أبسط مثال على ما حصلنا عليه بعد التحليل هو مؤشر جودة الهواء ، المعروف أيضًا باسم AQI.
في الوقت نفسه ، تعمل العديد من الخدمات الأخرى على نظامنا الأساسي ، لكنها أساسًا ذات طبيعة خدمة. على سبيل المثال ، ترسل خدمة الإشعارات إعلامات إلى العملاء إذا تجاوزت أي من المعلمات المراقبة (على سبيل المثال ، محتوى CO
2 ) القيمة المسموح بها.
كيف يمكننا تخزين البيانات. قصة Kubernetes على المعدن العاري
يحتوي مشروع المراقبة البيئية URUS على العديد من مستودعات البيانات. في واحدة نحمل البيانات "الخام" - ما تلقيناه مباشرة من الأجهزة نفسها. هذا التخزين هو شريط "مغناطيسي" ، كما هو الحال في الأشرطة القديمة ، مع تاريخ جميع المؤشرات. يتم استخدام النوع الثاني من التخزين للبيانات التي تمت معالجتها مسبقًا - البيانات من الأجهزة المخصب بالبيانات الوصفية حول اتصالات أجهزة الاستشعار وقراءات الأجهزة نفسها ، والانتساب إلى المؤسسات ، والمواقع ، وما إلى ذلك. تتيح لك هذه المعلومات تقييم ديناميكي لكيفية تغير مؤشر معين خلال فترة زمنية محددة . نحن نستخدم تخزين البيانات الخام ، بما في ذلك كنسخة احتياطية واستعادة البيانات التي سبق معالجتها ، إذا دعت الحاجة إلى ذلك.
عندما كنا نبحث عن طرق لحل مشكلة التخزين منذ عدة سنوات ، كان لدينا خياران لاختيار منصة: Kubernetes و OpenStack. ولكن نظرًا لأن هذا الأخير يبدو وحشيًا جدًا (انظر فقط إلى هندسته المعمارية لرؤية هذا) ، ثم استقرنا على Kubernetes. وكانت الحجة الأخرى في صالحه هي التحكم البسيط نسبياً في البرامج ، والقدرة على قطع العقد الحديدي بمرونة أكبر في الموارد.
بالتوازي مع تطور Kubernetes نفسه ، درسنا أيضًا طرق تخزين البيانات ، بينما احتفظنا بجميع مخازننا في Kubernetes على أجهزتنا ، تلقينا خبرة ممتازة. كل ما عشناه في Kubernetes: التخزين الكامل للدولة ، ونظام المراقبة ، CI / CD. أصبحت Kubernetes منصة الكل في واحد لدينا.
لكننا أردنا العمل مع Kubernetes كخدمة ، وعدم الانخراط في دعمها وتطويرها. بالإضافة إلى ذلك ، لم نكن نحب أن يكلفنا محتواها من المعدن العاري ، وكان التطور مطلوبًا دائمًا! على سبيل المثال ، كانت إحدى المهام الأولى هي دمج وحدات تحكم Kubernetes Ingress في البنية التحتية للشبكة في مؤسستنا. هذه مهمة مرهقة ، خاصة إذا كنت تتخيل أنه في ذلك الوقت لم يكن هناك شيء جاهز لإدارة الموارد البرنامجية مثل سجلات DNS أو تخصيص IP. بعد ذلك بدأنا في تجربة مستودع بيانات خارجي. لم نصل إلى تنفيذ وحدة التحكم في PVC ، ولكن حتى ذلك الحين أصبح من الواضح أن هذا كان مجالًا كبيرًا من العمل الذي كان من الضروري فيه تحديد اختصاصيين فرديين.
الترحيل إلى Google Cloud Platform الحل المؤقت
لقد أدركنا أن هذا الأمر لا يمكن أن يستمر ، ونقل بياناتنا من المعدن العاري إلى منصة Google Cloud. في الواقع ، بالنسبة للشركة الروسية ، لم يكن هناك العديد من الخيارات المثيرة للاهتمام: بالإضافة إلى منصة Google Cloud ، لم تقدم سوى شركة Amazon خدمة مماثلة ، لكننا ما زلنا نتوصل إلى حل من Google. ثم بدا لنا أكثر ربحية من الناحية الاقتصادية ، وأقرب إلى المنبع ، ناهيك عن حقيقة أن جوجل نفسها هي نوع من PoC Kubernetes في الإنتاج.
ظهرت المشكلة الخطيرة الأولى في الأفق بالتوازي مع نمو قاعدة عملائنا. عندما أصبح من الضروري بالنسبة لنا تخزين البيانات الشخصية ، واجهنا خيارًا: إما أن نعمل مع Google وننتهك القوانين الروسية ، أو نبحث عن بديل في الاتحاد الروسي. كان الاختيار ، بشكل عام ، متوقعًا. :)
كيف رأينا الخدمة السحابية المثالية
بحلول بداية البحث ، عرفنا بالفعل ما أردنا الحصول عليه من مزود السحابة في المستقبل. ما الخدمة التي كنا نبحث عنها:
- سريع ومرن . حتى نتمكن من إضافة عقدة جديدة بسرعة أو نشر شيء ما في أي وقت.
- غير مكلفة . كنا قلقين للغاية بشأن القضية المالية ، لأننا كنا محدودين في الموارد. لقد أدركنا بالفعل أننا أردنا العمل مع Kubernetes ، والآن كانت المهمة هي تقليل تكلفتها من أجل زيادة أو على الأقل الحفاظ على فعالية استخدام هذا الحل.
- الآلي . لقد خططنا للعمل مع الخدمة من خلال واجهة برمجة التطبيقات (API) ، دون الحاجة إلى المديرين والمكالمات الهاتفية أو الحالات التي تحتاج فيها إلى رفع عشرات العقد يدويًا في وضع الطوارئ. نظرًا لأن معظم عملياتنا مؤتمتة ، فقد توقعنا نفس الشيء من خلال خدمة سحابية.
- مع خوادم في الاتحاد الروسي . بالطبع ، خططنا للامتثال للقانون الروسي ونفس 152-FZ.
في ذلك الوقت ، كان عدد مزودي خدمة Kubernetes aaS قليلين في روسيا ، أثناء اختيار مزود ، كان من المهم بالنسبة لنا ألا نضعف أولوياتنا. قدم لنا فريق Mail.ru Cloud Solutions ، الذي بدأنا العمل فيه وما زلنا نعمل ، خدمة مؤتمتة بالكامل مع دعم API ولوحة تحكم مريحة يوجد بها Horizon - حيث يمكننا رفع عدد تعسفي من العقد بسرعة.
كيف تمكنا من الهجرة إلى MCS في ساعتين
في عمليات الترحيل هذه ، تواجه العديد من الشركات صعوبات وفشل ، ولكن في حالتنا لم تكن كذلك. كنا محظوظين: نظرًا لأننا كنا نعمل بالفعل على Kubernetes قبل بدء الترحيل ، فقد قمنا فقط بتثبيت ثلاثة ملفات وأطلقنا خدماتنا على نظام أساسي سحابي جديد ، في MCS. واسمحوا لي أن أذكرك أنه بحلول ذلك الوقت تركنا أخيرًا معدنًا عارياً وعاشنا على Google Cloud Platform. نظرًا لأن الحركة بحد ذاتها لم تستغرق أكثر من ساعتين ، بالإضافة إلى وقت إضافي (حوالي ساعة) استغرقت عملية نسخ البيانات من أجهزتنا. ثم استخدمنا بالفعل Spinnaker (خدمة CD متعددة السحابية لتوفير توصيل مستمر). لقد أضفناها بسرعة إلى المجموعة الجديدة واستمرنا في العمل كالمعتاد.
بفضل أتمتة عمليات التطوير و CI / CD Kubernetes في URUS يشغلها أحد المتخصصين (وهذا أنا). في مرحلة ما ، عمل مسؤول نظام آخر معي ، لكن اتضح بعد ذلك أننا قد أتمنا بالفعل الروتين الرئيسي بأكمله ، ومن جانب منتجنا الرئيسي ، كانت هناك المزيد والمزيد من المهام ومن المنطقي توجيه الموارد إلى ذلك.
لقد تلقينا من المزود السحابي ما توقعناه ، حيث بدأنا التعاون دون أوهام. إذا كانت هناك أي حوادث ، فمعظمها حوادث فنية ، والتي يمكن تفسيرها بسهولة من خلال الحداثة النسبية للخدمة. الشيء الرئيسي هو أن فريق MCS يزيل بسرعة العيوب ويجيب بسرعة على الأسئلة في الرسائل الفورية.
إذا قارنا التجربة مع Google Cloud Platform ، فعندئذٍ في حالتي لم أكن أعرف حتى مكان زر التعليقات ، لأنه ببساطة لم يكن ضروريًا. وإذا حدثت أي مشاكل ، فقد أرسلت Google نفسها إعلامات من جانب واحد. ولكن في حالة MCS ، إضافة كبيرة ، أعتقد أنهم أقرب ما يكون إلى العملاء الروس - جغرافيا وعقليا.
كما نرى العمل مع الغيوم في المستقبل
الآن يرتبط عملنا ارتباطًا وثيقًا بـ Kubernetes ، وهو يناسبنا تمامًا من حيث مهام البنية التحتية. لذلك ، لا نخطط للترحيل منه في مكان ما ، على الرغم من أننا نقدم باستمرار ممارسات وخدمات جديدة لتبسيط المهام الروتينية وأتمتة مهام جديدة ، وزيادة استقرار وموثوقية الخدمات ... الآن نحن نطلق خدمة Chaos Monkey (على وجه التحديد ، نحن نستخدم chaoskube ، لكن هذا لا يغير المفهوم: ) ، الذي تم إنشاؤه أصلاً في Netflix. يقوم Chaos Monkey بعمل شيء واحد بسيط: في الوقت التعسفي يقوم بحذف تعسفي في Kubernetes. هذا ضروري لخدمتنا أن نعيش بشكل طبيعي مع عدد الحالات n - 1 ، لذلك نحن معتادون على أن نكون مستعدين لأية أعطال.
أرى الآن أن استخدام حلول الجهات الخارجية - نفس المنصات السحابية - هو الحل الصحيح الوحيد للشركات الناشئة. عادةً ما تكون الموارد محدودة في كل من الموارد البشرية والمالية في بداية الرحلة ، كما أن بناء وصيانة مركز البيانات أو السحابة الخاصة بك يعد مكلفًا للغاية ويستغرق وقتًا طويلاً. يمكن لموفري السحابة تقليل هذه التكاليف إلى الحد الأدنى ، يمكنهم الحصول بسرعة على الموارد اللازمة للخدمات للعمل هنا والآن ، ودفع ثمن هذه الموارد في الواقع. بالنسبة لشركة Urus ، سنبقى مخلصين لـ Kubernetes في السحابة في الوقت الحالي. لكن من يدري ، ربما سيتعين علينا التوسع جغرافيًا ، أو تنفيذ حلول تعتمد على بعض المعدات المحددة. أو ربما مقدار الموارد المستهلكة يبرر Kubernetes الخاصة به على المعدن العاري ، كما في الأيام الخوالي. :)
ما تعلمناه من تجربتنا مع الخدمات السحابية
بدأنا باستخدام Kubernetes على المعدن العاري ، وحتى هناك كان جيدًا بطريقته الخاصة. ولكن تم الكشف عن نقاط قوته على وجه التحديد كعنصر aaS في السحابة. إذا قمت بتعيين هدف وأتمتة كل شيء إلى أقصى حد ممكن ، فستتمكن من تجنب حبس البائع والتحرك بين مزودي الخدمات السحابية سيستغرق بضع ساعات ، وستبقى الخلايا العصبية معنا. يمكننا تقديم المشورة للشركات الأخرى: إذا كنت ترغب في بدء تشغيل الخدمة (السحابية) لديك ، والموارد المحدودة والسرعة القصوى للتنمية ، ابدأ الآن عن طريق استئجار الموارد السحابية ، وبناء مركز البيانات الخاص بك بعد أن يكتب Forbes عنك.