پوریا رضاتبار بالانقیبی

»»——☠——«   قسمت בوم »——☠——««

اندازه سازمان و تعداد سرورها و کلاینت ها

چرا اندازه سازمان «تعداد» نیست و «الگو» است

در طراحی بکاپ، بزرگ یا کوچک بودن سازمان فقط با شمارش سرورها تعیین نمی شود، بلکه با الگوی تولید داده و الگوی عملیات تعیین می شود. دو سازمان با ۲۰ سرور می توانند نیاز کاملا متفاوتی داشته باشند اگر یکی روزانه چند ترابایت تغییر داده داشته باشد و دیگری چند گیگابایت. بنابراین اندازه سازمان را باید به چند محور تبدیل کرد که مستقیما روی معماری اثر می گذارند

تعداد دارایی ها: سرورهای فیزیکی، ماشین های مجازی، کانتینرها، سرویس های ابری، کلاینت های کاربر

حجم داده تحت حفاظت و مهمتر از آن نرخ تغییر روزانه

تعداد سایت ها و شعب و فاصله شبکه ای آن ها

محدودیت های عملیاتی: پنجره بکاپ، ساعت های کاری، محدودیت خاموشی، تیم نگهداری

الزامات امنیتی و انطباق: نگهداری بلندمدت، جداسازی، ثبت وقایع، محدودیت دسترسی

 مدل سازمانی طبقه بندی دارایی ها برای بکاپ

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

دامنه سرویس: زیرساخت پایه، سرویس های تجاری، سرویس های پشتیبان

حساسیت داده: عمومی، داخلی، محرمانه، بسیار محرمانه

حیاتی بودن: حیاتی، مهم، معمولی، کم اهمیت

نوع بارکاری: فایل محور، دیتابیس، پیام رسانی، مجازی سازی، برنامه های وب، تحلیلی

این طبقه بندی مستقیم به سیاست زمان بندی، نگهداری، رمزنگاری، و مقصد بکاپ تبدیل می شود.

موجودی گیری سازمانی به سبک قابل اتکا

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

 نقشه دارایی ها: چه چیزی وجود دارد، کجاست، مالک آن کیست

نقشه وابستگی: هر سرویس به چه چیزهایی وابسته است مثل نام و گواهی و دیتابیس و صف پیام

نقشه داده: داده اصلی کجاست، کپی ها کجاست، «منبع حقیقت» کدام است

نقشه دسترسی: چه حساب هایی به کجا دسترسی دارند، مخصوصا به مخزن بکاپ

 نقشه تغییر: چه بخش هایی بیشترین تغییر را دارند تا سیاست افزایشی و نگهداری درست تعیین شود

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

برآورد ظرفیت به زبان مدیریتی و به زبان مهندسی

ظرفیت بکاپ دو نوع هزینه دارد: هزینه ذخیره سازی و هزینه زمان و شبکه.

برای اینکه ظرفیت قابل دفاع باشد، معمولا این محورها را عددی می کنند

حجم اولیه داده قابل بکاپ

نرخ رشد ماهانه

نرخ تغییر روزانه

نسبت فشرده سازی و رفع تکرار واقعی در داده های شما

همزمانی کارها و اوج بار

نرخ بازیابی مورد انتظار

به شکل سازمانی، شما باید دو ظرفیت جدا ببینید

ظرفیت مخزن عملیاتی برای بازیابی سریع کوتاه مدت

ظرفیت آرشیوی یا خارج از سایت برای تاب آوری و نگهداری بلندمدت

ترکیب این دو تعیین می کند بکاپ به چه شکل لایه بندی شود.

پنجره بکاپ و واقعیت بهره برداری

در سازمان های واقعی، بزرگترین دشمن بکاپ «کمبود زمان شبانه» است. اگر پنجره بکاپ کوتاه باشد، معماری باید به سمت این گزینه ها برود

 افزایشی دائمی با فول های دوره ای

 استفاده از تغییر بلوکی در مجازی سازی

 توزیع بار با پروکسی ها یا چند مسیر انتقال

 اولویت بندی کارها بر اساس حیاتی بودن

 بکاپ های نزدیک به منبع در شعب و سپس تجمیع خارج از ساعت شلوغی

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

کلاینت های کاربر و چالش پراکندگی

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

