نحوه مهاجرت به ابر در دو ساعت به لطف Kubernetes و اتوماسیون

شرکت URUS Kubernetes را به اشکال مختلف امتحان کرد: استقرار مستقل بر روی فلز خالی، در Google Cloud، و سپس پلت فرم خود را به ابر Mail.ru Cloud Solutions (MCS) منتقل کرد. ایگور شیشکین می گوید که چگونه آنها یک ارائه دهنده ابر جدید را انتخاب کردند و چگونه توانستند در یک رکورد دو ساعت به آن مهاجرت کنند (t3ran)، مدیر ارشد سیستم در URUS.

URUS چه می کند؟

راه های زیادی برای بهبود کیفیت محیط شهری وجود دارد که یکی از آنها سازگاری با محیط زیست است. این دقیقاً همان چیزی است که شرکت URUS - Smart Digital Services روی آن کار می کند. در اینجا آنها راه حل هایی را اجرا می کنند که به شرکت ها کمک می کند تا شاخص های مهم زیست محیطی را نظارت کنند و تأثیر منفی آنها را بر محیط زیست کاهش دهند. سنسورها داده‌های ترکیب هوا، سطح نویز و سایر پارامترها را جمع‌آوری می‌کنند و سپس آنها را برای تجزیه و تحلیل و ارائه توصیه‌ها به پلتفرم یکپارچه URUS-Ekomon ارسال می‌کنند.

چگونه URUS از داخل کار می کند

یک مشتری معمولی URUS شرکتی است که در یا نزدیک یک منطقه مسکونی واقع شده است. این می تواند یک کارخانه، بندر، انبار راه آهن یا هر تاسیسات دیگری باشد. اگر مشتری ما قبلاً اخطار دریافت کرده باشد، به دلیل آلودگی محیط زیست جریمه شده باشد یا بخواهد صدای کمتری ایجاد کند، میزان انتشارات مضر را کاهش دهد، به ما مراجعه می کند و ما قبلاً یک راه حل آماده برای نظارت بر محیط زیست به او پیشنهاد می کنیم.

نمودار نظارت بر غلظت H2S انتشار منظم شبانه از یک کارخانه مجاور را نشان می دهد

دستگاه‌هایی که ما در URUS استفاده می‌کنیم حاوی چندین حسگر هستند که اطلاعات مربوط به محتوای گازهای خاص، سطوح نویز و سایر داده‌ها را برای ارزیابی وضعیت محیطی جمع‌آوری می‌کنند. تعداد دقیق سنسورها همیشه بر اساس وظیفه خاص تعیین می شود.

بسته به مشخصات اندازه گیری ها، دستگاه های دارای حسگر را می توان بر روی دیوارهای ساختمان ها، قطب ها و سایر مکان های دلخواه قرار داد. هر یک از این دستگاه‌ها اطلاعات را جمع‌آوری می‌کند، آن‌ها را جمع‌آوری می‌کند و به دروازه دریافت داده ارسال می‌کند. در آنجا داده ها را برای ذخیره سازی طولانی مدت ذخیره می کنیم و آن را برای تجزیه و تحلیل بعدی از قبل پردازش می کنیم. ساده ترین مثال از آنچه در نتیجه تجزیه و تحلیل به دست می آوریم، شاخص کیفیت هوا است که به نام AQI نیز شناخته می شود.

به موازات آن، بسیاری از خدمات دیگر بر روی پلت فرم ما کار می کنند، اما آنها عمدتا ماهیت خدماتی دارند. به عنوان مثال، اگر هر یک از پارامترهای نظارت شده (مثلاً محتوای CO2) از مقدار مجاز فراتر رود، سرویس اطلاع رسانی اعلان هایی را برای مشتریان ارسال می کند.

چگونه داده ها را ذخیره می کنیم داستان Kubernetes بر روی فلز برهنه

پروژه نظارت بر محیط زیست URUS دارای چندین انبار داده است. در یکی، ما داده های "خام" را نگه می داریم - آنچه را که مستقیماً از خود دستگاه ها دریافت کرده ایم. این ذخیره‌سازی یک نوار "مغناطیسی" است، مانند نوارهای کاست قدیمی، با تاریخچه همه نشانگرها. نوع دوم ذخیره سازی برای داده های از پیش پردازش شده استفاده می شود - داده های دستگاه ها، غنی شده با ابرداده در مورد اتصالات بین حسگرها و خوانش های خود دستگاه ها، وابستگی به سازمان ها، مکان ها و غیره. این اطلاعات به شما امکان می دهد به صورت پویا ارزیابی کنید که یک شاخص خاص چگونه است. در یک دوره زمانی معین تغییر کرد. در صورت بروز چنین نیازی، از ذخیره‌سازی داده‌های خام، از جمله، به عنوان پشتیبان و برای بازیابی داده‌های از پیش پردازش شده استفاده می‌کنیم.

زمانی که چندین سال پیش به دنبال حل مشکل ذخیره سازی خود بودیم، دو گزینه پلتفرم داشتیم: Kubernetes و OpenStack. اما از آنجایی که دومی کاملاً هیولایی به نظر می رسد (فقط به معماری آن نگاه کنید تا در این مورد متقاعد شوید)، ما در Kubernetes قرار گرفتیم. استدلال دیگر به نفع آن، کنترل نرم افزاری نسبتاً ساده، توانایی برش انعطاف پذیرتر حتی گره های سخت افزاری بر اساس منابع بود.

به موازات تسلط بر خود Kubernetes، ما همچنین روش‌هایی را برای ذخیره داده‌ها مطالعه کردیم، در حالی که تمام فضای ذخیره‌سازی خود را در Kubernetes روی سخت‌افزار خود نگه داشتیم، تخصص بسیار خوبی دریافت کردیم. همه چیزهایی که در آن زمان در Kubernetes زندگی می کردیم: ذخیره سازی کامل، سیستم نظارت، CI/CD. Kubernetes برای ما به یک پلتفرم همه کاره تبدیل شده است.

