在本文中，我们将使用基于分布式存储的 Kubernetes 部署来构建一个 IRIS 的高可用配置，而不使用“传统的”IRIS Mirror。 这种部署将能够容忍与基础架构相关的故障，如节点、存储和可用区故障。 所描述的方法可以大大降低部署的复杂性，代价是 RTO的略微延长。

最近在多家现场都遇到了备机长时间宕机导致镜像日志写满磁盘的问题。在这里我将对这个问题发生的原因、发生后的处理、和如何预防这类问题发生进行一些讨论。

问题的发生一般始于一些原因导致的主机（如，01）宕机，进而触发镜像的主备切换。切换后备机（如，02）成为主机，并无缝接管业务。由于业务不受影响，如果不注意监控环境的话，很可能现场技术人员长时间都注意不到镜像的备机（01）是宕机状态。

备机长时间宕机会导致如下问题：

1. 这种情况下如果主机（02）再次遇到问题宕机，镜像将无法发挥其高可用性，无法保持业务稳定运行。

2. 主机（02）产生的镜像日志将无法同步到备机（01）。未同步的日志将一直被保存在主机（02）上不被删除。长此以往镜像日志磁盘将被写满，同样导致主机（02）宕机。

问题发现时切记不要手动从文件夹直接删除主机（02）上的镜像日志。未同步的日志一旦手动删除，镜像将无法自动同步，需要重做主备镜像。

问题发现时如果主机（02）还未宕机，此时尝试解决备机（01）问题，启动备机（01），等待镜像自动同步即可。同步完成之后镜像日志将可以被定时任务定时清除。如果遇到较为复杂的情况，现场请第一时间联系您的软件供应商，软件供应商将协同系联软件全球响应中心一起来解决您遇到的具体问题。

为了避免以上的问题发生，现场运维需要对镜像的状态和磁盘的状态配置监控。

++ 更新：2018 年 8 月 1 日

使用内置于 Caché 数据库镜像的 InterSystems 虚拟 IP (VIP) 地址有一定的局限性。特别是，它只能在镜像成员驻留在同一网络子网时使用。当使用多个数据中心时，由于增加了网络复杂性（ 此处有更详细的讨论），网络子网通常不会“延伸”到物理数据中心之外。出于类似的原因，当数据库托管在云端时，虚拟 IP 通常无法使用。

负载均衡器（物理或虚拟）等网络流量管理设备可用于实现相同级别的透明度，为客户端应用程序或设备提供单一地址。网络流量管理器自动将客户端重定向到当前镜像主服务器的真实 IP 地址。自动化旨在满足灾难后 HA 故障转移和 DR 升级的需求。

我们客户的一个共同需求是配置 HealthShare HealthConnect 和 IRIS的高可用性模式。

市场上的其他集成引擎通常被宣传为具有“高可用性”配置，但事实并非如此。通常，这些解决方案与外部数据库一起使用，因此，如果这些数据库未配置为高可用性，当发生数据库崩溃或与它的连接丢失时，整个集成工具将变得不可用。

对于 InterSystems 解决方案，这个问题不存在，因为数据库是工具本身的一部分和核心。 InterSystems 如何解决高可用性问题？深奥的配置会把我们拖入异化和疯狂的漩涡？不！在 InterSystems，我们倾听并处理了您的投诉（正如我们一直努力做的那样 ;)），并且我们已将镜像功能提供给所有用户和开发人员。

镜像

镜像如何工作？这个概念本身非常简单。如您所知，IRIS 和 HealthShare 都使用一个日志系统，该系统记录每个实例的数据库上的所有更新操作。这个日志系统是后来帮助我们在崩溃后恢复实例而不会丢失数据的系统。好吧，这些日志文件在镜像中配置的实例之间发送，允许并保持镜像中配置的实例永久更新。

架构

让我们简要解释一下在 Mirror 中配置的系统架构是什么样的：

在Cache 2018之前的版本中，数据库的高可用是通过第三方HA软件保障的，Cache数据库在2018以后及IRIS支持MIRROR技术，通过MIRROR可以保障数据库的高可用及数据的冗余，那么在新版本中，第三方HA软件与MIRROR是否可以同时使用以实现更高的数据库可用性？使用起来有哪些需要注意的？本文重点介绍探讨上述两个问题。

为得出正确结论，我们搭建了如下实验环境：

       我们采用3个服务器节点A、B、C分别部署IRIS 2021.1数据库，其中A节点、B节点部署第三方HA软件组成数据库高可用主备集群（本例中，采用的是基于POWER平台的PowerHA），该集群中定义A节点为主节点，B节点为备用节点，HA集群的共享资源组存放在共享SAN存储上，通过HA，生成HA集群的对外服务IP，即我们通常说的Service ip，保证在生产节点发生网络故障、主机故障、以及操作系统故障、手动切换等情况下，IRIS服务、共享资源组、以及HA的Service IP可自动切换至另外一台服务器，保障IRIS高可用，经测试，HA集群内部节点间服务切换时间约为30秒。

在虚拟化环境中使用镜像，构成镜像的InterSystems IRIS实例被安装在虚拟主机上，创造了一个混合的高可用性解决方案，将镜像的优点与虚拟化的优点结合起来。镜像通过自动故障切换对计划内或计划外的故障提供即时响应，而虚拟化HA软件在计划外的机器或操作系统故障后自动重新启动承载镜像成员的虚拟机。这允许失败的成员迅速重新加入镜像，充当备份（或在必要时作为主机）。

当镜像被配置在虚拟化环境中时，请参考以下建议：

• 故障转移成员的虚拟主机和备机不可以配置在同一台物理机上。

