第 2 章 准备及部署

第 2 章 准备及部署

运行云系统所需的工作量是衡量其扩展能力的一个重要部分。为了降低云系统的运行成本,需要通过配置管理系统,如 Puppet 或 Chef,设置和使用一个能够自动化部署和配置的基础架构。这些系统结合起来能够显著减少手工操作,同时降低人为操作失误的概率。

该基础架构中包含的系统能够自动安装操作系统的初始配置,并且随后自动且集中协调所有服务的配置。这能减少手工操作同时降低出现操作错误的可能性。这些系统包括 Ansible、Chef、Puppet 和 Salt。你甚至可以使用 OpenStack 来部署 OpenStack,这种做法称为“三 O 法”(OpenStack On OpenStack)。

2.1 自动化部署

自动化部署系统能够在新的服务器上安装并配置操作系统,并无需人为干预,此前只需要进行相当少的手工操作,包括物理机器上架、MAC 地址到 IP 地址的映射分配、电源配置等。典型的解决办法依赖于 PXE 引导封装器和 TFTP 服务器来进行基本的操作系统安装,随后切换到自动化配置管理系统完成剩下的工作。

Ubuntu 和 Red Hat Linux 都自带了配置操作系统的机制,包括 preseed 文件和 kickstart 文件,你可以在网络启动后使用它们。一般来说这些文件用于启动一个自动化配置系统。或者,你也可以使用一种基于镜像的方法来部署操作系统,例如 systemimager 软件。在一个虚拟的基础架构中,你可以同时使用以上两种方式,比如运行虚拟机区分控制服务和物理基础架构。

当你创建一个部署方案时,请专注于几个非常重要的方面,因为它们在部署完成后将很难修改。接下来的两个小节将会谈谈以下配置工作:

  • 磁盘分区及磁盘阵列的扩展性配置;

  • 仅用于 PXE 引导的网络配置。

2.1.1 磁盘分区及RAID

磁盘是任何一种操作系统(OS)安装的根本基础。

你必须对服务器的磁盘完成以下配置。

  • 分区。如后文所述,分区为操作系统和交换分区的布局提供了强大的灵活性。

  • 添加到 RAID 阵列(独立冗余磁盘阵列)。这取决于可用磁盘的数量,以便你在云系统规模增长的过程中添加更多存储容量。后文会详细介绍有关选项。

最简单的做法是仅使用一个硬盘,将其分为如下两个分区。

  • 文件系统。用于存储文件和目录,所有数据都存储其上,包括启动和运行系统的根分区。

  • 交换分区。用于释放进程使用的内存,作为物理磁盘的独立区域,它仅用作交换用途。

上述最简单的单盘配置中没有使用 RAID。但是在生产云环境中你需要使用多个磁盘,以确保一旦一块磁盘故障,其他磁盘可以代替故障磁盘。磁盘的数量决定了 RAID 阵列的类型。

