Docker Swarm系列第二部：重新调度Redis

欢迎回来，我们继续本系列的第二篇教程。今天我们将主要关注Redis，希望大家还记得第一部分的主要内容——了解如何安装我们将要使用的环境。

传送门： Docker Swarm系列第一部：利用Flocker部署多节点Cassandra集群

在发生节点故障时利用Swarm对Redis服务器进行重新调度

如果大家认真阅读了第一部分，应该记得我们在Swarm部署中使用了--experimental标记。其中包括Swarm 1.1.0中的一项功能——在节点故障时对容器进行重新调度。

今天，我们将关注如何部署Redis容器并测试当前实验性重新调度功能的当前状态。

注意：重新调度尚处于实验阶段，其中存在bug。我们将在示例过程中的对应位置提醒大家可能出现的bug。

如果大家希望在Swarm主机发生故障时对容器进行重新调度，则需要在容器部署中使用特定标记。作为可行方案之一，我们可以使用以下标记：--restart=always -e reschedule:on-node-failure或者类似于-l 'com.docker.swarm.reschedule-policy=["on-node-failure"]'的标签。以下示例将使用环境变量方法。

首先，我们使用重新调度标记与由Flocker管理的分卷进行Redis容器部署。

接下来，利用SSH接入Docker主机内的Redis容器运行位置，并查看Redis始终使用的appendonly.aof文件内容。该文件应当位于Flocker分卷中，作为容器起始点存在且不包含任何数据。

然后接入Redis服务器并添加一些键/值对。而后，再次查看appendonly.aof文件内容以确保Redis以正确方式存储数据。

在Flocker分卷中查看数据以验证Redis正确运行。

测试故障转移

现在我们将测试故障转移场景，确保我们的Flocker分卷能够将存储在Redis中的数据正确迁移至Swarm重新调度容器的新Docker主机上。

要实现这一目标，我们在Swarm管理器中指定Docker，并利用docker events命令监控各项事件。

要开始测试，首先在运行有Redis容器的Docker主机上运行shutdown -h now以模拟节点故障。大家应该看到与该节点及容器相关的各项事件。

这些事件在告知我们，该容器及其资源由于遭遇故障（包括网络与分卷）需要被移除、断开连接或者卸载。我们看到的事件如下：

Container Kill
Container Die
Network Disconnect
Swarm Engine Disconnect
Volume Unmount
Container Stop

在Docker主机关闭一段时间之后，大家应该会最终看到故障容器正在进行重新调度（即重新创建）。在这里需要提醒的是，在测试中我们发现Swarm 1.1.3版本中仍然存在问题，即其仍然会在被创建在新Docker主机上的容器中运行 Start 。

大家应该会在查看到Create事件记录的同时发现docker events，而后者的作用是对容器重建以及Flocker分卷移动进行初始化。

我们发现，大家可能需要在重新调度完成后，在新主机上手动Start该容器。

注意：容器创建过程中存在一些问题，但在测试中我们并未在容器启动时发现问题。

此事件代表着我们的容器已经经过重新调度并自动创建于新的Docker主机之上。请注意，最新信息中的IP地址发生了变化，这是因为容器被调度到了新的Docker主机中。

回顾

下面来看流程回顾：

如果我们对Swarm运行docker ps，则会看到该Redis容器为Created。在这种情况下，我们可以手动进行启动，而Redis也将恢复并运行在新节点上。

下面接入该Redis服务器以确保我们添加的数据仍然存在。

数据仍然存在！不过考虑到重新调度情况，我们不建议大家直接使用这些数据。

在测试当中，大部分用户反映容器能够在新节点上正常启动。但也确实有部分用户指出重新调度机制并未生效，或者是在Docker主机恢复后出现了两套容器。无论如何，工作当中显然还存在着问题，而社区的作用也正在于此——帮助测试、报告并修复这些问题，从而确保其运行效果更为可靠。