如何在Vblock里配置Boot from SAN

啥是vBlock

============

vBlock是VCE用在包含了它的数据中心产品的组件的机架上的一个商标名. 机架中的组件都是有VCE出厂前预先组装好的, 组件的预设以及解决方案, 都是客户可选的, 这样产品的电源, 重量, 冷却, 尺寸大小都是可以预见的确定的. vBlock系统包含EMC的存储, Cisco的switch和server, 还有VMware的虚拟化软件.

为啥要配置boot from SAN

=============

通过在运行中或在刀片机宕机的时候使用service profile来provision刀片机, Cisco UCS提供了无状态计算(stateless computing), 这使得boot from SAN成为了一个非常有吸引力的设计选择. Boot from SAN通过不在任何本地磁盘上存放数据, 从而使得添加新刀片机和替换挂掉的刀片机这种任务变为了简单的动动service profile就可以了的小case.

一些基本概念和知识的解释

=============

Storage Group和host以及LUN的对应关系为:

一个Host只能属于一个storage group, 一个LUN可以属于多个storage group.

Zoning和Masking

Zoning是SAN switch上的一种基于端口(WWPN)的配置. 而Masking是一种以LUN为颗粒度的storage feature.

不是有LUN Masking了么, 为啥要MDS (Multilayer Director Switch) 上做zoning呢?

除却security上的双保险之外, 还有一个好处. 如果在没有zoning的Fibre Channel network上, 任何fabric的change(Registered State Change Notification message)都会广播到每一个fabric的节点上, 即使这个节点跟这个修改没啥关系. 这样划zone就可以避免RSCN干扰FC网络.

引申

============

介绍了上面的基本概念, 下面问题来了. 假设在Vblock的UCS里有四台刀片机, 刀片机上安装ESXi, 都配置boot fromsan.

那我在划storage group的时候, 为每一台host和它对应的boot lun都创建一个storage group. 好了四台blade server都能正常启动了. 为什么要这么做呢? 因为boot LUN只是针对某一台specific的host的, 所以它应该只能是这个host单独所见.

现在我的这四台ESXi要join一个VMware cluster, 访问同一个VMFS/RDM data LUN. 那我的这四台blade已经各自存在于一个storage group了, 不能再添加进新的storge group. 也就是说, 如果要做到四台blade访问同一个VMFS/RDM data LUN, 那我的这个VMFS/RDM data LUN要被分别添加到这四个storage group中. 四台还好, 如果我有20台blade呢? 添加20次么? 如果有100台呢? 添加100次么? 如果要删除LUN呢? 也要这么10次20次100次的删除么?

另外, 如果我们的这个data lun漏join了一个storage group, 一开始很难发现, 但是一旦host重启, 虚拟机vMotion到别的host上的时候, 虚机直接就挂了.

解决方案是使用Cisco UCS的虚拟技术, 为host多创建两个vHBA, 即4个vHBA, 两个(vHBA0, vHBA1)用于设置启动, 通过zoning让这两个HBA只能看到boot LUN. 另外两个(vHBA2, vHBA3)用于访问data LUN. 在Unisphere中, 注册vHBA2和vHBA3为一个新的host的名字, 并且将它加入到一个名为cluster storage group的storage group中. VMFS/RDM data LUN加入到这个cluster storage group中去. 这样, blade server们使用起来就跟local boot一样了. 再也不用一个LUN加好多遍, 删好多遍了.