Important Notes:In this topic:
Creating disk pools for storage containers
Creating virtual disk templates to define storage container capabilities
Creating a datastore on a storage container
Migrating and cloning virtual machines
The SANsymphony™ Software-defined Storage platform has been integrated with the virtualization world of VMware vSphere™ datacenter platform and vCenter™ management by providing a VASA (vSphere Aware Storage API) Provider for SANsymphony software. The DataCore VASA Provider allows administrators to configure SANsymphony storage resources as storage containers for virtual machines and enables storage policy-based management (SPBM) of virtual machines—all from the VMware vSphere Web Client.
Custom storage policies, based on storage performance characteristics, are created and defined in VMware vSphere Web Client to help Virtual Infrastructure (VI) administrators overcome storage provisioning challenges. The DataCore VASA Provider enables SPBM by advertising the capabilities of the datastores to the vCenter. The administrator selects the desired storage policy and can then choose from a list of compatible storage containers when a virtual machine is deployed. In turn, a SANsymphony VVOL virtual disk is automatically created from compatible pools making the virtual machine hard disk policy compliant, thus extending virtual machine-level management to the storage layer.
Terminology |
|
Storage Container (SC) |
A storage container is used to create VVOL datastores (also known as virtual volumes or VVOLs) that are connected to a storage provider. Storage containers are defined and resourced from SANsymphony disk pools. See Creating a Datastore on a Storage Container for more information. |
Virtual volume (VVOL) |
A VVOL datastore allocated from a storage container that will be ultimately used to create a virtual machine. Virtual volumes that are allocated from the same storage container will have the capabilities of that storage container. Virtual disk templates define the capabilities of the VVOL datastore. Virtual volumes are represented in SANsymphony software as VVOL virtual disks. |
Protocol Endpoint (PE)
|
Protocol endpoints identify the location of the VVOL virtual disks and are used to establish paths for virtual machines. They make available virtual volumes to ESXi hosts and route traffic from ESXi hosts to the appropriate SANsymphony virtual disk. Protocol endpoints are represented as Protocol Endpoint virtual disks in SANsymphony software. See Creating Disk Pools for Storage Containers for more information. |
Bind
|
Binding is the process by which a virtual volume becomes available to ESXi hosts when the virtual machine is powered on. This process is equivalent to serving the virtual disks representing a virtual volume to the ESXi host. The virtual volume is "bound" to their protocol endpoint and only when bound are visible to the ESXi host. The VASA Provider creates all the necessary path connections for the protocol endpoint. See Creating Virtual Machines for more information. |
Unbind
|
Unbinding is the process by which a virtual volume becomes unavailable to ESXi hosts when the virtual machine is powered off. This process is equivalent to unserving the virtual disk. |
Important Notes:
o Before you begin, read the Release Notes for DataCore VASA Provider that contain requirements, setup, and installation instructions and other important information. The release notes can be viewed from the SANsymphony installation package or downloaded from the DataCore download site via the SANsymphony package. This feature may be installed using the SANsymphony installation package.
o During installation of this feature, the VASA Provider is registered with the designated vCenter. A user account with the VVol Managers role is required to install the VASA Provider and perform all actions in VMware vSphere Web Client that involve the VASA Provider, see Registering Users and Assigning Roles for more information.
o This topic contains information pertaining to the VASA Provider used with the VMware vSphere Web Client and the interactions between vSphere and SANsymphony software, but does not provide instructions for performing vSphere operations. See VMware documentation for information and instructions on performing operations in vSphere, such as creating datastores, storage policies, and virtual machines.
o Virtual disks that represent VVOLs and Protocol Endpoints are identified by subtypes in SANsymphony software. The subtypes are identified in the Type column in Virtual Disk Lists in the DataCore Management Console. The subtype, if applicable, will follow the virtual disk type, for example Single Protocol Endpoint, Mirrored VVOL.
o Virtual disks in SANsymphony that are associated with virtual machines in VMware vSphere cannot be deleted, renamed, or altered (by commands such as Replace, Move, Split and Unserve, Convert to Mirrored, Convert to Dual, or resizing the virtual disk) in SANsymphony.
o Paths cannot be changed on a protocol endpoint when a VVOL virtual disk is bound to it.
o Continuous Data Protection (CDP) and Sequential Storage (Random Write Accelerator) are not supported with VVOLs. Replication is not supported and is not recognized at the VMware level.
o All snapshot operations should be performed in the VMware vSphere Web Client. See Creating Snapshots of Virtual Machines for more information.
o Cloning and migration of virtual machines should be performed in the VMware vSphere Web Client. See Migrating and Cloning Virtual Machines for more information.
o If the VASA Provider is unavailable for any reason, no configuration changes can be performed with regards to protocol endpoints or VVOL virtual disks. If a virtual machine is powered off, it cannot be powered on when the VASA Provider is unavailable. For these reasons, a best practice is to have the VASA Provider configured for high availability.
Step |
Procedure |
1 |
The Storage Provider tab in the vSphere Web Client displays information about the DataCore VASA Provider that is used to provision and manage SANsymphony storage resources. To access the Storage Provider tab: 1 In the VMware vSphere Client or Web Client, from the Home tab, click Hosts and Clusters. 2 In the Navigator, select the vCenter. 3 In the Manage tab, click Storage Providers. DataCore SANsymphony Provider
should be listed as a Storage Provider. The status should be Online. The server group should
be in Active mode. |
2 |
In SANsymphony, create disk pools to use as storage containers. See Creating Disk Pools for Storage Containers. |
3 |
In SANsymphony, create virtual disk templates that use the disk pools as storage resources. Templates define the capabilities of the datastores and advertise those capabilities to the vCenter. See Creating Virtual Disk Templates. |
4 |
In the vSphere Web Client, create VVOL datastores on storage containers. Datastores are used to create virtual machines. See Creating a Datastore on a Storage Container. |
5 |
In the vSphere Web Client, use the properties defined in the virtual disk templates to create virtual machine storage policies that match the capabilities of the storage containers (datastores). See Creating VM Storage Policies |
6 |
In the vSphere Web Client, create virtual machines with compatible virtual machine storage policies from a compatible storage container. See Creating Virtual Machines. |
SANsymphony disk pools are used as storage resources for storage containers. VVOL datastores are created from storage containers.
Virtual disk templates
replace pool naming conventions used in earlier versions. Templates define
the pools to use when creating VVOL datastores, see Creating
Virtual Disk Templates.
To create disk pools:
o See Creating Disk Pools for instructions. Follow the instructions in the wizard to create the required disk pools. Existing disk pools may also be used.
o Templates define the pools to use when creating VVOL datastores, One disk pool is required to create a datastore without high availability (single VVOL virtual disk), one shared pool is required to create a shared datastore (dual VVOL virtual disk), and two disk pools on different servers are required to create a highly available datastore (mirrored VVOL virtual disk).
o Multiple VVOL datastores can be created from the same storage container (pool).
After disk pools are created, create virtual disk templates in order to advertise the capabilities of the datastore to the vCenter.
o New disk pools are added to the server group configuration under the associated DataCore Server and a Disk Pool Details page is created for each disk pool.
Virtual disk templates are used by the VASA Provider to define the capabilities of storage containers which will be used to create VVOL datastores. During the creation of a VVOL datastore in the vSphere Client, all SANsymphony virtual disks templates are listed to assist the administrator in selecting a compatible datastore for the virtual machine. Templates allow for greater control over how virtual machines are provisioned.
Templates replace pool naming
conventions used in earlier versions and are now required for the VASA Provider.
Create virtual disk templates in SANsymphony that specify the disk pools that were created as storage containers. Templates can also specify other properties of the VVOL virtual disks that are created as a result of the datastores. Supported features enabled on the virtual disk template will be enabled on the associated virtual disks when the virtual machine is created.
The virtual disk properties defined in a template can then be used to define storage policies (SPBM) for virtual machines in vCenter. See Creating VM Storage Policies.
To create virtual disk templates:
o See Virtual Disk Templates for more information about templates and instructions to create them.
o Create templates to describe the capabilities of each pool. More than one template can be created for the same pool.
o All virtual disk templates created in SANsymphony are eligible, but not required to be used as storage containers in vSphere. All templates will be visible in vSphere regardless of whether they are used in vSphere.
o A Virtual Disk Template details page is created for each template. The template is added to the Templates List.
o The VASA Provider creates protocol endpoint virtual disks (PEs) in SANsymphony for all disk pools defined in templates. Protocol endpoint virtual disks represent pool resources.
· When a single virtual disk is defined in a template, a single protocol endpoint for the pool is created if it does not already exist.
· When a mirror virtual disk is defined in a template, then a mirrored protocol endpoint (with both pools) and two single protocol endpoints (one for each pool) are created if they do not already exist.
· When a dual virtual disk is defined in a template, a dual protocol endpoint and two single protocol endpoints (one for the pool on each server) are created if they do not already exist.
· Each protocol endpoint is only created once in the server group, regardless of the number of times the pool/server combination exists in templates. For example, if Template1 uses pools "Disk pool 1" and "Disk pool 2" in a mirrored virtual disk, then three protocol endpoints are created (a mirrored PE for both pools, a single PE for "Disk pool 1", and a single PE for "Disk pool 2"). Later Template2 is created that uses pools "Disk pool 1" and "Disk pool 3" in a mirrored virtual disk. This action results in two additional protocol endpoints being created (a mirrored PE for both pools and a single PE for "Disk pool 3"). The single PE for "Disk pool 1" is not created because it already exists in the configuration.
o Protocol endpoint virtual disks are named Protocol Endpoint with a number appended to make it unique. (For example, Protocol Endpoint, Protocol Endpoint 1, Protocol Endpoint 2, and so on.)
o Pools and protocol endpoint virtual disks used in templates cannot be removed from the server group configuration.
From vSphere, create a datastore of type VVOL on a storage container.
Virtual disk templates define the capabilities of a datastore. When a datastore is created, it inherits all storage-based policies from the virtual disk template.
A storage container is the equivalent of a single disk pool (used to create single or dual VVOL virtual disks) or a set of two disk pools (for mirrored VVOL virtual disks).
Virtual volumes created from a particular datastore (storage container) will inherit the capabilities of that storage container. The VASA Provider uses templates to advertise the capabilities of the datastores to the vCenter, and the vCenter uses this information to determine storage container compatibility when a virtual machine is created.
Important Notes
o In order to create data stores, SANsymphony disk pools and templates defining the capabilities of the datastore are required.
o Select VVOL as the datastore type when creating the datastore in the wizard.
o In the container selection in the wizard, virtual disk templates created in SANsymphony will appear in the list of storage containers. Select a virtual disk template that defines a compatible storage container for the datastore.
o Multiple VVOL datastores can be created from the same storage container.
o In the event that a storage container becomes noncompliant with the defined storage policy, the existing virtual machines will continue to run in the same storage container with a compliance status of Noncompliant. The virtual machine may be migrated to a compliant storage container.
For additional information or instructions on creating storage containers and datastores, refer to VMware documentation.
After the datastore is created:
o The ESXi hosts selected to use the datastore are automatically registered in SANsymphony if they do not already exist.
o The corresponding protocol endpoint virtual disks in SANsymphony are served to the selected hosts, either when the datastore is created or after by manually mounting the datastore. (The virtual volume is not available to ESXi hosts until the virtual machine is powered on.)
o The template selected for the datastore will automatically be set to read-only, prohibiting any changes to the template. Read-only templates can be viewed in the Templates List. The read-only designation is indicated under the icon in the Virtual Disk Template details page.
Storage policies in vSphere are a collection of rules used to specify storage requirements for virtual machines. Storage policy-based management (SPBM) helps administrators choose policy-compliant storage for virtual machines based on application requirements.
The virtual disk properties defined in templates can be used to define virtual machine storage policies in vCenter. After creating a new datastore, the administrator can create a storage policy based on the virtual disk template that matches the datastore.
Possible rules for virtual machine storage policies:
o Storage profiles
· Performance Class (Archive, Low, Normal, High, Critical)
· Replication Priority (Low, Regular, High, Critical)
· Mirror Recovery Priority (Low, Regular, High, Critical)
· Write Aware Auto-tiering (Yes, No)
o Disk type (Single, Mirrored, or Dual)
· Dual disks require a qualified shared pool in SANsymphony that is configured as the storage container pool.
o Deduplication (Yes, No)
· Requires a deduplication pool created in SANsymphony that is configured as the storage container pool.
o Auto-tiering (Yes, No)
· Requires this feature to be enabled in SANsymphony software.
o Write-through enabled (Yes, No)
o Redundant mirror paths (Yes, No)
· Requires sufficient number of available ports with the mirror role assigned.
Important Notes:
o Select DataCore SANsymphony Provider as the provider for Rules based on data services in the Rule Set in the wizard.
o Before creating storage policies based on storage profiles, ensure that a matching storage profile exists in SANsymphony. For instance, if a defined storage policy has attributes such as critical mirror recovery priority and write-aware auto-tiering, then a storage profile should also exist with the same attributes and that storage profile should be selected in the template.
o Ensure that the datastores that satisfy the rules are displayed as compatible datastores in the Storage Compatibility list in the wizard.
o The VMware default storage policy selected when deploying a virtual machine will create a virtual machine without high availability (single VVOL virtual disk with a Normal storage profile in SANsymphony software).
For additional information or instructions on creating storage policies, refer to VMware documentation.
When creating a virtual machine, the administrator selects a storage policy and the wizard displays a list of compatible datastores to select as storage. This ensures that storage can be selected based on storage policy and the virtual volume is created from a storage container with matching capabilities. As a result, SANsymphony creates a VVOL virtual disk from pools with compatible capabilities and then binds these virtual disks to the virtual machine.
Important Notes:
o To create a compliant virtual machine, select the appropriate storage policy in the wizard and select a datastore from the compatible storage list to create the virtual machine.
o The VMware default storage policy selected when deploying a virtual machine will create a virtual machine without high availability (a single VVOL virtual disk with a Normal storage profile in SANsymphony software).
o In the event that a storage container becomes noncompliant with the defined storage policy, the existing virtual machines will continue to run in the same storage container with a compliance status of Noncompliant. The virtual machine may be migrated to a compliant storage container.
o VVOL virtual disks created by the VASA provider use system managed mirroring by default. If system managed mirroring is enabled, then later disabled for the server group, all virtual disks (including VVOL virtual disks) are converted to use standard mirror paths. After this point, any new VVOL virtual disks later created while system managed mirroring is disabled are created using standard mirror paths.
When a virtual machine is created:
o Typically
there are three associated virtual disks created in SANsymphony:
one for configuration data, one for the virtual machine hard disk (vmdk
file), and one for swap data (vswp file), These virtual disks are created
with the same name as the virtual machine. (Any additional hard
drives created for a virtual machine will be named after the virtual machine
in this format: VMName_1.vmdk, VMName_2.vmdk, and so on.)
Do not delete
any virtual disks associated with a virtual volume in VMware.
· The vmdk and configuration file for the virtual volume will appear in the configuration during the virtual machine creation.
· The swap file will appear in the configuration when the virtual machine is powered on and disappears from the configuration when the virtual machine is powered off.
· When the virtual machine is turned on, the virtual volume is bound to the protocol endpoint, and the virtual machine hard disk (vmdk) is made available to hosts. The virtual machine hard disk is displayed in the Hosts panel under the ESXi hosts and under the associated protocol endpoint. Since the virtual disks are not served to the hosts, there will be no serve information or front-end paths displayed in the DataCore Management Console. Only mirror paths are displayed. Hosts only see protocol endpoints, which directs and connects the virtual machine to the corresponding virtual volume. I/O goes directly to the virtual volume.
o Supported features enabled on the virtual disk template will be enabled on the virtual disks when the virtual machine is created.
For additional information or instructions on creating virtual machines, refer to VMware documentation.
Important Notes:
o Snapshot operations should be performed in the VMware vSphere Web Client. Snapshots of VVOL virtual disks cannot be created directly from SANsymphony software.
o Snapshot virtual disks will be created and maintained in SANsymphony as a result of snapshot operations performed in the vSphere Web Client. In SANsymphony, snapshots will be named after the virtual machine with a number appended to make it unique (such as VMsnapshot.vmdk 1, VMsnapshot.vmdk 2, and so on). Snapshots of VVOL virtual disks will appear in the console and have the subtype VVOL Do not perform any snapshot operations on existing snapshots of VVOL virtual disks or manipulate the snapshots in any way from SANsymphony software.
o A mapstore pool used for snapshots created in vSphere Web Client must be a SANsymphony disk pool that has been configured as a storage container. If a mapstore pool assigned in SANsymphony has been configured as a storage container, it will be used for the mapstore; otherwise; an existing storage container pool will be automatically selected by the VASA Provider when the first snapshot is created of a virtual volume. See Creating Disk Pools for Storage Containers for more information.
Important Notes:
o Cloning and migration of virtual machines should be performed in the VMware vSphere Web Client, not in SANsymphony software.
o Migrations can be performed to change the virtual machine storage, change the host, or both. For example, the storage may be changed if it becomes incompatible over time, or to change the policy of a virtual machine from a single VVOL virtual disk (not highly available) to a mirrored VVOL virtual disk (highly available).
o When a virtual machine does not differ much from the snapshot, cloning is faster than doing block level copies of the virtual machine.
o During migration or cloning, it is possible that many snapshots, DataCore Disks, and pass-through virtual disks may be created in SANsymphony software to facilitate the process. These entities may or may not be automatically removed after the operation is completed. These entities are owned by the VASA Provider and ESX and therefore should not be manipulated in any way.
