クラウドコンピューティングサービスをOpenStackの-Nova共有コンポーネント(5)

、新星紹介:

      OpenStackの新星は、クラウドコンピューティングリソース環境の維持・管理を担当するサービスの中核です。OpenStackのIaaSのクラウドオペレーティングシステムとして、仮想マシンのライフサイクル管理は、ノヴァによって達成されます。
 
用途・機能:
1)ライフサイクル管理の例
コンピューティング・リソースの2)管理
3)ネットワーク管理と認証
4)RESTスタイルのAPI
5)一貫非同期通信
6)ハイパーバイザ透明:サポートのXen、XenServerの/ XCP、KVM、UMLは、VMwareのvSphereおよびHyper-V
 
概要迅速かつ提供する画像シンダーブロックが提供され、VMのネットワーク接続を提供するために、オブジェクトストア中性子VM VMとして記憶されている:中心における新星Openstakアーキテクチャは、他の成分ノバのためのサポートを提供します。
新星-API
ノヴァは、受信したクライアントAPIの呼び出しに応答、アセンブリ全体へのゲートウェイです。すべての要求は、最初にノヴァのnova-APIによって処理されています。HTTP REST APIインターフェースキーストーンの数にさらさ新星-API私たちは外の世界にendponitsの新星-APIを照会することができます。
b)の新星、コンピューティング:
仮想マシン管理をノバ - 計算の計算ノード上で実行されている、コアサービスです。ノードのインスタンスのハイパーバイザーAPIのライフサイクル管理を呼び出すことによって。インスタンス上で、最終的に新星・コンピューティングへのOpenStackの操作が行われます。インスタンス新星・コンピューティングとハイパーバイザのためのライフサイクル管理を実現するために一緒にOpenStackの。
仮想マシンのデフォルトのパスに保存されたOpenStackの場合:/ var / libに/ノヴァ/インスタンス
ハイパーバイザは、コンピューティングノードハイパーバイザ、底VMハイパーバイザ上で実行されています。異なる仮想化技術は、独自のハイパーバイザーを提供しています。一般的に使用されるハイパーバイザーは、その上のKVM、Xenのは、VMwareとしています。これらのHypervisorが統一されたインタフェースを定義新星、計算、ハイパーバイザは、あなたがプラグ・アンド・ドライバーOpenStackのシステムの形に再生することができ、これらのインタフェースを実装する必要があります。
C)新星導体。
データベースの新星、計算などの仮想マシンの状態を更新し、取得など、頻繁に更新する必要があります。セキュリティとスケーラビリティの理由から、新星・コンピューティングは、データベースに直接アクセスしませんが、新星-導体にこの作業を委託します。
 
クライアントは、アドレス指定されたendponitsに要求を送信新星-APIに操作を要求することができます。もちろん、私たちは、最終的なユーザーの要求休憩AP I.として直接ません OpenStackのCLI、ダッシュボードおよびその他のコンポーネントは、これらのAPIを使用しますノヴァと交換する必要があります。
 
ノヴァ-APIは次のようにHTTPのAPIリクエストが処理されます受け取りました。
クライアントが有効なパラメータを渡すかどうかをチェックします
2.コールノヴァ他のサブサービス処理クライアントのHTTP要求
3.フォーマットノヴァ他のサブサービスの結果が返され、クライアントに返さ
a)の新星、スケジューラ:
仮想マシンのスケジューリングサービスは、仮想マシン上の計算ノードを実行することを決定する責任があります。インスタンスを作成すると、ユーザーは、CPU、メモリ、ディスクなどのリソース要件、どのくらいの各ニーズを提示します。OpenStackのこれらの要件は、味に定義されている、ユーザーはそれだけでその味を指定する必要があります。
フィルタースケジューラ
フィルタスケジューラ新星・スケジューラはデフォルトのスケジューラで、スケジューリングプロセスは、2つの段階に分かれています。
1. 通过过滤器(filter)选择满足条件的计算节点(运行 nova-compute)
2. 通过权重计算(weighting)选择在最优(权重值最大)的计算节点上创建 Instance
Scheduler 会对每个计算节点打分,得分最高的获胜。 打分的过程就是 weight,翻译过来就是计算权重值,那么 scheduler 是根据什么来计算权重值呢? 
目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值: 空闲内存越多,权重越大,instance 将被部署到当前空闲内存最多的计算节点上。
这样做有两个显著好处:
1. 更高的系统安全性
2. 更好的系统伸缩性
Console Interface
nova-console: 用户可以通过多种方式访问虚机的控制台:
nova-novncproxy: 基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy: 基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy: 基于 Java 客户端的 VNC 访问
nova-consoleauth: 负责对访问虚机控制台请求提供 Token 认证
nova-cert: 提供 x509 证书支持
Database
Nova 会有一些数据需要存放到数据库中,一般使用 MySQL。数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。
Message Queue
在前面我们了解到 Nova 包含众多的子服务,这些子服务之间需要相互协调和通信。为解耦各个子服务,Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线,是通过 Message Queue 联系的。
OpenStack 默认是用 RabbitMQ 作为 Message Queue。 MQ 是 OpenStack 的核心基础组件
二、Nova 组件如何协同工作
penStack 是一个分布式系统,可以部署到若干节点上,那么接下来大家可能就会问:Nova 的这些服务在物理上应该如何部署呢?
计算节点上安装了 Hypervisor,上面运行虚拟机。 由此可知:
1. 只有 nova-compute 需要放在计算节点上。
2. 其他子服务则是放在控制节点上的。
ps -elf | grep nova 来查看运行的 nova 子服务
RabbitMQ 和 MySQL 也是放在控制节点上的。可能细心的同学已经发现我们的控制节点上也运行了 nova-compute。 这实际上也就意味着 devstack-controller 既是一个控制节点,同时也是一个计算节点,也可以在上面运行虚机。
penStack 这种分布式架构部署上的灵活性: 可以将所有服务都放在一台物理机上,作为一个 All-in-One 的测试环境; 也可以将服务部署在多台物理机上,获得更好的性能和高可用。
也可以用 nova service-list 查看 nova-* 子服务都分布在哪些节点上
从虚机创建流程看 nova-* 子服务如何协同工作
1.客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“帮我创建一个虚机”
2.API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:“让 Scheduler 创建一个虚机”
3.Scheduler(nova-scheduler)从 Messaging 获取到 API 发给它的消息,然后执行调度算法,从若干计算节点中选出节点 A
4.Scheduler 向 Messaging 发送了一条消息:“在计算节点 A 上创建这个虚机”
5.计算节点 A 的 Compute(nova-compute)从 Messaging 中获取到 Scheduler 发给它的消息,然后在本节点的 Hypervisor 上启动虚机。
6.在虚机创建的过程中,Compute 如果需要查询或更新数据库信息,会通过 Messaging 向 Conductor(nova-conductor)发送消息,Conductor 负责数据库访问。
三、Nova 创建虚拟机详细过程
 

