长篇连载：说说EMC解决方案中的那些产品和案例

谢谢

这个有点类似ScaleIO+XtremSF的架构，服务器的直连存储做节点，用软件虚拟出存储给前面用，再用闪存卡加速弥补服务服务器直连存储的速度劣势。其实这是一套整体的解决方案了。到底好坏怎么样，我也没用过不予评价了。

XtremIO是闪存阵列，是可以出现在IP、SAN的任何一个位置，就和你原来使用阵列一模一样。不存在你说的添加到这个ENMO的解决方案中之说。

我这有一张借鉴目前流行的一个图

问题这个闪存卡的空间OS中的用户可以看闪存卡所代表LUN么？这个架构中多出一个XtremI/O 有必要么？

网上搜了一下Enmo Light Storage。

  你咋知道这个出自何处？

（四）双剑合璧，EMC VNX + XtemCahce加速Oracle数据库

     中端存储，是一个宽泛的定义，通常用于厂商在宣传自身产品时候所使用的的策略。VNX的前身CLARiiON销售的时候主打中端存储市场，随着VNX及VNX2（本文讨论的是VNX2阵列）推出，原来高端产品中的技术不断向中断存储市场迁移。现在的VNX定义已经不是一款单纯的中端存储阵列，EMC给其定位是一款统一的高可用与高性能的存储平台，面向企业混合应用负载及关键应用部署。其实，现今所谓的中端存储市场中，现在看来20年前业界所定义的高端存储的定义：只有大型机支持还保留在高端产品中，其他原本诸如容量，A/A等架构的区分已经并不明显了，以前的指标已经不能完全反应现在的中高端市场的分界线了。

     本篇的主要内容是介绍通过部署EMC VNX和EMC XtremCache如何显著提高整体Oracle RAC的存储性能。解决方案中部署环境是：

• Cisco的UCS C240 M3服务器
• RH Linux 6.3，部署8个节点的Oracle RAC，10Gb以太网互联
• 每节点加装2个700GB的EMC XtremSF卡，共计11TB的PCIe缓存卡
• SAN网络方面用的是Cisco MDS 9506（最大8Gb FC）

     拓扑如下图所示：

     这样的架构的特点可以概括为，通过三层闪存加速技术的结合（XtremCache + FAST Cache + FAST VP），利用VNX存储端闪存缓存技术加速读写，并在服务器端用闪存卡极大程度提高了数据库读的速度。先简单说一下这三种技术：

• XtremCache：XtremCache是一款软件，它需要配合XtremSF来使用，缺一不可。它支持物理和虚拟环境，主要作用的加速读，不挑I/O，顺序和随机都受益。对于写，XtremCache不做任何事情，write-through给后端存储。初次使用的时候需要预热，算法会把经常读的数据缓存到卡里，用户可以灵活配置缓存的容量。
• FASTCache：这个是VNX操作系统中内置的软件，原理是把闪存盘单独用来缓存数据，位于阵列物理DRAM缓存和数据磁盘之间。加速对读写都有用。总的来说，优势是成本上比较低，有的放矢，把访问频繁的数据缓存一份在闪存里。
• FAST VP：同样是VNX操作系统中的内置软件，作用是把数据按照不同的硬件磁盘类型（Flash、SAS、NL-SAS）分层存储，算法会把访问频率较高的数据移动到Flash，相对不频繁的留在成本较低的存储中。优势也是成本最大化考虑。

性能测试案例：

     在运行测试案例前，对于FAST VP，VNX端是需要一些配置的，基本上就是考虑数据池如何划分，每个池里面多少SSD，多少SAS，RAID用什么。这些需要管理员了解一些基本的存储性能知识，看过上一篇解决方案介绍的读者可能会记得，VMAX的SLO中并没有这一步，用户只要选择SLO等级就行了，后端存储池会自动调整。从这点上看来，用户多花钱买高端，从人力上还是节省不少，不过就技术管理人员来说，自己手动配置过，对整个环境也会更加了解，各有各的好处吧。解决方案中的FAST VP设计如下表所示：

案例一（OLTP）：

     测试案例的第一步是OLTP的测试，利用SLOB（Silly Little Oracle Benchmark）来生产随机的读写I/O。整个过程分为两个部分Query-Only和Update-Only，然后分为两个步骤进行：

