搜索​​​​

嗨，开发者们！ 看看你如何用PyODBC和Native API在Python中开发并连接到InterSystems IRIS®数据平台。 ⏯ Using Python to Connect to InterSystems IRIS 欢迎大家来我们的 Bilibili主页观看更多视频!

Docker 20.10.14（2022年3月23日发布）改变了赋予容器的Linux能力，其方式与InterSystems IRIS 2021.1（及以上）容器的Linux能力检查器不兼容。 在Linux上运行Docker 20.10.14的用户会发现，IRIS 2021.1+容器将无法启动，并且日志会错误地报告缺少所需的Linux能力。 比如说。 [ERROR] Required Linux capability cap_setuid is missing. [ERROR] Required Linux capability cap_dac_override is missing. [ERROR] Required Linux capability cap_fowner is missing. [ERROR] Required Linux capability cap_setgid is missing. [ERROR] Required Linux capability cap_kill is missing. [FATAL] Your IRIS container is missing one or more required Linux capabilities. 解决方案 遇到这个问题的用户需要调整传递给容器入口的命令行，以禁用对Linux功能的检查。 在命令行中，在docker run或docker start命令中的镜像后面添加--check-caps false。 例如: docker run containers.intersystems.com/intersystems/iris-community:2022.1.0.152.0 --check-caps false 如果你使用的是docker-compose，相应的改动如下： command: --check-caps false 能力检查是在启动IRIS进程之前检查常见的错误配置的一种方式。 禁用Linux能力检查对容器中运行的IRIS进程没有影响。 更多阅读 Docker 20.10.14 release notes Running InterSystems Products in Containers

开发者们好！ 我们很高兴地宣布推出InterSystems公司的合作伙伴名录! 这里是寻找基于InterSystems产品的商业服务 和 解决方案 的地方。 为什么选择InterSystems合作伙伴目录？ 每天，我们都会收到类似这样的问题： 是否有任何基于InterSystems技术的ERP解决方案？ 我住在瑞典，我怎样才能得到InterSystems的培训？ InterSystems在法国是否有任何实施伙伴？ 无论我们的客户是在寻找建立解决方案的帮助，还是在寻找可信赖的咨询来源，还是在寻找实施项目的帮助，或者是寻找一些额外的培训，他们都可以通过合作伙伴名录来与适合他们的公司建立关系。 如果你的公司是InterSystems的合作伙伴，并且提供： 与InterSystems技术有关的实施、咨询或培训服务， 和使用InterSystems产品构建的解决方案。 我们欢迎你加入合作伙伴目录. 欢迎访问并与你的同事分享!

