Adapt your capacity process to support Cloud

Potentially there are a large number of areas within a “standard” capacity process that need to be adapted to support Cloud solutions, but based on experience I believe the following topics represent the key areas.

• Process interfaces
• Tooling and monitoring
• Scope and Maturity

To effectively manage the capacity of “The Cloud” stronger or at least redefined process interfaces will be required.  Closer links with financial processes will be key to understanding the costs associated with the various options Public, Private, Hybrid etc and using this information to assess which will best meet the needs of the business.  The determination of these costs and sizing the environment correctly will be critical in ensuring that using “The Cloud” actually pays. 

Strong configuration and change processes will also be essential in tracking all elements of a service with the focus moving away from the component level information and towards the interconnectivity between these components. 

I believe the relationship with Service Level management will require increased visibility when transitioning to the cloud, both from the perspective of managing the customer expectations and in capturing and documenting key service level performance metrics.  A keen insight into both the service architecture and which Cloud implementation is best suited will be essential in ensuring the required service levels are continually met during and after any transition.  As the popularity of public clouds expands, demand management as providers over commit resource to drive down costs and the available Capacity will become far more of an issue and careful stewardship of the performance targets will be a valuable asset.

The tooling and monitoring requirements will need to be re-evaluated prior to moving to a Cloud implementation  as the traditional capacity focus at the component level will become less important,  with an aggregated service view being key to understanding the service performance and usage.  When selecting a tool try to ensure that it will monitor across the Enterprise and have the flexibility to import a wide variety of data sources.  These information sources can then be used to provide a unified reporting portal to assist in capacity monitoring and planning for the Cloud, service and underlying components.  In a cloud implementation rather than the components being the first bottleneck it is likely the network will be the focal point for initial performance monitoring and planning; more specifically the network links between your organisation and the cloud provider.

Ultimately I believe the biggest changes for the capacity management process will be the perceived scope of the process and the required maturity.  In my experience as a consultant working for a number of large scale organizations the majority will have a detailed understanding of the component level side of the business i.e. the servers, a degree of knowledge at the service level, but little knowledge of the business and financial aspects.  To successfully manage a Cloud implementation that meets the required service levels and provide actual financial savings, the process will need to cover all aspects of both the service and the underlying infrastructure, including networks and potentially facilities.

A detailed understanding of the business needs and drivers and again how these will relate to services and infrastructure is essential in a Cloud environment and to a lesser degree any large scale virtualization project.

Achieving this level of maturity and integration presents a considerable challenge for a capacity management team, but if achieved will benefit both the business and raise the profile of capacity management and ITIL immeasurably.

Come along to our free webinar on ‘Cloud Capacity Management’ this Wednesday

https://www.metron-athene.com/services/webinars/capacity-management-webinars.html

Charles Johnson

Principal Consultant

Cloud Capacity Management

Capacity Management continues to evolve as a practice with new environments in IT.

The inclusion of the Cloud infrastructure within IT requires the Capacity Management discipline to be extended. There are several variables in dealing with Cloud Capacity Management.

Many of them depend on where the Cloud infrastructure is hosted and the type of control a user has over the environment. On-Premise hosting, Hybrid hosting or Cloud provider hosting fit into the equation.

I'm presenting a webinar on March 15 which will discuss the variables that you need to consider when extending your Capacity Management to the Cloud.

I'll be looking at:

• Capacity Management in general
• The variables introduced by the Cloud
• An overview of the most prominent Cloud offerings
• How to plan to move your environment into the Cloud
• What metrics you need to capture for the Cloud Infrastructure
• Reporting Examples

Don't forget to join me, you can register for your place now

https://www.metron-athene.com/services/webinars/capacity-management-webinars.html

Charles Johnson

Principal Consultant

        

The changing face of Capacity Management - Private Clouds (4 of 4)

With a private cloud, a key output of any capacity management process must be information to the internal customers.  In order to get this information, capacity and performance data must be captured and stored.

As an example, let's consider a VMware vSphere implementation that was put in place to replace an organization's Windows and Linux estate.

First of all, this data must be at the right granularity and at the right levels -- as I mentioned earlier, it's not enough to know what's happening inside the virtual machine or even just within the service itself.

