در قسمت اول این مقاله به بررسی و مقایسه‌ی برخی از جوانب پیاده‌سازی کانتینرها برروی VMها و به صورت Bare Metal همچون امنیت، ناکارآمدی محدوده‌ی حفاظتی Containerها، عواقب پیکربندی اشتباه برروی یک هاست فیزیکی، استفاده‌ی بهینه از Trendهای پیشرفته و … پرداختیم. در قسمت دوم این مقاله به ابعاد دیگری از پیاده‌سازی Containerها از جمله دسترس‌پذیری، مدیریت منابع، ماندگاری داده‌ها، عملکرد و مقیاس‌پذیری خواهیم پرداخت.
دسترس‌پذیری در کانتینرها
برنامه‌های کاربردی که از معماری بی‌نقص همراه با Micro-Serviceها بهره می‌برند، می‌توانند به یک سیستم هماهنگ کننده Container همچون Kubernetes برای مدیریت دسترس‌پذیری اتکا کنند. اما اغلب برنامه‌های کاربردی Containerizeشده به خوبی معماری آنها بررسی و ایجاد نگردیده است: شاید برنامه‌های کاربردی Monolithic را به صورت چند جزء کوچک تقسیم شده، باز طراحی کنند و یا ممکن است بخش‌هایی از برنامه کاربردی را به به‌صورت جزئی با تعدادی Micro-Service و بخش‌های دیگر را بر پایه N-Tier باز طراحی کنند.
چنین برنامه‌های کاربردی، حداقل به‌صورت تکی به زیرساخت زیرین برای دسترس‌پذیری اتکا می‌کنند. تکنولوژی‌های اثبات‌شده از VMware، همچون VMware vSphere vMotion، VMware vSphere High Availability و VMware vSphere Distributed Resources Scheduler یا به اختصار DRS، برای حفظ دسترس‌پذیری حیاتی هستند.
حتی یک برنامه‌ی کاربردی که معماری بی‌نقصی داشته و از Micro-Serviceها برای کنترل کردن دسترس‌پذیری خود بهره‌مند باشد نیز همچنان می‌تواند از زیرساخت Software-Defined بهره ببرد. برای مثال، Redis به‌عنوان یک دیتابیس همسان‌سازی‌شده‌ی در سطح حافظه(In-Memory)، خرابی‌های زیرساختی را متحمل می شود؛ یک نمونهRedis تازه راه‌اندازی می‌شود تا جایگزین نمونه خراب‌شده بشود. اما با شروع به کار نمونه جدید، آن نمونه داده‌ها را از نمونه‌های دیگرRedis همسان‌سازی می‌کند تا زمانی که کامل بازیابی شود. با این‌حال انتقال داده‌ها برای همسان‌سازی هزینه‌ای به‌همراه دارد؛ این امر عملکرد کلی کلاستر Redis را کاهش می‌دهد. رویکرد دیگری که مؤثرتر است، استفاده از vMotion برای انتقال نمونه اصلیRedis به‌منظور جلوگیری از کاهش عملکرد می‌باشد.
جهت مشاوره رایگان و یا راه اندازی زیرساخت مجازی سازی دیتاسنتر با کارشناسان شرکت APK تماس بگیرید. |
بهبود مدیریت منابع با Container
Kubernetes برای به اشتراک‌گذاری یک کلاستر میان تیم‌هایی که بارهای کاری متفاوتی را اجرا می‌کنند، مکانیزم‌های کنترل کیفیت سرویس یا به اختصار QoS قدرتمندی را ارائه می‌دهد. اجرای کلاسترهای Kubernetes برروی vSphere، مکانیزم‌های QoS آن را تقویت می‌کند، خصوصاً وقتی‌که از ایزوله‌سازی قدرتمند بارِ کاری استفاده گردد. برنامه‌ریزی پیشرفته و مدیریت پویای منابع vSphere، به بازپس‌گیری و اشتراک‌گزاری منابع استفاده‌نشده میان تیم‌ها یا کلاسترهای Kubernetes کمک می‌کند.
قابلیت‌های مدیریت منابع vSphere شامل استقرار اولیه هوشمند، متعادل‌سازی پویا، Poolهای منابع، Shareها، Reservationها، محدودیت‌ها و Over-Commitment امن می‌باشد. تمام این قابلیت‌ها به کاربر اجازه می‌دهند که بارهای کاری قدیمی و Containerizeشده را بر روی زیرساخت‌های رایج اجرا کند و در عین حال از عملکرد قابل‌قبول اطمینان حاصل نموده و از تداخل میان بارهای کاری جلوگیری به‌عمل آورد.
برای کلاسترهای Kubernetesی که برروی vSphere درحال اجرا باشند، تکنولوژی‌های VMware همچون vMotion و DRS با متعادل‌سازی دوباره‌‍ی کلاسترها بدون تداخل در بارهای کاری، بهره‌وری سخت‌افزاری را به حداکثر می‌رسانند.
ماندگاری داده‌ها
علی‌رغم اینکه بسیاری از برنامه‌های کاربردی Containerizeشده Stateless هستند، انتقال برنامه‌های کاربردی به Containerها نیازمند الزاماتی می‌باشد تا برنامه‌های کاربردی Stateful برروی کانتینرها قرار گیرد و به‌منظور ماندگاری داده‌ها میان هاست‌ها، برای آنها Shared-Nothing Storage فراهم شود.
مدیریت تجهیزات ذخیره‌سازی فیزیکی طاقت‌فرسا است؛ سختی فرآیندهای دستی اغلب توسط بارهای کاری مختص به برنامه‌های کاربردی تشدید می‌شود. اضافه‌نمودن SSDهای جدید به‌منظور گسترش ظرفیت کارآمد نیست. تکنولوژی‌ها و فرآیندهای مختلف میان زیرساخت، می‌تواند منجر به پیچیدگی شرایط گردد و اختصاص‌دهی مستقل سخت‌افزار فیزیکی به یک برنامه‌ی کاربردی از لحاظ اقتصادی به‌صرفه نیست.
یک مدل واحد Software-Driven که فارغ از Containerizeشده یا نشده بودن برنامه‌های کاربردی با آنها سازگار باشد، مدیریت Storage، عیب‌یابی عملیات‌ها، گسترش ظرفیت و عملیات‌های Storage همچون پشتیبان‌گیری و Disaster Recovery را بسیار تسهیل می‌کند. VMware vSan با ارائه‌ی یک Storage توزیع‌شده و Shared-Nothing، عملیات‌های Storage را تسهیل نموده و هر دو بارهای کاری قدیمی و Cloud Native را برروی یک زیرساخت Storage مشابه، تجمیع می‌کند.
بررسی عملکرد
در VMware ESXi برنامه‌ریزی پردازنده به Hypervisor این توانایی را می‌دهد که عملکرد کلی بار‌کاری را برابر یا بیشتر از سیستم‌های لینوکسی که برروی سخت‌افزار فیزیکی درحال اجرا هستند، ارائه دهد.
مقاله‌‍‌‌ی تطبیقی از جانب VMware مشخص می‌نماید که برنامه‌های کاربردی سازمانی تحت وب می‌توانند در Docker Containerها برروی vSphere 6.5 با عملکردی بهتر از Docker Containerها به صورت Bare Metal اجرا شوند، عمدتاً به این دلیل که بهینهسازی در برنامه‌ریز پردازنده vSphere برای زیرساخت‌های Non-Uniform Memory Access یا به اختصار NUMA، این طرزفکر که اجرای Containerها برروی VMها سبب کاهش عملکرد می‌گردد، را باطل می‌کند. در برنامه‌ریزی VMها برروی NUMA Nodeها که محل استقرار حافظه آنها می‌باشد، vSphere بهتر عمل می‌کند. از طرف دیگر، لینوکس سعی می‌کند بهره‌وری از پردازنده را به حداکثر برساند. این امر بدین معنی است که فرآیندها ممکن است روی NUMA Nodeها متفاوت از جایگاه قرارگیری حافظه‌شان برنامه‌ریزی شوند که خود مسبب کندی دسترسی به حافظه و کاهش عملکرد می‌گردد.
یک تجزیه‌وتحلیل بارهای کاری Big Data برروی vSphere نیز همین نتایج را نشان می‌دهد. مجازی‌سازی می‌تواند ایزوله‌سازی عملکرد بهتری نسبت به اجرای Containerها در لینوکس ارائه دهد؛ خصوصاً در شرایط Noisy Neighbor. نتایج یک تحقیقات تطبیقی برروی Containerها و VMهای در مقیاس‌های گوناگون نشان می‌دهد که برنامه‌های کاربردی هم‌نشین (Co-Located) می‌توانند در عملکرد تداخل ایجاد کنند و میزان این تداخل در انواع خاصی از بارهای کاری بیشتر از باقی است. به‌دلیل شیوه‌ی عملکرد Linux Kernel می‌توان از جانب Containerهایی که منابع یا اجزای Kernel مشابه دارند نیز با تداخل Cross-Container مواجه شد. اشتباه است که اینطور فرض کنیم که “Kernel تمام منابع زیرین را در یک Container Granularity، کاملاً ایزوله‌سازی” قرار می دهد.
کلاسترهای Kubernetes نیز از مزایای مشابهی حین اجرا برروی vSphere بهره می‌برند. بعید است که اجرای Kubernetes برروی Bare Metal بتواند عملکرد بهتری نسبت به Kubernetes برروی vSphere داشته باشد که از الگوریتم‌های پیشرفته‌ی برنامه‌ریزی برای بهینهسازی تمام بارهای کاری، از جمله آن دسته که از Containerها استفاده می‌کنند، بهره می‌برد. کمپانی‌هایی که Kubernetes را برروی سخت‌افزار فیزیکی اجرا می‌کنند برای Scale نمودن و اداره‌ی مؤثر زیرساخت، با مشکل مواجه خواهند شد. برخلاف سخت‌افزار فیزیکی، اجرای Kubernetes برروی vSphere از سال‌ها تجربه بهره می‌برد تا در بهینهسازی عملکرد کلاسترهای بزرگ و بارهای کاری متناقض، به‌خوبی عمل کند.
مقیاس‌پذیری
Hypervisorها از ابتدا برای حل مشکل سختی کار با سخت‌افزار فیزیکی ساخته شده بودند؛ سختی که از مشکلات مدیریتی وقت‌گیر و بهره‌وری کم و پرهزینه شروع شده و به دشواری Scale نمودن سخت‌افزارها برای یک محیط توسعه‌دهنده یا بارِ کاری درحال گسترش برنامه‌ی کاربردی مربوطه ختم می‌شوند. با بهینهسازی بهره‌وری، مجازی‌سازی به کاربر اجازه می‌دهد که هزینه‌های سخت‌افزار فیزیکی را کاهش داده و درعین‌حال مقیاس‌پذیری را بهبود بخشد.
اگر تیم فناوری اطلاعات یک سرور Bare-Metal با یک Container Runtime پیاده‌سازی کنند که توسعه‌دهندگان بتوانند به‌وسیله‌ی آن Containerهای خود را Push کنند، Scale کردن سیستم سخت و زمان‌بر است. در شرایط مذکور اضافه نمودن یک سرور Bare-Metal دیگر، نصب یک Container Runtime برروی آن، اتصال دستی سرور به شبکه و اتصال Runtime به یک موتور تنظیم Container، اجباری خواهد بود.
برخلاف این شرایط، با یک Hypervisor می‌توان یک سرور Bare-Metal را در عرض چند دقیقه به دامین Container متصل نمود. آسودگی مقیاس‌پذیری که مجازی‌سازی به‌همراه دارد، یکی از دلایل بسیاری است که ارائه‌دهندگان بزرگ خدمات ابری از Hypervisorها برای اجرای خدمات Container خود استفاده می‌نمایند. برای مثال، هنگام ایجاد یک کلاستر Kubernetes برروی Google Container Engine یا Amazon Elastic Container Service، ارائه‌دهنده یک یا دو VM دیگر اجرا می‌نماید که مدت‌زمان آماده سازی در VMها بسیار سریع‌تر از Bare-Metal است.
این موضوع در مقیاس جهانی نیز صدق می‌کند. اگر بخواهیم Kubernetes را در یک دیتاسنتر و به صورت Bare-Metal بسازیم، چطور می‌شود آن را به هزار سایت در سرتاسر دنیا Scale نمود و درعین‌حال امنیت، شبکه، مانیتورینگ و مدیریت متمرکزشده را حفظ نمود؟
برای کلاسترهای بزرگ، استفاده از Kubernetes برروی Bare-Metal می‌تواند پیامدهایی برای بهره‌وری درخصوص Scale به‌دنبال داشته باشد. از Kubernetes 1.10 به‌بعد، پیکربندی‌های منتشرشده‌ی تحت پشتیبانی برای کلاسترها در توضیحات Kubernetes به‌صورت ذیل ذکر شده‌اند:
- بیش از 5 هزار Node موجود نباشد
- در کل بیش از 150 هزار Pod موجود نباشد
- در کل بیش از 300 هزار Container موجود نباشد
- در ازای هر Node بیش از صد Pod موجود نباشد
اگر هر Pod تنها یک Container داشته باشد، که امر غیررایجی نیست، درصورتی که هریک از این Containerها با عملکرد پایین مواجه باشد، منابع استفاده‌نشده‌ای برروی Bare-Metal باقی خواهد ماند. اما با vSphere می‌توان بیش از صد Pod در ازای هر هاست فیزیکی اجرا نمود که مسبب بهبود بهره‌وری از سخت‌افزار زیرین می‌گردد.
ـــــــــــــــــــــــ
مقایسه پیاده‌سازی کانتینر ها برروی VMها و Bare Metal – قسمت اول
مقایسه پیاده‌سازی کانتینر ها برروی VMها و Bare Metal – قسمت دوم
مقایسه پیاده‌سازی کانتینر ها برروی VMها و Bare Metal – قسمت سوم
مقایسه پیاده‌سازی کانتینر ها برروی VMها و Bare Metal – قسمت چهارم (پایانی)
