基础架构模型是需要根据业务模型设计的，接下来笔者以OpenStack基础架构为例，首先介绍适用性较广的通用型设计，然后以其为基础拓展至计算或存储密集型的设计。
另外，在部署工具的选择上，笔者推荐初学者使用Mirantis Fuel或RedHat RDO部署OpenStack，它们都使用了自动化部署工具——Puppet，前者相对后者拥有友好的Web界面，所以用户相对较多，在国内也有分支合资公司。
通用型设计
通用型设计即是指用户需求不太明显的情况，我们提供给用户适用性较广的架构以满足其潜在需求。如用户在内网运行Web服务器但不知何时会面向公网，或者用户是为了某个项目进行实验等等。这种设计所需要的OpenStack组件中，我们对用户的潜在需求进行分析，然后选择安装尽可能多的组件。
□存储考虑
提供的存储服务主要包括块存储与对象存储两部分。
块存储服务是整个架构的基础，一般会直接部署Cinder管理块存储服务，其后端有很多商业存储可供选择，同时OpenStack也提供了针对商业存储的插件。如果没有单独的存储设备则考虑在各个服务器上部署多副本的Cephfs集群，但服务器上除系统盘外也要有额外的硬盘组RAID 5或6。如果用户希望虚拟桌面的操作更流畅，或者他们需要频繁地创建、删除虚拟机，可考虑划分单独的SSD存储池用于虚拟机镜像存储（Nova、Glance）。如果服务器仅仅用作提供存储服务，从笔者经验来说采用高主频、少核的CPU时性价比较高。
而使用对象存储的目的有两个，一是存储部分虚拟机模板镜像，二是让用户将其作为网盘使用。存储模板镜像时，对象存储架构比较简单，Swift控制节点也可放入主控制器中；当作网盘使用时，那么Swift网关服务器就相当于一个Web服务器，且用户会话时间较长，此时如果并发有一定数量但未具备相当规模时，一般只需加强网关服务器硬件与优化系统配置即可，如果要针对较大规模并发，则需要更改其架构，比如添加单独的负载均衡设备或者组成高可用集群。
□网络考虑
在设计基础网络时，一般会针对不同的网络功能区域进行单独设计。
OpenStack目前提供nova-network与neutron两种网络后端，但前者在最近的版本中已被标记为“deprecated（抛弃）”，所以笔者推荐使用neutron以提高系统向后兼容性与扩展性。
通用型设计中，网络一般划分为公共网络、用户网络、管理网络、存储网络等。公共网络即是用于对外服务的网络，这些服务主要用于用户访问（Web、REST API、spice），连接到这些网络的节点只有控制器、Swift网关、桌面协议代理网关等，同时LB集群节点也会使用此网络。用户网络即是用户的虚拟机或容器实例使用的内部网络，其IP地址位于“虚拟网段”中，或者是与物理交换机相连的“物理网段”中，一些在公共网络中的服务也可在此网络中以提高内部实例访问服务的速度。管理网络即是管理硬件资源时使用的网络，管理员使用工具添加新节点时会赋予其管理网络所在网段的IP。存储网络即是存储节点所使用的网络，它对网络硬件的要求较高，包括带宽、延迟、冗余性等方面。
□计算考虑
通常，计算节点所组成的集群按照其逻辑功能或位置划分为多个计算池，且每个池中的资源总量都由管理员定义，如常驻桌面池、浮动桌面池、研发服务器池、办公服务器池等。考虑到虚拟机实例的可迁移性，同一池中的服务器CPU配置（主频适中、多核）都是相同的，同时服务器都需接入对应功能区域的网络。
虚拟化的基本特性之一是资源超分，即分配给虚拟机的资源可以超过所在计算节点实际资源，CPU资源、内存资源在OpenStack中的比例默认为16∶1、1.5∶1。这些比例并不一定适用于实际环境，比如当CPU超分过多时，会导致部分虚拟机因QEMU进程上下文切换成本过高而变得卡顿，当内存超分过多时，如果虚拟机实例实际占用的内存超过hypervisor的物理内存，则有可能发生交换（swap out）动作同样导致部分虚拟机性能下降，更严重者此虚拟机进程被直接杀死。
与计算节点紧密相关的控制节点硬件配置一般不需要很高，可参考存储网关节点配置。
□架构示例图2-23是以提供Web服务虚拟机为主和对象存储为辅服务的OpenStack架构。
存储服务由单独的存储服务器集群提供，包括用于计算节点的块存储服务Cinder以及用于云存储的对象存储服务Swift。
网络部分的划分笔者并没有在图中标注，但整体可进行如下划分：外部业务网络包括防火墙、控制器、Swift网关、负载均衡网关（虚拟机），服务器网络包括控制器、Nova计算集群，存储网络包括Cephfs存储集群、Nova计算集群、Swift存储网关，虚拟机网络则专门用于虚拟机。(www.xing528.com)
计算服务池分为研发和业务，前者用于研发人员开发、测试、代码/项目管理等，后者则用于运行已经上线的Web服务。由虚拟机组成的Web服务集群接收来自负载均衡设备分发的请求，再选择Web服务器予以响应。图2-24中的负载均衡网关是在虚拟机内以软件形式提供的，它与Web服务器集群的架构和传统架构相同，因为管理员对后者更为熟悉。而高可用的控制器则保证了所有OpenStack控制组件的稳定性。由于用户需求中对象存储仅仅作为可选存在，所以此设计并没有添加单独的Swift存储负载均衡网关。
图2-24 提供W eb服务虚拟机、对象存储服务为主的OpenStack架构示例
计算密集型设计
如果用户的应用是在高性能计算（HPC）、网格计算（Grid Computing）、图文索引等非常依赖CPU性能的环境中时，我们可以对通用型稍作修改以完成应用计算密集型设计，而这其中又可以分别选择Nova或者Magnum提供虚拟机实例或容器实例，以隔离计算资源分别进行计算作业，从而构建出多租户环境的PaaS平台。
计算密集型的设计中，我们会尽量缩短I/O路径以减少数据搬迁带来的时间成本，且由于虚拟机实例或容器实例很少有高可用需求，所以采用本地存储将直接用于存放Nova虚拟机实例镜像与应用程序需要的文件系统，如HDFS。此时，网络划分相对来说简单一些，但是计算节点则需要拥有独立的数据盘，采用OpenStack基础设施的Hadoop集群架构如图2-25所示，其中控制节点可选装OpenStack大数据项目Sahara。
这种架构虽然牺牲了虚拟机的迁移特性，但同时正因为这点我们便可以在Nova节点添加物理显卡并透传至虚拟机中，从而提高特定行业领域的分布式计算性能。
由于虚拟化的性能较之物理机有轻微损失，所以有人考虑使用性能几乎等同于物理机的容器运行分布式计算应用。本书成文时原生Kubernetes、Docker Swarm、Mesos/Marathon组建的Docker集群并没有多租户功能。而出现稍晚的OpenStack容器服务Magnum由于可将Swarm与Kubernetes作为容器集群后端，利用Nova或者Heat提供容器模板，加之其原生的多租户支持，而越来越受人关注。其架构可参考图2-26，其中使用Kubernetes作为容器集群服务，两个计算池分别用Nova和Heat提供的容器实例以适应不同的应用场景，其网络同样由Kubernetes提供，存储部分可参考图2-25。
图2-25 以OpenStack虚拟机作为基础设施的Hadoop集群
图2-26 OpenStack M agnum参考架构
存储密集型设计
存储密集型的设计一般可将其理解为用于提供对外存储服务的基础架构，相当于一个独立的存储设备，其中的Nova上的虚拟机仅用作高可用存储管理服务与负载均衡的Swift存储网关，如图2-27所示。
这个架构主要参考了一些存储厂商的软件设计，所有对外暴露的存储服务都由管理入口进行控制，包括RBD、共享文件系统、对象存储以及基于它们二次构建的NFS、iSCSI、CIFS等。其中计算节点性能较弱，仅运行一些功能单一的虚拟机，厂商的实现中甚至将包括控制器、管理入口在内的服务直接部署至存储节点。
图2-27 存储密集型OpenStack架构
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