Important data includes availability information, utilizations and allocations, service level agreements (how often are they violated) and financial data (costs, charges, and pricing) as well.

On top of data that's specific to that group, it's probably a good idea with a private cloud to include some "macro" level data.  How much overall capacity is there within the private cloud?  What are the overall utilizations?  How much available capacity is there in the entire environment?

Again, it's easy to over-allocate or under-allocate by a small amount for each internal group or application, but it's just as important to show the "overall" view because it is incredibly costly to an organization if the overall environment is over-built (too much money spent on hardware, software, etc.) or under-built (lost business, unhappy customers).

So it stands to reason that any capacity management solution for a private cloud should capture data from a VMware environment at the datacenter, cluster, resource pool, host, and VM level. Provide you with data capture at a very granular level and have the ability to roll up into multiple levels of summaries over time.  

It’s important to be able to incorporate business statistics, financial and costing information in to the database.

Reports and alerts (performance and trending) including these types of data help you to communicate effectively with your internal customers and your organization's management, in terms they understand.

It will come as no surprise that we have expertise in producing and implementing capacity management processes or that athene®, along with our capture packs, provides everything you need to successfully capacity manage your cloud environment.

Visit our website www.metron-athene.com

Rich Fronheiser

Chief Marketing Officer

The changing face of Capacity Management - Private Clouds(3 of 4)

So, how does capacity management change when moving from a server-oriented or client-server environment to a private cloud?

First, it's important to understand that most organizations have many internal customers -- and that moving to a private cloud eliminates the separation of computing resources that client-server computing had always promised.  For some of those customers, this may be an uncomfortable arrangement and it's important that capacity management and the regular communication of capacity and performance information be in place to satisfy those customers.

Performance and capacity monitoring must be done at multiple levels.  While it's possible (and useful) to monitor what happens inside virtual machines, it's far more crucial to monitor from a more global perspective.  How much additional capacity is available for unseen peaks and for quick virtual machine deployments?

Over-procurement and over-allocation of resources to one internal group may not be a major expense.  But when resources are over-allocated to dozens of internal groups, the incremental cost to the organization itself could be quite large.  Furthermore, over-allocation of physical resources to manage the cloud means that hardware is being purchased too far in advance, likely for more money than if those purchases were delayed until needed.  Of course these concepts are nothing new -- it's just that within the cloud those additional purchases may be seen as necessary overhead, when in fact it's just a problem of over-allocation pushed up from individual customers through to the organization itself.

Likewise, under-procurement and under-allocation of resources can cause problems in a cloud environment.  One of the selling points of the cloud is rapid deployment and complete flexibility - when a customer needs resource, it can be quickly made available.  If a company doesn't invest in having *enough* resources available, then there is little advantage for internal customers to agree to a move to a private cloud.  Further, the inability to provide sufficient resources in this model means that many internal customers may not be meeting service level agreements at crucial times.

In my final instalment on Friday I'll talk about implementing a capacity management mindset that specifically deals with some of the challenges of working with a private cloud.

Rich Fronheiser

Chief Marketing Officer

The Changing Face of Capacity Management - Private Clouds (2 of 4)

Looking at the present and future of Capacity Management, it's clear that managing cloud environments is incredibly important as more organizations decide to move much of their computing to the cloud.

The first type of cloud I want to cover is the private cloud.  

In many cases, a private cloud implementation involves organizations using virtualization and other technologies in-house that public cloud providers use when delivering their services.  In a traditional cloud implementation, services are delivered via the Internet.  In a private cloud, services may be delivered internally by other means.

For example, an organization could decide that it wants to change how it manages its Windows and Linux estate.  The company at this point decides to make an investment in VMware and turn all the existing physical servers into virtual machines to be managed centrally by a VMware administration team and using a lot of the automation VMware builds into vSphere.

Sounds good, right?

Well, one of the arguments for cloud computing is that clouds relieve the organization from day-to-day management and computing becomes much more of a utility (turn on the switch and it just works).  In private clouds that are implemented in-house, none of this is true.  Companies have to buy, build, and manage the environments and also deal with the complexity of having many applications running simultaneously in a virtual environment.

