在 Docker 中配置镜像

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

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

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

镜像

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

架构

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

• 在故障转移模式下配置的两个实例：
  • 主动节点——接收所有常规的读/写操作。
  • 被动节点：在读取模式下，它同步接收主动节点产生的任何变化。
• 0-14个异步实例：你可以使用多个异步实例，它们可以是两种类型：
  • DR 异步（灾难恢复）：处于读取模式的节点不是故障转移的一部分，尽管它们可以被手动提升成故障转移节点。如果是这样，它们可以在其他两个故障转移节点发生故障时自动提升为主节点。您的数据更新是异步的，所以不能保证其数据是最新的。
  • 报告异步：异步更新节点，用于 BI 任务或数据挖掘。它们不能升级为故障转移，因为可以对数据执行写入。
• ISCAgent：安装在每个实例所在的服务器上。它将负责监视所述服务器实例的状态。这是镜像服务器之间除了直接通信之外的另一种通信方式。
• Arbiter：它是一个独立于构成镜像的服务器安装的 ISCAgent，并允许通过监视安装的 ISCAgent 和 IRIS/HealthShare 实例来提高安全性和内部故障转移的控制。它的安装不是必须的。

这是一个由只有两个节点的故障转移形成的镜像的操作：

先前的警告

与本文相关的项目没有允许配置镜像的活动许可证。如果你想尝试，直接给我发邮件或者在文末添加评论，我会联系你。

在 Docker 中部署

对于本文，我们将在 Docker 中建立一个小项目，允许我们设置 2 个故障转移实例和一个Arbiter 。默认情况下，可用于 Docker 的 IRIS 映像已经安装并配置了 ISCAgent，因此我们可以跳过该步骤。有必要配置与来自 Visual Studio Code 的文章关联的项目，因为这将使我们以后可以更轻松地使用服务器文件。

让我们看看我们的 docker-compose.yml 会有什么形式：

 version: '3.3'
services:
  arbiter:
      container_name: arbiter
      hostname: arbiter
      image: containers.intersystems.com/intersystems/arbiter:2022.1.0.209.0
      init: true
      command:
        - /usr/local/etc/irissys/startISCAgent.sh 2188
  mirrorA:
    image: containers.intersystems.com/intersystems/iris:2022.1.0.209.0
    container_name: mirrorA
    depends_on:
      - arbiter
    ports:
    - "52775:52773"
    volumes:
    - ./sharedA:/shared
    - ./install:/install
    - ./management:/management
    command:
      --check-caps false
      --key /install/iris.key
      -a /install/installer.sh
    environment:
    - ISC_DATA_DIRECTORY=/shared/durable
    hostname: mirrorA
  mirrorB:
    image: containers.intersystems.com/intersystems/iris:2022.1.0.209.0
    container_name: mirrorB
    depends_on:
      - arbiter
      - mirrorA
    ports:
    - "52776:52773"
    volumes:
    - ./sharedB:/shared
    - ./install:/install
    - ./management:/management
    command:
      --check-caps false
      --key /install/iris.key
      -a /install/installer.sh
    environment:
    - ISC_DATA_DIRECTORY=/shared/durable
    hostname: mirrorB

可以看到我们定义了3个容器：

• Arbiter ：它对应于将被部署以控制将形成 Mirror Failover 的 IRIS 实例的 ISCAgent（即使图像称为 Arbiter）。当启动容器时，它将执行一个 shell 文件，该文件将启动侦听容器端口 2188 的 ISCAgent。
• mirrorA ：将部署 IRIS v.2022.1.0.209 映像的容器，稍后我们将其配置为主故障转移节点。
• mirrorB ：将部署 IRIS v.2022.1.0.209 镜像的容器，稍后我们将其配置为辅助故障转移节点。

当我们执行docker-compose up -d命令时，定义的容器将部署在我们的 Docker 中，它在我们的 Docker 桌面中应该看起来像这样（如果我们从 Windows 执行此操作）。

镜像配置。

部署容器后，我们将继续访问我们将在镜像中配置的实例，第一个将在端口 52775 ( mirrorA ) 上侦听，第二个在 52776 ( mirrorB ) 上侦听。访问用户和密码将是superuser/ SYS

由于实例部署在 Docker 中，我们将有两个选项来配置我们服务器的 IP。第一种是在配置中直接使用我们容器的名称（这是最简单的方法）或检查 Docker 为每个容器分配的 IP（打开控制台并执行返回分配的 IP 的 ifconfig）。为了清楚起见，我们将在示例中使用我们为每个容器指定的名称作为 Docker 中每个容器的地址。

