چگونه PostgreSQL «رایگان» را در یک محیط سازمانی خشن قرار دهیم

بسیاری از مردم با PostgreSQL DBMS آشنا هستند و خود را در نصب های کوچک ثابت کرده است. با این حال، گرایش به منبع باز به طور فزاینده ای واضح شده است، حتی زمانی که صحبت از شرکت های بزرگ و الزامات سازمانی می شود. در این مقاله به شما خواهیم گفت که چگونه Postgres را در یک محیط شرکتی ادغام کنید و تجربه خود را از ایجاد یک سیستم پشتیبان (BSS) برای این پایگاه داده با استفاده از سیستم پشتیبان Commvault به عنوان مثال به اشتراک بگذارید.

PostgreSQL قبلاً ارزش خود را ثابت کرده است - DBMS عالی کار می کند، این DBMS توسط مشاغل دیجیتال مد روز مانند Alibaba و TripAdvisor استفاده می شود، و فقدان هزینه های مجوز آن را جایگزینی وسوسه انگیز برای هیولاهایی مانند MS SQL یا Oracle DB می کند. اما به محض اینکه شروع به فکر کردن درباره PostgreSQL در چشم انداز Enterprise می کنیم، بلافاصله با الزامات سختگیرانه مواجه می شویم: «در مورد تحمل خطای پیکربندی چطور؟ مقاومت در برابر بلایا؟ نظارت جامع کجاست؟ در مورد پشتیبان گیری خودکار چطور؟ در مورد استفاده از کتابخانه های نوار هم به طور مستقیم و هم در حافظه ثانویه چطور؟


از یک طرف، PostgreSQL ابزارهای پشتیبان داخلی مانند DBMS های "بزرگسال" مانند RMAN در Oracle DB یا SAP Database Backup ندارد. از سوی دیگر، تامین‌کنندگان سیستم‌های پشتیبان شرکتی (Veeam، Veritas، Commvault) اگرچه از PostgreSQL پشتیبانی می‌کنند، اما در واقع فقط با یک پیکربندی خاص (معمولاً مستقل) و با مجموعه‌ای از محدودیت‌های مختلف کار می‌کنند.

سیستم‌های پشتیبان‌گیری که مخصوص PostgreSQL طراحی شده‌اند، مانند Barman، Wal-g، pg_probackup، در نصب‌های کوچک DBMS PostgreSQL یا در جاهایی که نیازی به پشتیبان‌گیری سنگین از سایر عناصر چشم‌انداز فناوری اطلاعات نیست، بسیار محبوب هستند. به عنوان مثال، علاوه بر PostgreSQL، زیرساخت ممکن است شامل سرورهای فیزیکی و مجازی، OpenShift، Oracle، MariaDB، Cassandra و غیره باشد. توصیه می شود از همه اینها با یک ابزار مشترک نسخه پشتیبان تهیه کنید. نصب یک راه حل جداگانه به طور انحصاری برای PostgreSQL ایده بدی است: داده ها در جایی روی دیسک کپی می شوند و سپس باید روی نوار حذف شوند. این پشتیبان‌گیری مضاعف، زمان پشتیبان‌گیری را افزایش می‌دهد، و همچنین، مهم‌تر، زمان بازیابی را افزایش می‌دهد.

در یک راه حل سازمانی، پشتیبان گیری از نصب با تعداد معینی گره در یک خوشه اختصاصی انجام می شود. در همان زمان، برای مثال، Commvault فقط می تواند با یک خوشه دو گره کار کند، که در آن Primary و Secondary به شدت به گره های خاصی اختصاص داده می شوند. و فقط پشتیبان گیری از Primary منطقی است، زیرا پشتیبان گیری از Secondary محدودیت های خود را دارد. با توجه به ویژگی های DBMS، یک Dump در Secondary ایجاد نمی شود و بنابراین فقط امکان پشتیبان گیری از فایل باقی می ماند.