Still, companies feel that this is a good investment and, in many cases, so do I. However, it's just as crucial, probably more so, that the environment be properly planned and managed.  In a typical application that runs on a server if the server runs into capacity and performance problems, only one application or service is affected.  In a private cloud, a shortage of capacity could affect all of the applications and services running within that cloud.

As of right now, most companies who are implementing virtualization technologies internally (and are taking advantage of technologies that allow for the rapid and seamless deployment and reallocation of resources) are setting up their own private clouds.

 
On Wednesday  I'll deal with some of the things that need to be considered when looking at a private clouds.

Rich Fronheiser

Chief Marketing Officer

The changing face of Capacity Management (1 of 4)

The view of capacity planning when I started in this profession over 15 years ago is different now than it was then.  Yes, many mainframers have told me that they had virtualization back then and nothing new is really new again.  I'll concede that to a certain degree, but for those of us who came into a client-server world, things have changed dramatically.

Back then, planning for me was the building, calibrating, evaluating, and creating scenarios revolving around analytic models for a single system.  Workloads were the items of importance and quite frequently we looked at technical numbers and pretty much ignored the business.

Things have changed.

Today I spend more time talking about capacity as the overall amount of capacity remaining in a virtualized datacenter rather than the capacity remaining on a server.  I spend more time talking about central storage and SAN performance than I do talking about locally-attached storage.  And for me the workload view has been replaced in many cases with a real-user transactional view we couldn't hope to get back in the days before Y2K.  It's the only way we know whether we're meeting those SLAs.  With services hitting many different tiers (and potentially disappearing into the cloud), that transactional view can actually be the easiest way to measure performance.  How much of that transaction is visible to the planner depends on the cloud implementation and on the service provider.

So, the cloud. Sure, it would be ideal to have knowledge of everything that's happening inside the cloud, but if you're paying for software-as-a-service (SaaS), you probably aren't going to get that from your vendor -- and, to be honest, why would you want that view?  You are paying a premium in order to reduce computing down to the utility level -- flip the switch and the light comes on.  When I turn a light on in my kitchen, I don't think about the wires, the devices, or the electrical grid -- I just want to know that the light will come on.  And I take for granted that there's enough electricity in the system to service all my household needs.

But we pay a price for that, and there's a chance that instead of paying for excess capacity in your data center, you're paying for excess capacity (for yourself and for other clients of the vendor) in the cloud.

In the next few installments, I'll start looking at clouds in more detail.  I'll focus on the different types of clouds, the different types of services that can be purchased from cloud providers, and how that affects how you'll do capacity planning.

Rich Fronheiser
Chief Marketing Officer

I'll complete my series by taking a look at some of the implications around sizing our cloud resources, more specifically systems being Undersized and Oversized and what we should be doing to get it right. 

As mentioned in the Cloud Computing introduction, in a cloud computing environment you should be able to self provision computing capabilities. One of the primary steps taken before deployment, would be to perform Application Sizing.  This process enables you to accurately provision the correct amount of resource required to support the application(s) avoiding any potential performance issues and any unnecessary costs. Without this you could run the risk of being undersized which can lead to poor performance and Service Level Agreements (SLA) being affected.

Cloud providers will implement limits to restrict usage.  This of course can be increased for a cost.  Even if the initial resource usage costs are low, there could be higher costs down to the financial impact of possible SLA penalties and / or loss of business or productivity due to poor application performance and this in turn can damage the reputation of the business. Cloud bursting may be required if you are undersized and need some additional capacity very rapidly and this approach can incur higher usage premiums.   Over sizing or overprovisioning. The key here is whether you have provisioned too much capacity?  You may have over provisioned to wholly satisfy an SLA due to strict penalties, but it could be costing you far more than is actually required.

Gartner state "that most organizations overprovision the resources in their IT environment by more than 100% with an average utilization of physical environments of only 10% and virtual environments of 35%".  (extracted from “Does Cloud Computing Have a ‘Green’ Lining? – Gartner Research 2010)

This is primarily to cope with peak workload demands, which typically do not occur very frequently.  Save costs on resource usage by provisioning the optimum level to satisfy all criteria, i.e. SLA’s.  Costs such as Software Licensing where you are licensed per CPU would incur more costs because you have provisioned more CPU’s than necessary.

