در مقاله بررسی دسترسی‌پذیری بالا و Disaster Recovery در طراحی SCOM به بررسی قابلیت‌های دسترسی پذیری بالا یا High Availability و Disaster recovery در System Center Operation Manager پرداختیم. در این مقاله سعی داریم به بیان سناریوهای پیاده‌سازی این ویژگی‌ها در سیستم SCOM بپردازیم.
اگر در پیاده‌سازی Operation Manager بازیابی سریع Management Group ضروری نباشد و کاربر بخواهد که از پیچیدگی‌های پیاده‌سازی Management Group دیگر بپرهیزد ، می‌تواند به منظور حفظ قابلیت Management Group، در یک دیتاسنتر ثانویه Management Group را پیاده‌سازی کند.
به منظور بازیابی دیتابیس‌های عملیاتی و Data Warehouse بین دو یا چند دیتاسنتر ، پیاده‌سازی SQL Server 2014 یا 2016 با ویژگی Always on Availability Group ، به صورتی که یک Two-node Fail Over Cluster Instance یا به اختصار FCI در دیتاسنتر اولیه و یک Standalone SQL Server در دیتاسنتر ثانویه به عنوان بخشی از Windows Server Fail Over Cluster یا به اختصار WSFC باید مد نظر گرفته شود. همانگونه که در نمودار زیر نشان داده شده است، Replicaی ثانویه برای Always on Availability Group باید روی Non-FCI Standard Instance باشد.
در این مثال ممکن است کاربر نیاز به پیاده‌سازی یک یا چند Windows Server با پیکربندی سخت افزاری و نام کامپیوتر یکسان و نصب مجدد Role سرور مدیریت (Management Server) با استفاده از پارامتر Recover/ داشته باشد. در طول این مدت، Agentها داده‌های جمع‌آوری شده که شامل هشدارها، وقایع، عملکرد و… می‌شوند را در Queue قرار می‌دهند تا زمانی‌که بتوانند ارتباط خود را با یک Management Server در Management Group از سر بگیرند. این رویکرد از نصب Instanceهای جدید SQL Server و بازیابی مجدد دیتابیس‌ها از آخرین Backup سالم کاربر اجتناب می‌کند. هر چند در این روش بازیابی، احتمالا تاخیر طولانی‌تری در بازگشت به حالت عملیاتی وجود خواهد داشت زیرا کاربر باید تا Roleهای دیگر را برای از سرگیری حداقل قابلیت مانیتورینگ، پیاده‌سازی کند. اگر این روش موثر واقع نشود، کاربر می‌تواند Management Serverها را در دیتاسنتر ثانویه برای ON-Standby Recovery پیاده‌سازی کند و آن‌ها را تحت عنوان بخش‌هایی از سه Resource Pool اصلی که شامل همه Management Server Resource Pool، Notificationها و AD Assignment می شوند، حذف نماید. این امر همچنین شامل همه‌ی Resource Poolهای سفارشی می‌شود، که ممکن است شامل Management Servers Hosted در دیتاسنتر اولیه باشد که نیاز به ادامه عملکرد به عنوان بخشی از برنامه بازیابی را دارد.
بیشتر بخوانید: مدیریت جامع شبکه با استفاده از Microsoft System Center
سرویس‌های System Center Data Access، System Center Configuration Management ، Microsoft Monitoring Agent باید متوقف یا به صورت دستی Disable شوند و فقط در زمان اجرای Disaster Recovery باید شروع به‌کار کنند. اگر Management Server از یکپارچه‌سازی از طریق رابطی که مستقیما روی Management Server یا روی System Center Product دیگری مانند VMM، Orchestrator یا Service Manager میزبانی می‌شود، پشتیبانی می‌کند. بسته به نوع پیکربندی یکپارچه‌سازی و توالی مراحل بازیابی، این امر نیاز به برنامه‌ریزی برای مراحل بازیابی به صورت دستی یا خودکار دارد. این امر تضمین می‌کند زمانی‌که باید برنامه Disaster Recovery اجرا شود برای هرگونه وابستگی دیگر به Management Server، برنامه‌ریزی شده و تحت کنترل می‌باشد.
اگر یک سایت از دسترس خارج شود شود، در صورتی که پیکربندی Agent’s Failover این اجازه را دهد، Agent به Management Server در سایت دیگری Fail Over خواهد شد. Windows Agent ها در دیتاسنتر اولیه باید به صورتی مدیریت و پیکربندی شوند تا فقط Management Serverها را در دیتاسنتر اولیه Cache کنند و از تلاش آن‌ها برای Failover یک Management Server در دیتاسنتر ثانویه جلوگیری کنند، زیرا اینکار فقط ممکن است باعث تاخیر در بازیابی و گزارش‌دهی شود. این امر درصورتی محقق می‌شود که کاربر به صورت دستی Agent را به‌شیوه‌ای خودکار‌سازی‌شده با یک Script پاورشل یا VBScript پیاده‌سازی کند تا پیکربندی از پیش تعیین شده در حین نصب، یا پس از آن انجام شود، مشروط بر اینکه کاربر Agent را از کنسول Push کند و دوباره از روش رمزگذاری مدیریت شده با راه‌حل مدیریت پیکربندی استفاده نماید.
برای حفظ استمرار Management Group، می‌توان Operations Manager را روی ماشینهای مجازی Azure به عنوان گزینه‌ی جایگزین Disaster Recovery پیاده‌سازی کرد. پیاده‌سازی SQL Server روی ماشین مجازی در Azure و نه در یک پیکربندی Hybrid ضروری است، زیرا تاخیر بین Management Server و SQL Server میزبانِ دیتابیسِ Operation Manager تاثیر منفی بر عملکرد Management Group خواهد گذاشت. به منظور طراحی مناسب این روش در Azure laaS یا سایر ارائه‌دهندگان Cloud باید دامنه مانیتورینگ، توپولوژی شبکه، اتصال شبکه به Microsoft Azure که بصورت Site-To-Site VPN Express Route است، نقاط یکپارچه‌سازی با راهکارها ITSM و دیگر محصولات System Center، دسترسی کنسول، قوانین و سیاست‌های مربوط یا تنظیم شده و سایر موراد در نظر گرفته شوند.