• 为了避免单点存储故障，故障转移成员上的InterSystems IRIS实例所使用的存储应永久隔离在不同磁盘组或存储阵列的独立数据存储中。

• 在虚拟化平台层面上进行的一些操作，如备份或迁移，可能会导致故障转移成员长时间没有反应，从而导致不需要的故障转移或不理想的警报频率。为了解决这个问题，你可以增加QoS超时设置。

• 在进行导致故障转移成员连接中断的计划性维护操作时，你可以暂时停止备份上的镜像，以避免不必要的故障转移和警报。

1. VMWare快照引起的网络中断导致非计划内主备机切换问题

1.1 问题描述

在创建虚拟机快照时，虚拟机需要短时间的冻结，这个短时间冻结通常指虚拟机静默，在静默过程中网络连接处于中断状态。由于数据库的不断增长，使用VMWare快照的方式对虚拟机进行备份的时长也会不断增加，当对虚拟机进行快照的时长长于InterSystems镜像服务质量 (QoS) 超时时间，即当主机网络中断超过QoS超时时间，仲裁机与备机观察并相互确认与主机的连接丢失后，将发起切换过程，使原备机成为主机并将虚拟IP从主机MAC地址解绑后重绑定到备机的MAC地址上。特别需要注意的是，在这种由于网络中断引起的切换中，仲裁与备机都无法得知主机的实际工作状态。因此，在主机网络连接恢复后，为了为了避免因切换期间主机还在处理数据导致主备机间数据不一致，备机主动发起请求让主机下线，关闭主机，此时主机状态显示为关闭（Down）。

1.2 解决方案

对于由于虚拟机快照引起的网络中断造成的非计划内主备切换问题，请参考以下两种解决方案：

高可用性（HA）指的是使系统或应用程序在很高比例的时间内保持运行，最大限度地减少计划内和计划外的停机时间。

维持系统高可用性的主要机制被称为故障转移。在这种方法下，一个故障的主系统被一个备份系统所取代；也就是说，生产系统故障转移到备份系统上。许多HA配置还提供了灾难恢复（DR）的机制，即在HA机制无法保持系统的可用性时，也能及时恢复系统的可用性。

本文简要讨论了可用于基于InterSystems IRIS的应用程序的HA策略机制，提供了HA解决方案的功能比较，并讨论了使用分布式缓存的故障转移策略。

操作系统级别的集群HA

在操作系统层面上提供的一个常见的HA解决方案是故障转移集群，其中主要的生产系统由一个（通常是相同的）备用系统补充，共享存储和一个跟随活动成员的集群IP地址。在生产系统发生故障的情况下，备用系统承担生产工作量，接管以前在故障主系统上运行的程序和服务。备用机必须能够处理正常的生产工作负载，只要恢复故障主机所需的时间就可以了。也可以选择让备用机成为主机，一旦主机恢复，故障主机将成为备用机。

安装Arbiter

为了将自动故障转移扩展到尽可能广泛的故障情况，InterSystems建议你为每个镜像配置一个仲裁机。

要充当仲裁者，系统必须有一个正在运行的ISCAgent进程。由于ISCAgent是与InterSystems IRIS一起安装的，任何承载一个或多个InterSystems IRIS实例的系统都符合这一要求，可以被配置为仲裁者而无需进一步准备；但是，承载一个或多个故障转移或DR异步镜像成员的系统不应该被配置为该镜像的仲裁者。

没有托管InterSystems IRIS实例的系统可以通过安装Arbiter方式的作为仲裁者。请从InterSystems公司下载适合你的仲裁者系统平台的ISCAgent安装包，然后，安装ISCAgent。

注意：Arbiter的版本要和InterSystems IRIS安装版本保持一致。

在Windows上安装Arbiter

在Windows系统上，只需执行安装文件，例如ISCAgent-2020.1.0.540.0-win_x64.exe。

在Linux上安装Arbiter

所有源代码均在: https://github.com/antonum/ha-iris-k8s 

在上一篇文章中，我们讨论了如何在k8s集群上建立具有高可用性的IRIS，基于分布式存储，而不是传统的镜像。作为一个例子，那篇文章使用了Azure AKS集群。在这一篇中，我们将继续探讨k8s上的高可用配置。这一次，基于Amazon EKS（AWS管理的Kubernetes服务），并将包括一个基于Kubernetes 快照进行数据库备份和恢复的选项。

安装

开始干活. 首先需要一个AWS账户,安装 AWS CLI,kubectl 和 eksctl 工具. 要创建新的集群，请运行以下命令:

eksctl create cluster \
--name my-cluster \
--node-type m5.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

这个命令需要大约15分钟，部署EKS集群并使其成为你的kubectl工具的默认集群。你可以通过运行以下代码来验证你的部署：

现在我们院区也遇到这样一个问题。关于cache的高可用架构现有有两个方案：

1.选择双节点的完全无共享架构的自动转移镜像集群外加一个灾难恢复镜像

2.就像你提问的那种，两台主机先做Rose HA用一套双活存储实现高可用，然后再弄一台服务器做Rose HA的单机镜像（有可能是同步也有可能是异步那种比如灾难恢复镜像）

现在想问问如果单纯考虑切换时候对业务的影响，如果切换的中断时长什么的，用哪个最好啊？第二种方案真有很多单位用么？

希望有大神能替我解答一下，谢谢。

    我的几个孩子都很喜欢手工艺品，您可能会觉得作为一个父亲我会用夸张的表情表扬他们很有创意然后还拍照片发到Pinterest（世界上最大的图片社交分享网站）上去，但是我从来都没这么做过。我肯定爱我的孩子，我也确实认为他们有创意，但老实讲如果你有一个正上小学的孩子，你肯定很清楚他们实际的水平。

