آیا پایگاه های داده در Kubernetes زندگی می کنند؟

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

اتفاقاً با ظهور کانتینرها و این همه غذاهای دوست داشتنی با docker و k8s شرطی، بحث "برای" و "علیه" استفاده از قابلیت های جدید در زمینه های مختلف باطن آغاز شد. (بیایید از قبل رزرو کنیم که اگرچه Kubernetes اغلب به عنوان یک ارکستر در این بحث نشان داده می شود، انتخاب این ابزار خاص اهمیت اساسی ندارد. در عوض، می توانید هر ابزار دیگری را که برای شما راحت و آشنا به نظر می رسد جایگزین کنید. .)

و به نظر می رسد، این یک اختلاف ساده بین دو روی یک سکه است. به اندازه تقابل ابدی بین Win و Linux که در آن افراد کافی جایی در میانه وجود دارند، بی معنی و بی رحم است. اما در مورد کانتینرسازی، همه چیز به این سادگی نیست. معمولاً در چنین اختلافاتی طرف درستی وجود ندارد، اما در مورد ظروف «استفاده» یا «عدم استفاده» برای ذخیره پایگاه داده، همه چیز وارونه می شود. زیرا به یک معنا هم موافقان و هم مخالفان این رویکرد حق دارند.

سمت روشن

استدلال لایت ساید را می توان به طور خلاصه در یک عبارت توصیف کرد: "سلام، 2k19 خارج از پنجره است!" البته به نظر پوپولیسم می‌آید، اما اگر به جزئیات بپردازید، مزایای خود را دارد. حالا بیایید آنها را مرتب کنیم.

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

درست است، داده ها. قلب هر پروژه داده‌های آن است: این می‌تواند یک DBMS معمولی باشد - MySQL، Postgre، MongoDB، یا ذخیره‌سازی مورد استفاده برای جستجو (ElasticSearch)، ذخیره‌سازی کلید-مقدار برای ذخیره‌سازی حافظه پنهان - به عنوان مثال، redis، و غیره. در حال حاضر ما نیستیم. هنگامی که پایگاه داده به دلیل پرس و جوهای نوشته شده ضعیف از کار می افتد، در مورد گزینه های اجرای backend کج صحبت خواهیم کرد، و در عوض در مورد اطمینان از تحمل خطا در این پایگاه داده تحت بار مشتری صحبت خواهیم کرد. از این گذشته، وقتی برنامه خود را کانتینری می کنیم و به آن اجازه می دهیم تا برای پردازش هر تعداد درخواست ورودی آزادانه مقیاس شود، این به طور طبیعی بار روی پایگاه داده را افزایش می دهد.

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

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

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

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

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

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

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

Containerization و در واقع توپولوژی فیزیکی توزیع شده پایگاه داده پروژه شما به جلوگیری از چنین لحظات اعتبار سنجی کمک می کند. به یک تازه کار اعتماد ندارید؟ خوب! بیایید به او خوشه خود را بدهیم تا با آن کار کند و پایگاه داده را از خوشه های دیگر جدا کنیم - همگام سازی فقط با فشار دستی و چرخش همزمان دو کلید (یکی برای سرپرست تیم، دیگری برای مدیر). و همه خوشحال هستند.

و اکنون زمان تبدیل شدن به مخالفان خوشه‌بندی پایگاه داده است.

سمت تاریک

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

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

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

به طور کلی، این عقیده وجود دارد که مافیای داکر/مکعب به طرز احمقانه ای در حال خرد کردن مشتریانی است که این مسائل زیرساختی را برون سپاری می کنند. از این گذشته، برای کار با خوشه ها، به مهندسانی نیاز داریم که این توانایی را داشته باشند و به طور کلی معماری راه حل اجرا شده را درک کنند. ما قبلاً مورد خود را با انتشارات Republic شرح دادیم - در آنجا تیم مشتری را آموزش دادیم تا در واقعیت های Kubernetis کار کنند و همه راضی بودند. و شایسته بود اغلب، «اجراکننده‌های» k8s زیرساخت مشتری را گروگان می‌گیرند - زیرا اکنون فقط آنها می‌دانند که همه چیز در آنجا چگونه کار می‌کند؛ هیچ متخصصی در سمت مشتری وجود ندارد.