برای کاهش خطر خرابی، هنگام ایجاد یک سیستم مقاوم در برابر خطا، یک پیکربندی خوشه "زنده" ایجاد می شود و Primary می تواند به تدریج بین سرورهای مختلف مهاجرت کند. به عنوان مثال، خود نرم افزار Patroni، Primary را بر روی یک گره خوشه ای انتخاب شده به طور تصادفی راه اندازی می کند. IBS راهی برای ردیابی خارج از جعبه ندارد و اگر پیکربندی تغییر کند، فرآیندها خراب می شوند. یعنی معرفی کنترل خارجی از عملکرد مؤثر ISR جلوگیری می کند، زیرا سرور کنترل به سادگی نمی داند که از کجا و چه داده هایی باید کپی شود.

مشکل دیگر پیاده سازی پشتیبان در Postgres است. از طریق dump امکان پذیر است و روی پایگاه داده های کوچک کار می کند. اما در پایگاه های داده بزرگ، dump زمان زیادی می برد، به منابع زیادی نیاز دارد و می تواند منجر به شکست نمونه پایگاه داده شود.

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

جایی برای عقب نشینی نیست! توسعه دهندگان مسکو عقب هستند!

با این حال، اخیراً تیم ما با یک چالش دشوار روبرو شد: در پروژه ایجاد AIS OSAGO 2.0، جایی که ما زیرساخت فناوری اطلاعات را ایجاد کردیم، توسعه دهندگان PostgreSQL را برای سیستم جدید انتخاب کردند.

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

• به SRK آموزش دهید که از گره اصلی خوشه پشتیبان تهیه کند. برای انجام این کار، SRK باید آن را پیدا کند - به این معنی که یکپارچه سازی با یک یا آن راه حل مدیریت خوشه PostgreSQL مورد نیاز است. در مورد RSA از نرم افزار Patroni برای این کار استفاده شد.
• بر اساس حجم داده ها و نیازهای بازیابی در مورد نوع پشتیبان گیری تصمیم بگیرید. به عنوان مثال، زمانی که نیاز به بازیابی صفحات به صورت دانه بندی دارید، از Dump استفاده کنید و اگر پایگاه داده ها بزرگ هستند و نیازی به بازیابی دانه ای نیست، در سطح فایل کار کنید.
• برای ایجاد یک نسخه پشتیبان در حالت چند رشته ای، امکان بک آپ گیری بلوک را به راه حل ضمیمه کنید.

در همان زمان، ما در ابتدا تصمیم گرفتیم یک سیستم موثر و ساده بدون مهار هیولا از اجزای اضافی ایجاد کنیم. هر چه عصا کمتر باشد، حجم کار کمتری برای کارکنان و خطر شکست IBS کمتر می شود. ما بلافاصله رویکردهایی را که از Veeam و RMAN استفاده می‌کردند حذف کردیم، زیرا مجموعه‌ای از دو راه‌حل قبلاً به غیرقابل اعتماد بودن سیستم اشاره می‌کند.

کمی جادو برای شرکت

بنابراین، ما نیاز به تضمین پشتیبان گیری قابل اعتماد برای 10 کلاستر از 3 گره، با زیرساخت مشابه در مرکز داده پشتیبان داشتیم. مراکز داده از نظر PostgreSQL بر اساس اصل فعال - غیرفعال کار می کنند. حجم کل پایگاه داده 50 ترابایت بود. هر سیستم کنترلی در سطح شرکت می تواند به راحتی با این موضوع کنار بیاید. اما نکته این است که در ابتدا Postgres سرنخی برای سازگاری کامل و عمیق با سیستم های پشتیبان ندارد. بنابراین، ما باید به دنبال راه‌حلی می‌گشتیم که در ابتدا حداکثر عملکرد را در ارتباط با PostgreSQL داشته باشد و سیستم را اصلاح کنیم.