对于那些在某种程度上需要测试ECP的水平可扩展性（计算能力和/或用户和进程的并发性），但又懒得建立环境、配置服务器节点等的人来说，我刚刚在Open Exchange上发布了OPNEx-ECP部署的应用/示例。 

本文提供了一个参考架构，作为示例说明基于 InterSystems Technologies（适用于 Caché、Ensemble、HealthShare、TrakCare 以及相关的嵌入式技术，例如 DeepSee、iKnow、Zen 和 Zen Mojo）提供的强大性能和高可用性应用。
Azure 有两种用于创建和管理资源的不同部署模型：Azure Classic 和 Azure Resource Manager。本文中的详细信息基于 Azure Resource Manager (ARM) 模型。

本报告介绍了ESG 集团对多个数据库管理软件产品进行的并发数据摄取和实时查询性能验证测试。测试结果表明，InterSystems IRIS 数据平台可在摄取上亿条记录的同时执行数百万条查询，响应时间达到微秒级，其性能优于其他传统产品和内存产品。

Amazon Web Services (AWS) 云提供广泛的云基础设施服务，例如计算资源、存储选项和网络，这些都非常实用：按需提供，几秒内就可用，采用即付即用定价的模式。 新服务可得到快速配置，且前期无需支出大量资金。 这使得大企业、初创公司、中小型企业以及公共部门的客户可以访问他们所需的基础设施，从而快速响应不断变化的业务需求。

更新日期：2019 年 10 月 15 日

Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品，包括最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。

以下概述和详细内容由谷歌提供，可在此处找到。

概述

GCP 资源

GCP 由一系列物理资产（例如计算机和硬盘驱动器）和虚拟资源（例如虚拟机（VM））组成，它们分布于谷歌遍布全球的数据中心。 每个数据中心的位置都是一个泛区域。 每个区域都是地区的集合，这些地区在该区域内彼此分离。 每个地区都通过一个名称标识，名称由字母标识符和相应区域的名称组成。

这种资源分配带来众多优势，包括发生故障时提供冗余，以及通过将资源配置在客户端附近来减少延迟。 这种分配也引入一些有关如何统筹资源的规则。

访问 GCP 资源

在云计算中，物理硬件和软件变成了服务。 这些服务提供对基础资源的访问。 在 GCP 上开发基于 InterSytems IRIS 的应用程序时，您可混合和匹配这些服务，组合它们来提供您所需的基础架构，然后添加您的代码来实现您要构建的方案。 有关可用服务的详细信息， 可在此处找到。

项目

您分配和使用的任何 GCP 资源必须属于一个项目。 项目由设置、权限和其他描述应用程序的元数据组成。 根据区域和地区规则，单个项目中的资源能够轻松协作，例如通过内部网络进行通信。 每个项目包含的资源在项目边界上保持独立；您只能通过外部网络连接来互连它们。

服务交互

GCP 提供 3 种与服务和资源交互的基本方法。

控制台

Google Cloud Platform 控制台提供基于 web 的图形用户界面，供您管理 GCP 项目和资源。 使用 GCP 控制台，您可创建新项目，或选择现有项目，可使用您在项目环境中创建的资源。 您可以创建多个项目，因此您可以使用项目以任何对您有意义的方式分开您的工作。 例如，如果您想确保只有某些团队成员可以访问项目中的资源，而所有团队成员可以继续访问另一个项目中的资源，则可以开始一个新项目。

命令行界面

如果您喜欢在终端窗口中工作，Google Cloud SDK 提供 gcloud 命令行工具，让您可以访问所需的命令。 gcloud 工具可用于管理您的开发工作流程和 GCP 资源。 有关 gcloud 的详细内容可在此处找到。

GCP 也提供 Cloud Shell，一种基于浏览器的 GCP 交互 shell 环境。 可从 GCP 控制台访问 Cloud Shell。 Cloud Shell 提供：

客户端库

Cloud SDK 拥有客户端库，让您轻松创建和管理资源。 GCP 客户端库公开 API 有两个主要目的：

• 应用 API 提供对服务的访问。 应用 API 针对支持的语言（例如 Node.js 和 Python ）进行了优化。 客户端库围绕服务隐喻而设计，因此您可以更自然地使用服务，并编写更少的样板代码。 客户端库还提供身份验证和授权助手。 有关详细信息可在此处找到。
• 管理 API 提供资源管理功能。 例如，如果您想构建自己的自动化工具，可以使用管理 API。

您还可以使用 Google API 客户端库来访问产品的 API，如 Google Map、Google Drive 和 YouTube。 有关 GCP 客户端库的详细信息可在此处找到。

InterSystems IRIS 示例体系结构

本文部分内容阐述了面向 GCP 的 InterSystems IRIS 部署示例，旨在为特定应用程序的部署抛砖引玉。 这些示例可用作很多部署方案的指南。 此参考体系结构拥有非常强大的部署选项，从最小规模的部署，到满足计算和数据需求的大规模可扩展工作负载，不一而足。

本文还介绍了高可用性和灾难恢复选项以及其他建议的系统操作。 个体可对这些进行相应的修改以支持其组织的标准实践和安全策略。

针对您的特定应用，就基于 GCP 的 InterSystems IRIS 部署，您可联系 InterSystems 进一步探讨。

示例参考体系结构

以下示例体系结构按照容量和功能逐步升级的顺序讲述了几种不同的配置， 分别为小型开发/生产/大型生产/分片集群生产。先从中小型配置讲起，然后讲述具有跨地区高可用性以及多区域灾难恢复的大规模可扩展性解决方案。 此外，还讲述了一个将 InterSystems IRIS 数据平台的新分片功能用于大规模处理并行 SQL 查询的混合工作负载的示例。

