windows server 2008 R2 高可用性和群集

  小白最近测试windows server 2008 R2 故障转移群集，在测试期间受到高手的指点在加上MVA学院老外讲高可用性和群集，总结了一些关键原理。在这里拿出来和大家分享，在这里敬请各位的同行提出宝贵的想法，大家共同进步。

  故障转移群集是我们为虚拟机提供的高可用性的平台，当然网络负载平衡，分布式流量等其他技术也可以用来保证其高可用性，但是技术更多的是关于冗余性的，而我们真正关注的私有云，动态数据中心，虚拟机内部的灵活性以及把所有虚拟机转移到另一台主机时可以同时进行服务器维护。还有更重要的是灾难恢复，在一个数据中心内部拥有高可用性非常不错的事情，但是如果你损失了整个数据中心，会发生什么呢？而通过“多边群集”的灾难恢复解决方案，我们不仅可以在一个数据中心的服务器之间迁移虚拟机，还可以在数据中心之间转移虚拟机，使故障转移真正的跨越不同的地理位置，从而让你的服务器保持24/7小时在线运行。因此故障转移群集和Hyper-v对私有云是很重要的。

  在windows server 2000或2003版本上做群集备份是一件很痛苦的事情，那个时代有一个windows服务器目录，详细的列出了群集兼容的硬件，如果你使用群集的同时又想更换网卡，但是新网卡不再硬件兼容列表里，我们都知道在技术层面上不会有一个可支持的解决方案。所以在windows server 2008 R2版本中，完全的改变了这一点，硬件仍需要windows加载程序，它会和windows一起验证，然后通过一个内嵌的我们称之为“合法性验证”的最佳实践分析器进行验证，只要这个硬件是有商标的即可通过验证，通过验证后你就拥有了一个可以完全屏蔽硬件差异的群集。这使群集部署更容易。但我们建议使用相似的硬件，这符合最佳实践。

  最关键的应该是假如我们已经创建了一个群集，故障转移群集内部都在发生什么样的事情呢，这好比当你在路由器上敲了N条命令，路由器内部会发生什么状况是一个道理。我们都知道群集上的各个节点都会运行一个应用程序、一个服务或者一台虚拟机，一个节点可以运行上百个应用程序，服务或虚拟机，如过你有两个节点，它们相互作为彼此的延伸，所以对于在哪个节点上运行哪个应用程序事实是没有限制的，这都是故障转移群集环境中的灵活性，应用程序并不关心它在哪个节点上运行，虚拟机也不关心它在哪个节点上上，只需要保持虚拟机并启动一直运行即可，对于这些问题某个时刻在一个节点上运行，而节点则会保持同一时刻其他节点运行的内容，我们称之为群集数据库，它本质是注册表的一部分，通过跟踪知道节点1上运行了哪些程序，节点2上运行了哪些程序，而且跟踪结果会被复制并覆盖整个数据中心，整个群集，所以在任何时刻每个节点都会知道其他节点上运行的内容。群集的另一个关键部分是存储结构，所有节点需要访问相同的数据，为了实现这一点，我们把数据放在存储区域网络（SAN）上，如过我的虚拟机在节点1上，虚拟机的磁盘文件VHD和我的所有的数据都放在一个SAN上，当我的虚拟机转移到另一个节点，在新节点上的虚拟机仍然可以访问数据，因此拥有共享存储是保证在群集在节点间转移虚拟机和转移应用的移动性和灵活性的硬性要求，现在所有的节点都在不断的监测其他节点的状态，这样的跟踪可以保证集群数据库的内容的有效性，每个节点不断的Ping其他节点，发送“你是否正常”的信息，从而保证我们可以检测到任何计划外的故障，这就是常说的“心跳”状态监测方法。那么当一个计划外的故障发生时，假如我节点1崩溃了，不可用了，心跳会检测会发现这个故障，这和一个路由器挂了就会发送TCN报文说我出问题了，是一样的，那么第二个节点会说：“第一个节点不可用了”我会去数据库看看并尝试启动这些服务，然后第二个节点会去连接共享存储，去连接客户端，所有服务上线了，一切就这么简单。

  有人会问，我们能否将虚拟机集群化，在虚拟层面获得高可用性？答案是肯定的，我们称之为客户群集。主机群集是物理层面的群集，因此我如果有两台物理服务器，而一个虚拟机就可以在两台服务器之间转移，所以我们可以将不同的业务运行在虚拟机上，并且在虚拟机之间服务可以进行故障转移。那么是否可以同时做两种群集呢？答案是可以的，当我们做群集时，是物理的还是虚拟的没有任何限制，对支持这两种群集我们的要求是相同的，所有的硬件必须有商标，必须通过最佳实践验证和合法性验证。一旦通过验证就可以做群集。主机群集是为了消除单点故障，此时Hyper-v的另外一个优势就体现出来，由于我们整合了物理主机和虚拟主机，只要我们开启了心跳设置，事实我们就可以看到内部的虚拟机的操作系统，并检测是否有任何用户模式挂起，因此如果一个虚拟机蓝屏了或虚拟机系统崩溃了，那么主机会说，我的虚拟机崩溃了，让我来自动重启，因此我们有了增强的故障恢复，增强的高可用性。另一种不错的方式是如果你想为物理基础设施打补丁，但是你不希望你的所有虚拟机在线运行，这个没问题。只要把你的虚拟实时迁移到另一台主机上即可。而且对于这些虚拟机不会有可察觉的停机时间，因为它们只是在物理服务器之间做了简单的实时迁移，因此这提供了很大的灵活性。如果你想监控运行在虚拟机内的应用程序状态，客户群集是一个不错的选择。

  接下来谈谈ISCSI和光纤通道，如果是在物理层面做群集，我们支持光纤、串行连接的SCSI和ISCSI。如果要做客户群集，只群集虚拟机，并在虚拟层面支持故障转移，那么必须使用ISCSI，这是Hyper-v的要求，小白多一嘴，哈哈…，也就是说Hyper-v不支持虚拟HBA。用光纤通道，很快，性能好，而ISCSI很便宜，我们可以得到很多免费的ISCSI对象，但是性能没那么好。所以需要权衡利弊。而串行连接的SCSI在某种程度上介于光纤通道和ISCSI之间。我们做实时迁移时，网络带宽越大越好，这和Vmotion一样，带宽越大能塞进去的流量就更多，这在某种程度上加速了内存映像的拷贝的过程。当然还有多路径I/0的冗余性，这是指整个堆栈的冗余性。对于windows来说只要提供磁盘备份，windows是不会关心是光纤、以太网、ip通道，这是有硬件存储来实现的。关于群集共享卷和普通群集磁盘有同样的基础要求，没什么特别。群集共享卷单将会单独讨论。关于网络，我们完全是和TCP/IP协议栈集成的，事实上，我们有称之为NETFT的驱动，NETFT适合用在集群内部通信，例如群集更新至数据库或这像心跳线通信类的普通通信，现在当我们谈到冗余性，高可用性时我们需要把网络也考虑进来，所以至少要保证网卡的冗余性，如果你要使用Hyper-v群集，那么我们建议在最佳实践中，四块网卡是很必要的。如果你使用ISCSI，你么你很可能需要5块网卡，现在我们看看如和使用这些网卡，第一块网卡用来做普通的Hyper-v管理，因为我需要管理我的所有Hyper-v虚拟机，第二块网卡为那些实际使用虚拟机的人提供网络通道，例如我的虚拟机上正在运行一个数据库，某人可能需要访问这个数据库，我们可以尽力提供一个网络通道，这样可以避免干扰其他群集通信。还有一个我们会使用的网络，就是CSV，CSV允许我们通过SMB将存储流量传输到另一个网络，这样即使我们损失了一个存储通道，我们仍然可以有高可用性和冗余性。另外我们建议为实时迁移提供一个独立的网络。因为我们进行实时迁移需要进行大量的内存映像复制操作，拥有一个专用的通道才是最佳实践。那么我们为什么要尽力的隔离这些网络？这是因为我们不希望触发错误的健康警报。

  做过故障转移测试的人都知道，群集验证是必须的，小白第一次做的时候报了好多错误和警告，深受其折磨。windows会运行一系列的端到端的测试，确保所有的硬件和软件是适合群集的。例如部署的服务包是一致的，打的补丁是一致的，这些都是为了服务可以尽快的启动，测试中有一项是测试是否每一个节点都可以访问磁盘，另一个重要的磁盘检查是检查它是否支持永久保留，持久保留是一个SCSI3命令，是节点对磁盘加锁的一种机制，这种机制保证对于一个磁盘同一时刻只能有一个节点在写磁盘操作，并确保其他节点在获取写权限之前不能写磁盘，这是群集存储的一个要求，测试系统配置文件，从而确保你给驱动器安装的补丁是否处在相同的级别，节点必须加入域，同时也可以访问一个可写的域控制器。

  好了，今天就写到这里，时间有限啊。再一次说明，这些都是老外说的，不是小白说的，只是辛苦总结了一些。