管理程序集群架构 (Hypervisor Clustering Architecture)
管理程序集群架构是由多个管理程序组成的集群。正如我们之前所学，管理程序是运行在裸机硬件上的低级环境，管理多个虚拟机，使它们认为自己运行在独立的硬件服务器上。管理程序集群意味着有多个物理服务器，每个服务器运行一个管理程序。除了管理自己的虚拟机，每个管理程序还与集群中的其他管理程序交互，以便在物理机之间迁移虚拟机。这可能在故障转移处理、负载管理过程或扩展过程中发生。
管理程序集群通常由VIM（虚拟化基础设施管理器）管理。VIM监控管理程序以确保它们正常运行。如果由于硬件故障等原因，管理程序无法正常运行，VIM可以将虚拟服务器迁移到正常运行的管理程序。VIM通过监控心跳消息来监控管理程序，这些消息是从被监控设备定期发送的简单消息。在管理程序集群中，管理程序也使用心跳消息来检查其他管理程序的可用性。
集群中的管理程序通过云存储设备迁移虚拟机。虚拟服务器的虚拟映像保存在云存储设备中。当检测到管理程序故障时，该映像可以加载到另一管理程序中。哪个管理程序接管虚拟服务器的决定由VIM做出，VIM会了解集群中每个管理程序的负载情况。
有时我们会说虚拟服务器在管理程序之间进行实时迁移。然而，实时的定义取决于虚拟映像的存储方式。如果管理程序维护虚拟机状态的最新映像，则可以在新管理程序上非常快速地重启映像。然而，如果映像只是一个可启动的映像，则复制的虚拟服务器可能需要从该映像重新启动，这会因为启动过程引入一些延迟。
以下阅读还指出，管理程序集群架构可能还包括：
- 逻辑网络边界——防止不同用户的虚拟服务器相互干扰。
- 资源复制——管理程序集群的状态必须在所有管理程序之间复制。
活动9
写下以下问题的答案：
- 用你自己的话描述什么是心跳消息以及它是如何使用的。
- 心跳消息是被监控设备定期发送的简单消息，用于确认设备的正常运行状态。VIM使用心跳消息监控管理程序的可用性，确保它们运行正常。
- 你认为为什么通常由VIM决定将虚拟机迁移到哪个管理程序？（为什么不是由管理程序做出决定？）
- VIM通常决定将虚拟机迁移到哪个管理程序，因为VIM掌握整个集群的全局视图，了解每个管理程序的负载情况，能够做出更优化的决策。而单个管理程序无法获得整个集群的全局信息。
- 在讨论实时迁移时，我们提到的“虚拟机的最新映像”是什么意思？
- “虚拟机的最新映像”指的是管理程序维护的虚拟机状态的最新版本，使得在迁移到新管理程序时能够快速重启虚拟机。
负载均衡虚拟服务器实例架构 (Load Balanced Virtual Server Instance Architecture)
当我们有多个虚拟服务器运行在多个物理机器上（不在集群中）时，不可避免地会有一个或多个物理服务器过载，而其他服务器有剩余容量。此时需要一个负载均衡机制。负载均衡虚拟服务器实例架构监控物理服务器的负载，并自动分配虚拟服务器实例以平衡负载。
负载监控和后续的平衡由容量监控系统执行。容量监控系统有三个组件：
- 云使用监控器：监控虚拟机和物理机的使用情况。
- 容量规划器：包含物理服务器和虚拟服务器的容量信息，当容量限制被超出或物理服务器未被充分利用时通知VIM。
- 虚拟机迁移组件：由VIM或容量规划器启动，负责将虚拟服务器从一个物理服务器迁移到另一个物理服务器。
需要注意的是，这与之前讨论的集群架构不同，因为这里描述的物理服务器并不在集群中，在VIM看来是独立的设备。
活动10
写下以下问题的答案：
- 阅读中显示容量监控系统直接连接到物理服务器。它可能收集什么信息来确定物理和虚拟服务器的负载？
- 容量监控系统可能收集CPU使用率、内存使用率、网络流量、磁盘I/O和虚拟机数量等信息，以确定物理和虚拟服务器的负载情况。
- 阅读中提到一个用于虚拟机迁移的程序。这个程序可以在哪里执行？
- 这个程序可以在VIM、容量规划器或需要迁移虚拟机的物理服务器上执行。
- 迁移程序会引入延迟吗？
- 是的，迁移程序可能会引入延迟，尤其是在迁移过程中需要停止和重启虚拟机时。
无中断服务迁移架构 (Non-Disruptive Service Relocation Architecture)
无中断服务迁移架构设计用于在不中断服务的情况下重新定位云服务。这类似于之前讨论的弹性架构，但旨在在物理服务器之间迁移服务而不影响其操作。无中断服务迁移适用于可预测的迁移，例如在维护期间或迁移到新物理服务器环境时。当当前物理服务器达到其处理容量时，也可以使用它。
无中断服务迁移（在教科书中也称为实时迁移）包括以下阶段：
- 启动一个可能带有升级软件的重复服务环境。
- 测试新环境是否会响应请求。
- 将传入请求重定向到新服务位置。
- 如有必要，在旧环境中执行维护，并重复1-3步骤以将服务切换回旧位置。 要确保这些步骤无中断，步骤2必须在步骤3之前完成。如果新环境位于同一或升级的物理服务器中，则步骤4不是必要的，此时旧服务可以直接停用。
服务迁移需求可以由自动扩展监听器或负载均衡机制检测到。也可以通过云或用户控制台手动发起（例如用于维护）。这些都会指示VIM启动过程。
活动11
阅读（https://www.informit.com/articles/article.aspx?p=2357815&seqNum=12）。
- 无中断服务架构在负载均衡服务器实例架构中起什么作用（在上一节讨论过）？
- 无中断服务架构确保在负载均衡过程中服务不中断，允许在物理服务器之间迁移服务以保持负载平衡而不会影响用户体验。
- 图12.12到12.14显示由自动扩展监听器启动的无中断服务迁移。如果迁移是从云提供商的控制台启动的，会有什么不同？
- 如果迁移是从云提供商的控制台启动的，可能需要手动配置和验证步骤，自动化程度较低，可能会增加一些人工干预和延迟。
零停机时间架构 (Zero Downtime Architecture)
根据教科书的定义，零停机时间架构是一种在物理服务器故障时为虚拟服务器提供零停机时间的弹性架构。这并不是一个容易实现的架构。考虑到当你的个人计算机蓝屏（对于Windows用户）或发生电源故障时会发生什么。CPU停止，内存中的任何进程都无法访问。问题在于如何恢复运行在故障物理服务器上的虚拟服务器的状态。
零停机时间架构将虚拟服务器的当前状态保存在辅助存储或其他不受物理服务器故障影响的存储中。这个保存的状态用于在另一台物理服务器上恢复虚拟服务器。他们还必须在新副本的虚拟服务开始运行后切换网络连接。网络活动由持久虚拟网络配置架构完成，我们将在下一个主题中讨论。
活动12
阅读https://www.informit.com/articles/article.aspx?p=2357815&seqNum=9）。
- 使用教科书定义，零停机时间架构也是无中断服务迁移架构吗？它们之间有什么关系？
- 是的，零停机时间架构也是无中断服务迁移架构的一种。它们都旨在确保服务不中断，但零停机时间架构更侧重于在物理服务器故障时提供无缝恢复，而无中断服务迁移架构则更侧重于可预测的迁移。
云负载均衡架构 (Cloud Balancing Architecture)
云负载均衡架构用于在不同云之间平衡负载。云负载均衡架构遵循基本的资源平衡架构原则，但这些原则应用于多个云，而不是位于一个云中的多个资源。
云负载均衡由自动扩展监听器管理，它将传入请求分配给运行在不同云中的相同云服务。自动扩展监听器本身可以位于消费者的内部网络中或单独的云中。通常还会有一个故障转移系统监控涉及的云，以便在一个云变得不可访问或出现性能问题时进行故障转移处理。故障转移机制可能仅通知自动扩展监听器，或者可能启动其他动作，例如在运行中的云中创建额外的服务副本。
活动13
阅读链接：chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.f5.com/pdf/white-papers/cloud-balancing-white-paper.pdf 用ReadSpeaker docReader打开此文档。
- 云负载均衡的业务目标是什么？
- 云负载均衡的业务目标是提高服务的可用性和可靠性，优化资源利用，降低运营成本，并确保在不同云提供商之间的工作负载分配，实现更好的服务性能。
- 云负载均衡架构的集成过程有哪些挑战？
- 集成过程的挑战包括跨不同云平台的兼容性问题、数据和服务迁移的复杂性、统一管理和监控的需求，以及确保数据安全和隐私。
动态故障检测与恢复架构 (Dynamic Failure Detection and Recovery Architecture)
动态故障检测与恢复架构负责监控云提供商的IT资源，并在发生故障时采取行动。云提供商可能同时运行数千个云资源，手动24/7监控这么多资源是不切实际的。云提供商需要实现自动化监控架构，以采取措施从资源故障中恢复。需要注意的是，硬件通常需要手动干预来修复或更换故障组件，因此动态故障检测与恢复架构的恢复机制可能只是通知相关人员进行维修。
弹性监控系统执行此架构的监控部分。它必须具备弹性，以确保其故障概率极低。它还必须能够监控许多不同类型的IT资源，并根据检测到的故障资源类型做出相应响应。它还负责记录事件以供将来分析。
弹性监控系统由云提供商配置，以提供适当的响应。响应可能包括以下一种或多种：
- 发送控制台消息
- 发送电子邮件或短信
- 发送SNMP陷阱（SNMP是与网络设备交互的协议）
- 记录帮助台工单
- 运行批处理文件
对于任何设备的故障，弹性监控系统可能会执行这些响应的组合。例如，在工作时间发送控制台消息，在其他时间发送短信。它还可以配置为按顺序尝试其中一种响应，例如，运行批处理文件，如果状态仍然故障则发送短信。
需要注意的是，我们已经讨论过的弹性架构可能仍需要弹性监控系统在弹性架构自动恢复时采取行动。例如，在资源池架构中，如果一个组件故障，资源池将继续通过将请求转移到剩余的池成员来运行。然而，必须修复故障的池成员以恢复池的原始配置，即使池继续运行。这需要通知相关人员进行维修。
活动14
阅读教科书第12章第12.7节（https://www.informit.com/articles/article.aspx?p=2357815&seqNum=5）。
- 图12.20和12.21中显示弹性监控系统使用智能监控器的信息。它的作用是什么？
- 智能监控器收集和分析IT资源的状态和性能数据，提供实时监控和故障检测，并在检测到问题时触发适当的响应措施。
- 教科书中提到弹性监控器可以升级问题。这是什么意思，如何实现？
- 升级问题意味着将未解决的问题提升到更高级别的处理，以确保问题得到解决。可以通过多种方式实现，例如，如果初级响应未解决问题，则通知更高级别的支持团队，或启动更高级别的故障恢复程序。
- 如果弹性磁盘集群（例如RAID）中的磁盘驱动器故障，弹性监控系统应该做什么？记住，磁盘集群会在没有故障磁盘的情况下继续运行。
- 弹性监控系统应记录故障并通知相关人员进行修复，以便尽快更换故障磁盘并恢复磁盘集群的冗余和完整性。
活动15 (反思活动)
是否可以将“无中断服务迁移架构”与“动态故障检测与恢复架构”集成？简要解释如何实现。
- 是的，可以将“无中断服务迁移架构”与“动态故障检测与恢复架构”集成。可以通过在检测到故障时，动态故障检测与恢复架构自动触发无中断服务迁移过程，将服务迁移到其他正常运行的服务器上，以确保服务连续性和稳定性。