注意：这是Delphix企业部署系列的第15篇文章-你现在有了德尔菲斯什么目标解决方案设计-第1部分|解决方案设计第2部分|解决方案设计-过渡过程解决方案设计-添加掩蔽|高级时间线|需求分析|影响分析|预算分析|过渡计划|转换计划|推出计划|需求跟踪矩阵|集成资源和系统依赖关系从哪里开始与任何企业平台转型一样，规模是关键。有必要预先了解需要多少台Delphix引擎才能保持当前的支持水平并在不牺牲当前性能的情况下实现增长。为了保持当前的性能，我们需要了解Delphix设备的性能限制，然后设计正确数量的Delphix引擎，使其保持在最大值的80%并支持用例目的：（即引擎是虚拟化引擎吗，它是否支持Jetstream容器，它是否是用于存档的复制引擎或用于灾难恢复的复制引擎等）。请注意，Delphix虚拟化引擎性能是CPU、存储、网络和RAM的组合，列出的是Delphix虚拟化引擎的当前发布限制：吞吐量限制一个8vCPU DE w/10GbE可维持800 MB/s的峰值吞吐量；1GB/s（超大帧）一个16 vCPU DE w/20GbE可维持1600 MB/s的峰值吞吐量；2GB/s（超大帧）一个24 vCPU DE w/30GbE可维持2500 MB/s的峰值吞吐量；使用巨型帧时为3GB/sSnapSync、LogSync和复制流量对总体负载有贡献IOPS限制一个8 vCPU DE可支持超过40K的IOPS（8K块大小）存储IOPS是限制。一个32 vCPU在SSD上持续300K IOPS储存限制VMFS总限制：ESXi v5.0/v5.1上为60TB，最佳性能为100TB，ESXi 5.5上最大为3.6PB+总RDM限值：ESXi 5.x及以上3.6PB用户体验的300对象限制GUI、策略引擎、作业管理都在不断改进，以处理更大的对象数量将您的系统需求映射到低于这些限制是一个棘手的部分。对于任何一种技术，有很多种方法可以用来确定大小，有些方法将使用基于多年系统经验的经验法则，有些方法将收集现有系统上的用户活动和增长率，有些方法可能需要收集I/O和网络吞吐量并进行计算估计。在所有的情况下，系统架构师都应该在软件供应商设计架构时审查他们推荐的产品应用限制。请给我发邮件或发邮件给我，获取文档和数据收集工具，以帮助您从当前系统获取信息。或者，我会在我的博客系列文章末尾提供我的其他文档模板的工作表。为项目购买额外资源了解引擎的数量很重要，有几个原因：1每个引擎的使用者内存和来自VM场的CPU以及这个CPU一个内存必须在VM场上可用以进行分配。如果VM场没有能力为Delphix构建VM服务器，那么必须购买额外的硬件来支持该项目。理想情况下，硬件需求是在项目的影响分析和预算阶段确定的，此时我们正在执行采购阶段。类似地，解决方案设计文档和影响分析应该会产生系统布局和Delphix用例支持，同样，delphixvm服务器的数量也会被调用，此时它正在执行任何所需的采购订单。如果确定了任何其他硬件或软件需求，如VM许可证、存储购买或网络接口卡，项目经理将推动购买这些项目，并跟踪所需的硬件交付周期。大多数公司都会有一个类似这样的供应商采购流程。正如您所看到的，这个过程的执行是许多部门和产品供应商之间的协作，当这个过程阻碍了整个项目的交付时，项目经理应该跟踪进度并注入紧迫感。