现在，InterSystems IRIS、IRIS for Health 和 IRIS Studio 的 2020.4 版发布了预览版本。由于是预览版本，因此我们渴望在下个月正式发布之前了解您对新版本的体验。 **InterSystems IRIS 数据平台 2020.4 **使开发、部署和管理增强型应用程序和业务流程（桥接数据和应用程序孤岛）变得更加容易。 其拥有众多新功能，包括： 面向应用程序和界面开发者的增强功能，包括： 使用 Oracle OpenJDK 和 AdoptOpenJDK 时均支持 Java SE 11 LTS 支持 JDBC 连接池 分段虚拟文档的路由规则新增“foreach”操作 面向数据库和系统管理员的增强功能，包括： ICM 现在支持部署系统警报和监视 (SAM) 以及 InterSystems API 管理器（IAM） 常见管理任务的 SQL 语法得到扩展 InterSystems 报告的部署得到简化    ** InterSystems IRIS for Health 2020.4 **包括 InterSystems IRIS 的所有增强功能。 另外，此版本还包括： 增强的 FHIR 支持，包括对 FHIR 配置文件的支持 支持 RMD IHE 配置文件 在 HL7 迁移工具中支持 DataGate   有关这些功能的更多详细信息，请参见产品文档： InterSystems IRIS 2020.4 文档及版本说明 InterSystems IRIS for Health 2020.4 文档及版本说明 由于这是 CD 版本，因此仅以 OCI（开放容器计划） 亦即 Docker 容器格式提供。  容器映像可用于面向 Linux x86-64 和 Linux ARM64 的 OCI 兼容运行时间引擎，如[支持的平台文档](https://docs.intersystems.com/iris20204/csp/docbook/platforms/index.html)中详述。   **企业版**容器映像及其所有相应组件都可以使用以下命从[ InterSystems 容器注册表](https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_containerregistry)中获得： docker pull containers.intersystems.com/intersystems/iris:2020.4.0.521.0 docker pull containers.intersystems.com/intersystems/irishealth:2020.4.0.521.0 有关可用映像的完整列表，请参阅[ ICR 文档](https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_containerregistry#PAGE_containerregistry_images)。 也可以使用以下命令从[ Docker 存储库](https://hub.docker.com/_/intersystems-iris-data-platform)提取**社区版**的容器映像： docker pull store/intersystems/iris-community:2020.4.0.521.0 docker pull store/intersystems/iris-community-arm64:2020.4.0.521.0 docker pull store/intersystems/irishealth-community:2020.4.0.521.0 docker pull store/intersystems/irishealth-community-arm64:2020.4.0.521.0 另外，可以通过 WRC 的[预览版本下载网站](https://wrc.intersystems.com/wrc/coDistPreview.csp)获取所有容器映像的 tarball 版本。   InterSystems IRIS Studio 2020.4 是 Microsoft Windows 支持的独立开发映像。 其可以与 InterSystems IRIS 和 IRIS for Health 版本 2020.4 及更低版本一起使用，还可以与 Caché 和 Ensemble 一起使用。 可以通过 WRC 的[预览下载网站](https://wrc.intersystems.com/wrc/coDistPreview.csp)进行下载。 此预览版本的内部版本号是 2020.4.0.521.0。

你好，开发者！ 你们中的许多人在 [Open Exchange](https://openexchange.intersystems.com/) 和 Github 上发布了 InterSystems ObjectScript 库。 但对于开发者来说，如何简化项目的使用和协作呢？ 在本文中，我想介绍一种简单方法，只需将一组标准文件复制到你的仓库中，就可以启动任何 ObjectScript 项目和对其做出贡献。 我们开始吧！ **TLDR** - 将以下文件从[该仓库](https://github.com/intersystems-community/objectscript-docker-template)复制到你的仓库： [Dockerfile](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Dockerfile) [docker-compose.yml](https://github.com/intersystems-community/objectscript-docker-template/blob/master/docker-compose.yml) [Installer.cls](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Installer.cls) [iris.script](https://github.com/intersystems-community/objectscript-docker-template/blob/master/iris.script) [settings.json](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.vscode/settings.json "settings.json"){#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73} [.dockerignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.dockerignore ".dockerignore"){#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637} [.gitattributes](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitattributes ".gitattributes"){#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1} [.gitignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitignore ".gitignore"){#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb} 你已经知道启动你的项目和协作的标准方式。 以下将详细说明这样做的步骤和原因。 **注意：**在本文中，我们将考虑可在 InterSystems IRIS 2019.1 及更新版本上运行的项目。 **选择 InterSystems IRIS 项目的启动环境** 通常，我们希望开发者尝试项目/库，并确保这是快速安全的练习。 在我看来，快速安全地启动任何新项目的理想方式是 Docker 容器，它可以保证开发者启动、导入、编译和计算任何内容对于主机来说都是安全的，并且不会破坏任何系统或代码。如果出了问题，只需停止并删除容器即可。 如果应用程序占用大量磁盘空间，使用容器将其擦除，空间就回来了。 如果某个应用程序破坏了数据库配置，只需删除配置被破坏的容器。 简单又安全。 Docker 容器提供安全和标准化。 运行通用 InterSystems IRIS Docker 容器的最简单方法是运行 [IRIS 社区版映像](https://hub.docker.com/_/intersystems-iris-data-platform/plans/222f869e-567c-4928-b572-eb6a29706fbd?tab=instructions)： 1. 安装 [Docker desktop](https://www.docker.com/products/docker-desktop)  2. 在操作系统终端中运行以下命令： docker run --rm -p 52773:52773 --init --name my-iris store/intersystems/iris-community:2020.1.0.199.0 3. 然后在主机浏览器上打开管理门户： 4. 或者打开终端启动 IRIS： docker exec -it my-iris iris session IRIS 5. 不需要 IRIS 容器时，将其停止： docker stop my-iris 好！ 我们在一个 docker 容器中运行 IRIS。 但是你希望开发者将你的代码安装到 IRIS 中，可能还要进行一些设置。 这就是我们下面要讨论的。 **导入 ObjectScript 文件** 最简单的 InterSystems ObjectScript 项目可以包含一组 ObjectScript 文件，例如类、例程、宏和global。 请查看有关命名和建议的文件夹结构的文章。 问题是如何将所有这些代码导入 IRIS 容器？ 此时我们可以借助 Dockerfile 来获取通用 IRIS 容器，并将某个仓库中的所有代码导入 IRIS，然后根据需要对 IRIS 进行一些设置。 我们需要在仓库中添加一个 Dockerfile。 我们来看一下 [ObjectScript 模板](https://github.com/intersystems-community/objectscript-docker-template)仓库中的 [Dockerfile](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Dockerfile)： ARG IMAGE=store/intersystems/irishealth:2019.3.0.308.0-community ARG IMAGE=store/intersystems/iris-community:2019.3.0.309.0 ARG IMAGE=store/intersystems/iris-community:2019.4.0.379.0 ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0 FROM $IMAGE USER root WORKDIR /opt/irisapp RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp USER irisowner COPY Installer.cls . COPY src src COPY iris.script /tmp/iris.script # run iris and initial  RUN iris start IRIS \     && iris session IRIS < /tmp/iris.script   前几个 ARG 行设置 $IMAGE 变量，随后在 FROM 中使用该变量。 这适合在不同的 IRIS 版本中测试/运行代码，只需在 FROM 前面的最后一行中更改 $IMAGE 变量即可切换版本。 这里我们采用： ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0 FROM $IMAGE 这意味着我们将使用 IRIS 2020 社区版 build 199。 我们想要导入仓库中的代码，这意味着我们需要将仓库中的文件复制到 docker 容器。 下面几行完成此操作： USER root WORKDIR /opt/irisapp RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp USER irisowner COPY Installer.cls . COPY src src USER root - 这里我们将用户切换为 root，以在 docker 中创建文件夹和复制文件。 WORKDIR  /opt/irisapp - 我们在此行中设置将文件复制到的工作目录。 RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp   -  这里我们为运行 IRIS 的 irisowner 用户和组授予权限。 USER irisowner - 将用户从 root 切换到 irisowner COPY Installer.cls .  - 将 [Installer.cls](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Installer.cls) 复制到工作目录的根目录。 不要漏了那个点儿。 COPY src src - 将[仓库的 src 文件夹](https://github.com/intersystems-community/objectscript-docker-template/tree/master/src/)中的源文件复制到 docker 上的工作目录的 src 文件夹中。 在下一个块中，我们运行初始脚本，其中将调用安装程序和 ObjectScript 代码： COPY iris.script /tmp/iris.script # run iris and initial  RUN iris start IRIS \     && iris session IRIS < /tmp/iris.script COPY iris.script / - 我们将 iris.script 复制到根目录。 它包含我们要调用以设置容器的 ObjectScript。 RUN iris start IRIS\  - 启动 IRIS && iris session IRIS < /tmp/iris.script - 启动 IRIS 终端并在其中输入初始 ObjectScript。 很好！ 我们有 Dockerfile，它将文件导入 docker。 但还有两个文件：installer.cls 和 iris.script。我们来检查一下。 [**Installer.cls**](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Installer.cls) Class App.Installer { XData setup {                                   } ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ] {   #; Let XGL document generate code for this method.    Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "setup") } } 坦白说，我们不需要 Installer.cls 就可以导入文件。 这只需要一行就能完成。 但除了导入代码之外，我们经常还需要设置 CSP 应用，引入安全设置，创建数据库和命名空间。 在此 Installer.cls 中，我们创建了名为 IRISAPP 的新数据库和命名空间，并为该命名空间创建了默认的 /csp/irisapp 应用程序。 所有这些都在元素中 执行： <Namespace Name="${Namespace}" Code="${Namespace}" Data="${Namespace}" Create="yes" Ensemble="no"> <Configuration> <Database Name="${Namespace}" Dir="/opt/${app}/data" Create="yes" Resource="%DB_${Namespace}"/> <Import File="${SourceDir}" Flags="ck" Recurse="1"/> </Configuration> <CSPApplication Url="/csp/${app}" Directory="${cspdir}${app}" ServeFiles="1" Recurse="1" MatchRoles=":%DB_${Namespace}" AuthenticationMethods="32" /> </Namespace> 我们用 Import 标签导入 SourceDir 中的所有文件： <Import File="${SourceDir}" Flags="ck" Recurse="1"/> 这里的 SourceDir 是一个变量，设置为当前目录/src 文件夹： <Default Name="SourceDir" Value="#{$system.Process.CurrentDirectory()}src"/> 有了带这些设置的 Installer.cls，我们可以自信地创建一个干净的新数据库 IRISAPP，我们将从 src 文件夹导入任意 ObjectScript 代码到该数据库中。 [iris.script](https://github.com/intersystems-community/objectscript-docker-template/blob/master/iris.script) 欢迎在这里提供任何所需的初始 ObjectScript 设置代码来启动 IRIS 容器。 例如， 我们加载并运行 installer.cls，然后让 UserPasswords 永远有效，以避免第一次启动时出现密码更改请求，因为开发不需要这个提示。 ; run installer to create namespace do $SYSTEM.OBJ.Load("/opt/irisapp/Installer.cls", "ck") set sc = ##class(App.Installer).setup()  zn "%SYS" Do ##class(Security.Users).UnExpireUserPasswords("*") ; call your initial methods here halt [docker-compose.yml](https://github.com/intersystems-community/objectscript-docker-template/blob/master/docker-compose.yml) 为什么需要 docker-compose.yml，不能只用 Dockerfile 构建和运行映像吗？ 可以的。 但 docker-compose.yml 能让生活更轻松。 通常，docker-compose.yml 用于启动连接到一个网络的多个 docker 映像。 当启动一个 docker 映像需要处理多个参数时，也可以使用 docker-compose.yml 来简化过程。 你可以使用它向 docker 传递参数，例如端口映射、卷、VSCode 连接参数。 version: '3.6' services: iris: build: context: . dockerfile: Dockerfile restart: always ports: - 51773 - 52773 - 53773 volumes: - ~/iris.key:/usr/irissys/mgr/iris.key - ./:/irisdev/app 这里我们声明服务 iris，它使用 docker 文件 Dockerfile，并开放 IRIS 的以下端口：51773、52773、53773。 此服务还映射两个卷：将主机主目录中的 iris.key 映射到期望的 IRIS 文件夹，以及将源代码的根文件夹映射到 /irisdev/app 文件夹。 Docker-compose 提供了更短的统一命令来构建和运行映像，无论你在 docker compose 中设置了什么参数。 总之，构建和启动镜像的命令是： $ docker-compose up -d 要打开 IRIS 终端： $ docker-compose exec iris iris session iris Node: 05a09e256d6b, Instance: IRIS USER> 此外，docker-compose.yml 有助于设置 VSCode ObjectScript 插件的连接。 [.vscode/settings.json](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.vscode/settings.json) 与 ObjectScript 加载项连接设置有关的部分如下： { "objectscript.conn" :{ "ns": "IRISAPP", "active": true, "docker-compose": { "service": "iris", "internalPort": 52773 } } } 在这里，我们看到的设置与 VSCode ObjectScript 插件的默认设置不同。 我们想要连接到 IRISAPP 命名空间（我们用 Installer.cls 创建的）： "ns": "IRISAPP", 一个 docker-compose 设置指示，docker-compose 文件在服务“iris”内，VSCode 将连接到 52773 映射到的端口： "docker-compose": { "service": "iris", "internalPort": 52773 } 如果我们检查一下 52773 的相关设置，我们会看到没有为 52773 定义映射端口： ports: - 51773 - 52773 - 53773 这意味着将使用主机上的随机可用端口，并且 VSCode 将通过随机端口自动连接到 docker 上的 IRIS。 **这是一个非常方便的功能，因为它允许在随机端口上运行任意数量的带 IRIS 的 docker 映像，并让 VSCode 自动连接到它们。** 其他文件呢？ 我们还有： [.dockerignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.dockerignore)  - 该文件可用于过滤你不想复制到所构建的 docker 映像中的主机文件。 通常 .git 和 .DS_Store 是必须有的行。 [.gitattributes](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitattributes) - git 的属性，用于统一来源中的 ObjectScript 文件的行尾。 如果仓库由 Windows 和 Mac/Ubuntu 所有者协作，此文件非常有用。 [.gitignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitignore) - 你不希望 git 跟踪其更改历史记录的文件。 通常是一些隐藏的操作系统级文件，例如 .DS_Store。 好了！ 如何使你的仓库可被 docker 运行并且对协作友好？   1. 克隆[此仓库](https://github.com/intersystems-community/objectscript-docker-template)。 2. 复制以下所有文件： [Dockerfile](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Dockerfile) [docker-compose.yml](https://github.com/intersystems-community/objectscript-docker-template/blob/master/docker-compose.yml) [Installer.cls](https://github.com/intersystems-community/objectscript-docker-template/blob/master/Installer.cls) [iris.script](https://github.com/intersystems-community/objectscript-docker-template/blob/master/iris.script) [settings.json](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.vscode/settings.json "settings.json"){#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73} [.dockerignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.dockerignore ".dockerignore"){#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637} [.gitattributes](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitattributes ".gitattributes"){#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1} [.gitignore](https://github.com/intersystems-community/objectscript-docker-template/blob/master/.gitignore ".gitignore"){#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb} 到你的仓库。 更改 [Dockerfile 中的这一行](https://github.com/intersystems-community/objectscript-docker-template/blob/10f4422c105d5c75111fde16a184a83f5ff86d06/Dockerfile#L15)，使目录与仓库中要导入 IRIS 的 ObjectScript 匹配（如果在 /src 文件夹中则不要更改）。 就这样。 每个人（也包括你）都会将你的代码导入到新的 IRISAPP 命名空间的 IRIS 中。 **人们如何启动你的项目** 在 IRIS 中执行任何 ObjectScript 项目的法则为： 1. Git clone 项目到本地 2. 运行项目： $ docker-compose up -d $ docker-compose exec iris iris session iris Node: 05a09e256d6b, Instance: IRIS USER>zn "IRISAPP" **开发者如何为你的项目做出贡献** 1. 对仓库执行分叉，并将分叉后的仓库 git clone 到本地 2. 在 VSCode 中打开该文件夹（还需要在 VSCode 中安装 [Docker](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) 和 [ObjectScript](https://marketplace.visualstudio.com/items?itemName=daimor.vscode-objectscript&ssr=false#review-details) 扩展） 3. 右击 docker-compose.yml->重启 - [VSCode ObjectScript](https://openexchange.intersystems.com/package/VSCode-ObjectScript) 将自动连接并准备好编辑/编译/调试 4. 向你的仓库提交、推送和拉取请求更改 以下是操作过程的短 gif：  好了！ 编码愉快！  

亲爱的社区用户，您好！ 您知道吗，在 Global Masters，您可以兑换关于以下任何 InterSystems 产品的 InterSystems 专家咨询：InterSystems IRIS数据平台、IRIS医疗版、互操作平台 (Ensemble)、IRIS Analytics (DeepSee)、Caché、HealthShare统一的健康档案。 我们还有一个振奋人心的消息要分享，我们现在可以提供以下语言的咨询： 英语、葡萄牙语、俄语、德语、法语、意大利语、西班牙语、日语、汉语 而且！ 咨询时长延长到 1.5 小时，让您与专家深入探讨主题。 如果您有兴趣，不要犹豫，快来 Global Masters 兑换奖励吧！ 如果您还不是 Global Masters 的会员，欢迎您“点击此处加入”点击 InterSystems 登录按钮，然后使用您的 InterSystems WRC 凭据）。 要了解关于 Global Masters 的更多信息，请阅读文章：认识Global Masters 倡导中心，从这里开始！ 让我们在 InterSystems Global Masters 上见！🙂

企业需要快速有效地扩展和管理其全球计算基础设施，同时优化和管理资本成本及支出。 Amazon Web Services (AWS) 和 Elastic Compute Cloud (EC2) 计算和存储服务提供高度稳健的全球化的计算基础设施，可满足最苛刻的基于 Caché 的应用程序的需求。Amazon EC2 基础设施使各公司能够迅速预置计算能力和/或快速灵活地将其现有内部基础架构扩展到云端。 AWS 针对安全、网络、计算和存储提供了一套丰富的服务和强大的企业级机制。 AWS 的核心是 Amazon EC2。 它是支持各种操作系统和机器配置（例如 CPU、RAM、网络）的云计算基础设施。 AWS 提供预先配置的虚拟机 (VM) 映像（称为 Amazon 系统映像或 AMI），客户操作系统包括各种 Linux® 和 Windows 发行版及版本。 可以将其它软件用作 AWS 中运行的虚拟化实例的基础。 您可以将这些 AMI 用作实例化以及安装或配置其他软件、数据等的起点，以创建特定于应用程序或工作负载的 AMI。 与任何平台或部署模式一样，必须留心以确保考虑到应用程序环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细介绍以下每个方面。 网络设置和配置。 此部分介绍基于 Caché 的应用程序在 AWS 中的网络设置，包括为参考架构内不同层级和角色的逻辑服务器组提供支持的子网。 服务器设置和配置。 此部分介绍为每一层设计各种服务器时涉及的服务和资源。 还包括用于跨可用区实现高可用性的架构。 安全。 此部分讨论 AWS 中的安全机制，包括如何配置实例和网络安全以实现对整体解决方案以及层和实例之间的授权访问。 部署和管理。此部分提供有关打包、部署、监控和管理的详细信息。 架构和部署方案 本文提供了几个在 AWS 内实现的参考架构，作为提供基于 InterSystems 技术（包括 Caché、Ensemble、HealthShare、TrakCare）以及相关嵌入式技术（如 DeepSee、iKnow、CSP、Zen 和 Zen Mojo）的高性能和高可用性应用程序的示例。 为了了解如何在 AWS 上托管 Caché 及相关组件，我们先来回顾一下典型 Caché 部署的架构和组件，并探讨一些常见的方案和拓扑。 Caché架构回顾 InterSystems 数据平台不断发展，提供先进的数据库管理系统和快速的应用程序开发环境，以在处理和分析复杂数据模型以及开发 Web 和移动应用程序方面实现突破。 这是新一代的数据库技术，提供多种数据访问模式。 数据只在单个集成数据字典中描述一次，并且可以通过对象访问、高性能 SQL 和强大的多维存取即时进行访问 – 所有这些方式可以同时访问相同数据。 图 1 说明了可用的 Caché 高级架构组件层和服务。 这些通用层也适用于 InterSystems TrakCare 和 HealthShare 产品。 图 1：高级组件层 常见部署方案 部署有许多可能的组合，但本文将介绍两种方案：混合模型和完整的云托管模型。 混合模型 在此方案中，公司希望在需要时将企业内部资源和 AWS EC2 资源都用于灾难恢复、内部维护应急、重新平台化计划或短期/长期扩容。 此模型可以为内部故障转移镜像成员集群提供业务连续性和灾难恢复的高可用性。 在该方案中，此模型的连接依赖于内部部署和 AWS 可用区之间的 VPN 隧道，将 AWS 资源作为企业数据中心的扩展。 还有其他连接方法，例如 _AWS Direct Connect_。 但是，这不是本文涵盖的内容。 有关 AWS Direct Connect 的更多详细信息，可以在here找到。 有关设置此 Amazon Virtual Private Cloud (VPC) 示例以支持内部数据中心灾难恢复的详细信息可以在here找到。 图 2：使用 AWS VPC 提供内部灾难恢复的混合模型 上面的示例展示了一个故障转移镜像对通过与 AWS VPC 的 VPN 连接在内部数据中心的运行。 所示的 VPC 在给定 AWS 区域的双可用区中提供了多个子网。 有两个灾难恢复 (DR) 异步镜像成员 (每个可用区有一个) 提供弹性。 云托管模型 在此方案中，基于 Caché 的应用程序（包括数据层和表示层）完全放在 AWS 云中，使用了单个 AWS 区域内的多个可用区。 可以使用相同的 VPN 隧道 AWS Direct Connect， 甚至纯互联网连接模型。 图 3：支持完整生产工作负载的云托管模型 图 3 中的示例说明了在 VPC 中支持整个应用程序生产部署的部署模型。 此模型利用双可用区，在可用区之间同步故障转移镜像，同时将负载均衡 Web 服务器和相关应用程序服务器作为 ECP 客户端。 每个层都隔离在一个单独的安全组中，以进行网络安全控制。 IP 地址和端口范围仅根据应用程序的需要开放。 存储和计算资源 存储 有多种类型的存储选项可供选择。 就本参考架构而言，将针对几种可能的用例讨论 Amazon Elastic Block Store (Amazon EBS) 和 （也称为临时驱动器）卷。 各种存储选项的更多详细信息可以在 here 和 here 找到。 Elastic Block Storage (EBS) EBS 提供了可与 Amazon EC2 实例（虚拟机）配合使用的持久块级存储，在 Linux 或 Windows 中可以将其格式化并挂载为传统文件系统，最重要的是，这些卷是非实例存储，独立于单个 Amazon EC2 实例的运行寿命而持续存在，这对于数据库系统非常重要。 此外，Amazon EBS 还提供了创建卷的时间点快照的功能，这些快照会持久保存在 Amazon S3 中。 这些快照可以用作新的 Amazon EBS 卷的起点，并保护数据以实现长期耐久性。 同一快照可用于实例化任意数量的卷。 这些快照可以跨 AWS 区域复制，因此可以更容易地利用多个 AWS 区域进行地理扩张、数据中心迁移和灾难恢复。 Amazon EBS 卷的大小范围为 1 GB 到 16 TB，以 1 GB 为增量进行分配。 Amazon EBS 内有三种不同的类型：磁介质卷、通用型 (SSD) 和预置 IOPS (SSD)。 以下各小节提供了每种类型的简要介绍。 磁介质卷 磁介质卷为具有中等或突发 I/O 要求的应用程序提供经济高效的存储。 磁介质卷设计为平均每秒提供约 100 次输入/输出操作 (IOPS)，最大突发能力为数百 IOPS。 磁介质卷也非常适合用作启动卷，其突发能力提供了快速的实例启动时间。 通用型 (SSD) 通用型 (SSD) 卷提供具有成本效益的存储，是各种工作负载的理想选择。 这些卷的延迟只有个位数毫秒，能够长时间突发至 3,000 IOPS，基准性能为 3 IOPS/GB，最高可达 10,000 IOPS (3,334 GB)。 通用型 (SSD) 卷的大小范围为 1 GB 到 16 TB。 预置 IOPS (SSD) 预置 IOPS (SSD) 卷设计用于为 I/O 密集型工作负载（例如对存储性能和随机访问 I/O 吞吐量的一致性敏感的数据库工作负载）提供可预测的高性能。 在创建卷时指定 IOPS 速率，然后 Amazon EBS 在给定一年的 99.9% 的时间内提供 10% 内的预置 IOPS 性能。 预置 IOPS (SSD) 卷的大小可以为 4 GB 到 16 TB，每个卷最多可预置 20,000 IOPS。 预置的 IOPS 与请求的卷大小之比最大为 30；例如，IOPS 为 3,000 的卷必须至少为 100 GB 大小。 预置 IOPS (SSD) 卷对每个预置的 IOPS 的吞吐量限制为 256 KB，最高 320 MB/秒（1,280 IOPS）。 本文讨论的架构使用 EBS 卷，因为这些卷更适合需要可预测的低延迟每秒输入/输出操作 (IOPS) 和吞吐量的生产工作负载。 选择特定的虚拟机类型时必须小心，因为并非所有 EC2 实例类型都可以访问 EBS 存储。 注意: 由于 Amazon EBS 卷是网络附加设备，Amazon EC2 实例执行的其他网络 I/O 以及共享网络上的总负载可能会影响单个 Amazon EBS 卷的性能。 为了让 Amazon EC2 实例充分利用 Amazon EBS 卷上的预置 IOPS，可以将选定的 Amazon EC2 实例类型作为 Amazon EBS 优化的实例启动。 有关 EBS 卷的详细信息，可以在here 找到。 EC2 实例存储（临时驱动器） EC2 实例存储由托管您的正在运行的 Amazon EC2 实例的同一台物理服务器上的磁盘存储的预配置和预附加块组成。 提供的磁盘存储量因 Amazon EC2 实例类型而异。 在提供实例存储的 Amazon EC2 实例系列中，较大的实例往往提供更多更大的实例存储量。 存储优化 (I2) 和密集存储 (D2) 的 Amazon EC2 实例系列提供针对特定用例的专用实例存储。 例如，I2 实例提供了非常快的 SSD 实例存储，能够支持超过 365,000 的随机读取 IOPS 和 315,000 的写入 IOPS，并提供具有成本吸引力的定价模型。 与 EBS 卷不同，该存储不是永久性的，只能用于实例的生命周期，不能分离或附加到其他实例。 实例存储用于临时存储不断变化的信息。 在 InterSystems 技术和产品领域中，诸如将 Ensemble 或 Health Connect 用作企业服务总线 (ESB) 的项目、使用企业缓存协议 (ECP) 的应用程序服务器或将 Web 服务器与 CSP 网关一起使用，对于这种类型的存储和存储优化的实例类型，以及使用预置和自动化工具来提高有效性和支持弹性的操作来说，都是很好的用例。 有关实例存储卷的详细信息，可以在here 找到。 计算 EC2 实例 有多种实例类型可供使用，它们针对各种用例进行了优化。 实例类型包括 CPU、内存、存储和网络容量的不同组合，从而实现无数种组合来合理调整您的应用程序的资源要求。 就本文档而言，将参考_通用 M4_ Amazon EC2 实例类型作为优化环境大小的方法，这些实例提供 EBS 卷的功能和优化。 根据您的应用程序的容量要求和定价模型，还可能有替代方案。 M4 实例是最新一代的_通用_实例。 此系列提供了计算、内存和网络资源的平衡配置，对于许多应用程序来说是很好的选择。 容量范围为 2 到 64 个虚拟 CPU 和 8 到 256GB 的内存，以及相应的专用 EBS 带宽。 除了各个实例类型，还有分层的分类，例如专用主机、Spot 实例、预留实例和专用实例，每个类别的定价、性能和隔离都不同。 在 here 确认当前可用实例的可用性和详细信息。 可用性和操作 Web/App 服务器负载均衡 您的基于 Caché 的应用程序可能需要外部和内部负载均衡的 Web 服务器。 外部负载均衡器用于通过互联网或 WAN（VPN 或 Direct Connect）进行的访问，内部负载均衡器可用于内部流量。 AWS Elastic Load Balancing 提供两种类型的负载均衡器 – 应用程序负载均衡器和传统负载均衡器。 传统负载均衡器 传统负载均衡器根据应用程序或网络信息对流量进行路由，是在多个需要高可用性、自动扩展和强大安全性的 EC2 实例之间实现简单的流量负载均衡的理想选择。 具体的详细信息和功能可在here 找到。 应用负载均衡器 应用程序负载均衡器是 Elastic Load Balancing 服务的负载均衡选项，该服务在应用程序层运行，允许您根据一个或多个 Amazon EC2 实例上运行的多个服务或容器中的内容定义路由规则。 此外，还支持 WebSockets 和 HTTP/2。 具体的详细信息和功能可在here找到。 示例 在以下示例中，定义了一组三个 Web 服务器，每个服务器都在一个单独的可用区，以提供最高级别的可用性。 必须为 Web 服务器负载均衡器配置粘性会话 ，才能支持使用 cookie 将用户会话固定到特定 EC2 实例的功能。 当用户继续访问您的应用程序时，流量将路由到相同实例。 图 4 给出了 AWS 中的传统负载均衡器的一个简单示例。 图 4：传统负载均衡器示例 数据库镜像 在 AWS 上部署基于 Caché 的应用程序时，如果要为 Caché 数据库服务器提供高可用性，则需要在给定的主 AWS 区域使用同步数据库镜像来提供高可用性，还可能需要使用异步数据库镜像将数据复制到辅助 AWS 区域中的热备份以实现灾难恢复，具体取决于正常运行时间服务水平协议要求。 数据库镜像是两个数据库系统的逻辑分组，也就是所说的故障转移成员，它们在物理上是仅通过网络连接的独立系统。 在这两个系统之间进行仲裁后，镜像会自动将其中一个系统指定为主系统； 另一个成员自动成为备份系统。 外部客户端工作站或其他计算机通过镜像虚拟 IP (VIP) 连接到镜像，该虚拟 IP 在镜像配置期间指定。 镜像 VIP 会自动绑定到主镜像系统上的接口。 注意: 在 AWS 中，无法以传统方式配置镜像 VIP，因此设计了替代解决方案。 不过，镜像可跨子网获得支持。 目前在 AWS 中部署数据库镜像的建议是，在跨越三个不同可用区的同一个 VPC 中配置三个实例（主要、备份、仲裁器）。 这可以确保在任何给定时间，AWS 都将保证可以从外部连接其中的至少两个虚拟机，SLA 达到 99.95%。 这样可以为数据库数据本身提供充分的隔离和冗余。 有关 AWS EC2 服务水平协议的详细信息，可在here 找到。 故障切换成员之间的网络延迟没有硬性上限。延迟增加所产生的影响因应用程序而异。如果故障转移成员之间的往返时间与磁盘写入服务时间相似，则预计不会产生影响。 但是，当应用程序必须等待数据变为持久保存（有时称为日志同步）时，响应时间可能是一个问题。 有关数据库镜像和网络延迟的详细信息，可在here 找到。 虚拟 IP 地址和自动故障转移 大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力，这种地址通常用在数据库故障转移设计中。 为解决这一问题，Caché、Ensemble 和 HealthShare 中增强了几种最常用的连接方法，尤其是 ECP 客户端和 CSP 网关，从而不再依赖 VIP 功能使它们实现镜像感知。 xDBC、直接 TCP/IP 套接字等连接方法或其他直接连接协议仍需要使用 VIP。 为解决这些问题，InterSystems 数据库镜像技术通过使用 API 与 AWS Elastic Load Balancer (ELB) 进行交互以实现类似 VIP 的功能，使得在 AWS 中为这些连接方法提供自动故障转移成为可能，从而在 AWS 中提供完整而强大的高可用性设计。 此外，AWS 最近推出了一种新类型的 ELB，称为应用程序负载均衡器。 这种类型的负载均衡器在第 7 层运行，支持基于内容的路由，并支持在容器中运行的应用程序。 基于内容的路由对于使用分区数据或数据分片部署的大数据类型项目尤其有用。 与虚拟 IP 一样，这是网络配置的突然变化，不涉及任何应用逻辑，不会向已连接到发生故障的主镜像成员的现有客户端发出正在进行故障转移的通知。 根据故障的性质，这些连接终止的原因可能是故障本身、应用程序超时或错误、新的主镜像实例强制旧的主镜像实例停机，或者客户端使用的 TCP 保持连接定时器过期。 结果，用户可能必须重新连接并登录。 您的应用程序的行为将决定此行为。 有关各种类型的可用 ELB 的详细信息，可在here找到。 AWS EC2 实例对 AWS Elastic Load Balancer 方法的调用 在此模型中，ELB 可以定义一个包含故障转移镜像成员和潜在 DR 异步镜像成员的服务器池，其中只有一个活动条目是当前主镜像成员，或者只定义一个具有单个活动镜像成员条目的服务器池。 图 5：与 Elastic Load Balancer 交互的 API 方法（内部） 当某个镜像成员成为主镜像成员时，会从您的 EC2 实例向 AWS ELB 发出一个 API 调用，以调整/指示新主镜像成员的 ELB。 图 6：使用负载均衡器的 API 故障转移到镜像成员B 如果主镜像成员和备份镜像成员都变得不可用，同一模型也适用于升级 DR 异步镜像成员。 图 7：使用负载均衡器的 API 将 DR 异步镜像成员升级为主镜像成员 按照标准推荐的 DR 过程，上面的图 6 中的 DR 成员升级需要人为决策，因为异步复制可能会造成数据丢失。 不过，一旦执行该操作，就不再需要对 ELB 执行管理操作。 在升级期间调用 API 后，将自动路由流量。 API 详细信息 这个用于调用 AWS 负载均衡器资源的 API 在 ^ZMIRROR 例程中专门定义为以下过程调用的一部分： $$CheckBecomePrimaryOK^ZMIRROR() 在此过程内，插入您选择的要从 AWS ELB REST API、命令行界面等使用的任何 API 逻辑或方法。 与 ELB 进行交互的一种有效且安全的方法是使用 AWS Identity and Access Management (IAM) 角色，这样不必为 EC2 实例分配长期凭据。 IAM 角色提供了 Caché 可以用来与 AWS ELB 进行交互的临时权限。 有关使用分配给 EC2 实例的 IAM 角色的详细信息，可在 here 找到。 AWS Elastic Load Balancer 轮询方法 2017.1 提供了一种使用 CSP 网关的mirror_status.cxw 页的轮询方法，可以将其用作 ELB 监控每个已添加到 ELB 服务器池的镜像成员运行状况的轮询方法。只有主镜像会响应“SUCCESS”，因而网络流量只定向到活动的主镜像成员。 此方法不需要向 ^ZMIRROR 添加任何逻辑。 请注意，大多数负载均衡网络设备对运行状态检查的频率有限制。 通常，最高频率不少于5秒，这通常是可接受的，可支持大多数正常运行时间服务水平协议。 一个对以下资源的 HTTP 请求将测试本地缓存配置的镜像成员状态。 /csp/bin/mirror_status.cxw 对于所有其他情况，这些镜像状态请求的路径应解析到适当的缓存服务器和命名空间，它们与用于请求实际 CSP 页的缓存服务器和命名空间使用相同的分层机制。 示例：在 /csp/user/ 路径中测试服务于应用程序的配置的镜像状态： /csp/user/mirror_status.cxw 注意：调用镜像状态检查不消耗 CSP 许可证。 根据目标实例是否为活动的主要成员，网关将返回以下 CSP 响应之一： ** Success (Is the Primary Member) =============================== HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 7 SUCCESS ** Failure (Is not the Primary Member) =============================== HTTP/1.1 503 Service Unavailable Content-Type: text/plain Connection: close Content-Length: 6 FAILED ** Failure (The Cache Server does not support the Mirror_Status.cxw request) =============================== HTTP/1.1 500 Internal Server Error Content-Type: text/plain Connection: close Content-Length: 6 FAILED 下图说明了各种使用轮询方法的方案。 图 8：轮询所有镜像成员 如上面的图 8 所示，所有镜像成员都在运行，只有主镜像成员向负载均衡器返回“SUCCESS”，因此网络流量将只定向到该镜像成员。 图 9：使用轮询故障转移到镜像成员 B 上图演示了将 DR 异步镜像成员升级到负载均衡池中的过程，这通常假定同一台负载均衡网络设备为所有镜像成员提供服务（本文稍后将介绍按地理位置划分的方案）。 按照标准推荐的 DR 过程，DR 成员升级需要人为决策，因为异步复制可能会造成数据丢失。 不过，一旦执行该操作，就不再需要对 ELB 执行管理操作。 它会自动发现新的主镜像成员。 图 10：使用轮询对 DR 异步镜像成员进行故障转移和升级 备份和还原 备份操作有多个选项。 对于 InterSystems 产品的 AWS 部署，可以使用以下三个选项。 前两个选项包括一个快照类型过程，该过程在创建快照前会暂停将数据库写入磁盘，然后在快照成功建立后恢复更新。 执行以下高级步骤使用任一快照方法创建干净备份： 通过数据库冻结 API 调用暂停对数据库的写入。 创建操作系统和数据磁盘的快照。 通过数据库解锁API 调用恢复 Caché 写入。 将设施存档备份到备份位置。 可以定期添加完整性检查等其他步骤，以确保备份干净一致。 决定使用哪个选项取决于组织的运营要求和策略。 InterSystems 可与您详细讨论各种选项。 EBS 快照 EBS 快照是在高度可用和成本较低的 Amazon S3 存储上创建时间点快照的非常快速且有效的方法。 EBS 快照连同 InterSystems 外部冻结和解锁API 功能，可以实现真正的 24x7 弹性运行，并确保干净的定期备份。 使用 AWS 提供的服务（如 Amazon CloudWatch Events）或市场上的第三方解决方案（如 Cloud Ranger 或 N2W Software Cloud Protection Manager 等等），有许多选项可以使该过程自动化。 此外，还可以使用 AWS 直接 API 调用，以编程方式创建您自己的自定义备份解决方案。 有关如何利用 API 的详细信息，请参见here 和here. 注意：InterSystems 不为上述任何第三方产品背书或明确进行验证。 测试和验证取决于客户. 逻辑卷管理器快照 或者，通过在虚拟机自身内部署单独的备份代理，并利用文件级备份与 Linux 逻辑卷管理器 (LVM) 快照或 Windows 卷影复制服务 (VSS) 相结合，可以使用市场上的许多第三方备份工具。 此模型的主要优点之一是能够对基于 Windows 或 Linux 的实例进行文件级还原。 该解决方案有几点需要注意，由于 AWS 和大多数其他 IaaS 云提供商不提供磁带介质，因此所有备份存储库都基于磁盘进行短期归档，而且能够利用 Amazon S3 低成本存储并最终使用 Amazon Glacier 实现长期保留 (LTR)。 如果使用此方法，强烈建议使用支持去重技术的备份产品，以最有效地利用基于磁盘的备份存储库。 这些具有云支持的备份产品的示例包括但不限于：Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。 注意：InterSystems 不为上述任何第三方产品背书或明确进行验证。 测试和验证取决于客户. Caché 在线备份 对于小型部署，内置 Caché 在线备份工具也是一个可行选项。 该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据，然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 在 AWS 中，在线备份完成后，必须将备份输出文件和系统使用的所有其他文件复制到用作文件共享的 EC2 (CIFS/NFS)。 该过程需要在虚拟机中编写脚本并执行。 在线备份是入门级方法，适合于希望实施低成本备份解决方案的小型站点。 但是，随着数据库的增大，建议将使用快照技术的外部备份作为最佳做法，其优势包括：备份外部文件、更快的恢复时间，以及企业范围的数据视图和管理工具。 灾难恢复 在 AWS 上部署基于 Caché 的应用程序时，建议将 DR 资源（包括网络、服务器和存储）放在不同的 AWS 区域中，或者至少放在单独的可用区中。指定的 DR AWS 区域所需的容量取决于您组织的需求。 在大多数情况下，以 DR 模式运行时需要 100％ 的生产能力，但作为一个弹性模型，可以先预置较少的能力，直到需要更多能力。 较少的能力可以体现为较少的 Web 和应用程序服务器，甚至可能使用较小的 EC2 实例类型作为数据库服务器，升级后，EBS 卷将附加到较大的 EC2 实例类型。 异步数据库镜像用于连续复制到 DR AWS 区域的 EC2 实例。 镜像使用数据库事务日志以对主系统性能影响最小的方式通过 TCP/IP 网络复制更新。 强烈建议对这些 DR 异步镜像成员配置日志文件压缩和加密。 公共互联网上所有希望访问应用程序的外部客户端都将通过作为附加 DNS 服务的 Amazon Route53 进行路由。Amazon Route53 用作将流量定向至当前活动数据中心的交换机。 Amazon Route53 执行三种主要功能： 域注册 –允许您注册 example.com 之类的域名。 域名系统 (DNS) 服务 – Amazon Route53 将类似 www.example.com 的友好域名转换为 192.0.2.1 之类的 IP 地址。 Amazon Route53 使用全球权威 DNS 服务器网络来响应 DNS 查询，从而降低延迟。 运行状况检查–Amazon Route53 通过互联网向您的应用程序发送自动请求，以验证其是否可达、可用和正常运行。 这些功能的详细信息可在 here找到。 就本文档而言，将讨论 DNS 故障转移和 Route53 运行状况检查。 运行状况检查监控和 DNS 故障转移的详细信息可在 here 和here找到。 Route53 的工作方式是向每个端点发出常规请求，然后验证响应。 如果某个端点未能提供有效响应， 它将不再包含在 DNS 响应中，而是返回一个替代的可用端点。 这样，用户流量就会从发生故障的端点转向可用的端点。 使用上述方法，将只允许流量转向特定区域和特定镜像成员。 这是由端点定义控制的，它是本文先前讨论过的 mirror_status.cxw 页，由 InterSystems CSP 网关提供。 只有主镜像成员会在运行状况检查中报告 HTTP 200 来表示“SUCCESS”。 下图演示了高级别的故障转移路由策略。 此方法和其他策略的详细信息可在here找到。 图 11：Amazon Route53 故障转移例程策略 在任何给定时间，只有一个区域会根据端点监控进行在线报告。 这样可以确保流量在给定时间只流向一个区域。 区域之间的故障转移无需增加步骤，因为端点监控将检测到指定的主 AWS 区域中的应用程序已关闭，并且该应用程序此时在次要 AWS 区域中处于活动状态。 这是因为 DR 异步镜像成员已被手动升级为主镜像成员，随后允许 CSP 网关将 HTTP 200 报告给 Elastic Load Balancer 端点监控。 上述解决方案有很多替代方案，可以根据您组织的运营要求和服务水平协议进行自定义。 监控 Amazon CloudWatch 可用于为您的所有 AWS 云资源和应用程序提供监控服务。 Amazon CloudWatch 可用于收集和跟踪指标，收集和监控日志文件，设置警报，并自动对 AWS 资源的变化做出反应。 Amazon CloudWatch 可以监控 AWS 资源，如 Amazon EC2 实例，以及您的应用程序和服务生成的自定义指标，还有您的应用程序生成的任何日志文件。 您可以使用 Amazon CloudWatch 获得系统范围内的资源利用率、应用程序性能和运行状况的可见性。 详细信息可在here找到。 自动预置 目前，市场上有许多工具，包括 Terraform、Cloud Forms、Open Stack 和 Amazon 自己的 CloudFormation。 使用这些工具并与其他工具（如 Chef、Puppet、Ansible 等）相结合，可以提供完整的基础设施即代码，来支持 DevOps 或简单地以完全自动化的方式引导您的应用程序。 Amazon CloudFormation 的详细信息可在here找到。 网络连接 根据您的应用程序的连接要求，有多种连接模型可用：使用互联网、VPN 或使用 Amazon Direct Connect 的专用链接。 选择方法取决于应用程序和用户需求。 三种方法的带宽使用情况各不相同，最好通过 AWS 代表或 Amazon 管理控制台确认给定区域的可用连接选项。 安全 当决定通过任何公共 IaaS 云提供商部署应用程序时，都需要谨慎。 应遵循您组织的标准安全策略或专门针对云制定的新策略，以保持您组织的安全合规性。 当组织的数据存储在其国家/地区之外，并受数据所在国家/地区的法律约束时，相关的数据主权也是您必须了解的。 现在，云部署增加了数据在客户数据中心和物理安全控制之外的风险。 强烈建议对静态数据（数据库和日志）和动态数据（网络通信）使用 InterSystems 数据库和日志加密，分别使用 AES 和 SSL/TLS 加密。 与所有加密密钥管理一样，您需要按照您组织的策略记录并遵循正确的程序，以确保数据安全，防止不必要的数据访问或安全漏洞。 Amazon 提供了大量文档和示例，为基于 Caché 的应用程序提供高度安全的运行环境。 请务必查看here 关于 Identity Access Management (IAM) 的各种讨论主题。 架构图示例 下图说明了典型的 Caché 安装，其以数据库镜像（同步故障转移和 DR 异步）、使用 ECP 的应用程序服务器，以及多个负载均衡 Web 服务器的方式提供高可用性。 TrakCare 示例 下图说明了典型的 TrakCare 部署，其中包含多个负载均衡 Web 服务器，两个作为 ECP 客户端的 EPS 打印服务器，以及数据库镜像配置。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 ECP 客户端和 CSP 网关可感知镜像，不需要 VIP。 如果您正在使用 Direct Connect，则可为灾难恢复方案启用包括多线路和多区域访问在内的多个选项。 与电信提供商合作以了解他们支持的高可用性和灾难恢复方案至关重要。 下面的示例参考架构图包括活动或主要区域中的高可用性，以及在主要 AWS 区域不可用时到其他 AWS 区域的灾难恢复。 而且在此示例中，数据库镜像包含 TrakCare DB、TrakCare Analytics 和 Integration 命名空间，全部在单个镜像集内。 图 12：TrakCare AWS 参考架构图 – 物理架构 此外，下图显示了更有逻辑的架构图，其中包含所安装的相关高级软件产品及功能用途。 图 13：TrakCare AWS 参考架构图 – 逻辑架构 HealthShare 示例 下图显示了一个典型的 HealthShare 部署，其中含有多个负载均衡 Web 服务器，以及多个 HealthShare 产品，包括 Information Exchange、Patient Index、Personal Community、Health Insight 和 Health Connect。 这些产品中的每一个都包含一个数据库镜像对，以在多个可用区内提供高可用性。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 用于 HealthShare 产品之间的 Web 服务通信的 CSP 网关可感知镜像，不需要 VIP。 下面的示例参考架构图包括活动或主要区域中的高可用性，以及在主要区域不可用时到其他 AWS 区域的灾难恢复。 图 14：HealthShare AWS 参考架构图 – 物理架构 此外，下图显示了更有逻辑的架构图，其中包含所安装的相关高级软件产品、连接要求和方法，以及相应的功能用途。 Figure-15: HealthShare AWS 参考架构图 – 逻辑架构

InterSystems IRIS、IRIS for Health和HealthShare Health Connect的2021.1版本的预览版现已发布。 由于这是一个预览版，我们希望在下个月的通用版本发布之前了解您对这个新版本的体验。请通过开发者社区分享您的反馈，以便我们能够共同打造一个更好的产品。 InterSystems IRIS数据平台2021.1是一个扩展维护（EM）版本。自2020.1（上一个EM版本）以来，在持续交付（CD）版本中增加了许多重要的新功能和改进。请参考2020.2、2020.3和2020.4的发布说明，了解这些内容的概况。 这个版本的增强功能为开发人员提供了更大的自由度，可以用他们选择的语言构建快速和强大的应用程序，并使用户能够通过新的和更快的分析功能更有效地处理大量的信息。 通过InterSystems IRIS 2021.1，客户可以部署InterSystems IRIS Adaptive Analytics，这是一个附加产品，它扩展了InterSystems IRIS，为分析终端用户提供了更强大的易用性、灵活性、可扩展性以及效率，而不管他们选择何种商业智能（BI）工具。它能够定义一个利于分析的业务模型，并通过在后台自主构建和维护临时数据结构，透明地加速针对该模型运行分析查询时的工作负载。 这个版本中的其他重点新功能包括 一套综合的外部语言网关，改进了可管理性，现在包括R和Python，可以用您选择的语言构建强大和可扩展的服务器端代码InterSystems Kubernetes Operator（IKO）为您的环境提供声明式配置和自动化，现在还支持部署InterSystems System Alerting & Monitoring（SAM）。InterSystems API Manager v1.5，包括改进的用户体验和对Kafka的支持IntegratedML的主流版本，使SQL开发人员能够在纯粹的SQL环境中直接构建和部署机器学习模型 InterSystems IRIS for Health 2021.1包括InterSystems IRIS的所有增强功能。此外，该版本通过针对FHIR数据解析和评估FHIRPath表达式的API，进一步扩展了该平台对FHIR®标准的广泛支持。这是对2020.1以来发布的重要的FHIR相关功能的补充，包括对FHIR Profiles、FHIR R4 Transforms和FHIR客户端API的支持。 关于所有这些功能的更多细节可以在产品文档中找到。 InterSystems IRIS 2021.1文档和发布说明InterSystems IRIS for Health 2021.1文档和发布说明HealthShare Health Connect 2021.1 文档和发布说明 EM版本包括所有支持平台的传统安装包，以及OCI（Open Container Initiative）又称Docker容器格式的容器镜像。 完整的清单，请参考支持平台文档。 安装包和预览密钥可以从WRC的预览下载网站获得。 InterSystems IRIS和IRIS for Health的企业版的容器镜像以及所有相应的组件都可以从InterSystems容器注册处使用以下命令获得。 docker pull containers.intersystems.com/intersystems/iris:2021.1.0.205.0 docker pull containers.intersystems.com/intersystems/irishealth:2021.1.0.205.0 关于可用镜像的完整列表，请参考ICR文档。 社区版的容器镜像也可以使用以下命令从Docker商店拉取。 docker pull store/intersystems/iris-community:2021.1.0.205.0 docker pull store/intersystems/iris-community-arm64:2021.1.0.205.0 docker pull store/intersystems/irishealth-community:2021.1.0.205.0 docker pull store/intersystems/irishealth-community-arm64:2021.1.0.205.0 另外，所有容器镜像的tarball版本都可以通过WRC的预览下载网站获得。 InterSystems IRIS Studio 2021.1是一个独立的IDE，用于Microsoft Windows，可以通过WRC的预览下载网站下载。它与InterSystems IRIS和IRIS for Health 2021.1及以下版本一起使用。InterSystems还支持 VSCode-ObjectScript 插件，用于将 Visual Studio Code 做为 InterSystems IRIS 开发IDE，该插件可用于Microsoft Windows、Linux和MacOS。 其他独立的InterSystems IRIS 2021.1组件，如ODBC驱动程序和Web网关，可从同一页面获得。 该预览版的构建号是 2021.1.0.205.0。 通过www.DeepL.com/Translator（免费版）翻译

InterSystems API Manager (IAM)的2.3版本的正式版本已经发布。 IAM的容器，包括从IAM早期版本升级的所有相关工件，可以从。WRC软件分发站点 的组件区下载. 这个版本的构建号是IAM 2.3.3.2-1。 这个版本是基于Kong企业版2.3.3.2。 InterSystems API Manager 2.3使其更容易以安全的方式和高可用性的场景进行部署 它有许多新的功能，包括: 引入了混合模式 更广泛地支持Docker Secrets 混合模式允许你在数据面和控制面部署IAM节点。当数据平面处理API流量时，控制平面用于配置数据平面节点并观察来自数据平面的遥测数据。这赋予了部署更多的灵活性，减轻了部署HA场景的工作量。关于混合模式的更多信息可以在[这里](https://docs.konghq.com/enterprise/2.3.x/deployment/hybrid-mode/)找到。在接下来的日子里，InterSystems开发者社区也将更详细地介绍这一功能。 IAM 2.3的文档可以在 这里找到。该文档只涉及IAM特有的元素。产品中的文档链接将用户直接带到Kong Enterprise的文档。 从IAM 1.5.0.9升级需要通过两个中间版本进行增量升级，这在文档中会有更详细的描述。 IAM仅以OCI（Open Container Initiative）又称Docker容器格式提供。容器镜像可用于Linux x86-64和Linux ARM64的OCI兼容运行时引擎，详见 支持平台文件。 Best Regards, Stefan

Intersystems RIS 机器学习工具包, 包括Python/R/Julia, 支持协调管理基于云的高级分析服务，如微软Azure数据工厂和机器学习。

我们刚刚发布了包管理器的一个小更新，如我们11 月宣布，我们已经将 ZPM 重命名为 IPM。现在这个是一个错误修复版本，正确解释 ROBOCOPY 返回代码并修复阻止安装某些包的回归。 在这里获取： https://github.com/intersystems/ipm/releases/tag/v0.5.2

** 2018 年 2 月 12 日修订 虽然本文是关于 InterSystems IRIS 的，但它也适用于 Caché、Ensemble 和 HealthShare 发行版。 介绍 内存以页为单位进行管理。 Linux 系统上的默认页面大小为 4KB。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11 和 Oracle Linux 6 引入了一种根据系统配置提供 2MB 或 1GB 大小的增加页面大小的方法，称为 HugePages。 起初 HugePages 需要在启动时分配，如果管理或计算不当可能会导致资源浪费。因此，各种 Linux 发行版引入了默认启用 2.6.38 内核的Transparent HugePages。这是一种自动创建、管理和使用 HugePages 的方法。以前的内核版本也可能具有此功能，但可能未标记为 [always] 而是设置为 [madvise]。 Transparent Huge Pages (THP) 是一种 Linux 内存管理系统，它通过使用更大的内存页面来减少在具有大量内存的机器上进行Translation Lookaside Buffer (TLB) 查找的开销。然而，在当前的 Linux 版本中，THP 只能映射单个进程的堆栈空间。 问题 任何 Caché 系统中的大部分内存分配都是共享内存段（全局和例程缓冲池），因为 THP 不处理这些共享内存段。因此，THP 不用于共享内存，而仅用于每个单独的进程。这可以使用一个简单的 shell 命令来确认。 以下是来自 InterSystems 的测试系统的示例，其中显示了分配给 Caché 进程的 2MB THP： # grep -e AnonHugePages /proc/*/smaps | awk '{ if($2>4) print $0} ' | awk -F "/" '{print $0; system("ps -fp " $3)} ' /proc/2945/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 2945 1 0 2015 ? 01:35:41 /usr/sbin/rsyslogd -n /proc/70937/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70937 70897 0 Jan27 pts/0 00:01:58 /bench/EJR/ycsb161b641/bin/cache WD /proc/70938/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70938 70897 0 Jan27 pts/0 00:00:00 /bench/EJR/ycsb161b641/bin/cache GC /proc/70939/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70939 70897 0 Jan27 pts/0 00:00:39 /bench/EJR/ycsb161b641/bin/cache JD /proc/70939/smaps:AnonHugePages: 4096 kB UID PID PPID C STIME TTY TIME CMD root 70939 70897 0 Jan27 pts/0 00:00:39 /bench/EJR/ycsb161b641/bin/cache JD /proc/70940/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70940 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 1 /proc/70941/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70941 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 2 /proc/70942/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70942 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 3 /proc/70943/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70943 70897 0 Jan27 pts/0 00:00:33 /bench/EJR/ycsb161b641/bin/cache SWD 7 /proc/70944/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70944 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 4 /proc/70945/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70945 70897 0 Jan27 pts/0 00:00:30 /bench/EJR/ycsb161b641/bin/cache SWD 5 /proc/70946/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70946 70897 0 Jan27 pts/0 00:00:30 /bench/EJR/ycsb161b641/bin/cache SWD 6 /proc/70947/smaps:AnonHugePages: 4096 kB 此外，运行时内存分配存在潜在的性能损失，尤其是对于具有高作业或进程创建率的应用程序。 建议 InterSystems 建议暂时禁用 THP，因为预期的性能提升不适用于 IRIS 共享内存段，并且可能会对某些应用程序产生负面性能影响。 通过运行以下命令检查您的 Linux 系统是否启用了 Transparent HugePages： 对于 Red Hat Enterprise Linux 内核： # cat /sys/kernel/mm/redhat_transparent_hugepage/enabled 对于其它内核： # cat /sys/kernel/mm/transparent_hugepage/enabled 上面的命令将显示是否启用了 [always]、[madvise] 或 [never] 标志。如果从内核中删除 THP，则 /sys/kernel/mm/redhat_transparent_hugepage 或 /sys/kernel/mm/redhat/transparent_hugepage 文件不存在。 要在引导期间禁用透明 HugePages，请执行以下步骤： 1. 将以下条目添加到 /etc/grub.conf 文件中的内核引导行： transparent_hugepage=never 2.重启操作系统 有一种方法也可以即时禁用 THP，但这可能无法提供所需的结果，因为该方法只会停止为新进程创建和使用 THP。已经创建的 THP 不会被反汇编成常规内存页。建议完全重新启动系统以在启动时禁用 THP。 *注意：建议与您各自的 Linux 经销商确认以确认用于禁用 THP 的方法。

如果您已经使用%UnitTest 框架构建了单元测试，或者正在考虑这样做，请查看InterSystems 测试管理器Test Manager。 无需离开 VS Code，您现在可以浏览单元测试、运行或调试它们，并查看之前的运行结果。 InterSystems 测试管理器适用于 ObjectScript 扩展支持的两种源代码位置范例。您的单元测试类可以在 VS Code 的本地文件系统（“客户端编辑”范例）或服务器命名空间（“服务器端编辑”）中掌握。在这两种情况下，实际测试运行都发生在服务器命名空间中。 欢迎反馈。

在检查我们的^pButtons（在IRIS中改名为^SystemPerformance）性能监控工具的文档时，一位客户告诉我。"我理解所有内容，但我希望它能更简单......更容易定义配置文件，管理它们等等"。 在这次会议之后，我认为尝试为其提供一些更简单的人机界面是一个不错的试验。 这方面的第一步是在现有的pButtons例程上包裹一个基于类的API。 我还能够添加一些更多的 "功能"，比如显示当前正在运行的配置文件，它们剩余的运行时间，以前运行的进程等等。 下一步是在这个API的基础上添加一个REST API类。 有了这个工件（pButtons REST API），人们就可以在上面建立一个比较时髦的用户界面。 举个🌰： - 我在这里分享这个方法的几个步骤： 两个类是 "Basic "API – 以及REST API（包括一些单元测试类来测试这些）。 一个用于REST API的Swagger JSON。为了构建这个，我使用了当时（2017年）InterSystems IRIS中尚未发布的REST管理功能。在InterSystems IRIS提供的基本Swagger JSON的基础上，我添加了更多的信息。 以及一个更加简单的angular UI界面 (基于 http://websystique.com/angularjs/angularjs-crud-application-using-ngresource/) 几个重点提示: 大多数的 "Basic "API方法都使用有文档的和官方支持的pButtons/SystemPerformance rountine的入口点。但有些方法是访问由pButtons工具管理的内部结构。这些方法没有被记录下来，也不被支持，这些方法在升级后可能会停止工作而不被通知。 这段代码不应该作为使用InterSystems IRIS构建基于REST的Angular应用程序的 "最佳实践 "范例。UI部分只是作为一个例子/"预告 "和示例的起点，[例如，它并不完整--"常规部分"（例如，日志文件夹位置管理的占位符）没有实现；刷新内容并不完全工作，以及其他一些 "已知问题..."] 这段代码最早是在很久之前写的--所以: (a) 我重新检查/测试/修改确保能在IRIS上运行 (包括改些名字等等). (b) REST API并没有使用需求/设计优先的方法--我最初确实玩过（当时）IRIS-beta对生成Swagger的支持，现在用它把这个变成了需求/设计优先的方法. (c) 这个可能没有用到最新的特性. (d) 我现在还增加了对在Docker容器中运行的支持（有相关的Docker文件等）。 (e) 我还增加了能作为ZPM包安装的支持。 应用和源代码：https://openexchange.intersystems.com/package/sys-perf-restapi

InterSystems 数据平台团队非常高兴地宣布，InterSystems IRIS数据平台、InterSystems IRIS for Health和HealthShare Health Connect的2021.2版本现已向我们的客户和合作伙伴全面开放（GA）。 发布重点: InterSystems IRIS数据平台2021.2使开发、部署和管理连接数据和应用孤岛的增强型应用和业务流程更加容易。它有许多新的功能和改进! 为应用程序和界面开发人员提供的增强功能，包括： 嵌入式Python 使用Python进行互操作性开发 对Visual Studio Code ObjectScript扩展包的更新 增加了新的业务服务和操作，允许用户以最少的自定义编码来设置和运行SQL查询 对分析和人工智能的增强，包括： 新的SQL LOAD命令有效地将CSV和JDBC源数据加载到表中 增强适应性分析的功能 对云计算和运营任务的加强，包括: 新的云连接器使得在InterSystems IRIS应用程序中访问和使用云服务变得简单。 IKO的改进提高了Kubernetes资源的可管理性 对数据库和系统管理员的增强，包括: 在线分片再平衡可以在不中断操作的情况下自动在各节点间分配数据 自适应SQL引擎使用快速块采样和自动化来收集高级表的统计数据，并利用运行时信息来改进查询规划 通过新的流和日志文件压缩设置，InterSystems IRIS的存储需求得以降低 支持TLS 1.3和OpenSSL 1.1.1，使用系统提供的库 新的^TRACE工具报告详细的进程统计数据，如缓存点击率和读取率 关于所有这些功能的更多细节可以在产品文档中找到: InterSystems IRIS 2021.2 documentation and release notes InterSystems IRIS for Health 2021.2 documentation and release notes HealthShare Health Connect 2021.2 documentation and release notes 如何获得软件 InterSystems IRIS 2021.2是一个持续交付（CD）版本，现在带有所有支持平台的经典安装包，以及OCI（Open Container Initiative）（又称Docker容器格式）的容器镜像。 容器镜像可用于Linux x86-64和Linux ARM64的OCI兼容运行时引擎。 详见 支持平台文档. 每个持续交付产品的完整安装包都可以从WRC 支持中心的网站 获得 . 使用 "自定义 "安装选项使用户能够挑选他们需要的选项，如InterSystems Studio和IntegratedML，以正确地缩小他们的安装范围。 容器镜像 企业版本，和社区版本 和所有的相关组件都可以从 InterSystems Container Registry 使用以下命令获得: docker pull containers.intersystems.com/intersystems/iris:2021.2.0.649.0 docker pull containers.intersystems.com/intersystems/iris-ml:2021.2.0.649.0 docker pull containers.intersystems.com/intersystems/irishealth:2021.2.0.649.0 docker pull containers.intersystems.com/intersystems/irishealth-ml:2021.2.0.649.0 有关可用镜像的完整列表，请参考 ICR 文档. 另外，所有容器镜像的tarball版本可以通过WRC的 CD容器产品下载网站获得。. 我们在主要云市场上的相应列表将在未来几天内更新。 分享你的经验 我们很高兴看到这个版本现在达到了GA的里程碑，并渴望听到你对新软件的体验。请不要犹豫，通过InterSystmes的销售团队或 开发者社区 与我们联系。 对于选定的新功能和产品，我们已经建立了早期试用计划，允许我们的用户在软件发布之前进行评估。通过这些有针对性的举措，我们可以向目标受众学习，确保新产品在发布时能满足他们的需求。如果你有兴趣参与其中的任何一项，请通过InterSystems销售团队或 开发者社区 与我们联系。