Thoughts on Infrastructure : Common Engineering Criteria

Of Instrumentation and Management Packs

BjarneD — Sat, 02 Jun 2007 01:59:00 GMT

Why should you care?

What is a Management Pack? What about Health Models? What's instrumentation good for? And, finally we should you care about all of it? ......

Let's take the last of my rhetorical question first: Why should you care? As an IT pro implementing Microsoft server products or 3rd party products running on Windows you need all the help you can get. I know how this sounds, but trust me, I'm not pointing fingers at any one, nor am I trying to patronizing anyone. With all the variables of setting up a server environment, it's complex enough, the last thing you need is to further add complexity by adding multiple server applications from both Microsoft and others to the mix. And, in case it's not completely clear, I'm referring to managing these applications.

Recent studies have shown that administration and management of server applications is increasing at a whopping 8 times the annual spend on the servers themselves. Some of that complexity comes from the fact that achieving scale (across many users and servers) is inherently complex, some of it comes from the fact that we all trying to solve these problems using whatever Shinny New Ultimate Technology that comes along. A good example of this is Virtualization. We are starting to see that our customers are using Virtualization as a means to consolidate the number of physical servers that they have in their datacenter onto bigger boxes. Now, using Virtualization doesn't necessarily solve the underlying problem (of managing many physical boxes) it simply consolidates many (virtual) instances of OS's and applications onto a smaller number of boxes. Unless you add Virtualization Management tools (such as the recently announced System Center Virtual Machine Manager) to the equation, you still have to care and feed the individual OS's and applications with regards to patches, etc. In other words, you have realized none of the benefits of scale and all of the issues, and you now have a potential single point of failure to boot!

So, you ask, what do we do to solve the issue? The real answer is instrumentation. Making sure that the applications themselves are more intelligently aware of their environment and are able to communicate the root cause of whatever problem arises to IT operations (through a management console). This leads us to my remaining two rhetorical questions around Management Pack and Health models.

Management Packs

Systems Center Operations Manager utilizes management packs to provide intelligent operations management for a wide variety of your server applications. Management packs monitor a wide array of server health indicators which enable them to call attention—often preemptively—to many critical events that require administrator intervention. Monitoring is augmented by in-depth knowledge base content associated directly with the relevant alerts included in the management pack module, providing prescriptive guidance for the administrator to quickly resolve outstanding alerts.

To provide the best possible management of your infrastructure, we encourages management packs to be developed by the application providers who have the knowledge to embed the necessary operational intelligence to aid you in maintaining your system.

In the Management Pack Catalog, you will find not only management pack provided by Microsoft, but a number of non-Microsoft management packs that allow MOM to manage a variety of other applications as well.

Management Packs in Operations Manager 2007 are XML based and use the Service Modeling Language (SML) language to define health models and store knowledge documents in XML.

Health Models

Health models define what it means for a system and its components to be healthy or unhealthy, and define how a system and its components move in and out of these states. Good information about a system’s health is necessary for maintaining, diagnosing, and recovering from errors in applications and operating systems deployed in production environments. Health models capture system events and instrumentation for your software.

Providing the right view of an application, what it looks like when it is and isn’t functioning normally, and providing the right knowledge to help you troubleshoot system and application issues.

As you can probably see, Health models and Management pack go hand-in-hand to allow you to meet your service level agreements (SLAs) to your own customers, whether they are internal or external to your business.

Lastly, let me conclude with what we are doing to ensure the adoption of this model based approach across Microsoft infrastructure server products (also know as the shameless "plug"):

Common Engineering Criteria Infrastructure Management

Let me point out what we done so far using the Common Criteria:

2005 Criteria

MOM 2005 Management Pack Support at Launch

To help businesses reduce the cost of managing infrastructure, all server products will have a MOM Management Pack available at launch. The management pack will be serviced on the same schedule as the core product. MOM packs will provide:

Event and performance processing alerts.
Basic views that graphically map performance and event trending information.
State Monitoring view (green/yellow/red) state for managed entities.
Tasks.

Recently, we've updated the Management requirement to include v3 Management Pack capabilities and added the new Health Model capabilities to the requirement.

2008 Criteria

New Health Model to improve Troubleshooting

IT often have to perform an "information treasure hunt" when presented with events and trying to troubleshoot them. The documentation of events is often inconsistent between product documentation, the Windows Event Viewer, and documents on the web.

