Increasing storage system capacity to meet the needs of ongoing growth is a frequent task for traditional storage array solutions, as capacity among shared storage systems is often allocated gradually over time because there is typically a need to conserve expensive disk resources.

In terms of operational management, we estimate that vSAN has a significant impact on the ongoing expansion and modification of array-based storage, because the demand for additional storage performance and capacity can change over time.

The reason for this is that vSAN brings about a significant change in the processes required to deploy additional capacity and performance within the storage platform. This is a very common task in larger environments, and more so when a traditional shared storage array is employed by both virtual hosts and non-virtual systems. In environments such as these, the typical behavior of storage administrators is to maintain the environment by a practice of carving out relatively small chunks of capacity on an ongoing basis, and expanding storage volumes as and when actual utilization demands it. In addition to this obvious operational overhead, there is also typically an impact on agility as well, when multiple operational teams must negotiate over the “how much”, “what”, “where”, and “when” of provisioning additional storage capacity. However, in order to break this scenario down into specific tasks, when the actual provisioning activities occur, storage administrators typically:

Some service providers might avoid the full operational overhead of this problem by acquiring arrays configured at their full raw capacity upfront, and only carrying out allocation tasks (45 minutes). However, the disadvantage of this model of operations is both in the initial CapEx and in the OpEx cost of maintaining a significant proportion of unused capacity across the storage array.

The VMware hyper-converged infrastructure model significantly simplifies these activities, when service providers are deploying standardized servers with consistent internal disk capacity in a building-block architecture. As hosts are typically more frequently provisioned than storage, the natural expansion of the physical server resources is likely to bring about more than sufficient storage capacity and performance, in a newer and more operationally efficient way. That is not to say that this new smoother and more gradual means of provisioning infrastructure does not require appropriate planning. It is also noteworthy that when a service provider does not wish to expand their storage, new hosts can still operate in a vSphere cluster without employing their local storage resources. The datastore can be expanded later by selecting the disks you want to use with vSAN. When adding additional hosts to an existing vSAN cluster, this newly added capacity is made available immediately on the vSAN datastore, allowing the provisioning of new workloads within minutes.

A final consideration for increasing capacity and scaling is the balancing and maximizing of compute and storage resource utilization. One of the key design factors associated with a hyper-converged architecture is the balancing of compute and storage resources – so that disk resources, CPU, and memory resources are consumed and exhausted in parallel, as far as possible.

For instance, the total cost of ownership of any hyper-converged infrastructure would be significantly increased if 95 percent of usable storage resources have been exhausted on hosts when only 35 percent of compute (CPU and memory) is being consumed. This can then be exacerbated significantly when a large-scale or web-scale platform is being designed, and a disproportionate amount of resources are not being effectively utilized across hundreds, or even thousands, of hosts.

The following table provides a summary of the estimations and assumptions of time and effort outlined in the sample scenarios above.

 

These are just a few examples of how vSAN can reduce the sometimes complex tasks associated with traditional storage administration. In these three examples, we have calculated an overall mean improvement in operational management efficiency of 33x.

For the operational tasks outlined in these scenarios, specifically tasks that involve provisioning storage at an explicit service level, the service provider with traditional array-based storage might often spend a significant amount of time and effort in planning the multi-disciplinary activities. These activities, such as determining requirements and modeling for capacity and storage capability between application owners and infrastructure administrators, might with some service providers be more rigorous, predetermined, and automated. However, the reality is that this is rarely the case, and such determinations typically occur over time, as applications are provisioned, or as business requirements change.

Finally, many storage tasks remain unchanged by the adoption of vSAN. For instance, storage management tasks, such as the replacement of failed disks, storage networking, monitoring, and off-site backups, account for the remaining total operational time associated with storage administration. As you would expect, many of these activities are typically required by vSAN in an operational model similar to that required for traditional storage arrays.