David Ziembicki on Infrastructure Architecture : ITIL

Comparing MOF to ITIL and ISO/IEC 20000

davidzi — Tue, 02 Jun 2009 03:15:12 GMT

Over on the MOF and Service Management blog, two new guides have been released detailing how the Microsoft Operations Framework (MOF) complements the ITIL and ISO/IEC 20000 standards and how MOF can be used in concert with them. While oversimplified, I’ve always described MOF as specific Microsoft process guidance for implementing the vendor-agnostic frameworks like ITIL. Where ITIL describes a standard configuration management process, MOF describes how to implement such a process using Microsoft technologies. This simplification makes it approachable to new folks who mistakenly think that MOF directly competes with ITIL.

Late last year I earned the ITIL Service Manager certification and previously had earned the MOF Essentials certification as well. I’m looking forward to digging into the MOF v4 and ITIL v3 the second half of this year. Maybe throw in TOGAF 9 as well. I really like the direction these are going in taking a lifecycle approach not a “one true framework to rule them all” approach. The hard part is getting an organization to really adopt frameworks like these, or even just the parts that work for them. It takes sustained senior leadership buy-in as well as a core team who really understand them for something like this to become ingrained in an organization’s culture. Usually that is due to a lack of focus on metrics and reporting to document the value delivered in terms of lower costs, increase customer satisfaction, etc.

Clustering SQL Server Virtual Machines

davidzi — Mon, 25 May 2009 16:00:07 GMT

When planning server consolidation initiatives, particularly if using a structured offering and tools like SVAM and MAP, underutilized database servers are a frequent consolidation candidate. Similarly, if you have already widely implemented virtualization, then virtualizing database servers for new software deployments is also a common desire. As you consolidate and create more VMs, high availability becomes a requirement, particularly for database servers.

Until recently, Microsoft did not support clustering virtual machines running SQL server. You could cluster the hosts underneath of SQL VMs but you couldn’t cluster the VMs running SQL and remain supported. Fortunately, after finishing a large amount of testing that was required, this support policy has been changed and you can now cluster SQL VMs on Hyper-V and SVVP validated virtualization platofrms. See this article for the details: 956893.

The change in support policy opens up many new consolidation and software deployment scenarios. We have a site dedicated to SQL virtualization here and a great whitepaper on virtualizing SQL 2008 here.

Given all that, does it make sense to virtualize SQL (or any database)? The answer is an absolute, definite, maybe! Virtualization fan boys (like me) will say yes in many cases. Traditionalists in high end applications (both Microsoft’s and others) in a lot of cases will say no as they bare the scars of implementations gone bad due to going cheap on hardware or underestimating demand. Their concerns should not be ignored as they are usually based on deep experience with their apps.

What I think is unacceptable are blanket statements that “Product X should never be virtualized” or “never virtualize the database for Product Y”. These are poor excuses for trying to skip proper architecture and design. Just as bad are the vendors that promote “virtualizing everything” without any regard for performance, licensing, cost, or support considerations. This is also poor architecture and design.

Using proper capacity and availability planning practices, it is not that difficult to get to fact-based decisions on whether to virtualize a server workload or not. SQL is one of the more challenging ones as the product itself provides substantial consolidation options by supporting multiple instances and multiple databases per server/cluster. Almost all of our product groups now are releasing specific virtualization guidance (SQL, MOSS, OCS, etc.)

One of the most important considerations in this design process is the maximum size of a single virtual machine supported by your virtualization platform of choice. This will be the scale unit against which your capacity and availability requirements must be compared. If your workload doesn’t scale out well and requires a large single database server with 32 cores, that will not be a good candidate (or even possible) to virtualize as the major hypervisors today only support between 4 and 8 cores per VM. If your workload is able to scale out then this limitation can be worked around by using a greater number of smaller VMs that total up to the required capacity but you must consider the cost and management considerations of doing so (more VMs to manage, more agents, more licenses, etc).

It seems to be my mantra lately but there is no one size fits all when it comes to infrastructure architecture. That’s the fun part of this line of work, the art and science of good architecture which is a process. Beware of architects and vendors showing up and declaring that there is only one true way…

Is the CMDB just a dream?

davidzi — Mon, 27 Apr 2009 16:00:24 GMT

Glenn O'Donnell over at Forrester had a great post titled “Is a CMDB even possible?” that I just came across. As you may know, CMDB stands for Configuration Management Database and is typically defined as a single repository holding all configuration items (systems, applications, etc) and their relationships. The idea of a CMDB has been a core tenet ITIL for a long time. Late last year I invested a substantial amount of time over a couple months pursuing (and achieving) the ITIL Service Manager certification (ITIL v2). In earning that credential and interacting with a lot of other ITIL trained people over the years at various customers, the CMDB concept seams to be the one concept that resonates the most with people. I think this is because it is really the only area in ITIL v2 that has a bit of a technical nature to it whereas the primary focus is process. Since a lot of folks that participate in ITIL training are IT folks, I think they tent to naturally gravitate toward the technical.

In any event, while I haven’t had time to dig into ITIL v3 in any detail yet, one of the big changes is that it moves away from evangelizing a single, monolithic CMDB and toward a Configuration Management System (CMS) that may be made up of several different management systems. Glenn’s article goes into the reasoning for this and he has some thoughts on where this might be going in terms of federating different management systems.

The rush toward the holy grail of a single CMDB consumes a lot of people and resources when the newly “indoctrinated” come back from ITIL training. I think that outcome was the biggest flaw in the definition and delivery of ITIL v2 and I’m glad it has been changed in V3 to a much more feasible approach.

In terms of the Microsoft stack, obviously System Center is where these concepts are and will be instantiated. System Center Service Manager will be bringing a lot of capability in this space. This week at MMS there are at least 9 sessions on Service Manager.