SDDC Operations Management

SDDC.Management.Stack.Reference.ArchitectureIn, Building a Management Stack for Your Software Defined Data Center, we proposed a reference architecture for how one might assemble the suite of management components that will be needed to manage a Software Defined Data Center (SDDC). In this post we take a look at the Operations Management portion of the reference architecture and the vendors that can provide this functionality.

The Need for New Operations Management Vendor in Your SDDC Management Stack

So why you ask, will a SDDC require a new approach to Operations Management and therefore more than likely a new vendor for Operations Management? The reasons are driven by the fact that managing the operations of an SDDC will be dramatically different from managing a static and physical data center in the following respects:

  1. Legacy Operations Management products were built to the assumptions of servers dedicated to single applications, networks implemented solely in hardware, and usually a dedicated path from the database server to the storage array. A SDDC is based upon shared servers, networks implemented in both hardware and software, and potentially a shared and multiplexed path to the storage array.
  2. Legacy Operations Management solutions were built to assume systems that changed relatively infrequently.  The SDDC is built to support private clouds and IT as a Service. The whole point of both private clouds and IT as a Service are to fully automate the process by which IT services are provisioned for end users. This means that the configuration and resource allocation in an SDDC will change whenever users want it to, since users will be provisioning workloads whenever they need to.
  3. For the above two reasons, you cannot just add VMware vSphere as a data source to a legacy Operations Management solution and expect to have something useful. Operations Management for a SDDC means getting different data, getting more of it, getting it more frequently, and doing different things with it than were done in the legacy physical case.
  4. For example the whole notion of resource contention caused by N workloads running on one server simply does not exist in the physical world. Neither does the notion that new workloads are going to show up on a server in an automated matter at the discretion of a business constituent of the IT department.
  5. The SDDC is going to be concerned with the configuration and operation of all of the CPU, memory, networking and storage resources underlying the SDDC. In the legacy world there were completely separate products for managing servers, for managing switches, and for managing storage arrays.  The management of all four of these key resources will need to be combined into one Operations Management solution for the SDDC.

The Software Defined Data Center Management Stack Reference Architecture


Key Criteria for an SDDC Operations Management Solution

Since there are many vendors selling Operations Management products into the VMware and Hyper-V virtualization markets today, the most important thing to do is to evaluate these vendors on their future ability to expand their product scopes to include support for the SDDC. That would include the following key capabilities:

  1. Just about every Operations Management vendor supports more than one hypervisor today. At this point support for at least VMware vSphere and Microsoft Hyper-V ought to be assumed as table stakes. Even if you are a 100% VMware vSphere shop today, you should at least get a statement of commitment for support of Microsoft Hyper-V and Red Hat KVM from your Operations Management vendor. This is because there is nothing wrong with having more than one hypervisor. However building a management stack as depicted above that is different for each of two or three hypervisors would re-create the management mess that characterizes Operations Management in the physical world for most enterprises.
  2. The ability to handle the scale and scope of your environment. This requirements produces drastically different results depending upon the size of your environment, the diversity of the hardware in your environment, and the nature of the workloads in your environment. At the low end (100 physical hosts), the idea is to end up with one simple to implement product that collects data from the standard management interfaces available at each layer of the SDDC and does appropriate analysis and presentation of that data. At the high end (5,000 to 10,000 hosts) commodity data is going to equal commodity results. You will want to invest in an Operations Management solution from a vendor that understands and has the ability collect unique and valuable data with their own R&D efforts.
  3. Today’s Operations Management solutions focus primarily upon the management of physical and virtual servers. Little attention is paid to the virtual network that exists today in the form of the vSwitch and they only attention that most vendors pay to storage is to consume the storage metrics that VMware makes available in the vSphere API. This will have to dramatically change. Managing the virtual network layer and the virtual storage layer will be much more demanding for Operations Management vendors than managing CPU and memory contention.
  4. Today, relatively few of VMware’s customers have fully implemented private cloud or IT as a Service environments. The point of the SDDC is to support the creation of these environments. So Operations Management solutions are going to have to significantly change to provide the level of management needed for large scale and dynamic systems.
  5. The combination of having to manage CPU, memory, networking and storage, with having to manage a large scale environment, with being able to cope with the constant changes driving by the automation in private clouds supporting IT as a Service will require different Operations Management solutions than those that we have today.

