ここで1は、OpenStackのコア・コンポーネント記述の51CTO O版に掲載友人があり、要約が整備されているので、私は再起動していないだろう車輪を。〜、〜
Https://down.51cto.com/data/2448945
プライベートクラウド、
パブリッククラウド
、ハイブリッドクラウド
のIaaS（サービスとしてのインフラストラクチャ）：OpenStackは、CloudStackの
PaaSの（サービスとしてのプラットフォーム）：ドッカー、OpenShift
のSaaS（サービスとしてのサービス）：ブラウザを通じて主要なエンドユーザーに直面したが、いずれかを使用して達成することができますインストールすることなくアプリケーション、。
DBaaS（サービスとしてのデータベース）
FWaaS（サービスとしてのファイアウォール）
非同期キューサービス：受信と同時に、あなたが200 VMインスタンスを開始したいときなど、タスクキューを作成、起動、削除、私は単純に、非同期キューに要求した後にVMを起動し、
私は他のことをやって始めました。
OpenStackの成分：
OpenStackのAPIスタイル：RESTfulな、それはAWS（アマゾンクラウド）、S3と互換性があり、すなわちOpenStackの直接AWSアプリケーションまたはS3に、呼び出し
アプリケーションOpenStackのがAWS、S3に直接呼び出すことができる、ことが非常に便利なコンポーネントハイブリッド。
コアコンポーネント：
1.サービス名：計算（コード名：ノヴァ）：主に、SSHなどの接続を提供し、SSHキー注入を実行し、破壊し、VMインスタンスの完全なライフサイクルを管理するために使用を開始、リソースの割り当て、閉じています、それにより提供します。
2.サービス名：ネットワーキング（コード名：中性子）：初期、ノヴァが提供する、すなわち計算は、Fバージョン（フォルサムリリース）から独立しましたが、多くの一般的なネットワークをサポートするように設計されたプラグインを使用してインターネット接続サービスを提供するために使用されます管理プラグイン。
3.Storage 2つのコンポーネント、ブロックストレージ（燃えがら）のための1つは、他のオブジェクトストレージ（SWIFT）は
、VMwareのディスクファイルと同様ではなく、VMwareのディスク・ファイル・オブジェクト・ストレージ、オブジェクトストレージ：オブジェクトストレージ自身が独自のメタデータが含まれていることを、してもディスク上にファイルシステムをそれを入れていない、それはまた、自己管理することができます。システムの開発は、OpenStackの初期プロモーターの一つであるため、OpenStackのスウィフトは、分散ストレージシステムを使用してヘビー級、と同社はまた、そのシステムとしてOpenStackのオブジェクトストレージへの分散ストレージシステムに貢献しますスウィフトです。
オブジェクトストレージ：コード名：スウィフト、それは非常にスケーラブルなフォールトトレラント・ストレージ・アーキテクチャである非構造化データオブジェクトを格納および取得するためにRESTfulなインターフェースを介して行われます。
ブロックストレージ：コード名：VMは、永続ストレージ・ブロック・アセンブリを提供するために、以前のノバによって提供燃えがら、すなわち計算コンポーネントは、独立したバージョンFから始め、それが主です。
4.コード名を特定しますディレクトリサービスに類似した認証とサービスカタログ・サービス・エンドポイントの承認と自身を除く他のすべてのコンポーネント、すなわちを提供キーストアを、すべてのコンポーネントは、それへのアクセスパスによって取得することができます。
5.画像、コード名：概要は、取り出さストレージオブジェクトのメタデータを提供するために、フロントエンド・スウィフトとして使用され、それは単に：開始する前に、VMはそれを取得するために、イメージ・サービスへのアクセスを必要とする、ディスクイメージファイルがあるかを知る必要があり、すべての情報は、スウィフトイメージ・サービス上の保存場所に保存されている、それは、その後、VMclientはその後、自分自身を見つけるのイメージをダウンロードするために行くためにどこVMclientを教えてくれます。
6.ダッシュボード（ユーザー・インターフェース）（ホライゾン）：これは、Webベースのアクセスインタフェースと対話OpenStackの成分です。
7.テレメトリ、コード名：雲高計、VMの監視と計測、計測：どのくらいあなたがそうでRAM、CPU、ネットワーク帯域幅、ディスクスペースとを使用します。それは、次のようなVMのリソース利用者の使用に基づいて充電すること、です。
8. Orachestration：コード名：熱、より迅速にCloudFormationテンプレート形式またはAWSリソースのテンプレート形式に基づいて達成するためにアップリンクし、理解することは簡単で完全な統一サービス：テンプレートベースのシステム管理
9.データベース：コード名：トローブ、組立DBaaSを提供します。
10.Data処理：コード名：サハラ（サハラ砂漠）、OpenStackのでスケーラブルなHadoopの管理の実装のための需要。
図の構成要素間の相互作用をOpenStackの。
各组件间交互的简略描述:
1.通过Dashboard/CLI(OpenStack命令行接口)/自己开发的创建VM的界面,要启动VM,需先到Keystore认证并登录,接着用获得的Token,来访问Nova-API.
2.Nova-API它是接收用户请求的调用接口,它需要监听在一个套接字上,来通过TCP/IP协议来访问.当Dashboard/CLI发过来请求后,Nova-API会先验证它的Token是否合法,若合法则接收请求。接着向Nova-DB(MySQL)请求查询该VM,Nova-DB从已创建的VM中查询,若有要启动的VM则获取该VM的信息(如:实例名/RAM大小/CPU/磁盘等信息),并将这些信息返回给Nova-API。
3.当Nova-API获得的VM的信息后,Nova-API会将该VM信息组织成Hypervisor或Nova-compute上借助Hypervisor来操作VM的特定请求包,并发送给Hypervisor或Nova-compute,由它来负责操作VM, Nova-API和Nova-compute的交互是异步的,它们中间隔着一个队列.;
【注: Nova-API它仅是用来接收VM操作请求,验证是否有权限操作VM,并获取VM信息交给Hypervisor来完成VM的实际管理操作.】
4.Nova-API将特定请求包丢入队列后,Nova-Scheduler会获得这些请求,并为该请求调度选择运行节点,完成后,Nova-scheduler会将该调度信息再次丢入队列中,同时向Nova-DB发送VM已启动的更新信息,Nova-DB更新完该VM的状态后,会通知Nova-scheduler.
5.Nova-compute可以看成是具体的一个物理实体机,它会从队列中获取Nova-scheduler发出的调度信息,并判断是否是自己的任务,若是则获取该启动VM的任务,并生成VM的已在启动中的状态信息,在丢入队列中。
6.当Nova-conductor发现Nova-compute丢入队列中的VM状态更新信息后,它会读取该信息,并将该信息发给Nova-DB来更新该VM的状态,当Nova-DB更新完成后，Nova-DB会通知Nova-conductor,接着Nova-conductor会将该信息丢入队列,当Nova-compute检测到Nova-conductor丢入的更新成功的信息后，Nova-compute便开始进行接下来的VM启动步骤。
7.当知道VM更新信息已经完成后,Nova-compute开始向glance-API请求启动该VM的磁盘镜像,这时glance-API会先从通过glance-registry来查询glance-DB看是否存在该VM的磁盘信息,若有则glance-registry会将该磁盘镜像信息返回给glance-API,然后，glance-API会先到Keystore验证该Nova-compute提供的Token是否合法,若合法,则通过该VM磁盘镜像信息到Image Store中去下载该VM启动的磁盘镜像文件,并返回给Nova-compute。
8.quantum-server: 它是负责为VM创建网络基础设施的,如:构建虚拟网桥,虚拟路由器并添加相应转发规则,甚至是NAT; quantum-server是一个非常繁忙的系统,因为它需要为每个VM创建网络基础设施,但quantum-server并不直接为VM创建网络基础设施,而是将请求丢入到quantum子系统内部的队列中。
9.相应的quantum-plugin会从quantum子系统内部的队列中读取构建网络设施的信息,并通过查询Quantum-DB来判断那些部分在真正运行VM的Nova-compute上创建(如:创建网桥就需要在本地创建.)，那些在quantum上创建,若需要在运行VM的节点上创建,则quantum-plugin会将这些信息丢入内部队列中，Nova-compute上运行的quantum-agent会从quantum内部队列中获得这些信息,并在本地创建相应的网络基础设施，完成后，quantum-agent会将完成信息发送给Quantum-DB来更新该网络基础设施的状态信息。【注:quantum-server也会在收到Nova-compute的请求到Keystore上去验证是否有合法。】最后，quantum-server会通告Nova-compute网络已经构建完成。
10.Nova-compute会从获得的启动VM的信息中看是否需要加载它曾经关联过的Block设备,若有则向cinder-API发起请求,cinder-API会先将请求信息发给cinder-volume,由它来查询Cinder-DB看是否存在Nova-compute请求的Block设备,若有则cinder-volume会通知cinder-API,cinder-API在向Keystore发起验证请求,验证通过后，cinder-api会直接将Block设备信息返回给nova-compute,若这是一个创建Block的请求，则cinder-volume会将Block信息丢入cinder内部队列中,由cinder-scheduler从cinder-DB中获取后端存储的信息，并根据要创建Volume的大小，VolumeType，所需具有的特性等信息，从后端存储主机中选出一个最匹配的，并将结果写入cinder队列中，cinder-volume通过该信息在存储节点上调用相应的存储驱动创建volume，创建完成后将这些信息写入cinder-db中，最后cinder-volume告诉cinder-api，cinder-api在返回信息给nove-compute.
Controller Node + Network Node + Compute Node 这种三节点OpenStack架构是OpenStack的最小结构。
Controller Node:
基础服务：
1.Identity(认证)服务。即Keystore
2.Image Service.
3.compute的Nova Management。
4.Networking: Neutron server, ML2 Plug-in.
5.Dashboard ：图形管理界面
支持服务:
1.Database MySQL or MariaDB
2.Message Broker: RabbitMQ or Qpid，它是用来为基础服务和数据库连接提供缓存区的。
它至少需要一个网卡接口，来作为管理接口。
1.需要注意: 若需要向外网提供公有云服务,则应该还需要改Controller Node提供一个外网访问网卡.
以便外部可调用Cinder提供的Block Storage或Object Storage，以及Image Service.
Network Node:
需要提供基础的Networking服务,该服务包含:
ML2 Plug-in(第二层插件),
Layer2 Agent(第二层代理:OVS): OVS是用来构建桥、VLAN、VxLAN、GRE、与Network Node节点通信均有它来完成。
Layer3 Agent(第三层代理):创建NAT NS并构建NAT规则,iptables过滤规则、路由转发规则等
DHCP Agent:用来提供DHCP服务,为VM提供动态地址分配管理。
它需要提供三个网卡接口:
1.Management 接口。
2.与实例构建隧道的接口.
3.与外网连接的接口。
Compute Node:
它是运行VM的基本节点。它可以有非常多。
它需要运行的基础服务：
1.Compute(计算服务):Nova Hypervisor; KVM or QEMU
2.Networking: ML2 Plug-in, Layer2 Agent(OVS)
它需要两个网卡接口:
1. Management接口
2.构建Tunnel的接口。
控制节点需要哪些必要组件？
对于控制节点来说，最主要的组件有 nova（nova-api, nova-sheduler,nova-conductor等），neutron-server(neutron的二层，三层，元数据代理)，Glance(镜像服务)，keystone(认证服务)，通常也都会部署cinder服务，因此控制节点一般这些基础服务端进程是需要运行在控制节点的，但有时也需要使用想manila，heat这些服务，也需要在控制节点部署，但heat我研究不多，我的实践中，nova，neutron，glance，keystone，cinder是必须要配置的，像我们启动一台VM，首先就要访问nova-api，由nova-api来访问keystone验证用户提供的凭据，身份验证通过后，才会将请求做进一步处理，比如说要创建VM，nova-api就会将请求发给nova-sheduler,而它会查询nova数据库，获取当前所有计算节点上资源的使用情况，并根据调度算法，选出一个最佳的计算节点，并将创建VM的请求发送到对应的消息队列的管道中，这样所有订阅了这个管道的计算节点上的nova-compute就都能收到，并解析请求，若是自己的任务，就会在自己的节点上启动创建VM的任务，当然这个过程涉及到了前面提到的所有组件，比如它会先访问glance获取创建VM的镜像，随后访问neurton创建必须的网络，最后还会访问cinder获取VM所需要挂载的云盘信息等等，最后还要通知nova-conductor将VM的启动状态写入nova数据库中，当然这启动之初就会先告知nova-conductor，这样我们在前端Dashboard上才能看到VM的启动状态到那一步了，所以状态报告是每个阶段都需要有的. 另外像neutron，它通常会在用户创建网络时，如二层网络，或虚拟路由器等，会由neutron-server通过消息队列通知各个计算节点上的neutron-代理来完成计算节点上基础虚拟网桥的创建。
另外我在实践中发现，像消息队列服务,通常使用rabbitmq，缓存及Session保持常用memcached，数据库通常用Mariadb，并且这三个服务最好分别部署，一般部署测试环境时，会将它们单独放到一台主机上来部署，前面用HAProxy或Nginx+Keepalived，这样部署会尽可能降低消息队列，缓存及数据库的压力，降低瓶颈，不会出现mysql挂了，所有服务都不能正常工作，mysql做双主会多些，但使用时，还按照主从方式用.
计算节点通常需要哪些组件？
对于计算节点来说，通常需要运行nova-compute,这是最基本的，因为控制节点上nova-api验证用户完用户身份后，就以创建VM为例来说，它会将创建VM的任务交给nova-scheduler，由它来从查询nova数据库获取每个计算节点的信息,比如内存,磁盘,CPU等信息,找一个资源最富裕的计算节点,并通过消息队列,通知给订阅了该消息通道的nova-compute，nova-compute就需要在当前计算节点与底层的hapyervsior通信，不过基本是跟libvirtd通信，因为libvirtd已经统一了底层绝大部分haypervsior,在Linux上通常做IaaS层面的私有云，首选通常是KVM+Qume，不过若硬件不支持虚拟化，就只能使用Qume这种模拟器了，不过对于服务器来说这是不可能的。能创建VM，但也必须让用户能访问它才行，所以，neutron的代理是必须要安装的，neutron就是通过如linuxbridge-agent,ovs-agent这些计算节点上的网络代理来实现接受neutron-server通过消息队列发来的创建虚拟网络的指令，这样计算节点上就可以创建二层网桥，并自动将虚拟网线的一端安装到VM中，另一段连接到网桥上，当然若使用安全组，VM和虚拟网络之间就还需要一个网络名称空间来做安全策略，这样就可以能让VM连接的隧道网络上了，通常不会直接让VM连接的公网桥上的，而是通过tunnel network连接到Neutron-server端，在通过NAT来让VM上网的，但对于VM的远程管理，就比较复杂了，这一块主要涉及到nova的几个主要组件计算节点上的nova-compute,控制节点上的nova-consoleauth,nova-novncproxy，nova-api他们之间经过复杂交换，生成token，转换URL为公网可访问的URL，最后返回给用户的浏览器，最终用户才得以看到VM的管理控制台，这期间是不涉及neutron网络组件的。