在当前设计日益复杂的分布式系统中,对于如何更加完善地去做好服务的配置管理,并不是一件简单的事情。配置的管理里面包含的细节内容其实不少,诸如配置的历史变更记录(就是我们常说的配置版本管理),还有配置的统一、一致性管理。我们经常会看到系统服务的配置在没有规范统一的情况下最后被改成各种差异化的配置值。这其中差异的配置在日后将会给系统管理人员带来额外的管理成本以及一些隐患。本文笔者结合目前Hadoop Ozone系统对于配置管理的一些idea设计,来谈谈这里面的内容。也是帮助大家了解了解在一个复杂的分布式系统中,我们会遇到哪些配置上的问题,以及我们可以怎么做来解决、改善这些问题。
当我们很多时候谈到系统的时候,我们不禁会聊到里面的Service服务,而对于这些独立Service的启动背后,对应的都有其相对应的配置。而随着系统Service功能的不断开发、迭代,对应的就会有越来越多新的相关联的配置项被加入到系统的配置文件中。这里面配置项的数目就可能扩张到一个非常恐怖的数量,比如Hadoop系统的配置。Hadoop系统发展至今,尽管它已经将配置进行了分模块的划分,但是每个模块下的配置数依然十分之多。即使是一个非常熟悉Hadoop系统的人,他也基本不可能记住所有的配置以及相应的作用描述吧。
虽然说有的时候我们有这么多的配置项,但是按照大类型来划分的话,可以归纳为以下两类:
了解完配置的类型划分后,那么我们说复杂配置到底会给我们,更具体地来说应该是系统管理员带来哪些问题呢?
至少有以下三方面问题:
1)系统服务的初始建立变得更加的复杂。因为配置更加复杂,管理者要了解更多相关配置的含义,而且有些还得按照依赖关系配置完毕,系统才能最终启动。
2)客户端的配置也要被迫进行复杂的配置,否则将无法正常访问系统服务。
3)较难确保系统各组件配置的一致性。当同个系统下的各组件都处于独立部署运行模式下,我们很难保证它们的配置都是出于一致的。每个组件服务的都有其自身的启动配置项值。
基于以上暴露出来的问题,Hadoop Ozone提出了中心配置管理化的设计方案。与我们平常说的中心配置管理方案不同的是,它是在系统内部做了一个小的设计,而不是新开发独立的外部系统来做的,我们继续来看后面的内容。
Ozone的中心化配置管理的设计核心在于配置的出处要尽量控制在出自于同一个地方,其次系统管理员尽不需要配置复杂的配置项来启动服务。
以下是Ozone中心配置管理的细节要点,不过在了解细节要点之前,我们先来理一理Ozone内部Service的关系,因为Ozone配置的中心管理需要依赖这层联系。
首先是SCM服务首先启动,然后OzoneManager服务其次启动,接着是诸如后续Recon Server等服务。
根据上述的服务启动依赖顺序,所以中心配置化的管理的服务应该是在最初的启动服务内,也就是这里的SCM服务。也就是说,管理员其实只要提供一份初始配置给SCM服务即可,后续其它关联服务都从SCM服务获取配置信息即可。
这里有几个细节点:
对于客户端来说,我们可以通过命令从SCM服务中获取集群的配置信息,然后进行本地客户端的快速使用。目前Ozone已经支持用户快速获取并生成集群配置文件的工具命令。
另外,Ozone社区吸取了Hadoop现有配置设计上的一些缺陷,在配置项entry中新增了ETag属性,来标明配置所属的方面,比如Security,是不是Must required等等。ETag的引入将会帮助用户快速筛选哪些是我们想要调整的配置项。一个配置项是可以有多高tag值的,比如下面这个配置:
<property>
<name>ozone.om.https-addressname>
<value>0.0.0.0:9875value>
<tag>OM, MANAGEMENT, SECURITYtag>
<description>
The address and the base port where the OM web UI will listen
on using HTTPS.
If the port is 0 then the server will start on a free port.
description>
property>
下图是简单的Ozone服务配置中心化的流程图:
[1].https://issues.apache.org/jira/browse/HDDS-1467 . Support configless Ozone service management