小型开发配置

在本示例中，显示了一个能支持 10 名开发人员和 100GB 数据的小型开发环境，这基本是最小规模的配置。 只要适当地更改虚拟机实例类型并增加持久性磁盘存储，即可轻松支持更多的开发人员和数据。

这足以支持开发工作，并让您熟悉 InterSystems IRIS 功能以及 Docker 容器的构建和编排（如果需要的话）。 小型配置通常不采用具有高度可用性的数据库镜像，但是如果需要高可用性，则可随时添加。

小型配置示例图

示例图 2.1.1-a 显示了图表 2.1.1-b 中的资源。 其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。

下列 GCP VPC 项目资源是针对最小规模的配置提供的。 可根据需求添加或删除 GCP 资源。

小型配置 GCP 资源

下表提供了小型配置 GCP 资源的示例。

需要考虑适当的网络安全和防火墙规则，以防止对 VPC 的不必要访问。 谷歌提供网络安全最佳做法供您入门使用，可在此处找到。

如果您的安全策略确实需要内部 VM 实例，则您需要在网络上手动设置 NAT 代理和相应的路由，以便内部实例可以访问互联网。 务必要明确，您无法使用 SSH 直接完全连接到内部 VM 实例。 要连接到此类内部机器，必须设置具有外部 IP 地址的堡垒实例，然后建立隧道通过它。 可以配置堡垒主机，以提供进入 VPC 的外部入口点。

有关堡垒主机的详细信息，可在此处找到。

产品配置

在本示例中，展示了一个规模较大的产品配置，其采用 InterSystems IRIS 数据库镜像功能来支持高可用性和灾难恢复。

此配置包括 InterSystems IRIS 数据库服务器同步镜像对，该镜像服务器在区域 1 内分为两个地区，用于自动故障转移，在区域 2 内的第三个 DR 异步镜像成员用于灾难恢复，以防万一整个 GCP 区域脱机 。

InterSystems Arbiter 和 ICM 服务器部署在单独的第三个地区，以提高弹性。  此示例体系结构还包括一组可选的负载均衡 web 服务器，用于支持启用 Web 的应用程序。 这些使用 InterSystems 网关的 web 服务器可以根据需要进行缩放。

产品配置示例图

示例图 2.2.1-a 显示了图表 2.2.1-b 中的资源。 其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。

建议将以下 GPC VPC 项目中的资源作为分片集群部署的最低配置。 可根据需求添加或删除 GCP 资源。

产品配置 GCP 资源

下表提供了产品配置 GCP 资源的示例。

大型产品配置

在本示例中，提供了一个大规模可缩放性配置。该配置通过扩展 InterSystems IRIS 功能也引入使用 InterSystems 企业缓存协议 (ECP：EnterpriseCacheProtocol) 的应用程序服务器，实现对用户的大规模横向缩放。 本示例甚至包含了更高级别的可用性，因为即使在数据库实例发生故障转移的情况下，ECP 客户端也会保留会话细节。 多个 GCP 地区与基于 ECP 的应用程序服务器和部署在多个区域中的数据库镜像成员一起使用。 此配置能够支持每秒数千万次的数据库访问和数万亿字节数据。

大型产品配置示例图

示例图 2.3.1-a 显示了图表 2.3.1-b 中的资源。  其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。

此配置中包括一个故障转移镜像对，四个或更多的 ECP 客户端（应用程序服务器），以及每个应用程序服务器对应一个或多个 Web 服务器。 故障转移数据库镜像对在同一区域中的两个不同 GCP 地区之间进行划分，以提供故障域保护，而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中，以提高弹性。

灾难恢复扩展至第二个 GCP 区域和地区，与上一示例中的情况类似。 如果需要，可以将多个 DR 区域与多个 DR 异步镜像成员目标一起使用。

建议将以下 GPC VPC 项目中的资源作为大型生产部署的最低配置。 可根据需求添加或删除 GCP 资源。

大型产品配置 GCP 资源

下表提供了大型产品配置 GCP 资源的示例。

采用 InterSystems IRIS 分片集群的生产配置

在此示例中，提供了一个针对 SQL 混合工作负载的横向缩放性配置，其包含 InterSystems IRIS 的新分片集群功能，可实现 SQL 查询和表跨多个系统的大规模横向缩放。 本文后面将详细讨论 InterSystems IRIS 分片集群及其功能。

采用 InterSystems IRIS 分片集群的生产配置

示例图 2.4.1-a 显示了图表 2.4.1-b 中的资源。  其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。

此配置中包括四个镜像对，它们为数据节点。 每个故障转移数据库镜像对在同一区域中的两个不同 GCP 地区之间进行划分，以提供故障域保护，而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中，以提高弹性。

此配置允许从集群中的任何数据节点使用所有的数据库访问方法。 大型 SQL 表数据在物理上跨所有数据节点进行分区，以实现查询处理和数据卷的大规模并行。 将所有这些功能组合在一起，就可以支持复杂的混合工作负载，比如大规模分析 SQL 查询及引入的新数据，所有这一切均在一个 InterSystems IRIS 数据平台中执行。

注意，上面图表中以及下表“资源类型”列中的术语“计算[Engine]”是一个表示 GCP（虚拟）服务器实例的 GCP 术语，将在本文的 3.1节中做进一步介绍。 它并不表示或暗示本文后面所描述的集群体系结构中对“计算节点”的使用。

