OpenStack 源码系列之 Nova：服务启动

2017-08-20

跟 Keystone 相比，Nova 的服务类型就要多一点了，如 nova-api、nova-compute、nova-scheduler、nova-conductor 等（可通过 ps -ef | grep nova 查看得到），具体可查阅官方文档 Compute service overview。其中，nova-api 跟另外的服务不一样的地方在于它是一个 WSGI 服务，用于接收 REST API 请求，再将请求转发给其他服务（如 nova-compute）。也就是说，nova-api 是一个应用层的服务，其余的是逻辑层的服务。

在源码中，nova-api 服务的启动方式跟其余服务的启动方式不一样，所以下文将会分成两个部分来说明，即 nova-api 的服务启动以及以 nova-compute 为代表的服务启动。

nova-api 服务

对于 WSGI 服务，我们一般需要从 setup.cfg 和 api-paste.ini 这两个文件入手就可以了。我们先来看一下 setup.cfg 文件内容：

......
console_scripts =
    nova-api = nova.cmd.api:main
......

也就是说，nova-api 服务的入口在 nova/cmd/api.py 的 main 函数：

# nova/cmd/api.py

def main():
    config.parse_args(sys.argv)
    logging.setup(CONF, "nova")
    utils.monkey_patch()
    objects.register_all()
    if 'osapi_compute' in CONF.enabled_apis:
        # NOTE(mriedem): This is needed for caching the nova-compute service
        # version which is looked up when a server create request is made with
        # network id of 'auto' or 'none'.
        objects.Service.enable_min_version_cache()
    log = logging.getLogger(__name__)

    gmr.TextGuruMeditation.setup_autorun(version)

    launcher = service.process_launcher()
    started = 0
    for api in CONF.enabled_apis:
        should_use_ssl = api in CONF.enabled_ssl_apis
        try:
            server = service.WSGIService(api, use_ssl=should_use_ssl)
            launcher.launch_service(server, workers=server.workers or 1)
            started += 1
        except exception.PasteAppNotFound as ex:
            log.warning(
                _LW("%s. ``enabled_apis`` includes bad values. "
                    "Fix to remove this warning."), ex)

    if started == 0:
        log.error(_LE('No APIs were started. '
                      'Check the enabled_apis config option.'))
        sys.exit(1)

    launcher.wait()

其中，gmr.TextGuruMeditation.setup_autorun(version) 表示开启 Guru Meditation Report（通用的错误报告产生框架），以便于排错。这里我们暂不详说。

另外一个值得注意的是 enabled_apis，在 /etc/nova/nova.conf 可以看到其值为 osapi_compute,metadata，也就是说 nova api 实际真正启动了 osapi_compute（“真正” nova-api）及 metadata 两个服务。我们接着往下看：

# nova/service.py

class WSGIService(service.Service):
    """Provides ability to launch API from a 'paste' configuration."""

    def __init__(self, name, loader=None, use_ssl=False, max_url_len=None):
        """Initialize, but do not start the WSGI server.

        :param name: The name of the WSGI server given to the loader.
        :param loader: Loads the WSGI application using the given name.
        :returns: None

        """
        self.name = name
        # NOTE(danms): Name can be metadata, os_compute, or ec2, per
        # nova.service's enabled_apis
        .......
        self.loader = loader or wsgi.Loader()
        self.app = self.loader.load_app(name)
        ......


# nova/wsgi.py
class Loader(object):
    """Used to load WSGI applications from paste configurations."""

    ......
    def load_app(self, name):
        """Return the paste URLMap wrapped WSGI application.

        :param name: Name of the application to load.
        :returns: Paste URLMap object wrapping the requested application.
        :raises: `nova.exception.PasteAppNotFound`

        """
        try:
            LOG.debug("Loading app %(name)s from %(path)s",
                      {'name': name, 'path': self.config_path})
            return deploy.loadapp("config:%s" % self.config_path, name=name)
        except LookupError:
            LOG.exception(_LE("Couldn't lookup app: %s"), name)
            raise exception.PasteAppNotFound(name=name, path=self.config_path)

也就是说，osapi_compute 及 metadata 的服务需要由 PasteDeploy 来加载，它们的配置如下：

# etc/nova/api-paste.ini

############
# Metadata #
############
[composite:metadata]
use = egg:Paste#urlmap
/: meta

[pipeline:meta]
pipeline = cors metaapp

[app:metaapp]
paste.app_factory = nova.api.metadata.handler:MetadataRequestHandler.factory

#############
# OpenStack #
#############

[composite:osapi_compute]
use = call:nova.api.openstack.urlmap:urlmap_factory
/: oscomputeversions
# v21 is an exactly feature match for v2, except it has more stringent
# input validation on the wsgi surface (prevents fuzzing early on the
# API). It also provides new features via API microversions which are
# opt into for clients. Unaware clients will receive the same frozen
# v2 API feature set, but with some relaxed validation
/v2: openstack_compute_api_v21_legacy_v2_compatible
/v2.1: openstack_compute_api_v21

到此，nova-api 的服务启动核心部分就说完了。关于其他相关的 Guru Meditation Report、Metadata、Eventlet 等，因为以后会说到，这里就暂不表。