How does over capacity affect other services in the cloud?  Are other services restricted because capacity has been over provisioned?  Could this lead to poor performance?
Single-threaded applications on a vSMP VM do not gain any performance benefit, moreover resources are not only wasted, they affect the performance of the underlying ESX host because they have to manage and provide resources to the associated worlds (processes).  

A virtual machine is a group of worlds and each vCPU assigned has a world plus one for the Mouse, Keyboard and Screen (MKS) and one for the Virtual Machine Monitor (VMM)

Over provisioning leads to VM Sprawl.

Memory resources can be shared across virtual machines, however over provisioning puts further pressure on ESX to manage allocation of resources to virtual machines. 

Our objective therefore, is to get our On Demand Sizing just right. If you need help with right sizing for Cloud then take a look at our Cloud Capacity Management Service

https://www.metron-athene.com/services/consulting/capacity-management-consulting.html

and don't forget to come along to our 'Cloud Capacity Management' webinar on March 15

https://www.metron-athene.com/services/webinars/capacity-management-webinars.html

Jamie Baker
Principal Consultant

Virtualization underpins Cloud Computing, through resource pooling and rapid elasticity (2 of 3)

As mentioned previously to be considered a cloud a service must be On Demand, provide Resource Pooling and also Rapid Elasticity.  And whilst Virtualization in general can provide the majority of these features the difference is that a private cloud using internet based technologies can actually provide the mechanism for end users to self provision virtual systems. Think of this as the ability to self-check in at an airport or print your boarding pass from home. 
You login to a browser with a reference code, plug in some personal details and print or walk up to a screen enter a few details and voila out pops the boarding card and off you go (business or hand luggage only) otherwise off to bag drop before you go - virtually eliminating the need to queue up at a check-in desk to get your boarding card. 

But it's more than just virtualizing systems and hosting them internally, it’s about giving control to the end user.  

Now of course, some administrators may wince after reading this but there are ways in which self- provisioned systems can be controlled by using the virtualization technology that underpins cloud technology.  Using resource pools within your private cloud gives you the ability to control resources via limits and shares and / or reservations so you can specify the amount of resources that users are allowed to provision.  These control settings can also be changed very quickly to increase or decrease the amount of resources that are available within that pool.  This helps prevent over specification and VM sprawl.

Another way to control resource deployment and / or usage is to internally charge.  Users and their departments will soon reign back on creating over provisioned systems if they are charged on their system configuration usage rather than just on the usage itself.   
It can be quite difficult to implement some form of internal charging. What do you charge with?  Maybe by utilizing project codes or some other internal monetary system?
On Monday I’ll be looking at Capacity on demand and how you can get your sizing right.

Jamie Baker
Principal Consultant

When we refer to a "cloud" what is it that we actually mean?(1 of 3)

We know that the cloud provides computing resources for customers to use and these resources are then charged at a monetary value accordingly.
Cloud providers deliver and manage services by using applications such as VMware's vCloud Director.  These cloud applications provide benefits such as:

·         Increased business agility by empowering users to deploy pre-configured services or custom-built services with the click of a button

·         Maintaining security and control over a multi-tenant environment with policy-based user controls and security technologies

·         Reducing costs by efficiently delivering resources to internal organizations as virtual datacenters to increase consolidation and simplify management

So, to be considered a Cloud it must be:

·         On Demand - cloud aware applications can in most cases automatically self provision resources for itself and release them back as necessary. 

·         Resource Pooling - freeing up unused resources provides the ability to move these resources between different consumers’ workloads, thus quickly and effectively satisfying demand.

·         Rapid Elasticity - rapid means within seconds to minutes (not in days).  In a Virtual Cloud Environment, to Scale Out or In would also cover the ability to provision new ESX hosts, rather than just scale to new virtual machines.

Virtualization technology encompasses these three requirements and underpins Cloud Computing.

Many businesses are now using these advantages to move away from overinvestment in rigid, legacy-based technology and adopting cloud-based services which are highly scalable, technology-enabled computing consumed over a network on an as-needed basis.

Cloud Types

Cloud types provide the “computing as a service” model to help reduce IT costs and make your technology environment a responsive, agile, service-based system.  These Cloud "types" or Service Delivery Models are commonly known as:

