分类： 服务器与存储
2012-05-28 13:14:28
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 ：
(3) Postmark
Postmark 是由著名的 NAS 提供商 NetApp 开发，用来测试其产品的后端存储性能。 Postmark 主要用于测试文件系统在邮件系统或电子商务系统中性能，这类应用的特点是：需要频繁、大量地存取小文件。 Postmark 的测试原理是创建一个测试文件池。文件的数量和最大、最小长度可以设定，数据总量是一定的。创建完成后， Postmark 对文件池进行一系列的事务（ transaction ）操作，根据从实际应用中统计的结果，设定每一个事务包括一次创建或删除操作和一次读或添加操作，在有些情况下，文件系统的缓存策略可能对性能造成影响， Postmark 可以通过对创建 / 删除以及读 / 添加操作的比例进行修改来抵消这种影响。事务操作进行完毕后， Post 对文件池进行删除操作，并结束测试，输出结果。 Postmark 是用随机数来产生所操作文件的序号，从而使测试更加贴近于现实应用。输出结果中比较重要的输出数据包括测试总时间、每秒钟平均完成的事务数、在事务处理中平均每秒创建和删除的文件数，以及读和写的平均传输速度。
URL ：
(4) Filebench
Filebench 是一款文件系统性能的自动化测试工具，它通过快速模拟真实应用服务器的负载来测试文件系统的性能。它不仅可以仿真文件系统微操作（如 copyfiles, createfiles, randomread, randomwrite ），而且可以仿真复杂的应用程序（如 varmail, fileserver, oltp, dss, webserver, webproxy ）。 Filebench比较适合用来测试文件服务器性能，但同时也是一款负载自动生成工具，也可用于文件系统的性能。
URL ：
测试 方法
本次测试主要使用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 文件系统性能和稳定性。