首先，我们将配置我们将用作故障转移活动节点的实例。在我们的例子中，它将是我们所说的mirrorA 。

第一步是启用镜像服务，因此我们将从管理门户访问镜像菜单： System Administration --> Configuration --> Mirror Settings --> Enable Mirror Service并标记Service Enabled检查：

启用服务后，我们可以开始配置我们的活动节点。启用该服务后，您将能够在镜像菜单中看到新选项已启用：

在这种情况下，由于我们还没有创建任何镜像配置，我们必须使用Create Mirror选项创建一个新配置。当我们访问这个选项时，管理门户将打开一个新窗口，我们可以从中配置我们的镜像：

让我们仔细看看每个选项：

• Mirror Name ：我们将用来标识我们的镜像的名称。对于我们的示例，我们将其称为 MIRRORSET
• 需要 SSL/TLS ：对于我们的示例，我们不会使用 SSL/TLS 配置连接，尽管在生产环境中，防止在实例之间没有任何类型的加密的情况下共享日志文件会比操作方便更重要。如果您有兴趣配置它，您可以在文档的以下URL中获得所有必要的信息。
• 使用 Arbiter ：此选项不是强制性的，但强烈推荐，因为它为我们的镜像配置增加了一层安全性。对于我们的示例，我们将选中它并指示我们运行 Arbiter 的 IP。对于我们的示例，IP 将位于容器名称arbiter中。
• 用户虚拟 IP ：在 Linux/Unix 环境中，此选项非常有趣，因为它允许我们为将由我们的镜像管理的活动节点配置虚拟 IP。此虚拟 IP 必须与故障转移节点属于同一子网。虚拟IP的操作非常简单，当主动节点出现故障时镜像会自动在待提升的被动节点所在的服务器上配置虚拟IP。这样，被动节点到主动节点的升级对用户来说将是完全透明的，因为他们将继续连接到同一个 IP，即使它将配置在不同的服务器上。如果您想了解有关虚拟 IP 的更多信息，可以查看文档的此URL 。

其余的配置可以保持原样。在屏幕右侧我们会看到镜像中这个节点的相关信息：

• Mirror Member Name ：这个镜像成员的名称，默认情况下它将采用服务器的名称以及实例的名称。
• 超级服务器地址：这个节点的超级服务器 IP 地址，在我们的例子中是mirrorA 。
• Agent Port ：配置了该节点对应的ISCAgent的端口。默认为2188 。

配置必要的字段后，我们可以继续保存镜像。我们可以从镜像监视器（系统操作-->镜像监视器）检查配置情况。

完美，这里我们有了新配置的镜像。如您所见，只有我们刚刚创建的活动节点出现。很好，接下来让我们在故障转移中添加我们的被动节点。我们访问mirrorB管理门户并访问镜像设置菜单。正如我们已经为mirrorA实例所做的那样，我们必须启用镜像服务。我们重复该操作，一旦菜单选项更新，我们将选择Join as Failover 。

这里我们有镜像连接屏幕。让我们简要解释一下每个字段的含义：

• 镜像名称：我们在创建时为镜像指定的名称，在我们的示例中为MIRRORSET 。
• Agent Address on Other System ：部署主动节点ISCAgent的服务器IP，对我们来说就是mirrorA。
• 代理端口：我们创建镜像的服务器的ISCAgent监听端口。默认为2188 。
• InterSystems IRIS 实例名称：主动节点上 IRIS 实例的名称。在这种情况下，它与被动节点IRIS的一致。

保存镜像数据后，我们将可以选择定义与我们正在配置的被动节点相关的信息。我们再来看看被动节点可以配置的字段：

• 镜像成员名称：被动节点将在镜像中使用的名称。默认情况下由服务器名称和实例组成。
• 超级服务器地址：被动节点中超级服务器的 IP 地址。在这种情况下mirrorB 。
• 代理端口：我们配置的被动节点服务器上安装的ISCAgent的监听端口。默认为2188 。
• SSL/TLS 要求：在此示例中不可配置，我们不使用 SSL/TLS。
• 镜像私有地址：被动节点的 IP 地址。正如我们所见，在使用 Docker 时，我们可以使用容器名称mirrorB 。
• 代理地址：安装 ISCAgent 的服务器的 IP 地址。和以前一样， mirrorB 。

我们按照指示保存配置，然后返回到镜像监视器以验证我们是否已正确配置所有内容。我们可以将mirrorA中的主动节点和mirrorB中的被动节点的监视器可视化。让我们看看这两个实例之间的差异。

活动节点mirrorA上的镜像监视器：

