StorNext概述
Quantum StorNext是一款虚拟化平台，能够提供横向扩展存储能力。它使企业可以通过创建流畅的文件存储基础设施来满足各种性能和长期存档要求。除了强大的扩展能力和极高的效率外，灵活性也是StorNext的重要特性－它支持包含多个操作系统、存储设备类型、厂商和存储网络协议的异构环境。它适用于需要使用SAN文件系统实现快速数据访问和低延迟的应用，以及使用分布式LAN客户端的CPU密集型应用。此外，StorNext还包括一些强大的企业级功能，例如，复制和重复数据删除等。
Quantum StorNext 能够提供高性能文件共享以及企业数据管理和保护，广泛应用于全球大多数数据密集型行业，如：传媒和娱乐、石油和天然气、卫星成像以及基因组研究。StorNext 4.0 采用的这项成熟技术具有复制、近线重复数据删除、分布式迁移服务器、部分文件恢复以及简单易用的管理控制台等特性。StorNext 包括两个核心组件：SAN 共享文件系统和存储管理器(Storage Manager)，使您能够史无前例地共享、管理和保护您的重要商业信息。
StorNext 的共享SAN 文件系统能够迅速存储信息，实现信息的跨异构平台、富媒体应用以及大多数磁盘和磁带系统的同步共享，从而加快业务经营。StorNext 能够更快地处理和发布内容，使客户能够整合共享的图片存储库、媒体内容、分析数据以及其他重要数字资产。即使是在跨Linux、Mac、Unix 和Windows 操作系统的异构环境中，SAN 或LAN 中的主机也能轻松地访问所有文件。
随着时间的推移，文件的成本和性能特性可能会降低。利用基于策略的分级存储和存档功能，StorNext Storage Manager 能够降低成本和简化管理。确保数据传输透明化、文件在线并可供访问，同时大幅降低存储和管理成本。StorNext的特征与优势概括如下：
l 可扩展存储虚拟化
l 高性能数据共享
l 跨 Linux、Windows、UNIX 和 Mac 操作系统同步整合
l 大规模可扩展归档
l 在线分级存储和归档
l 文件系统容量优化
l 全局数据保护和数据分发
测试目标
目前存在一个海量小文件应用，其存储需求概括如下：
l 文件对象数量约20亿，PB级存储容量，GB级数据吞吐量；
l 海量小文件应用，85%文件约为1KB，对文件系统IOPS要求高；
l 高扩展性，客户端数量能够扩展至100 ~ 1000台；
l 多平台支持，包括UNIX、Linux、Windows；
l 虚拟化共享存储，存储资源统一管理；
l 数据分层归档支持；
l LDAP/NIS/AD安全机制无缝整合；
l 开放式服务器和存储系统支持。
根据StorNext官方资料和实际部署案例，以及实际实施情况来看，StorNext能够满足上述存储需求。该存储需求有别于普通需求，关键特点是面向海量小文件应用，以往类似案例较少。因此，本次测试主要目标是进一步获取StorNext在这种应用场景下的性能表现，以验证能否真正满足客户的实际需求。本次测试具体目标如下：
l 文件对象数量能否达到20亿？以及在此场景下的系统性能表现。
l 海量小文件持续写入速率，即单位时间成功创建并完成写的文件数量。测试在不同已有文件对象总数量场景下的该指标。
l 海量小文件持续读写吞吐量和IOPS，测试在不同已有文件对象总数量场景下的该指标。
l 系统扩展能力，即客户端数量与性能指标的增长关系。
l 系统最大扩展能力，客户端数量能否达到100 ~ 1000台？
测试环境配置
本次测试环境部署总体架构如图1所示，主要由FC交换机、千兆以太网交换机、SAN磁盘阵列、StorNext MDC和StorNext客户端组成。基本配置情况如下：
l FC交换机：16口（4Gb）
l 千兆以太网交换机：16口（1Gb）
l SAN磁盘阵列：4台FC盘阵，每台16块磁盘，全做RAID0，其中一台供MDC专用
l StorNext MDC：16GB内存、Intel至强3.0GHz CPU、15K转SAS磁盘
l StorNext客户端：8GB内存、双Intel至强3.0GHz双核CPU、15K转SAS磁盘，共5台
性能指标
(1) 吞吐量
数据吞吐量(Throughput)，指单位时间内可以成功传输的数据数量，吞吐量以MB/S指标来衡量，体现存储系统在大量数据持续读写时的性能，特别是能衡量在非线性编辑、视频流媒体等需要大量读写环境下，存储持续读写的能力。对于大量顺序读写的应用，则更关注吞吐量指标。这里用来衡量大量小文件读写场景下的数据吞吐量。
(2) IOPS
IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量存储系统性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。随机读写频繁的应用，如OLTP(Online Transaction Processing)、海量小文件是典型代表，IOPS是关键衡量指标。
(3) 写入速率
写入速率，指单位时间（秒、分钟或小时）内成功创建并完成数据写操作的文件总数或者平均数量。客户每天平均约写入5000万小文件，写入速率要求达到每小时200万以上。
(4) 并发客户端数
并发客户端数，指系统能够同时支持的饱和读写能力的最大客户端数量。假设总写入速率为200万/小时，单位客户端写入速率为2万/小时，则系统至少需要支持100台并发客户端数。
(5) 其他指标
其他指标包括文件对象总数、系统负载（CPU占用率、MEM使用率、IOWAIT）。
测试工具
(1) DD
DD是Linux系统自带的一个简易测试工具，比较实用，可以作为一个测试工具对文件系统以及裸设备的吞吐量和带宽进行测试。DD只能提供一个大概的测试结果，而且是连续IO 而不是随机IO，理论上文件越大，测试结果越准确。DD通常用来大致测试文件系统的极限性能，包括IOPS和数据吞吐量。DD的bs参数可以用来设置读写记录大小，测试IOPS时可设置为1~4KB，测量数据吞吐量时可设置为4~16MB。实际测试中，建议文件大小是内存总量的两倍以上，或者采用DIRECT_IO模式，以获得更准确的测试结果。
(2) Bonnie++
Bonnie++是一款文件系统的基准性能自动化测试工具，包括测试文件系统的读写能力、查找能力、创建新文件的能力，它通过一系列的简单测试来生成文件系统的性能参数。其主程序提供两种风格的测试：针对单个文件的数据库风格的访问测试和针对大量小文件的创建和删除来模拟诸如Squid，INN,或者Maildir格式的Email这一类风格的访问测试。Bonnie++对三个方面做基准测试：数据读、写速度，每秒可以完成的文件元数据操作次数。Bonnie++ 12项结果分为5大类，分别是Sequential Output（写测试），Sequential Input（读测试），Random Seeks（读写测试），Sequential Create（顺序读写文件测试）和Random Create（随机读写文件测试）。
URL：http://www.coker.com.au/bonnie++/
(3) Postmark
Postmark是由著名的NAS提供商NetApp开发，用来测试其产品的后端存储性能。Postmark主要用于测试文件系统在邮件系统或电子商务系统中性能，这类应用的特点是：需要频繁、大量地存取小文件。Postmark的测试原理是创建一个测试文件池。文件的数量和最大、最小长度可以设定，数据总量是一定的。创建完成后，Postmark对文件池进行一系列的事务（transaction）操作，根据从实际应用中统计的结果，设定每一个事务包括一次创建或删除操作和一次读或添加操作，在有些情况下，文件系统的缓存策略可能对性能造成影响，Postmark可以通过对创建/删除以及读/添加操作的比例进行修改来抵消这种影响。事务操作进行完毕后，Post对文件池进行删除操作，并结束测试，输出结果。Postmark是用随机数来产生所操作文件的序号，从而使测试更加贴近于现实应用。输出结果中比较重要的输出数据包括测试总时间、每秒钟平均完成的事务数、在事务处理中平均每秒创建和删除的文件数，以及读和写的平均传输速度。
URL：http://www.gtlib.cc.gatech.edu/pub/debian/pool/main/p/postmark/
(4) Filebench
Filebench是一款文件系统性能的自动化测试工具，它通过快速模拟真实应用服务器的负载来测试文件系统的性能。它不仅可以仿真文件系统微操作（如copyfiles, createfiles, randomread, randomwrite），而且可以仿真复杂的应用程序（如varmail, fileserver, oltp, dss, webserver, webproxy）。Filebench比较适合用来测试文件服务器性能，但同时也是一款负载自动生成工具，也可用于文件系统的性能。
URL：http://www.solarisinternals.com/wiki/index.php/FileBench
测试方法
本次测试主要使用DD和Postmark两个工具进行性能测试，DD用于大致测试IOPS和数据吞吐量，Postmark用于测试海量小文件创建性能表现。测试过程中，使用TOP观测系统负载变化。
（1） DD测试方法
五个StorNext SAN客户端同行运行DD，命令行参数如下：
Dd if=/dev/zero of=/mnt/snfs/f100g bs=1KB count=100M（小写）
Dd if=/mnt/snfs/f100g of=/dev/null bs=1KB（小读）
Dd if=/dev/zero of=/mnt/snfs/f160g bs=16MB count=10K（大写）
Dd if=/mnt/snfs/f160g of=/dev/null bs=16MB （大读）
（2） Postmark测试方法
五个StorNext SAN客户端同时运行两个Postmark进程，总共10个进程。每轮测试创建1000万个2~6KB小文件，平均到每个进程为100万。Postmark对所创建的文件进行删除测试，为了让StorNext累积文件数，我对Postmark进行了修改，使其创建文件而不删除。10轮测试后，系统中文件数量可以达到1亿。然后再进行持续压力测试，每个进程创建2亿小文件，最后系统中文件总数可达到21亿个。Postmark参数配置说明如下：
set size 2048 6144 #文件大小设定为2 ~ 6KB
set number NR #文件数量，测试前指定
set location /mnt/snfs #StorNext mount点
set subdirectories 10000 #创建目录数设定为10000
set read 1024 #读记录大小设定为1024字节
set write 1024 #写记录大小设定为1024字节
run #执行测试
quit #完成退出并输出结果
LOSF性能调优
StorNext是一款完全针对SAN共享环境设计的并行文件系统，主要特点是高性能数据速率和大容量，它能充分发挥存储系统硬件的性能。它特别适用于高性能工作流和归档之类的大数据块连续访问的应用，在媒体、广电、石油、高性能计算、IPTV、制造业等行业中被广泛使用。
海量小文件（LOSF，Lots of Small Files）是非常特殊的一类应用，比如生命科学DNA序列、CDN边缘节点中的页面、淘宝网物品图片等，目前业界的文件系统以及分布式文件系统在LOSF应用上表现较差，尤其是文中所述的应用案例。
StorNext在大文件应用下，元数据压力非常小，MDC不会成为性能瓶颈。但对于LOSF应用而言，元数据压力非常大，MDC性能优劣直接决定系统性能，瓶颈几乎可以肯定在MDC。实际测试也验证了这一点，好在StorNext在MDC设计作了大量优化工作，广泛适用于不同的工作负载，并提供了大量可配置系统参数以方便系统管理员进行性能调优。参考StorNext官方性能调优指南，并结合实际测试验证，我们对StorNext进行了如下优化：
（1） MDC专用FC盘阵，并做成RAID0
（2） MDC BufferCacheSize设置为1GB，缺省为32MB
（3） MDC InodeCacheSize设置为512KB，缺省为32KB
（4） MDC ThreadPoolSize设置为64，缺省为32
（5） 文件系统块大小设置为最小的4KB，可选范围为4~512KB
（6） 客户端mount时CacheBufSize设置为256MB，缺省为64KB
以上优化措施从MDC后端存储、MDC和客户端缓存大小、文件系统块大小等方面着手，针对LOSF进行优化，实际测试验证性能提升明显。然而，在高并行负载压力下，MDC后端存储最终还是成为影响性能关键所在，IOWAIT值不断升高，可以采用SSD固态硬盘进一步消除IO性能瓶颈。大内存对MDC性能提升影响很大，我们测试中16GB内存几乎用完，加大内存还可以提升性能，但会增加数据丢失风险，需要对内存进行掉电保护。另外，StorNext调优指南中还有诸多其他优化措施，可进一步进行调优。
测试结果与分析
DD在性能调优前后测试结果基本没有变化，它与MDC交互非常少，主要是IOPS和数据吞吐量，OPS对其测试结果不会产生影响。DD测试结果如下：
（1）小文件吞吐量（bs = 1KB）：5个客户端同时运行，写214 MB/s，读117 MB/s；聚合写1070 MB/s，聚合读585 MB/s。
（2）大文件吞吐量（bs = 16MB）：5个客户端同时运行，写274 MB/s，读395 MB/s；聚合写1370 MB/s，读1975 MB/s。
Postmark小文件创建在性能调优前后变化显著，性能有大幅提升，这主要得利于MDC优化后OPS性能的提高。创建1000万2~6KB小文件，5＊2个postmark进程，前后测试结果对比如下：
（1）优化前：耗时约20小时，平均每小时创建50万个，每个客户每小时创建10万个；MDC CPU占用约30%，其中主要为IOWAIT（约24%），内存占用<2GB；客户端 CPU占用约1%，IOWAIT为0%，内存占用<1GB。
（2）优化后：耗时7800秒，约2.17小时，平均每小时创建460万个，每个客户每小时创建92万个；MDC CPU占用率约40%，IOWAIT约16%，MEM消耗约11GB；客户端CPU占用率约3%，IOWAIT为0，MEM消耗约1GB。
（3） 优化后，Postmark持续压力测试下，持续写入约4000万小文件后，性能下降50%以上；MDC IOWAIT上升到23%，MEM基本消耗完16GB；客户端 MEM也基本消耗完8GB内存。
从以上测试结果可以看出，针对LOSF应用，StorNext在非长持续压力下性能表现还是相当不错的，业界可能难逢竞争对手。然而，面对持续的LOSF负载压力，性能下降非常厉害，主要性能瓶颈还是在于MDC以及后端存储。不过，这个性能还是能够说得过去的，测试环境毕竟只配置了一个StorNext文件系统，如果同时配置2个以上文件系统，初步分析是可以满足文中所述的LOSF存储需求。后续考虑为MDC配置SSD固态硬盘，从而消除元数据服务器的I/O瓶颈，提升StorNext文件系统性能和稳定性。