-
BestPractice
From
DOIT WIKI
Jump to:
navigation
,
search
版权声明
：
《
EMC
存储最佳实践》
R22
的版权归美国
EMC
公司所有，
[
感谢
DOS
TOR
网友
/Arthas
的全力翻译
]
。
EMC
存
储最佳实践
R22
中文译稿可以转载，
转载时请
务必以超链接形式标明文章原始出处
DOSTOR
存储在线和作者与译者信息及本声
明。
目录
[
隐藏
]
?
1
一<
/p>
.
关于性能的探讨
o
1.1
1.
性能的定义
o
1.2
2.
应用的设计
?
1.2.1 A.
为顺序或者随机
I/O
的优化
?
1.2.2 B. I/O
的大小
?
1.2.3 C.
暂时的模式和峰值的表现（
temporal
patterns
and peak
activities
）
o
1.3
3
．主机文件系统影响
?
1.3.1 A.
文件系统的缓冲和组合（
coalesce
）
?
1.3.2
B.
最小化
I/O
的大小：文件系统的
request size
?
1.3.3 C.
最大化的
I/O
大小
?
1.3.4 D.
文件系统的
fragmentation
?
1.3.5
F.
校正对齐问题
?
1.3.6
的
I/O fragementing
o
1.4
4.
卷管理器
Volume
Managers
?
1.4.1 A
．
Plaid
应该做的
?
1.4.2 B. Plaid
不应该做的
?
1.4.3 C. Plaid
为高带宽的设置
?
1.4.4
D
．
Plaids and
OLTP
o
1.5 5.
主机
HBA
的影响
?
1.5.1 A. HBA
卡的限制
?
1.5.2 B.
Powerpath
o
1.6 6. MetaLUNs
?
1.6.1 A.
对比
metaLUN
和卷管理器
1
1.6.2 B.
MetaLUN
的使用说明和推荐
?
1.6.3 C.
MetaLUN
的扩充战略
o
1.7
7.
存储控制器的影响
?
1.7.1
A
．
CLARiiON
的存储控制器
?
1.7.2 B.
磁盘的级别和性能
o
1.8
引擎的缓存
?
1.8.1 A.
缓存的大小和速度
?
1.8.2 B.
缓存的设定
o
1.9
9.
后端设备（磁盘的子系统）
?
1.9.1 B.
LUN
的分布
?
1.9.2
C
．
系统和启动硬盘的影响
?
1.9.3
D
．
使用
L
UN
和
RAID
组的编号方式
?
1.9.4
E
．最小化硬盘的竞争
?
1.9.5 F
< br>．
Stripe
和
Stripe
element
的大小
?
1.9.6 G.
CLARiiON RAID 5
的
stripe
优化
?
1.9.7 H.
每一个
RAID<
/p>
组的硬盘的个数
?
1.9.8
I
．在一个存储系统里应该使用多少个硬盘
?
1.9.9 J.
硬盘的类型和大小
?
2
二．为可用性和冗余做考虑
o
2.1 1.
高可用性的配属
o
2.2 2. RAID-
level
的考虑
?
2.2.1 A. RAID
5
?
2.2.2 B. RAID 1/0
?
2.2.3 C. RAID
3
?
2.2.4 D.
热备份（
Hot
spares
）
o
2.3 3.
< br>把
RAID
组通过总线和
DAE
绑定
?
2.3.1 A.
跨
DAE
来绑定硬盘
?
2.3.2 B.
跨后端总线绑定硬盘
?
2.3.3 C.
通过
DPE
磁盘绑定
?
2.3.4 D.
热备份的策略
o
2.4 4.
数据复制的持续性
?
[
编辑
]
2
一
.
关于
性能的探讨
性能调优有多重要呢？在一个
Raid 5
的阵列组中使用
5-9
块硬盘和使用默认的
设置，
CLARiiON
光纤储系统能发挥极好的性能
----
这是
EMC
< br>在性能测试实验室
里测试自己的
CLARiiON
系统得出来的。
CLARiiON
存储系统默认的设置是为实际环境中遇到的大部分工作情形所设计
的。
但是，有一些工作情景还是需要调优来实现存储系统的最佳配置。
< br>为什么在阵列组里用
5
到
9
块硬盘？这个设置并没有任何神奇的地方，
也不是因
为这个配置有什么特殊的优化。然而，
Raid 5
使
用这个数量的硬盘确实是最有
效的利用了校验，
同时也能在合理
的时间能重建数据。
更小的阵列组会有更高的
校验开销，而大的
阵列组则会花更长的时间来重建数据。
这份白皮书探讨了在
设计优化系统方面的时设计到的许多要素。
请注意这里提供
的信
息是非常有帮助的，尤其当你充分理解了你的阵列的工作情形。因此，
EMC
推荐你使用
Navisphere
Analyz
er
来分析你的阵列的工作情形，
并且要定期的复
习和回顾相关文档的基础知识。
同时，
请记住在配置
一个阵列的时候很少有显而
易见的选择，所以在有疑问的时候最好是按照默认的配置和保
守的评估。
[
编辑
]
1.
性能的定义
以下的名词在整个白皮书当中都会用到。
如果你对他们不熟悉，
请回顾一下
EMC
CLARiiON Fibre
Channel Storage Fundamentals
?
?
?
?
?
?
?
?
?
?
?
带宽
校验
读取
随机
响应时间
要求数据大小
Request size
顺序
条带
条带元素
Stripe element
吞吐量
Write-aside
[
编辑
]
2.
应用的设计
3
应用的设计对系统的表现影响很大。
提升性能的最佳方法的第一步就是应用的优
化。任何存储系统的调优都不可能建立一个
非常差的应用设计上面。
[
编辑
]
A.
为顺序或者随机
I/O
的优化
非常典型的一个例子是，
提升带宽在顺序访问的调优方面会起显著作用，
因为存
储系统在顺序
I/O
方面会更加有效率
--
尤其是在
RAID5
的时候。<
/p>
而为随机访问的
调优则要改善吞吐量和更快的响应时间，
因为这样会改善处理顾客响应所花的时
间。
读和写的对比写比读更加耗费存储系统的资源，这是基于
CLA
RiiON
对数据保护
的机制的应用。写到
write
cache
是镜像到两个存储控制器的（
SP
）。写到带校
验的
Raid Group
会碰到校验运算的要求，而这也要求把冗余的信息写到磁盘里
面。写到镜像的
Raid
Group
会需要两份数据的拷贝的写入。
读的开销相对会小一些，这是因为，从
CLARiiON
系统的读的吞吐量会比写的吞
吐量要大一些。但是，对大部分工作情形来看，数据往往
是写入
write cache
，
这样
会有更短的响应时间。读，在另一方面来说，可能命中
cache
，也可能不命
中
cache
；而对大
部分随机的工作情形来说，读比写会有更高的相应时间，因为
数据还是需要从磁盘里面抓
取。
如果要达到高的随机读取吞吐量，
需要更好的协
作（
concurrency
）。
[
编辑
]
B. I/O
的大小
每一个的
I/O
都有一个固定的开销和一个变量的开
销，
后者决定于其他的一些事
情，例如
I/O
的大小。
大的
I/O
能提供更少的固定开销因为有着更大的数据。因而，对
CLARiiON
而言
大的
I
/O
比小块的
I/O
能提供更大的带宽
。如果有足够的硬盘，在执行大的
I/O
的时候后段总线的速度
将会成为系统的性能瓶颈。小块的随机访问应用（例如
OLTP
）的瓶颈在于磁盘（的个数），而且很少达到后端总线速率。
当设计
OLTP
的时候，必须要使用基于磁盘（的个数）的<
/p>
IOP
来衡量，而不是使
用基于总线的带
宽来衡量。
然而，在一个
CLAR
iiON
存储系统里面，当
I/O
到了
某一个特定的大小的时候，
包括
write caching<
/p>
和
prfetching
都会被
bypass
掉。是决定用一个大的
I/O
请求还是把他分成几个顺序的请求，
取决于应用程序和它跟
cache
之间的相互作
用。这些相互作用在<
/p>
“
The Raid engine
Cache
”里会探讨到。
4 <
/p>
文件系统也可以影响到
I/O
的大小，这
也在稍后的“
Host
file-system
impact
”
中描述到。
[
编辑
]
C.
暂时的模式和峰值的表现（
temporal
patterns and peak
activities
）
应用的操作
设计
--
如何去使用，
什么时候去使用
，
什么时候需要去备份
--
都会影
响到存储系统的负载。
例如，
用作随机访问
的应用的存储系统，
在备份和批量处
理的时候，需要好的顺序性
能。
一般来说，对
OLTP
和消息应用（任何跟大量随机访问
I/O
有关
的），更高的并
发处理能力（
concurrency
）会更好。当有更高的并发处理能力的时候，存储系
统将会获得更高的吞
吐量。
使用异步
I/O
是一种获得更高
的并发处理能力的通常
的手法。
对带宽而言，
< br>单线程的应用几乎不能有效地利用四块硬盘以上带来的好
处，除非
request size
是非常大的（比
2MB
大）或者使用到
volume manager.
< br>当最佳的顺序性能达到的时候，而此时如果顺序处理到磁盘的路径是唯一的时
候，
用户还是可以从有适度并发随机访问的光纤硬盘（每个硬盘的
I/O
在
100
以下）的设置中获得一个可接受顺序性能。
[
编辑
]
3
．主机文件系统影响
在主机层次，通过指定最小最大的
I/O request s
ize
，文件系统也影响了应用
I/O
的特性。
[
编辑
]
A
.
文件系统的缓冲和组合（
coalesce
< br>）
跟在存储系统上的
cach
e
相似的是，缓冲是文件系统提高性能的一种主要方式。
缓冲
在大部分的情况下，
文件系统的缓冲应该最大化，
因为这能减少存储系统的负载。
然而，还是会有一些意外。
一般来说，
应用自己来调配缓冲，
能避免文件系统的缓冲或者在文件系统的缓冲<
/p>
之外工作。
这是基于应用能更加有效的分配缓冲的假设之上。
而且，
通过避免文
件系统的
coalesce
，应用更能控制
I/O
的响应时间。但是，正如在
64
位的服务
器里
RAM
的容量将会提升到
32GB
或者更多，这也就有可能把这个文件系统都放
在缓
冲里面。这就能使读操作在缓冲下，性能会有非常显著的提升。
（写操作应
该使用写透（
write-
through
）的方式来达到数据的持续性。）
5
结合
Coalescing
文件系统的
coalesce
能帮助我们从存
储系统里获得更高的带宽。在大部分顺序
访问的操作里面，
用最
大邻近和最大物理的文件系统设置来最大化文件系统的结
合
Co
alescing.
例如，这种处理方式可以和备份程序一起把
64KB
的写操作结合
（
coales
ce
）成一个完全
stripe
的写操
作，这样在
write cache
被
bypass
的
情况下，对于带校验的
Raid
会更加有效果。
[
编辑
]
B
.
最小化
I/O
的大小：文件系统的<
/p>
request size
文件系统通常都被配置成一个最小的
范围大小，例如
4KB
，
8KB
或者
64KB
，这是
提供给阵列的最小的不可分割的请求。
应用使用的
I/O
在比这个范围大小要小的
时候，会导致很多不必要的数据迁移和
/
或
read-modify-write<
/p>
的情形出现。这
也是考虑应用和文件系统文件的最佳设置的最好办
法。（
it
is
best
to
consult
application and file system
documentation for the optimal
settings
）而
request
size
没有被文件系统限制的
Raw
partitions
，则没有受到这个约束。
[
编辑
]
C
.
最大化的
I/O
大小
如果想要快速的移动大量的数据，
那么一个大的
I/O
（
64KB
或更大）
会更加有帮
助。在整合（
co
alescing
）顺序的写操作成
Raid Group
整个的
stripe
的时候，
阵列将会更加有效率，
正如预读取大的顺序读操作一样。
大的
I/O
对从基于主机
的
stipe
获得更好的带宽而言也是很重要的，因为他们将会被基于<
/p>
srtipe
的
toplogy
打散成更小的大小。
[
编辑
]
D
.
文件系统的
fragmentation
< br>避免
fragmentation
和
defragementation
在一起，这是一个基础的原则。注意
NTFS
文件系统可能被分区成任何形式除了默认的范围大小，他们不能被
大部分
的工具所
defragement
：这个
API
（程序的接口）并不能允许这样做。执行一个<
/p>
文件级别的拷贝
（到另一个
LUN
或者执行一个文件系统的备份和恢复）是
d
efragement
的一个有效的实现。
6
跨越磁盘的小
< br>I/O
在一些主机的类型里显得更加重要，
而我们接下来
将会探讨为
什么会导致这种状况。
当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响：
a)
有大比例的
block size
大于
16KB
的随机
< br>I/O
b)Navisphere Analyzer
报告的硬盘的平均等候队列长度比
4
大的时候对齐
4KB
或者
8KB
边界的
时候（例如
Exchange
和
Ora
cle
），工作负载将会从对齐中获得
一些优势。但因为
I/O
当中，小于
6%
（对于
4KB
）或者
12%
（对于
8KB
）的
I/
O
都会造成跨盘操作
（碰巧的是他们可能会以并行的方式来完成
）
。
这种额外的收
益可能很难在实践中
注意到。但如果当一个特定的文件系统和
/
或应用鼓励使用
对齐的地址空间并且位移（
offset
）
被注明，
EMC
推荐使用操作系统的磁盘管理
< br>来调整分区。
Navisphere LUN
的绑定位移
（
offset
）工具应该要小心的使用，
因为它可能反而会影响分层的应用同步速度。
在
Intel
架构系统中的文件对齐
Intel
架构的系统，包括
windows
2000/windows2003
，都会受到在
LUN
上元数据
的位置的影响，这也会导致磁盘分区的不对齐。这是因为遗留
的
BIOS
的代码问
题，
BIOS
里面用的是磁柱，磁头和扇区地址来取代
L
BA
地址。（这个问题一样
影响了使用
intel
架构的
linux
操作系统
，正如
windowsNT
，
2000
，和
2003
。这
个问题也一样影响了运行在
intel
硬件上的
VMWare
系统）
fdisk
命令，正如
window
s
的
Disk
Manager
，把
MBR
（
Mas
ter
Boot
Record
）放
在每一个
SCDI
设备上。
MBA
将会占用设备上的
63
个扇区。其余可访问的地址是
紧接着这
63
个隐藏分区。这将会后续的数据结构跟
CLARiiONRAID
的
stripe
变
得不对齐
。
在
linux
< br>系统上，
这个隐藏扇区的多少取决于
boot
loader
和
/
或磁
盘管理软件，
但
63
个扇区是一个最常
遇到的情况。对于
VMware
，位移（
offset
）是
63
。
在任何情况下，
这个结果都为确定的比例的<
/p>
I/O
而导致不对齐。
大的
I/O
是最受
影响的。例如，假设使用
CLARiiON
默认的
stripe
element
64KB
，所有的
64KB
7
的
I/O
都会导致跨盘操作。对于那些比这个
stripe element
的小的
I/O
，会导
致跨盘操作的
I/O
的比例，我们可以通过以下公式来计算：
Percentage of data crossing=(I/O
size)/(stripe element size)
这个结果会给你一个大
致的概念，
在不对齐的时候的开销状况。
当
cache
慢慢被
填充的时候，这种开销会变得更大。
aa
[
编辑
]
F.
校正对齐问题
< br>你可以选择以下的方法之一来修正对齐的问题。记住，必须只是两种方法之一：
here LUN
的对齐位移（
off
set
）
b.
使用分区工具
对任何特定的<
/p>
LUN
，只要使用其中一种，不是两个。这个是我们经常要强调的
。
同时，当设定一个
metaLU
N
，只有那个
base component
< br>需要分条的对齐（就是
那个被其他
LUN
挂靠上去的
LUN
）
。
如果使用
LUN
的对齐位移，
当
metaLUN
建立
的时
候，
metaLUN
的对齐位移也被设置了。当扩展一个
metaLUN
，不需要再调整
了。
如果用了分区工具的方法，
这个调整只需要在用户第一次对
LUN
分区的时候
来做。
用什么方式来做
当没有基于主机的
程序在使用的时候，我们可以使用
LUN
对齐位移的方式。
LUN
对齐位移方法对一些复制的软件操作，如
clone sync I/O
，
SnapView
Copy On
Write
opertions
，
MirrowView
sync
I/O,
SAN
Copy
I/O
等，造成磁盘和
strip
跨盘的问题。
如果可以，使用基于主机的分区工具方式。
避免使用
LUN
对齐位移方法，假如你在这个
LUN
上使用了
SnapView
，
SAN
copy,
MirrorView
。相反，
应该使用基于主机的分区工具方式。
LUN
的位移
LUN
的位移方法使用把
LUN
偏
移，
来达到对齐
stripe
分界的分
区。
LUN
从第一个
RAID
的
stripe
的末端开始。换一句话说，将<
/p>
LUN
的位移设置成
RAID
stripe
的
大小，会让（紧接着
MBR
开始的）文件系统对齐了，如下图
2
所示。
8
LU
N
对齐位移的不足之处是它可能会造成任何要对
Raw LUN
进行操作的软件的
I/O
请求的不对齐
。
CLARiiON
的复制会对
raw LUN
操作，如果
LUN
被位移了，
这也会产生跨磁盘的
操作。
Navisphere
中，
当
LUN
被
b
ound
的时候和
block
大小被设
置成
512byte
的时候，
位移会被
设置成特定的。例如，在一个
windows2003
系统，将
会把
63
个
block
设置为位移量。
FLARE
会调整
< br>stripe
，因此用户的数据就会从
stripe
的开头来
开始。
图
2
：
Intel MBR with partition and LUN offset correction
磁盘分区的对齐
基于主机的分区程
序使用增加可设定地址的区域的起始部分，来校正对齐的问
题；因此，可设定地址的空间
在
RAID strip element
的起始部分开始算起
，或
者在整个
strip
的起始部分。
因为
LUN
从正常的地方算起，在
RA
ID
strip
的起
始部分，复制
软件操作也是对齐的。事实上，对于镜像操作，当
secondary
< br>被写
入的时候，
primary
的对齐是被保护了的，因为增加了的分区目录被写入了源
LUN
。
磁盘分区对齐和
windows
的系统
在
Windows
NT
，
2000
，
2003
系统中，
分区软件
，
作为
WRK
（
Windows
Resource
Kit
）的一部分，可以用来设定分区位移的开始。你必须要在数据写入
LUN
之前做这件事，
因为
diskpar
会重新写分区表：
所有在
LUN
上出现的数据都
会丢失掉。
9
对于随机访问操作或者是
meta
LUN
，在
diskpart
中设定起
始位移的大小，跟对
被用来
Bind
LUN
的
stripe element size
的大小一致（一般
128blocks
）。对
于高带宽要求的应用，设定起始位移的大小跟
LUN stripe
size
的大小一致。
开始，用
Disk Manager
来
获得磁盘的数目。在命令行中，使用
diskpar
加上
-i
的选项：
diskpar -i x (
新的大小是磁盘个数
)
来检查已经存在
的位移：
C:>diskpar -i 0
Drive 0 Geometry
Information ----
Drive Partition 0 Information ----
StatringOffset = 32256 PartitionLength
= 4 HiddenSectors =
63
。。。
注意
HiddenSectors
的值。这就是分区的位移的数值
1.
假如磁盘
X
有数据你不想丢失，
那么备份那个数据
2.
假如磁盘
X
是一个
Raw
Drive
，
跳到第四部。
3.
删掉在磁盘
X
上
所有的分区，
使之成为一个
Raw
Disk
。
4.
在命令行中使用
diskpar
-s X (X
是磁盘个数
) 5.
输入新的起始位移
(
单位
sector
s)
和分区长度
(
单位
MB)
。这一步骤写入为那个磁盘写入新的
MBR
和创建新的分区。在你输入起始位移和分区大小，
MBR
就被修改了，而新的分
区信息出现了。<
/p>
6.
在
command
prompt
输入
diskpar -i x (x
为磁盘个数
)
来复查新近创立的分
区上的信息。
64
位
windows
系统
在
64
位的
windows
系统里面，
如果按照默认创建，
MBR
类型
的磁盘是对齐的；
GPT
分区也是按默认对齐，尽管他们有一个小的保留区域
（
32MB
）是没有对齐的。
在
linux
系统中的磁盘分区调整
在
linux
中，在数据写入
LUN
之前对齐分区表
(table)
，
因为分区影射
(map)
会
被重写，
所有在
LUN
上的数据都会毁
坏。
在接下
来的例子里，
LUN
被影射到
/dev/emcpowerah
，
而且
LUN
stripe
element
size
是
128block
。
fdisk
软件工具的使用方式如下所示：
fdisk
/dev/emcpowerah x # expert mode b # adjust
starting block number
1 # choose
partition 1 128 # set it to 128, our stripe
element size w #
write the new
partition
10
对于那些会使用
snapshot
，
clone
，
MirrowView
的镜像构成的
LUN
来说，
这个方
法比
LUN
对齐位移方法更加适用。这对
SAN <
/p>
Copy
中的
sources
和
targets
是一
样
适用的
对于
VMWare
的磁盘分区调整
VMware
会更加复杂，因为会有两种情况存在。
当对齐
raw
disk
或者
Raw Device Mapping(RDM
)
卷，实在虚拟主机
(VM)
层次上<
/p>
来实现对齐的。例如，在
windows
的虚拟主机上使用
diskpar
来实现对齐。
对于
VMFS
卷，会在
ESX
Server
的层次上使用<
/p>
fdisk
来实现对齐，正如
diskp
ar
在
VM
层次。这是因为不管是
ESX Server
还是客户端都会把
MBR
放到
LUN
上面
去。
ESX
必须对齐
VMFS
卷，而客户系统必需对其他们的虚拟磁盘。
对齐
ESX
Server
：
On service console,
execute
sd
to
create
a
new
partition
Type
to
create
a
primary
partition
Type
to create partition #1
Select the defaults
to use
the
complete disk Type
partitions Type
#1 to align on 64KB boundary Type
change partition type Type
to write label and the partition
information to disk
通过把分区类型声明为
< br>fb
，
ESX Server
会
将这个分区认为一个没有被格式化的
VMFS
卷。你应该能够使
用
MUI
或者
vmkfstools<
/p>
，把一个
VMFS
文件系统放上去。
对于
Linux
的虚拟主机，
按照上面列出的程序步骤来做。
对于
windows
的虚拟主
机，也是按照上面的程序步骤来做。
< br>
[
编辑
]
的
I/O fragementing
对于
linux
来说，
避免对一个
LUN
上的多个大文件的并发访问是很重要
的。
否则，
这回造成来自不同的线程的许多个访问，
使用不同的虚假设备来访问同一个潜在
的设备。这种冲突减少了写操作的<
/p>
coalescing
。最好还是使用很多个小的
LUN
，
每一个有一个单一的大的文件。
动态
LUN
的融合和偏
移
如果你使用一个基于主机的分区工具来对齐数据，
在你融合几个
LUN
的时候，
这
个对齐也会被保留。这是假设所有
LUN
的
LUN stripe
size
是一致的。假如
Navisphere
Bind
Offset
被融合的源<
/p>
LUN
所使用，那么目标
LUN
，在
bound
用来
调
整
stripe
对齐的时候，必须要使用
Bind Offset
。
[
编辑
]
11
4.
卷管理器
Volume
Managers
对卷管理器的主要性能影响因素，是
CLARiiON
LUN
使用了
stripe
< br>的方式（我们
所说的
plaid
或者
stripe on
stripe
）。
我们要避免使用
基于主机
RAID
而且使用校验（如
R
aid3
，
Raid5
）的应用。这会
消耗掉主机的资源来实现这一服务
（校验保护）
，
而这其实让存储系统来实现这
个服务会更加好。
图三显示了在以下章节中讨论到的三种不同
plaid
技术
对于所有的情形，都会遵从以下规则：
[
编辑
]
A
．
Plaid
应该做的
把主机管理器的
stripe
深度（
stripe
element
）设成
CLARiiON
LUN
的
stripe
size
。你可以使用整数倍的，但最好还是把
stripe elemen
t
设定在
512KB
或者
1MB
。
简而言之，从基本的
CLARiiON LUN
上来考虑建立逐级管理器的
stripe
。
从分开的磁盘组来使用
LUN
；这个组应该有相同的参数（
stripe
size
，
disk
count
，
RAID
type
，等等）。
[
编辑
]
B. Plaid
不应该做的
千万不要在同一个
RAID
group
里把多个
LUN stripe
（译者注：
stripe
和
con
catenate
都是
meteLUN
的一种方式，下文中的英文部分的
stripe
都是特指
12
这个）
在一起。
这是因为会造成大量的磁盘寻道。
如果你从一个磁盘组需要捆绑
多个
LUN
，使用
concaten
ate
来实现
-
千万不要使用
striping
的方式。
不要使主机的
stripe element
< br>比
CLARiiON
的
RAID
stripe size
小。
不要对那些具有不同
RAID
type
和
stripe
size
的
RAID Group
，或
者根本不同
磁盘组的
LUN
，使用
plaid
的方式在一起。结果并不一定是灾难性的，但很可能
会出现未知的因素。
[
编辑
]
C. Plaid
为高带宽的设置
plaid
在以下几个原因使用在高带宽的应用里面：
plaid
可以增加存储系统的协
作（并行访
问）。
plaid
允许多于一个的主机
HBA
卡和
CLARiiON
的存储
运算器
（
SP
）共同为一个
volume
所用。非常大的卷可以被分布到多于一个的
< br>CLARiiON
系统之上。
增加协作
Plaid
在应用是单线程（也就是说，读一个单一的大文件）的时候会比较有用。
如果
应用的
I/O
的大小正好跟卷管理器的条带大小一致，
那么卷管理器可以访问
那些可以包装成卷的并发的
LUN
。
从多个存储器分布式访问
跨越存储
系统，
正如在图三的配置
B
里面所演示
那样，
仅仅当文件系统的大小和
带宽要求需要这样的一个设计的
时候，才被建议使用。例如，一个
30TB
的地质
信息系统数据库，
要求的写的带宽超过了一个
arr
ay
所能达到的极限，
将会是一
个多系
统
plaid
的候选者。
必须注意的是
，
一个软件的更新或者任何存储系统的
出错—
< br>-
例如因为一个存储系统上的一个组件的出错而导致的写缓存的停用—
-
将会影响到整个文件系统。
[
编辑
]
D
．
Plaids and
OLTP
OLTP
应用是难以去分析，也难以去忍受一些热点
。
Plaids
是一种有效的策略来
使
I/O
从多个轴来分布式访问。
一个可
以让很多个磁盘处于忙碌状态的应用，
将
会从多个硬盘数中得益
。
注意一些卷的管理建议小的主机
stripe
（
16KB
到
64KB
）
。
这对使用一
种
stripe
的
Raid
type
的
CLARiiON
< br>来说并不正确。
对于
OLTP
，
卷管理器的
stripe
eleme
nt
应该跟
CLARiiON
的
stripe
size
（典型来说是
128KB
到
512KB
）
。
Plaid
对于
OLTP
主要的开销，在于大部分的用户以跨
pla
id
的方式结束。
13
跨
plaid
磁盘—
-
连同磁盘组—
-
会变得更大；
因此，
用户也常常会因为好几个主
机卷被同
一个
CLARiiON
的
Raid
groups
所创立（一个跨<
/p>
plaid
—看图三中的配置
C
）而结
束。
这个设
计的基本原理是在于以下的情况：对于任何一个卷组的随机行为的爆发，
将会分布到多个
磁盘上去。
这个的不足之处在于测定卷之间的相互作用，
是相当
困难的。
但是，一个跨
plaid
也有可能是有效率的，当以下情况存在的时候
< br>:
.
I/O
sizes<
/p>
比较小（
8KB
或更小）和随机的访问<
/p>
.
卷是受制于一天中不同时间的爆发，而
不是同一时刻。
[
编辑
]
5.
主机
HBA
的影响
用来实现主机附加的拓扑，
取决于系统的目标。
高可用性要求双
HBA
< br>卡和到存储
器的双路径。
双路径对性能的影响，
主要看管理者如何去从系统资源里得到负载
均衡的能力。
在对存储系统调优的时候，必须牢记
HBA
卡和驱动的作用。
EMC
的
< br>E-Lab
提供了
设置磁盘和固件的建议，而我们必须要
按这些建议来操作。
[
编辑
]
A. HBA
卡的限制
HBA
卡的固件，
HBA
卡
使用的驱动的版本，和主机的操作系统，都可以影响到在
存储阵列中的最大量的
I/O size
和并发访问的程度。
[
编辑
]
B. Powerpath
如果操作系统可以使用，
Powerpath
这个软件应该总是要使用的—
-
不管是对于
一个单一连接到一个交换机的系统
（允许主机继续访问，
当软件升级的时候）
还
是在一个完全冗余的系统。
除了基本的<
/p>
failover
之外，
Powerpa
th
还允许主机通过多个存储处理器（
SP
）
的端口来连接到一个
LUN
上面
—
--
一种我们通常称之为多路径的技术。
Powerpath
通过负载均衡算，来优化多路径访问
L
UN
。
Powerpath
提供了几种
负
14
载均衡的算法，默认的那种
-
---ClarOpt----
是我们所推荐的。
ClarOp
t
可以调
整传输
byte
的数量，正如队列的深度一样。
连接到所有目前
的
CLARiiON
的型号的主机，都可以从多路径中获益。直
接连接
的多路径需要至少两张
HBA
卡
；
实际的
SAN
多路径需要两张
HBA
卡，
其中的每一
个都会被分配到多于一个
SP
端口的区域。多路径的好处在于
：
在同一个
SP
< br>中，可以从一个端口
failover
到另一个端口，修
复一个事件的系统工作。
?
在
SP
的端口和主机
HBA
卡中的负载均衡
?
从主机到存储系统中获得更高的带
宽（假设
主机里，路径能使用足够多的
HBA
< br>卡）
?
< br>当
Powerpath
提供了所有可行路径的负载均衡，
这会带来一些附加的开销：
一些主机的
CPU
资源会被一般的操作所使用，
正如会被
failover
的时候使用。
?
在一些情形下，活跃的路径会增加
一些时间
来
failover
。（
Powerpath
在尝试几条路径
之后，
才会
trespass
一个
LUN
从一个
SP
到
另一
个
SP
）
?
因为这些事实，活跃的路径应该受
到限制，通过
zoning
，到两个存储系统的端
口对应一个
HBA
卡来影射到一个被主机绑定的存储
系统。
一个例外是，
在从其它
共享存储
系统端口的主机所爆发的环境，是不可预知和严峻的。在这个情形下，
四个存储系统的端
口都有一个各自的
HBA
卡，这是可以实现的。
[
编辑
]
6. MetaLUNs
MetaLUN
是一个所有
CLARiiON
系列存储系统都特有的功能。
我们从好几个方面
来讨论什么时候和怎么用
metaLUN
。
[
编辑
]
A.
对比
metaLUN
和卷管理器
在一个
CL
ARiiON
存储系统，
metaLUN
被当作一个在
RAID
引擎之上的层，在功能
上来说相似于主机上的一个卷管理器。
但是，
在
metaLUN
和卷管理器之间还是有
很多重
要的明显的区别。
单一的
SCSI
目标
对比
很多的
SCSI
目标
< br>
15
要创建一个卷管理器的
stripe
，
所有构成的
LUN<
/p>
必须设定成可以访问到主机的。
MetaLUN
< br>要求只有一个单一的
SCSI LUN
被影射到主机；这
个主机并不能看到组
成这个
metaLUN
的多个
LUN
。这会让管理员在以下几个情形下得益：
对于因为
OS
限制而有受限制的
LUN
可用的主
机<
/p>
?
对于那
些增加
LUN
导致
SCSI
设备重编号的主
机；经常一个内核需要重建，用来清除设备
的条目。
?
在这些情形下，使用
metaLUN
而不是卷管理
器会简化在主机上的管理。
没有卷管理器
不是所有的操作系统
都有卷管理器的支持。
MS
的
Serv
er Win2000/2003
集群使
用
Microsoft
Cluster
Services
（
MSCS
）并不能使用动态磁盘。
Me
taLUN
是一个
可以为这些系统提供可扩展的，
stripe
和
concatenated
（连接的）卷的解决方
案
。
卷的复制
如果卷是要被使用
SnapView
，
MirrorView<
/p>
或者
SAN
Copy
< br>的存储系统所复制的话，
一个可用的镜像会要求持续的处理分离的能力。采用
metaLUN
会简化复制。
卷访问共享的介质
当一个使用了<
/p>
stripe
或者
concatenat
e
的卷必须要允许在主机间共享访问，一
个卷管理器不能许可共
享访问，而
metaLUN
可以使用并实现这个功能。
MetaLUN
可以在两个的主机存储组之间应用。
存储处理器（
SP
）的带宽<
/p>
卷管理器的卷和
metaLUN
之间的一个重要的显著区别是，
metaLUN
是可以被一个
CLARiiON
存储系统上的一个存储处理
器完全的访问。如果一个单一的卷需要非
常高的带宽，
一个卷管
理器仍然是最好的方式，
因为卷可以从不同的
SP
上的
LUN
上来建立。一个卷管理器允许用户访问存
储器，通过很多个
SP
的集合起来的带
宽。
卷管理器和并发访问
正如在“
Plaids
：
< br>
为高带宽设置”章节里指出的那样，基于主机的
str
ipe
的卷
的使用，对于有多线程的大的
request
（那些有多于一个卷
stripe segm
ent
组
成的
request
），会有比较高的效果。这会增加存储器的并发访问能力。使用
meta
LUN
不会带来多线程上好的效果，因为
component
LUN
上的多路复用是由存
储系统来实
现的。
16
[
编辑
]
B.
MetaLUN
的使用说明和推荐
M
etaLUN
包含了以下三种类型：条带的
(stripe)<
/p>
，结和的
(concatenate)
，
和混
合的
(hybrid)
。
这个章节会做出几个通常的推荐。
对那些想要更多细节的人来说，
接下来的章节中将会定位建立
metaLUN
和相关每种类型的优点的策略和方法。
什么时候使用
metaLUN
通过前面的卷管理器的讨论，应该在以下情形下使用
metaLUN
：
当大量的存储整合变得有必要的
时候（每一
个卷都需要非常多的很多磁盘）
?
当要求
L
UN
的扩展的时候
?
当你建立一个
metaLUN
的时候，
你可以控制以下的要素：
component
LUN
的类型，
metaLUN
的类型，和
stirpe
multiplier
（增加的）。
Component LUN
的类型
用来绑定在一个
metaLUN
上的<
/p>
LUN
的类型应该能反映
metaLUN
上要求的
I/O
的形
< br>式。例如，使用在这份白皮书里面建议的各种不同的
Raid
< br>的类型（“
Raid
的类
型和性
能”提供了更多的信息），来匹配
I/O
的形式。
当绑定
component
LUN
的时候，使用以下规则：
?
?
?
?
?
?
当为
metaLUN
绑定
< br>LUN
的时候，总是使用默
认的
stripe element size(128 block)
总是激活读缓存和写缓存
确保为
component
LUN
设置的
write-aside
的大小为
2048
。（
write-a
side
在“
RAID
引
擎缓存”里面会被提到）
避免在
RAID 5
的磁盘组里使用少
于
4
块的硬
盘（或者说，至少是要
3+1
模式）
使用
RAID
1/0
磁盘组的时候，至少使用
4
块
硬盘（新的
1+1
并不是对
meta
LUN
的一个好
的选择）
不要使用
component LUN
位移来校正
stripe
的对齐。
Me
taLUN
有他们自己的位移值。
MetaLUN
的类型
17
一般来说，尽可能的使用
str
ipe
方式的
metaLUN
，因为他
们能体现出我们能预
知的更好的性能。
Concatenat<
/p>
一个单独的
LUN
给一个
metaLUN
，
会更加方便；
这
可能在扩展一个对性能并不敏感的卷会更加合适。
Hybrid metaLUN
使用
s
tripe
的方式捆绑
concatenate
的
LUN
。这个方式被用来
克
服
stipe
扩展的成本（这样会比较低）。一个采用
stripe
方式的
metaLUN
可
以通过
concatenate
另一个
stripe
component
的方式来扩展。
这样保持了
stripe
component
可预计的性能，也允许用户用来扩展一个
stripe
的
metaLUN
而不用
队已经出线的数据的重组
（性能将会受到影响，
当重新条带化操作进行的时候）
。
图四
展示了这一点。
图四
hybrid-striped metaLUN <
/p>
在理想的情况下，
在扩展
stripe<
/p>
设置的
LUN
将会分布在同样
RAID
类型的不同的
RAID
< br>组里面，也会表现得更原始的
stripe
compo
nent
一致。大部分最直接的方
式是使用同一个
RAID
组作为基础的
component
。这个
RAID
组是被最先扩展的，
以便使空间变的可用。这个方式在“
metaLUN
扩展方法”里会演示。
RAID<
/p>
组的扩展是更加有效率的，对比
metaLUN restrip
e
（把这个重分条过程设
置成中等优先级别），也会对主机性能
有更小的影响。
MetaLUN stripe
multiplier stripe multiplier
决定了
< br>metaLUN
的
stripe
element size:
Stripe
multiplier * base LUN stripe size = metaLUN stripe
segment size
MetaLUN stripe segment
size
是任何
component LUN
< br>能收到的最大的
I/O
。
所有的高带宽性能和随机分布都要求
metaLUN
stripe element
的大小为
1MB
左
右。
而且，
在下面的
RAID
组还可能被扩充。
我们需要确保<
/p>
metaLUN
stripe
ele
ment
是足够大，
大到跟写的完全的
stripe
一样，
用来扩展
comp
onent
LUN
（图表
1
）
。
使用以下规则来设置
stripe
multiplier
：
?
除非使用
RAID 0
，使用最少四个
磁盘的磁盘
组，来组成作为
component LUN
主机的
RAID
组。
18
为磁盘组的大小来测定选择有效的磁盘个
数。
例如，
六个磁盘的
RAI
D
1/0
是
3
（
3+3
）
。
五个磁盘的
RAID5
是
4
（
4+1
）
?
通过图表
1
，为有效磁盘的个数而选择
multiplier
?
如果有
疑问，使用
4
作为
metaLUN
的
stripe multiplier
。
对大部分情形来说，
这是一个默认的，也是一个好的选择。
MetaLUN
对齐的位移
如果你计划通过
metaLUN
来使用
SnapView
或者
MirrorView
，
把
metaLUN
< br>对齐位
移值设为
0
。使用磁盘分
区工具来调整分区的位移。
MetaLUN
和
ATA
磁盘
在这个时候，
ATA
并不适合繁忙的随机
I/O
访问的方案。
这个章节集中在使用
ATA
磁盘作为高带宽的应用。
保持
RAID
组的足够小，是
< br>metaLUN
策略的一部分。这会使
ATA
硬盘更加合理，
因为小的磁盘组比大的会有更小的重组时间。但是，必须意
识到的时，
metaLUN
会被一个单一的磁盘组的
rebuild
所影响，
而
ATA
磁盘的
rebulid
时间是
冗长的。
基于数据可用性的考量，在非常多的环境里，我们最好避免使用
ATA
硬盘来做
metaLUN
除非动态扩展或者需要非常大的一个容量。
CLI
例子：建立一个
metaLUN
在接下来的例子的代码，我们建立一个
stripe
方式的使用
base LUN30
的
metaLUN
。没有建立
metaLUN
< br>的命令；你需要扩展一个已经出现的
FLARE LUN
来
建立一个
metaLUN
。在命令中
设计而成的
LUN
，都是相同
RAID
的类型和容量的
FLARE
LUN
。
LUN
30
会变成基本的—新的
metaLUN
< br>会把
30
作为他的
identi
fier
。
Matalun
–
expand
–
base
30
–
lus
31
32
33
–
name
P1H00
–
elszm
4
–
type
S
19
扩展的类型被设置成
S
，作为
stripe
方式，而选择
element size
（
4
）是因为
LUN
是建立在
5
块硬盘的
RAID5
组里面。
[
编辑
]
C. MetaLUN
的扩充战略
<
/p>
对于有长期扩展计划的用户来说，
有好几种使用策略。
使用一种策略，
你必须要
确认你的目标。在接下来
的章节会出现的一些可能的目标如下：
把本地的爆发的随机
数据分布到多个磁盘上
去
?
好的顺序
/
带宽的性能
?
有效的利用容量
?
灵活的扩展设备
?
这些都是使用
metaLUN
的用户的主要的目的。
扩展模式的初始化配置初始化安装的规则在图
5
中阐明
。这些规则是：
为初始化容量部署，来部署所需要的磁盘
?
建立合适大小的磁盘阵列组：
?
a.
对于
RAID 1/0
，使用
4
或
6
个硬盘
b.
对于
RA
ID5
或者
RAID3
，使用
5
个硬盘
?
?
?
?
?
把磁盘组按照每一个
set
有
4-8
个
RAID
组的
方法来组织。
（如果要求高的随机
I/O
，那么
需要更多的磁盘组）
对于每一个
m
etaLUN
，根据归属来确定
Raid
组的
set
。
< br>对每一个计划要做的
metaLUN
，通过用
RAID
组在自己的
RAID
组
set
里面的数目来分
meta
LUN
的大小，来确定
component
< br>LUN
的大
小。
从每一个在自己
set
里的
RAID
组里，为每一
个
metaL
UN
建立一个
component
。<
/p>
建立
metaLUN
的时候，
请让组成这个
metaLUN
的
LUN
，跨越所有的的
RA
ID
组
set
里的
RAID
组。
图
5
是一个
set
的
metaLUN
和他们的
RAID
组
set
的例子
20
Figure5.
metaLUN
里面的存储的初始化分布
< br>注意到在图
5
，每一个
meta
LUN
由一个对应一个
RAID
组的<
/p>
LUN
组成。因此，每
一个
LUN
的负载是分布在所有在那个
set
里的
RAID
组。但是，这些
metaLUN
是
和对其他
RAI
D
组的
set
的数据访问是分隔开的。
为什么要使用
RAID
组的
set
？如果我们不允许一个
metaLUN
来扩展到自己的
set
以外，我们可以做出一定级别的隔离，将这种影响控制在磁盘的级别。例如，一
个
RAID
组的
set
可能为一大群文件服务器所设立，
而另一个
RAID<
/p>
组的
set
是为
RDBMS
的数据目录
----
这时一
对普通的
RAID1
组可能被使用作为
RDBMS
的日志设
备。图
6
展示了这一点。
21