·         Software as a Service (SaaS) - External Service Providers (ESP) such as Amazon can provide access to a specific software application, e.g. Business Mail Service Desk and charge as necessary.  You would access this application via a "thin client" typically a web browser.

·         Platform as a Service (PaaS) - This enables you to deploy supported applications into the Cloud with some degree of control over what environment settings are required.  You do not have any control over the resources provided to host these applications.

·         Infrastructure as a Service (IaaS) - This provides the ability to provision your own resources and you have full control over what operating systems, environment settings and applications are deployed.  The cloud provider still retains full management and control over the infrastructure.

The Cloud or "Clouds" as we know them are categorized by location and ownership, typically referred to as Public / Private or Internal or External clouds.  In addition there are Community and Hybrid clouds whereby a Community share the cloud and are bound by a common concern or interest and Hybrid where you have a composition of two or more Private or Public clouds.  This allows for data and application portability between clouds to occur.  VMware introduced the vApps functionality specifically for this.

Most organisations will tend to lean more towards having exclusive "Internal" cloud services and possibly "Hybrid" cloud services (a mixture of Public and Private clouds).  You may find that critical or data sensitive applications are always kept within the organisation and in some cases Testing and Development applications are ported to the Public Cloud where it is more cost effective to do so.  There may also be the use of SaaS within the organisation which would be external to the business.

Just to reiterate, Virtualization underpins Cloud Computing, through resource pooling and rapid elasticity and to avoid any confusion, I will be explaining the primary difference of say a Private or Internal Cloud over Virtualization on Friday.
In the meantime register for our next webinar Cloud Capacity Management' 
https://www.metron-athene.com/services/webinars/capacity-management-webinars.html

Jamie Baker
Principal Consultant

The changing face of Capacity Management - Private Clouds (5of 5)

With a private cloud, a key output of any capacity management process must be information to the internal customers.  In order to get this information, capacity and performance data must be captured and stored.

As an example, let's consider a VMware vSphere implementation that was put in place to replace an organization's Windows and Linux estate.

First of all, this data must be at the right granularity and at the right levels -- as I mentioned earlier, it's not enough to know what's happening inside the virtual machine or even just within the service itself.

Important data includes availability information, utilizations and allocations, service level agreements (how often are they violated) and financial data (costs, charges, and pricing) as well.

On top of data that's specific to that group, it's probably a good idea with a private cloud to include some "macro" level data.  How much overall capacity is there within the private cloud?  What are the overall utilizations?  How much available capacity is there in the entire environment?

Again, it's easy to over-allocate or under-allocate by a small amount for each internal group or application, but it's just as important to show the "overall" view because it is incredibly costly to an organization if the overall environment is over-built (too much money spent on hardware, software, etc.) or under-built (lost business, unhappy customers).

So it stands to reason that any capacity management solution for a private cloud should capture data from a VMware environment at the datacenter, cluster, resource pool, host, and VM level. Provide you with data capture at a very granular level and have the ability to roll up into multiple levels of summaries over time.  

It’s important to be able to incorporate business statistics, financial and costing information in to the database.

Reports and alerts (performance and trending) including these types of data help you to communicate effectively with your internal customers and your organization's management, in terms they understand.

It will come as no surprise that we have expertise in producing and implementing capacity management processes or that athene®, along with our capture packs, provides everything you need to successfully capacity manage your private cloud environment.

If you’d like more info call us or visit our website www.metron-athene.com

Rich Fronheiser

Chief Marketing Officer

The changing face of Capacity Management - Private Clouds(4 of 5)

So, how does capacity management change when moving from a server-oriented or client-server environment to a private cloud?

First, it's important to understand that most organizations have many internal customers -- and that moving to a private cloud eliminates the separation of computing resources that client-server computing had always promised.  For some of those customers, this may be an uncomfortable arrangement and it's important that capacity management and the regular communication of capacity and performance information be in place to satisfy those customers.

Performance and capacity monitoring must be done at multiple levels.  While it's possible (and useful) to monitor what happens inside virtual machines, it's far more crucial to monitor from a more global perspective.  How much additional capacity is available for unseen peaks and for quick virtual machine deployments?