我们建议你从以下多磁盘选项中选择一种。

  • 选项1

    以相同的方式对所有磁盘进行水平分区,如图 2-1 所示。

    {%}

    图 2-1:磁盘分区设置

    在此种方式下,你可以将不同的分区分配给不同的 RAID 阵列。你可以将第一、二块磁盘的分区 1 分配给 /boot 分区镜像,将所有磁盘的分区 2 作为根分区镜像,将所有磁盘的分区 3 作为 LVM(逻辑卷管理)的 cinder-volumes 分区,并运行在 RAID 10 阵列上。

    虽然可能最终会有未使用的分区,例如本例中磁盘三和磁盘四的分区 1,但是此选项可以最大化地利用磁盘空间。如果所有磁盘都被分配了任务,那么 I/O 性能可能会有问题。

  • 选项2

    将所有裸磁盘添加到一个大型的 RAID 阵列中,无论是硬件 RAID 还是软件 RAID。随后你可以将此大型 RAID 阵列分为引导分区、根分区、交换分区和 LVM 分区。这个选择易于实施并且使用了所有分区,但是磁盘的 I/O 性能可能会受到损害。

  • 选项3

    将整个磁盘全部用于特定的分区。例如,你可以将磁盘一和磁盘二做成 RAID 1 镜像,然后全部分给引导分区、根分区和交换分区,同样将磁盘三和磁盘四设置成 RAID 1 镜像并全部作为 LVM 分区。这样做,磁盘的 I/O 专注于特定的任务,因此 I/O 性能会更高;然而 LVM 分区相比而言就小得多了。

 你也可以自动分区。例如,麻省理工学院使用 Fully Automatic Installation 软件(FAI,http://fai-project.org)来做基于 PXE 的初始化分区,安装时采用了最大化 / 最小化和基于百分比相结合的分区方式。

对于大多数架构选择方案,你的环境决定了你的选择。如果你使用现有的硬件,那么你就知道服务器的磁盘密度,并可以基于上述选项做出分区决策。如果你在进行采购,那么用户需求会帮助你确定硬件采购的类型。下面几个例子来自美国电话电报公司(AT&T)的一个为网站开发人员提供定制环境的私有云。这个例子来自一个特定的部署方案,因此你的现有硬件或采购的选择可能与此不同。AT&T 在部署中使用了如下三种类型的硬件。

  • 控制器节点硬件。用于所有无状态的 OpenStack API 服务;大约 32~64 GB 内存,磁盘容量较小,一个处理器,6~12 核。

  • 计算节点的硬件。一般为 256 GB 或 144 GB 内存,两个处理器,24 核。4~6 TB 的内置存储,通常使用 RAID 5 配置。

  • 存储节点硬件。在保证储存机柜空间高效利用的同时,优化了磁盘容量,使每 GB 的存储成本最低。

再次强调一下,对于大多数架构选择方案,具体环境决定了你的选择。你必须在空间利用率、易用性和 I/O 性能之间权衡并做出决策。

2.1.2 网络配置

网络配置是一个很大的主题,涉及本书的多个部分。现阶段,你需要确保你的服务器可以 进行 PXE 引导,并与部署服务器进行通信。

例如,在进行 PXE 引导的过程中,通常无法为虚拟局域网配置网卡。另外你通常无法使用 绑定的网卡进行 PXE 引导。如果你遇到了这样情况,可以考虑在私有网络中使用一个简单 的 1 Gbit/s 交换机,仅用于云系统通信。

2.2 自动化配置

自动化配置管理的目的是建立和维护系统的一致性,避免人为干预。在部署过程中保证一致性,从而可以反复部署云系统,并保证每次部署都一样。正确使用自动化配置管理工具,可以确保云系统的组件处于特定状态,另外还可以简化部署和配置变更传递过程。

这些工具也使得测试和撤销变更成为可能,因为它们是完全可以重复操作的。在这个领域,OpenStack 社区已经做了大量工作。Puppet 这种配置管理工具,甚至在一个称为 Stackforge(http://opsgui.de/NPFUpL)的 OpenStack 基础架构系统中为 OpenStack 提供了官方模块。网址 https://github.com/stackforge//openstack-chef-repo 提供了 Chef 配置管理工具。其他配置管理系统还有 Juju、Ansible 和 Salt。另外,PackStack 是 Red Hat Enterprise Linux 及其衍生版使用的命令行工具,它使用 Puppet 模块并利用现有服务器的 SSH 连接来支持 OpenStack 的快速部署。

配置管理系统不可分割的部分就是它控制的那些配置项目,你应该谨慎考虑所有项目——哪些项目需要自动化控制,哪些不需要。例如你可能不想对存有用户数据的磁盘进行自动格式化。

2.3 远程管理

以我们的经验,大多数运维者并不坐在运行云系统的服务器旁边,很多人不愿前往数据中心。OpenStack 应当是完全远程可控的,但是有时并非事事如愿。

在这种情况下,如果有一种带外路径能访问运行 OpenStack 组件的节点,就非常方便了。IPMI 协议就是业界事实上的标准,强烈建议使用支持 IPMI 协议的硬件以实现无人值守数据中心的目标。

另外,也要考虑远程电源控制。虽然 IPMI 通常可以控制服务器的电源状态,但是如果能远程控制到服务器电源线连接的配电装置(PDU),那么当所有服务器都卡住时,它会很有用。

2.4 关于准备和部署OpenStack的最后几句话

理解所要创建的云系统的用例,这样可以节约时间。OpenStack 的用例各有不同:有些仅仅使用对象存储,有些对计算资源进行预先配置来加速开发环境的建设,有些需要对已经通过私有网络对每个租户进行保全的计算资源进行快速部署。你的用户也许需要高度冗余的服务器,以保证其遗留应用程序可以继续运行。可能目标正是架构这些遗留应用程序,使它们在云端以容错的方式在多个实例上运行,而不是随着时间的推移添加到那些集群中。你的用户也许还会因为使用大量的 Windows 服务器,而对扩展性要求更高。

从已有的硬件中寻找最合适的,这可以节约资源。你也许有一些高密度的存储硬件。你可以格式化这些存储硬件,并改用于 OpenStack 的对象存储。所有这些注意事项和用户的需求都能够帮助你构建自己的用例,并制定部署计划。

 想知道关于 OpenStack 部署的进一步研究,可以从以下公司的网站查找有关支持和记录 OpenStack 预配置、预打包的安装程序:Canonical(http://opsgui.de/NPFSy7)、Cisco(http://opsgui.de/1gwRmlS)、Cloudscaling(http://opsgui.de/1eLAFSL)、IBM(http://opsgui.de/NPFYG3)、Metacloud(http://opsgui.de/1eLAGWE)、Mirantis(http://opsgui.de/NPFWOy)、Piston(http://opsgui.de/1eLAHKd)Rackspace(http://opsgui.de/1gwRm58)、Red Hat(http://opsgui.de/NPFXlq)、SUSE(http://opsgui.de/1eLALK5) 和 SwiftStack(http://opsgui.de/NPG0hb)。

2.5 总结

关于准备和部署的决策,将会直接影响你将来对云系统的日常维护。你的配置管理方式将会随着时间的推移而进化。无论如何,你得对部署、磁盘分区和网络配置等问题提前进行更多的考量和设计。

目录