اما ما می خواستیم با Kubernetes به عنوان یک سرویس کار کنیم و در پشتیبانی و توسعه آن شرکت نکنیم. بعلاوه، ما دوست نداشتیم که نگهداری آن بر روی فلز لخت چقدر برایمان هزینه داشت و دائماً به توسعه نیاز داشتیم! به عنوان مثال، یکی از اولین وظایف ادغام کنترلرهای Kubernetes Ingress در زیرساخت شبکه سازمان ما بود. این یک کار دست و پا گیر است، به ویژه با توجه به اینکه در آن زمان هیچ چیز برای مدیریت منابع برنامه ای مانند رکوردهای DNS یا تخصیص آدرس های IP آماده نبود. بعداً ما شروع به آزمایش با ذخیره سازی داده های خارجی کردیم. ما هرگز به اجرای کنترلر PVC نرسیدیم، اما حتی پس از آن مشخص شد که این یک حوزه کاری بزرگ است که به متخصصان اختصاصی نیاز دارد.

تغییر به Google Cloud Platform یک راه حل موقت است

متوجه شدیم که این نمی‌تواند ادامه یابد و داده‌های خود را از فلز خالی به Google Cloud Platform منتقل کردیم. در واقع، در آن زمان گزینه‌های جالب زیادی برای یک شرکت روسی وجود نداشت: علاوه بر پلتفرم ابری گوگل، تنها آمازون خدمات مشابهی را ارائه می‌کرد، اما ما همچنان بر روی راه‌حل گوگل قرار گرفتیم. سپس به نظر ما از نظر اقتصادی سودآورتر به نظر می رسید، به Upstream نزدیک تر، بدون ذکر این واقعیت که گوگل خود نوعی 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 مقایسه کنم، در مورد آنها حتی نمی دانستم دکمه بازخورد کجاست، زیرا به سادگی نیازی به آن وجود نداشت. و اگر مشکلی پیش می آمد، خود گوگل اعلان هایی را به صورت یک طرفه ارسال می کرد. اما در مورد MCS، من فکر می کنم مزیت بزرگ این است که آنها تا حد امکان به مشتریان روسی نزدیک هستند - هم از نظر جغرافیایی و هم از نظر ذهنی.

نحوه کار با ابرها در آینده را می بینیم

اکنون کار ما کاملاً با Kubernetes گره خورده است و از نظر وظایف زیرساختی کاملاً مناسب ما است. بنابراین، ما قصد نداریم از آن به جایی مهاجرت کنیم، اگرچه ما دائماً در حال معرفی شیوه‌ها و خدمات جدید برای ساده‌سازی کارهای روتین و خودکارسازی کارهای جدید، افزایش پایداری و قابلیت اطمینان سرویس‌ها هستیم... اکنون در حال راه‌اندازی سرویس Chaos Monkey هستیم (به طور خاص ، ما از chaoskube استفاده می کنیم، اما این مفهوم را تغییر نمی دهد: )، که در ابتدا توسط نتفلیکس ایجاد شده بود. Chaos Monkey یک کار ساده انجام می دهد: یک غلاف تصادفی Kubernetes را در یک زمان تصادفی حذف می کند. این برای اینکه سرویس ما به طور معمول با تعداد نمونه های n-1 زندگی کند ضروری است، بنابراین ما خود را آموزش می دهیم که برای هر مشکلی آماده باشیم.

اکنون استفاده از راه حل های شخص ثالث - همان پلتفرم های ابری - را تنها کار درست برای شرکت های جوان می بینم. معمولاً در ابتدای سفر، منابع انسانی و مالی آنها محدود است و ساخت و نگهداری ابر یا مرکز داده خودشان بسیار گران و کار فشرده است. ارائه دهندگان ابری به شما اجازه می دهند تا این هزینه ها را به حداقل برسانید؛ می توانید به سرعت منابع لازم برای بهره برداری از خدمات را اینجا و اکنون از آنها دریافت کنید و پس از آن هزینه این منابع را بپردازید. در مورد شرکت URUS، ما در حال حاضر به Kubernetes در فضای ابری وفادار خواهیم ماند. اما چه کسی می داند، ممکن است مجبور شویم از نظر جغرافیایی گسترش پیدا کنیم یا راه حل هایی را بر اساس برخی تجهیزات خاص پیاده سازی کنیم. یا شاید مقدار منابع مصرف شده مانند روزهای خوب قدیمی، کوبرنتیس خود را بر روی فلز برهنه توجیه کند. 🙂

آنچه از کار با خدمات ابری آموختیم

ما شروع به استفاده از Kubernetes روی فلز خالی کردیم، و حتی در آنجا نیز در نوع خود خوب بود. اما نقاط قوت آن دقیقاً به عنوان یک جزء aaS در ابر آشکار شد. اگر هدفی تعیین کنید و همه چیز را تا حد امکان خودکار کنید، می‌توانید از قفل شدن فروشنده جلوگیری کنید و جابه‌جایی بین ارائه‌دهندگان ابر چند ساعت طول می‌کشد و سلول‌های عصبی با ما باقی خواهند ماند. ما می‌توانیم به شرکت‌های دیگر توصیه کنیم: اگر می‌خواهید سرویس (ابر) خود را راه‌اندازی کنید، با داشتن منابع محدود و حداکثر سرعت توسعه، از همین حالا با اجاره منابع ابری شروع کنید و پس از نوشتن فوربس در مورد شما، مرکز داده خود را بسازید.

منبع: www.habr.com