حال تصور کنید که از این طریق نه تنها بخش وب سرور، بلکه نگهداری پایگاه داده را نیز برون سپاری می کنیم. گفتیم که BD قلب است و از دست دادن قلب برای هر موجود زنده ای کشنده است. به طور خلاصه، چشم انداز بهترین نیست. بنابراین، به جای هیپ Kubernetis، بسیاری از پروژه‌ها به سادگی نباید با تعرفه معمولی AWS زحمت بکشند، که تمام مشکلات مربوط به بارگذاری روی سایت/پروژه آنها را حل می‌کند. اما AWS دیگر مد نیست و خودنمایی ها ارزش بیشتری از پول دارند - متاسفانه در محیط IT نیز.

خوب. شاید این پروژه واقعاً به خوشه‌بندی نیاز داشته باشد، اما اگر همه چیز با برنامه‌های بدون حالت مشخص باشد، چگونه می‌توانیم اتصال شبکه مناسب را برای یک پایگاه داده خوشه‌ای سازماندهی کنیم؟

اگر ما در مورد یک راه حل مهندسی یکپارچه صحبت می کنیم، یعنی همان چیزی که انتقال به k8 است، پس سردرد اصلی ما تکرار داده ها در یک پایگاه داده خوشه ای است. برخی از DBMS ها در ابتدا کاملاً به توزیع داده ها بین نمونه های جداگانه خود وفادار هستند. بسیاری دیگر چندان استقبال نمی کنند. و اغلب بحث اصلی در انتخاب یک DBMS برای پروژه ما توانایی تکرار با حداقل منابع و هزینه های مهندسی نیست. به خصوص اگر این پروژه در ابتدا به عنوان یک میکروسرویس برنامه ریزی نشده باشد، بلکه به سادگی در این مسیر تکامل یافته است.

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

ادامه مبحث فایل سیستم های مجازی: Docker Volume متاسفانه بدون مشکل نیست. به طور کلی، در موردی مانند ذخیره سازی داده های قابل اعتماد طولانی مدت، من می خواهم به ساده ترین طرح های فنی بسنده کنم. و افزودن یک لایه انتزاعی جدید از FS ظرف به FS میزبان والد به خودی خود یک خطر است. اما زمانی که عملکرد سیستم پشتیبانی کانتینری با مشکلی در انتقال داده ها بین این لایه ها روبرو می شود، واقعاً یک فاجعه است. در حال حاضر، به نظر می رسد اکثر مشکلات شناخته شده برای بشریت مترقی ریشه کن شده است. اما می‌دانید، هر چه مکانیزم پیچیده‌تر باشد، راحت‌تر می‌شکند.

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

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

به جای خروجی

اگر منتظر یک نتیجه روشن هستید "برای مجازی سازی پایگاه داده یا نه"، ما شما را ناامید خواهیم کرد: اینجا نخواهد بود. زیرا هنگام ایجاد هر راه حل زیرساختی، نه باید مد و پیشرفت، بلکه قبل از هر چیز با عقل سلیم هدایت شود.

پروژه هایی وجود دارند که اصول و ابزارهایی که با Kubernetis ارائه می شوند کاملاً مطابقت دارند و در چنین پروژه هایی حداقل در منطقه باطن آرامش وجود دارد. و پروژه‌هایی هستند که نیازی به کانتینری‌سازی ندارند، بلکه به یک زیرساخت سرور معمولی نیاز دارند، زیرا اساساً نمی‌توانند به مدل خوشه‌ای میکروسرویس تغییر مقیاس دهند، زیرا سقوط خواهند کرد.

منبع: www.habr.com