被动节点mirrorB上的镜像监视器：

如您所见，显示的信息是相似的，基本上改变了故障转移成员的顺序。选项也不同，让我们看看其中的一些：

• 主动节点mirrorA ：
  • 设置无故障转移：防止在作为其中一部分的任何实例停止的情况下执行故障转移。
  • 降级其他成员：从镜像配置中删除其他故障转移成员（在本例中为mirrorB ）。
• 被动节点mirrorB ：
  • Stop Mirror On This Member ：停止故障转移被动节点上的镜像同步。
  • 降级为 DR 成员：将此节点从其实时同步故障转移的一部分降级为异步模式下的灾难恢复模式。

完美，我们已经配置了节点，现在让我们看看配置的最后一步。我们必须决定哪些表将成为镜像的一部分，并在两个节点上进行配置。如果您查看与本文相关的 Open Exchange 项目的 README.md，您将看到我们配置和部署了两个通常用于训练的应用程序。当我们启动 Docker 容器时，这些应用程序会自动部署，默认情况下会创建 NAMESPACES 和数据库。

第一个应用程序是COMPANY ，它允许我们保存公司记录，第二个应用程序是PHONEBOOK ，它允许我们添加与注册公司以及客户相关的个人联系人。

让我们添加一家公司：

现在让我们为之前的公司创建个人联系人：

公司数据将在COMPANY数据库中注册，联系人数据在PERSONAL中，这两个数据库都已映射，以便可以从命名空间 PHONEBOOK 访问它们。如果我们检查两个节点中的表，我们将看到在mirrorA中我们有公司和联系人的数据，但在mirrorB中仍然没有任何数据，这是合乎逻辑的。

mirrorA注册的公司：

好的，让我们继续在我们的镜像上配置数据库。为此，从我们的活动节点 ( mirrorA )，我们访问本地数据库管理屏幕（系统管理员-->配置-->系统配置-->本地数据库）并单击添加到镜像选项，我们必须选择从列表中我们要添加的所有数据库并从屏幕上读取消息：

一旦我们将数据库从主动节点添加到镜像中，我们必须对其进行备份或复制数据库文件 (IRIS.dat) 并将它们还原到被动节点上。如果您决定直接复制 IRIS.dat 文件，请记住您必须冻结要复制的数据库中的写入，您可以在文档的以下URL中查看必要的命令。在我们的例子中，没有必要暂停，因为除了我们之外没有人在写入数据。

在复制数据库文件之前，让我们从活动节点的监视器上检查镜像的状态：

让我们看看被动节点：

正如我们所看到的，从被动节点我们被告知，虽然我们在镜像中配置了 3 个数据库，但配置尚未完成。让我们继续将数据库从主动节点复制到被动节点，不要忘记我们必须卸载被动节点的数据库才能进行复制，为此我们将从管理门户访问系统配置—— >数据库并访问它们中的每一个，我们继续卸载它们。

完美的！卸载的数据库。让我们从 Visual Studio Code 访问与本文相关的项目代码，看看我们有 IRIS 安装所在的文件夹， sharedA用于mirrorA和sharedB用于mirrorB 。让我们访问 COMPANY、CUSTOMER 和 PERSONAL 数据库所在的文件夹 ( /sharedA/durable/mgr )，然后继续将镜像中每个数据库的 IRIS.dat 复制到 mirrorB 的相应目录 ( /sharedB/durable/mgr) ).

复制完成后，我们再次挂载mirrorB数据库并从mirrorB中的镜像监视器检查已配置数据库的状态：

答对了！我们的镜像已经识别出数据库，现在我们只需要激活和更新它们。为此，我们将点击Activate操作，然后点击Catchup ，这将在激活后出现。让我们看看他们是如何结束的：

完美，我们的数据库已经在镜像中正确配置，如果我们查询 COMPANY 数据库，我们应该看到我们之前从mirrorA注册的记录：

显然我们的COMPANY数据库中有我们之前在mirrorA中输入的记录，毕竟我们已经复制了整个数据库。让我们继续从mirrorA添加一个新公司，我们将其称为“另一家公司”，然后再次查询 COMPANY 数据库表：

在这里，我们完成了。我们只需要确保我们在镜像中配置的数据库对于被动节点mirrorB处于只读模式：

他们在那里！是只读模式R 。好吧，我们已经配置了镜像并同步了数据库。如果我们的产品正在运行，这不会成为问题，因为镜像会自动负责管理它们，并在主动节点出现故障时在被动节点中启动它们。

非常感谢大家走到这一步！它很长，但我希望你觉得它有用。