여기에 하나가 OpenStack은 핵심 구성 요소 설명의 51CTO O 버전에 게시 된 친구가, 요약 장소에, 그래서 나는 다시 최대되지 않습니다 바퀴가. ~, ~
Https://down.51cto.com/data/2448945
프라이빗 클라우드,
퍼블릭 클라우드
하이브리드 클라우드
의 IaaS (서비스로서의 인프라) : OpenStack은, CloudStack
PaaS를 (서비스로서의 플랫폼) : 부두 노동자, OpenShift
(서비스로 서비스)의 SaaS는 : 직면 브라우저를 통해 주요 최종 사용자는 하나를 사용하여 달성 할 수와 설치할 필요없이 응용 프로그램.
DBaaS (A 서비스 AS 데이터베이스)
FWaaS (A 서비스 AS 방화벽)
비동기 큐 서비스 : 같은 시간에 당신이 200 VM 인스턴스를 시작하려고 할 때 수신, 등을 작업 큐, 삭제, 시작, 만들 비동기 큐에 요청, 이후 나는 단순히 VM을 시작
내가 다른 일을 시작했다.
OpenStack은 구성 요소 :
OpenStack은 API를 스타일 : 편안하고, 그것은 AWS (아마존 클라우드), S3와 호환되는, 즉 OpenStack은 직접 AWS 응용 프로그램 또는 S3에 전화
응용 프로그램 OpenStack은이 AWS, S3에 직접 호출 될 수있을 매우 편리한 구성 요소 하이브리드.
핵심 구성 요소 :
1. 서비스 이름 : 계산 (코드 명 : 노바) : 그것은 주로 SSH 등의 연결을 제공, SSH 키 주입을 실행, 폐쇄 파괴, VM 인스턴스 시작, 자원 할당의 전체 라이프 사이클을 관리하는 데 사용됩니다, 그것에 의해 제공합니다.
2. 서비스 이름 : 네트워킹 (코드 명 : 중성자) : 초기, 즉 노바가 제공하는 계산에서, F 버전 (Folsom 보낸 자료)에서 독립 한 많은 인기 네트워크를 지원하기위한 플러그인을 사용하는 인터넷 접속 서비스를 제공하는 데 사용됩니다 관리 플러그인.
3.Storage : 두 가지 구성 요소, 블록 스토리지 (쇠 찌끼) 하나는, 다른 하나는 객체 저장 (스위프트)는
VM웨어 디스크 파일과 유사,하지만 VM웨어 디스크 파일 객체 저장, 객체 저장 : 개체 저장 그 자체가 자신의 메타 데이터를 포함, 심지어 디스크에는 파일 시스템을 넣어하지, 그것은 또한 자체 관리 할 수 있습니다. OpenStack은 스위프트 시스템의 개발 OpenStack은 초기 발기인 중 하나이기 때문에, 분산 스토리지 시스템을 사용 헤비급, 회사는 또한 시스템으로 오브젝트 스토리지를 OpenStack은 그들의 분산 스토리지 시스템을 기여 스위프트입니다.
객체 저장 : 코드 명 : 스위프트, 그것은 확장 성이 뛰어난 내결함성 스토리지 아키텍처이다 구조화되지 않은 데이터 객체를 저장하고 검색하는 편안하고 인터페이스를 통해입니다.
블록 스토리지 : 코드 명 : 신더 앞서 노바에 의해 제공되는, 즉 계산 요소는 독립 버전 F로부터는 VM 영구 저장 블록 조립체를 제공 주로위한 시작.
4. 코드 이름을 식별 : 디렉토리 서비스와 유사한 인증 및 서비스 카탈로그 서비스 엔드 포인트의 허가 자체를 제외한 다른 모든 구성 요소, 즉를 제공 키 스토어, 모든 구성 요소가 그것에 접근 경로를 검색 할 수 있습니다.
5. 이미지, 코드 이름 : 눈, 스토리지 오브젝트 메타 데이터를 검색 제공하기 위해 프런트 엔드 스위프트로 사용, 단순히 : 시작하기 전에, VM는 검색 할 이미지 서비스에 대한 액세스를 필요로, 디스크 이미지 파일이 무엇인지 알 필요가있다, 모든 정보는 스위프트 이미지 서비스에 저장 위치에 저장되고, 그 후, VMclient 후 자신을 찾을 이미지를 다운로드 어디로 VMclient을 알려드립니다.
6. 대시 (사용자 인터페이스) (수평선)는 웹 기반 액세스 인터페이스와 상호 작용 OpenStack은 구성 요소이다.
7. 원격 측정, 코드 명 : Ceilometer, VM 모니터링 및 측정, 측정 : 즉, 같은 VM 자원 사용자의 사용을 기반으로 충전 할 : 당신이 그렇게에 RAM, CPU, 네트워크 대역폭, 디스크 공간 및 사용 방법 많은.
8. Orachestration : 코드 명 : 열은 CloudFormation 템플릿 형식이나 더 빠르게 연결 AWS 자원을 이해하기 간단한 완전한 통일 서비스의 템플릿 형식을 기반으로 달성하기. 템플릿 기반의 시스템 관리
(9) 데이터베이스 : 코드 명 : 발견 물, 조립 DBaaS를 제공합니다.
10.Data 처리 : 코드 명 : 사하라 (사하라)는 OpenStack은 확장 가능한 하둡 관리 구현에 대한 수요.
도 1의 구성 요소 간의 상호 작용을 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网络组件的。