علت اهمیت Kubernetes-native و بررسی ضرورت راهکار Native Backup – قسمت اول

Uptime برنامه کاربردی است و Kubernetes به‌ شیوه‌ای عالی با استفاده از راهکار Native Backup به آن دست یافته است. با این حال، اگر تمام داده‌های سازمان خود را از دست بدهیم، چه می‌شود؟

این مقاله دقیقاً توضیح می‌دهد که چرا به راهکارهای بک‌آپ Kubernetes-native نیاز است و بسیاری از عواملی را بررسی می‌کنند که باعث می‌شوند به‌کارگیری این راهکار ضروری باشد. الگوهای مختلف پیاده‌سازی تا شیوه‌های معروف به DevOps، از جمله این عوامل هستند. در ادامه توضیح داده می‌شود که چگونه راهکار Native Backup و Backupگیری Cloud-native از استرس کاربران می‌کاهد و پهنای باند بیشتری برای نوآوری در اختیار آن‌ها قرار می‌دهد، شکاف‌های حفاظت از داده‌ها را پر می‌کند و اطمینان حاصل می‌کند حتی زمانی که برنامه‌های کاربردی از چندین سرویس داده مختلف استفاده می‌کنند، کاربر در وضعیت مناسبی باشد.

اهمیت راهکار Native Backup

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

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

قرار نیست دوباره به کابوس‌های شبانه رو آوریم، اما نمی‌توان از این واقعیت فرار کرد که Kubernetes دنیایی کاملاً جدید است و به دلایلی خطر از دست رفتن داده‌ها در Cloud بیشتر است. یکی از علت‌های اصلی این موضوع، پیچیده بودن Kubernetes است؛ هنوز برای بسیاری از افراد ناآشناست و مسئولیت‌های مدیریتی آن چندان متمرکز نیستند. به همین علت احتمال وقوع حوادث بیشتر می‌شود.

راهکار Kubernetes چیست و چه مزایایی دارد

ویدیوهای بیشتر درباره ی راهکار Kubernetes

ابزارهایی عالی برای زیرساخت‌های مبتنی بر مجازی‌سازی در دسترس هستند، اما برای محیط‌های غیر مجازی به مجموعه جدیدی از ابزارها نیاز خواهد بود. شاید ترجیح بدهیم به هریک از تیم‌های برنامه کاربردی مسئولیتی اختصاص دهیم، اما تقسیم کردن مسئولیت Backupگیری هم ریسک را افزایش می‌دهد و هم‌زمان بازیابی را بالا می‌برد. البته زمان پول است؛ در این مورد، میانگین هزینه به ازای هر ساعت خرابی برنامه کاربردی مهم معادل نیم میلیون دلار است.

بنابراین، با راهکار Native Backup و Backupگیری Cloud-native، وضعیت بسیار بهتر خواهد بود. برای Backupگیری و محافظت از برنامه‌های کاربردی مبتنی بر Kubernetes، به یک راهکار Backupگیری Kubernetes-native نیاز است.

برخورد با دنیایی متفاوت

نیازی نیست کسی یادآوری کند که Kubernetes یک تحولگر است؛ این پلتفرم تغییراتی بنیادین و فراگیر ایجاد می‌کند و محبوبیت زیادی دارد، روشی متفاوت از معماری است که لایه انتزاعی را جابجا کرده و برای بهبود اجرای جریان‌های کاری، انعطاف‌پذیری را بالا برده است. بین پلتفرم Kubernetes و تقریباً تمام زیرساخت‌های محاسباتی پیش از آن، تفاوت‎‌هایی اساسی وجود دارد.

با این حال، آنچه تغییر نکرده است، الزامات مربوط به Backupگیری است. در هر پلتفرم، نه فقط Kubernetes، مدیر باید برنامه‌ای برای Backupگیری داشته باشد.

بیشتر بخوانید: استفاده از مزایای راهکار Kubernetes برای افزایش بهره ­وری سازمان

یکی از قوانینی که همواره می‌تواند هر سناریوی خرابی را به‌طور مؤثر برطرف کند، «Backupگیری 3-2-1» نام دارد. این رویکرد کمک می‌کند به دو سؤال مهم پاسخ دهیم: چند فایل Backup باید داشته باشیم و کجا باید آن‌ها را ذخیره کنیم؟ قانون Backupگیری 1-2-3 پاسخ‌های زیر را ارائه می‌دهد:

» 3: کاربر حداقل سه نسخه از داده‌های خود را داشته باشد.

» 2: نسخه‌ها را در دو رسانه مختلف ذخیره کند.

» 1: نسخه‌ای از Backup در خارج از سایت داشته باشد.

در ابتدا باید به این واقعیت اشاره کرد که برنامه‌های کاربردی Containerشده را بر سرورها یا ماشین‌های مجازی VMها Map نمی‌کنیم. در مقایسه با ماشین‌های مجازی، Container فقط نیازمند سیستم عامل، برنامه‌ها و Libraryهای پشتیبان و منابع سیستم برای اجرای برنامه‌ای خاص است.