Who Could Provide Operations Management for the SDDC?

First let’s make a very important point. Since the SDDC does not exist yet, no one has an Operations Management product for an SDDC today. We have wait for VMware to deliver upon the recently announced NSX network virtualization components, and deliver on the rumored but not yet announced storage virtualization projects. Given how things are unfolding, and have unfolded in the past, there are good reasons to hope that further announcements and delivery dates will be provided at VMworld this fall.

Given that no Operations Management product for an SDDC exists today, what we are left with is the ability to engage in informed speculation as to who might deliver such a Operations Management solution. Note that this is 100% speculation based upon an analysis of each vendor’s strategy in the Operations Management space today.


VMware is a leader in the Operations Management business for virtualized data centers today with its vCenter Operations product. Since VMware is the only vendor on the planet who has announced the intention to build and deliver an SDDC, it is a reasonable assumption that VMware will evolve vCenter Operations to be able to manage its own SDDC. Despite the fact that it seems obvious that VMware would go down this path, there are tremendous challenges for VMware as it expands the scope of vCenter Operations in this manner. Some of these challenges were outlined in our Big Data for for the SDDC post. Basically VMware has to start by ripping the existing data store out of vCenter Operations and replacing it with something most likely built by the Log Insights team from Pattern Insights. Next VMware has to add the relevant metrics at the relevant level of frequency for the virtual networking and virtual storage layers. This is going to require the new big data back end since there will be so many new metrics arriving at such a rate that the existing data store would have no change of keeping up. Finally, the analytics in vCenter Operations will have to go through a significant evolution to deal with this new torrent of data and to be able to provide effective cross-domain root cause analysis. VMware likely understands each of these challenges very well. However VMware is unlikely to address all of them across the diversity of its own customer base, leaving plenty of room for third party vendors.


If you are looking to throw our your legacy physical Operations Management solution and replace it with something that is built from the ground up for the SDDC and the private cloud and IT as a Services use cases for the SDDC, then Zenoss would be a good place to start. Operations Management starts with the ability to manage events and mange the impact of events upon the availability of the physical and virtual environment. Zenoss has a completely modern event management system and if your environment is of the scale and diversity that event management is needed then Zenoss is a great place to start.


One of the key points behind building and using and SDDC will be that it will be possible to automate many things that are not or cannot be automated today. VMTurbo uniquely solves the problem of fully automating the process by which the important workloads in your environment are assured that they get the resources that they need to meet their SLA’s. VMTurbo does this by allowing you to prioritize your workloads, and then by using the virtual CPU, virtual memory, network I/O control and storage I/O control interfaces in vSphere to ensure that the highest priority workloads get the resources that they need. This is precisely the kind of approach that will be essential to the smooth operation of the SDDC as there will be no way for humans to keep up with resource allocation decisions as private clouds and IT as a Service gets deployed in your SDDC.


Like VMTurbo, Cirba comes at the Operations Management problem for the SDDC with a heavy dose of analytics. However, the focus of Cirba is more upon making sure that the physical capacity of the infrastructure underlying the environment is properly utilized and allocated. This will prove to be an essential capability for the management of the SDDC as all of the automation in the world will end up being useless if the underlying physical capacity across the four key resources areas does not exist or is not properly allocated. Conversely, the tendency to over-provision in the name of reducing risk is likely to be just as strong for the SDDC as it has been historically for physical environments, making Cirba into something that is an essential cost management tool.

The Quest Software Division of Dell

