Shared Storage Logical Design

The following section discusses the logical storage design of the environment.

Storage Tiering

Today’s enterprise-class storage arrays contain multiple drive types and protection mechanisms. The storage, server, and application administrators face a challenge in selecting the correct storage configuration for each application being deployed in the environment. Virtualization can exacerbate this problem by consolidating many disparate application workloads onto a small number of large devices.

Given this challenge, it is not uncommon to see a single storage type used for every type of workload, without regard to the actual needs of any particular workload. Not all application workloads are the same, and storage tiering allows for these differences by creating multiple levels of storage with varying degrees of performance, reliability and cost, depending on the specific application workload needs.

Storage Tiering Example

Storage-tiering diagrams often resemble a pyramid structure. Tiering is indicative of the way storage is typically implemented. Although the number of layers might change from one organization to another, the most mission-critical data typically represents the smallest amount of data and offline data represents the largest amount.

Figure 9. Storage Tiering

Determining Storage Tiers

Many metrics can be used to determine the appropriate storage tier to use for application data. For each application or service, determine their storage characteristics by looking at the following:

I/O operations per second (IOPS) requirements

Megabytes per second (MBps) requirements

Capacity requirements

Availability requirements

Latency requirements

The following information can be used to move applications and services to the storage tier designed with matching characteristics.

Consider any existing service-level agreements (SLAs)

Data might move between storage tiers during the information life cycle

Storage Tiering Implementation

The following is the storage tiering implementation for <Customer>.

Table 45. Storage Tiering Implementation with Cinder for the Compute Cluster

Tier Interface SLA Speed RAID # Disk Remarks
<TBD>

Datastore Clusters

A datastore cluster is a collection of datastores with shared resources and a shared management interface. Datastore clusters are to datastores what clusters are to hosts. When a datastore cluster is created, VMware vSphere Storage DRS™ can be used to manage storage resources.

When a datastore is added to a datastore cluster, the datastore’s resources become part of the datastore cluster's resources. As with clusters of hosts, datastore clusters are used to aggregate storage resources, which enable support of resource allocation policies at the datastore cluster level. The following resource management capabilities are also available per datastore cluster.

Table 46. Datastore Cluster Capabilities

Capability Description
Space utilization load balancing A threshold for space use can be set. When space use on a datastore exceeds the threshold, vSphere Storage DRS generates recommendations or performs vSphere Storage vMotion migrations to balance space use across the datastore cluster.
I/O latency load balancing I/O latency threshold can be configured for bottleneck avoidance. When I/O latency on a datastore exceeds the threshold, vSphere Storage DRS generates recommendations or performs vSphere Storage vMotion migrations to help alleviate high I/O load.
Anti-affinity rules Anti-affinity rules for virtual machine disks can be also configured. For example, the virtual disks of a certain virtual machine might need to be kept on different datastores. By default, all virtual disks for a virtual machine are placed on the same datastore.

The following are guidelines to follow when a datastore cluster is created:

Datastore clusters must contain similar or interchangeable datastores. A datastore cluster can contain a mix of datastores with different sizes and I/O capacities, and can be from different arrays and vendors. However, the following types of datastores cannot coexist in a datastore cluster:

NFS and VMFS datastores cannot be combined in the same datastore cluster.

Replicated datastores cannot be combined with non-replicated datastores in the same datastore cluster that is enabled with vSphere Storage DRS.

All hosts attached to the datastores in a datastore cluster must be running ESXi 5.0 and later or vSphere Storage DRS will not run.

Datastores shared across multiple data centers cannot be included in a datastore cluster.

As a best practice, datastores that have hardware acceleration enabled should not be included in the same datastore cluster as datastores that do not have hardware acceleration enabled. Datastores in a datastore cluster must be homogeneous to guarantee hardware acceleration-supported behavior.

vSphere Storage DRS

vSphere Storage DRS provides a method for automating the management of datastores based on latency and utilization. When configuring vSphere Storage DRS, verify that all datastores use the same version of VMFS and are on the same storage subsystem.

Although VMware vSphere Storage I/O Control is enabled by default when vSphere Storage DRS is enabled, it uses a different method for managing latency. With Storage I/O Control, after a latency threshold is reached, Storage I/O Control distributes the resources based on virtual disk share values.

vSphere Storage DRS measures latency over a period of time. If the latency threshold of vSphere Storage DRS is met in that time frame, migration of virtual machines executes to balance latency across datastores that are part of the cluster.

The following should be considered when using Storage DRS:

Always use vSphere Storage DRS where possible.

vSphere Storage DRS provides a way of balancing usage and IOPS among datastores in a storage cluster:

Initial placement of virtual machines is based on storage capacity.

vSphere Storage vMotion is used to migrate virtual machines based on storage capacity.

vSphere Storage vMotion is used to migrate virtual machines based on I/O latency.

vSphere Storage DRS can be configured in either manual or fully automated modes.

Shared Storage Logical Design Decisions

The following table lists the logical storage design decisions made for this architecture design.

Table 47. Shared Storage Logical Design Decisions

Decision ID Design Decision Design Justification Design Implication
For this design, <Customer> has made the following decisions listed in this table.
No datastore clusters will be used for the compute clusters. Datastore clusters are currently not supported with VMware Integrated OpenStack. vSphere Storage DRS will not be used.

results matching ""

    No results matching ""