تحمل قطع و وصل اینترنت و ادامه انتقال

رمزنگاری سرتاسری

کنترل پهنای باند و زمان بندی

سیاست نگهداری کوتاه برای کاهش هزینه

قابلیت بازیابی خودکار یا سلف سرویس برای کاهش فشار به تیم IT

در سازمان بالغ، سیاست این است که یا داده را از کلاینت به مخازن سازمانی منتقل کنید یا بکاپ کلاینت را یک سرویس رسمی با مالکیت و گزارش گیری کنید، نه یک اقدام سلیقه ای.

مجازی سازی دارید یا نه

تفاوت بنیادی در نقطه کنترل

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

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

این تفاوت روی همه چیز اثر می گذارد: سرعت، سازگاری، پیچیدگی، و حتی مدل امنیت.

معماری بکاپ در محیط غیرمجازی

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

ایجنت روی هر سرور برای بکاپ فایل و سیستم و اپلیکیشن

بکاپ برنامه محور جداگانه برای دیتابیس ها

ذخیره سازی متمرکز یا نیمه متمرکز برای مخزن

چالش ها

نگهداری نسخه ایجنت ها و ناسازگاری ها

مصرف منابع روی سرورهای تولید

پیچیدگی در بازگردانی کامل سرویس به سخت افزار جدید

راه حل سازمانی

استاندارد کردن سیستم عامل ها و پچ ها تا ایجنت ها پایدار باشند

تعریف «پروفایل بکاپ» برای نقش ها مثل فایل سرور، وب سرور، دیتابیس

مستندسازی بازیابی bare metal یا معادل آن

معماری بکاپ در محیط مجازی

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

اسنپ شات هماهنگ با فایل سیستم و اپلیکیشن

انتقال داده از مسیر بهینه با پروکسی

تغییر بلوکی برای کاهش حجم افزایشی

امکان بازیابی سریع ماشین و سپس انتقال به ذخیره سازی اصلی

اما ریسک های خاص هم وجود دارد

انفجار همبستگی: یک خطای ذخیره سازی یا یک پیکربندی بد، صدها ماشین را یکجا تحت تاثیر می گذارد

قفل شدن روی یک نقطه کنترل: اگر کاتالوگ یا سرویس مدیریت بکاپ آسیب ببیند، بازیابی گسترده سخت می شود

رشد اسنپ شات ها و پر شدن datastore در اثر بکاپ های ناقص

برای سازمان های بزرگ، بلوغ یعنی اینها را رسمی می کنند

سیاست محدودیت مدت اسنپ شات و پایش اجباری

جداسازی شبکه بکاپ از شبکه تولید

طراحی ظرفیت با در نظر گرفتن بازیابی انبوه نه فقط بکاپ گیری روزانه

کانتینر و بارهای مدرن

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

داده پایدار و حجم ها

پیکربندی ها و رازها و سیاست ها

رجیستری و نسخه تصاویر

تعریف سرویس و شبکه

در سازمان های نوین، هدف این است که بازتولید محیط سریع باشد و بکاپ بیشتر روی داده های پایدار متمرکز شود.

نوع دیتابیس ها و برنامه های حیاتی

چرا «نوع دیتابیس» تعیین کننده RPO است

برای دیتابیس، بکاپ با کپی فایل فرق دارد. شما با مفهومی به نام سازگاری تراکنشی سروکار دارید. بنابراین نوع دیتابیس و مدل ثبت لاگ و روش بازیابی آن تعیین می کند که آیا می توانید RPO چند دقیقه ای داشته باشید یا نه.

به زبان سازمانی، سه کلاس نیاز دارید

دیتابیس هایی که باید نقطه به نقطه بازیابی شوند و لاگ بکاپ می خواهند

دیتابیس هایی که بکاپ روزانه کافی است

دیتاست هایی که بیشتر آرشیوی اند و می توانند با RPO بزرگتر کار کنند

برنامه های حیاتی و دامنه واقعی بکاپ

برای یک برنامه حیاتی، معمولا چند جزء باید همزمان دیده شوند

داده اصلی مثل دیتابیس

فایل های بارگذاری شده و دارایی های رسانه ای

پیکربندی برنامه و پارامترها

گواهی های دیجیتال و کلیدها

وابستگی ها مثل صف پیام، کش، سرویس جستجو، سرویس گزارش

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