关于 Apache CloudStack 的 最佳实践 （一）
Best Practices
部署 Apache CloudStack 是极具挑战性的，在整个部署过程中需要你做出形形色色的技术性选择。 Apache CloudStack 的配置条目是相当灵活的，这是因为在组合和配置具体条目时有太多方式可以实现。本部分涵盖了 Apache CloudStack 部署过程中的建议性要求和必须性要求。
下述内容应当被视为建议而非绝对要求。我们的确鼓励任何计划构建 Apache CloudStack 云的人通过项目邮件列表寻求指导和建议。
Process Best Practices
强烈建议搭建一个能够模仿业务环境的工作台式 Apache CloudStack 云。如果在 Apache CloudStack 云中应用了定制化的不仅，这么做是十分重要的。
要在 Apache CloudStack 云的部署、尝试和学习中花费足够多的时间。初次部署 Apache CloudStack 云时，安装基础模型网络可能在数小时内完成、但安装高级模型网络可能要花费几天时间。要部署一个全功能的 Apache CloudStack 云病逐步解决部署过程中的问题，大约要花费4到8周的时间，在此过程中你可以通过项目社区的邮件用户列表寻求帮助。
Setup Best Practices
- 每个宿主机都应被配置为仅接受来自可信实体的连接（例如来自 Apache CloudStack 云管理服务和自己的监控软件的连接）
- 如果你想获得确定数量的虚拟机实例，那就在每个豆荚舱内使用多个宿主机集群。
- 用于主存储的共享挂载点或者逻辑单元号设备的主存储容量不应超过6TB，最好在每个宿主机集群中使用多个容量较小的主存储设备、避免使用单个大容量存储设备。
- 当需要导出主存储中的共享文件时，可以通过限定具备访问存储系统权限的IP地址范围来避免数据丢失。
- 网卡绑定是可以直接实现的，且可以增强网路的可靠性。
- 当使用能够支持较多虚拟机实例的重型服务器时，推荐给存储系统配置万兆网络。
- 宿主机的容量取决于虚拟机实例的RAM规格。CPU和存储通常是可以超配的，RAM则不可以超配，RAM通常是设计宿主机容量的一个限制性因素。
- 在使用XenServer作为虚拟化引擎时，建议给dom0分配更多的RAM以便XenServer宿主机可以承载更多的虚拟机实例（dom0是为XenServer虚拟化引擎优化过的一个Linux内核，给dom0分配更多的内存有助于XenServer处理更多量的虚拟机）。推荐给XenServer的dom0分配超过2940MB的RAM（XenServer的dom0默认为752MB内存）。
Maintenance Best Practices
- 注意监测宿主机的磁盘使用情况。宿主机运行错误的很多情况是root分区所在磁盘被未经恰当分割转储的日志文件填满了。
- 监测每个宿主机集群中的虚拟机实例总量。一旦宿主机集群中的虚拟机总量超出了虚拟机引擎的处理最大能力，则应禁止向该宿主机集群分配虚拟机实例。要在宿主机集群中留有安全余量以应对一台或多台宿主机不可运行的可能性，一旦有宿主机不可用、就会因重新部署原本运行于柒上的虚拟机实例而导致其他宿主机的负载加重。查阅你所使用的虚拟化引擎产品文档以确认每个宿主机上可承载的虚拟机数量的最大值，然后通过 Apache CloudStack 的全局设定进行限制。
- 监测每个宿主机集群中的虚拟机实例的活跃度，保持活跃的虚拟机实例数量低于允许宿主机故障后的宿主机集群能够承载的虚拟机实例安全数量。例如，在一个宿主机集群中有M个宿主机，最多同时允许3个宿主机发生故障，每个宿主机上最多承载H个虚拟机实例，那么这个宿主机集群中的安全虚拟机实例的数量就不应超过（M-3）*H 个虚拟机实例。一旦宿主机集群中的虚拟机实例数量达到这个值，就应通过 Apache CloudStack 的管理功能禁止再向这个宿主机集群分配虚拟机实例。
- 虚拟化引擎更新补丁的缺失可能导致数据错误和虚拟机实例丢失。要确保虚拟化引擎厂商提供的更新补丁已被安装。通过虚拟化引擎更新通道查询并更新你的虚拟化引擎。 Apache CloudStack 不会自动更新或者提示你虚拟化引擎有新的更新包，然而保持虚拟化引擎更新是至关重要的。你的虚拟化引擎供应商可能对没有更新过补丁的虚拟化引擎提供技术支持。
Basic and Advanced Networking
正确设定网路对成功部署 Apache CloudStack 至关重要。本部分涵盖了如何选择并正确设定 Apache CloudStack 的网路。
Apache CloudStack提供2中类型的网路：
- 基本型网路：也就是AWS风格的overlay型网络模型。这是一张通过3层网络实现虚拟机实例隔离的单一网络。
- 高级型网路：有更为精致的网络拓扑结构，在定义客户机网路时更为灵活、配置也更为复杂。
每个专职地带的网路要么是基本型网路，要么是高级型网路，并伴随其整个生命周期。一旦专职地带的网络欧兴被选定且配置后，便不可再更改。
以下图表中对比了两种网路模型的特点：
在整个Apache CloudStack云中，这两种网络模型可以同时存在。然而在一个既定的专职地带里，此二者只能存其一。
不同的网络流量可以被隔离在同一个实体网路中，客户机流量也可以按照Apache CloudStack账户进行隔离。也可以使用VLAN来隔离不同的网络流量。如果你在单一的实体网路上使用VLAN，需要确保VLAN的标签在对应的数字方位内。
VLAN Allocation Example
公网流量和客户机网路流量都会使用到VALN，以下是VLAN分配的一个示例：
Example Hardware Configuration
本部分阐述了一个用于专职地带级别的3层交换的指定交换设备的配置过程。假定诸如VTP或GVRP之类的VLAN管理协议已经被禁用。如果你想要启用VTP或GVRP管理协议，就必须对本文中提供的命令语句进行恰当的修改。
- Dell 62xx 系列交换机
下面是戴尔 62XX系列交换机被配置为专职地带级别的3层交换的配置过程。我们假定VLAN-201被用于路由豆荚舱1中的无标签的专用IP、豆荚舱1中的2层交换连接到了以太网口1/g1。
戴尔 62XX系列交换机支持1024个VLAN。
S1 在数据库中配置VLAN
S2 配置以太网段口 1/g1
配置结果的含义是：
VLAN-201用于端口 1/g1 的无标签网络流量；
VLAN-300到VLAN-999 用于豆荚舱级别的2层交换
- Cisco 3750
下面是思科 3750型交换机被配置为专职地带级别的3层交换的配置过程。我们假定VLAN-201被用于路由豆荚舱1中的无标签的专用IP、豆荚舱1中的2层交换连接到了以太网口1/0/1。
S1 启用VTP管理协议，以便我们可以使用的VALN数量超过1000（试试上我们仅使用到了999个VLAN，因此这不是必须操作）。
S2 配置以太网端口 1/0/1
配置结果的含义：
VLAN-201用于端口1/0/1上没打标签的网络流量；
VLAN-300到VLAN-999 用于豆荚舱级别的2层交换（思科的交换机默认允许所有的VALN通过）
关于2层交换：
2层交换是豆荚舱内的接入交换层，它把所有的交换机级主干链路VLAN 汇聚给每台宿主机，也切换包含了计算型宿主机和存储型宿主机的管理网的流量。3层交换机此时作为管理网的网路关口出现。
本部分阐述了一个用于豆荚舱级别的2层交换的指定交换设备的配置过程。假定诸如VTP或GVRP之类的VLAN管理协议已经被禁用。如果你想要启用VTP或GVRP管理协议，就必须对本文中提供的命令语句进行恰当的修改。
- Dell 62xx 系列交换机
以下展示了戴尔 62XX系列交换机被配置为豆荚舱级别的2层接入交换的过程。
S1 在数据库中配置VLAN
S2 VLAN-201被保留给了豆荚舱1中未打标签的专用IP、且豆荚舱1连接到了此2层接入交换
配置结果的含义如下：
所有的加端口以同一种方式配置；
VLAN-300到VLAN-999通过了2层交换的全部端口
- Cisco 3750
以下展示了在豆荚舱级别的2层交换中配置思科3750型交换机的过程。
S1 启用VTP管理协议，以便我们可以使用的VALN数量超过1000（试试上我们仅使用到了999个VLAN，因此这不是必须操作）。
S2 为全部端口配置 dot1q 并把本地VLAN 设定为201
默认情况下思科的交换机允许所有的VLAN通过。当两个端口被连接在一起时，思科的交换机会认为这些原生VLAN-ID是不同的。这也是必须在2层接入交换中把VLAN-201设为原生VLAN的原因。