1、界面或命令行通过RESTful API向keystone获取认证信息。

2、keystone通过用户请求认证信息,并生成auth-token返回给对应的认证请求。

3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求(携带auth-token)。

4、nova-api接受请求后向keystone发送认证请求,查看token是否为有效用户和token。

5、keystone验证token是否有效,如有效则返回有效的认证和对应的角色(注:有些操作需要有角色权限才能操作)。

6、通过认证后nova-api和数据库通讯。

7、初始化新建虚拟机的数据库记录。

8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。

9、nova-scheduler进程侦听消息队列,获取nova-api的请求。

10、nova-scheduler通过查询nova数据库中计算资源的情况,并通过调度算法计算符合虚拟机创建需要的主机。

11、对于有符合虚拟机创建的主机,nova-scheduler更新数据库中虚拟机对应的物理主机信息。

12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。(Flavor)

15、nova-conductor从消息队队列中拿到nova-compute请求消息。

16、nova-conductor根据消息查询虚拟机对应的信息。

17、nova-conductor从数据库中获得虚拟机对应信息。

18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

19、nova-compute从对应的消息队列中获取虚拟机信息消息。

20、nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

21、glance-api向keystone认证token是否有效,并返回验证结果。

22、token验证通过,nova-compute获得虚拟机镜像信息(URL)。

23、nova-compute通过keystone的RESTfull API拿到认证k的token,并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

24、neutron-server向keystone认证token是否有效,并返回验证结果。

25、token验证通过,nova-compute获得虚拟机网络信息。

26、nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

27、cinder-api向keystone认证token是否有效,并返回验证结果。

28、token验证通过,nova-compute获得虚拟机持久化存储信息。

29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

四、彻底删除nova-compute节点
1、1、控制节点上操作查看计算节点,删除node1
(1).openstack host list
(2).nova service-list
2.将node1上的计算服务设置为down,然后disabled
(1).systemctl stop openstack-nova-compute
(2).nova service-list
(3).nova service-disable node1 nova-compute
(4).nova service-list
3、在数据库里清理(nova库)
(1).删除数据库中的node1节点信息
五、nova配置文件:
[DEFAULT]
my_ip=172.16.254.63
use_neutron = True
firewall_driver = nova.virt.firewall.NoopFirewallDriver
enabled_apis=osapi_compute,metadata
 
[api]
auth_strategy = keystone
 
[api_database]
 
[barbican]
 
[cache]
 
[cells]
 
[cinder]
os_region_name = RegionOne
 
[cloudpipe]
 
[conductor]
 
[console]
 
[consoleauth]
 
[cors]
 
[cors.subdomain]
 
[crypto]
 
[database]
 
[ephemeral_storage_encryption]
 
[filter_scheduler]
 
[glance]
api_servers =  http://controller:9292
 
[guestfs]
 
[healthcheck]
 
[hyperv]
 
[image_file_url]
 
[ironic]
 
[key_manager]
 
[keystone_authtoken]
auth_uri =  http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = nova
 
[libvirt]
virt_type=qemu
 
[matchmaker_redis]
 
[metrics]
 
[mks]
 
[neutron]
auth_type = password
project_domain_name = default
user_domain_name = default
region_name = RegionOne
project_name = service
username = neutron
password = neutron
service_metadata_proxy = true
metadata_proxy_shared_secret = METADATA_SECRET
 
[notifications]
 
[osapi_v21]
 
[oslo_concurrency]
lock_path=/var/lib/nova/tmp
 
[oslo_messaging_amqp]
 
[oslo_messaging_kafka]
 
[oslo_messaging_notifications]
 
[oslo_messaging_rabbit]
 
[oslo_messaging_zmq]
 
[oslo_middleware]
 
[oslo_policy]
 
[pci]
[placement]
os_region_name = RegionOne
auth_type = password
project_name = service
project_domain_name = Default
username = placement
password = placement
user_domain_name = Default
 
[quota]
 
[rdp]
 
[remote_debug]
 
[scheduler]
 
[serial_console]
 
[service_user]
 
[spice]
 
[ssl]
 
[trusted_computing]
 
[upgrade_levels]
 
[vendordata_dynamic_auth]
 
[vmware]
 
[vnc]
enabled=true
vncserver_listen=$my_ip
vncserver_proxyclient_address=$my_ip
novncproxy_base_url =  http://172.16.254.63:6080/vnc_auto.html
 
[workarounds]
 
[wsgi]
 
[xenserver]
 
[xvp]

おすすめ

転載: www.cnblogs.com/kittywerwer/p/11700506.html