Query-Only节点扩展测试  – 测试中会从1个RAC节点（64个模拟用户）扩展到8个节点（512个模拟用户），观察性能变化。结果如下，可以看到，整个环境中的读IOPS线性增长，八个节点的IOPS超过380w，且响应时间维持在1ms以下，Read-hit率保持在98%。其中有一点需要注意的是，这个是一个极端的测试情况，Oracle的Active Data容量是小于整个XtremSF卡的容量的，也就是说，XtremCache可以缓存所有的数据库数据，结果就是，在这种情况下，性能表现极其强劲！

Query-Only FAST Suite测试 - 测试启用FAST VP和FAST Cache（统称FAST Suite）后运行同样的测试，比较性能变化。读者会发现，为什么启用了FAST Suite IOPS反而降低了，其实是这个测试过程中，将Oracle的Active Data增加了，总得容量超过了XtremSF卡的总容量，这种情况最接近真实生产的。数据需要不停的从VNX-XtremSF进行交换，并且一部分数据需要从VNX直接读取。可以看到，结果中，Baseline为230w IOPS响应时间在1ms左右，而随着FAST VP中的SSD数目增加性能上是有所提升的，但是提升幅度不是很高，反而在启用FAST Cache前后，性能有10%左右的增长。

Update-Only节点扩展测试 -  这个测试中的负载模拟只是数据更新，整个过程和Query-Only节点扩展测试一样，XtremCache缓存了所有数据，VNX端只需要处理数据更新。

Update-Only FAST Suite测试 -  测试中的Oracle Active Data是大于XtremSF容量的，从上下两张图中可以看到，启用了FAST Suite以后，测试中的写处理性能是有明显提升的，总提升量在70%左右。

案例二（Data Warehouse测试）

     众所周知，在数据仓库环境中的主要衡量指标不是IOPS，而是Throughput，即每秒数据吞吐量。这个案例中就以Throughput为主要内容进行测试。方法和案例中的一样，节点扩展启用FAST Cache和启用FAST  VP两种。效果如下，单位是GB/s，可以看到在启用Cache后的总体Throughput提升还是相当客观的：

节点扩展启用FAST Cache测试 - 可以看到在启用Cache后的总体Throughput提升还是相当客观的：

启用FAST  VP测试 – 这个测试中也是增加Active Data数据量的，也就是说，数据增加以后，同样8节点并启用FAST Cache的测试Baseline是19.90GB/s。随着FAST VP启用，并添加SSD的数量以后，Throughput有着线性的增长。

     综合来看，本篇的测试案例有很多个，而主要目的都是为了帮助证明开篇中所提到的三种闪存加速技术的功效。几个测试案例中，选择的基线比较略有不同，楼主一开始看的时候也有点没看明白。为什么在启用了FAST Suite以后IOPS反而降低了，原来是测试数据总量的原因。总结下来，VNX + XtremCache的性能表现是非常不错的，XtremCache在完全缓存数据的测试结果也差点亮瞎的楼主，当然这是极端的例子，只能证明近服务器闪存这种跳过存储网络的技术，真的可以让存储性能更上一层楼。最后，对于需要评估存储性能的读者来讲，楼主很推荐这篇白皮书中的做法：对于特定的性能功能或技术，在相同的环境下设置性能基线baseline，然后通过启用/禁用，然后进行比较的，最后获得这个性能功能对整体系统的提升百分比，从而评估一个技术的优劣，这个方法在实践中很是值得借鉴。

下一篇按节奏应该看一下VNXe了。

dear 文章太好啦

这个都是在实验室里面做的测试么？

对的，解决方案中心有专门的Lab运行此类测试的。

好羡慕呀

EMC里面有专门做solution的部门，现在也越来越重视solution这块了

哇 ，这样的solution会不会和相关的厂家合作呢？有些资源自己并不能搞定呀。

有没有最近火热的软件定义存储方面的呢？

软件定义相关解决方案很多的，下周应该会有一篇发布。等着吧

好羡慕啊 各种方案随便搞搞挂了再来爽快 呵呵

有些地方小心翼翼的就生怕出事， 哎

顶一个～！也算是史上第一个中文整理的EMC解决方案大典了！

