SES与扩展柜管理

扩展柜（JBOD/SBOD）管理可能在这个坛子里是个冷门的话题吧。 也许有人认为it is not a big deal, 但是须知在RAID系统中no problem is small problem， 尤其是产品已经在客户处运行的情况下，哪怕一点小情况都会让管理员和CS们担心吧，因为这直接关系到存储系统连接的服务能否正常运行。 扩展柜有时候是有可能影响存储系统的性能和稳定的。另外如今的绿色存储的概念中， 扩展柜管理也是其中的一环。

通常来说，扩展柜管理是通过SES 协议/IPMI协议实现的。至于SES 协议和IPMI协议本身，一哥在这里不介绍了，baidu/google一下就可以下载。这里重点讲讲SES 的实现和对RAID system的可能的影响。

SES协议决定了SES device必须是一个SCSI device，这是因为SES协议是通过SCSI Command "Send Diagnostics" 和 "receive diagnostics"传递协议中的page。而SES Device一般来说是实现SES 协议的chip，而这个chip对外呈现一个SES Device (SCSI device type value = 0Dh), RAID Head 把它连到Drive Channel 中，通过SCSI Inband方式进行管理。如果一个扩展柜是Standalone的，那么就需要Host software来管理了。

IPMI 协议最初是用在PC/Server上的，由于它协议的可扩展性加上是大厂推动的协议，很快也应用在存储产品上。在管理途径上和SES的区别在于IPMI是通过outband来管理的。

从过去到现在，SES的实现有以下方法
1）Disk 代理：已经过时，很少有人用了。
2）专门的SES Chip. 现在也渐渐少了,因为其功能单一。
3）在loop switch/SAS expander chip 上，SES 功能作为附带功能出现，同时这些chip 能提供一个SES device. 在loop switch 和 SAS Expander 普及的现在，这种方式最流行。

SES的硬件方面: 一般来说，实现ses的chip通常在硬件上有I2C或是Serial 等连接，因为这些方式是沟通FAN/PSU 以及其他特殊硬件component的方式。ses chip 通过I2C和Serial Interface 和PSU/FAN的application code交换传递控制和状态数据。

SES的软件方面：RAID 主要通过SES 协议上的一些status pages 和control page 来监控扩展柜，而这些pages是通过上面提到的SCSI命令实现的。我们所说的控制PSU/FAN等所谓的一些绿色存储的功能，大多就是通过动态设置FAN/PSU的threshold等方法来实现的，决不是什么高深的学问。

那么，扩展柜管理可不可能影响RAID的功能呢？听上去不太可能吧, 呵呵，nothing is impossible. 介绍一个见识过一个案例。一款FC Raid, 后端有一款SES chip, SES chip通过I2C连到FAN. 在某一个特殊环境下出现电磁干扰，使得I2C上的通信干扰（数据线和信号线互相错乱）造成ses读到的FAN的数据都是garbage data使得SES于是进入retry or re-verify程序，因为SES chip OS的问题，使得retry or re-verify程序在I2C上化了太多时间，从而来不及响应FC/SCSI，造成Loop上FC chip timeout, 从而drop了ses device. RAID看见ses 不见了，也开始retry 和rescan. 这个过程不断重复，造成IO 完成缓慢，甚至有时会看见Lip Storm。等把系统搬出那个环境，一些回归正常。这些测试在实验室里，甚至在特殊实验室的环境下也不一定碰得上。有时候系统设计上的容错能力不一定能完全测得出来的，而在客户的地方，也许会出现一些意想不到的情况。另外，需要记住的是有时候，在实际中如何实现协议所带来的问题可能比实现协议本身更重要。