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

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

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

 لایه بندی مقصد یعنی دو سرعت، دو کارکرد، یک سیاست واحد

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

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

هدف این لایه بازیابی سریع روزمره است، مثل برگرداندن فایل حذف شده، بازگردانی ماشین مجازی، یا بازیابی سریع دیتابیس در همان سایت. این لایه باید

سریع باشد از نظر IOPS و Throughput

ظرفیت کافی برای نگهداری کوتاه مدت داشته باشد

در شبکه داخلی کم تاخیر قرار بگیرد

مانیتورینگ دقیق و هشدار ظرفیت داشته باشد

این لایه معمولا نقطه اصلی تحقق RTO کوتاه است.

لایه تاب آوری خارج از سایت

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

از نظر دسترسی و هویت از محیط تولید جدا باشد

ترجیحا تغییرناپذیر یا حداقل دارای سیاست جلوگیری از حذف سریع باشد

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

اینجا تمرکز بیشتر روی RPO قابل قبول و «قابل اتکا بودن» است نه سرعت برق آسا.

لایه آرشیو بلندمدت در صورت نیاز

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

جزئیات پیشرفته در لایه بندی مقصد

همسان سازی سیاست ها

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

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

اگر لایه دوم با همان اعتبارنامه های ادمین دامنه قابل حذف باشد، عملا خارج از سایت شما هم در همان حادثه می افتد.

طراحی برای بازیابی، نه فقط ارسال

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

خطاهای رایج در لایه بندی مقصد

نگهداری طولانی در لایه سریع و گران، که باعث پر شدن و شکست بکاپ های روزانه می شود 

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

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

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

این راهبرد دو هدف دارد

کاهش داده ای که باید منتقل شود

کاهش دفعات شکست انتقال در لینک های ناپایدار

بخش اول، ارسال افزایشی واقعی

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

افزایشی در سطح فایل

ساده تر است ولی برای فایل های بزرگ که کمی تغییر می کنند، ناکارآمد می شود چون کل فایل دوباره ارسال می شود.

افزایشی در سطح بلوک

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

بخش دوم، رفع تکرار یا Deduplication

رفع تکرار یعنی داده های تکراری را دوباره ذخیره یا منتقل نکنید. نکته سازمانی این است که محل انجام Dedup بسیار مهم است.

رفع تکرار نزدیک به منبع

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

رفع تکرار در مقصد

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

رفع تکرار ترکیبی

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

پیچیدگی های پیشرفته که باید از قبل حل شوند

اثر رمزنگاری روی Dedup

اگر قبل از Dedup رمزنگاری انجام شود، تکرارپذیری از بین می رود و Dedup بی اثر می شود. باید معماری رمزنگاری و محل Dedup هماهنگ باشد. هدف این است که امنیت حفظ شود بدون اینکه کارایی نابود شود.

ریسک دامنه خرابی

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

اندازه بلوک و الگوی داده

برای داده های بسیار فشرده یا رمز شده مثل رسانه های فشرده و فایل های رمز شده، Dedup کمتر اثر دارد. برای ماشین های مشابه و سیستم عامل های تکراری، اثرش زیاد است. بنابراین انتظار باید بر اساس نوع داده تنظیم شود.

کنترل های سازمانی لازم

سیاست فشرده سازی و Dedup بر اساس تیپ داده

محدودیت منابع CPU و IO برای جلوگیری از ضربه به تولید

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

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

زمان بندی انتقال خارج از ساعت کاری یعنی جدا کردن «لحظه بکاپ» از «لحظه ارسال»

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

گرفتن بکاپ به مقصد محلی سریع در پنجره کوتاه

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

اجزای عملیاتی زمان بندی انتقال

پنجره های انتقال تعریف شده

مثلا شب ها، آخر هفته، یا بازه های کم ترافیک روزانه. نکته مهم این است که «قابل پیش بینی» باشد تا تیم شبکه بتواند ظرفیت را مدیریت کند.

محدودسازی نرخ انتقال

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

اولویت شبکه ای

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

انتقال مرحله ای

به جای یک انتقال عظیم، انتقال را به قطعات کوچک تقسیم می کنند تا خطاها اثر کمتری داشته باشند و از سرگیری ساده تر شود.

مزیت سازمانی این راهبرد

کاهش تداخل با کاربران و برنامه ها

کاهش احتمال شکست به خاطر ازدحام لینک

امکان کنترل بهتر هزینه های لینک و کیفیت تجربه کاربران

ریسک ها و راه حل ها

عقب افتادن RPO

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

رخداد همزمان با زمان های شلوغ

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

تداخل با پنجره نگهداری

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

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

این راهبرد برای سازمان هایی است که هم داده زیاد دارند هم لینک محدود. به جای تلاش برای انتقال همه چیز، باید «آنچه بقا و ادامه کسب و کار را ممکن می کند» زودتر و مطمئن تر خارج شود.

مدل پیشرفته اولویت بندی

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

سرویس های درآمدزا، احراز هویت، دیتابیس های اصلی، و داده های عملیاتی باید بالاترین اولویت را داشته باشند.

اولویت بر اساس RPO

هرچه RPO پایین تر، دفعات ارسال بیرونی بیشتر و پیگیری سختگیرانه تر.

اولویت بر اساس RTO

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

اولویت بر اساس نسبت ارزش به حجم

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

نتیجه عملی در سیاست انتقال

صف انتقال چند سطحی

سطح ۱ داده حیاتی و کوچک، تقریبا دائم

سطح ۲ داده حیاتی و بزرگ، زمان بندی شده و افزایشی

سطح ۳ داده کم اهمیت، فقط هفتگی یا ماهانه یا اصلا فقط داخلی

سیاست نگهداری متفاوت

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

تعریف مجموعه بازیابی حداقلی

یک بسته حداقلی که اگر فقط همان را داشته باشید بتوانید سرویس های حیاتی را بالا بیاورید. این بسته باید بیرون از سایت همیشه تازه باشد.

خطاهای رایج در اولویت بندی

برابر دیدن همه سرورها به خاطر فشار سیاسی داخلی

نداشتن مالک سرویس و نبود تصمیم گیری رسمی

اولویت بندی فقط بر اساس «نام سرور» نه بر اساس جریان کسب و کار

Seed اولیه یعنی شروع را با شبکه خراب نکنید

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

سناریوهای رایج Seed

انتقال اولیه به رسانه قابل حمل سازمانی

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

انتقال اولیه از طریق لینک موقت پرسرعت

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

Seed در شعب

اگر شعب داده محلی دارند، Seed نزدیک به شعب انجام می شود و بعد همگام سازی مرکزی شکل می گیرد.

نکات حساس سازمانی در Seed

زنجیره امانت و کنترل فیزیکی

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

سازگاری نسخه ها و کاتالوگ

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

زمان انقضا

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

امنیت در زمان حمل

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

ملاک های موفقیت Seed

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

کاهش فشار روی لینک در هفته های اول

امکان شروع سریع سیاست های نگهداری و تغییرناپذیری در مقصد بیرونی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

چالش ها

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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