در طراحی SCOM یا System Center Operation Manager باید خرابی احتمالی ویژگی‌ها و سرورها را مد نظر قرار داد و برای این زمان‌ها راه‌حلی اندیشید. میزان از دست رفتن اطلاعات و قابلیت‌ها، براثر خرابی در سناریوهای خرابی مختلف با هم متفاوت است و بستگی به ویژگی دچار خرابی و طول مدت زمان بازیابی آن دارد.
بررسی دسترسی‌پذیری بالا یا HA در طراحی SCOM
با ایجاد افزونگی در Management Group، دیتابیس‌های عملیاتی و پایگاهدادهی Operation Manager، Management Servers و Gateway و بارهای کاری مشخص، پاسخ به نیاز‌های مربوط به دسترسی‌پذیری بالا امکانپذیر است. این بارهای کاری شامل مانیتورینگ دستگاه شبکه، مانیتورینگ در بین پلتفرم‌ها (Cross-Platform) و بارهای کاری مختص به Management Group به‌خصوصی که قبلا توسط Root Manager Server مدیریت می‌شدند، می‌باشد.
پیکربندی Management Group با چندین سرور می‌تواند برای ارائه دسترسی‌پذیری بالا و تداوم خدمات برای دیتابیس‌های Operation Manager از SQL Server Always On استفاده کند. با داشتن حداقل دو Management Server و استفاده از Poolهای منابع برای مانیتورینگ سرورهای UNIX و Linux و دستگاه‌های شبکه، قابلیت Fault-Tolerance (تحمل خطا) Management Server فراهم میگردد. سرورهای ویندوز مبتنی بر Agent را می‌توان با یک Management Server اولیه و ثانویه پیکربندی کرد تا در صورت از کار افتادن Management Server، ارتباطات Agent تغییر مسیر پیدا کند.
ویدیوی آشنایی با System Center 2016
مشاهده ویدیوهای بیشتر
در صورتی که Management Server میزبان RMS Emulator غیر قابل دسترسی شود، می‌توان RMS Emulator را به سرورهای مدیریتی دیگر منتقل نمود. می‌توان با پیکربندی دسترس‌پذیری بالا برای Data Access Services، اتصالات کنسول عملیات را بسیار دسترسی‌پذیر نمود. این کار با نصب Microsoft Network Load Balancing یا به اختصار NLB، یا با استفاده از تعدیل کننده‌های بار مبتنی بر سخت‌افزار یا DNS امکانپذیر است. یک یا چند Management Server به‌عنوان اعضای Pool NLB اضافه می‌شوند و هنگام بازکردن کنسول، کاربر به نام مجازی ثبت شده‌ی خود در DNS از سرورهای مدیریتی تعدیل‌بار شده، ارجاع می‌دهد. قابل توجه است که تعدیل‌کننده‌ی بار برای کنسول وب Operation Manager پشتیبانی نمی‌شود.
می‌توان چندین سرور Gateway را در محدوده‌ی اعتماد قرار داد تا مسیرهایی اضافی را برای Agentهایی که در آن محدوده‌ی اعتماد قرار دارند، ارائه دهند. همانطور که Agentها می‌توانند بین Management Server اولیه و یک یا چند سرور مدیریتی ثانویه Failoverکنند، می‌توانند دربین سرورهای Gateway نیز Failover نمایند. علاوه‌براین می‌توان از چندین سرور Gateway برای تقسیم بارکاری مدیریت کامپیوترهای مدیریت شده بدون (Agent (Agentless-Managed و دستگاه‌های شبکه‌ای مدیریت شده، استفاده کرد. اگر سرورهای مدیریتی چندتایی در دسترس باشند، علاوه بر ارائه افزونگی از طریق Agent- Gateway Failover، سرورهای Gateway را می‌توان برای Failover بین سرورهای مدیریتی در Management Group پیکربندی کرد.
با وجوداینکه SQL Server Reporting Services از یک مدل نصبScale-Out پشتیبانی می‌کند که به کاربر اجازه می‌دهد تا چندین Instance سرور گزارش را راه‌اندازی کند که تنها در یک دیتابیس سرور گزارش مشترک هستند، ولی همراه باOperation Manager پشتیبانی نمی‌شود. Operation Manager Reporting یک افزونه امنیتی سفارشی را به عنوان بخشی از راه اندازی اجزای Front-end نصب می‌کند که در سراسر Web Farm قابل همسان‌سازی نیست.
بررسی Disaster Recovery در طراحی SCOM
Disaster Recovery به مجموعه اقدامات انجام‌شده جهت اطمینان از انجام مجدد عملیات، در صورت وقوع یک خرابی فاجعه‌بار، مربوط می‌شود. مثلا از دست رفتن کل دیتاسنتر که میزبانِ زیرساخت اولیه می‌باشد. این امر، عنصری مهم محسوب میگردد که باید در هر پیاده‌سازی در نظر گرفته شود و تصمیماتی که در برنامه‌ریزی برای Disaster Recovery گرفته می‌شود روی چگونگی قابلیت Operation Manager در پشتیبانی از مانیتورینگ فعال و آینده‌نگرانه، گزارش عملکرد و دسترس‌پذیری خدمات IT حیاتی کاربر تاثیر خواهد داشت. این بخش بر روی این موضوع تمرکز خواهد کرد که راهکارهای پیشنهادی Disaster Recovery و قابلیت خود ترمیمی چیست و اینکه برای اطمینان از بازیابی بدون نقص چه اقداماتی لازم است.
اگرچه راهکارهای HA و DR از خرابی یا ازدست‌رفتن سیستم محافظت می‌کنند ولی نمی‌توان برای ارائه‌ی محافظت در مقابل خرابی و از دست‌دادن تصادفی یا ناخواسته داده‌ها روی آن‌ها حساب کرد. در این موارد ممکن است نسخه‌ی Backup یا نسخه‌ی Lagged Replication برای عملیات بازیابی بهتر باشند. در خیلی از موارد، عملیات بازیابی (Restore) مناسب‌ترین شکل DR است؛ مثال این موضوع می‌تواند دیتابیس گزارش‌‌گیری دارای اولویت پایین‌تر یا داده‌های تجزیه‌وتحلیلی باشد. در بسیاری از موارد هزینه فعال‌سازی Multisite DR در سطح سیستم یا در برنامه کاربردی به مراتب بیشتر از ارزش داده‌ها است. در مواردی که ارزش کوتاه مدت داده‌ها کم است و نیاز به دسترسی به داده‌ها می‌تواند بدون تاثیر شدید برکسب‌و‌کار به تاخیر بیفتد، اگر خرابی یا DR سایت بیش‌ازحد باشد و صرفه‌جویی در هزینه‌ها این موضوع را توجیه کند استفاده از فرایند ساده‌ی Backup و بازیابی باید مد نظر قرار گیرد.
مطلب مرتبط: ویژگی های جدید SCOM 2019
آگاهی از میزان تاثیر Downtime و قابلیت تحمل آن به کاربر کمک خواهد کرد تصمیماتی بگیرد که به منظور طراحی مناسب معماری برای Operation Manager و همچنین تعیین سطح پیچیدگی و هزینه‌های مورد نیاز برای‌پشتیبانی از Disaster Recovery لازم هستند. علاوه بر این، باید میزان از دست‌دادن داده‌ها را که بدون ایجاد عواقب در کسب‌و‌کار برای سازمان IT قابل‌تحمل است مد نظر قرار داده شود. این امر به بهترین شکل، از طریق دو مفهومِ زمان بازیابی (RTO) و نقطه بازیابی (RPO) به بهترین شکل توصیف شده‌است.
دو مورد از رایج‌ترین پیکربندی‌های طراحی Disaster Recovery برای Operations Manager عبارتند از:
- ایجاد یک Management Group تکراری که در دیتاسنتر ثانویه‌ی کاربر نصب شده و در مقیاس و پیکربندی گروه مدیریت اولیه را تکرار می‌کند.
- پیاده‌سازی سرورهای اضافی در دیتاسنترهای ثانویه برای پشتیبانی از دیتابیس‌های Data Warehouse و Operational، با پیاده‌سازی Management Server در پیکربندی Cold Standby، بدون شرکت در Management Group تا زمانیکه نیاز به انجام عملیات بازیابی باشد.
وقتی که تحمل برای خرابی وجود نداشته باشد، نصب Management Group تکراری گزینه مناسبی است، هر چند که پیچیده‌ترین گزینه می‌باشد. پیکربندی این دو باید آن‌قدر با ثبات انجام شود که وقتی دسترسی کاربر قطع می‌شود دیگر تفاوتی در چیزی که مانیتور می‌شود، در موردش هشدار یا گزارش داده می‌شود، ارائه میگردد و درنهایت تشدید می‌شود وجود نداشته باشد. ادغام با سایر پلتفرم‌های مانیتورینگ یا پلتفرم‌های ITSM مانند System Center، Service Manager، Remedy یا Service Now نیز باید وجود داشته باشد و باید در حالت Active/Passive پیکربندی شود تا از تکرار حوادث، آیتم‌های پیکربندی و غیره اجتناب گردد. Agentها بین هر دو گروه مدیریتی Multihomed خواهد شد، پس نسخه‌ی دیگری از داده‌ها وجود خواهد داشت.