建议将以下 GPC VPC 项目中的资源作为分片集群部署的最低配置。 可根据需求添加或删除 GCP 资源。

使用分片集群配置 GCP 资源的产品

下表提供了分片集群配置 GCP 资源的示例。

云概念简介

Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的云环境，使其具备完备的功能，支持所有的 InterSystems 产品，包括支持基于容器的 DevOps 及最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、系统操作、高可用性、灾难恢复、安全控制和其他管理程序。 本文档将介绍所有云部署涉及的三个主要组件：计算、存储和网络。

计算引擎（虚拟机）

GCP 中存在数个针对计算引擎资源的选项，以及众多虚拟 CPU 和内存规范及相关存储选项。 在 GCP 中值得注意的一点是，对给定机器类型中 vCPU 数量的引用等于一个 vCPU，其是虚拟机监控程序层上物理主机中的一个超线程。

就本文档的目的而言，将使用 n1-standard * 和 n1-highmem * 实例类型，这些实例类型在大多数 GCP 部署区域中广泛可用。 但是，对于将大量数据缓存在内存中的大型工作数据集而言，使用 n1-ultramem * 实例类型是不错的选择。 除非另有说明，否则使用默认实例设置（例如实例可用性策略）或其他高级功能。 有关各种机器类型的详细信息，可在此处找到。

磁盘存储

与 InterSystems 产品最直接相关的存储类型是持久性磁盘类型，但是，只要了解并适应数据可用性限制，本地存储可以用于高水平的性能。 还有其他一些选项，例如云存储（存储桶），但是这些选项更特定于单个应用程序的需求，而非支持 InterSystems IRIS 数据平台的操作。

与大多数其他云提供商一样，GCP 对可与单个计算引擎关联的持久性存储施加了限制。 这些限制包括每个磁盘的最大容量、关联到每个计算引擎的持久性磁盘的数量，以及每个持久性磁盘的 IOPS 数量，对单个计算引擎实例 IOPS 设置上限。 此外，对每 GB 磁盘空间设有 IOPS 限制，因此有时需要调配更多磁盘容量才能达到所需的 IOPS 速率。

这些限制可能会随着时间而改变，可在适当时与谷歌确认。

磁盘卷有两种类型的持久性存储类型：“标准持久性”磁盘和“SSD 持久性”磁盘。 SSD 持久性磁盘更适合于那些要求低延迟 IOPS 和高吞吐量的生产工作负载。 标准持久性磁盘对于非生产开发和测试或归档类型的工作负载，是一种更经济的选择。

有关各种磁盘类型及限制的详细信息，可在此处找到。

VPC 网络

强烈建议采用虚拟私有云 (VPC) 网络来支持 InterSystems IRIS 数据平台的各个组件，同时提供正确的网络安全控制、各种网关、路由、内部 IP 地址分配、网络接口隔离和访问控制。 本文档中提供了一个详细的 VPC 示例。

有关 VPC 网络和防火墙的详细信息，可在此处找到。

虚拟私有云 (VPC) 概述

GCP VPC 与其他云提供商略有不同，其更加简单和灵活。 可在此处找到各概念的比较。

在 GCP 项目中，每个项目允许有数个 VPC（目前每个项目最多允许 5 个），且创建 VPC 网络有两个选项——自动模式和自定义模式。

此处提供每个类型的详细信息。

在大多数大型云部署中，采用多个 VPC 将各种网关类型与以应用为中心的 VPC 进行隔离，并利用 VPC 对等进行入站和出站通信。 有关适合您的公司使用的子网和任何组织防火墙规则的详细信息，强烈建议您咨询您的网络管理员。 本文档不阐述 VPC 对等方面的内容。

在本文档提供的示例中，使用 3 个子网的单一 VPC 用于提供各种组件的网络隔离，以应对各种 InterSystems IRIS 组件的可预测延迟和带宽以及安全性隔离。

网络网关和子网定义

本文档的示例中提供了两种网关，以支持互联网和安全 VPN 连接。 要求每个入口访问都具有适当的防火墙和路由规则，从而为应用程序提供足够的安全性。 有关如何使用路由的详细信息，可在此处找到。

提供的示例体系结构中使用了 3 个子网，它们专与 InterSystems IRIS 数据平台一起使用。 这些单独的网络子网和网络接口的使用为上述 3 个主要组件的每一个提供了安全控制、带宽保护和监视方面的灵活性。 有关各种用例的详细信息，可在此处找到。

有关创建具有多个网络接口的虚拟机实例的详细信息，可在此处找到。

这些示例中包含的子网：

内部负载均衡器

大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力，这种地址通常用在自动化数据库故障转移设计中。 为了解决这一问题，InterSystems IRIS 中增强了几种最常用的连接方法，尤其是 ECP 客户端和 Web 网关，从而不再依赖 VIP 功能使它们实现镜像感知和自动化。

xDBC、直接 TCP/IP 套接字等连接方法，或其他的直接连接协议，均需要使用类 VIP 地址。 为了支持这些入站协议，InterSystems 数据库镜像技术使用称作<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span>的健康检查状态页面为 GCP 中的这些连接方法提供自动化故障转移，以与负载均衡器进行交互，实现负载均衡器的类 VIP 功能，仅将流量重定向至活动的主镜像成员，从而在 GCP 内实现完整且强大的高可用性设计。

此处提供了使用负载均衡器实现类 VIP 功能的详细信息。

示例 VPC 拓扑

下图 4.3-a 中的 VPC 布局组合了所有组件，具有以下特点：

持久性存储概述