When Quest Software bought vKernel, two market leading products were brought together under one roof. One was the vFoglight product from Quest. The other was the vOperations product from vKernel. These products have now been combined into the Quest vOPS product line. This product line is unique in that it retains the two key aspects of the parent products. On the low end the product is extremely easy to try, implement and purchase (a legacy of vKernel). At the high end (a legacy of vFoglight and the rest of the Foglight product line), the product is a fully enterprise capable solution that can be combined with numerous other Quest offerings to solve complex end-to-end and cross stack Operations Management issues.

Reflex Systems

Reflex Systems is unique in the Operations Management space in that the company long ago decided to architect its solution for very large environments and for large amounts of rapidly arriving data. Reflex Systems is one of the few Operations Management vendors that can collect the operations and configuration data in a VMware environment directly from each vSphere host every 15 seconds, as opposed to waiting for the 5 minute roll-up of that data from the vSphere API. The ability to do this for the largest of VMware’s customers, supported by the analytics required to analyse this data and a user interface capable of making sense of the quantity of the data and the scale of its source makes Reflex Systems into a unique Operations Management vendor today. The foundations upon which the Reflex Systems product are built positions the company extremely well for Operations Management of the forthcoming SDDC.


What if the right way to approach the problem of collecting the Operations Management data for an SDDC and then analyzing that data is to use the approach that Google took to collecting data and analyzing it for its own data center. If you are willing to consider that possibility, then consider CloudPhysics, a vendor with cloud hosted (delivered as a service) operations management solution. One of the key reasons that CloudPhysics may be able to provide something of extraordinary value is that the company has a strategy of applying Google quality analytics to Google size data sets. The analytics come from a world class team of people some of whom previously worked at Google. The data today is collected by virtual appliances installed at CloudPhysic’s customer sites (in their respective VMware environments). This puts CloudPhysics in the unique position of being able to do analytics across the operations management data from many customers, which will likely result in features and benefits simply not possible from on-premise solutions.


Splunk is in fact the only vendor on the planet from whom you can purchase an on-premise big data datastore, which is today being populated not just by various logs, but by virtue of the Splunk App for VMware and the Splunk Apps for Citrix true Operations Management data for these environments.  In fact if you go to SplunkBase do s search on “virtual” you will find 11 different operations management applications feeding data into Splunk. Splunk has a strategy of being the management data platform across operations management, application performance management and security and certainly bears watching as it evolves its strategy and product offerings in the direction of the SDDC.


If your current virtualization environment or your future SDDC spans more than one hypervisor, but your primary environment is VMware, then you really need to consider Hotlink. Holink offers something different than any other Operations Management solution profiled here. Hotlink lets your VMware administrators administer Hyper-V, KVM and Amazon EC2 environments from within the vCenter management console in the exact same manner as they manage a vSphere environment. This give rise to a new meaning for cross platform. In Hotlink’s world cross platform is not just that an Operations Management or Cloud Management solution works across two or more hypervisors. In Hotlink’s world cross-platform means that you can use one management console (vCenter) to manage all of these environments, migrate workloads across these environments, and leverage your vSphere management conventions (like snapshots) across all of these environments.


Count how many management agents of various types (operations management, application performance management, security, backup, etc.) you have deployed in each virtual machine in your environment. Now multiply that by the number of VM’s in your environment. If the thought of having to manage and update all of those agents (and preventing their misbehavior from affecting your environment) gives you a headache, then Intigua is for you. Intigua applies application virtualization techniques to the management agents in your virtualized server environment (think App-V for management agents on servers). This makes it much easier to manage the agents in your environment and allows you set policies that prevent those agents from harming your environment.

ManageEngine and SolarWinds

If all of the above sounds too complex and too expensive for you because your environment is just not that large and just not that complex then you need to focus upon solutions that just rely upon the management data available from standard management API’s (the vSphere API, WMI, SNMP, SMIS, etc.) and that are easy to evaluate, easy to implement, and easy and affordable to purchase. If you consider yourself to be an SMB or an SME then the products from ManageEngine and SolarWinds are for you. The objective here is how quickly do these products deliver value to you and how little manual configuration work do you have to do to get that value. Most importantly, how little on-going maintenance work are you going to have to do to keep your environment up and running.


