Enterprise Level Deployment of Delphix: Sizing the Delphix System Software and HW/SW Procurement
Note: This is the 15th in our series of Enterprise Deployment of Delphix. Read the first 14 posts here -
Where to Begin
As with any enterprise platform transformation, size if of the essence. It is necessary to understand up front how many Delphix engines will it take to maintain the current level of support and allow for growth without sacrificing current performance. To maintain current performance one needs to know the performance limits of the Delphix appliance and then architect the correct number of Delphix engines to remain at 80% of the maximum and to support the use cases purpose: ( i.e is the engine a Virtualization engine, will it support Jetstream containers, is it a replicated engine for archiving or a replicated engine for Disaster Recovery, and etc).
Be aware the Delphix Virtualization engine performance is a composite of CPU, Storage, Network and RAM Listed is the current published limits for the Delphix Virtualization Engine:
- Throughput Limits
- One 8 vCPU DE w/10GbE can sustain 800 MB/s peak throughput; 1GB/s with Jumbo frames
- One 16 vCPU DE w/20GbE can sustain 1600 MB/s peak throughput; 2GB/s with Jumbo frames
- One 24 vCPU DE w/30GbE can sustain 2500 MB/s peak throughput; 3GB/s with Jumbo frames
- SnapSync, LogSync and Replication traffic contribute to overall load
- IOPS Limits
- One 8 vCPU DE can sustain more than 40K IOPS (8K block size)
- Storage IOPS is the constraint. A 32-vCPU DE sustained 300K IOPS on SSD
- Storage Limits
- Total VMFS limits: 60TB on ESXi v5.0/v5.1, 100TB for optimal performance, 3.6PB max on ESXi 5.5+
- Total RDM limits: 3.6PB on ESXi 5.x and above
- 300 Object Limit for User Experience
- GUI, Policy Engine, Job Management are constantly improving to handle larger object counts
Mapping your system requirements to stay below these limits is the tricky part. There are many methods to come up with a sizing method for any technology some will use a rule of thumb based on years of system experience, some will want to gather user activity and growth rates on existing systems, others may want to gather I/O and network throughput and make a calculated estimate. In all cases the system architect should review the software vendors recommended appliance limits of the product as they layout the architecture. Delphix provides many methods for estimating the initial need. Please email or message me for the document and data gathering tools to help you grab the information from your current systems. Alternatively I will provide the worksheets at the end of my blog series with my other document templates.
Purchasing Additional Resources for the Project
Knowing the number of engines in important for several reasons: 1 each engine consumer memory and CPU from the VM Farm and this CPU an Memory must be available on the VM Farm for allocation. If the VM farm does not have capacity to build the VM server for Delphix, then additional hardware must be purchased to support the project. Ideally, the hardware requirement was identified during the impact analysis and budgeting phase of the project. At this point in the project we are executing the purchasing phase.
Similarly the solution design document and impact analysis should have resulted in the system layout and Delphix use case support and again the number of Delphix VM servers would have been called out and at this point it is executing any needed purchase orders.
If any other hardware or software requirement needs were identified such as VM licenses, Storage purchases, or network interface cards the Project manager will be pushing for these items to be purchased and any needed hardware delivery lead times tracked.
Most companies will have a vendor purchasing process that will look something like this.
The execution of this process as you can see is a collaboration effort among many departments and the product vendor. The project manager should be tracking the progress and injecting urgency when the process holds up the overall project delivery.