گروه مدیریت یا Management Group در سیستم SCOM به‌واسطه‌ی یک دیتابیس واحد، یک یا چند Management Server، تجهیزات و Agent مانیتور شده شناسایی می‌شود. با اتصال به گروه مدیریت، مشاهده و ویرایش هشدارها و داده‌های مانیتورینگ توسط یک کنسول واحد، امکان‌پذیر می‌گردد. علاوه بر آن می‌توان Taskها را به منظور اجرا در Objectهای مدیریت‌شده‌ی متعلق به یک Management Group، از یک گروه مدیریتی Local آغاز کرد.
ساده‌ترین روش برای اجرای Operations Manager در سیستم SCOM یک Management Group واحد است. هر گروه اضافه دست‌کم به دیتابیس عملیاتی و سرور Management مختص به خود نیاز دارد. به علاوه، هر گروه باید به‌طور جداگانه با تنظیمات پیکربندی، Management Packها و یکپارچه‌سازی مختص به خود و دیگر راهکارهای ITSM و مانیتورینگ نگهداری شود.
پیاده‌سازی Distributed Management Group، اساس و پایه‌ی نصب نود و نه درصد از پیاده‌سازی‌های Operations Manager دv سیستم SCOM می‌باشد. این امر امکان توزیع ویژگی‌ها و خدمات در سراسر سرورهای چندتایی را فراهم می‌کند و مقیاس‌پذیری و افزونگی برخی از این ویژگی‌ها را میسر می‌سازد. همچنین می‌تواند شامل همه‌ی Roleهای سرور Operations Manager باشد و با استفاده از سرور Gateway از مانیتورینگ دستگاه‌ها در سراسر Boundaryهایی که Trust هستند، پشتیبانی می‌کند. نمودار زیر یکی از گزینه‌های ممکن برای توپولوژی Distributed Management Group را نشان می‌دهد.
نکته‌ی قابل توجه این است که هیچ ارتباط مستقیمی بین کنسول Operation و دیتابیس‌ها وجود ندارد. همه‌ی ارتباطات از طریق پورت TCP 5724 به یک سرور Management خاص و سپس به سرورهای دیتابیسی که از OLE DB در TCP 1433 استفاده می‌کنند یا یک پورتی که طی راه‌اندازی Instance دیتابیس SQL توسط ادمین SQL مشخص شده است، هدایت می‌شوند. با این‌حال ارتباط مستقیمی بین یک کنسولApplication Diagnostics (Co-Locateشده با کنسول تحت وب) و SQL Serverی که میزبان دیتابیس‌های عملیاتی و پایگاه داده است، وجود دارد.
بیشتر بخوانید: معرفی قابلیت های جدید SCOM 2019
در سیستم SCOM گروه Management Group ی که کاربر در محیط مربوط به خود نصب می‌کند، امکان ادغام با Microsoft Operations Management Suite یا به اختصار OMS، را دارد و با استفاده از Log Analytics کاربر می‌تواند عملکرد، رویدادها و هشدارها را همبسته و تصویرسازی کرده و همچنین بر اساس آن‌ها اقداماتی صورت دهد. این امر با افزایش قابلیت دید، کاربر را قادر می‌سازد تا به منظور برقراری ارتباط بین سیستم‌ها و برنامه‌های کاربردی که به صورت On-Premise میزبانی می‌شوند یا در Cloud هستند، به جست‌وجوهای دلخواه در تمامی مجموعه‌ی داده‌ها بپردازد.
یکپارچه‌سازی با Operations Manager به محصولات دیگری نیز از قبیل BMC Remedy و IBM و Netcool و یا دیگر راهکارهای مدیریتی سازمانی که کاربر از آن استفاده می‌کند، تعمیم می‌یابد.
اجزای گروه Management Group در سیستم SCOM
سرور Management
در نسخه‌ی قدیمی‌تر Operations Manager که در سال 2007 منتشر شد، سرور Management اصلی یا RMS نوعی سرور مدیریتی تخصصی در Management Group و اولین Management Server نصب‌شده در گروه مدیریت بود و RMS نقطه‌ی کانونی مدیریت پیکربندی Management Group، مدیریت و ارتباط با Agentها، دیتابیس Operational و سایر دیتابیس‌ها در گروه مدیریت بود. علاوه بر این RMS به عنوان هدفی برای کنسول Operational و هدفی ارجح برای کنسول تحت وب به کار می‌رفت. در System Center 2012 R2-Operational Manager، سرور RMS حذف شد و در حال حاضر همه‌ی سرورهای Management با هم برابر هستند. این پیکربندی همچنان در System Center 2016 و نسخه‌های بعدی Operations Manager موجود است. از آنجایی که تمام سرورهای Managementی میزبان سرویس‌هایی هستند که پیش‌تر تنها توسط RMS میزبانی می‌شدند، RMS دیگر Single Point of Failure به شمار نمی‌رود. اگر یک سرور مدیریت از دسترس خارج شود، مسئولیت آن به طور خودکار توزیع می‌شود. یک RMS Emulator Role، انطباق با نسخه‌ی قدیمی را برای بسته‌های مدیریتی با هدف RMS، فراهم می‌کند. اگر کاربر یک بسته‌ی مدیریتی ندارد که قبلا RMS را مورد هدف قرار داده باشد، نیازی به استفاده از RMS Emulator ندارد.
بیشتر بخوانید: مفاهیم و قابلیت های System Center Operations Manager
گروه مدیریت ممکن است شامل چندین سرور مدیریت به منظور فراهم کردن ظرفیت اضافه و دسترسی مداوم باشد. وقتی دو یا چند سرور مدیریت به یک گروه مدیریت اضافه می‌شوند، سرورهای Management به طور خودکار بخشی از سه Resource Pool پیش‌فرض می‌شوند و کار بین اعضای Pool پخش می‌شود. برای Resource Pool های تعریف‌شده و دلخواه، اعضا به صورت غیر خودکار و دستی اضافه می‌شوند. وقتی هر یک از اعضای Pool از کار بیفتد، اعضای دیگر در Resource Pool مربوطه، وظایف آن عضو را به عهده می‌گیرند. وقتی یک سرور Management جدید اضافه می‌شود، به طور خودکار بعضی از وظایف اعضای موجود در Resource Pool را به عهده می‌گیرد. برای کسب اطلاعات بیشتر در مورد چگونگی عملکرد آن‌ها و توصیه‌هایی که در برنامه‌ی طراحی شما تاثیر می‌گذارد، از Resource Pool Design Considerations دیدن نمایید.
اگر سرور MS به هر دلیلی در دسترس نباشد، به صورت پیش‌فرض، Agentهایی که به آن وابسته هستند به طور خودکار به سرور MS دیگری سوییچ می‌شوند. به هنگام انتخاب تعداد و استقرار سرورMS ، اگر دسترسی بالا مورد نیاز باشد، این توانایی سوییچ کردن باید درنظر گرفته شود.
Agentها برای برقراری ارتباط با سایر اجزای Operations Manager به یک سرور MS متصل می‌شوند. از وظایف انجام‌شده توسط سرور Management ، فرآیند پردازش گرفتن داده‌های عملیاتی فرستاده‌شده توسط Agentها و قراردادن آن در دیتابیس عملیاتی و پایگاه داده است.
یک Management Server قادر است به صورت معمولی حدود سه هزار Agent را تحت پوشش داشته باشد. عملکرد واقعی سرور بسته به حجم داده‌های عملیاتی جمع‌آوری‌شده، متفاوت است. با این حال، سرورهای مدیریت معمولا قادر به پشتیبانی از سه هزار Agent حتی با حجم نسبتا بالایی از داده‌های عملیاتی، هستند. هیچ محدودیتی در حداکثر تعداد سرور MS در Management Group وجود ندارد. هرچند، بهترین روش، استفاده از کمترین تعداد ممکن بعد از مشخص کردن قابلیت مقیاس‌پذیری، دسترسی بالا و محدودیت‌های Disaster Recovery است.
سرورهای MS باید از اتصال شبکه‌ی خوبی به دیتابیس Operations Manager و پایگاه داده برخوردار باشند زیرا آن‌ها اغلب حجم بالایی از داده‌ها را به این Storeها می‌فرستند. به‌طور کلی، اتصالات SQL Server پهنای باند بیشتری مصرف می‌کنند و به میزان تاخیر (Latency) شبکه حساس‌تر هستند. بنابراین، همه‌ی سرورهای Management باید در همان شبکه‌های محلی همانند دیتابیسOperational و دیتابیس ِData Warehouse نصب شوند و هرگز در سراسر یک شبکه‌ی گسترده نصب نشوند. میزان تاخیر بین یک Management Server و SQL Server Instance میزبان دیتابیس‌های Operations Manager، باید کمتر از ده میلی ثانیه باشد.