The SDDC is going to require a new approach to Operations Management. Vendors with effective Operations Management solutions for today’s virtualized data centers are in the best position to be able to expand their offerings for the SDDC.   Legacy vendors face a complete rewrite of their products and the adoption of a new business model (easy to try and easy to buy) that will destroy them financially, and will therefore be unable to react to the SDDC either technically or financially.

Client Hypervisors: Intelligent Desktop Virtualization too clever for its own good?

DesktopVirtualizationIn 2011, we asked if  Client Hypervisors will drive will the Next Generation Desktop. Yet, other desktop virtualization industry experts, such as Ron Oglesby, decided the technology was a dead man walking, writing off Type 1 Client  Hypervisors.

Fight? Fight? Fight?

While VMware moved away from client hypervisors, they had to agree that an end user compute device strategy must encompass non-VDI. Their Mirage technology can be considered desktop virtualization, but it is not a client hypervisor. Client hypervisor vendors such as Citrix (who subsumed Virtual Computer’s NxTop) , MokaFive, Parallels, Virtual Bridges and joined by Zirtu. Organisations like  WorldView look to innovate on desktop vitualization through containers rather than full virtualization.

Tablets. Touch Screen capable laptops. Hybrid devices with detachable screens. The netbook might be dead, or they could just be resting. The presence of tablets has undeniably shaken the netbook market but businesses still need powerful, capable laptops.

Bring Your Own Pencil aside – there is still a need to manage “stuff”: still large and small organisations who need to manage the delivery of IT including the end device. The question remains how are devices, and the all important data and applications on them, managed? Hosted and session based desktops have their place – but offline capable device requirements will remain.  Is Intelligent Desktop Virtualization the same as client hypervisors?

Continue reading Client Hypervisors: Intelligent Desktop Virtualization too clever for its own good?

The Big Data Back End for the SDDC Management Stack

SDDC.Management.Stack.Reference.ArchitectureIn, Building a Management Stack for Your Software Defined Data Center, we proposed a reference architecture for how one might assemble the suite of management components that will be needed to manage a Software Defined Data Center (SDDC). In this post we take a look at the need for that management suite to be supported by a multi-vendor big data datastore, and take a look at who might provide such a data store.

The Need for a Multi-Vendor Management Data Store in Your SDDC Management Stack

So why you ask, will a SDDC require a set of management products that will in turn require a multi-vendor big data back end. The reasons are as follows:

  1. The whole point of moving the configuration and management of compute, memory, networking and storage out of the respective hardware and into a software layer abstracted from the hardware is to allow for configuration and management changes to happen both more quickly and more automatically (which means very quickly). Each configuration change or policy change is going to create a blizzard of management data.
  2. If you look at all of the horizontal boxes in our Reference Architecture (below) each one of them along with the vertical IT Automation box will be generating data.
  3. The rate of change in the SDDC will be high enough so as to require fine grained and very frequent monitoring at every layer of the infrastructure.
  4. Just combining the number of layers with the rate of change with the need for fine grained and high frequency monitoring (5 minutes is an eternity) creates a big data problem.
  5. Finally, the need to be able to to cross layer root cause analytics (where in the software or hardware infrastructure is the cause of that application response time problem) means that the root cause analysis process has to cross domains and layers. This in and of itself calls for a common data store across management products.

The Software Defined Data Center Management Stack Reference Architecture



Who Could Provide the Multi-Vendor Big Data Repository?

There are two basic criteria for being able to provide such a repository. The first is that you have to have one, or have the intention to build one. The second is that since it is multi-vendor, you have to have the technical capability to, and the business model to partner with the vendors whose products will feed this datastore. The rest of this post is entirely speculative in nature as it is based upon who could do what, not upon who is doing what. To be clear, no vendor listed below has told us anything about what they intend to do in this regard. The rest of this post is based entirely upon what people are shipping today and the author’s speculation as to what might be possible.