（五） 小身材大用途，VNXe部署千人Exchange企业邮箱

     前几篇介绍的都是EMC存储里的高大上产品，全闪存阵列、高端存储、服务器端闪存卡。今天这篇东西准备走一下亲民路线，聊一聊EMC的入门级存储VNXe。VNXe，这个“e”字，楼主个人理解是两层意思：“Economic”和“Essential”，直接翻译过来就是经济实惠且必不可少。也就是说，VNXe提供的功能是那些能被中小型企业最常用到的，而且价钱相对低廉，成本优势高。虽说是EMC面向中小型企业的入门款阵列，但是VNXe并不是一个所谓的VNX简化版，就面向应用来说完全可以满足企业的核心业务所需。本篇解决方案就介绍了VNXe 3150系列给一家千人规模的公司部署Microsoft Exchange邮箱系统的案例。

首先，大概说一下VNXe 3150的软硬件，这个2U的阵列主要包括了以下功能：

• 统一存储，可以连IP网络（CIFS，NFS），iSCSI的Block存储。
• 可以装2.5寸的闪存盘和SAS盘，以及3.5寸的SAS和NL SAS盘，最多100个盘。
• 包括本地复制，远程复制，数据保护和安全功能软件。

     EMC为VNXe建议的使用场景有几种，Microsoft Exchange、VMware datastore、Hyper-V datastore、共享文件和通用iSCSI存储。可以看到基本上包含一个中小企业在核心应用，虚拟化以及文件存储上的绝大多数需求了。本解决方案就给出的就是一个部署Exchange的例子。部署架构和环境如下图所示：

     环境中部署了两台Exchange Hyper-V Server，配置了一个DAG Group，每台Server有500 Active和500 Passive Mailbox每个大小为1.5GB。每个VM分别连接到一台VNXe阵列，存储端磁盘分布使用4+1 RAID5，物理盘是900GB的SAS 10k RPM，分别存储Exchange DB和Log。存储网络直接用的是1Gb/s的iSCSI。数据的总容量是近2TB。

Exchange每邮箱IOPS：

     整个部署性能方面的设计是规划了每个用户邮箱0.24 IOPS。这个0.24 IOPS有必要展开说一下。从Exchange 2010的IO特性来说，一种计算每个Mailbox的IOPS的方法是：

• Mailbox disk IOPS per mailbox = (MSExchange Database Instances\I/O Database Reads/sec (Information Store\database)) + MSExchange Database Instances\I/O Database Writes/sec (Information Store\database) ÷ (number of mailboxes on that database)

假设：

• MSExchange Database Instances\I/O Database Reads/sec (Information Store\database) = 28
• MSExchange Database Instances\I/O Database Writes/sec (Information Store\database) = 32
• Number of mailboxes = 1000

那么每个mailbox的IOPS就是：

• (28 + 32) ÷ 1000 = 0.06 IOPS

每个Mailbox 0.24 IOPS是什么概念呢？，MS给出来一个表参考的表，相当于基本上每个用户每天收发250份邮件的水平。

测试结果：

     测试中使用了MS的Exchange测试工具Jetstress 2010，这个工具专门是用来模拟Exhange Server的用户行为的。测试分为两个部分，服务器性能测试和Exchange数据库备份与恢复测试。服务器测试性能测试结果如下，可以看到达到0.24 IOPS每个用户的时候的性能状况，服务器的总IOPS达到254，平均读等待和写等待分别为17.8ms和5ms，对于Exchange邮件这种对响应时间不苛刻的应用来说已经够用了。

数据库备份与恢复测试主要测试的存储的Throughput，这数字分别达到了26MB和52MB

     总结来说，本篇解决方案中的性能测试部分并不是非常详细，而且就结果来看，VNXe 3150在处理1000个邮箱0.24 IOPS每个用户的情况下全无压力，可见VNXe 3150的潜力完全不止1000个Exchange邮箱和0.24 IOPS每用户。因为每个企业部署的情况有所不同，环境和用户使用上也有差异，所以本篇解决方案只是在某个尺度的情况下，提供一个解决方案的演示案例，证明使用VNXe可以非常好的处理类似Exchange企业邮箱这样的核心应用，并优化应用负载。楼主最后八卦了一下VNXe list price，基本上这个2U的机器每平方米价格和上海内环每平米的房价差不多，作为可以搞定上千人的邮件系统存储，性价比还是很高的。

下一篇楼主还没想好，先过个周末再说，不过下周肯定有一篇软件定义存储的解决方案，什么时候发，关注预告！