Capacity planning is the tightrope act of IT, leaving you to walk the thin line between wasting money on excess capacity and losing money because of capacity constraints.
In a rapidly changing business environment, delays caused by a lack of capacity can lead to missed opportunities. There is no net under this tightrope. You have to get the balance right.
How much server capacity do you have right now? Are you actively monitoring capacity, or are you just setting alarms to let you know when it is almost gone? And as your capacity is consumed, do you know where it is going? Five different project planners may think they have sufficient capacity available, but if they were all looking at the same pool of available resources, you could be in serious trouble if even two of those five projects move forward.
Capacity planning and resource management have always been challenges for businesses, and recent virtualization trends may actually place even greater emphasis on these challenges.
Virtualization exposes previously masked deficiencies as it decreases provisioning times and speeds up server deployments. For example, before you virtualized, you may have provisioned hardware and scheduled firewall rules concurrently. If provisioning hardware took, say, three weeks, it didn't matter that it took two weeks to schedule firewall rules. But as soon as virtualization shortened the hardware provisioning time to three days, the firewall scheduling suddenly became the roadblock. This is just one of the factors that can work to upset the capacity planning balancing act.
Organizations can usually consume resources pretty quickly, but replenishing those resources can involve bidding, quotes and a number of signatures before orders are even placed -- and then there is shipping, receiving, racking, cabling, etc. You cannot do capacity planning for tomorrow, because by the time you get your additional resources, you'll already need even more. You need to be looking at least two months out.
You may also need to re-evaluate and consider streamlining your procurement process to address capacity planning needs. If you are in a position to have your vendors deliver excess resources that you will not pay for until powering them on, that could be a good option to help you respond to demand more quickly.
Capacity planning is a critical task for IT shops. If you are implementing virtualization or managing a cloud computing infrastructure, you have placed your capacity planning and management under a microscope. The success or failure of your environment is directly tied to your ability to manage capacity.
Original article at http://searchservervirtualization.techtarget.com/news/column/0,294698,sid94_gci1516710,00.html?track=NL-653&ad=776236&asrc=EM_NLN_12051365&uid=3056478
Wednesday, August 4, 2010
Monday, August 2, 2010
How to address data storage management problems caused by virtual desktop software
Your customers are beginning to look at virtual desktop software -- also referred to as desktop virtualization or virtual desktop infrastructure (VDI) -- as a way to help manage the challenges of user desktops and laptops. Desktop virtualization typically fills two roles: to either drive down end-point costs in the case of organizations with a large number of shift workers or to lower end-point management costs for companies with users equipped with their own laptops and desktops. In either case, the load that desktop virtualization puts on data storage management -- which manifests in capacity problems and boot storms -- is unprecedented, even when compared with server virtualization.
While it is true that most traditional desktops have far less capacity than physical servers, there are generally far more desktops than servers, so when those desktops are virtualized, there's still a significant capacity impact on the data center. And while most virtual desktop software products have the capability to negate initial capacity consumption through the use of techniques such as golden masters, in which one core copy of the desktop environment feeds many users, the net changes that users make to those systems are stored separately. Clearly, golden masters help rein in capacity demands, but hundreds or thousands of users adding data to their virtual desktops (as well as making changes to their preferences) will of course increase the overall data storage management burden.
To help customers address their capacity issues, you should look for supporting storage systems that can provide deduplication and/or compression.
As you'd expect, deduplication's role with desktop virtualization is to identify and reduce potential redundancies that are introduced after imaging. The classic example is the same document being emailed and then stored on each desktop or laptop. In the past these documents were all on standalone, individual systems, so no capacity gains could be made. With a virtual desktop software infrastructure, those documents would be saved on the same storage system, and with deduplication, the redundancy can be eliminated. Another, less obvious storage gain of deduplication relates to operating system updates. While these updates can be applied to the master, not all updates are; some are applied to their resulting clones on an individual basis. Because of this, duplication can work its way into the system files, and deduplication can help address this problem.
The role of compression with VDI, on the other hand, would be to help your customers further reduce the data footprint by compressing the entire data set. Together, deduplication and compression can significantly shrink the capacity footprint of the virtual desktop software environment, in some cases by as much as 95%.
The second issue stemming from desktop virtualization related to data storage management is the boot storm, or login storm, which can occur at the beginning of the work day or during a shift change, where hundreds of users might log in to the system at about the same time. The storage system becomes overwhelmed with the number of requests, and your customer's users can experience incredibly long boot times. Quickly, they start screaming for their old desktops back.
To resolve the boot storm issue, the first step is to reduce the overall capacity requirements as discussed above. With the capacity reduced, more of the boot images can be loaded into the storage system's cache and the storage I/O process required by login can be served from the faster RAM that makes up that cache. In a virtual desktop software environment, it is advisable to add as much memory to the storage system's cache as possible.
But, even if your customer can afford all the cache that their system supports, sometimes the storage system can't support enough cache to fix the problem. In that case, traditional storage media will need to serve up the initial image loads. The faster the media the better; solid-state drives (SSD) are ideal. The problem is cost-justifying the most expensive storage possible just for a once-a-day event.
The best approach here is to recommend a solution that can automatically tier images to and from a faster SSD platform during the boot process and then move those images back to slower mechanical drives after the boot-up is complete. After the initial boot storm has passed, automated tiered storage could move performance-starved business application data to the faster tier for the rest of the day until the next morning's login.
If your customer can't cost-justify an SSD tier, another, slower option is to use a small group of 15,000 rpm drives (Fibre Channel or SAS, depending on the storage system) to auto-tier in conjunction with the normal primary storage tier, which typically consists of 10,000 rpm drives.
From Article on http://searchstoragechannel.techtarget.com/tip/0,289483,sid98_gci1516467,00.html?track=NL-675&ad=775735&asrc=EM_NLT_11998040&uid=3056478
While it is true that most traditional desktops have far less capacity than physical servers, there are generally far more desktops than servers, so when those desktops are virtualized, there's still a significant capacity impact on the data center. And while most virtual desktop software products have the capability to negate initial capacity consumption through the use of techniques such as golden masters, in which one core copy of the desktop environment feeds many users, the net changes that users make to those systems are stored separately. Clearly, golden masters help rein in capacity demands, but hundreds or thousands of users adding data to their virtual desktops (as well as making changes to their preferences) will of course increase the overall data storage management burden.
To help customers address their capacity issues, you should look for supporting storage systems that can provide deduplication and/or compression.
As you'd expect, deduplication's role with desktop virtualization is to identify and reduce potential redundancies that are introduced after imaging. The classic example is the same document being emailed and then stored on each desktop or laptop. In the past these documents were all on standalone, individual systems, so no capacity gains could be made. With a virtual desktop software infrastructure, those documents would be saved on the same storage system, and with deduplication, the redundancy can be eliminated. Another, less obvious storage gain of deduplication relates to operating system updates. While these updates can be applied to the master, not all updates are; some are applied to their resulting clones on an individual basis. Because of this, duplication can work its way into the system files, and deduplication can help address this problem.
The role of compression with VDI, on the other hand, would be to help your customers further reduce the data footprint by compressing the entire data set. Together, deduplication and compression can significantly shrink the capacity footprint of the virtual desktop software environment, in some cases by as much as 95%.
The second issue stemming from desktop virtualization related to data storage management is the boot storm, or login storm, which can occur at the beginning of the work day or during a shift change, where hundreds of users might log in to the system at about the same time. The storage system becomes overwhelmed with the number of requests, and your customer's users can experience incredibly long boot times. Quickly, they start screaming for their old desktops back.
To resolve the boot storm issue, the first step is to reduce the overall capacity requirements as discussed above. With the capacity reduced, more of the boot images can be loaded into the storage system's cache and the storage I/O process required by login can be served from the faster RAM that makes up that cache. In a virtual desktop software environment, it is advisable to add as much memory to the storage system's cache as possible.
But, even if your customer can afford all the cache that their system supports, sometimes the storage system can't support enough cache to fix the problem. In that case, traditional storage media will need to serve up the initial image loads. The faster the media the better; solid-state drives (SSD) are ideal. The problem is cost-justifying the most expensive storage possible just for a once-a-day event.
The best approach here is to recommend a solution that can automatically tier images to and from a faster SSD platform during the boot process and then move those images back to slower mechanical drives after the boot-up is complete. After the initial boot storm has passed, automated tiered storage could move performance-starved business application data to the faster tier for the rest of the day until the next morning's login.
If your customer can't cost-justify an SSD tier, another, slower option is to use a small group of 15,000 rpm drives (Fibre Channel or SAS, depending on the storage system) to auto-tier in conjunction with the normal primary storage tier, which typically consists of 10,000 rpm drives.
From Article on http://searchstoragechannel.techtarget.com/tip/0,289483,sid98_gci1516467,00.html?track=NL-675&ad=775735&asrc=EM_NLT_11998040&uid=3056478
Subscribe to:
Posts (Atom)