آشنایی با Orchestration

کانتینری شدن سرویس‌ها کمک شایانی به راه اندازی پلتفرم‌ها و نرم افزار‌ها کرده است. با زیاد شدن container ‌ها به جهت مدیریت و افزوده شدن ویژگیهای جدید ابزار‌هایی به نام orchestrator به جود آمدند

Orchestration

این روز‌ها کمتر توسعه دهندگانی هستند که نام‌ Docker و Orchestration را نشنیده باشند.

در معماری مایکروسرویس ابزار‌های مختلف و پیشرفته به جهت Deploy  کردن نرم افزار و سرویس‌هاپدید آمدند. امکاناتی به وجود آمدند که همه توسعه دهنگان را به جهت پایداری نرم افزار‌های خود به سمت و سوی ابزار‌هایی همچون Docker و Kubernetes هدایت کردند. یکی از مهمترین مزیت‌های استفاده از چنین ابزار‌هایی پایدار شدن سرویس‌ها و نرم افزار‌ها است و با ایجاد Transparency چه از دیدگاه توسعه دهنده و چه از دیدگاه کاربر اعتماد و تمایل کاربران به استفاده از نرم افزار‌ها نیز افزایش یافته است. همان طور که در مقالات ارائه شده قبلی اشاره شد ابزارهای container engine یا container run time در معماری مایکروسرویس، نرم افزار‌ها و سرویس‌ها را به صورت container base آپ می‌کنند و همین کانتینری شدن سرویس‌ها کمک شایانی به راه اندازی پلتفرم‌ها و نرم افزار‌ها کرده است. با زیاد شدن container ‌ها به جهت مدیریت و افزوده شدن ویژگیهای جدید ابزار‌هایی به نام orchestrator به جود آمدند. در حقیقت orchestrator ‌ها ابزار‌های پیشرفته ای هستند که به جهت ایجاد کلاسترینگ در مدیریت container ‌ها به وجود آمدند.

با یک مثال اهمیت Orchestration را مورد بررسی قرار می‌دهیم.

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

-1دیتابیس

-2ویپ

-3پیام رسان

هر کدام از این قسمت‌ها به صورت image‌هایی توسط توسعه دهنده مربوط به خود توسعه داده شده است. به طوری که برای آپ شدن  این نرم افزار لازم است که سه image مربوط به این نرم افزار RUN و یا Deploy شوند تا نتیجه آن بالا آمدن (UP شدن ) نرم افزار‌هایی هم چون تلگرام باشد. سوالی که به وجود می‌آید این است که چه طور می‌توان با Deploy کردن سه image نرم افزار پر ترافیکی همچون تلگرام را هندل کرد. قطعا به این شکل نیست. با توجه به وجود آمدن container engine ‌های مختلف می‌توان هر image مربوط به چنین نرم افزار‌هایی را می‌توان به دفعات مختلف Deploy کرد، به عبارتی دیگر می‌توان از روی یک image تعداد زیادی container  یا instance ‌های مختلفی به وجود آورد. Image‌های container base این قابلیت را دارند که کانتینر‌های مختلفی از آنها بتوان Deploy کرد. با توجه به مثال ارائه شده می‌توان از یک image توسعه داده شده داکری صد‌های کانتیر به وجود آورد. صد‌های کانتینر دیتابیس

می‌توان برای ویپ نرم‌افزار صدها کانتینر از image مربوط به ویپ نرم افزار Deploy کرد و همین طور برای component پیام رسان چنین نرم افزارهایی می‌توان صد‌ها کانتیر به وجود آورد. نرم‌افزاری با 300 کانتینر از سه  imageتوسعه داده شده. با توجه به مثال ارائه شده به سناریو‌های عملیاتی نزدیک تر شدیم. چنین نرم‌افزاری که در سراسر دنیا کاربران زیادی دارد و به سبب کاربران خود ترافیک زیادی را می‌بایست هندل کند، قطعا می‌توان app‌هایی با چنین scale ‌هایی را با بیش از 300 کانتینتر هندل کرد. به عبارتی دیگر در چنین شرایط ترافیک component ‌های مختلف نرم افزا بین کانتیر‌های مختلف تقسیم می‌شوند و این روند کمک به هندل کردن نرم افزار‌ها می‌کند. با توجه به مثال ارائه شده در زمان افزایش کانتینر و ترافیک، این کانتینر‌ها دارای پیچیدگی‌هایی می‌شوند. مثلا این 300 کانتینر به چه صورت مدیریت می‌شوند؟ ترافیک به چه صورت بین آنها پخش شود؟ در صورتی که به هر دلیل هر یک از کانتینتر‌ها Down شود به چه صورت کانتینر‌های جدید متولد شود؟ و... اینجاست که اهمیت استفاده از ابزارهای Orchestration  بیش از بیش محسوس می‌شود. ابزار‌های Orchestration با توجه به الگوریتم‌ها و سازو کار‌های تعیین شده به صورت قدرتمند می‌توانند این کانتیئر‌ها را مدیریت کنند. تعدد کاننتینر‌ها اهمیت و نیاز به ساز و کار کلاسترینگ را طلب می‌کند که دقیقا بحث مربوط به کلاستر شدن این کانتینر با Orchestration ‌های محقق می‌شود. با کمک ابزار‌های Orchestration می‌توان فضایی یکپارچه به صورت Cluster مهیا کرد که مدیریت کانتینر و پایدار بودن APP را بتوان تضمین کرد. به عبارتی دیگر می‌توان Orchestration را این گونه تعریف کرد که فضایی پایدار از صد‌ها و هزاران node مختلف container در سرار دنیاست که به صورت کلاستر APP‌ها را Deploy می‌کنند.