If there is one vendor who has an early lead in filling this role it would be Splunk. Splunk is in fact the only vendor on the planet from whom you can purchase an on-premise big data datastore, which is today based upon shipping and available products being populated by data from management products from other vendors.  In fact if you go to SplunkBase do searches on things like APM, monitoring, security, and operations you will find a wide variety of Splunk written and vendor written applications that feed data into Splunk. Now it is important to point that today, when a vendor like ExtraHop Networks or AppDynamics feeds their data into Splunk they are not making Splunk in THE back end datastore for their products. They are just feeding a subset and a copy of their data into Splunk. But this is a start, and it puts Splunk further down this road than anyone else. Needless to say, if the vision of the multi-vendor datastore is correct, and Splunk is to become the or one of the vendors who provides this, then Splunk is going to have to entice a considerable number of software vendors to trust Splunk to perform a role that no vendor today trusts any other vendor to perform.


In, VMware Fleshes Out SDN Strategy with NSX, we went through how VMware is combining Nicira into its Network Virtualization offering, NSX. In the VMware announcement there was a link to a blog post, “Open Source, Open Interfaces, and Open Networking” contained the following fascinating statement:

Statistics Collection & Telemetry

“Another area of focus for an open networking ecosystem should be defining a framework for common storage and query of real time and historical performance data and statistics gathered from all devices and functional blocks participating in the network. This is an area that doesn’t exist today. Similar to Quantum, the framework should provide for vendor specific extensions and plug-ins. For example, a fabric vendor might be able to provide telemetry for fabric link utilization, failure events and the hosts affected, and supply a plug-in for a Tool vendor to query that data and subscribe to network events”.

Needless to say, it is highly unlikely that VMware would choose to make the current datastore for vCenter Operations into the “framework for the common storage and query of real time performance data“. Rather it is much more likely that VMware would build its own big data datastore with the people and the assets that VMware acquired when VMware acquired the Log Insight technology and team from Pattern Insight. VMware therefore clearly has the technology building blocks and the people to pull this off. You could also argue that they would not have make this acquisition if there were not intentions to go at least somewhat in this direction. The key challenge for VMware will then be the multi-vendor part. VMware has no relationship of technical cooperation with any other management software companies other than Puppet Labs, so this is clearly an area where VMware has a long way to go.

New Relic

New Relic is the hands down market leader for monitoring Java, .NET, Ruby, Python, and PHP applications in the cloud. New Relic offers cloud hosted APM as a Service and has gone in four years from a brand new company to now having more organizations using its product than the rest of the APM industry combined. New Relic recently raised $75M from top tier investors and is rumored to be positioning itself for an IPO in the 2014-2015 timeframe. New Relic already makes its data available to third parties in its partner program via a REST API. It is not much of a stretch for New Relic to consider becoming the management platform in the cloud, partnering with adjacent vendors and becoming a vendor of the multi-vendor cloud datastore. Again all of this is pure speculation at this point.

The Pivotal Initiative

The Pivotal Initiative is a new company formed with assets and people from EMC and VMware lead by former VMware CEO Paul Maritz. These assets consist of the application platform PaaS products from VMware (Gemfire, Spring, vFabric and CloudFoundry), and the big data assets fromEMC (GreenPlum). The stated ambition is to deliver a way to build and deploy big data applications that is radically better than the incumbent method and tackle giants like IBM, Microsoft, and Oracle in the process. This means that the focus of both the application development assets and the big data assets is most likely to be upon solving business problems for customers, not IT management problems for customers. However, it would not be inconceivable for a third party company to license these technologies from Pivotal and build an offering targeting the multi-vendor management stack use case.


Consider the possibility that this multi-vendor big data datastore is in fact non on-premise, but in the cloud. If you are willing to consider that possibility, then it is not much of a stretch to consider that CloudPhysics a vendor with cloud hosted (delivered as a service) operations management solutions might step into this fray. One of the key reasons that CloudPhysics may be able to provide something of extraordinary value is that the company has a strategy of applying Google quality analytics to Google size data sets. The analytics come from a world class team of people some of whom previously worked at Google. The data today is collected by virtual appliances installed at CloudPhysic’s customer sites (in their respective VMware environments). If CloudPhysics is already collecting data across customers and putting it in its cloud, it is not too huge a stretch to consider the possibility that other vendors who also deliver their value as a service could partner up with CloudPhysics, combine their respective sets of data, and produce a 1+1=3 scenario for joint customers.


