通过我们的最新版本Compliance Engine，Delphix现在支持部署到Amazon Web Services（AWS）和其他私有/公共云环境中。在这个博客系列中，我将讨论我在AWS方面的经验，并讨论Delphix如何帮助客户进入AWS并充分利用现有的AWS部署。AWS是继ESX之后我们部署到的第二个主要平台，我们希望了解AWS生态系统的性能特征。在这篇博客文章中，我将讨论我在AWS上运行的实验，以具体评估可用的块级存储选项。IO报告卡Delphix部署为一个虚拟设备，并依赖底层存储来维持由引擎虚拟化的数据库的聚合负载。我们开发了一个叫做"IO报告卡"的工具，用来评估分配给Delphix的存储。基于开源文件系统基准FIO的报告卡运行合成工作负载，并根据延迟和吞吐量特性生成字母等级。这是我们的一位客户的报告卡示例，该客户将全闪存阵列用于他们的Delphix引擎。这是一位使用第二层存储阵列的客户提供的。请注意，此阵列有一个带有闪存驱动器的层，由高容量旋转磁盘支持。在每次部署Delphix之前，都会运行报告卡，以确保配置的存储足够。安装程序Delphix作为EC2实例部署在AWS上，使用EBS卷进行存储。AWS为弹性块存储（EBS）存储卷提供了三个选项：1标准2通用（GP）SSD3.提供IOPS标准卷每卷有100 IOPS，GP卷提供高达3 IOPS/GB的存储，能够维持每卷3000 IOPS的突发。已配置的IOPS卷可为每个卷每GB最多支持30个16KB IOPS。最近添加了GP卷（在我的实验中），但对它们的特性知之甚少。这就是为什么我在这个选择上花费了不成比例的墨水。AWS的IOPS SLA实际上是一个吞吐量保证。如果我们提供1000 IOPS，则可以保证16MB/s的吞吐量。使用较小的IOs可以提供更高的IOPS，因为IOs随后可以合并。我使用了三个Delphix引擎，配置如下。实例名称实例类型EBS卷卷类型德尔菲1r3.4X大3x250GB标准卷德尔菲2r3.4X大3x250GBGP SSD（9K IOPS）德尔菲3r3.4X大3x250GB配置的IOPS（10K IOPS）EBS卷有首次访问惩罚。最好使用DD或某些类似的实用程序初始化所有块，以产生可预测的IO性能。结果完整的报告卡可以在这里找到：标准卷、通用SSD和配置的IOPS。大多数结果符合预期，并符合sla。在这篇文章中，我将讨论这些实验中的一些有趣的观察结果。OLTP工作负载评估数据库应用程序IO性能的最重要工作负载之一是8KB随机读取。在这个测试中，该工具使用16个线程在所有设备上生成8KB的随机偏移读取。下面的图表是IO报告卡结果的片段。"等待时间"图表显示了平均延迟和分数刻度上第95个百分位延迟。这些分数是基于95%的潜伏期，任何超过14毫秒的都得"D"。"柱状图"显示延迟柱状图，而"缩放"图表显示当负载从16个线程增加到32个线程时，第95个百分位的延迟是如何变化的。图1：标准卷，8KB随机读取图2：通用SSD卷，8KB随机读取图3：配置的IOPS卷，8KB随机读取在这个世界上，你付出什么就得到什么。-库尔特·冯内古特，猫的摇篮。正如预期的那样，标准卷的成绩单成绩并不令人印象深刻。配置的IOPS本质上是对给定数量的IO的延迟保证。因为我没有"提供"任何IOPS，所以我预期延迟低于标准，这就是我们看到的。平均延迟约30毫秒，异常值约为90毫秒。很明显，此存储无法支持大多数数据库工作负载。如果发出较小的块请求（4KB、8KB），则标准卷可以提供更高的随机读取IOPS，这些请求可以由EBS合并到下游配置的IOPS卷显示的级别类似于高端闪存阵列，在3ms以下有95%的异常值。延迟直方图显示在2ms以下响应的百分比甚至令人印象深刻。负载缩放图还显示随着负载翻倍而良好的扩展。当配置了足够的IOPS时，配置的IOPS卷会显示与全闪存阵列类似的性能特征。通用SSD卷的结果喜忧参半。平均7毫秒的延迟与典型的第二层SAN或NAS存储一致。但直方图显示了双峰分布。一个群集大约1ms，另一个群集大约20ms。这表示存储分层或某种类型的限制。我的工作负载的工作集大小是256GB，柱状图显示，只有大约50%的响应在2ms之内，根据这个数据，我们可以在小型或轻负载的数据库中获得良好的性能。但是对于较大的数据库或IO密集型工作负载的数据库，很难从这个特定的存储选项中获得良好、一致的性能。考虑到它们的价格，"GP-ssd"是轻负载数据库的一个可行的选择。DSS或批处理工作负载图4：读吞吐量与负载数据分析、报告和批处理工作负载通常受吞吐量限制-需要大量数据移动。为了评估这些工作负载的性能，IO报告卡会生成1MB的读取请求，以进行顺序偏移。该工具通过将线程从4个增加到64个来扩展负载。下表显示了负载增加时观察到的总吞吐量。考虑到标准卷是由旋转磁盘支持的，我希望它们在顺序工作负载下表现更好，这就是我们在这里看到的。令人惊讶的是，GP卷无法维持较高的顺序吞吐量。在所有这些情况下，工作负载都受到IOPS的限制。请注意，配置的IOPS卷能够驱动~300MB/s的吞吐量，这几乎是其SLA的两倍。对于GP和配置的IOPS卷，SLA适用于顺序或随机工作负载。写入性能报告卡使用小的（1KB）的写入来模拟典型的日志写入程序，而使用大的（128KB）来模拟重载和批处理写入的日志写入程序。对于大型写测试，所有卷的吞吐量都是有限的，并且结果与sla相匹配。所附的报告卡具有三种卷类型的延迟分布。图5：标准卷上1KB顺序写入的延迟直方图小块写测试也受到IOPS的限制，但在标准卷和GP卷之间显示了有趣的延迟分布。标准卷在小块写上表现良好。许多小块请求合并为单个大块请求，从而产生更高的有效IOPS。另外，由于这些请求都是顺序偏移的，所以旋转磁盘在上运行得很好。标准卷也可能有一个回写缓存层，在写入到达旋转磁盘之前对其进行缓冲。虽然我们没有足够的信息来证实这一点。图6:GP SSD卷上1KB顺序写入的延迟直方图对于GP卷，延迟分布是双模的。大约60%的写操作在1毫秒内完成，而其余40%的写入操作需要10毫秒以上。这再次指向GP卷的突发容量SLA。只有一部分写操作由快速存储提供服务，而其他写入操作则在突发事件无法持续时排队等待。如果您的工作负载特别是写密集型，那么您就走运了。EBS卷在每购买容量的写入性能方面相当慷慨。我多次获得高于配置容量的容量。为什么GP量有时比标准卷慢？在对数据进行了一点深入研究并进行了一些额外的运行之后，我意识到GP卷的问题是突发性的IOPS。GP卷的构建可支持每卷3000 IOPS的突发。因此，对于3个设备，我们总共应该有9000个IOPS。但是，SLA只针对"突发容量"，这意味着卷将仅在短突发情况下维持这些IOPS。事实上，我的实验表明，加载几分钟后，IOPS开始下降。GP卷的持续IOPS SLA实际上是3 IOPS/GB数据，在我们的示例中为2250 16KB IOPS。在我的测试中，我观察到初始测试可以获得更高的IOPS和更好的延迟。然后是16KB IOPS平台。目前尚不清楚能维持多少次爆发或持续多久。GP卷可在5分钟内保持每个卷3000 IOPS，之后恢复为3 IOPS/GB。结论最新版本的Delphix部署在AWS中，我想了解AWS中可用的存储（EBS）选项的性能特征。我在三种可用的EBS卷上运行了合成工作负载。以下是我可以从这项工作中得到的一些观察。如果使用标准卷，运行IO密集型工作负载的DB应用程序的IO性能将低于标准通用SSD卷具有良好的性价比，是小型、低负载数据库的理想选择。但对于大型（大于250GB）或IO密集型应用，它们是不够的。对于OLTP或DSS样式的工作负载，最好使用具有已配置IOPs的卷。以下公式显示应用程序需要多少配置的IOPS。部件可从AWR报告中获得。最佳IOPS=物理读取总IO请求+物理写入总IO请求+重做写入在与AWS弹出式loft中的EBS专家交谈后，我意识到AWS上的DB应用程序的一般做法是根据容量"最大化配置的IOPS"。因此，客户最终通常会为其存储调配尽可能多的IOPS（30 IOPS/GB）。这样做的主要原因当然是可预测的性能，但也将数据从迁移到调配的IOPS卷