System Center Manager for Azure and AWS

Introduction: Enterprise on-premise server management was a well-known routine that was arguably facilitated very well by System Center Operations Manager. It involved monitoring an asset using several sources on that computer and providing a central console to view this information across assets. It enabled consolidation of tools while bringing a single console to monitor services and assets from simple to complex. With the move to cloud, the assets exploded in size and regions including and not limited to a variety of servers, platforms, hardware and vendors. We discuss how this was overcome technically in brief.

Description: The Systems Center Management Pack for Windows Azure lets us now instrument Azure assets for availability, performance monitoring and reporting using SCOM. The Azure Fabric management pack discovers PaaS and IaaS components from Azure subscriptions and communicates directly with an Azure web service to deliver cloud based management data to SCOM.

At the heart of this technology is the notion of a cloud web service and agents on the inventory. The SCOM agent is already fluent in gathering data from a variety of sources and this was made easier by the operating system features that remained consistent if not better across versions. With the explosion of data sources across assets, a central cloud services scales up to meet the challenge. The SCOM Console continues to provide a holistic picture while providing the detailed drill down that it used to for every single asset.

However, organizations were known to have a heterogeneous environment consisting of a mix of Windows and flavors of Linux. Having multiple monitoring and alerting technologies on different operating system flavors was traditionally a maintenance challenge but limiting the ability to scale to a public cloud made it more so.  The SCOM agent from windows server allowed monitoring Unix/Linux flavors in existing infrastructure with just a few more steps:

1)      Create accounts to be used for monitoring and agent maintenance.

2)      Add the created accounts to the appropriate UNIX/Linux profiles

This  was facilitated by Management packs for Unix/Linux from Microsoft as shown here and with guidance as published here

With the move to Cloud, the SCOM agents for these OS Flavors were now deployed to Azure VM instances and with the discovery of these instances, the Azure Fabric management pack would facilitate the inside and outside perspectives of the cloud hosted VMs. If an application went down, the failure could be quickly narrowed down to the VM OS, the Azure Service or the Azure storage.

However the same could not be said for multiple public clouds such as Azure and AWS. With the availability of Amazon EC2 Systems Manager that has changed too and now we can automatically collect software inventory, OS patches, system images, and configure both Windows and Linux Operating systems.

With new era convention of facilitating programmatic access to all the applications and services, there are now APIs to talk to either cloud systems managers. Thus organizations can choose leverage and promote a consistent terminology for both these clouds.

Even with hybrid resources such as containers and clusters, production support may be standardized with system manager spanning these resources as well. Containers and clusters provided their own monitoring and health management solutions. From a systems center perspective, it made no difference if we queried the information directly from the operating system via our own agent or via the host that makes an API available so long as the information can be standardized.  System centers already work with different versions of Operating System flavors and technologies from hybrid cloud. At the same time, well known container vendors and proprietary cluster managers already make web APIs ubiquitous.  Mashing up the APIs with the expectations of the System Center for a uniform and consistent view to the layer above, then becomes straight-forward. However care must be taken to make sure that behavior and quirks of the vendor systems are tolerated.  Whether it is from System Center to the layer below or within the containers and clusters layer, the techniques for monitoring and rotations involving setup and teardown are similar and the best practice for both may suitably be shared.

Conclusion:  Systems Center Managers are available at cloud level doing away with proprietary and custom software both in house or purchased for managing the IT assets of the organization.