To solve this problem, all server products must create and maintain a health model based on the standard Service Modeling Language (SML) including relevant operational events and performance counters, in addition to identifying potential failures and define diagnose and recovery information.

Improved Management Pack(s)

The new version of the Management Pack specification released as part of System Center Operations Manager 2007 offers significant improvement in system monitoring, availability, and health through centralized and proactive management. In order to ensure that IT can continue to support existing products in addition to implementing new products by taking advantage of the new Health Model and Management Packs, all server products will continue to also ship Microsoft Operations Manager 2005 Management Packs.

If you would like to know more about Health Models and Management packs, here's a couple of relevant links:

Common Engineering Criteria Homepage

Microsoft Dynamic Systems Homepage

Microsoft System Center Homepage

How To Develop A Management Pack for System Center Operations Manager 2007

64-bit and Virtualization - Mainstream?

BjarneD — Fri, 06 Apr 2007 00:45:53 GMT

Virtualization will drive the adoption of 64-bit computing.

Back when we first started with the program we refer to as the Common Engineering Criteria (CEC), we pushed support for Virtualization and 64-bit processors across our products. Now it looks as if we're going to get help making them mainstream from customer demand, no less.

In case you don't know what Virtualization is or what 64-bit means, let me provide a short primer.

Effectively, Virtualization (Virtual Server and Longhorn Server's Windows Virtualization) creates a sandbox, where the application(s) running believe that there's nothing else running beside them and an OS. Access to hardware is provided through the Virtualization layer and it can support many different OS's. In many ways you can argue that we are simply taking the vitalization of resources in Windows one stop further.

64-bit is simply the next generation of processors. Both Intel and AMD have been pushing 64-bit for a while, albeit using different designs initially. There are many benefits of 64-bit computing, and it is not the purpose of this blog to go into them all, but let me summarize:

Hardware support for Virtualization
Support for a vast memory space
Better hardware protection from rogue programs

As I alluded to previously, we pushed the adoption of these two technologies since the initial set of the CEC, published in 2004. If you don't know what the CEC is you should read one of my previous blogs (Common Engineering Criteria - Consistency and Predictability).

It was obvious to us that adoption of 64-bit in general and Virtualization in particular was not a matter of if, but when. We were surprise how fast hardware caught up with regards to servers. Today it is virtually impossible to purchase new server hardware that is not x64-based.

In our CEC for 2008 we are dialing up the support for 64-bit (x64 specifically) system in the server space. We seen over the last year of so that customers have started starts to move from experimenting with vitalization to actually deploying in their data centers, although not in vast numbers initially.

We are assuming that Virtualization and 64-bit (in particular x64) will be mainstream by 2009. And I'm suggesting that the former will push the latter.

Huh?

Let me expand on that. With Windows Virtualization for Longhorn server (codename Viridian) we are introducing a new generation of Virtualization for Windows Server, among other things we taking advantage of the hardware support for Virtualization that AMD and Intel are providing with the their new generation of x64-bit processors (codename VT and Pacifica, respectively). This basically means that the Virtualization software no longer will have to do the heavy lifting of pretending that the OS inside it is running directly on hardware. Remember that Intel's x86 processors provide several levels of protection : Ring 0 through 3. x86 based OS, such as Windows run typically run in ring 0, with applications and most services running in Ring 1 -3. Both processors will provide new Virtualization extensions to allow an the Virtualization to run at a higher level than 0 (with better protection and higher priority that both ring 2 and ring 0), whilst providing the capability of allowing OS's to run in guest partitions on top of it in as though they were running in Ring 0. If this makes your brain hurt, think of it as if the hypervizor runs in ring -1.

In Windows Server "Longhorn" this means that we can provide a very thin OS (referred to as the Hypervizor), on top of which the actually OS's run. This very thin OS will provide a Master OS that controls the other OS's. Effectively, this will give us better performance as well as better control.

Without going to deep into what Virtualization is going bring us and what inevitable challenges we come across, I believe that our customers would want to use the new Virtualization capabilities we are provide together with Windows Server Longhorn.

However, there's a catch, the new hardware capabilities that I've just described above are only provided on Intel's and AMD's 64 bit processor. This means that in order for our customers to take advantage of these new capabilities, they'll have to move the 64-bit. It's my personal opinion that there's sufficient value in doing so, including the new Virtualization capabilities. Also, bear in mind that even though the hypervizor will run on 64-bit systems, it will support both 64- and 32-bit guests OS's.

Now, even in the longer term, it's unlikely that all applications will run in a virtualized environment, but a significant percentage will. Most likely, there will continue to be a number of applications that have special roles (anti-virus, etc) or requires access to specialized hardware devices, thus preventing these from taking advantage of the Virtualization technologies.

In conclusion, today we mandate that, unless there are specific hardware reasons, all infrastructure server products be capable of running in a virtualized environment (for more details, check the CEC homepage). We also mandate that all infrastructure server products support 64-bit. It's our goal that we will have completed the transition to 64-bit support (x64) of of our infrastructure server software by the end of 2009.

Clearly, there's a bright future for 64-bit systems and Virtualization, now we just need to manage those, but that is a topic for later.

If you wish to give me feedback as to what additional criteria (common features or technologies) we should consider in the years ahead feel free to post comments to this blog.

For more information go to the following site:

http://www.microsoft.com/windowsserversystem/cer/overview.mspx

Common Engineering Criteria - Consistency and Predictability

BjarneD — Sat, 20 Jan 2007 12:15:02 GMT

Over the past nearly 4 year Microsoft's Servers have been going through a transformation. Many are the times that we have talked about better together, integrated innovation, etc. In 2003, some of our executives decided that now was the time to do something about it.

They decided to start a process - or a program called "Common Engineering Criteria". The whole point was that all server teams would agree on doing certain things across all their products in certain releases.

The simple idea being that our customers and partners could expect a certain level of consistency across all Microsoft Server products within a release year and that we would be very public about what we were going to do and when. Even to the point that we would maintain a public scorecard that listed the status of the individual server products vis-a-vis the common engineering criteria.

It sound really simple, but this needed to work across 20+ products with different target markets, different levels of maturity in the market, different degrees of complexity.

Adding to the complexity was also the fact that computer software aren't developed in weeks, but years. The effort required the various groups within Microsoft to agree on what should be done in all server applications and how up to 2 years in advance.

The first list of Common Engineering Criteria was published in the summer of 2004 at TechEd in the US. This represented the common technologies and features of the 2005 products. this may sound strange but as you may know, Microsoft names the enterprise server products after the year (actually the Microsoft Fiscal Year) in which they ship. Consequently, the list of Common Engineering Criteria announced applies to SQL Server 2005, Live Communications Server 2005, Virtual Server 2005, and Microsoft Operations Manager 2005. Maybe not an impressive list, but a start nonetheless.

In the years since the summer of 2004 we have been adding more server products and more criteria.

It's important to explain a couple of ground rules. As a general rule all server product shipping in a given model year will comply with the criteria for that year in addition to the criteria from the previous years. However, some times there are reasons why a particular product cannot comply with a certain criteria.

We have a process for handling those exceptions and can grant a given product group an exemption for the complying with the criteria if our executives decided that there are good (business and/or technical) reasons why aparticular server product can't comply with a particular criteria. For example, the criteria from 2005 requires that all server products be tested to run inside Microsoft Virtual Server 2005, both in test and in product. Well, as you may have guessed Microsoft Virtual Server cannot run inside Microsoft Virtual Server 2005. The hardware simply will not support it (besides the fact that it would be completely and utterly ridiculous to run Virtual Server inside Virtual Server). Needless to say, Microsoft Virtual Server 2005 was granted an exemption and you can find both exemption as well as the explanation why on the Common Engineering Criteria Website listed below.

We have strict requirements as to when we start disclosing what server product will comply with the criteria and what exemptions may have been granted. As you can see on the website, we begin tracking the individual server products when they ship their first public beta.

Also, core to this process is our wish to be as transparent to our customers as we possibly can as to what we are going to do with our server products, so we up until last year (2006) we published the additional criteria and the new products that would be measured against them every summer at TechEd. Last fall we decided to change that such that we would announce them a full 2 years in advance. So at IT Forum on Barcelona we announced the 2008 criteria following our announcement of the 2007 criteria at TechEd in the summer.

We come a long way, but there plenty work for us ahead. As you can see from the website we now track 10 of our server products (about 50% of the target server products) and the list of criteria is growing year over year. Not only are we adding server products and criteria to the list, we are not growing the number of exemptions at the same pace, which clearly indicates that the initial concept behind the Common Engineering Criteria is working.

If you wish to give me feedback as to what additional criteria (common features or technologies) we should consider in the years ahead feel free to post comments to this blog.

For more information go to the following site:

http://www.microsoft.com/windowsserversystem/cer/overview.mspx