Over-procurement and over-allocation of resources to one internal group may not be a major expense.  But when resources are over-allocated to dozens of internal groups, the incremental cost to the organization itself could be quite large.  Furthermore, over-allocation of physical resources to manage the cloud means that hardware is being purchased too far in advance, likely for more money than if those purchases were delayed until needed.  Of course these concepts are nothing new -- it's just that within the cloud those additional purchases may be seen as necessary overhead, when in fact it's just a problem of over-allocation pushed up from individual customers through to the organization itself.

Likewise, under-procurement and under-allocation of resources can cause problems in a cloud environment.  One of the selling points of the cloud is rapid deployment and complete flexibility - when a customer needs resource, it can be quickly made available.  If a company doesn't invest in having *enough* resources available, then there is little advantage for internal customers to agree to a move to a private cloud.  Further, the inability to provide sufficient resources in this model means that many internal customers may not be meeting service level agreements at crucial times.

In my final instalment on Monday I'll talk about implementing a capacity management mindset that specifically deals with some of the challenges of working with a private cloud.

Rich Fronheiser

Chief Marketing Officer

The Changing Face of Capacity Management - Private Clouds (3 of 5)

Looking at the present and future of Capacity Management, it's clear that managing cloud environments is incredibly important as more organizations decide to move much of their computing to the cloud.

The first type of cloud I want to cover is the private cloud.  

In many cases, a private cloud implementation involves organizations using virtualization and other technologies in-house that public cloud providers use when delivering their services.  In a traditional cloud implementation, services are delivered via the Internet.  In a private cloud, services may be delivered internally by other means.

For example, an organization could decide that it wants to change how it manages its Windows and Linux estate.  The company at this point decides to make an investment in VMware and turn all the existing physical servers into virtual machines to be managed centrally by a VMware administration team and using a lot of the automation VMware builds into vSphere.

Sounds good, right?

Well, one of the arguments for cloud computing is that clouds relieve the organization from day-to-day management and computing becomes much more of a utility (turn on the switch and it just works).  In private clouds that are implemented in-house, none of this is true.  Companies have to buy, build, and manage the environments and also deal with the complexity of having many applications running simultaneously in a virtual environment.

Still, companies feel that this is a good investment and, in many cases, so do I.  However, it's just as crucial, probably more so, that the environment be properly planned and managed.  In a typical application that runs on a server if the server runs into capacity and performance problems, only one application or service is affected.  In a private cloud, a shortage of capacity could affect all of the applications and services running within that cloud.

As of right now, most companies who are implementing virtualization technologies internally (and are taking advantage of technologies that allow for the rapid and seamless deployment and reallocation of resources) are setting up their own private clouds.

 
On Friday I'll deal with some of the things that need to be considered when looking at a private clouds.

Rich Fronheiser

Chief Marketing Officer

The changing face of Capacity Management (2 of 5)

The view of capacity planning when I started in this profession over 15 years ago is different now than it was then.  Yes, many mainframers have told me that they had virtualization back then and nothing new is really new again.  I'll concede that to a certain degree, but for those of us who came into a client-server world, things have changed dramatically.

Back then, planning for me was the building, calibrating, evaluating, and creating scenarios revolving around analytic models for a single system.  Workloads were the items of importance and quite frequently we looked at technical numbers and pretty much ignored the business.

Things have changed.

Today I spend more time talking about capacity as the overall amount of capacity remaining in a virtualized datacenter rather than the capacity remaining on a server.  I spend more time talking about central storage and SAN performance than I do talking about locally-attached storage.  And for me the workload view has been replaced in many cases with a real-user transactional view we couldn't hope to get back in the days before Y2K.  It's the only way we know whether we're meeting those SLAs.  With services hitting many different tiers (and potentially disappearing into the cloud), that transactional view can actually be the easiest way to measure performance.  How much of that transaction is visible to the planner depends on the cloud implementation and on the service provider.

So, the cloud. Sure, it would be ideal to have knowledge of everything that's happening inside the cloud, but if you're paying for software-as-a-service (SaaS), you probably aren't going to get that from your vendor -- and, to be honest, why would you want that view?  You are paying a premium in order to reduce computing down to the utility level -- flip the switch and the light comes on.  When I turn a light on in my kitchen, I don't think about the wires, the devices, or the electrical grid -- I just want to know that the light will come on.  And I take for granted that there's enough electricity in the system to service all my household needs.

