MULTI-SITE INFRASTRUCTURE

چند سایت باید مثل یک زیرساخت واحد کار کنند، نه چند جزیره جدا

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

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

قبل از طراحی ارتباط سایت‌ها

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

کدام سرویس‌ها باید محلی بمانند؟
مسیر جایگزین ارتباط چیست؟
داده بین سایت‌ها چطور Replicate می‌شود؟
Backup کجا نگهداری می‌شود؟
شبکه سایت‌ها چطور از هم تفکیک می‌شود؟
مدیریت و Monitoring چقدر متمرکز است؟

چند سایت یعنی چند Failure Domain

یک معماری چندسایتی خوب، خرابی را محدود می‌کند

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

تصمیم‌های اصلی معماری

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

سرویس مرکزی یا محلی

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

مسیر اصلی و جایگزین

WAN، اینترنت، MPLS یا مسیرهای دیگر باید بر اساس حساسیت سرویس طراحی شوند و Failover ارتباطی از قبل مشخص باشد.

محل نگهداری داده

باید روشن باشد داده اصلی، Replica و Backup در کدام سایت قرار می‌گیرند و خرابی یک سایت چه اثری روی دسترسی به آن‌ها دارد.

ظرفیت هر سایت

همه سایت‌ها لزوماً ظرفیت یکسان نمی‌خواهند. نقش سایت، تعداد کاربران و سناریوی Recovery تعیین می‌کند چه منابعی لازم است.

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

ارتباط بین سایت‌ها نباید به معنی باز بودن همه مسیرها باشد. Segmentation و Policy باید با نقش هر سایت و سرویس هماهنگ باشد.

مدیریت متمرکز

Monitoring، Configuration و Support بهتر است تا حد ممکن یکپارچه باشند تا تیم مرکزی تصویر روشنی از وضعیت همه سایت‌ها داشته باشد.

مرکزیت در برابر استقلال سایت

همه چیز را متمرکز نکنیم، فقط چون می‌توانیم

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

برای هر سرویس این سؤال‌ها را می‌پرسیم

در صورت قطع WAN سرویس ادامه دارد؟
کدام داده باید Local Cache یا Replica داشته باشد؟
Authentication و DNS از کجا تأمین می‌شوند؟
چه مقدار Downtime قابل قبول است؟
پس از برگشت لینک، Sync چطور انجام می‌شود؟

لایه‌های راهکار

Multi-Site فقط پروژه Network نیست

Network نقطه اتصال سایت‌هاست، اما پایداری نهایی به Compute، Storage، Backup، DR و Security هم وابسته است. اگر این لایه‌ها جدا از هم طراحی شوند، مشکل معمولاً در همان مرزها ظاهر می‌شود.

Network و Connectivity

مسیر اصلی و جایگزین، Routing، Bandwidth و کیفیت ارتباط باید با حساسیت سرویس‌ها هماهنگ باشند.

امنیت شبکه ←

Replication و DR

برای سرویس‌های حساس، باید مشخص باشد Replica به کدام سایت می‌رود و Failover در چه شرایطی انجام می‌شود.

Business Continuity و DR ←

Backup و Data Protection

Backup محلی و Off-Site باید طوری چیده شوند که خرابی یا حادثه در یک سایت همه نسخه‌های قابل بازیابی را درگیر نکند.

راهکارهای Backup ←

Compute و Virtualization

برای سرویس‌های محلی یا سایت پشتیبان، ظرفیت Compute باید با نقش واقعی همان سایت و سناریوی Recovery هماهنگ باشد.

Private Cloud و VCF ←

Segmentation و Security

سایت‌ها، کاربران و سرویس‌ها باید مرزهای مشخص داشته باشند تا یک رخداد در یک بخش به کل سازمان سرایت نکند.

Monitoring و Support

تیم مرکزی باید بتواند وضعیت لینک‌ها، ظرفیت، Backup و سرویس‌های کلیدی سایت‌ها را بدون وابستگی به حضور محلی مشاهده کند.

سایت دوم همیشه DR Site نیست

وجود چند سایت فرصت ایجاد می‌کند؛ اما نقش هرکدام باید صریح تعریف شود

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

قبل از انتخاب سایت پشتیبان بررسی می‌کنیم

ظرفیت Compute و Storage
کیفیت و استقلال مسیر Network
فاصله و Failure Domain مشترک
امکان Replication
دسترسی تیم فنی
RPO و RTO سرویس‌های هدف

کجا این معماری بیشتر دیده می‌شود؟

مدل Multi-Site در صنایع مختلف، شکل یکسانی ندارد

نفت، گاز و پتروشیمی

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

مشاهده صنعت ←

هلدینگ‌ها

اتصال شرکت‌های تابعه، Shared Services و تفکیک منابع و دسترسی.

مشاهده صنعت ←

صنعت و تولید

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

مشاهده صنعت ←

انرژی و زیرساخت‌های حیاتی

سایت‌های توزیع‌شده، High Availability و محدود کردن دامنه خرابی.

مشاهده صنعت ←

نحوه شروع پروژه

اول نقشه سایت‌ها و وابستگی سرویس‌ها را می‌سازیم

قبل از تغییر Network یا خرید تجهیزات، باید بدانیم هر سایت چه نقشی دارد، چه سرویس‌هایی در آن اجرا می‌شوند، به چه سایت‌هایی وابسته‌اند و در زمان اختلال چه چیزی باید ادامه پیدا کند.

۰۱

Site Map

سایت‌ها، ارتباطات، ظرفیت و سرویس‌های هر نقطه مشخص می‌شوند.

۰۲

Dependency

وابستگی سرویس‌ها به Network، Data و سایت‌های دیگر بررسی می‌شود.

۰۳

Architecture

Connectivity، Security، Replication، Backup و DR کنار هم طراحی می‌شوند.

۰۴

Test

سناریوی قطع لینک یا سایت و مسیر ادامه سرویس در عمل بررسی می‌شود.

اگر چند سایت دارید، مسئله را از بدترین نقطه ارتباط شروع کنیم

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

درخواست جلسه فنی