设为首页 收藏本站
查看: 1259|回复: 0

[经验分享] OpenStack overview 笔记

[复制链接]

尚未签到

发表于 2017-6-24 22:45:49 | 显示全部楼层 |阅读模式
  Example architecture
  example architecture 至少需要两个节点启动一个虚拟机或者实例。可选的服务,例如Block storage和Object storage需要额外的节点。example architecture和minimal production architecture的区别如下所示:
  (1)、Networking agent存在于controller node中,而不是一个或多个独立的network nodes
  (2)、对于self-service network的Overlay(tunnel)是走management network而不是dedicated network
  Controller
  Controller node运行identify service, image service, networking的管理部分,各种networking agents和dashbord。其中还可以包括很多supporting service,例如SQL 数据库,消息队列和NTP
  事实上,controller node还可以运行block storage,object storage,orchestration和telemetry service。最后,controller node 需要至少两个网卡
  Compute
compute node运行compute的hypervisor部分用于操作虚拟机实例。默认情况下,Compute使用KVM作为hypervisor。compute node还要运行networking service agent,它能将虚拟机连接到虚拟网络中,并且给虚拟机提供firewalling service。我们可以部署多个compute node,每个node需要至少两个网卡。
  Block Storage
  Block Storage node是可选的,其中包含了为虚拟机提供的Blocke storage和Shared File System service的磁盘。为了简单起见,compute node和本节点是使用management network进行通信的。在生产环境中需要提供专有的网络用于提高性能和安全性。我们可以部署多个block storage node,每个node至少需要一个网卡
  Object Storage
  Object Storage node是可选的,其中存放了Object Storage service的磁盘用于存放accounts,containers以及object。和Block node类似,为了简单起见,compute node和本节点直接是使用management network进行通信的。但是在生产环境中,需要实现专有的网络用于通信。该服务需要至少两个节点,每个node至少需要包含一个网卡。
  Networking
  Networking Option 1:Provider networks
  Provider networks 用的是最简单的OpenStack Networking service部署方案,提供了基本的layer-2(birdging/switching)services和VLAN segmentation of networks。本质上,它将虚拟网络和物理网络相连,并且依赖物理网络的基础设施来提供layer-3(routing) services。另外,DHCP service为虚拟机提供IP信息
  Networking Option 2:Self-service networks
  self-service networks 在provider networks的基础上提供了layer-3(routing) service,主要是利用overlay segmentation methods,例如VXLAN实现的。事实上,它通过NAT将虚拟网络路由到物理网络。另外,这种network option提供了一些高级的服务,例如LBaas和FWaas。
  Identity service
  OpenStack的Identity service提供了对于管理认证,授权,以及service目录的单点集成。Identity service通常是用户解除的第一个service,一旦通过认证,端用户就能通过它们的identity去获取OpenStack service。同样,其他的OpenStack services利用Identity service来确认用户,以及发现其他service部署在什么地方。Identity service还能和其他的外部用户管理系统集成(例如LDAP)。
  用户和service能够通过service目录获取其他目录的位置。如名字所示,service目录是OpenStack集群上可用的service的集合。每个service都可以有一个或多个endpoint,每个endpoint都是admin, internal或者public三个类型中的一种。在生产环境中,不同的endpoint类型会存在于不同的network中,因为处于安全的考虑,不同的类型是有不同的network的。比如,public API network在Internet上是可见的,从而用户能管理他们的云。而admin API network可能仅仅局限于那些云基础设施的管理者。internal API network则局限于那些运行着OpenStack service的主机。为了扩展性,OpenStack支持多region,但是出于简单起见,我们对于所有的类型都使用同一网络并且使用默认的RegionOne region。总之,Identity service中创建的region,service和endpoint构成了集群中的service目录。对于每一个OpenStack service,都需要在Identity service中存放一个伴有相应endpoint的service entry。这些都能在Identity service安装和配置好之后完成。
  Identity service由以下组件组成:
  Server:一个中心化的server提供使用RESTful接口的授权和认证
  Drivers:drivers或者service back end是和中心化server集成的。它们是用于为OpenStack外部的库提供identity信息的,并且可能在OpenStack还在部署的时候就已经存在了。
  Modules:OpenStack组件地址空间上运行的Middleware module也使用identity service。这些modules解析service request,抽取出user credentials,并且将它们发送给中心server用于授权。Middleware和OpenStack组件之间通过Python Web Server Gateway Interface进行通信。
  Image service
  Image service能够让用户发现,注册,检索虚拟机镜像。它提供了一个REST API,从而让你能查询虚拟机镜像的元数据以及检索实际的镜像。我们可以将虚拟机镜像存放在各种地方,从简单的文件系统到像OpenStack Object Storage的对象存储系统
  为了简单起见,我们使用file back end来配置image service,即将镜像存放在运行image service的controller node的目录中。默认情况下,该目录为/var/lib/glance/images/。在进行操作之前,我们需要确保在controller node中的相应目录至少有几个G的存储空间。需要注意的是,file back end通常是在controller node的本地的,而这对于多节点的部署显然是不合适的。
  OpenStack的image service位于IAAS的中心。它接收来自端用户或者OpenStack计算组件对于磁盘,服务镜像以及元数据定义的API请求。同时,它还支持磁盘存储,多种类型的服务镜像,包括OpenStack Object Storage。OpenStack image service上有一定数目的周期性运行的进程用于支持caching。Replication services用来确保集群的一致性和可用性。其他周期性运行的进程包括,auditors, updaters,reapers。
  glance-api:接收镜像API调用,包括镜像发现,检索和存储
  glance-registry:存储,处理和恢复镜像的元数据。元数据包括大小和类型。(注:registry是OpenStack image service的一个private internal service,不能将它暴露给用户)
  Database:用于存储镜像的元数据,我们可以根据自己的偏好任意选择数据库。大多数部署使用MySQL或者SQLite
  Storage repository for image files:OpenStack支持各种各样的repository type,包括普通的文件系统(或者任何挂载在glance-api所在的controller node上的文件系统),对象存储,RADOS块设备,VMware数据库以及HTTP。需要注意的是,一些repository只支持只读。
  Metadata definition service:一个通用的API用于为vendor,admins,service,以及user定义它们自己的元数据。这些元数据可以被用于不同类型的资源,例如images,artifacts,volumes,flavors以及aggregates。一个标准的定义通常包括,新特性的键值,描述,约束以及相关的资源类型。
  Compute service overview
  使用OpenStack Compute管理云计算系统。OpenStack Compute是IAAS系统的主要部分。它的主要部分是由Python实现的。OpenStack Compute通过和OpenStack Identity交互来进行认证;和OpenStack image service交互用于磁盘和服务镜像;和OpenStack dashboard交互用于user和administrative的接口。镜像的访问受项目和用户的限制,配额则受到项目的限制(例如实例的数目)。OpenStack Compute可以在标准硬件上水平扩展,并且下载镜像来生成实例。
  OpenStack Compute由以下这些组件构成:
  nova-api service:用于接收以及回复端用户的compute API调用,该service支持OpenStack Compute API,Amazon EC2 API,以及special Admin API为特权用户执行管理员操作。它强行执行一些策略,以及初始化大多数的编排操作,例如运行一个实例。
  nova-api-metadata service:接收来自实例的元数据请求。nova-api-metadata service通常在运行multi-host模式并且安装了nova-network的时候使用。
  nova-compute service:一个worker daemon通过hypervisor API创建并且终止虚拟机实例。比如:XenAPI for XenServer/XCP,libvirt for KVM or QEMU,VMware for VMware。
  处理的过程是非常复杂的。通常,daemon从队列中接收指令,再执行一系列的系统命令,例如启动一个KVM实例,以及更新它在数据库中的状态。
  nova-scheduler service:从队列中获取一个虚拟机实例请求,并且决定在哪个compute server上运行。
  nova-conductor module:nova-compute service和数据库的中介。它限制了nova-compute service对于云数据库的直接访问。nova-conductor module可以水平扩展。然而不要将它部署在运行nova-compute service运行的节点上。
  nova-cert module:用于提供X509 certificate Nova Cert service的server daemon。用于为euca-bundle-image生成证书。只在EC2 API中使用。
  nova-network worker daemon:和nova-compute service类似,从队列中接收并处理networking tasks。执行例如设置网桥接口或者改变IPtables 规则等任务。
  nova-consoleauth daemon:验证console proxies提供的tokens。参见nova-novncproxy和nova-xvpvncproxy。如果要console proxies能正常工作,这个service必须运行。在集群配置了单个的nova-consoleauth就能运行两个proxy中的任意一个。
  nova-novncproxy daemon:为通过VNC连接一个运行实例提供代理。支持基于浏览器的novnc客户端。
  nova-spicehtml5proxy daemon:为通过SPICE连接一个运行实例提供代理。支持基于浏览器的HTML5客户端。
  nova-xvpvncproxy daemon:为通过VNC连接一个运行实例提供代理。支持OpenStack的Java客户端。
  nova-cert daemon:x509证书。
  nova client:使用户能够作为租户管理员或者端用户提交请求
  The queue:用于daemon之间传递数据的central hub。通常通过RabbitMQ实现,也能通过另外的例如AMQP消息队列实现,例如ZeroMQ。
  SQL database:用于存储大多数云基础设施的build-time和run-time状态,包括:可用的实例类型,正在使用的实例,可用的网络,Project。
  理论上来说,OpenStack Compute能支持任何SQL-Alchemy支持的数据库。通用的数据库为SQLite3,用于测试和开发工作,MySQL,MariaDB和PostgreSQL。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-387738-1-1.html 上篇帖子: libvirt笔记(未完待续) 下篇帖子: linux 内核---------董昊 ( Robin Dong ) and OenHan
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表