HDFS 对机器在 DC/OS 内重启的弹性
HDFS resiliency to machine restarts in DC/OS
我已经在我的 DCOS 集群上安装了来自 universe 的 HDFS，集群有 10 个核心 OS 机器（3 个主节点，7 个代理节点）。我的 HA HDFS 配置有 2 个名称节点、3 个日志节点和 5 个数据节点。现在，我的问题是。 HDFS 不应该对机器重启有弹性吗？如果我重新启动安装了数据节点的机器，数据节点将被重建为其他节点的镜像（仅在从 DC/OS UI 重新启动 HDFS 服务之后）。在日志节点或名称节点所在的重新启动的情况下，节点将被标记为丢失并且永远不会重建。
像您这样的 HA 部署的 HDFS 弹性模型的快速总结：
- 这两个 NameNode 形成 active/standby 对。如果机器重启活动，系统会检测到活动发生故障，备用将接替成为新的活动。一旦机器完成重启，NameNode 进程再次运行，它成为新的备用节点。除非两个 NameNode 同时停机，否则没有停机时间。主机上的数据（例如 fsimage 元数据文件）通常在重新启动之间进行维护。如果您的环境不是这种情况，那么您将需要额外的恢复步骤 re-establish 备用数据库，例如通过 运行
hdfs namenode -bootstrapStandby 命令。
- 这 3 个 JournalNode 构成了一个法定人数。在机器重启的情况下，NameNode 可以继续将其编辑日志事务写入剩余的 2 个 JournalNodes。一旦机器完成重启，JournalNode 进程再次运行，追上它可能错过的事务，然后 NameNode 再次写入所有 3 个。除非有 2 个或更多 JournalNodes 同时关闭，否则没有停机时间。如果数据（例如编辑文件）在重新启动时没有得到维护，那么重新启动的 JournalNode 将通过从 运行 JournalNode 复制来赶上。
- DataNodes 大多是一次性的。在机器重启的情况下，客户端将被重新路由到其他 运行 DataNodes 进行读写（假设典型的复制因子为 3）。机器完成重启后，DataNode 进程再次运行，它可以再次开始为来自客户端的 read/write 流量提供服务。没有停机时间，除非大规模同时发生的故障事件（极不可能并且可能与更大的数据中心问题相关）导致特定块的所有 DataNodes 托管副本同时停机。如果数据（块文件目录）在重启后没有维护，那么重启后，它看起来就像一个全新的 DataNode 上线。如果这导致集群不平衡，那么可以通过 运行 HDFS 平衡器来解决。
最终问题是在 DC/OS 的 universe HDFS 包的错误版本中发现的。但是，DC/OS 的全新 HDFS 软件包将在接下来的几周内在 Universe 上发布。
https://dcos-community.slack.com/archives/data-services/p1485717889001709
https://dcos-community.slack.com/archives/data-services/p1485801481001734
我已经在我的 DCOS 集群上安装了来自 universe 的 HDFS，集群有 10 个核心 OS 机器（3 个主节点，7 个代理节点）。我的 HA HDFS 配置有 2 个名称节点、3 个日志节点和 5 个数据节点。现在，我的问题是。 HDFS 不应该对机器重启有弹性吗？如果我重新启动安装了数据节点的机器，数据节点将被重建为其他节点的镜像（仅在从 DC/OS UI 重新启动 HDFS 服务之后）。在日志节点或名称节点所在的重新启动的情况下，节点将被标记为丢失并且永远不会重建。
像您这样的 HA 部署的 HDFS 弹性模型的快速总结：
- 这两个 NameNode 形成 active/standby 对。如果机器重启活动，系统会检测到活动发生故障，备用将接替成为新的活动。一旦机器完成重启，NameNode 进程再次运行，它成为新的备用节点。除非两个 NameNode 同时停机，否则没有停机时间。主机上的数据（例如 fsimage 元数据文件）通常在重新启动之间进行维护。如果您的环境不是这种情况，那么您将需要额外的恢复步骤 re-establish 备用数据库，例如通过 运行
hdfs namenode -bootstrapStandby命令。 - 这 3 个 JournalNode 构成了一个法定人数。在机器重启的情况下，NameNode 可以继续将其编辑日志事务写入剩余的 2 个 JournalNodes。一旦机器完成重启，JournalNode 进程再次运行，追上它可能错过的事务，然后 NameNode 再次写入所有 3 个。除非有 2 个或更多 JournalNodes 同时关闭，否则没有停机时间。如果数据（例如编辑文件）在重新启动时没有得到维护，那么重新启动的 JournalNode 将通过从 运行 JournalNode 复制来赶上。
- DataNodes 大多是一次性的。在机器重启的情况下，客户端将被重新路由到其他 运行 DataNodes 进行读写（假设典型的复制因子为 3）。机器完成重启后，DataNode 进程再次运行，它可以再次开始为来自客户端的 read/write 流量提供服务。没有停机时间，除非大规模同时发生的故障事件（极不可能并且可能与更大的数据中心问题相关）导致特定块的所有 DataNodes 托管副本同时停机。如果数据（块文件目录）在重启后没有维护，那么重启后，它看起来就像一个全新的 DataNode 上线。如果这导致集群不平衡，那么可以通过 运行 HDFS 平衡器来解决。
最终问题是在 DC/OS 的 universe HDFS 包的错误版本中发现的。但是，DC/OS 的全新 HDFS 软件包将在接下来的几周内在 Universe 上发布。
https://dcos-community.slack.com/archives/data-services/p1485717889001709
https://dcos-community.slack.com/archives/data-services/p1485801481001734