In this topic:
About Virtual SAN Configurations
Configuration and Operational Notes for the Virtual SAN Node
Configuring Service Dependencies for Proper System Startup and Shutdown
Removing the DCSX Service Dependency in a System Startup
Setting a hypervisor host for a Virtual SAN node running in a VM
Also see:
DataCore Storage Management Provider
DataCore™ Hyperconverged Virtual SAN Software is used to create high-performance and highly-available disk pools using the local storage on application servers. The software may be installed on the host (such as a hypervisor, or virtual machine) to bring the advanced SAN features of the SANsymphony™ Software-defined Storage platform closer to running applications. The host in a DataCore Hyperconverged Virtual SAN configuration (also referred to as a Virtual SAN node) can take advantage of the same performance enhancing features used by dedicated storage servers; such as storage pooling, thin provisioning, caching, and auto-tiering. The host can also leverage the performance of locally-attached devices by reading and writing from fast server RAM and keeping data close to applications to avoid network latency issues.
DataCore™ Hyperconverged Virtual SAN Software works with a broad choice of hardware platforms and all major hypervisors.
A Virtual SAN node is a physical host or virtual machine which has DataCore™ Hyperconverged Virtual SAN Software running and is acting as a DataCore Server in a server group. Virtual SAN nodes are, for all intents and purposes, DataCore Servers running SANsymphony software. Storage resources for the server group are managed centrally from the DataCore Management Console. A Virtual SAN node combines compute, networking, and storage in scalable nodes.
Virtual SAN nodes are deployed using the DataCore Installation Manager or DataCore Installation Manager for vSphere, automated installation tools that guide administrators through the initial deployment of SANsymphony software on DataCore Servers. The wizards perform prerequisite hardware and/or software checks, install the software, and perform port and server group configuration.
Two deployment options for Virtual SAN configurations:
Option #1 |
DataCore™ Hyperconverged Virtual SAN Software
is installed directly on a Windows
Server-based host which is running an application or Hyper-V. |
Option #2 |
DataCore™ Hyperconverged Virtual SAN Software
is installed on one or more Windows
Server-based virtual machines that are running on Hyper-V, an
ESX host or other non-Windows-based hypervisors. |
Generally, each Virtual SAN node contributes
its locally-attached storage to pools in the server group. All uninitialized
block storage devices attached to the Virtual SAN node can be used as
storage resources for pools. Multiple disk pools can be created on a single
Virtual SAN node. Their
storage resources can be combined with other Virtual SAN nodes, integrated
into a central SANsymphony
SAN, or Cloud storage. Internal storage resources may be shared in a highly-available
configuration with multiple Virtual SAN nodes or across a cluster of servers.
A DataCore Hyperconverged Virtual SAN
can consist of from one to 64 Virtual SAN nodes. The Virtual SAN node
does not need to be configured to contribute storage, but instead can
be configured to host applications that access storage directly from the
pools.
Each Virtual SAN node must be properly licensed to run DataCore™ Hyperconverged Virtual SAN Software. DataCore™ Hyperconverged Virtual SAN Software is licensed per node according to the Capacity license activated on the node.
Some steps
may have been performed by the Automated
Installation and Upgrade Wizard during
software installation, in which case skip those steps. Those steps depend
on the template selected during installation.
Most configuration and operations performed for Virtual SAN nodes are the same as that for any standard DataCore Server. However, some special notes apply when performing configuration or operations from a Virtual SAN node, as noted below. (Refer to the associated Help topics below for more information and instructions.)
Once configured, the Virtual SAN node can perform operations and management activities in the same manner as any standard DataCore Server in the server group.
o Refer to the release
notes for this product and the Hyperconverged
Virtual SAN Best Practices Guide for important configuration information.
The guide can be found on the DataCore Support Web page
in FAQ 838 (All Best Practices
Guidelines). Also see these other applicable FAQs on the
DataCore Technical Support Portal
for running the software on virtual machines: FAQ 1155 (Best Practices-Installing
a DataCore Server
within a Virtual Machine), FAQ 1348 (Best Practice Guideline for SANsymphony), and FAQ 1626
(iSCSI Best Practices, Network Settings for DataCore in a VM). (These
FAQs can be viewed by registered
customers with a login to the DataCore Support Web page.)
o Add DataCore Server operation - When adding the Virtual SAN node as a DataCore Server to an existing server group, the Add DataCore Server operation must be performed from one of the DataCore Servers in the existing server group, not from the Virtual SAN node. See Establishing Server Groups.
o Port roles assignments - Port roles should be configured to provide dedicated network ports for use with the software. Remove port roles for all other ports not dedicated to running the software in order to prohibit access. See Assigning Port Roles and Groups.
o Set hypervisor host for virtual machines - This note pertains to Virtual SAN nodes running in virtual machines as outlined in deployment option #2 above. In order to serve virtual disks directly to a hypervisor host, a hypervisor host must be declared for each Virtual SAN node running in a virtual machine. See Setting a Hypervisor Host for a Virtual SAN Node Running in a VM for instructions.
o System startup and shutdown - The software runs as a system service called DataCore Executive (Dcsx); only when the service is started can the virtual disk be accessed. Properly configuring service dependencies is essential to ensure the proper start and/or stop order of the software and application services. See Configuring Service Dependencies for Proper System Startup and Shutdown for instructions. (Also see Removing the DCSX Service Dependency in a System Startup to remove the DCSX service as a dependency.)
o Creating virtual disks - When creating mirrored virtual disks, use a local disk pool of the Virtual SAN node as the primary storage source (top selection) and a pool from another DataCore Server in the server group as the secondary storage source. See Creating Virtual Disks.
o Serving virtual disks - When serving virtual disks, allow the front-end paths to be auto-selected, which is the default setting. See Serving Virtual Disks.
o Discovering served virtual disks - Virtual disks can be discovered, and prepared for use in the same manner as any physical disk. Note: the software will protect devices that are being managed, as well as internal devices that were created when virtual disks are served back to the server that created it. Those protected devices will appear in Disk Manager as Not Initialized. Attempting to initialize those protected devices will result in an error message "The device is not ready." This is normal behavior.
A hypervisor host should be identified for each virtual machine running the software. This hypervisor host setting is intended for use with Virtual SAN configurations and allows virtual machines running the software to create virtual disks from local storage resources and serve them directly to any of the hypervisor hosts in the group to use as storage (as noted in deployment option #2 above).
To set the hypervisor host:
1 Open the DataCore Server Details page for the virtual machine running the software.
2 In the Settings tab, select the Hypervisor host from the drop-down box or select None to remove the hypervisor host.
3 Click Apply.
The SANsymphony software runs as a system service called DataCore Executive (Dcsx); only when this service is started can virtual disks be accessed. The proper start and/or stop order of SANsymphony software and application services is essential, in particular during startup or shutdown of the Windows operating system.
o On startup, an application may start incorrectly or fail if the disk resources used by the application are not available. Ensure that SANsymphony software is running before the application starts by configuring service dependencies. See Ensure Successful Startup.
o On shutdown, an application may shutdown incorrectly or lose data if the disk resources used by the application become unavailable before the application has properly stopped. Ensure that the SANsymphony software keeps running until the application has stopped. See Ensure Proper Shutdown.
The following instructions are an example of how to configure service dependencies. In this example we use Microsoft Hyper-V Server to illustrate how to set the service dependencies correctly. Depending on your specific Virtual SAN configuration, different and/or additional configuration steps may be necessary to achieve the same result.
In this example, we will make the Hyper-V Virtual Machine Management service dependent on the SANsymphony service, so that the Hyper-V service will only start if the service is already running. The service name for the software is DataCore Executive (DCSX).
1 On the
Virtual SAN node, find the service name of the application. The service
name is typically found in the Properties
dialog box of the service in Computer
Management>Services. The service name of the Hyper-V service
is VMMS.
2 Open
a command window and query the current service configuration by entering
this command: SC
QC VMMS
Make
a note of the services listed in the DEPENDENCIES section. In this case,
the current service dependencies are: RPCSS and WINMGMT. Ensure
proper spelling.
3 The
service name for the software is DataCore
Executive (DCSX). In order to extend the list of service dependencies
to include DCSX, enter:
SC CONFIG VMMS DEPEND=RPCSS/WINMGMT/DCSX
The following success message should be displayed: [SC]
ChangeServiceConfig SUCCESS
4 To
confirm that DCSX was correctly added, enter the command SC
QC VMMS again. The list of
dependencies should have the original dependencies, as well as
DCSX.
During system shutdown, by default, the Service Control Manager does not take service dependencies into consideration. As a result, SANsymphony software may be stopped after a Shutdown or Restart has been initiated and before dependent applications.
In order to prevent potential
problems or data loss, a Virtual SAN node running the software should
not
be shutdown or restarted without taking pre-emptive steps.
All applications must be stopped on the Virtual SAN node before initiating a Restart or Shutdown. Dependent services should be stopped before stopping the DataCore Executive service. Provided that the service dependencies have been set up correctly, this can be done by stopping the DataCore Executive service. Initiating a Stop command to the DataCore Executive service will first stop any dependent services before the SANsymphony software is stopped.
Stopping the DataCore Executive service can be done either from Computer Management>Services or from the command prompt. Instructions are provided for both methods.
From Computer Management>Services:
1 Right-click on DataCore Executive and select Stop from the context menu.
2 Confirm the Stop
Other Services message in order to proceed with stopping SANsymphony software as
well as dependent applications.
3 After the DataCore Executive service has successfully stopped, the Virtual SAN node can be safely shutdown or restarted.
From a command prompt:
1 Enter NET
STOP DCSX. A
message will appear that the dependent services will also stop. Confirm
to continue by entering Y.
2 After the DataCore Executive service has successfully stopped, the Virtual SAN node can be safely shutdown or restarted.
The preceding example sets the DCSX service as a dependency for the Hyper-V service.
Under certain circumstances, it may be necessary to remove the DCSX service dependency in a system startup.
In the following example, the DCSX service is removed by reconfiguring the existing dependencies without DCSX; therefore, the Hyper-V service will start without the DCSX service. Depending on your specific Virtual SAN configuration, different and/or additional configuration steps may be necessary to achieve the same result.
1 Open a
command window. The currently configured service dependencies for the
Hyper-V service can be queried by entering
this command:
SC QC VMMS
(The services
are listed in the DEPENDENCIES section.)
2 In
this case, the DCSX service is omitted and the other dependencies RPCSS
and WINMGMT are reconfigured.
SC CONFIG VMMS
DEPEND=RPCSS/WINMGMT