服务启动之后效果如下：

nova-compute 服务

因为除了 nova-api 服务的启动方式稍微有点不一样，其他的服务的都是类似的，这里我们就以 nova-compute 为例来说明，其他的服务只要以此类推就可以了。另外，值得说明的是，nova-compute 服务的启动相对其他其实要复杂得多。

同样，对于 nova-compute 服务，我们也从 setup.cfg 入手：

......
console_scripts =
    nova-compute = nova.cmd.compute:main
......

看下服务启动代码：

# nova/cmd/compute.py

def main():
    config.parse_args(sys.argv)
    logging.setup(CONF, 'nova')
    priv_context.init(root_helper=shlex.split(utils.get_root_helper()))
    utils.monkey_patch()
    objects.register_all()
    # Ensure os-vif objects are registered and plugins loaded
    os_vif.initialize()

    gmr.TextGuruMeditation.setup_autorun(version)

    cmd_common.block_db_access('nova-compute')
    objects_base.NovaObject.indirection_api = conductor_rpcapi.ConductorAPI()

    server = service.Service.create(binary='nova-compute',
                                    topic=CONF.compute_topic)
    service.serve(server)
    service.wait()

不仔细研究代码就不知道这 10 几行代码所涵盖的复杂度。这里特意花了一个 nova-compute 服务启动的概览（图有点大，页面看不清楚，可右键下载查看）：

能够仔细看完这张图的一定是真爱…下边我们挑一些重点的来说。

数据库访问

在以上 main 函数中，代码明确说明了不能直接访问数据库，否则报错：

# nova/cmd/compute.py
def main():
    ......
    cmd_common.block_db_access('nova-compute')
    ......

# nova/cmd/common.py
def block_db_access(service_name):
    """Blocks Nova DB access."""

    class NoDB(object):
        def __getattr__(self, attr):
            return self

        def __call__(self, *args, **kwargs):
            stacktrace = "".join(traceback.format_stack())
            LOG.error(_LE('No db access allowed in %(service_name)s: '
                          '%(stacktrace)s'),
                      dict(service_name=service_name, stacktrace=stacktrace))
            raise exception.DBNotAllowed(service_name)

    nova.db.api.IMPL = NoDB()

而只能通过 conductor 来远程访问（RPC）数据库：

# nova/cmd/compute.py
def main():
    ......
    objects_base.NovaObject.indirection_api = conductor_rpcapi.ConductorAPI()
    ......

# nova/conductor/rpcapi.py
@profiler.trace_cls("rpc")
class ConductorAPI(object):
    def __init__(self):
        super(ConductorAPI, self).__init__()
        target = messaging.Target(topic=CONF.conductor.topic, version='3.0')
        version_cap = self.VERSION_ALIASES.get(CONF.upgrade_levels.conductor,
                                               CONF.upgrade_levels.conductor)
        serializer = objects_base.NovaObjectSerializer()
        self.client = rpc.get_client(target,
                                     version_cap=version_cap,
                                     serializer=serializer)
    ......

也就是说，每当 nova-compute 服务有访问数据库的请求时，它都会调用 nova-conductor 的 rpcapi，从而实现对数据库的读写。这里的 RPC 调用实际是 nova-compute 向消息队列（RabbitMQ）发送 topic 为 CONF.conductor.topic 的消息，而 nova-conductor 又监听该 topic，所以就实现了对 nova-conductor 的调用。这个远程调用过程可参考博文深入研究 Openstack Nova 组件对象模型以及数据库访问机制。

注：Nova 模块以前支持 nova-compute 直接操作数据库而不经过 nova-conductor，具体由配置文件中的 use_local 字段来决定。但在这个最新的版本（Ocata），这个字段就直接废除了：

# releasenotes/notes/rm-conductor-local-apis-f121afaee99f6fa4.yaml

---
upgrade:
  - |
    The ''use_local'' option, which made it possible to
    perform nova-conductor operations locally, has been
    removed. This legacy mode was introduced to bridge a
    gap during the transition to the conductor service.
    It no longer represents a reasonable alternative for
    deployers.

服务初始化及启动

千言不如一图（下图单独拆分成了服务初始化、启动两部分）：

RPC 服务

RPC 服务非常重要，因为在 Nova 中，几个重要的服务 nova-compute、nova-conductor、nova-scheduler 互相之间只能通过 RPC 来实现调用，所以这几个服务都会在启动的时候开启 RPC 服务，监听消息队列中的信息。

在 RPC 启动 RPCServer 之前，对 Transport、Notifier 进行了初始化，详细可参考下图：

接下来就是服务启动了（注意 topic）：

RPC 服务启动完成后，其他模块想向 nova-compute 发送请求的时候，直接调用 nova-comptue 的 rpcapi 就可以了。

定时任务

定时任务也是非常重要的一块。有两类定时任务，时间间隔固定和时间间隔动态决定两种，前一种的有服务状态定时上报（servicegroup.drivers.db::DbDriver::_report_state），后一种的主要跟虚拟机相关，如检查虚拟机 build 时间（compute.manager::ComputeManager::_check_instance_build_time）。详细请参考下图：

花这些图花了差不多两个星期（每天 1.5 个小时左右）…