自动化程度较高的基础设施的基石之一是提供单个服务器的系统。一个让我们能够可靠、快速、可重复地创建新的服务器实例的系统，能够在整个基础设施中保持一致，这意味着我们花费在单个服务器上的时间更少。相反，服务器变成了一次性的组件，可以轻松地交换、替换和扩展，因为我们把注意力集中在我们提供的服务的更大图景上。

实现这一点的第一步是确保使用自动化流程构建服务器实例。这样可以确保每个服务器都是以相同的方式构建的，改进可以很容易地并入服务器构建过程中，并且可以很容易地创建新的实例，以及废弃和替换坏的实例。自动化这个过程也意味着你的团队的高技能，高收入的专业人士不需要花费大量的时间在无脑的死记硬背工作点击菜单，通过操作系统安装工作。

2002年，我第一次使用 PXE-booting 物理机架服务器自动安装，遵循了当时的 infrastructures.org 网站上的建议，后来又把同样的概念应用到虚拟服务器和 IaaS 云实例上。

机器生命周期

我认为这是机器生命周期(我倾向于称之为“服务器生命周期”，因为这是我通常使用的，尽管它同样适用于桌面)。这涉及到设置和管理单个计算机实例所需的大量活动，例如分区存储、安装软件和应用配置。

这些活动在机器生命周期的一个或多个阶段中应用。有三个阶段: “包映像”、“提供实例”和“更新实例”。有许多不同的策略来决定在每个阶段进行哪些活动。

各种活动可以在一个或多个阶段中应用，这取决于用于管理机器生命周期的策略。例如，一些战略在打包阶段执行更多的活动，而其他方法可能具有更简单的打包阶段，但在供应和/或更新阶段执行更多的活动。

机器生命周期阶段

镜像打包阶段

在镜像打包阶段，一个机器实例的一些或全部元素被预先打包成一个机器镜像，这样就可以重用来创建多个运行的实例。

这可以像使用来自供应商的裸操作系统安装 CD 或 ISO 一样简单。或者，它可以是完全安装、完全配置的可运行系统的快照，例如赛门铁克 Ghost 映像、 VMWare 模板或 EC2 AMI。不管采用哪种方式，这些映像都保存在机器映像库中，以便在实例配置阶段使用。

不同的机器生命周期策略使用不同的方法进行图像打包。ManualInstanceBuilding 和 ScriptedInstanceBuilding 都倾向于使用库存操作系统映像，这涉及较少的前期工作和机器映像库的维护，因为实例是直接从供应商获取的。但是，仍然需要在配置时创建、测试和维护用于配置实例的检查列表或脚本。

另一方面，Cloning赖以存在的机器实例(MachineInstances)和 TemplatedMachineInstances 都会创建预配置的服务器映像，它们只需要很小的更改(比如主机名和 IP 地址)就可以提供新的实例。这很有吸引力，因为提供新实例的工作较少，但缺点是创建和更新映像需要更多的工作。管理员倾向于对正在运行的实例进行更新和修复，这些实例可能不会出现在模板中，这有助于 ConfigurationDrift，特别是在临时更改的情况下。

克隆存在机器实例，通常采取复制现有服务器的形式，根据需要创建新的服务器，往往会使 ConfigurationDrift 变得更糟，因为新的服务器继承其父服务器的运行时残骸和碎片(日志文件、临时文件等) ，并且很难将各种服务器与单一、一致的配置保持一致。TemplatedMachineInstances 是保持基础结构一致性和易于管理的更好方法。

脚本安装和打包映像之间的权衡部分取决于用于脚本和/或打包的工具，而这又常常取决于托管平台。例如，AmazonAWS 需要使用模板(AMI)。在任何一种情况下，在供应阶段更充分地利用自动化都有利于保持打包阶段尽可能轻量级。

实例提供阶段

在配置阶段，从映像创建一个机器实例并准备好用于操作。

这个阶段的活动示例包括实例化 VM 或云实例、准备存储(分区磁盘等)、安装操作系统、安装相关软件包和系统更新，以及配置系统和应用程序以供使用。

有两种主要的策略来决定哪些活动属于打包阶段，哪些属于配置阶段。一个是 RoleSpeciTemplate，另一个是 GenericTemplate。

使用 RoleSpeciTemplate，机器映像库包括已经为特定角色预打包的映像，例如 Web 服务器、应用程序服务器、邮件服务器等。它们具有在打包阶段创建的必要软件和配置，因此配置只需要引导一个新实例并调整一些配置选项。这种方法有两个缺点。首先，你需要维护更多的图片，这样会创造更多的工作。例如，在更新用于多个角色的操作系统时，必须重新打包所有这些角色的映像。其次，这种模式给您带来的灵活性较低，因为您不能轻松地提供一个组合多个角色的实例，除非您为您可能需要的每个角色组合创建-然后维护-映像。

使用 GenericTemplate 模式，每个映像都是通用的，只包括所有角色通用的软件和配置。在配置阶段为每个机器实例分配角色，然后相应地应用软件和配置。我们的目标是尽量减少机器图像库中的图像数量，以减少维护这些图像所需的工作量。通常，对于单个操作系统安装不支持的每个硬件和操作系统组合，都需要一个单独的模板。JeOS (Just Enough Operation System)概念将这一点发挥到了极致，使基本模板尽可能小。

GenericTemplate 模式确实需要在配置期间进行更健壮的自动化配置，并且可能意味着配置实例比使用更完整的构建映像需要更长的时间，因为在安装期间需要安装更多的包。

实例更新阶段

一旦机器实例正在运行和使用，它就会不断地更新。这包括应用系统和软件更新、新配置设置、用户帐户等活动。

许多团队手动执行这些更新，但是以这种方式维护系统需要高水平的规程和组织，特别是随着系统数量的增加。一个团队可以管理的机器数量与团队的规模密切相关，因此服务器对系统管理员的比例很低。在实践中，使用手动更新的团队往往是被动的，在执行其他任务时机会性地更新机器，或者是为了修复突然出现的问题。这导致了 ConfigurationDrift，机器之间变得越来越不一致，产生了各种各样的问题，包括不可靠的操作(在一台机器上运行的软件不能在另一台机器上运行) ，以及需要进行故障排除和维护的额外工作。

使用无须实名的阿里云国际版，添加微信：ksuyun 备注：快速云！

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请发送邮件至 cloud@ksuyun.com 举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.hanjifoods.com/16116.html

试用期之后服务器异常(试用期之后服务器异常怎么办)

机器生命周期

机器生命周期阶段

镜像打包阶段

实例提供阶段

实例更新阶段

相关推荐