AppNeta is today a market leading vendor of a cloud hosted service, PathView Cloud, that measures the performance of the wide area network in between the users and branch offices of an enterprise and the enterprises back end data center. The back end is a true big data back end, built around true big data technologies. AppNeta is branching out into APM with its TraceView offering.  But network performance data and application performance data are just parts of the compete set of data that will get generated by the SDDC and about the SDDC by various management products. AppNeta does not today have a partner program to attract third party data to its management data cloud, but who knows what the future holds.


Boundary is an APM vendor with a cloud hosted big data back end that today focuses upon collecting the statistics from the network layer of the operating system that support applications running in clouds. If you think of New Relic as the vendor who is monitoring your application in the cloud, you can think of Boundary as the vendor who should be monitoring the interaction of your operation system underlying your application with the cloud.  Boundary has no partner program today, and no ability to add third party vendor data to its cloud datastore today, but again who knows what the future might hold.


The SDDC and the Cloud are going to require a new SDDC Management Stack that will need to be based upon a multi-vendor big data datastore. There will likely be on-premise and cloud hosted version of these datastores. Splunk, VMware, New Relic, The Pivotal Initiative, CloudPhysics, AppNeta, and Boundary are all excellent hypothetical suppliers of such a datastore.

Public Cloud Reality: Do we Stay or Do We Go?

CloudComputingSoon the backup power will be available for our new datacenter and the redesign to make use of VMware vCloud Suite is nearing completion. Soon, our full private cloud will be ready for our existing workloads. These workloads however now run within a XenServer based public cloud.  So the question is, do we stay in a poorly performing public cloud (mentioned in our Public Cloud Reality series) or move back to our own private cloud? As the Clash put it “Should I Stay or Should I Go Now.” Continue reading Public Cloud Reality: Do we Stay or Do We Go?

Hard Disk Drives (HDD) for virtual environments (Part IV) from power to warranties

StorageNetworkingBy Greg Schulz, Server and StorageIO @storageio

Let us pick up where we left off in part III in our look beyond the covers to help answer the question of which is the best HDD to use.

Power and energy

Power consumption will vary based on size and type of HDD, along with different usage. For example, during power-up there is a larger amount of energy being used vs. when the drive is idle (not reading or writing) yet still spinning, or actively reading and writing. With intelligent power management (IPM), inactive drives can go into lower power usage modes with variable performance. IPM includes the ability to vary the amount of power used to level of performance with different steps or levels. This is different from some first generation MAID solutions based on desktop class drives that were either on or off with subsequent performance issues. While an HDD requires power to spin the platters, once those are in motion, less power is required; however, energy is needed for the read write heads and associated electronics.

This leads to a common myth or misperception that HDDs consume a lot of energy because they are spinning. There is energy being used to keep the platters moving, however power is also required for the electronics to manage the drives interface, read write heads and other functions. With IPM leaving the drive spinning or reducing the rotational speed can help save power, so to can disabling or putting into low power mode the associated processors and control electronics.

As a comparison SSD, drives are often touted as not drawing as much energy compared to an HDD, which is true. However, SSDs do in fact consume electricity and get warm as they also have electronics and control processors similar to HDDs. If you do not believe this, put an SSD to work and feel it over time as it heats up. Granted that is an apple to oranges comparisons, however my point is that there is more to energy savings with HDDs than simply focusing on the rotational speeds. Speaking of energy savings, typical enterprise class drives are in the 4 to 8 watts or a fraction of what they were only a few years ago. Notebook, laptop and workstation drives can be in the single watt to a few watts in power usage range. Note that these numbers may be less than what some will talk about when comparing SSD and HDDs, or trying to make a point about HDDs and power consumption. The reason is this is a reduction from where just a few years ago when drives were in the “teens” in terms of watts per drive. For performance or active drives, compare those on a cost per activity per watt such as cost per IOP per watt, for inactive data then cost per capacity per watt can be relevant.


