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

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

1.1 问题描述

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

安装Arbiter

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

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

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

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

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

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

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

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

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

对于那些在某种程度上需要测试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) 模型。

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

更新日期：2019 年 10 月 15 日