关于 Apache CloudStack 的 最佳实践 （五）
存储系统的规划与配置实践
Primary Storage
Apache CloudStack被设计为与广泛的商品级和企业级存储系统联合使用。在受虚拟化引擎支持的情况下，Apache CloudStack也支持使用虚拟化引擎所在宿主机的本地磁盘作为主存储。虚拟机实例所能使用的虚拟磁盘类型取决于选用了哪种虚拟化引擎。（Apache CloudStack并不直接支持用于KVM虚拟化引擎的集群化逻辑卷管理【CLVM】存储）
Secondary Storage
Apache CloudStack被设计为与广泛的辅助存储系统联合使用，其要求是辅助存储系统支持NFS协议。对于大规模、多专职地带部署的Apache CloudStack也可以使用AWS的S3对象存储系统作为辅助存储。这允许辅助存储跨统辖区域使用，然而，由于大多数虚拟化引擎不能直接挂载S3一类的对象存储，因此NFS暂存区必须在每个专职地带内维护。
配置Apache CloudStack的存储系统
Small-Scale Setup
在小规模的部署配置中，一个单独的NFS存储服务器可以同时承担主存储和辅助存储的角色。这种情况下，NFS存储必须被分割成两个部分，一个用作主存储、一个用作辅助存储。需要使用一个实体主机或者虚拟机实例来运行NFS的服务端程序。在小规模的部署场景中，磁盘和网路性能对在虚拟机实例的部署、运行、制作快照过程中的良好体验十分重要。
Large-Scale Setup
在大规模的部署场景中，主存储和辅助存储通常由独立的实体存储阵列构成。主存储可能必须支持随机读写I/O，辅助存储一般只需支持持续的连续读写请求即可。
对于正在经历大量用户制作虚拟机实例快照或者部署虚拟机实例的Apache CloudStack而言，辅助存储的性能对于此时的用户体验就相当重要了。在存储系统设计之初就框定它所能支持的工作负载估值是很重要的，还必须考虑虚拟机实例对IOPS的要求、及数据存储容量和到达存储网卡的可用带宽（单位是 MB/s）。
Apache CloudStack存储架构设计
在Apache CloudStack环境下，有大量不同的存储类型可用。在决定使用哪种存储类型是需要考虑到特定的使用情况，财务方面的限制通常使得技术上最优的存储架构难以在经济性上得以实现。
大体上，可选用的主存储架构有3类：
- 宿主机的本地存储
本地存储最适合于纯云工作负载，这种场景下不需要再存储池间迁移虚拟机实例、虚拟机实例的高可用也不需要。随着SSD称为驻留存储设备且变得廉价，基于本地存储的实例现在可以获得IOPS大小服务（此前这种服务只能通过每10为一组的纺锤阵列提供）。由于没添加一个宿主机就同时添加了等规格的存储容量，因此本地存储是可扩展的。由于不能利用或复用连接克隆，本地存储是相对低效率的。
- 基于节点的共享存储
基于节点的共享存储是一种阵列，这种阵列使用一个控制器或一对儿控制器挂载了一群磁盘。理想情况下，每个豆荚舱会有这么一个阵列以限制单个豆荚舱发生故障的爆炸半径。这是一种不经济的做法，我们应尝试减少任何和可能存在单个整列的专职地带相关的事故的规模。在某个宿主机故障时使用共享存储可以使工作负载在后补宿主机上马上得到重启。这些共享的存储阵列通常具备利用大型SATA磁盘、SAS磁盘和SSD磁盘构建存储阶梯的能力。这些性能不同的存储阶梯层可以作为不同的产品呈现给用户。存储阵列的大小应考虑到全部工作负载所需的IOPS及索要存储的数据量。此外，海英考虑存储阵列预期支持的虚拟机实例数量和可能流经存储控制器的最大网路带宽。
- 集群化的共享存储
集群化的共享存储阵列是新一代的存储，这种存储可以没有供数据进出存储阵列的单一组网卡，而是在任意两个存活节点之间分布的，因而及大地提高了存储的可扩展性和存储性能。即便是在一个节点上的数据全部丢失后，某些集群化的存储阵列也允许全部数据可以继续被访问。
在使用集群化的共享存储时，应当充分考虑存储网路的拓扑结构，以避免存储系统中出现网络瓶颈。
Network Configuration For Storage
设计Apache CloudStack时应考虑到的不仅是存储系统的磁盘阵列的性能，还应考虑到从交换机到存储系统网卡的可用带宽容量。
Apache CloudStack的网路设计：存储系统
首先要搞明白的是供应主存储的过程。当你为某个宿主机集群创建了一个存储池时，Apache CloudStack的云管理服务会告知每个宿主机上的虚拟化引擎去挂载这个存储池（可以使NFS共享存储或iSCSI的逻辑单元号）。这个存储池会以数据块的形式呈现给宿主机上的虚拟化引擎（如VMware ESXi中的datastore、XenServer中的storage repository、KVM中的mount point）。最重要的一点是，着是虚拟化引擎自身在和主存储通讯、Apache CloudStack的云管理服务仅和宿主机上的虚拟化引擎通讯。现在，所有的虚拟化引擎都通过某种管理网卡和外部通讯（如VMware ESXi中的VMkernel端口、XenServer中的Management Interface）。由于Apache CloudStack的云管理服务需要和宿主机上的虚拟化引擎通讯，这个"管理网卡"必须在Apache CloudStack的云内管理网或云内网络上。宿主机上应当有其他网卡来承载在宿主机内通向虚拟机实例的公网流量或客户机网流量。
对存储虚拟化背景的用户而言会考虑分离主存储的网路流量，给存储网流量穿件一个特定的网口并不是什么新的概念。通过给iSCSI存储力量指定战术交换机以避免读写延时或读写资源争夺，这是长期以来的有效实践。
有时候在"云"的世界里，我们忘记了我们正在精心策划的、由虚拟化引擎已经执行了的、配置了的事物依旧适用。以下逻辑示意图说明了这种流量分离是如何实现的：
- 如果你想要用一张额外的网卡和虚拟化引擎通讯，拿就需要给这个网卡一个IP地址。
- 创建一个可空虚拟化引擎使用的网卡的机制就是创建一个额外的管理网卡。
- 虚拟化引擎可以辨别位于不同且不重叠的分支网络中的管理网卡。
- 为了使云内主存储管理网卡能够和主存储通讯，主存储阵列上的网卡必须和云内主存储管理网卡处于同一个CIDR地址块中。
- 因此，主存储系统必须和Apache CloudStack云内管理网处于不同的分支网络中。
Small-Scale Example Configurations
本部分通过几个案例来说明如何恰当地设定存储系统。
NFS存储系统（基于本地磁盘或直连式存储）
以下描述了如何在Linux上配置NFS关口。
- 在RHEL系列发行版上安装NFS服务端。
- 如果磁盘超过了2TB，就分割出一个磁区（20GB较为适宜）用于安装RHEL系列发行版。
- 操作系统安装完毕后，创建一个名为"/export"的路径。它可以是root磁区中的路径，也可以是一个挂载点。
- 每个ext3格式的文件系统最多支持16TB容量。如果你的存储磁区大于16TB，可以在其上创建多个ext3格式的文件系统并创建多个NFS关口。
- NFS关口路径"/export"创建结束后参考执行以下命令进行配置
受限制的NFS关口：
我们推荐你通过指定子网掩码的方式把NFS关口限制到某一个特定的分支网络中(例如"192.168.1.0/24")。在只允许指定宿主机集群访问存储系统的限制下，可以避免非存储池成员挂载这个存储。你所设定的着个首先存储必须同时包含云内管理网可存储网。如果管理网和存储网是同一个网路，那么一个CRID地址块就足够了；如果存储网络是隔离的，那就必须提供一个隔离的CRID地址块或者足以覆盖管理网和存储网的CRID地址块。
以下是使用隔离CRID地址块的配置示例：
移除异步标识：
通过允许NFS服务端在向磁盘的写操作提交之前做出响应，异步标识提升了存储性能。在关键产品的部署中请移除异步标识。
- 启用NFS服务
- 编辑配置文件/etc/sysconfig/nfs、启用以下配置
- 编辑iptablespeizhi文件/etc/sysconfig/iptables，在INPUT链的开始位置添加以下内容：
- 重启NFS服务端。
至此，一个名为"/export"的NFS共享存储就设置好了。
NFS存储（基于iSCSI）
以下步骤说明了如何假设一个基于iSCSI三维NFS服务端关口（适用于RHEL 5 系列的发行版）。
- 安装iSCSI管理工具"iscsiadm"：
- 寻找 iSCSI target ：
- 登录到 iSCSI target ：
- 寻找SCSI磁盘：
- 格式化SCSI磁盘并把它挂载到NFS服务端关口：
- 把SCSI磁盘添加到系统级文件系统库表，确保磁盘可以被OS开机挂载：
现在来把NFS服务端关口设定为NFS共享存储。
受限制的NFS关口：
为避免数据丢失，我们推荐你通过指定子网掩码的方式把NFS关口限制到某一个特定的分支网络中(例如"192.168.1.0/24")。在只允许指定宿主机集群访问存储系统的限制下，可以避免非存储池成员挂载这个存储和疏忽性地删除存储上的数据。你所设定的着个首先存储必须同时包含云内管理网可存储网。如果管理网和存储网是同一个网路，那么一个CRID地址块就足够了；如果存储网络是隔离的，那就必须提供一个隔离的CRID地址块或者足以覆盖管理网和存储网的CRID地址块。
以下是使用隔离CRID地址块的配置示例：
移除异步标识：
通过允许NFS服务端在向磁盘的写操作提交之前做出响应，异步标识提升了存储性能。在关键产品的部署中请移除异步标识。