在本文中，我们将使用基于分布式存储的 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.

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

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

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

操作系统级别的集群HA

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

InterSystems IRIS的设计可以轻松地与所支持的平台的故障转移集群技术相结合（如InterSystems支持的平台中所述）。

安装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

[root@arbiterhost home]# gunzip ISCAgent-2020.1.0.540.0-lnxrhx64.tar.gz
[root@arbiterhost home]# tar -xf ISCAgent-2020.1.0.540.

所有源代码均在: 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工具的默认集群。你可以通过运行以下代码来验证你的部署：

kubectl get nodes
NAME                                             STATUS   ROLES    AGE   VERSION
ip-192-168-19-7.

现在我们院区也遇到这样一个问题。关于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 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。