OpenStack 中的neutron-server启动过程，openstackneutron


neutron-server是neutron的核心组件之一，负责直接接收外部请求，然后调用后端相应plugin进行处理。

其核心启动过程代码主要在neutron.server包中。

__init__.py文件中包括一个main()函数，是WSGI服务器开始的模块，并且通过调用serve_wsgi来创建一个NeutronApiService的实例。然后通过eventlet的greenpool来运行WSGI的应用程序，响应来自客户端的请求。

主要过程为：

   eventlet.monkey_patch()

绿化各个模块为支持协程（通过打补丁的方式让本地导入的库都支持协程）。

config.parse(sys.argv[1:])

if not cfg.CONF.config_file:

        sys.exit(_("ERROR: Unable to find configuration file via the default"

                   " search paths (~/.neutron/, ~/, /etc/neutron/, /etc/) and"

                   " the '--config-file' option!"))

通过解析命令行传入的参数，获取配置文件所在。

pool = eventlet.GreenPool()

创建基于协程的线程池。

neutron_api = service.serve_wsgi(service.NeutronApiService)

api_thread = pool.spawn(neutron_api.wait)

serve_wsgi方法创建NeutronApiService实例（作为一个WsgiService），并调用其的start()来启动socket服务器端。

#neutron.service

def serve_wsgi(cls):

    try:

        service = cls.create()

        service.start()

    except Exception:

        with excutils.save_and_reraise_exception():

            LOG.exception(_('Unrecoverable error: please check log '

                            'for details.'))

    return service

neutron.service.NeutronApiService类继承自neutron.service.WsgiService，其create方法返回一个appname默认为“neutron”的WsgiService对象；start方法则调用_run_wsgi方法。

def start(self):

        self.wsgi_app = _run_wsgi(self.app_name)

_run_wsgi方法主要是从api-paste.ini文件中读取应用（最后是利用neutron.api.v2.router:APIRouter.factory来构造应用），然后为应用创建一个wsgi的服务端，并启动应用，主要代码为。

def _run_wsgi(app_name):

    app = config.load_paste_app(app_name)

    if not app:

        LOG.error(_('No known API applications configured.'))

        return

    server = wsgi.Server("Neutron")

    server.start(app, cfg.CONF.bind_port, cfg.CONF.bind_host,

                 workers=cfg.CONF.api_workers)

    # Dump all option values here after all options are parsed

    cfg.CONF.log_opt_values(LOG, std_logging.DEBUG)

    LOG.info(_("Neutron service started, listening on %(host)s:%(port)s"),

             {'host': cfg.CONF.bind_host,

              'port': cfg.CONF.bind_port})

    return server

至此，neutron server启动完成，之后，需要创建rpc服务端。

try:

            neutron_rpc = service.serve_rpc()

except NotImplementedError:

            LOG.info(_("RPC was already started in parent process by plugin."))

else:

            rpc_thread = pool.spawn(neutron_rpc.wait)

            rpc_thread.link(lambda gt: api_thread.kill())

            api_thread.link(lambda gt: rpc_thread.kill())

这些代码创建plugin的rpc服务端，并将api和rpc的生存绑定到一起，一个死掉，则另外一个也死掉。

pool.waitall()

最后是后台不断等待。

下图总结了neutron-server的核心启动过程。





openstack 怎启动实例

1. 使用命令：nova boot --flavor 1 --key_name mykey --image 9e5c2bee-0373-414c-b4af-b91b0246ad3b --security_group default cirrOS
其中：
flavor是虚拟机的配置，比如说内存大小，硬盘大小等，默认下1为最小，4为最大。
key_name是创建虚拟机使用的密钥，使用以下三条命令创建密钥：
ssh-keygen
cd .ssh
nova keypair-add --pub_key id_rsa.pub mykey
image是已上传镜像的ID，使用nova image-list查询。
security_group是安全组。
cirrOS是你所要创建的虚拟机名。

2.使用dashboard，dashboard创建实例很简单，选择项目，然后选云主机中的创建云主机，然后一步一步按照提示就行了。
 

openstack组件问题

OpenStack其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：
Swift——提供对象存储 （Object Storage），在概念上类似于Amazon S3服务，不过swift具有很强的扩展性、冗余和持久性，也兼容S3 API
Glance——提供虚机镜像（Image）存储和管理，包括了很多与Amazon AMI catalog相似的功能。（Glance的后台数据从最初的实践来看是存放在Swift的）。
Cinder——提供块存储（Block Storage），类似于Amazon的EBS块存储服务，目前仅给虚机挂载使用。
（Amazon一直是OpenStack设计之初的假象对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于AWS中的重要的EC2服务，OpenStack中是Nova来对应，并且保持和EC2 API的兼容性，有不同的方法可以实现）
三个组件中，Glance主要是虚机镜像的管理，所以相对简单；Swift作为对象存储已经很成熟，连CloudStack也支持它。Cinder是比较新出现的块存储，设计理念不错，并且和商业存储有结合的机会，所以厂商比较积极。
Swift
关于Swift的架构和部署讨论，除了官方网站，网上也有很多文章，这里就不重复.(也可以参考我之前在OpenStack中国行活动中上海站演讲的PPT)。从开发上看，最近也没有太大的结构性调整，所以我想主要说说比较适用的应用领域好了。
从我所了解的实际案例来看，Swift出现的领域有4个，(应该还有更多，希望大家看到实际用例能够指教)
1.网盘。
Swift的对称分布式架构和多proxy多节点的设计导致它从基因里就适合于多用户大并发的应用模式，最典型的应用莫过于类似Dropbox的网盘应用，Dropbox去年底已经突破一亿用户数，对于这种规模的访问，良好的架构设计是能够支撑的根本原因。
Swift的对称架构使得数据节点从逻辑上看处于同级别，每台节点上同时都具有数据和相关的元数据。并且元数据的核心数据结构使用的是哈希环，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。另外数据是无状态的，每个数据在磁盘上都是完整的存储。这几点综合起来保证了存储的本身的良好的扩展性。
另外和应用的结合上，Swift是说HTTP协议这种语言的，这使得应用和存储的交互变得简单，不需要考虑底层基础构架的细节，应用软件不需要进行任何的修改就可以让系统整体扩展到非常大的程度。
2.IaaS公有云
Swift在设计中的线性扩展，高并发和多租户支持等特性，使得它也非常适合做为IaaS的选择，公有云规模较大，更多的遇到大量虚机并发启动这种情况，所以对于虚机镜像的后台存储具体来说，实际上的挑战在于大数据（超过G）的并发读性能，Swift在OpenStack中一开始就是作为镜像库的后台存储，经过RACKSpace上千台机器的部署规模下的数年实践，Swift已经被证明是一个成熟的选择。
另外如果基于IaaS要提供上层的SaaS 服务，多租户是一个不可避免的问题，Swift的架构设计本身就是支持多租户的，这样对接起来更方便。
3.备份归档
RackSpace的主营业务就是数据的备份归档，所以Swift在这个领域也是久经考验，同时他们还延展出一种新业务--“热归档”。由于长尾效应，数据可能被调用的时间窗越来越长，热归档能够保证应用归档数据能够在分钟级别重新获取，和传统磁带机归档方案中的数小时......余下全文>>
 

相关内容