Deployment for Hyper-V

8 vCPUs

• CPU resource shortfalls can occur on an 0ver-committed host as well as competition for host resources during high IO utilization.

• CPU reservations are strongly recommended for the Delphix VM so that Delphix is guaranteed the full complement of CPUs even when resources are overcommitted.

• It is suggested to use a single core per socket unless there are specific requirements for other VMs on the same Hyper-V host.

Never allocate all available physical CPUs to virtual machines.

• CPU for the Hyper-V Server to perform hypervisor activities must be set aside before assigning vCPUs to Delphix and other VMs

• We recommend that a minimum of 8-10% of the CPUs available are reserved for hypervisor operation. (e.g. 12 vCPUs on a 128 vCore system).

128 GB vRAM (recommended)

64GB vRAM (minimum)

• The Delphix Engine uses its memory to cache database blocks. More memory will provide better read performance.

• Memory reservations are required for the Delphix VM. The performance of the Delphix Engine will be significantly impacted by the over-commitment of memory resources in the Hyper-V Server. 

• Reservations ensure that the Delphix Engine will not be forced to swap pages during times of memory pressure on the host. A swapped page will require orders of magnitude more time to be brought back to physical memory from the Hyper-V swap device.

Memory for the Hyper-V Server to perform hypervisor activities must be set aside before assigning memory to Delphix and other VMs. 

Failure to ensure sufficient memory for the host can result in a hard memory state for all VMs on the host which will result in a block for memory allocations.

Virtual ethernet adapter requirements.

• SR-IOV is recommended for all virtual ethernet adapters that will be used for Delphix data I/O.

• Jumbo frames are recommended.
  

• A 10GbE NIC in the Hyper-V Server is recommended.

If the network load in the Hyper-V Server hosting the Delphix engine VM is high, dedicate one or more physical NICs to the Delphix Engine.

• Adding NICs only works if VMs are discovered using different interfaces. The NFS/iSCSI mounts will only use the network associated with the discovery.

• See General network and connectivity requirements for information about specific port configurations, and Network performance configuration options for information about network performance tuning.

lDE Controller for the boot drive

SCSI Controller for database storage

Per Hyper-V Storage I/O Performance Tuning Guidelines; For optimal performance, it is recommended that you attach multiple disks to a single virtual SCSI controller and create additional controllers only as they are required to scale the number of disks connected to the virtual machine. 

For example, a VM with 3 virtual disks should distribute the disks across the single SCSI controller as follows:

• IDE Controller 1

  • Boot Drive

• SCSI Controller

  • disk1

  • disk2

  • disk3

For load purposes, we generally focus on the Delphix storage (data disks) and ignore the controller placement of the system disk.

Storage used for Delphix must be provisioned from storage that provides data protection.

For example, using RAID levels with data protection features, or equivalent technology. 

The Delphix Engine does not protect against data loss originating at the hypervisor or SAN layers.

For more information refer to, Optimal storage configuration parameters for the Delphix engine.

When adding additional disks to the block storage pool, storage device initialization will not occur since it is not required on this hypervisor.

The Delphix Engine disks must be stored on NTFS volume(s).

The volume for the Delphix Engine System Disk Storage is often created on the same volume as the Delphix VM definition. In that case, the volume must have sufficient space to hold the Delphix VM Configuration, the virtual disk for the system disk, and a paging area if a memory reservation was not enabled for the Delphix Engine.

The Delphix .vhdx file is configured for a 128GB system drive. 

The volume where the .vhdx is deployed should, therefore, have at least 127GB of free space prior to deploying the .vhdx.

A minimum of 3 VHDXs should be allocated for database storage.

Allocating a minimum of 3 VHDXs for database storage enables the Delphix File System (DxFS) to make sure that its file systems are always consistent on disk without additional serialization. This also enables the Delphix Engine to achieve higher I/O rates by queueing more I/O operations to its storage.

If using VHDXs:

• Each VHDX should be the only VHDX on its NTFS volume

• The VHDX volumes should be assigned to dedicated physical LUNs on redundant storage. 

Provisioning VHDXs from isolated volumes on dedicated physical LUNs:

• Reduces contention for the underlying physical LUNs

• Eliminates contention for locks on the volumes from other VMs and/or the Hyper-V Server Console

If the underlying storage array allocates physical LUNs by carving them from RAID groups, the LUNs should be allocated from different RAID groups. This eliminates contention for the underlying disks in the RAID groups as the Delphix engine distributes IO across its storage devices.

The physical LUNs used for NTFS volumes should be of the same type in terms of performance characteristics such as latency, RPMs, and RAID levels.

The total number of disk drives that comprise the set of physical LUNs should be capable of providing the desired aggregate I/O throughput (MB/sec) and IOPs (Input/Output Operations per Second) for all virtual databases that will be hosted by the Delphix Engine

Disk types supported by the physical LUNs used for NTFS volumes are: Fixed-size and Dynamically expanding.

If the storage array allocates physical LUNs from storage pools comprising dozens of disk drives, the LUNs should be distributed evenly across the available pools.