Given the large amount of data that can be stored on an HDD along with compliance and other concerns, drive level security is becoming more common. There are different types of drive level encryption including self-encrypting devices (SEDs) with some supporting FIPS level requirements. Drive level encryption depending on implementation can be used to off-load servers, workstations or storage systems from performing encrypt and decrypt functions.

Space capacity

The space capacity of the drives is determined by the aerial density (how many bits in a given amount of space) per platter, the size of the platter (3.5” are larger than 2.5”) and number of platters. For example at the same aerial density, more bits and bytes exist on a 3.5” vs. 2.5” device, and by adding more platters (along with read/write heads) the resulting taller height drive has even more space capacity. Drive space capacities include 4TB and smaller for 3.5” devices and TB plus sized for various 2.5” form factors. Watch out for “packaging” games where for example a drive is offered as say 4TB that are actually two separate 2TB drives in a common enclosure (no RAID or NAS or anything else).

The super parametric barrier effects keeps being delayed, first with perpendicular recording, now with shingled magnetic recording (SMR) and heat assisted magnetic recording (HAMR) all in the works. The super parametric barrier is the point where data bits can no longer safely (with data integrity) be stored and later used without introducing instability. Watch for more on SMR and HAMR in a later post when we look at new and emerging trends.

Speaking of space capacity, ever wonder where those missing bits and bytes disappeared on a HDD or SSD? First there is how it is measured, meaning decimal or base10 vs. binary base 2 for example one Gigabyte (GB) being one billion bytes vs.  1,024,000,000.00 bytes. These space capacities are before RAID or hypervisor or operating system and file system formatting overhead are added. There is also reserved space for bad block re vectoring which can be thought of as hot spare blocks for when the drive (HDD or SSD) detects something going bad. In addition to the bad block areas, there are also some reserved space that you will not be able to access that is kept for drive management, read/write head alignment and other things.

Speaking of large capacity drives, as mentioned earlier, rebuild operations with RAID configurations can take longer given more data to move. Good news is that some RAID systems or solutions can rebuild a 1TB or 2TB drive as fast as or faster than a 9GB drive from a decade ago. The catch is that there are more drives and they are getting larger with 3TB and 4TB shipping and larger ones in the works. Things you can do to minimize the impact of long rebuild times; include selecting the right type of drive that has better endurance, reliability and availability. This could mean that selecting a lower priced drive up front that is not as reliable could cost you down the road. Configuration including RAID level, number of parity drivers, and software, adapter, controller or storage system with ability to accelerate rebuilds can also make a difference.

Another impact of large capacity drives or large numbers of HDDs in general is how to securely erase them when decommissioning. That is assuming you are securely erasing them or taking other safeguards disposition vs. throwing in the garbage or giving them away. Self-encrypting devices (SEDs) normally associated with security can be part of a solution for some environments. Since SEDs can effectively erase the data stored on those by, removing the enablement key, instead of hours or days, for some environments secure erase can be in minutes or less.


There are various warranties on HDDs, those from the manufacture that may be the same as what an OEM or system integrator passes on to their customers. Some HDDs have a manufactures limited warranty of five years while others have shorter terms. Thus while a manufacture may offer a five year warranty, it can be up to the OEM or integrator to pass that warranty on, or in turn provider a shorter duration with different terms or price. Something to think about in terms of HDD warranties is that replacing them can mean sending your old device back in exchange for a new one. If you have sensitive or secure data on those devices, how will they be disposed of? An option is to not leverage return to vendor or manufacture warranties opting for self-disposition, or using self-encrypting devices (SEDs).

This wraps up this post, coming up next in part V we will look at what to use when, where along with other options and some trends.

Ok, nuff said (for now).

Cheers gs

Cloud Computing News, Resources, and Analysis