如简介中所述，建议使用 GCP 持久性磁盘，尤其 SSD 持久性磁盘类型。 之所以推荐 SSD 持久性磁盘，是由于其拥有更高的读写 IOPS 速率以及低的延迟，适合于事务性和分析性数据库工作负载。 在某些情况下，可使用本地 SSD，但值得注意的是，本地 SSD 的性能提升会在可用性、耐用性和灵活性方面做出一定的权衡。

可在此处找到本地 SSD 数据持久性方面的详细信息，您可了解何时保存本地 SSD 数据以及何时不保存它们。

LVM 条带化

与其他的云提供商一样，GCP 在每个虚拟机实例的 IOPS、空间容量和设备数量方面都施加了众多存储限制。 有关当前的限制，请查阅 GCP 文档，可在此处找到。

由于这些限制的存在，使用 LVM 条带化实现数据库实例的单个磁盘设备的 IOPS 最大化变得非常必要。 在提供的此示例虚拟机实例中，建议使用以下磁盘布局。 与 SSD 持久性磁盘相关的性能限制可在此处找到。

LVM 条带化的优势在于可以将随机的 IO 工作负载分散到更多的磁盘设备并继承磁盘队列。 以下是如何在 Linux 中将 LVM 条带化用于数据库卷组的示例。 本示例在一个 LVM PE 条带中使用 4 个磁盘，物理盘区 (PE) 大小为 4MB。 或者，如果需要，可以使用更大的 PE 容量。

• 步骤 1：根据需要创建标准性磁盘或 SSD 持久性磁盘
• 步骤 2：使用“lsblk -do NAME,SCHED”将每个磁盘设备的 IO 调度器设置为 NOOP
• 步骤 3：使用“lsblk -do KNAME,TYPE,SIZE,MODEL”识别磁盘设备
• 步骤4：使用新的磁盘设备创建磁盘卷组
  • vgcreate s 4M  
  • 示例： vgcreate -s 4M vg_iris_db /dev/sd[h-k]
• 步骤 4：创建逻辑卷
  • lvcreate n -L -i -I 4MB
  • 示例：lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db
• 步骤 5：创建文件系统
  • mkfs.xfs K
  • 示例：mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01
• 步骤 6：装载文件系统
  • 使用以下装载条目编辑 /etc/fstab
    • /dev/mapper/vg_iris_db-lv_irisdb01    /vol-iris/db    xfs  defaults 0 0
    • 装载 /vol-iris/db

使用上表，每个 InterSystems IRIS 服务器将具有以下配置：2 个 SYS 磁盘、4 个 DB 磁盘、2 个主日志磁盘、2 个备用日志磁盘。

为了增长，LVM 允许在需要的情况下不中断地扩展设备和逻辑卷。 有关持续管理和扩展 LVM 卷的最佳做法，请查阅 Linux 文档。

配置

InterSystems IRIS 新增了 InterSystems Cloud Manager (ICM)。 ICM 执行众多任务，并提供许多用于配置 InterSystems IRIS 数据平台的选项。 ICM 作为 Docker 映像提供，其拥有配置强大的、基于 GCP 云的解决方案所需的一切。

ICM 当前支持以下平台上的配置：

• Google Cloud Platform (GCP)
• Amazon Web Services，包括 GovCloud (AWS / GovCloud)
• Microsoft Azure Resource Manager，包括 Government (ARM / MAG)
• VMware vSphere (ESXi)

ICM 和 Docker 可以从台式机/笔记本电脑工作站运行，也可以具有中央专用的适度“配置”服务器和中央存储库。  

ICM 在应用程序生命周期中的作用是“定义->配置->部署->管理”

有关安装和使用 ICM 及 Docker 的详细信息，可在此处找到。

容器监视

ICM 包含基本的监视工具，其使用 Weave Scope 进行基于容器的部署。 默认情况下不会部署该工具，需要在默认的文件中使用监视器字段指定它。

有关使用 ICM 进行监视、编排和调度的详细信息，可在此处找到。

有关 Weave Scope 的概述和该文档，可在此处找到。

高可用性

InterSystems 数据库镜像可在任何云环境中提供最高级别的可用性。  有一些选项可以直接在实例级别提供虚拟机弹性。 有关 GCP 中可用的各种政策的详细信息，可在此处找到。

上文中已讨论了云负载均衡器如何通过数据库镜像为虚拟 IP（类 VIP）功能提供自动化 IP 地址故障转移。  云负载均衡器使用<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span>健康检查状态页面，上文内部负载均衡器部分提到过该页面。  数据库镜像有两种模式——自动故障转移同步镜像、异步镜像。 在本示例中，将介绍同步故障转移镜像。 有关镜像的详细信息，可在此处找到。

最基本的镜像配置是仲裁器控制配置中的一对故障转移镜像成员。 仲裁器放置在同一区域内的第三个地区中，以防止潜在的地区中断影响仲裁器和其中一个镜像成员。

在网络配置中，有多种方法专供设置镜像。 在本示例中，我们将使用本文档前述网络网关和子网定义部分中定义的网络子网。 下一部分内容将提供 IP 地址方案示例，并且基于本部分内容，将仅描述网络接口和指定的子网。

灾难恢复

InterSystems 数据库镜像将支持灾难恢复的高可用性功能扩展到另一个 GCP 地理区域，以在整个 GCP 区域万一脱机的情况下支持操作弹性。 应用程序如何耐受此类中断取决于恢复时间目标 (RTO) 和恢复点目标 (RPO)。 这些将为设计适当的灾难恢复计划进行的分析提供初始框架。 以下链接中的指南提供了您在为自己的应用程序制定灾难恢复计划时要考虑的事项。 https://cloud.google.com/solutions/designing-a-disaster-recovery-plan 和 https://cloud.google.com/solutions/disaster-recovery-cookbook

