|
第13期 － 2015年8月 Loxoll HA-AP 如何处理孤岛状态？
在引擎间利用管理端口 ( E1 ) 实施以太心跳 ( Ethernet Heartbeat )，用以协助识别 FC 孤岛 ( FC Isolation ) 和异地站点故障 ( remote-site-down )。一旦引擎无法经由 FC 正常沟通，即可借助以太心跳来判断是异地站点故障 ( 无以太心跳 )，还是仅仅因为 FC 断链 ( 有以太心跳 )，然后采取适当应对措施，避免脑裂现象。 绝对孤岛 那么是否有可能 FC 和以太心跳同时断链呢？机会很小，但是并非绝无可能，我们称这种状态为“绝对孤岛” ( Total Isolation )，同样是会导致脑裂现象。 如何处理绝对孤岛 ( Total Isolation Protection )。一旦发生 FC 和以太心跳同时断链，也就是绝对孤岛状态，那么集群中的众引擎必然处于以下两种场景之一：即 1.
异地站点的所擎确实已经失去行为能力 ( 例如被关机、因无法访问任何存储而自行停止运营、或其他原因 )；或 2.
异地站点的引擎仍在运营，但是两站点之间的通讯断链。
然而引擎对于绝对孤岛状态的发生原因，究竟是站点故障还是通讯断链，并不具备分辨能力。 解决之道，是在客户现场 ( client site ) 实施一个点名服务 ( Quorum Service )，用以协助识别绝对孤岛状态的存在，并避免发生脑裂现象。在绝对孤岛状态下，集群中的两个站点引擎不但各自处于 FC 孤岛状态，同时也失去彼此之间的以太心跳，这时必须借助应用层的点名服务，执行以下的绝对孤岛状态评估步骤，来判断哪一个站点应该继续运营，哪一个站点应该停止运营，或是两者都应该停止运营，才能避免发生致命的脑裂现象: 1.
如果一个引擎无法访问点名服务，它会无条件自行停止运营。 2.
如果一个引擎可以访问点名服务，并且其配置定义属于系统设定之主要站点 ( primary site )，该引擎会继续运营。 3.
如果一个引擎可以访问点名服务，并且其配置定义属于系统设定之次要站点 ( secondary site )，该引擎必须借助点名服务与主要站点 ( primary site ) 之间的当时状态来做决定；若点名服务能够看到主要站点的引擎集群，则该引擎自行停止运营，否则继续。 上述点名服务必须设定于客户现场，并使用和以太心跳不同的网域 ( domain )，以避免与心跳同时断链。 |
存储厂商 如何让标准的 SAN 存储蜕变为企业级的 HA 解决方案？ 企业 IT 专业 如何完善您的 IT 基础设施以实现无间断业务连续性？ HA-AP 欢迎注册！您只需提供简单的联系信息，即可下载。 联系我们：
|