ما 3 "هکاتون" داخلی برگزار کردیم - بیش از پنجاه پیشرفت را بررسی کردیم، آنها را آزمایش کردیم، تغییراتی را در ارتباط با فرضیه های خود ایجاد کردیم و دوباره آنها را آزمایش کردیم. پس از بررسی گزینه های موجود، Commvault را انتخاب کردیم. خارج از جعبه، این محصول می‌توانست با ساده‌ترین نصب خوشه PostgreSQL کار کند و معماری باز آن امیدها را (که موجه بود) برای توسعه و یکپارچه‌سازی موفق ایجاد کرد. Commvault همچنین می تواند از گزارش های PostgreSQL پشتیبان تهیه کند. به عنوان مثال، Veritas NetBackup از نظر PostgreSQL فقط می تواند نسخه پشتیبان کامل تهیه کند.

بیشتر در مورد معماری سرورهای مدیریت Commvault در هر یک از دو مرکز داده در یک پیکربندی CommServ HA نصب شدند. این سیستم آینه ای است، از طریق یک کنسول مدیریت می شود و از نقطه نظر HA، تمام الزامات سازمانی را برآورده می کند.

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

Patroni یک گره اولیه برای هر خوشه تعریف می کند. این می تواند هر گره رایگان در مرکز داده باشد - اما فقط بیشتر. در پشتیبان گیری، همه گره ها ثانویه هستند.

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

به طور کلی، روند به صورت زیر است:

Patroni Primary → Keepalived را انتخاب می کند و اسکریپت را اجرا می کند → عامل Commvault در گره خوشه انتخابی اعلانی دریافت می کند که Primary → Commvault به طور خودکار نسخه پشتیبان را در شبه کلاینت پیکربندی مجدد می کند.

مزیت این روش این است که راه حل بر سازگاری، صحت گزارش ها یا بازیابی نمونه Postgres تأثیر نمی گذارد. همچنین به راحتی مقیاس پذیر است، زیرا دیگر نیازی به تعمیر گره های اصلی و ثانویه Commvault نیست. کافی است سیستم بفهمد که Primary کجاست و تعداد گره ها را می توان تقریباً به هر مقداری افزایش داد.

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

در هر شبه مشتری، گره فعال خوشه نشان داده شده است. این همان چیزی است که راه حل یکپارچه سازی ما برای Commvault تعریف می کند. اصل عملکرد آن بسیار ساده است: اگر یک IP خوشه بر روی یک گره افزایش یابد، اسکریپت پارامتر "گره فعال" را در باینری عامل Commvault تنظیم می کند - در واقع، اسکریپت "1" را در قسمت مورد نیاز حافظه تنظیم می کند. . عامل این داده ها را به CommServe منتقل می کند و Commvault از گره مورد نظر یک نسخه پشتیبان تهیه می کند. علاوه بر این، صحت پیکربندی در سطح اسکریپت بررسی می شود و به جلوگیری از خطا هنگام شروع یک نسخه پشتیبان کمک می کند.

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

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

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

در حال حاضر، IBS بر خدمات بهره وری تأثیر نمی گذارد، اما اگر وضعیت تغییر کند، Commvault می تواند محدودیت بار را فعال کند.

خوب است؟ خوب!

بنابراین، ما نه تنها یک نسخه پشتیبان قابل اجرا، بلکه یک نسخه پشتیبان کاملاً خودکار برای نصب خوشه PostgreSQL نیز دریافت کرده‌ایم و همه الزامات تماس‌های سازمانی را برآورده می‌کند.

پارامترهای RPO و RTO 1 ساعت و 2 ساعت با یک حاشیه پوشانده می شوند، به این معنی که سیستم حتی با افزایش قابل توجه حجم داده های ذخیره شده با آنها مطابقت خواهد داشت. برخلاف بسیاری از تردیدها، PostgreSQL و محیط سازمانی کاملاً سازگار بودند. و اکنون از تجربه خودمان می دانیم که پشتیبان گیری برای چنین DBMS هایی در پیکربندی های مختلف امکان پذیر است.

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

آیا کار با PostgreSQL را در یک محیط شرکتی امتحان کرده اید؟

نویسنده:

اولگ لاورنوف، مهندس طراح سیستم های ذخیره سازی داده، جت اینفوسیستمز

دیمیتری اریکین، مهندس طراحی سیستم های کامپیوتری در جت اینفوسیستمز

منبع: www.habr.com