浅谈云计算20 | OpenStack管理模块（下）

OpenStack管理模块（下）

• • 五、存储管理
  • • [5.1 存储管理概述](#5.1 存储管理概述)
  • [5.2 架构设计](#5.2 架构设计)
  • • [5.2.1 Cinder块存储架构](#5.2.1 Cinder块存储架构)
    • [5.2.2 Swift对象存储架构](#5.2.2 Swift对象存储架构)
  • 六、网络管理
  • • [6.1 网络管理概述](#6.1 网络管理概述)
    • [6.2 架构解析](#6.2 架构解析)
    • • [6.2.1 Neutron网络服务架构](#6.2.1 Neutron网络服务架构)
      • [6.2.2 网络拓扑架构](#6.2.2 网络拓扑架构)
    • [6.3 原理与流程](#6.3 原理与流程)
    • • [6.3.1 网络创建原理](#6.3.1 网络创建原理)
      • [6.3.2 网络流量控制流程](#6.3.2 网络流量控制流程)
  • 七、编排管理
  • • [7.1 定义与功能](#7.1 定义与功能)
    • [7.2 架构设计](#7.2 架构设计)
    • [7.3 工作原理与流程](#7.3 工作原理与流程)
  • 八、故障管理
  • [8.1 定义与重要性](#8.1 定义与重要性)
  • [8.2 架构与技术](#8.2 架构与技术)
  • • [8.2.1 故障检测架构](#8.2.1 故障检测架构)
    • [8.2.2 故障诊断与恢复技术](#8.2.2 故障诊断与恢复技术)

（注：OpenStack管理模块（上）在这里）

五、存储管理

5.1 存储管理概述

在 OpenStack 生态中，存储管理极为关键，负责统一管理调度云平台存储资源，涵盖分配、配置、存储、检索及监控维护等操作，能满足企业级和大数据等不同场景存储需求。

块存储由 Cinder 实现，为虚拟机提供类似物理磁盘的块级设备，可挂载、格式化、分区及创建文件系统，适用于数据库等对读写性能要求高且需频繁随机读写的结构化数据场景，能保障数据库稳定高性能运行。

对象存储由 Swift 负责，以对象形式存储数据及元数据，擅于处理海量非结构化数据，如图片、视频等，其分布式架构和高效检索机制可满足互联网企业多媒体数据存储等需求，在需高扩展性和可靠性的非结构化数据存储场景应用广泛。

5.2 架构设计

5.2.1 Cinder块存储架构

Cinder块存储架构精巧且复杂，由多个关键组件协同工作，共同实现对块存储资源的高效管理 。cinder-api作为对外的接口，负责接收来自用户或其他OpenStack组件（如Nova在创建虚拟机时对存储卷的请求）的API请求 。它对请求进行解析和验证，确保请求的合法性和完整性。若请求合法，cinder-api会将请求转发给后续的处理组件，如cinder-scheduler或cinder-volume 。

当用户通过OpenStack的客户端（如Horizon界面或命令行工具）向cinder-api发送创建存储卷的请求时，请求首先会被cinder-api接收 。cinder-api会对请求进行严格的解析和验证，检查请求中是否包含了所有必要的参数，如存储卷的大小、名称、所属项目等信息，以及参数的格式是否正确 。若请求合法，cinder-api会将请求信息转发给cinder-scheduler。

cinder-scheduler在接收到请求后，会依据一系列精心设计的调度算法，从众多存储节点中挑选出最适合创建该存储卷的节点 。这些调度算法综合考虑了多个关键因素，如存储节点的剩余容量，确保所选节点有足够的空间来创建指定大小的存储卷；性能指标，优先选择读写性能良好的节点，以保障存储卷的高效运行；与计算节点的网络距离，尽量选择网络延迟较低的节点，减少数据传输的时间开销 。在某企业的云平台中，若有一个对存储性能要求较高的数据库应用需要创建存储卷，cinder-scheduler会优先筛选出配备高性能存储设备且与数据库服务器所在计算节点网络延迟较低的存储节点 。

一旦确定了目标存储节点，cinder-scheduler会将调度结果发送给该节点上的cinder-volume服务 。cinder-volume负责与底层的存储设备进行交互，以完成存储卷的实际创建操作 。在这一过程中，逻辑卷管理（LVM）技术发挥着重要作用。以使用LVM存储后端为例，cinder-volume会通过调用LVM的命令行工具或API，在指定的卷组（Volume Group）中创建一个新的逻辑卷（Logical Volume） 。它会根据用户请求的存储卷大小，从卷组中分配相应的物理扩展块（Physical Extent），并将这些物理扩展块组合成逻辑卷，从而实现存储卷的创建 。

在创建过程中，cinder-volume还会对存储卷进行初始化配置，如设置存储卷的访问权限、文件系统类型（如果需要）等 。创建完成后，cinder-volume会将存储卷的相关信息，如存储卷的ID、位置、状态等，反馈给cinder-api，cinder-api再将这些信息返回给用户，告知用户存储卷已成功创建 。

5.2.2 Swift对象存储架构

Swift 对象存储采用分布式架构，多个节点协同工作，不存在单点故障风险。在存储节点布局上，数据分散于多个节点，每个节点都有对象服务器负责实际存储数据并分配唯一标识符、账户服务器管理账户元数据及容器列表、容器服务器管理容器内对象元数据及存储位置。

其数据冗余机制借助一致性哈希算法和数据复制策略保证可靠性与容错性。一致性哈希算法能将对象均匀分布到存储节点，减少节点变动时的数据重分布。数据复制策略通常会为每个对象在多个节点创建副本，如三个副本。

数据读写流程如下：写数据时，用户请求经 Swift API 发至 Proxy 服务器，先验证身份权限，通过后依一致性哈希算法算出目标存储节点，数据被分割成对象存于对象服务器本地磁盘并创建副本；读数据时，同样先经 Proxy 服务器验证，再依算法确定可能的存储节点并发送读请求，对象服务器读取数据返回给 Proxy 服务器，Proxy 从可用副本获取数据并返回用户。整个过程中，Swift 还通过监控机制监测存储节点状态，节点故障时能从其他副本获取数据并修复或替换故障节点，确保数据完整性和可用性。

六、网络管理

6.1 网络管理概述

在 OpenStack 中，网络管理由 Neutron 负责，其关键在于管理和调配虚拟网络资源，包括网络的创建、配置等操作，能为多种设备提供稳定网络连接。Neutron 有丰富 API，用户可借此创建不同类型网络、定义子网与配置路由器。

Neutron 网络模型含网络、子网、端口、路由器等关键概念。网络类似局域网，可含多个子网；子网定义 IP 范围与配置；端口连接虚拟机和网络；路由器实现网络间流量转发。此外，它还支持高级网络服务与多种后端驱动，具有灵活性和扩展性。

6.2 架构解析

6.2.1 Neutron网络服务架构

Neutron采用分布式架构，由多个组件协同工作，共同为云平台提供强大的网络服务 。Neutron Server作为核心组件，运行在控制节点上，是整个网络服务的入口，负责接收来自用户或其他OpenStack组件的API请求 。它宛如一个智能的指挥中心，对请求进行解析和处理，并根据请求的类型和内容，合理地调用相应的插件（Plugin）进行后续处理 。

（图源：https://blog.csdn.net/qq_42761527/article/details/104641141）

在 Neutron 架构里，插件极为关键，能扩展网络服务功能。核心插件提供基本二层网络功能，像网络创建、子网划分等，其中 ML2 插件灵活性强且适用广，支持 Open vSwitch、Linux Bridge 等驱动，便于用户依需求构建虚拟网络。

• 服务插件（Service Plugin）： 专注提供 DHCP、路由、负载均衡、防火墙等高级功能。如 DHCP 插件可为虚拟机动态分配 IP 地址，保障其接入网络时自动获取合法配置；路由插件通过配置路由表，实现不同网络间数据包准确转发。

• 代理（Agent）： 分布于各节点，负责执行网络服务，把插件配置指令转化为具体操作。计算节点上的 Open vSwitch Agent 管理 Open vSwitch 虚拟交换机以连接虚拟机和网络；网络节点上的 L3 Agent 实现三层路由功能，与路由器交互完成子网间流量转发。

• 数据库（Database）： 存储 Neutron 网络状态信息，涵盖网络、子网、端口、路由器等资源的详细配置与状态，Neutron Server 处理请求时频繁与之交互读写更新。创建新网络时，相关信息会存入数据库，网络状态改变时也会及时更新。

• 消息队列（Queue）： 是 Neutron 架构中组件通信的关键桥梁，RabbitMQ 常被使用。Neutron Server 接收请求后发至消息队列，插件获取并返回结果，代理也通过它接收指令反馈执行结果，保障网络服务协同运作。

6.2.2 网络拓扑架构

在OpenStack中，网络拓扑的构建基于Neutron网络模型，呈现出多样化且灵活的架构特点 。外部网络，也被称为公共网络，是连接OpenStack项目与外部网络环境的桥梁，它为虚拟机提供了访问互联网或其他外部资源的途径 。在一个企业的云平台中，外部网络可能连接到企业的核心网络，使得虚拟机能够与企业内部的其他系统进行通信；或者连接到互联网，让虚拟机能够访问外部的服务和资源 。

内部网络则完全由软件定义，通常被称为私有网络，是虚拟机实例实际运行的网络环境 。它可以包含多个子网，每个子网都有独立的IP地址范围和配置 。在一个企业的开发测试环境中，可能会创建多个私有网络，每个网络对应不同的项目或团队，实现网络资源的隔离和分配 。通过合理规划子网的IP地址范围，可以满足不同业务场景对网络资源的需求 。

（图源：https://developer.aliyun.com/article/256415）

路由器在网络拓扑架构中起着关键的连接作用，它负责将内部网络与外部网络连接起来，实现不同网络之间的流量转发和通信 。在配置路由器时，需要设置其网关、路由表等参数，以确保数据包能够正确地在不同网络之间进行路由 。在一个包含多个私有网络和一个公共网络的云平台中，路由器可以将私有网络中的虚拟机与公共网络进行连接，使得虚拟机能够访问外部互联网资源 。同时，路由器还可以实现网络地址转换（NAT）功能，将私有网络的IP地址转换为公共网络的IP地址，从而实现虚拟机与外部网络的通信 。

网络拓扑架构还支持多种网络类型，如VLAN（虚拟局域网）、VXLAN（虚拟可扩展局域网）等 。VLAN通过在二层网络中划分不同的虚拟局域网，实现不同网络之间的隔离和通信 。在一个数据中心中，可能会使用VLAN技术将不同业务部门的网络进行隔离，确保各个部门之间的网络安全和独立性 。VXLAN则基于隧道技术，构建了一个大二层的数据中心网络，它能够跨越不同的物理网络，实现大规模的网络扩展和灵活的网络部署 。在一个跨地域的云平台中，VXLAN可以将不同地区的数据中心网络连接起来，形成一个统一的虚拟网络，为用户提供无缝的网络体验 。

6.3 原理与流程

6.3.1 网络创建原理

在OpenStack中，网络创建涉及多个层面的原理与技术实现。当用户发起创建网络的请求时，Neutron Server首先接收到该请求，并对其进行解析和验证 。请求中通常包含网络的相关配置信息，如网络名称、类型（私有网络或公共网络等）、是否共享等。若请求合法，Neutron Server会将请求转发给相应的插件进行处理 。

以使用ML2插件为例，该插件会根据用户指定的网络类型和所选的网络驱动（如Open vSwitch或Linux Bridge），在底层创建相应的网络基础设施 。在创建基于Open vSwitch的网络时，ML2插件会与Open vSwitch Agent进行交互，在计算节点上配置Open vSwitch虚拟交换机，创建虚拟网桥，并为网络分配唯一的标识符 。

在子网创建方面，需要依据网络的IP地址范围进行合理划分 。用户在创建子网时，需指定子网的IP地址段、子网掩码、网关IP地址等信息 。例如，若用户要创建一个IP地址范围为192.168.1.0/24的子网，其中192.168.1.0是网络地址，/24表示子网掩码为255.255.255.0，这意味着该子网可容纳254个可用的IP地址 。Neutron会根据这些信息，在网络中划分出相应的子网，并将子网信息存储到数据库中，以便后续的管理和查询 。

对于端口的创建，它是虚拟机接入网络的关键桥梁 。当为虚拟机创建端口时，Neutron会为端口分配唯一的MAC地址和IP地址，这些地址从所属子网的IP地址池中选取 。IP地址的分配方式可以是静态分配，即用户手动指定一个IP地址；也可以是动态分配，通过DHCP服务从IP地址池中自动获取一个可用的IP地址 。在一个企业的云平台中，对于一些对网络配置要求较高的关键业务虚拟机，可能会采用静态IP地址分配方式，以确保网络配置的稳定性；而对于一些测试用的虚拟机，则可以采用动态IP地址分配方式，提高IP地址的利用率和管理的灵活性 。

6.3.2 网络流量控制流程

网络流量控制是保障网络性能和安全性的重要环节，在OpenStack中，主要通过防火墙规则设置和QoS策略执行等方式来实现 。

防火墙规则设置是网络流量控制的基础手段之一。在Neutron中，可以通过安全组（Security Group）来定义防火墙规则 。安全组本质上是一组允许或拒绝网络流量的规则集合，每个虚拟机都可以关联一个或多个安全组 。当创建安全组时，用户可以定义入站规则和出站规则 。入站规则决定了哪些外部流量可以进入虚拟机，而出站规则则控制虚拟机可以向外部发送哪些流量 。例如，若要允许外部主机通过SSH协议（端口22）访问某个虚拟机，可在该虚拟机关联的安全组中添加一条入站规则，允许源IP地址为指定范围（如企业内部网络的IP地址段）的流量通过端口22进入虚拟机 。

QoS（Quality of Service，服务质量）策略执行则侧重于保障网络流量的质量和性能 。在OpenStack中，可以通过配置QoS策略来对网络流量进行分类、标记和调度 。首先，需要定义流量分类规则，根据流量的源IP地址、目的IP地址、端口号、协议类型等因素，将网络流量划分为不同的类别 。对于视频会议流量，可以将其划分为高优先级类别，因为这类流量对实时性和带宽要求较高；而对于一些非关键的文件传输流量，可以划分为低优先级类别 。

在定义好流量分类规则后，为每个流量类别设置相应的QoS参数，如带宽限制、延迟容忍度、优先级等 。对于高优先级的视频会议流量，可以设置较高的带宽保证，确保其在网络拥塞时能够优先获得足够的带宽，以保证视频会议的流畅性；对于低优先级的文件传输流量，可以限制其最大带宽，避免其占用过多网络资源，影响其他重要流量的传输 。

QoS策略通过Neutron的代理在各个节点上执行 。在计算节点上，Open vSwitch Agent会根据QoS策略对虚拟机发出的流量进行标记和调度 。在网络节点上，L3 Agent会对经过路由器的流量进行QoS处理，确保不同类别的流量能够按照预设的策略进行传输 。通过这些措施，实现了对网络流量的有效控制，保障了网络的性能和稳定性，满足了不同业务场景对网络质量的需求 。

七、编排管理

7.1 定义与功能

在 OpenStack 生态中，编排管理靠 Heat 组件实现，它是基于模板的自动化工具，能整合编排各种资源，实现复杂云基础设施的快速部署管理。Heat 用模板描述资源配置和关系，用户写模板文件，它就可自动创建管理资源，简化云环境搭建管理。

从技术实现看，Heat 基于 OpenStack 的 RESTful API 开发，与 Nova、Neutron、Cinder 等组件协作，调用它们的 API 操作资源，像创建虚拟机时调用 Nova 和 Neutron 的 API 来完成配置。

Heat 资源编排功能强大，通过 yaml 模板文件，用户可定义各种资源信息，如创建含虚拟机、网络、存储的环境时，能在模板中指定虚拟机规格、网络设置、存储配置等，借助相应服务创建资源，还能处理资源依赖关系，如虚拟机依赖网络创建，存储挂载依赖虚拟机创建，通过模板设定可保证创建顺序正确。Heat 还支持云资源生命周期管理，可更新或删除资源，如修改模板可升级虚拟机配置，也可删除所有模板定义的资源，实现快速清理回收。

7.2 架构设计

Heat编排服务的架构设计精妙且复杂，它与多个OpenStack组件紧密协作，共同构建起一个高效的云资源编排体系。Heat Engine是Heat组件的核心部分，它负责执行模板的解析与资源的编排操作 。当用户提交一个编排模板后，Heat Engine会首先对模板进行深入解析，理解其中定义的各种云资源的配置信息以及资源之间的依赖关系。在创建一个包含虚拟机、网络和存储卷的云环境模板时，Heat Engine会准确识别出虚拟机所需的计算资源规格、网络的拓扑结构以及存储卷的大小和挂载方式等关键信息。

（图源：https://www.cnblogs.com/yyuuee/p/14180834.html）

Heat Engine依据解析后的模板信息，与其他OpenStack组件进行交互，以实现资源的创建和管理。它会调用Nova的API来创建虚拟机实例，根据模板中指定的虚拟机规格，如CPU核心数、内存大小、磁盘容量等参数，向Nova发送创建请求，Nova则根据这些参数在合适的计算节点上创建虚拟机 。Heat Engine会调用Neutron的API来配置网络资源，根据模板中定义的虚拟网络类型、子网的IP地址范围、网关设置等信息，Neutron会创建相应的网络基础设施，包括虚拟网络、子网和路由器等，确保虚拟机能够获得正确的网络配置，实现与其他设备的通信 。

在存储资源方面，Heat Engine会调用Cinder的API来创建和管理存储卷。如果模板中要求创建一个特定大小的存储卷并将其挂载到虚拟机上，Heat Engine会向Cinder发送创建存储卷的请求，Cinder会根据请求在合适的存储节点上创建存储卷，并将其挂载到指定的虚拟机上 。Heat Engine还会与Keystone进行交互，以获取用户的认证信息和权限，确保只有经过授权的用户能够执行资源编排操作 。通过这种与多个OpenStack组件的紧密协作，Heat编排服务能够实现对复杂云环境的自动化部署和管理，大大提高了云资源的管理效率和灵活性 。

7.3 工作原理与流程

当用户提交一个编排模板后，Heat Engine首先会对模板进行解析，如前文所述，通过词法分析、语法分析和语义分析，将模板转化为内部数据结构，明确需要创建的资源类型、属性以及资源之间的依赖关系 。在创建一个包含虚拟机、网络和存储卷的云环境模板时，Heat Engine会准确识别出虚拟机所需的计算资源规格、网络的拓扑结构以及存储卷的大小和挂载方式等关键信息 。

Heat Engine会根据资源之间的依赖关系，确定资源的创建顺序。它会优先创建那些没有依赖其他资源的基础资源，如在上述云环境模板中，会先创建网络资源，因为虚拟机的创建依赖于网络的存在 。Heat Engine会调用Neutron的API来创建虚拟网络、子网和路由器等网络基础设施。根据模板中定义的虚拟网络类型、子网的IP地址范围、网关设置等信息，Neutron会在底层创建相应的网络配置 。

在网络资源创建完成后，Heat Engine会创建虚拟机资源。它会调用Nova的API来创建虚拟机实例，根据模板中指定的虚拟机规格，如CPU核心数、内存大小、磁盘容量等参数，向Nova发送创建请求，Nova则根据这些参数在合适的计算节点上创建虚拟机 。在创建过程中，Nova会与Glance服务进行交互，获取模板中指定的镜像，为虚拟机提供操作系统和初始配置 。

Heat Engine会创建存储资源。如果模板中要求创建一个特定大小的存储卷并将其挂载到虚拟机上，Heat Engine会向Cinder发送创建存储卷的请求，Cinder会根据请求在合适的存储节点上创建存储卷，并将其挂载到指定的虚拟机上 。在整个资源编排过程中，Heat Engine会实时监控资源的创建状态，一旦某个资源的创建出现故障，如API调用失败、资源冲突等，Heat Engine会根据预设的策略进行处理，可能会尝试重试创建操作，或者根据资源之间的依赖关系进行回滚，确保整个云环境的编排过程的一致性和可靠性 。当所有资源都成功创建后，Heat会将云环境的状态标记为"创建成功"，用户即可使用编排好的云资源 。

八、故障管理

8.1 定义与重要性

在 OpenStack 云平台中，故障管理是关键功能，能全面、及时、有效地对系统运行中的故障进行检测、诊断和恢复。它像 "健康卫士"，监控系统数据，发现故障隐患或已发生故障。检测到故障后，会运用算法和智能分析技术，结合相关组件信息，排查定位故障原因，如虚拟机无法启动时会综合多因素分析。明确故障后会采取恢复措施，如重启组件、调整资源、修复数据等，保障业务连续性和稳定性。

故障管理对系统稳定运行至关重要，是系统持续服务的关键保障，可减少因故障导致的系统停机和服务中断，确保用户持续稳定使用服务。在降低运维成本上意义重大，能减少人工排查故障时间和工作量，提供自动化检测诊断，快速定位故障并给出方案，提高效率，节省人力和时间成本。它还能增强用户对云平台的信任，保证高可用性和稳定性，为平台长期发展奠定用户基础。

8.2 架构与技术

8.2.1 故障检测架构

在OpenStack的故障管理体系中，故障检测架构融合了多种先进的监控工具和技术，以实现对系统全方位、实时的状态监测。其中，Ceilometer（现已更名为Aodh）作为OpenStack的核心监控组件，发挥着关键作用 。它通过在各个节点上部署的代理，实时采集系统的各类性能指标和状态信息，包括CPU使用率、内存占用率、磁盘I/O速率、网络流量等。这些数据被持续收集并存储在后端的数据库中，为后续的故障分析提供了丰富的数据来源 。

（图源：https://blog.csdn.net/m0_62727902/article/details/130744652）

Ceilometer代理在每个计算节点、控制节点和存储节点上均有部署。在计算节点上，代理会每隔一定时间间隔（如1分钟）采集一次CPU的使用率数据。当某一计算节点的CPU使用率在短时间内持续超过80%时，Ceilometer会将这一异常数据记录下来，并发送到中央数据存储库中 。

除了Ceilometer，OpenStack还常与外部监控工具结合使用，如Zabbix。Zabbix具有强大的分布式监控能力，能够对OpenStack云平台的物理服务器、网络设备等底层基础设施进行深入监控 。它可以监测服务器的硬件状态，如硬盘温度、电源状态等；还能对网络设备的端口状态、链路带宽等进行实时监测。通过与Zabbix的集成，OpenStack能够获取更全面的系统状态信息，进一步提高故障检测的准确性和及时性 。

在数据采集技术方面，采用了基于消息队列的异步采集方式 。以RabbitMQ作为消息队列系统，Ceilometer代理将采集到的数据封装成消息，发送到RabbitMQ队列中。然后，由专门的数据处理模块从队列中读取消息，并进行进一步的处理和存储。这种异步采集方式有效地减少了数据采集对系统性能的影响，确保了系统的正常运行。同时，消息队列的缓冲机制还能够在数据量较大时，避免数据丢失，保证数据的完整性 。

8.2.2 故障诊断与恢复技术

故障诊断在OpenStack的故障管理中至关重要，它主要通过对系统日志分析和故障模式匹配等方法来实现。系统日志包含了丰富的信息，记录了系统运行过程中的各类事件和操作。通过对Nova、Neutron、Cinder等组件的日志进行深入分析，可以发现故障的线索 。在Nova组件的日志中，如果出现大量关于虚拟机创建失败的记录，且错误信息提示为"镜像无法获取"，则可以初步判断故障可能与Glance镜像服务有关 。

故障模式匹配则是将采集到的故障数据与预先定义好的故障模式库进行比对。故障模式库中存储了各种常见故障的特征和表现形式 。在网络故障诊断中，如果发现网络流量突然大幅下降，且伴有大量的数据包丢失，通过与故障模式库中的网络链路故障模式进行匹配，就可以快速判断可能是网络链路出现了问题 。

在故障恢复方面，OpenStack采用了多种技术手段。自动重启是一种常见且有效的恢复方式 。当某个服务组件出现故障时，故障管理系统可以自动尝试重启该组件。在Keystone认证服务出现短暂的服务中断时，故障管理系统会自动重启Keystone服务，通常情况下，经过重启后，服务能够恢复正常运行 。

资源迁移技术在应对硬件故障或资源性能下降等情况时发挥着重要作用 。当某一计算节点的硬件出现故障，如硬盘损坏时，故障管理系统会将该节点上正在运行的虚拟机迁移到其他健康的计算节点上 。这一过程需要借助Nova组件的虚拟机迁移功能，通过实时迁移技术，在不中断虚拟机运行的情况下，将其从故障节点迁移到目标节点，确保业务的连续性 。

在一些复杂的故障场景中，可能需要进行数据修复和网络重新配置 。在存储系统中，如果发现部分数据损坏，故障管理系统会利用数据冗余机制和备份数据进行修复 。在Swift对象存储中，由于数据会在多个存储节点上进行冗余存储，当某个节点上的数据损坏时，系统可以从其他副本中获取数据，并进行修复 。对于网络配置错误导致的故障，故障管理系统会重新检查和调整网络配置参数，如IP地址分配、路由表设置等，以恢复网络的正常运行 。