XP24000 Best Practise (一 ) – CHA Processor Sharing 准备一个系列的文章关于XP24000 Best Practise，及最佳操作实践，通过这些最佳的做法和方式，使XP 磁盘阵列的性能和可靠性达到最佳。文章没有什么前后顺序，可能会想到哪里写到哪里，实在抱歉。 先来说说CHA Processor Sharing，主要功能是当CHIP 中的处理器负载程度达到50%以后，其他的处理器可以帮助处理部分IO 请求，避免在同一块CHA 上出现负载的热点，需要说明的是，该特性只针对写操作有效，对于读操作是无效的，这也就是有时我们通过XPPA 或其他性能监控工具看到，某一个CHIP 的某一个处理器负载在60%甚至更高，但是其他处理器几乎空闲，第一反应，这是典型的读IO，备份的可能性很大。 CHA 除了Processor Sharing 以外，对于IO 的类型也是敏感的，特别是顺序类型的IO 操作，对于顺序IO 读， CHA处理器会从后端磁盘中预抓取部分数据，用以保证Cache 的高命中率，对于顺序IO 写，CHA 会在Cache 中处理全部的校验IO，批量的写入后端，同时CHA 会根据IO 情况出发其对应读写Cache 的比例。 XP24000 Best Practise (二 ) – Concatenated 继续昨天的讨论，想说说Concatenated，直接翻译过来“连接或联合”， XP 之所设计出这种磁盘的组合方式，其主要目的是考虑更多的底层磁盘的Striping，以应对更多的来自Host 的 IO 请求，毕竟传统的Array Group 只用4 块硬盘，即使通过7D+1P 或是6D+2P 的方式，也只有使用到8 块硬盘，但是通过Concatenate 的方式，可以轻松的striping到 32 块物理磁盘，以便达到更高的IOPS。 但是在操作Concatenate 的时候，问题出来了，如何选择RG（ Raid Group），对于Raid5/6，这个比较好选择，XP 只可以通过连接/跨越DKA 的方式实现，也就是说R3 和 R5， R4 和 R6 （ concatenation，如果不考虑DKC0 的话，也就是DKU 上下HUD 进行striping），但是对于Raid1（ 4D+4D）来说就有两个选择了，可以跨越DKC，也可以在一对 DKC 内实现，实际对于4D+4D 来说，通过XP 的 Raid 选择方式是无法选择的，必须通过concatenate 的方式手动实现，所以就会出现以上的两种选择，参考了很多文档，官方也没有一种明确的说法该如何去实现4D+4D，所以我觉得两种方式都ok，在实际环境中，两种方式本人都亲自配置成功过，以下的说法很有参考性。 “There is no rule or limitation which RAID ...
