数据中心容错从服务器集群故障做起

日期: 2009-03-04 作者:Kyle Rankin翻译:王霆 来源:TechTarget中国 英文

平时关注专业数据中心的人总会强调一则古训——“不要把所有的鸡蛋都放在一个篮子里”。无论你的电力供应、容错网络设备、多路径存储区域网络(SAN)光纤和RAID存储空间是否多余,你所做的一切都要实现N+1冗余。它可以使服务器的容错能力得到极大提高,但并不会增加其成本,同时使你不仅可以在开机的情况下更换电源和硬盘,甚至还可以更换CPU。   许多数据中心的管理人员最终认识到,服务器集群化是一个很好的办法,不仅可以提高其容错能力,还可以降低成本,因为有许多商业服务器硬件可以使用。

除了在成本节约方面的优势外,对服务器集群规模进行扩展时也显得更为容易。如果你需要更多的资源,只需在集群里再加入一台服务器。尽……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

平时关注专业数据中心的人总会强调一则古训——“不要把所有的鸡蛋都放在一个篮子里”。无论你的电力供应、容错网络设备、多路径存储区域网络(SAN)光纤和RAID存储空间是否多余,你所做的一切都要实现N+1冗余。它可以使服务器的容错能力得到极大提高,但并不会增加其成本,同时使你不仅可以在开机的情况下更换电源和硬盘,甚至还可以更换CPU。

  许多数据中心的管理人员最终认识到,服务器集群化是一个很好的办法,不仅可以提高其容错能力,还可以降低成本,因为有许多商业服务器硬件可以使用。除了在成本节约方面的优势外,对服务器集群规模进行扩展时也显得更为容易。如果你需要更多的资源,只需在集群里再加入一台服务器。尽管说这种服务器集群在容错方面有很大的优势,但如果你对其构造了解不透,其原本用来保护集群的监控系统就可能会给你的数据中心造成破坏。

  对数据中心服务器进行集群化处理

  你有两种方法可以将格言“不要把所有鸡蛋都放在一个篮子里”所描述的原理运用到数据中心。你可能会认为,将各种资源散布到多个服务器就是“将鸡蛋放在了不同的篮子里”。但如果你退一步考虑,将整个数据中心看作是一个单一的篮子,你就会发现实施灾难恢复策略的必要性,至少要将这些鸡蛋的复制品放在另一个篮子里。

  如今,服务器集群是数据中心需要考虑的主要问题。大多数基于Web的业务都拥有某种Web集群或数据库集群,甚至可以说云计算也是实施大规模服务器集群的结果。像VMware这类先进的虚拟化技术也在利用服务器集群技术,虚拟化主机会让许多虚拟机在集群服务器之间来回迁移。如果你的虚拟机需要更多资源,你只需在集群里再加入一名成员。如果需要对服务器进行维护,让其从集群中脱离很容易,整个过程中所有虚拟机都不会停机。

  集群故障和心跳监测技术

  在正常运行时,服务器集群的能量是毋庸置疑的。但如果你在一些基本问题上不够小心的话,集群技术也会给你带来麻烦。一套配置不良的集群还可能会发生单独的故障。大多数集群都已经配置了一种心跳监控系统,当服务器集群中有成员机不能正常运行时,整个集群就可以觉察到,而该成员机自己也会知道它与整个故障集群的差异。

  如果一台主机在离线之后依然试图进入集群,就会出现许多问题,因此你会发现许多服务器集群在意识到主机出现故障时会强制将其移出集群。例如,当OCFS2集群(Oracle的集群文件系统)发现有服务器内核不能及时响应心跳监测系统时,它会强迫其在一台机器上运行。

  如果你的服务器集群不能得到正确配置,心跳监测系统就会成为系统中薄弱的环节。许多服务器集群都在网络中部署了心跳监测系统,而在许多最佳方案中大家都提倡将心跳监测系统部署在与生产线隔离的独立网络。许多情况下,大家还提倡尽可能在主机间使用交叉电缆来为心跳监测系统服务。这样的话,如果主机的网络连接已经饱和或是网络层出现问题的话,主机也不会执行其容错脚本。

  不幸的是,并非所有的数据中心都可以有一个独立的网络来为心跳监测系统服务,这是我个人曾经遇到的导致集群故障的问题。我之前已经提到了VMware High Availability(高可用性)集群技术,但我没有提到的是,直到目前为止,除非你在使用ESX时先更改其默认的集群设置,否则就会导致集群故障。

  服务器集群可以检查是否能通过网络或SAN来连接到主机。每台主机必须定期更新其虚拟机管理的档案锁。再结合网络监控措施,就可以判断出一台主机是否出现了故障。遗憾的是,默认的HA(高可用性)设置会使服务器集群与主机隔离,而一旦其脱离了网络连接,就不能支持虚拟机的运行了,无论其是否还拥有SAN连接。

  我已经不止一次地意识到了这个问题。尽管我们的每台VMware主机都有多余的网络接口,但我们却没有为心跳监测系统设置独立的网络。到目前为止我还记着我们第一次出现这种故障的情景。每个周末,网络组都会对网络层进行了例行的维护,包括防火墙的更新在内,有时还会更改网络配置。但我们对此并不是很担心,因为我们的确为VMware主机准备了多余的网络接口,以至于每次只要关闭一个开关,系统的运营环境就可以维持下去。

  一旦维护完成之后,VMware系统管理程序就无法与许多VMware虚拟机保持联系了。它只能识别出是集群的重要组成部分出了问题,因此,它会将那台主机上的所有虚拟机都关掉,将它们迁移到可用的主机上,再将其启动。如果只有一两台主机出现问题,这样做是完全可以的,但如果有很多主机同时出现问题,效果就不会很好。结果会是两到三台位于顶部的VMware主机运载着我们所有的虚拟机。当然了,这些主机就会完全超载,导致曾经在运行的虚拟机也无法正常运行。如果出现故障的主机上搭载的是我们的LDAP及DNS虚拟机,当他们停止相应时,其余要依靠它们的主机的运行速度也会变得很慢。简而言之,在这样的情况下,等网络恢复正常、所有虚拟机恢复正常运作要花好几个小时的时间。

  除了这种大型故障,我们还经历了多次紧张时刻,每当快要进行重大维修时,我们的服务器集群的HA(高可用性)功能就无法得到发挥。最终,在经历了一次由网络中断导致的停机故障后,我们完全禁用了这一功能,因为与没使用该功能之前相比,它使我们的停机时间变得更长了。

  结论:

  我们的反应当然是有些极端。毕竟,集群技术在许多公司发挥了很好的作用。而对我们公司来说,它是一个非常酷的功能,但却不是很有必要。这个问题的底线是,你永远不应该让你自己在数据中心容错方面形成一种错误的安全意识。要想对每个单独故障进行追踪是很困难的,你几乎不可能预测到数以百计的故障组合,而它们有可能会摧毁你坚如磐石的架构。从这一点上讲,容错和安全防范很像——这种漏洞你是无法预知的,但它却可以将你数据中心篮子的底部割一个破洞。

翻译

王霆
王霆

相关推荐