对集群服务器应该如何进行备份

一般情况下对网络服务器进行备份是比较简单的工作，但是，一旦这些服务器组成了集群，那么备份起来就会让人摸不着头脑了，因为集群中会有多台物理服务器(又被称为节点)，而他们对外则表现为一台逻辑服务器。本文就帮你来理清如何对集群服务器进行备份的思绪。

集群有多种，针对每一种集群所采用的备份方式也不尽相同。作为样例，我就举例说明如何在一个被配置了Cluster Continuous Replication (CCR)的Windows Server Majority Node Set (MNS)集群中对其上运行的Exchange Server 2007数据进行备份。

简单来讲，一个集群服务器化之后的mailbox由两个集群节点组成，一个处于活动状态，另一个处于非活动状态，只有活动状态的服务器处于工作状态，非活动状态的服务器则作为一种热备机而存在。Exchange Server 2007使用一种被称为“log shipping(日志传送)” 的机制将活动服务器上的transaction log传送到非活动服务器上。这样，一旦活动服务器发生故障，那么所有的数据都会在非活动服务器上保存着一份，可以立即被使用。

至于对数据的备份，Microsoft则推荐备份非活动服务器上对应的数据而不是备份活动服务器上的。之所以这样推荐，其背后的原因是因为活动服务器是处于工作状态的，它需要承担所有的工作负载，此时如果去备份非活动服务器上对应的数据，就可以将对活动服务器的影响降到最低，你可以在任何时候发起备份，而不影响活动服务器上的用户访问。

虽然这种备份方式听起来很有道理，但是你依然需要注意一个小问题。在集群failover的情况下，非活动服务器变成了当前工作的服务器，但当你把原本的活动服务器恢复上线时，它就会变为现在的非活动服务器了，而且会一直保持非活动服务器的角色，除非你手动设置它为活动节点(或者设定为自动回管)。此时问题就来了，你不可能立即就知道当前是哪台服务器处于非工作状态，那么你就不知道应该在哪台服务器上进行备份了。

万幸的是，你不必埋头自己去解决这个问题了。大多数企业级的备份软件都是cluster aware的，它们可以感知到集群当前的状态，即便如此，你依然需要对备份集群服务器中的数据有一个战略性的准备。

我还是展示一下我刚才说的意思吧。我们来看看“A：对集群的备份”。这张截图是从Microsoft's System Center Data Protection Manager 2007 (DPM 2007)备份程序中截取的，DPM就是我用于我的网络环境中的备份工具。图示的这个对话框可以让你来选择需要备份的项目。你会发现，其中有EXCHNODE1服务器，另一台服务器EXCHNODE2。这两台服务器就是当前Exchange Server集群中的两个节点。

你会看到，Microsoft's System Center Data Protection Manager 2007将集群中的所有两个节点都列出来了。

如果你看一下列表的最下方，你会发现一个ProdCluster，这就是由刚才那两台节点所虚拟出来的虚拟服务器了。当我展开ProdCluster时，DPM 2007会显示出一个列表，其中包含“Cluster group，还有集群化的mailbox服务器。

DPM 2007可以让你直接选择备份集群服务器化之后的mailbox，而无需单独的去集群服务器中两台节点上实行备份。至此我们仍然对非活动节点只字未提。然而，当我选中集群服务器化之后的mailbox后点击Next的时候，DPM 2007 跳出了一个对话框，如图“B：选择所需备份的节点”所示。你看到了，到此我终于可以选择到底在哪台节点上执行备份了，是活动服务器，或者非活动服务器。

​ Redis Cluster 集群分区方案采用去中心化的方式，包括：sharding（分区）、replication（复制）、failover（故障转移）

​ Redis Cluster 由多个Redis节点组构成，是一个P2P（point to point）无中心节点的集群架构，依靠Gossip协议传播集群

Gossip协议是一个通信协议，一种传播消息的方式。

起源于：病毒传播

Gossip协议基本思想：

一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。

这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。

信息会周期性的传递给N个目标节点。这个N被称为 fanout （扇出）

gossip协议包含多种消息，包括meet、ping、pong、fail、publish等等

通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能。

redis-cluster把所有的物理节点映射到[0-16383]个 slot 上,基本上采用平均分配和连续分配的方式。

比如上图中有5个节点，这样在 Redis Cluster 创建时，slot槽可按下表分配

cluster 负责维护节点和slot槽的对应关系 value------>slot-------->节点

当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把

结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点

数量大致均等的将哈希槽映射到不同的节点。

比如：

set name zhangsan

hash("name")采用crc16算法，得到值：1324203551%16384=15903

根据上表15903在13088-16383之间，所以name被存储在Redis5节点。

slot槽必须在节点上连续分配，如果出现不连续的情况，则RedisCluster不能工作。

redis版本说明

redis505

服务器说明

启动 7001、7002、7003、7011、7012、7013

配置启动脚本

三主三从

客户端连接集群

-c 以集群方式连接

扩容节点数据必须为空

启动 7004、7014

将 7004、7014 添加到集群

只能删除数据为空的节点

集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PIN

如果在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B

标识为pfail。

A在后续发送ping时，会带上B的pfail信息， 通知给其他节点。