异步数据库镜像

InterSystems IRIS 数据平台的数据库镜像提供强大的功能，可在 GCP 地区和区域之间异步复制数据，以帮助支持您的灾难恢复计划的 RTO 和 RPO 目标。 有关异步镜像成员的详细信息，可在此处找到。

与上述高可用性部分中讲述的内容相似，云负载均衡器也使用上文内部负载均衡器部分中提到过的<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span>健康检查状态页面为虚拟 IP（类 VIP）功能提供自动化 IP 地址故障转移，以进行 DR 异步镜像。

在本示例中，将介绍 DR 异步故障转移镜像，并介绍 GCP 全局负载均衡服务，以便为上游系统和客户端工作站提供单个任播 IP 地址，不分您的 InterSystems IRIS 部署是否在哪个区域或地区中运行。

GCP 的其中一个发展就是负载均衡器的诞生，这是一种软件定义的全局资源，并且不受制于特定的区域。 由于其不是基于实例或设备的解决方案，因此它具有跨区域利用单个服务的独特功能。 有关通过单个任播 IP 进行 GCP 全局负载均衡的详细信息，可在此处找到。

在上述示例中，所有 3 个 InterSystems IRIS 实例的 IP 地址都提供给了 GCP 全局负载均衡器，它会将流量仅定向到承担主要镜像的镜像成员，而不论其位于哪个地区或区域。

分片集群

InterSystems IRIS 拥有一系列全面的功能来缩放您的应用程序，您可以根据自己工作负载的性质以及所面临的特定性能挑战来单独或组合应用这些功能。 分片功能是这些功能中的一种，可跨多个服务器对数据及其关联的缓存进行分区，从而为查询和数据引入提供灵活、高性价比的性能扩展，同时通过高效的资源利用最大化基础架构的价值。 InterSystems IRIS 分片群集可以为各种应用提供显著的性能优势，尤其对于工作负载包括以下一项或多项的应用更是如此：

• 大容量或高速数据引入，或两者的组合。
• 相对较大的数据集、返回大量数据的查询，或两者。
• 执行大量数据处理的复杂查询，例如扫描磁盘上大量数据或涉及大量计算工作的查询。

这些因素分别都会影响分片的潜在优势，但组合起来使用它们可能会增加优势。 例如，这 3 个因素的组合——快速引入大量数据、大型数据集、检索和处理大量数据的复杂查询——使得当今的许多分析性工作负载非常适合进行分片。

注意，这些特征都与数据有关；InterSystems IRIS 分片的主要功能是缩放数据量。 不过，当涉及某些或所有这些与数据相关的因素的工作负载也经历大量用户的超高查询量时，分片群集也能提供用户量缩放功能。 分片也可以与纵向缩放相结合。

操作概述

分片架构的核心是跨多个系统对数据及其关联的缓存进行分区。 分片集群跨多个 InterSystems IRIS 实例以行方式（称为数据节点）对大型数据库表进行物理上的横向分区，同时允许应用通过任何节点透明地访问这些表，但仍将整个数据集看作一个逻辑并集。 该架构具有 3 个优点：

• 并行处理：查询在数据节点上并行运行，然后将结果进行合并和组合后，由节点作为完整查询结果返回给连接的应用。许多情况下，这大大提高了执行速度。
• 分区缓存：每个数据节点都有自己的缓存，专用于它存储的分片表数据分区，再不是单个实例的缓存服务于整个数据集，这大大降低了缓存溢出的风险，并强制执行性能降低式磁盘读取。
• 并行加载：数据可以并行加载到数据节点，从而减少了引入工作负载和查询工作负载之间的缓存和磁盘争用，提高了两者的性能。

有关 InterSystems IRIS 分片集群的详细信息，可在此处找到。

分片元素和实例类型

分片集群包含至少一个数据节点，如果特定性能或工作负载有需要，则可添加一定数量的计算节点。 这两种节点类型提供简单的构建块，从而实现简单、透明和高效的调整模型。

数据节点

数据节点存储数据。 在物质层面，分片表[1]数据分布在集群中的所有数据节点上，非分片表数据仅物理存储在第一个数据节点上。 这种区分对用户是透明的，唯一可能的例外是，第一个节点的存储消耗可能比其他节点略高，但是由于分片表数据通常会超出非分片表数据至少一个数量级，因此这种差异可以忽略不计。

需要时，可以跨集群重新均衡分片表数据，这通常发生在添加新的数据节点后。 这将在节点之间移动数据的“存储桶”，以实现数据的近似均匀分布。

在逻辑层面，未分片的表数据和所有分片的表数据的并集在任何节点上都可见，因此客户端会看到整个数据集，这与其连接哪个节点无关。 元数据和代码也会在所有数据节点之间共享。

分片集群的基本架构图仅由在集群中看起来统一的数据节点组成。 客户端应用程序可以连接到任何节点，并且可以像在本地一样体验数据。

数据节点

对于要求低延迟（可能存在不断涌入数据的冲突）的高级方案，可以添加计算节点以提供用于服务查询的透明缓存层。

计算节点缓存数据。 每个计算节点都与一个数据节点关联，为其缓存相应的分片表数据，此外，它还根据需要缓存非分片表数据，以满足查询的需要。

由于计算节点物理上并不存储任何数据，其只是支持查询执行，因此可对其硬件配置文件进行调整以满足需求，例如通过强调内存和 CPU 并将存储空间保持在最低限度。 当“裸露”应用程序代码在计算节点上运行时，引入数据会被驱动程序 (xDBC, Spark) 直接或被分片管理器代码间接转发到数据节点。