But we pay a price for that, and there's a chance that instead of paying for excess capacity in your data center, you're paying for excess capacity (for yourself and for other clients of the vendor) in the cloud.

In the next few installments, I'll start looking at clouds in more detail.  I'll focus on the different types of clouds, the different types of services that can be purchased from cloud providers, and how that affects how you'll do capacity planning.

Rich Fronheiser
Chief Marketing Officer

Old Habits & Potential Risks (9 of 10)

Gartner stated that "through to 2015, more than 70% of private Cloud implementations will fail to deliver operational energy and environmental efficiencies"

(Extract from “Does Cloud Computing Have a ‘Green’ Lining? – Gartner Research 2010)

Why?  Well Gartner are referring to the need to implement an organization structure with well-defined roles and responsibilities to manage effective governance and implementation of services, well-defined and standardized processes (such as change management and capacity management) and a well-defined and standardized IT environment. Cloud-computing technology (such as service governor, automation technology and platforms) itself is evolving, and thus, the efficiency promises will not be delivered immediately.

"Old habits" include departmental infrastructure or application hugging. Within an organisation what you tend to find most often is departments develop a "silo mentality", i.e. mine is mine.  They become afraid to share infrastructure through a lack of trust and confidence, because they fear an impact on their own services they adopt the we need to protect ourselves from everybody else approach.

The problem with this attitude is it can lead us back to the "just in case" capacity mind set, where you end up  always over provisioning systems  By using effective capacity management techniques and combining with the functionality that  vSphere provides  you can get that right, by sizing and provisioning more accurately avoiding over provisioning.  Performing application sizing at the first level will help you get the most efficient use out of your infrastructure as possible and ultimately lead to achieving that equilibrium between service and cost.

So how can we "Avoid an Internal Storm" and "Ensure a Brighter Outlook"? 

Firstly, ask yourself this question - What is different with Cloud Computing, in terms of Capacity Management, compared with how we've always done it?   

Typically, we still need to apply the same capacity management principles such as getting the necessary information at the Business, Service and Component levels.  But we have to take into consideration the likelihood that the Cloud is underpinned by Virtualization and more specifically the use of resource pools.   Therefore in this case, we need to be aware of what Limits, Shares and Reservations are set and what VMs are running in which pools in our cluster(s).  Earlier we displayed a chart of a priority guest resource pool and the CPU usage of the guests within it.  We need to identify limits.  How much are our virtual machines allowed to use?  Do they have a ceiling?  What is the limit?  When we talk about utilization is it the utilization of a specific CPU limit for example?

Do they have higher priority shares over others?  What about any guarantees? Are they guaranteed resources because they may be high priority guests? And are there any CPU infinities assigned.

Information we need. 

•       Business - how many users is the service supporting? What resources are required? Are we likely to experience growth in this service?  If so, by how much and when? Monthly, Quarterly or Annually?

•       Service – have the Service Level Requirements (SLR) been defined and / or have they been agreed (SLA) and what do they entail?  What, if any, are the penalties for not meeting the terms stated in the SLA?

•       Component – gather and store the configuration, performance and application data from the systems and applications hosting the service in a centralized database that can be readily and easily accessed to provide the key evidence on whether services are and will in future satisfy the requirements as stated in the SLAs.

ITIL v3 Capacity Management explains about the kind of information you should be gathering at these levels.  Having this information enables us to get the full picture of what is currently happening and allows us to forecast and plan ahead based on the business growth plans for the future.  

Once we have all of the required information, we can implement automatic reporting and alerting and that’s what I’ll be covering in the last of my series on Monday....

Jamie Baker
Principal Consultant

Organisations typically over provision by as much as 100% (8 of 10)

As mentioned previously organisations typically over provision by as much as 100%, so this could put a squeeze on other applications running within your infrastructure, within your internal cloud.  Therefore when providing unlimited access to resources for our critical applications and setting high priority shares, it could impact on other applications.

But what impact is that likely to have?  It may be insignificant but if it isn’t then we need to think about scaling out or up. 

