每个 IT 系统都有一个用途。 为了实现该用途，它需要可供使用。 一些 IT 系统对企业至关重要，因此需要高度可用，并且没有或只有极短的时间部分或完全不可用。 其他系统不太重要，一定量的计划内或计划外停机时间是可以接受的，例如，如果用户可以回退到备用工作流程或只是等到系统再次可用。 许多系统介于这两个极端之间。
高可用性 (HA) 是一种设计方法，用于支持系统在特定时间段内满足预先安排的运行性能级别。 高可用性系统为客户提供可靠的系统和环境，以满足或超过其服务交付的业务要求，并性能达到预期的质量水平。
与灾难恢复 (DR) 相关的高可用性是一个单独的概念。 通常，HA 侧重于避免服务交付的计划外停机，而 DR 侧重于保留发生灾难后将系统恢复到先前可接受状态所需的数据和资源。 实施 DR 计划时，服务交付通常会中断，直到系统恢复为止。 有关详细信息，请参阅备份和灾难恢复。
该领域的另一个常用术语是地理冗余，它通常指通过在其他地理位置提供额外的系统或备份系统，使应用程序或系统能够在数据中心完全中断后正常运行的设计目标。 这种方法有助于预防自然灾害、停电或其他原因造成的数据中心可用性中断。
许多架构师使用一组通用术语来引用和详细描述实现高可用性的系统或组件级方法。 该领域中最常用的术语如下：
衡量可用性的一个指标是正常运行时间，它通常以系统在一段时间内 “可用”的时间百分比来衡量。 可用的定义具有主观性，应该在系统设计流程的早期进行设置，以就此目标达成共识。 所需的可用性级别通常定义为目标正常运行时间，通常以多个 9 表示。 例如：
可用性目标可以按照系统用户与运行该系统的组织之间的服务级别协议 (SLA) 形式正式确定。 通常，SLA 包括除纯可用性目标之外的其他与性能相关的指标，例如预期响应时间，如果存在供应商和客户关系，则可以定义达不到这些目标时的处罚。 内部 SLA 也同样重要，尽管它们通常不包括面向客户的 SLA 的罚款和报告要求。
组织采用的与可用性相关的另一种方法是为他们维护的系统建立重要性层，范围从非必要到基础，具体取决于中断可能对组织产生的影响。 考虑因素可能包括用户体验、财务、声誉和监管影响，并且每个重要性层可能具有不同的目标 SLA 定义。 一些组织可能将某个系统称为 “第 1 层”或 “关键业务”，而其他系统是 “第 2 层”或不太关键的业务系统，因此具有较少的约束或不同的配置。
要设计和构建满足预定义可用性级别的系统，需要一种整体方法以考虑许多不同的方面或主题领域，如下所示：
与仅满足标准级别可用性的基准相比，要构建满足更高正常运行时间需求的系统，通常需要大量的前期和持续的时间和资源投资。但是，高可用性不是一个全有或全无的命题，通常，建议考虑是否存在可以放宽可用性目标而不会显著影响 IT 系统业务价值的子系统。
不需要从头开始制定设计高可用性系统的流程。 在大多数情况下，组织的现有 IT 基础设施、策略、专业知识和偏好将决定企业级 GIS 系统需要适应的整体框架。 这包括支持系统的预期正常运行时间或可用性，以及哪些 IT 组件可用于帮助实现高级别可用性。 考虑决策之间的相互依赖关系，其中一个设计决策通常会产生另一个设计决策。 其中许多细节可以被视为设计约束，这有助于指导设计流程朝着双方都同意的目标发展，此时系统满足总体要求，同时与组织的既定标准保持一致，并平衡成本、可管理性和其他因素。
通常，设计约束分为以下几类：
同样，IT 组织可能会进一步限制基础设施的选择范围，例如，物理硬件、虚拟化层、存储系统、负载均衡器、反向代理等的特定品牌和型号。
利用基于云的商业基础设施即服务 (IaaS) 时，无论是虚拟机还是 Kubernetes 集群，您的选择也会受到限制。
对于 Windows 和 Linux 上的 ArcGIS Enterprise，高可用性指提高 ArcGIS Enterprise 单一部署可用性的措施。 复制的部署（通常在另一个数据中心或另一个云区域中分布）提供灾难恢复功能。 了解有关 Windows 和 Linux 系统上 ArcGIS Enterprise 的高可用性，以及 ArcGIS Enterprise on Kubernetes 中的架构配置文件，以了解该部署模式的选项。
Windows 和 Linux 上的 ArcGIS Enterprise 通过组合每种组件类型的采用不同配置的多台计算机来实现更高级别的可用性。 ArcGIS Enterprise 的组件使用不同的方法来实现高可用性：
高可用性门户站点由两台服务器组成，这两台服务器连接在一起以创建 HA 站点。 它们都是完全冗余的，但系统会将一台计算机作为主要节点维护，另一台计算机为备用节点。 如果主计算机发生故障或无响应，则备用计算机将检测到故障并将自身提升为主计算机。
在 Web 服务器和应用程序级别下，系统为主动-主动系统，因为每个门户节点都能够为传入请求提供服务，并且搜索索引在两个系统之间保持同步。 在数据库级别，存在主数据库（两个 web 服务器都可以从中读取和写入数据）和辅助数据库，在发生故障转移时，由软件保持辅助数据库处于同步状态，因此最好将整个系统描述为主动-被动系统。
高可用性门户还需要负载均衡器，以在两个节点之间分配请求，通常采用轮询方式。 主节点和备用节点通过经由端口的计算机间通信和数据库同步共享状态，但也依赖于门户内容目录的共享文件存储，这可以是 NFS 文件共享、UNC 文件共享或云原生对象存储。
阅读有关配置高可用性 Portal for ArcGIS 部署的详细信息。
高可用性 GIS 服务器站点由两台或多台完全冗余的计算机组成，这些计算机连接在一起形成一个 ArcGIS Server “站点”，其中工作负载在所有节点之间进行负载平衡，这是一种主动-主动配置。 高可用性 GIS 服务器还需要负载均衡器才能将请求路由到成员计算机，通常采用轮询方法，但 Web 流量也可以以主-备用方式路由。
站点中的计算机主要通过服务器目录和配置存储的共享存储位置（通常是 NFS 类型或基于 UNC 的文件共享）共享状态。 对于云系统，云原生选项也可用于服务器目录和配置存储，例如 AWS 中的 DynamoDB 和 S3 存储或 Microsoft Azure 中的 Azure 文件存储。
值得注意的是，某些专用 GIS 服务器角色（例如 GeoEvent Server）无法配置为在多机站点中运行。 因此，要为这些 GIS 服务器角色实现更高级别的可用性，需要考虑一些特殊的注意事项。
阅读有关配置多机站点的详细信息以实现 ArcGIS Server 高可用性部署。 此外，还提供了用于单机高可用性部署的资源。
Web Adaptor 可以冗余地部署在两台或多台计算机上，每个实例在主动-主动配置中都是完全冗余的。 此配置需要接收客户端发送请求的前端负载均衡器，以在两个 Web Adaptor 主机之间分配请求。 文档中提供了更多资源。
关系存储高可用性关系存储恰好由采用主动-主动集群配置的两个完全冗余实例组成。 如果主数据存储计算机发生故障，备用计算机将检测到故障并将自身提升为主计算机，从而允许客户端继续使用托管要素服务而不会中断。
图谱存储：高可用性图形存储恰好由采用主动-主动集群配置的三个完全冗余实例组成。
对象存储：在集群模式下支持对象存储的高可用性，此架构至少需要三台计算机。 在集群模式下，数据将在三台计算机之间复制，这样数据存储在单台计算机中断的情况下仍然可用。
时空大数据存储：这种类型的数据存储还支持集群模式。 集群应包含奇数台计算机（成员之间达成共识所需的数量）以及至少三台计算机。 这些配置都是主动-主动高可用性配置。
文档主题配置高可用性托管数据存储提供了其他指导、步骤和建议。
数据库资源的可用性是一个专业架构领域，每个单独的数据库产品都有许多提供者特定选项，包括主动-主动和主动-被动模式。 通常，当用于访问或发布服务的数据注册流程使用 DNS 别名 或灵活 IP 时，ArcGIS 可以连接到这些配置，将始终从 ArcGIS 访问，但如果主系统中断，则可能会指向不同的后端数据库。 在这种情况下，ArcGIS 组件不知道后端数据库的变化，并在相同的凭据、方案和行可用的情况下继续按预期工作。
ArcGIS Enterprise on Kubernetes 使用架构配置文件的概念来配置服务的可用性并提升可靠性。 此配置在部署期间定义，可以增加为实现冗余而部署的 pod 数量，其中包括跨云部署中的可用区。 有关附加信息，请参阅博客文章 ArcGIS Enterprise on Kubernetes 中的可靠性。
要做出与高可用性相关的明智且有效的选择，请考虑以下设计建议：