如果B被标记为pfail的个数大于集群主节点个数的一半（N/2 + 1）时，B会被标记为fail，A向整个集群

广播，该节点已经下线

其他节点收到广播，标记B为fail。

采用 raft 协议

每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数

据越多）的从节点，选举时间越靠前，优先进行选举。

slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选，

master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。

slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到

FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。

所有的 Master 开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 +

1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。

RedisCluster失效的判定 ：

1、集群中半数以上的主节点都宕机（无法投票）

2、宕机的主节点的从节点也宕机了（slot槽分配不连续）

当slave 收到过半的master 同意时，会成为新的master。此时会以最新的Epoch 通过PONG 消息广播

自己成为master，让Cluster 的其他节点尽快的更新拓扑结构(nodeconf)。

自动切换

就是上面讲的从节点选举

手动切换

人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式(数据无丢失)将当前

master节点和其中一个slave节点(执行cluster-failover的节点)交换角色

1、向从节点发送cluster failover 命令（slaveof no one）

2、从节点告知其主节点要进行手动切换（CLUSTERMSG_TYPE_MFSTART）

3、主节点会阻塞所有客户端命令的执行（10s）

4、从节点从主节点的ping包中获得主节点的复制偏移量

5、从节点复制达到偏移量，发起选举、统计选票、赢得选举、升级为主节点并更新配置

6、切换完成后，原主节点向所有客户端发送moved指令重定向到新的主节点

以上是在主节点在线情况下。

如果主节点下线了，则采用cluster failover force或cluster failover takeover 进行强制切换。

我们知道在一主一从的情况下，如果主从同时挂了，那整个集群就挂了。

为了避免这种情况我们可以做一主多从，但这样成本就增加了。

Redis提供了一种方法叫副本漂移，这种方法既能提高集群的可靠性又不用增加太多的从机。

Master1宕机，则Slaver11提升为新的Master1

集群检测到新的Master1是单点的（无从机）

集群从拥有最多的从机的节点组（Master3）中，选择节点名称字母顺序最小的从机（Slaver31）漂移

到单点的主从节点组(Master1)。

具体流程如下（以上图为例）：

1、将Slaver31的从机记录从Master3中删除

2、将Slaver31的的主机改为Master1

3、在Master1中添加Slaver31为从节点

4、将Slaver31的复制源改为Master1

5、通过ping包将信息同步到集群的其他节点

它非常适合用来快速配置一个集群中的所有运行相同服务和具备相同配置的计算机节点。现在有大量的开源管理工具，都可以实现这样的管理，比如dsh、SUSE Manager等。下面是用ClusterSSH管理多台Linux服务器的具体过程。

如果你是一名Linux系统管理员，那你每天一定会和许许多多的机器打交道，因为你要定期监测和维护这些机器，如一批Web服务器，如果你要同时在多台机器上敲入相同的命令，你可能会通过SSH登录，然后逐台敲入，如果使用ClusterSSH，可以为你节省不少类似的工作时间。

ClusterSSH是用Tk/Perl包装XTerm和SSH后形成的新工具，就其本身而言，它可以运行在任何兼容POSIX的操作系统上，我曾经在Linux，Solaris和Mac OS X上运行过它，它需要Perl库Tk（在Debian或Ubuntu上就是perl-tk）和X11::Protocol（在Debian或Ubuntu上就是libx11-protocol-perl），此外，xterm和OpenSSH是必不可少的。

安装在Debian或Ubuntu上安装ClusterSSH是相当简单的，只需要敲入sudo apt-get install clusterssh就可以安装好，至于依赖包你也不必担心，一切都会为你装好的，它也提供了适合Fedora的rpm包，在FreeBSD上可通过port系统安装，还为Mac OS X准备了MacPort版本，因此你可以在你的苹果电脑上安装ClusterSSH，当然，如果你是极客，也可以下载源代码自己编译。

配置可以通过ClusterSSH的全局配置文件/etc/clusters，或用户home目录下的。csshrc文件来配置它，我喜欢用户级的配置方式，这样同一个系统中的不同用户可以根据自己的喜好进行配置，ClusterSSH定义了一个“cluster”机器组，你可以通过一个界面来控制这个组中的所有机器，在配置文件的顶端“clusters”部分，你可以详尽地列出你的集群，然后用独立的段落来描述每个集群。

例如，假设我有两个集群，每个集群由两台机器组成，“Cluster1”由“Test1”和“Test2”两台机器组成，“Cluster2”由“Test3”和“Test4”两台机器组成，~csshrc（或/etc/clusters）配置文件的内容看起来应该是：

clusters = cluster1 cluster2

cluster1 = test1 test2

cluster2 = test3 test4你也可以创建中间集群（包含其它集群的集群），如果你想创建一个名叫“all”的集群包含所有的机器，有两种实现手段，首先，你可以创建一个包含所有机器的集群，如：

clusters = cluster1 cluster2 all

cluster1 = test1 test2

cluster2 = test3 test4

all = test1 test2 test3 test4但我更喜欢的方法是使用一个包含其它集群的中间集群：

clusters = cluster1 cluster2 allcluster1 = test1 test2