Scaling out is to scale "out" to existing systems of a similar specification.  So what are the advantages of being able to do this?  One of the advantages is that you may have some existing hardware lying around which has not been deployed or provisioned or some servers that are earmarked for removal that can be added rapidly to a cluster by using the golden reference host to install ESX.

Some benefits from this approach are:

·         Short lead time. You don’t need to place an order and there is no need to wait for it to be built and delivered to you and then installed.  There’s no need for a hardware upgrade because you’ve actually put extra resources into your cluster and then DRS can migrate virtual machines to load balance. 

·         Acceptable Costs. Your costs are acceptable in this respect

·         SLA’s are met. But for how long? Are they only met for the short term?  Are there enough resources and how much more do we actually need going forward as the business grows?

Some disadvantages of this approach would be that the hardware currently available or that has been decommissioned would be older and slower than those currently out there in the market at the moment. It may not be 64 bit compatible; it may not have the latest chip technology or greater memory capacity than the latest servers do.  And while it satisfies our short term requirements, it may not meet our medium or long term objectives as the business grows and demand pressure on resources continues to grow.

You may also encounter some additional costs, such as extra software licensing based on the extra licences that you’ll need.  You may need to extend some hardware support because you have older systems and you may also find that older servers have a higher power consumption, along with having to find space to host the servers. 

Scaling Up.

So what benefits do we get from scaling upwards?  This means we scale to the latest and greatest, normally bigger and more powerful systems. Faster CPU's, more physical Memory capacity, 64bit compatible etc.  We can also look at increasing our consolidation ratio on these more powerful systems in comparison to what we currently have in place.  This helps reduce the number of systems within a data centre leading to the benefits of smaller data centres, lower power consumption, and reduce carbon footprint for example, contributing to any green IT initiatives.

These newer systems may also support hyper threading, in which the CPU scheduler within vSphere actually allows you to have more execution threads for your virtual CPU’s to execute on.

We can make efficiency savings.  After making the initial upgrade to a more powerful larger system, taking into consideration the cost of the upgrade, we may actually save over time against scaling out to older systems. It’s essential to perform a cost benefit analysis to see what savings we can make by scaling up.

Some disadvantages are:

·         Longer lead time.  You have to wait for the systems to be built and delivered / configured and installed after making an upgrade purchase. 

·         Space.  You may have to find space for your new systems and you may have to decommission some old servers within your data centre, this again extending the lead time.  The associated costs would be the cost of purchasing new equipment and any associated licensing costs that you are likely to incur by scaling upwards.

    One example of a scaling up benefit is from eBay.  A key note speech from Mazen Rawashdeeh  eBay's VP of Technology Operations at the Gartner Data centre summit in Las Vegas talked about the benefits of leasing servers.  The benefit of leasing servers is that you get a complete package for an annual fee.  By trading in your existing leased servers for the latest technology that is available on a yearly cycle.  This leads to benefits such as being greener by using more power efficient servers which uses less cO2, and reducing our physical size because we can have confidence in being able to host more VMs per ESX server and there increase the conversions of physical systems to virtual machines.

Other cost savings such as power usage, less data centre space in terms of  reducing the physical footprint, reduction in the number of software licenses, were some of the key benefits that Mazen was trying to point out why eBay had now shifted to leasing.

I’ve covered the benefits of scaling up and scaling out, but what about scaling in?

Scaling In

What is Scaling in?  Well it is the process of using the spare capacity within our infrastructure.  We previously mentioned about way of relieving the pressure on your virtual environment if experiencing capacity / performance issues.  But what about if your environment is performing as expected and you have over provisioned?

Do you have spare capacity within your infrastructure?  Consider consolidating workloads (guests) onto fewer hosts to “sweat the assets” more.  Also consider using periods of inactivity to migrate workloads between hosts.  An example would be to run batch programs overnight on hosts running working day applications.  By performing these actions you may be able to invoke the VMware Distributed Power Management (DPM) application which powers off unused hosts during these periods.  This in turn will reduce the power consumption and in turn energy costs.  It may also lead to a consolidation on the number of ESX hosts required and thus reduce the number of ESX host licenses needed.  On Friday I'll be taking a look at old habits and potential risks....

Jamie Baker
Principal Consultant