查看其它 2 个回答jxnxsdengyu的回答
这里说说我的看法
面对企业不同规模的云计算体系，如何设计云计算管理平台的架构是需要考虑的重点之一，按照之前的理论，云管平台的架构设计应该包括两个层面，云管平台统一资源层和云管平台服务管理层，对于统一资源层来说，面对的无论是大规模的云计算还是中小规模的云计算，我的想法是尽量用“分布式”的设计理念去实现：
这里不得不说下OpenStack的分布式的特性。OpenStack所有组件既可以采用all-in-one的方式存在一个控制节点中，各个组件也可以广泛分布于各个不同的控制节点中，只需保证节点间的通信即可；不仅如此，每种组件中的子组件也可存在多个，进行分布式部署，通过LoadBlance实现负载均衡；另外，对于all-in-one架构的控制节点，也可按照不同功能、分区甚至数据中心进行区分，组成多个全套的控制节点，这多个控制节点通过将Keystone认证信息和EndPoint链接注入至其中一个主控制节点当中，实现在该主控制节点统管所有资源，实际上部署却是分布式的，互不相干的。下面一一解释：
（1）资源层控制节点的组件all-in-one
云管平台资源层设计为所有OpenStack组件都集中在一个控制节点中，适用于计算节点和存储节点较少的场景，并且并发部署和管理的资源个数不宜太多。另外，由于只有一个控制节点，该节点的高可用也需要考虑，尤其是控制节点中的数据库，用数据库复制技术也可，还可以用双机软件，搭建Linux操作系统的双机实现高可用，如Keepalive、TSA或者Pacemaker等。
（2）组件或者子组件分布于不同控制节点
云管平台资源层设计为所有不同的组件和子组件均衡分布于不同的控制节点当中，如下图所示为资源层架构样例，相同组件的控制节点通过应用负载节点实现负载均衡（如HAProxy），实现ACTIVE-ACTIVE；RabbitMQ的消息控制节点则可通过自身的集群实现ACTIVE-ACTIVE，所有组件均通过RabbitMQ实现异步通信，同时为保证负载均衡和自动切换，组件配置了RabbitMQ的集群节点列表。数据库节点间可通过高可用软件+数据库复制技术实现ACTIVE-STANDBY，所有数据库的访问请求均通过虚拟服务IP实现。
不仅如此，每个控制节点当中的子组件设计也可以按照“分布式”的理念进行设计，如下图所示，同样是多个相同的子组件通过HAProxy实现负载均衡，组件内部的不同子组件间也均通过RabbitMQ集群进行异步的通信。
整个架构有几下优点：
A.当计算资源不够了无法创建虚机时，可以增加计算节点或者存储节点（增加Nova-Compute、Neutron-Agent和Cinder-Provider）。
B.当客户的请求量太大调度不过来时，可以增加Scheduler或者直接增加控制节点。
C.通过消息组件RabbitMQ的异步通信实现调用，一是可以解耦各子组件和组件，他们不需要知道其他组件在哪里运行，只需要发送消息给消息组件就能完成调用。二是提高了性能，异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。三是提高伸缩性，子组件和组件可以根据需要进行扩展，启动更多的控制节点处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他组件，也就是说变化对别人是透明的。
所以，该资源层的架构非常适合大规模和超大规模的云计算。
（3）多个all-in-one的控制节点功能分区
云管平台资源层的单个控制节点五脏俱全，包含了所需的所有组件，但每个控制节点的用途不一样，比如每个网络安全分区一个控制节点或者Power平台一个或多个控制节点，Vmware X86一个或多个控制节点，然后开源X86一个或多个控制节点，然后再搭建一个主控制节点，通过继承其他控制节点的KeyStone和EndPoint实现资源的接管，在主控制节点的Dashboard上通过切换不同Region实现管理的切换。通常商用私有云管平台喜欢采用这种架构，因为商用产品的软件会做得比较全，按照它的设计理念，面面俱到。但是这样如果部署在一个控制节点上，在资源规模比较大的情况下，不可避免地会产生性能瓶颈，可靠性也存在考验。如果按照不同功能进行分区的方式，则能起到立竿见影的效果，同时也可以实现统一管理的效果。比如下面商用私有云的架构（IBM Cloud Manager+IBM Cloud Orchestrator），不同功能的ICM控制节点分别管理不同的资源池，最后在逻辑上从属于主ICM，主ICM设计为高可用集群架构，其中的部分组件则采用了ACTIVE-ACTIVE的方式，均衡负载请求，实际上这个集群架构则为第二种架构模型，相当于在这个架构模型之上，再来了一层控制节点，增加了一层深度。和第二种架构模型的区别是，第二种架构组件的子组件也可以采用分布式部署方式，而该架构只能是所有组件all-in-one。这种架构由于也是“分布式”，可适用的资源规模也可以非常大，但显然没有第二种架构灵活性高。