کلاسترینگ برای container‌ها توسطorchestrator ‌ها محقق می‌شود که به لحاظ نرم‌افزاری می‌توان نود‌های orchestrator را به 2 گروه تقسیم کرد.

گروه اول نود‌های MASTER یا MANAGER

در Orchestrator‌های مختلف همیشه نود‌ها و یا سرور‌هایی وجود دارند که اصطلاحا به آن‌ها Master گفته می‌شود.

همیشه نود‌های MASTER یا MANAGER بحث مدیریت کردن کلاسترینگ را بر عهده دارند، MASTER ‌ها مشخص می‌کنند که کانتینر‌ها روی کدام یک از نود‌های کلاستر متولد شوند و همیشه نود‌هایی که روی آنها کانتینر ایجاد شده را مدیریت و مانینتور می‌کنند. MASTER می‌تواند یک نود یا سرور باشد و یا بر حسب نیاز می‌تواند خود و اجزایش در کلاستری به تعداد فرد وجود داشته باشد، به عنوان مثال می‌توانیم کلاستری با 9 نود Master داشته باشیم، می‌توانیم کلاستری با 99 نود MASTER داشته باشیم، به طوری که کم تر از نصف سرور‌های‌ MASTER اگر DOWN شوند هنوز کلاستر به کار خود ادامه می‌دهد. در کلاستری که 3 نود و یا سرور MASTER دارد با Down  شدن یکی از Master‌ها اختلالی در ادامه روند کاری کلاستر به وجود نخواهد آمد. در کلاستری که 9 سرور و یا نود MASTER دارد با DOWN شدن 4 نود MASTER کلاستر همچنان به کار خود ادامه می‌دهد و به عبارتی دیگر، در کلاستری که بر پایه orchestration وجود دارد تا زمانی که کم تر از نصف تعداد کل نود‌ها سرور‌ها Down شوند کلاستر به کار خود ادامه می‌دهد. اما در صورتی که تعداد نصف و بیشتر سرور‌های master به هر دلیلی fail شوند، دیگر کلاستر از ادامه سرویس دهی باز خواهند ماند.

گروه دوم نود‌های Worker

orchestrator ‌ها در محیط‌های عملیاتی همیشه کانتینر‌های مربوط به APP ‌های Deploy شده را در نود‌های Worker متولد می‌کنند، سرور‌ها و یا نود‌های Worker همیشه در حال listen کردن Master  نود‌ها هستند.

ورکر نود‌ها به محض دریافت دستور از نود‌های Master کانتینر‌ها را ایجاد خواهند کرد. ورکر نود‌ها همیشه به صورت دوره‌ای به Master نود‌ها گزارش از وضعیت کانتینر‌ها خواهند داد و هر جا Master متوجه Down شدن کانتینر و یا نود ورکری شود سریعا دستور رفع مشکل و یا نهایتا دستور ایجاد شدن مجدد کانتینر‌ها روی نود‌های دیگر را خواهد داد.

کارکرد کلی orchestrator ‌های مختلف به صورت مشخص شده و واحد است. اما هر Orchestrator می‌تواند قواعد و قابلیت‌ها و ساختار خاص خود را داشته باشد، با همه این توضیحات می‌توان گفت که اهداف همه Orchestrator ‌های یکی است و آن هم پایداری بیشتر APP و سرویس‌ها است. از قابلیت‌های مهم برخی ازOrchestrator ‌ها این است که قابلیت توسعه دارند به نحوی که می‌توان در مدل ارائه شده کلودی PaaS از آنها استفاده کرد. در حقیقت سرویس PaaS از پیچیدگی کار کردن با Orchestrator ‌ها می‌کاهد و می‌توان با توسعه Orchestration به یک سرویس PaaS پایدار و user friendly رسید که به کاربران مختلف سرویس ارائه کرد.

دو Orchestration معروف در سطح دنی مورد استفاده توسعه دهنگان وجود دارد که Docker swarm و Kubernetes می‌باشند و در مقالات جداگانه ای به آنها خواهیم پرداخت.

نتیجه

Orchestration  یک ابزار بسیار مهم و پیشرفته است که توسط آن می‌توان کلاستری از نود‌های مختلف ایجاد و مدیریت کانتینر‌ها را برعهده گرفت. هر Orchestrator با توجه به ساختار و ساز و کار‌های خود به جهت مدیریت بهتر کانتینر‌ها، ویژگی‌ها و قایلیت‌های خاص خود را دارد که از Docker swarm و Kubernetes می‌توان به عنوان دو Orchestrator معروف و پر کاربرد یاد کرد.