分片集群说明

分片集群部署有多种组合。 下列各图说明了最常见的部署模型。 These diagrams do not include the networking gateways and details and provide to focus only on the sharded cluster components.

基本分片集群

下图是在一个区域和一个地区中部署了 4 个数据节点的最简单分片群集。 GCP 云负载均衡器用于将客户端连接分发到任何分片集群节点。

在此基本模型中，除了 GCP 为单个虚拟机及其连接的 SSD 持久性存储提供的弹性或高可用性外，没有其他弹性或高可用性。 建议使用两个单独的网络接口适配器，一则为入站客户端连接提供网络安全隔离，二则为客户端流量和分片集群通信之间提供带宽隔离。

具有高可用性的基本分片集群

下图是在一个区域中部署了 4 个镜像数据节点的最简单分片集群，每个节点的镜像在地区之间进行了划分。 GCP 云负载均衡器用于将客户端连接分发到任何分片集群节点。

InterSystems 数据库镜像的使用带来了高可用性，其会在该区域内的第二地区中维护一个同步复制的镜像。

建议使用 3 个单独的网络接口适配器，一方面为入站客户端连接提供网络安全隔离，另一方面为客户端流量、分片集群通信、节点对之间的同步镜像流量之间提供带宽隔离。

此部署模型也引入了本文前面所述的镜像仲裁器。

具有单独计算节点的分片集群

下图采用单独的计算节点和 4 个数据节点扩展了分片集群，以此来应对大量的用户/查询并发。 云负载均衡器服务器池仅包含计算节点的地址。 更新和数据引入将像以前一样继续直接更新到数据节点，以维持超低延迟性能，并避免由于实时数据引入而在查询/分析工作负载之间造成资源的干扰和拥挤。

使用此模型，可以根据计算/查询和数据引入的规模单独微调资源分配，从而在“适时”需要的地方提供最佳资源，实现经济而简单的解决方案，而非只是进行计算或数据的调整，浪费不必要的资源。

计算节点非常适合直接使用 GCP 自动缩放分组（亦称自动缩放），允许基于负载的增加或减少自动从托管实例组添加或删除实例。 自动缩放的工作原理为：负载增加时，将更多的实例添加到实例组（扩展）；对实例的需求降低时将其删除（缩减）。

有关 GCP 自动缩放的详细信息，可在此处找到。

自动缩放可帮助基于云的应用程序轻松应对流量增加的情况，并在资源需求降低时降低成本。 只需简单地定义自动缩放策略，自动缩放器就会根据测得的负载执行自动缩放。

备份操作

备份操作有多个选项。 以下 3 个选项可供您通过 InterSystems IRIS 进行 GCP 部署。

下面的前 2 个选项（下文详细说明）采用快照类型的过程，该过程会在创建快照之前将数据库写入操作挂起到磁盘上，然后在快照成功后恢复更新。

可采取以下高级别步骤通过任一快照方法来创建洁净的备份：

• 通过数据库外部冻结 API 调用暂停对数据库的写入。
• 创建操作系统和数据磁盘的快照。
• 通过外部解冻 API 调用恢复数据库写入。
• 将设施存档备份到备份位置

有关外部冻结/解冻 API 的详细信息，可在此处找到。

第三个选项是 InterSystems 在线备份。 这是小型部署的入门级方法，具有非常简单的用例和界面。 但是，随着数据库的增大，建议将使用快照技术的外部备份作为最佳做法，因为其具有以下优势：备份外部文件、更快的恢复时间，以及企业范围的数据和管理工具。

可以定期添加诸如完整性检查之类的其他步骤，以确保洁净且一致的备份。

决定使用哪种选项取决于您组织的运营要求和策略。 InterSystems 可与您详细讨论各种选项。

GCP 持久性磁盘快照备份

可以使用 GCP gcloud 命令行 API 以及 InterSystems 外部冻结/解冻 API 功能实现备份操作。 这允许实现真正的 24x7 全天候操作弹性，并确保洁净常规备份。 有关管理、创建和自动化 GCP 持久性磁盘快照的详细信息，可在此处找到。

逻辑卷管理器 (LVM) 快照

或者，可以在 VM 本身中部署单个备份代理，利用文件级备份，并结合逻辑卷管理器 (LVM) 快照，来使用市面上的许多第三方备份工具。

该模型的主要优点之一是能够对基于 Windows 或 Linux 的 VM 进行文件级恢复。 此解决方案需要注意的几点是，由于 GCP 和大多数其他 IaaS 云提供商都不提供磁带媒体，因此所有的备份存储库对于短期归档均基于磁盘，并能够利用 Blob 或存储桶类型的低成本存储来进行长期保留 (LTR)。 强烈建议您使用此方法来使用支持重复数据删除技术的备份产品，以最有效地利用基于磁盘的备份存储库。

这些具有云支持的备份产品的示例包括但不限于：Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。

在线备份

对于小型部署，内置在线备份工具也是可行的选择。 该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据，然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 有关在线备份的详细信息，可在此处找到。

在 GCP 中，在线备份完成后，必须将备份输出文件和系统正在使用的所有其他文件复制到该虚拟机实例之外的其他存储位置。 存储桶/对象存储是对其很好的命名。

使用 GCP 存储桶有两种选择。

• 直接使用 gcloud 脚本 API 来复制和操作新创建的在线备份（和其他非数据库）文件。 有关详细信息可在此处找到。
• 尽管云存储桶属于对象存储，但将存储桶装载为文件系统，并将其用作类似持久性磁盘的功能足以。

有关装载云存储桶（使用云存储 FUSE ）的详细信息，可在此处找到。