Optimal storage configuration parameters for the Delphix engine
This topic describes minimum capacity and throughput requirements for storage devices used with the Delphix Engine.
Storage for the Delphix Engine must be able to sustain the aggregated Input/Output Operations Per Second (IOPS) and throughput (MBPS) requirements of all its Virtual Databases. Throughput required for data source synchronization (SnapSync and LogSync) must also be supported.
The Delphix Engine requires storage for:
Item | Description |
|---|---|
A copy of each Source Database | The copies are compressed. |
Unique Block Changes in VDBs | When changes are made to a VDB, the Delphix Engine stores the changes in new blocks associated with only that VDB. The new blocks are compressed. |
Timeflow for dSources and VDBs | The TimeFlow kept for each dSource and VDB comprises snapshots of the database (blocks changed since the previous snapshot) and archive logs. The retention period for this history of changes is determined by policies established for each dSource and VDB. The TimeFlow is compressed. |
In addition to the storage for these items, the Delphix Engine requires 30% free space in its storage for the best performance. See An Overview of Capacity and Performance Information and related topics for more details on managing capacity for the Delphix Engine.
Best practices for storage performance include:
Initial storage is equal to the size of the physical source databases. For high redo rates and/or high DB change rates, allocate an additional 10-20% storage.
Add storage when storage capacity approaches 30% free
Use physical LUNS allocated from storage pools or RAID groups that are configured for availability
Never share physical LUNs between the Delphix Engine and other storage clients.
Keep all physical LUNs the same size.
Provision storage using VMDKs or RDMs operating in virtual compatibility mode.
VMDKs should be Thick Provisioned, Lazy Zeroed. The underlying physical LUNs can be thin provisioned.
Physical LUNs used for RDMs should be thick provisioned.
Measure or estimate the required IOPS and manage the storage disks to provide this capacity. It is common to use larger numbers of spindles to provide the IOPS required.
Physical LUNs carved from RAID 1+0 groups or pools with dedicated spindles provide higher IOPS performance than other configurations
Maximize Delphix Engine vRAM for a larger system cache to service reads
Example
There are two production dSources, totaling 5 TB in size. 5 VDBs will be created for each. The Sum of read and write rates on the production source database is moderate (1000 IOPS), the sum of VDB read rate is moderate (950 IOPS), and the VDB update rate is low (50 IOPS).
Initial storage equal to 5TB, provisioned as 5 x 1 TB physical LUNs, Thin Provisioned. Allow for expansion of the LUNs to 2TB.
Provision as 5 x 950 GB Virtual Disks. VMDKs must be Thick Provisioned, Lazy Zeroed. Using 1 TB LUNs allows expansion to 2 TB (ESX 5.1 limit).
The storage provisioned to the Delphix Engine storage must be able to sustain 1000 IOPs (950 + 50). For this reason, each physical LUN provisioned to the Delphix Engine must be capable of sustaining 200 IOPs. IOPs on the source databases are not relevant to the Delphix Engine.
64GB Delphix Engine vRAM for a large system cache