با توجه به این موضوع، می‌توان دو یا سه برابر تعداد برنامه کاربردی‌‌ بر یک سرور واحد در VM را در Container قرار داد. Containerها همچنین به کاربر این امکان را می‌دهند که یک محیط عملیاتی قابل حمل و متناسب، برای توسعه، سنجش و پیاده‌سازی ایجاد کند. Kubernetes اجزای برنامه کاربردی را با استفاده از Policy مکان‌یابی خود در تمام سرورها توزیع می‌کند تا عملکرد بهبود را بخشد و تحمل خطای سرویس‌ها را بالا برد.

اگر سیستم مدیریت داده کاربر قدیمی باشد و با چنین شرایطی مواجه شود، احتمالاً شکست خواهد خورد. در چنین شرایطی کاربر ممکن است بتواند Backup بگیرد، اما اگر ابزارهای مورداستفاده او به‌صورت Cloud-native طراحی نشده باشند، وقتی نوبت به بازیابی می‌رسد، همه‌چیز سخت خواهد شد.

این نکته را هم باید افزود که برنامه‌های کاربردی Cloud-native از طبیعت پویای محیط خود بهره می‌برند. برای بهبود تعدیل بار، می‌توان برای Containerها فوراً دوباره برنامه‌ریزی کرد یا تعداد آن‌ها را در Nodeهای مختلف افزایش یا کاهش داد. پیاده‌سازی‌های جدید همواره صورت می‌گیرد و دائماً اجزایی اضافه یا حذف می‌‌شوند.

به‌عبارت دیگر، برنامه کاربردی دائماً در حال تغییر است. کاربر به یک راهکار Backup نیاز خواهد داشت که با الگوهای معماری Cloud-native آشنا باشد؛ چنین راهکاری باید بدون ثبات در آدرس‌های IP همچنان قابل استفاده و همچون برنامه کاربردی Cloud-native Kubernets با تغییرات سازگار باشد.

اگر از راهکارهای قدیمی Backupای که در محیط سرورها و VMها عملکرد خوبی دارند، در Kubernetes استفاده کنیم، مانند این است که ماهی‌های آب شیرین را به اقیانوس شور بیندازیم. برای برآوردن الزاماتی مانند کشف پویای برنامه کاربردی، Backupگیری در لحظه، بازیابی یکپارچه‌سازی پلتفرم، و در برگرفتن تمام زمینه‌های اجرای برنامه کاربردی، فقط به Backupگیری Kubernetes-native نیاز خواهد بود.

بیشتر بخوانید: شباهت‌های بین مجازی‌سازی و کانتینرهای Kubernetes

یکی از نکات مکمل در خصوص این پیشرفت و تکامل این است که سیستم‌های فیزیکی برای محافظت از داده‌ها و سیستم عامل به رویکردی مبتنی بر Agent نیاز داشتند. هنگامی که مجازی‌سازی به میان آمد، بسیاری از همان Backup Vendorها، Agentهای خود را به همان صورت به دنیای مجازی انتقال دادند.

این امر باعث ایجاد سرباری بر ماشین‌های مجازی برای انجام Backupگیری شد، زیرا با آن‌ها همچون‌هایی ماشین‌هایی فیزیکی رفتار می‌‌شد که صرفاً مکان‌شان عوض شده است.

روشن شد که بهترین راه برای محافظت از این بارهای کاری مجازی، از طریق API و در لایه مجازی‌سازی است. با این شیوه، امکان ایجاد Backupهای سازگار با برنامه کاربردی به روشی سریع و کارآمد و بدون تأثیر بر عملکرد ماشین مجازی فراهم شد.

به عبارت ساده‌تر، همان ماجرا این بار در جهان Kubernetes رقم خورد. به‌طو نظری، امکان بهره‌گیری از فرآیند مجازی‌سازی یا Backupگیری و فیزیکی و محافظت از محیط و داده‌های Kubernetes وجود دارد. برخی از این شیوه‌ها، و نه همه آن‌ها، فرآیند بازیابی را دشوار می‌کنند.

بسیاری فلسفه DevOps را همچون نماد بی‌نهایت در نظر می‌گیرند، همچون یک «8» افقی که حلقه‌ای بی‌انتهاست و از چپ به راست، راست به چپ و به همین ترتیب در حرکت است. همچنین می‌توان آن را چیزی شبیه پیست مسابقه در نظر گرفت، چراکه Devops به‌طور کلی با چرخه‌های پرسرعت توسعه برنامه کاربردی سروکار دارد.

وقتی درباره تصویرسازی Devops با استفاده از نماد بی‌نهایت صحبت می‌کنیم، معمولاً توسعه را در سمت چپ و عملیات را در سمت راست این نماد در نظر می‌گیریم. فلسفه DevOps، زمانی که در دنیای Kubernetes استفاده می‌شود، نیازها و الزامات توسعه‌دهندگان و عملیات‌ها را به گونه‌ای متفاوت با گذشته گرد هم می‌آورد. در سمت چپ این حلقه رویدادهای بیشتری اتفاق می‌افتد و از این رو از اصطلاح «Shift Left» برای آن استفاده می‌شود.

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

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

مقاله های مرتبط: