高可用性

每个 IT 系统都有一个用途。 为了实现该用途,它需要可供使用。 一些 IT 系统对企业至关重要,因此需要高度可用,并且没有或只有极短的时间部分或完全不可用。 其他系统不太重要,一定量的计划内或计划外停机时间是可以接受的,例如,如果用户可以回退到备用工作流程或只是等到系统再次可用。 许多系统介于这两个极端之间。

定义和了解可用性

高可用性 (HA) 是一种设计方法,用于支持系统在特定时间段内满足预先安排的运行性能级别。 高可用性系统为客户提供可靠的系统和环境,以满足或超过其服务交付的业务要求,并性能达到预期的质量水平。

注:

与灾难恢复 (DR) 相关的高可用性一个单独的概念。 通常,HA 侧重于避免服务交付的计划外停机,而 DR 侧重于保留发生灾难后将系统恢复到先前可接受状态所需的数据和资源。 实施 DR 计划时,服务交付通常会中断,直到系统恢复为止。 有关详细信息,请参阅备份和灾难恢复

该领域的另一个常用术语是地理冗余,它通常指通过在其他地理位置提供额外的系统或备份系统,使应用程序或系统能够在数据中心完全中断后正常运行的设计目标。 这种方法有助于预防自然灾害、停电或其他原因造成的数据中心可用性中断。

许多架构师使用一组通用术语来引用和详细描述实现高可用性的系统或组件级方法。 该领域中最常用的术语如下:

  • 主动-主动,这是一种容错模式,依赖于两个或多个主动接收和处理请求的系统。 在主动-主动系统中,接收请求的每个节点与其他节点相等,并且请求通常进行负载均衡,从而以大致相等的比例发送到每个后端节点。
  • 主动-被动(也称为主要/备用),是一种容错模式,其中用户请求完全流向一个系统,第二个系统备用以在需要时使用:主系统故障(主动系统停止处理请求),或计划或规划的切换,以上任一场景都会导致用户流量被发送到被动系统,此时该系统被视为主动系统。
  • 故障转移系统旨在与活动系统保持完全同步,但要准备好接收流量,仅在主系统由于某种原因发生故障时才接收该流量。 故障转移系统类似于主动-被动配置,但与该系统的“故障转移”相关联的工作流可能不同。

可用性目标

衡量可用性的一个指标是正常运行时间,它通常以系统在一段时间内“可用”的时间百分比来衡量。 可用的定义具有主观性,应该在系统设计流程的早期进行设置,以就此目标达成共识。 所需的可用性级别通常定义为目标正常运行时间,通常以多个 9 表示。 例如:

  • 99%(两个 9)- 相当于每年允许的停机时间为 3.65 天
  • 99.9%(三个 9)- 相当于每年允许的停机时间为 8.77 小时

可用性目标可以按照系统用户与运行该系统的组织之间的服务级别协议 (SLA) 形式正式确定。 通常,SLA 包括除纯可用性目标之外的其他与性能相关的指标,例如预期响应时间,如果存在供应商和客户关系,则可以定义达不到这些目标时的处罚。 内部 SLA 也同样重要,尽管它们通常不包括面向客户的 SLA 的罚款和报告要求。

重要性层

组织采用的与可用性相关的另一种方法是为他们维护的系统建立重要性层,范围从非必要到基础,具体取决于中断可能对组织产生的影响。 考虑因素可能包括用户体验、财务、声誉和监管影响,并且每个重要性层可能具有不同的目标 SLA 定义。 一些组织可能将某个系统称为“第 1 层”或“关键业务”,而其他系统是“第 2 层”或不太关键的业务系统,因此具有较少的约束或不同的配置。

要设计和构建满足预定义可用性级别的系统,需要一种整体方法以考虑许多不同的方面或主题领域,如下所示:

  • 精心选择更高级别的软件和硬件组件,这些组件经过专门设计,可缩短平均故障间隔 (MTBF),而不是使用商品化组件。
  • 通过提供所有组件的冗余,消除系统中的所有单点故障。 单点故障指一个软件或硬件在它发生故障时导致整个系统不可用。 借助单点故障,系统可以容忍任一组件发生故障,这不会明显影响可用性。
  • 制定计划以在系统确实不可用时恢复系统并测试这些计划。 这可能包括定义使系统再次可用所需的可接受时间量目标,以及允许的数据丢失量。
  • 实施以变更管理为重点的策略和程序,以最大限度地减少意外或异常中断的可能性,例如由于人为错误。

与仅满足标准级别可用性的基准相比,要构建满足更高正常运行时间需求的系统,通常需要大量的前期和持续的时间和资源投资。但是,高可用性不是一个全有或全无的命题,通常,建议考虑是否存在可以放宽可用性目标而不会显著影响 IT 系统业务价值的子系统。

设计注意事项

不需要从头开始制定设计高可用性系统的流程。 在大多数情况下,组织的现有 IT 基础设施、策略、专业知识和偏好将决定企业级 GIS 系统需要适应的整体框架。 这包括支持系统的预期正常运行时间或可用性,以及哪些 IT 组件可用于帮助实现高级别可用性。 考虑决策之间的相互依赖关系,其中一个设计决策通常会产生另一个设计决策。 其中许多细节可以被视为设计约束,这有助于指导设计流程朝着双方都同意的目标发展,此时系统满足总体要求,同时与组织的既定标准保持一致,并平衡成本、可管理性和其他因素。

通常,设计约束分为以下几类:

  • 业务需求:组织的业务要求决定了可接受的停机时间,范围从零停机时间到系统还原前的数小时或数天。 这称为恢复时间目标 (RTO)。 业务需求还表示在发生故障时可以容忍数据丢失量(以时间表示)。 这称为恢复点目标 (RPO),范围通常在 0 秒到一周的数据丢失量之间。
  • 部署模式:选择给定的部署模式通常会预先确定在详细设计决策中必须考虑可用性考虑因素的程度。 换句话说,在围绕 SaaS 或 PaaS 产品构建系统时,其中许多决策已经由托管该产品的组织做出。 另一方面,将 GIS 服务器软件部署到您的组织拥有和管理的数据中心时,将尽可能提高满足确切可用性要求方面的灵活性,但随之而来的责任也最多。
  • 基础设施:在大多数情况下,如果由 IT 专业人员设计和构建 GIS 系统以部署到贵组织运营的数据中心,则这些专业人员无需关心基本的物理基础设施,例如托管设施、电力、冷却和网络,因为这些基础设施已建立,并且通常可实现这些基本商品的高级别可用性。
  • 维护:对于某些系统,在不停机的情况下修补或更新系统的能力至关重要,以确保用户不受影响或其他系统能够持续运行。 在此类情况下,滚动修补或使用蓝绿或主要/备用环境可能与这些目标一致,但在任何系统设计中,都需要考虑所需维护操作和维护间隔的潜在影响。

同样,IT 组织可能会进一步限制基础设施的选择范围,例如,物理硬件、虚拟化层、存储系统、负载均衡器、反向代理等的特定品牌和型号。

利用基于云的商业基础设施即服务 (IaaS) 时,无论是虚拟机还是 Kubernetes 集群,您的选择也会受到限制。

  • 软件:系统包含的软件组件支持更高级别可用性的级别各不相同,范围从无指定支持到完全支持和记录的高可用性配置。 它们的程度也不同:无法在给定软件上实现所有级别的可用性,这限制了可以实现的 SLA、RPO 或 RTO。
  • 人员和流程:通常最好利用既定流程和程序来构建和管理组织已建立的高可用性系统,以从现有专业知识中受益。

高可用性模式

对于 ArcGIS Enterprise,高可用性指提高 ArcGIS Enterprise 单一部署可用性的措施。 复制的部署(通常在另一个数据中心或另一个云区域中分布)提供灾难恢复功能。 了解 ArcGIS Enterprise 中的高可用性

ArcGIS Enterprise 通过组合采用不同配置的多台计算机来实现更高级别的可用性。 ArcGIS Enterprise 的组件使用不同的方法来实现高可用性:

Portal for ArcGIS

高可用性门户站点由两台服务器组成,这两台服务器连接在一起以创建 HA 站点。 它们都是完全冗余的,但系统会将一台计算机作为主要节点维护,另一台计算机为备用节点。 如果主计算机发生故障,备用计算机将检测到故障并将自身提升为主计算机。

在 Web 服务器级别下,系统为主动-主动系统,因为每个门户节点都能够为传入请求提供服务,并且搜索索引在两个系统之间保持同步。 但是,只有一个节点处理状态更改,其中编辑、成员邀请和配置将保存到门户数据库,因此整个系统被视为主动-被动系统。

高可用性门户还需要负载均衡器,以在两个节点之间分配请求,通常采用轮询方式。 主节点和备用节点通过经由端口的计算机间通信和数据库同步共享状态,但也依赖于门户内容目录的共享文件存储,这可以是 NFS 文件共享、UNC 文件共享或云原生对象存储。

阅读有关配置高可用性 Portal for ArcGIS 部署的详细信息。

GIS 服务器

高可用性 GIS 服务器站点由两台或多台完全冗余的计算机组成,这些计算机连接在一起形成一个 ArcGIS Server“站点”,其中工作负载在所有节点之间进行负载平衡,这是一种主动-主动配置。 高可用性 GIS 服务器还需要负载均衡器才能将请求路由到成员计算机,通常采用轮询方法,但 Web 流量也可以以主-备用方式路由。

站点中的计算机主要通过服务器目录和配置存储的共享存储位置(通常是 NFS 类型或基于 UNC 的文件共享)共享状态。 对于云系统,云原生选项也可用于配置存储,例如 AWS 中的 DynamoDB 和 S3 存储或 Microsoft Azure 中的 Azure 文件存储。

注:

值得注意的是,某些专用 GIS 服务器角色(例如 GeoEvent Server)无法配置为在多机站点中运行。 因此,要为这些 GIS 服务器角色实现更高级别的可用性,需要考虑一些特殊的注意事项。

阅读有关配置多机站点的详细信息以实现 ArcGIS Server 高可用性部署。 此外,还提供了用于单机高可用性部署的资源。

Web Adaptor

Web Adaptor 可以冗余地部署在两台或多台计算机上,每个实例在主动-主动配置中都是完全冗余的。 此配置需要接收客户端发送请求的前端负载均衡器,以在两个 Web Adaptor 主机之间分配请求。 文档中提供了更多资源。

ArcGIS Data Store

关系数据存储高可用性关系数据存储恰好由采用主动-主动集群配置的两个完全冗余实例组成。 如果主数据存储计算机发生故障,备用计算机将检测到故障并将自身提升为主计算机,从而允许客户端继续使用托管要素服务而不会中断。

Graph Data Store:高可用性图形存储恰好由采用主动-主动集群配置的三个完全冗余实例组成。

对象存储:在集群模式下支持对象存储的高可用性,此架构至少需要三台计算机。 在集群模式下,数据将在三台计算机之间复制,这样数据存储在单台计算机中断的情况下仍然可用。

时空大数据存储:这种类型的数据存储还支持集群模式。 集群应包含奇数台计算机(成员之间达成共识所需的数量)以及至少三台计算机。 这些配置都是主动-主动高可用性配置。

文档主题配置高可用性托管数据存储提供了其他指导、步骤和建议。

关系数据库

数据库资源的可用性是一个专业架构领域,每个单独的数据库产品都有许多提供者特定选项,包括主动-主动和主动-被动模式。 通常,当用于访问或发布服务的数据注册流程使用 DNS 别名灵活 IP 时,ArcGIS 可以连接到这些配置,将始终从 ArcGIS 访问,但如果主系统中断,则可能会指向不同的后端数据库。 在这种情况下,ArcGIS 组件不知道后端数据库的变化,并在相同的凭据、方案和行可用的情况下继续按预期工作。

设计建议

要做出与高可用性相关的明智且有效的选择,请考虑以下设计建议:

  • 备份:要避免数据丢失和减少停机时间,最简单的方法是创建 ArcGIS 部署的备份。 这允许您恢复创建备份时存在的项目,并显著缩短操作时间。
  • 管理只读和读/写系统:如果您的应用程序或系统为只读系统,其中用户主要查看在其他位置管理的数据,则实现高可用性配置会更简单,因为可以使用主动-主动配置。 如果编辑是由用户创建的,则在读/写系统中,通常存在架构的主动-主动和主动-被动层混合,这允许维护主要主动记录数据库,同时维护被动、备用或故障转移系统,以在发生中断时准备好接收流量。
  • 重复和冗余:实施特定系统组件的多个实例,可能包括地理冗余,以减少单点故障。 考虑维护系统所需的技能。 假设一个人也很容易成为单点故障。
  • 测试计划和系统监测:通过测试压力、性能和故障转移功能,评估系统满足所需服务级别的能力。 所有测试计划和相关活动需要包含在整体系统治理中。 持续监测系统以纠正问题,以免造成大范围或不可恢复的中断。
  • 其他高可用性最佳实践包括自动化协作负载平衡工作负载分离
Top