搜索​​​​

文章
Qiao Peng · 一月 5, 2021

增强型日志监视器

各位开发者们大家好! 此前,我向各位介绍了一个非常好用的运行分析监控面板,它能使消息处理过程中的关键指标可视化,例如入站/出站消息的数量和平均处理时间等。 现在,我想用一项许多人已熟悉的工作流程,来展示一个增强型日志监视器——将警告信息作为Production中的消息来处理。我们可以通过创建路由规则来实现对告警消息的过滤和路由,并运用预先构建的组件(例如电子邮件适配器等)来发送粒度级别的通知。 如你所知,监视和管理警告信息是确保任何应用程序平稳运行的关键。对诸如HealthShare和IRIS医疗版这样支撑医疗系统运转的一级应用程序和集成引擎来说对告警信息的处理更显得尤为重要。 让我们先来梳理一下InterSystems产品中已经附带的警告信息监视和管理工具: 通过名为Ens.Alert的组件,你可以使用警告处理器(Alert Processor)为Production中的各类接口配置自定义警报。 系统监视器(System Monitor )能显示Production关键性能指标的实时状态。 日志监视管理器(Log Monitor Manager (^MONMGR) utility )程序能根据消息日志(现在InterSystems IRIS上称messages.log,以往称cconsole.log)生成各种严重级别的通知消息,再通过电子邮件将该通知发送给预设好的收件人。 Production监视器(Production Monitor )显示当前正在运行的Production及其接口(输入/输出连接)、队列、活动作业、事件日志、活动图表等的实时状态。 镜像监视器(Mirror Monitor)显示每个镜像及其构件的运行状态、镜像数据库状态以及关键镜像指标(例如日志传入速率)信息。 尽管由我制作的增强型日志监控器与上述这些日志监控器管理器(^MONMGR)非常相似,它的好处在于给用户提供了一个熟悉的界面和对警告信息的精准路由及管理能力——每个写进消息日志(messages.log文件)的告警条目都会被转换成一条Production里的消息,再按路由规则(Ens.Alert)精细过滤出特定的警告。这些警告可以通过Production中的操作(Business Operation)使用邮件和短信等方式发送出去。不仅如此,现在你还可以在Production中的邮件适配器设置来轻松编辑通知的收件人。 例如:日志监控管理器(^MONMGR)已经具备了按照指定的最低严重性级别发出警告的功能,你可以通过设置在发生二级日志事件时自动向系统管理员发出警告。 如果使用我即将介绍的增强型日志监视器,你就能进一步细化过滤,做到不是所有二级事项都发出,而是只在一个实例的发生了镜像故障转移切换(二级事件范畴下的一个具体情况)时才发出警告。在这个例子中,我们假设该系统部署了由镜像实现的高可用/灾备功能,并且包含这个日志监视器Production需要运行在每个镜像成员中的非镜像命名空间中。 使用增强型日志监控器前,请先从OpenExchange下载示例代码。下载的文件为xml格式,可以直接导入。导入时请转到管理门户,并导航至“Interoperability”->“管理”->“部署变化”->“部署”。 现在点选“Open Local Deployment”选项来打开从OpenExchange下载的xml文件,并在加载后单击“部署” 导航到刚刚部署的“Interoperability”(互操作性->列表->Production)。请勿在设定好全局^lasttimestamp(后面再做说明)之前启动Production。你应该能在Production中看到以下三个组件: “测试”服务 这其中包含了我所使用的定制底层代码(JK.MONMGR.CustomService class.)该代码会持续检查message.log文件是否被加入了新的行,再为每个新加的行项目创建Ens.AlertRequest消息并将其发送至Ens.Alert。你可以使用它的适配器设置来设定呼叫间隔——即在消息日志(messages.log文件)中检查新行的频率。为了能让设定值尽量贴近实际频率,你可以选则诸如1或5这样较小的整数。 “Ens.Alert”进程 这是一个名叫“Ens.Alerts”的路由规则,你可以利用它把特定的警告(基于警告文本)从消息日志路由到“EnsLib.EmailAlertOperation”以发送邮件通知。请注意要在条件中包含AlertText的内容(即Document.AlertText [ “”后面双引号内的警告文字)。你还可以创建其他的附加规则,也可以用DTL把警告消息转换为向下游发送的电子邮件模板或其他格式的通知。 “EnsLib.EmailAlertOperation”操作 这是一个预先构建好的出站电子邮件操作(BO),让你能直接发送邮件通知。你可以利用Production配置中的邮件适配器设置来设定要发送电子邮件的地址列表,SMTP服务器/端口以及凭据等。 启动Production前应先设置全局^ lasttimestamp以记录下此工具检查最后一行时的时间戳。你需要按“月/日/年 时:分:秒”的格式进行设置–例如,从终端输入: >> set ^lasttimestamp = “08/28/2020 08:00:00” 现在可以启动这个Production来亲身体会它的功效了!你还可以通过修改示例代码来满足你的特定需求。 如有任何疑问,请在下方留言评论或与我们的销售工程师联系!
公告
Claire Zheng · 一月 7, 2021

Global Masters_ Open Exchange 上每个 ZPM 应用程序的奖励积分

亲爱的社区用户,您好! 您可能知道,您在 Open Exchange 上每发布一个应用程序都会获得 [Global Masters](https://intersystems.influitive.com/) 积分奖励。 最近,我们针对 [ZPM](https://openexchange.intersystems.com/package/ObjectScript-Package-Manager) 应用程序推出了附加积分。 **现在,您的每个 ZPM 应用程序都会为您赢得额外的 400 积分!**积分将自动调整。 立即查看 Global Masters 上的积分和可用奖励! 如果您对 Global Masters 有任何疑问,欢迎在下面的评论中提问。 * * * 关于 Global Masters 的其他信息: 什么是 Global Masters? 从这里开始如何在 InterSystems Global Masters 上获得积分  
文章
Louis Lu · 一月 7, 2021

FAQ 常见问题系列--RHEL V7.2 上的 Caché 进程故障

**RHEL V7.2 上的 Caché 进程故障** InterSystems WRC 处理了几个有关进程错误引发的问题,这些问题可以归因于 Red Hat Linux 最近的一次更新。 RHEL V7.2 (systemd-219-19.el7.x86_64) 中实现的一个新功能可能导致操作系统 IPC(进程间通信)信号量在 非系统用户注销时被解除分配(系统用户,即 UID 编号小于 1000 的用户除外)。 Caché 在内部利用 IPC 信号量来控制 Caché 进程的运行(例如,当尝试唤醒 Caché 进程时)。 这通过“semop”系统服务来实现,如果操作系统意外删除了 Caché 用于进行 IPC 通讯的信号量,则进程可能会出现错误。 如果发生这种情况,在 cconsole.log 中会找到以下证据: “System error while trying to wake-up a process, code = 22”(尝试唤醒进程时系统出错,代码 = 22) 以及在 Caché SYSLOG 中也会记录相应的错误,例如以下典型示例: Err   Process    Date/Time           Mod Line  Routine            Namespace 22    39761      09/29/2016 04:41:27PM 61  359   BF0+1359^Ens.Queue.1 HSBUS 这最终可能导致 Caché 的运行实例处于挂起状态。 以下是 Redhat 提供的一篇文章的链接,文中给出了有关此功能的详细信息以及禁用该功能的方法: [https://access.redhat.com/solutions/2062273](https://access.redhat.com/solutions/2062273 "Follow link")   此问题已在 systemd-219-19.el7_2.4(通过 RHBA-2016-0199 发布 ()中修复。
公告
Claire Zheng · 一月 7, 2021

如何在 InterSystems Global Masters倡导中心获得积分

大家好!InterSystems Global Masters 倡导中心与开发者社区紧密联系并不是秘密。 为开发者社区做出任何贡献都会带来 Global Masters 积分。 所以, 我们准备了一份关于如何在 Global Masters 以最佳方式获得积分的简短指南。 如何在 GLOBAL MASTERS 获得积分 在开发者社区上发布英文帖子 100 第一次在社区评论 回答一个问题 / 发表一个评论(英文) 300 30 第 1 个被标记为“已接受”的回答 1000 之后的每一个“已接收”回答 150 第5/10/25/50个“已接收”回答 4000/8000/20000/40000 翻译一篇文章 50 在 DC 上问第1/5/10/25/50个问题 500/2000 /5000 /15000/30000 在 DC 上发布第1/5/10/25/50个帖子 1500/7500/15000/40000/75000 在 Open Exchange 发布一个应用程序 800 对每一个ZPM应用积分奖励 400 在Open Exchange发布第1/5/10/25个应用程序 1000/10000/25000/75000 帖子浏览量达到750+/2000+/5000+/15000+ 600/2500/7000/20000 在开发者社区阅读一篇帖子 10 看一个视频 20 通过社交媒体分享一次(帖子/视频) 40 发布的第1/2/3/4/5 篇带“最佳实践”标签的文章 1000/3000/7000/10000/15000 在Open Exchange上您的应用第50/100/250/500/1000次下载 2500/5000/7500/12500/25000 对 InterSystems / InterSystems 产品作一次评述 2 000-3 000 邀请成员加入开发者社区 600 为您的OEX应用创建一个video 3000 *仅计算在 Global Masters 倡导中心注册后发布的帖子。 完成挑战,获得徽章并升级:Insider > Advocate > Specialist > Expert > VIP。 您的级别越高,可获得的奖励越有趣! 欢迎点击查看更多有关 Global Masters 的其他信息: 如何加入 InterSystems Global Masters Global Masters 徽章说明 Global Masters 级别说明 Global Masters 计划的变更 如果您尚未加入 InterSystems Global Masters 倡导中心,现在就开始行动吧! 欢迎在本帖评论中提出您的问题。
文章
Claire Zheng · 一月 7, 2021

认识Global Masters 倡导中心,从这里开始!

亲爱的社区用户,您好! 我们诚挚邀请所有社区成员加入InterSystems Global Masters倡导中心,以便了解最新动态,获取对开发者社区)的贡献积分,并获得奖励!请浏览本文并了解如何加入,有哪些福利可以期待! 点击此处:现在加入 ▶️ 什么是 Global Masters? Global Masters 是一个游戏化平台,您可以在其中完成与InterSystems技术相关的挑战(任务),赢取徽章和积分,并用积分兑换各种奖励! 在这里,每周都会发布5-10 个新挑战,公布开发者社区上最有趣的文章、最佳实践、视频、InterSystems 官方新闻、有趣的学习任务。 这是一个获得最新信息的好方法! ▶️ 具体是什么样的? 下面是挑战和奖励的示例: ▶️ 级别、徽章和特权 Global Masters 中有 6 个级别。您的级别越高,可获得的奖品价值和特权就越高。为开发者社区和 Open Exchange 做出贡献,在 Global Masters 保持活跃以达到最高级别!所有级别和徽章的列表将帮助您晋级到更高级别。 ▶️ 如何加入? 从这里开始! 1. 前往globalmasters.intersystems.com,点击“使用 InterSystems 登录名登录”按钮,然后使用您的WRC账号即可加入。 2. 登陆后,找到“自定义你的程序,从这里开始!(Customize your program! START HERE!)”开始挑战。这个初始挑战会解锁每周发布的奖励和新挑战。 不要跳过这个挑战,充分利用这里吧! 点击此处:现在加入 我们在 GM 中心等待所有 InterSystems 开发者的到来! 欢迎您提出任何反馈和想法。请随时与我们联系!InterSystems Global Masters 上见! 😉
文章
Jeff Liu · 一月 7, 2021

InterSystems 容器注册表介绍

我非常高兴地宣布,InterSystems 容器注册表现在可以使用了。 这为客户访问基于容器的版本及预览提供了新的渠道。 所有的社区版镜像都可在公共存储库中找到,且无需登录。 所有完整发布的镜像(IRIS、IRIS for Health、Health Connect、System Alerting and Monitoring、InterSystems Cloud Manager)和实用程序镜像(例如,仲裁器、Web 网关和 PasswordHash)都需要登录令牌,该令牌从 WRC 帐户生成。 WRC 发布网站暂时将继续以 tarball 方式提供已发布镜像。 不过,您现在可以配置 CI/CD 管道以直接从 InterSystems 容器注册表“docker pull”镜像。 可通过 https://containers.intersystems.com 访问该注册表。 有关完整的使用说明,请参阅下文或参阅文档(使用 InterSystems 容器注册表)。如果您遇到任何问题或有任何反馈要分享,请在下面的评论中告知我们,或联系 support@intersystems.com。-------------------------------------------------------------- 使用 InterSystems 容器注册表 本文档列出了 InterSystems 容器注册表 (ICR) 中可用的镜像,并提供了使用说明。该注册表位于 containers.intersystems.com 上。 可以使用 docker pull 命令下载 ICR 中的镜像,例如: docker pull containers.intersystems.com/intersystems/iris-community:2020.3.0.221.0 本文档包含以下部分: 公共像 受限访问镜像 对 ICR 进行身份验证 列出 ICR 清单 公共镜像 以下 ICR 镜像是公开可用的,无需身份验证即可拉取: InterSystems IRIS IntegratedML 2020.3 containers.intersystems.com/intersystems/iris-ml-community:2020.3.0.302.0 Community Edition 2020.3 containers.intersystems.com/intersystems/iris-community:2020.3.0.221.0 2020.3 ARM64 containers.intersystems.com/intersystems/iris-community-arm64:2020.3.0.221.0 InterSystems IRIS for Health IntegratedML 2020.3 containers.intersystems.com/intersystems/irishealth-ml-community:2020.3.0.302.0 Community Edition 2020.3 containers.intersystems.com/intersystems/irishealth-community:2020.3.0.221.0 2020.3 ARM64 containers.intersystems.com/intersystems/irishealth-community-arm64:2020.3.0.221.0 System Alerting and Monitoring 1.0 containers.intersystems.com/intersystems/sam:1.0.0.115 以下 ICR 镜像仅对经过身份验证的用户可用:受限访问镜像 以下 ICR 镜像是公开可用的,无需身份验证即可拉取: Arbiter 2020.1 containers.intersystems.com/intersystems/arbiter:2020.1.0.215.0 2020.2 containers.intersystems.com/intersystems/arbiter:2020.2.0.211.0 2020.3 containers.intersystems.com/intersystems/arbiter:2020.3.0.210.0 Health Connect 2020.1 containers.intersystems.com/intersystems/healthconnect:2020.1.0.215.0 InterSystems Cloud Manager (ICM) 2020.1 containers.intersystems.com/intersystems/icm:2020.1.0.215.0 2020.2 containers.intersystems.com/intersystems/icm:2020.2.0.211.0 2020.3 containers.intersystems.com/intersystems/icm:2020.3.0.221 InterSystems IRIS 2020.1 containers.intersystems.com/intersystems/iris:2020.1.0.215.0 2020.2 containers.intersystems.com/intersystems/iris:2020.2.0.211.0 2020.3 containers.intersystems.com/intersystems/iris:2020.3.0.221.0 2020.1 ARM64 containers.intersystems.com/intersystems/iris-arm64:2020.1.0.215.0 2020.2 ARM64 containers.intersystems.com/intersystems/iris-arm64:2020.2.0.211.0 2020.3 ARM64 containers.intersystems.com/intersystems/iris-arm64:2020.3.0.221.0 2020.3 IntegratedML containers.intersystems.com/intersystems/iris-ml:2020.3.0.302.0 InterSystems IRIS for Health 2020.1 containers.intersystems.com/intersystems/irishealth:2020.1.0.217.1 2020.2 containers.intersystems.com/intersystems/irishealth:2020.2.0.211.0 2020.3 containers.intersystems.com/intersystems/irishealth:2020.3.0.221.0 2020.1 ARM64 containers.intersystems.com/intersystems/irishealth-arm64:2020.1.0.217.1 2020.2 ARM64 containers.intersystems.com/intersystems/irishealth-arm64:2020.2.0.211.0 2020.3 ARM64 containers.intersystems.com/intersystems/irishealth-arm64:2020.3.0.221.0 2020.3 IntegratedML containers.intersystems.com/intersystems/irishealth-ml:2020.3.0.302.0 PasswordHash 1.0 containers.intersystems.com/intersystems/passwordhash:1.0 Web Gateway 2020.2 containers.intersystems.com/intersystems/webgateway:2020.2.0.211.0 2020.3 containers.intersystems.com/intersystems/webgateway:2020.3.0.221.0 要登录至 ICR,请执行以下步骤:对 ICR 进行身份验证 在您的浏览器中加载 https://containers.intersystems.com/,然后使用您的 InterSystems/WRC 凭据登录。 检索您的 Docker 登录令牌或完整的登录命令。 在 Docker 界面(例如,PowerShell 窗口或 Linux 命令行)中,使用提供的凭据对 ICR 进行身份验证。 您可以通过复制并粘贴显示的完整 docker login 命令来执行此操作,例如: docker login -u="bbinstoc" -p="provided_password" containers.intersystems.com 但是,出于安全原因,您可能想要输入命令 docker login container.intersystems.com,然后在 Username 提示符下输入用户名并将密码粘贴到 Password: 提示符下。 注意:如果您登录到另一个 Docker 注册表,则 docker login 命令可能会导致错误;登录到 container.intersystems.com 之前,请先注销其他注册表。 现在,您可以从 ICR 中拉取镜像,例如: docker pull containers.intersystems.com/intersystems/iris:2020.3.0.221.0 列出 ICR 清单 API 可用于列出 Docker 注册表中的镜像和标签。 可用于列出注册表清单的开源第三方实用程序的一个示例是 docker-ls ,其可从 https://github.com/mayflower/docker-ls 获取。 获取此实用程序的方法有几种。 你可以: 下载用于各种平台的预编译 docker-ls 二进制文件。 直接在某些平台上安装该实用程序,例如,在 Linux 系统上使用以下命令进行安装: sudo snap install docker-ls 在 Linux 平台上拉取并运行镜像 carinadigital/docker-ls:latest 以安装该实用程序,例如: docker run --rm carinadigital/docker-ls:latest 安装 docker-ls 后,您可以使用以下命令列出 ICR 中的存储库: docker-ls repositories --registry https://containers.intersystems.com --user username --password password 注意:使用 --interactive-password 选项提示输入密码,不要在命令行中输入密码。 要仅列出公开可用的镜像,请为 -user 和 --password 选项提供空字符串 ("") 作为参数, 例如,以下仅列出了公共 InterSystems IRIS for Health 镜像的标签: docker-ls tags --registry https://containers.intersystems.com --user "" --password "" intersystems/irishealth-community 如果希望看到非公共镜像的完整列表,则无论是否登录 container.intersystems.com,都需要向该实用程序提供用户名和密码。 可访问 https://github.com/mayflower/docker-ls 了解其他示例。
公告
Claire Zheng · 一月 7, 2021

Global Masters 奖励计划:1.5 小时的 InterSystems 专家咨询

亲爱的社区用户,您好! 您知道吗,在 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 上见!🙂
公告
Jeff Liu · 一月 7, 2021

InterSystems IRIS 和 IRIS for Health 2020.4 预览版本已发布!

现在,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。
公告
Claire Zheng · 一月 7, 2021

InterSystems 商业数字服务

亲爱的社区用户,您好! 我们在 Global Masters上推出了商业服务奖励计划,这是一个绝佳的契机,您可以在开发者社区和我们的社交媒体上宣传贵公司的应用、解决方案和服务,甚至为您的 OEX 应用兑换 Google AdWords 推广! $1,000 Google AdWords 推广代金券 兑换此奖励可在 Google Adwords 上推广您的 OEX 应用。我们将设置推广(关键字、描述、受众),并在推广结束后发送报告。 要求:应用程序应该在 InterSystems IRIS数据平台/IRIS医疗版 上工作,或是通过 IRIS 进行管理/开发的工具。 3,000 积分 开发者社区上的“NEWS”宣传块 兑换此奖励可在开发者社区上宣传您的服务、活动或职位空缺。时长:1 周。 显示在网站所有网页的右侧。 我们的设计人员将为您准备一个横幅。 要求:开发服务、活动或职位空缺应该与 InterSystems 技术相关。 1,500 积分 开发者社区上的 Open Exchange 项目推广 兑换此奖励可在开发者社区上推广您的 OEX 项目。1 周之内,所有社区访问者在网站所有网页右侧的“本周应用”板块中都会看到一个横幅,其中包含您的项目的可点击链接。 1,000 积分 InterSystems 支持的网络研讨会 如果您想针对开发者组织一次专业的网络研讨会,以介绍您的解决方案/工具和公司服务,那么请兑换此奖励,我们将帮忙组织。 您将获得:InterSystems 团队将建立一个在线网络研讨会;在 开发者社区和社交媒体上推广该网络研讨会;开发者社区上的登录页面;网络研讨会前演练和会议期间的技术支持。 要求:应用程序应该在 InterSystems IRIS数据平台/IRIS医疗版上工作,或是通过 IRIS 进行管理/开发的工具。 3,000 积分 让您的视频出现在 InterSystems 开发者 YouTube 频道上 您是否有描述InterSystems 数据平台相关的工具、解决方案或经验的YouTube 视频? 通过订购视频加速包提高您的 YouTube 视频流量:在 InterSystems 开发者 YouTube 频道上推广视频。 列入每月的“InterSystems 开发者视频”摘要。 这是一个示例。 在 Global Masters 和 InterSystems 开发者社交媒体上宣传。 1,500 积分 在开发者社区上发布您公司的标签 兑换此奖励可获得您公司在开发者社区上的标签,它也是一种公司描述,一个包含帖子和您的订阅者的区域。 5,000 积分 如果您还不是 Global Masters 会员,如何兑换? ➡️ 我们邀请您加入: 1. 使用您在开发者社区上的相同账密登录Global Masters 。 2. 回答“自定义你的程序。 从这里开始!”挑战中的 4 个问题(您会在挑战中看到)。 3. 您对 OEX 和开发者社区的贡献积分将在 3 天内自动授予。 4. 在奖励目录兑换奖励。 InterSystems 开发者社区每个月的访问量超过 35000 人。让世界了解您在 InterSystems 数据平台上构建的应用、解决方案和服务! 欢迎在下面的评论中提出您的问题。 * * * 有关 Global Masters 的其他信息:认识Global Masters倡导中心,从这里开始
文章
Jeff Liu · 一月 7, 2021

InterSystems 最佳实践系列之--从持久类和序列类生成 Swagger 规范

最近,我需要从持久类和序列类生成一个 Swagger 规范,所以我发布了我的代码(它并不完整 - 你仍然需要处理应用程序的细节,但这是一个开始)。 代码[在这里](https://github.com/eduard93/Utils/blob/master/Utils/YAML.cls.xml)。 假设你有下面的类:   类 Class REST.Test.Person Extends %Persistent { /// 人的名字。 Property Name As %String [ Required ]; /// 人的社会安全号。 这通过模式匹配进行验证。 Property SSN As %String [ Required ]; /// 人的出生日期。 Property DOB As %Date; /// 人的家庭地址。 这里使用一个嵌入对象。 Property Home As Address; /// 人的办公室地址。 这里使用一个嵌入对象。 Property Office As Address; /// 人的配偶。 这是对另一个持久对象的引用。 Property Spouse As Person; /// 代表人喜欢的颜色的字符串集合。 Property FavoriteColors As list Of %String; /// 代表人喜欢的颜色的字符串集合。 Property FavoriteNumbers As array Of %Integer; /// 人的年龄。<br> /// 这是一个经过计算的字段,其值来自于 <property>DOB</property>。 Property Age As %Integer; } Class REST.Test.Address Extends %SerialObject { /// 街道地址。 Property Street As %String(MAXLEN = 80); /// 城市名称。 Property City As %String(MAXLEN = 80); /// 2 个字母的州名缩写。 Property State As %String(MAXLEN = 2); /// 5 位美国 地区改进计划 (ZIP) 编码。 Property Zip As %String(MAXLEN = 5); } 你可以通过以下代码自动生成此 Swagger 定义: REST.Test.Person: type: "object" properties: Age: type: "integer" DOB: type: "string" FavoriteColors: type: "array" items: type: "string" FavoriteNumbers: type: "object" Home: $ref: "#/definitions/REST.Test.Address" Name: type: "string" Office: $ref: "#/definitions/REST.Test.Address" SSN: type: "string" Spouse: $ref: "#/definitions/REST.Test.Person" REST.Test.Address: type: "object" properties: City: type: "string" State: type: "string" Street: type: "string" Zip: type: "string" 主方法:Utils.YAML:GenerateClasses 测试运行:do ##class(Utils.YAML).Test()
文章
Jeff Liu · 一月 7, 2021

精华文章---在 Windows 主机上运行的 Hyper-V Ubuntu 虚拟机中配置 Docker 使用环境

这次我想谈一谈不专门针对 InterSystems IRIS 的东西,不过如果你想使用 Docker,并且你工作环境是安装了 Windows 10 专业版或企业版的 PC 或笔记本电脑,那么我认为这个很重要。 你可能知道,容器技术基本上来自于 Linux 世界,如今在 Linux 主机上发挥出最大潜能。 那些平常使用 Windows 的人会看到,Microsoft 和 Docker 在过去的几年做出了重要的努力,让我们可以在 Windows 系统上以非常简单的方式运行基于 Linux 映像的容器... 但是生产系统不支持这种方式,这是个大问题,如果我们要将持久性数据保留在主机系统中的容器之外,这样做非常不可靠... 这主要是由于 Windows 和 Linux 文件系统之间的巨大差异导致的。 最终,_Docker for Windows 自身使用了一个小型 linux 虚拟机 (_MobiLinux_) 来运行容器... 此操作对于 Windows 用户是透明的,而且效果完美,只要你不需要你的数据库比容器存活的时间更长... 好了,我们进入正题,很多时候为了避免出现问题和简化操作,我们需要一个完整的 Linux 系统,而且如果我们的服务器基于 Windows,那么唯一的方法就是通过虚拟机来实现。 至少在 Windows 中的 WSL2 发布之前是这样,但发布后就是另一回事了,不过它要变得足够强大稳定肯定还需要一些时间。 在本文中,我将一步一步告诉你如何在 Windows 服务器中的 Ubuntu 系统上安装一个能使用 Docker 容器进行工作的环境。 我们开始吧... 1. 启用 Hyper-V 如果尚未启用,则转到添加 `Windows 功能`并启用 Hyper-V。 你将需要重启(图片上的文本是西班牙语,但这就是我当前的区域设置。 如果你不懂堂吉诃德的语言,我希望加上说明能帮助你“解密”😉) ![](/sites/default/files/inline/images/images/image(424).png)   2. 在 Hyper-V 上创建一个 Ubuntu 虚拟机 我认为创建虚拟机 (VM) 没有更简单的方法了。 只需打开 `Hyper-V 管理器`的窗口,然后转到选项快速创建...(屏幕的右上角),使用已经提供的任一 Ubuntu 版本来创建你的虚拟机(你可以下载任何其他 Linux 的 iso 文件,创建不同发行版的虚拟机)。 在我的示例中,我选择了最新的 Ubuntu 版本:19.10。 不过,你在这里看到的一切内容也都适用于 18.04。 在 15 或 20 分钟内,具体取决于你下载映像花费的时间,新的虚拟机就创建完毕并准备就绪。 重要: 保持选项默认交换机 不变。这将保证你可以从主机和虚拟机访问互联网。 ![](/sites/default/files/inline/images/images/vm_ubuntu_network_start_defaultswitch_eth0.jpg) 3. 创建本地子网 使用虚拟机经常遇到的问题之一与网络配置有关... 有时有效,有时无效,或者连接 Wi-Fi 时有效,但连接网线就无效,或者是相反情况;或者如果我在 Windows 主机中建立一个 VPN,那么在虚拟机中就无法访问互联网,或者是虚拟机 (Linux) 和主机 (Windows) 之间的通信中断... 总之,非常让人抓狂! 这使得我在使用笔记本电脑进行开发、小型快速演示或展示时无法信任我的环境,而在这些场景下访问互联网很可能不如确保在主机与虚拟机之间进行可靠通信来得重要。 在 Windows 主机和虚拟机之间共享一个临时本地子网,可以解决这个问题。 要让它们互相通信,使用该子网就可以了。 你只需要为主机和虚拟机分配特定 IP 即可。 通过以下步骤可以很容易实现。 只需转到虚拟交换机管理器...,你可以在 `Hyper-V 管理器`中找到: ![](/sites/default/files/inline/images/images/image(425).png) 然后,转到选项新建虚拟交换机(之后就像虚拟机的新网卡一样): ![](/sites/default/files/inline/images/images/image(461).png) 确保将其定义为_内部网络_,选择我们想要的名称,其他选项保持默认 ![](/sites/default/files/inline/images/images/image(427).png) 现在,如果转到 _`Windows 控制面板 --> 网络和共享中心`_,我们会看到那里已经有了我们刚才创建的交换机: ![](/sites/default/files/inline/images/images/image(429).png)   4. 配置主机和虚拟机共享的本地子网 此时,你可以完成新的本地网络的配置。 为此,将光标放在连接 _Mi Nuevo Conmutador LOCAL_ 上,单击并转到属性,再转到 IPv4 协议,以便分配一个固定 IP 地址: ![](/sites/default/files/inline/images/images/image(449).png)   重要:在此处分配的 IP 将是主机 (Windows) 在该本地子网中的 IP。   5. 将新的本地网络链接并配置到虚拟机 现在回到 `Hyper-V 管理器`。 如果虚拟机正在运行,将其停止。 停止后,转到其配置并添加新的内部虚拟交换机: ![](/sites/default/files/inline/images/images/image(431).png) _(注意:在图片上可以看到另一个交换机 Hyper-V Conmutador INTERNO。 它用于我的另一个子网。 此配置中不需要它)_ 单击“添加”后,你只需选择先前创建的交换机: ![](/sites/default/files/inline/images/images/image(432).png) 好了,完成此操作后,依次单击“应用”、“接受”... 一切就绪!你只需启动并再次登录虚拟机即可完成内部连接的配置。 为此,在虚拟机启动后,单击网络图标(右上角),你将看到两个网络:_eth0_ 和 _eth1_。 _eth1_ 目前显示为断开连接: ![](/sites/default/files/inline/images/images/image(450).png) 进入以太网 (eht1) 的配置,并为此本地子网分配一个固定 IP,例如:_155.100.101.1_,子网掩码:_255.255.255.0_ ![](/sites/default/files/inline/images/images/image(452).png) 这样就完成了。 你的虚拟机标识为 IP 155.100.101.1,与主机共享同一子网。 7. 允许从虚拟机访问 Windows 10 你可能会发现 Windows 10 默认不允许其他服务器连接,对于 Windows 系统来说,你刚刚创建的虚拟机正是一个可能存在危险的外部服务器。因此,必须在防火墙中添加规则,才能从这些虚拟机连接到主机。 如何操作? 非常简单,只需在 `Windows 控制面板`中查找 `Windows Defender 防火墙`,转到高级配置,然后创建一条新的*入站规则*: ![](/sites/default/files/inline/images/images/image(451).png) 你可以设置一个端口或者一个或多个端口范围...(也可以设置针对所有端口的规则)... ![](/sites/default/files/inline/images/images/image(453).png) 我们需要的操作是_允许连接_... ![](/sites/default/files/inline/images/images/image(454).png) 用于_所有网络类型_... ![](/sites/default/files/inline/images/images/image(455).png) 为规则指定名称... ![](/sites/default/files/inline/images/images/image(456).png) **这里很重要**,指定名称后要立即再次打开新创建的规则的属性并*限制应用程序范围*,以便只应用于本地子网内的连接... ![](/sites/default/files/inline/images/images/image(457).png) 8. 就绪。 在新的 Ubuntu 虚拟机中安装 Docker 和任何其他应用程序 完成整个安装过程后,新虚拟机即就绪且为最新,并可以访问互联网等等。 你可以安装所需的应用程序... 至少要安装 Docker,这是一开始就有的想法,如果你需要连接公司网络,还可以安装 VPN 客户端,还有 VS Code、Eclipse+Atelier 等等。 具体来说,要在虚拟机中安装 Docker,可以按照以下说明进行操作: 确保 Docker 运行时正在工作,下载一些测试映像等等... 仅此而已。 这样... _**你已完成所有工作!**_,现在你将能够在 Ubuntu 虚拟机中无限制(除了硬件能力限制)运行容器,你可以从 Windows 10 主机、浏览器或应用程序连接到虚拟机,以及反过来从 Ubuntu 虚拟机连接到 Windows 10 主机。 所有使用你在共享本地子网中设置的 IP 地址的操作都将有效,无论是否建立 VPN,是通过 Wi-fi 适配器还是通过以太网电缆接入互联网。 啊... 最后一个建议。 如果要在 Windows 10 和虚拟机之间交换文件,一个非常有用且简单的选项是使用 [WinSCP](https://winscp.net/eng/download.php)。 它是免费的,而且非常好用。 当然,还有其他配置,但这是我使用的配置,已经证明是比较可靠的。 希望你也觉得它有用。 如果我帮助你避免了令人头疼的问题,这篇文章就值了。 编码愉快!     
文章
Jeff Liu · 一月 7, 2021

使用 GitHub Actions 在 EKS 上部署 InterSystems IRIS 解决方案

假设你想了解 InterSystems 在数据分析方面能提供什么。 你研究了理论,现在想要进行一些实践。 幸运的是,InterSystems 提供了一个项目:Samples BI,其中包含了一些很好的示例。 从 README 文件开始,跳过任何与 Docker 相关的内容,直接进行分步安装。 启动虚拟实例 安装 IRIS,按照说明安装 Samples BI,然后用漂亮的图表和表格让老板眼前一亮。 到目前为止还不错。 但是不可避免地,你需要进行更改。 事实证明,自己保留虚拟机存在一些缺点,交给云服务商保管是更好的选择。 Amazon 看起来很可靠,你只需创建一个 AWS 帐户(入门免费),了解到使用 root 用户身份执行日常任务是有害的,然后创建一个常规的具有管理员权限的 IAM 用户。 点击几下鼠标,就可以创建自己的 VPC 网络、子网和虚拟 EC2 实例,还可以添加安全组来为自己开放 IRIS Web端口 (52773) 和 ssh 端口 (22)。 重复 IRIS 和 Samples BI 的安装。 这次使用 Bash 脚本,如果你喜欢,也可以使用 Python。 再一次让老板刮目相看。 但是无处不在的 DevOps 运动让你开始了解基础架构即代码,并且你想要实现它。 你选择了 Terraform,因为它是众所周知的,而且它的方法非常通用,只需微小调整即可适合各种云提供商。 使用 HCL 语言描述基础架构,并将 IRIS 和 Samples BI 的安装步骤转换到 Ansible。 然后再创建一个 IAM 用户使 Terraform 正常工作。 全部运行一遍。 获得工作奖励。 渐渐地你会得出结论,在我们这个[微服务](https://martinfowler.com/articles/microservices.html)时代,不使用 Docker 就太可惜了,尤其是 InterSystems 还会告诉你[怎么做](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ADOCK_iris)。 返回到 Samples BI 安装指南并阅读关于 Docker 的几行内容,似乎并不复杂: $ docker pull intersystemsdc/iris-community:2019.4.0.383.0-zpm$ docker run --name irisce -d --publish 52773:52773 intersystemsdc/iris-community:2019.4.0.383.0-zpm$ docker exec -it irisce iris session irisUSER>zpmzpm: USER>install samples-bi   将浏览器定向到 http://localhost:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER 后,再次去老板那里,因为做得好而获得一天假期。 然后你开始明白,“docker run”只是开始,至少需要使用 docker-compose。 没问题: $ cat docker-compose.ymlversion: "3.7"services: irisce: container_name: irisce image: intersystemsdc/iris-community:2019.4.0.383.0-zpm ports: - 52773:52773$ docker rm -f irisce # We don’t need the previous container$ docker-compose up -d   这样你使用 Ansible 安装了 Docker 和 docker-compose,然后运行了容器,如果机器上还没有映像,则会下载一个映像。 最后安装了 Samples BI。 你一定喜欢 Docker,因为它是各种内核素材的又酷又简单的接口。 你开始在其他地方使用 Docker,并且经常启动多个容器。 还发现容器必须经常互相通信,这就需要了解如何管理多个容器。 终于,你发现了 Kubernetes。 从 docker-compose 快速切换到 Kubernetes 的一个方法是使用 [kompose](https://kompose.io/)。 我个人更喜欢简单地从手册中复制 Kubernetes 清单,然后自己编辑,但是 kompose 在完成小任务方面做得很好: $ kompose convert -f docker-compose.ymlINFO Kubernetes file "irisce-service.yaml" createdINFO Kubernetes file "irisce-deployment.yaml" created   现在你有了可以发送到某个 Kubernetes 集群的部署和服务文件。 你发现可以安装 minikube,它允许你运行一个单节点 Kubernetes 集群,这正是你现阶段所需要的。 在摆弄一两天 minikube 沙盒之后,你已经准备好在 AWS 云中的某处使用真实的 Kubernetes 部署。   设置 我们一起来进行吧。 此时,我们做以下几个假设: 首先,我们假设你有一个 AWS 帐户,你[知道其 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html),并且未使用 root 凭据。 你创建了一个具有[管理员权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)且只能以编程方式访问的 IAM 用户(我们称之为“my-user”),并存储了其凭据。 你还创建了另一个具有相同权限的 IAM 用户,名为“terraform”: ![](/sites/default/files/inline/images/images/iam_user.png) Terraform 将以它的名义进入你的 AWS 帐户,并创建和删除必要资源。 这两个用户的广泛权限将通过演示来说明。 你在本地保存了这两个 IAM 用户的凭据: $ cat ~/.aws/credentials[terraform]aws_access_key_id = ABCDEFGHIJKLMNOPQRSTaws_secret_access_key = ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123[my-user]aws_access_key_id = TSRQPONMLKJIHGFEDCBAaws_secret_access_key = TSRQPONMLKJIHGFEDCBA01234567890123   注意:不要复制和粘贴上面的凭据。 它们在这里作为示例提供,不再存在。 请编辑 ~/.aws/credentials 文件并引入你自己的记录。 其次,我们将在文中使用虚拟的 AWS 帐户 ID (01234567890) 和 AWS 区域“eu-west-1”。 可以随意使用其他区域。 第三,我们假设你知道 AWS 不是免费的,你需要为使用的资源付费。 接下来,您已经安装了 AWS CLI 实用程序,以便与 AWS 进行命令行通信。 你可以尝试使用 aws2,但你需要在 kube 配置文件中特别设置 aws2 的用法,如这里所述。 你还安装了 kubectl 实用程序来与 AWS Kubernetes 进行命令行通信。 并且你也针对 docker-compose.yml 安装了 kompose 实用程序,来转换 Kubernetes 清单。 最后,你创建了一个空的 GitHub 仓库,并将其克隆到主机上。 我们将其根目录引用为 。 在此仓库中,我们将创建并填充三个目录:.github/workflows/、k8s/ 和 terraform/。 请注意,所有相关代码都在 github-eks-samples-bi 仓库中复制,以简化拷贝和粘贴。 我们继续。   AWS EKS 预置 我们已经在文章使用 Amazon EKS 部署简单的基于 IRIS 的 Web 应用程序中知道了 EKS。 那时,我们以半自动方式创建了一个集群。 即,我们在一个文件中描述集群,然后从本地机器手动启动 eksctl 实用程序,该实用程序根据我们的描述创建集群。 eksctl 是为创建 EKS 集群而开发的,它非常适合概念验证实现,但对于日常使用来说,最好使用更通用的工具,例如 Terraform。 AWS EKS 简介是一个非常好的资源,其中介绍了创建 EKS 集群所需的 Terraform 配置。 花一两个小时熟悉一下,决不会是浪费时间。 你可以在本地操作 Terraform。 为此,你需要一个二进制文件(在撰写本文时,我们使用最新的 Linux 版本 0.12.20),并且 IAM 用户“terraform”需要有足够的权限才能让 Terraform 进入 AWS。 创建目录 /terraform/ 以存储 Terraform 代码: $ mkdir /terraform$ cd /terraform   你可以创建一个或多个 .tf 文件(它们会在启动时合并)。 只需复制并粘贴 AWS EKS 简介中的代码示例,然后运行如下命令: $ export AWS_PROFILE=terraform$ export AWS_REGION=eu-west-1$ terraform init$ terraform plan -out eks.plan   你可能会遇到一些错误。 如果遇到的话,可以在调试模式下操作,但记得稍后关闭该模式: $ export TF_LOG=debug$ terraform plan -out eks.plan$ unset TF_LOG   这个经验会很有用,你很可能会启动一个 EKS 集群(使用“terraform apply”进行该操作)。 在 AWS 控制台中查看: ![](/sites/default/files/inline/images/images/eks.png)   觉得厌烦时就清理掉: $ terraform destroy   然后进入下一阶段,开始使用 Terraform EKS 模块,尤其它也基于同一 EKS 简介。 在 examples/ 目录中,你将看到如何使用它。 你还会在那里找到其他示例。 我们对示例进行了一定的简化。 以下是主文件,其中调用了 VPC 创建和 EKS 创建模块: $ cat /terraform/main.tfterraform {  required_version = ">= 0.12.0"  backend "s3" {    bucket         = "eks-github-actions-terraform"    key            = "terraform-dev.tfstate"    region         = "eu-west-1"    dynamodb_table = "eks-github-actions-terraform-lock"  }} provider "kubernetes" {  host                   = data.aws_eks_cluster.cluster.endpoint  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)  token                  = data.aws_eks_cluster_auth.cluster.token  load_config_file       = false  version                = "1.10.0"} locals {  vpc_name             = "dev-vpc"  vpc_cidr             = "10.42.0.0/16"  private_subnets      = ["10.42.1.0/24", "10.42.2.0/24"]  public_subnets       = ["10.42.11.0/24", "10.42.12.0/24"]  cluster_name         = "dev-cluster"  cluster_version      = "1.14"  worker_group_name    = "worker-group-1"  instance_type        = "t2.medium"  asg_desired_capacity = 1} data "aws_eks_cluster" "cluster" {  name = module.eks.cluster_id} data "aws_eks_cluster_auth" "cluster" {  name = module.eks.cluster_id} data "aws_availability_zones" "available" {} module "vpc" {  source               = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master"   name                 = local.vpc_name  cidr                 = local.vpc_cidr  azs                  = data.aws_availability_zones.available.names  private_subnets      = local.private_subnets  public_subnets       = local.public_subnets  enable_nat_gateway   = true  single_nat_gateway   = true  enable_dns_hostnames = true   tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"  }   public_subnet_tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"    "kubernetes.io/role/elb" = "1"  }   private_subnet_tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"    "kubernetes.io/role/internal-elb" = "1"  }} module "eks" {  source = "git::https://github.com/terraform-aws-modules/terraform-aws-eks?ref=master"  cluster_name     = local.cluster_name  cluster_version  = local.cluster_version  vpc_id           = module.vpc.vpc_id  subnets          = module.vpc.private_subnets  write_kubeconfig = false   worker_groups = [    {      name                 = local.worker_group_name      instance_type        = local.instance_type      asg_desired_capacity = local.asg_desired_capacity    }  ]   map_accounts = var.map_accounts  map_roles    = var.map_roles  map_users    = var.map_users}   我们再仔细看一下 main.tf 中的“_terraform_”块: terraform {  required_version = ">= 0.12.0"  backend "s3" {    bucket         = "eks-github-actions-terraform"    key            = "terraform-dev.tfstate"    region         = "eu-west-1"    dynamodb_table = "eks-github-actions-terraform-lock"  }}   这里需要指出,我们将遵守不低于 Terraform 0.12 的语法(与早期版本相比有了很大变化),同时,Terraform 不应该将其状态存储在本地,而是远程存储在 S3 存储桶中。 不同的人可以从不同的地方更新 terraform 代码确实很方便,这意味着我们需要能够锁定用户的状态,因此我们使用 dynamodb 表添加了一个锁。 有关锁定的更多信息,请参见状态锁定页面。 由于存储桶的名称在整个 AWS 中应该是唯一的,因此你不能再使用名称“eks-github-actions-terraform”。 请想一个你自己的名称,并确保它没有被占用(应该收到 NoSuchBucket 错误): $ aws s3 ls s3://my-bucket调用 ListObjectsV2 操作时发生错误 (AllAccessDisabled):对此对象的所有访问均已禁用$ aws s3 ls s3://my-bucket-with-name-that-impossible-to-remember调用 ListObjectsV2 操作时发生错误 (NoSuchBucket):指定的存储桶不存在   想好一个名称,创建存储桶(我们这里使用 IAM 用户“terraform”。 它拥有管理员权限,因此可以创建存储桶),并为其启用版本管理(这在配置出错时能让你省心): $ aws s3 mb s3://eks-github-actions-terraform --region eu-west-1make_bucket: eks-github-actions-terraform$ aws s3api put-bucket-versioning --bucket eks-github-actions-terraform --versioning-configuration Status=Enabled$ aws s3api get-bucket-versioning --bucket eks-github-actions-terraform{  "Status": "Enabled"}   对于 DynamoDB,不需要唯一性,但你需要先创建一个表: $ aws dynamodb create-table                                                                                     \  --region eu-west-1                                                                                                           \  --table-name eks-github-actions-terraform-lock                                              \  --attribute-definitions AttributeName=LockID,AttributeType=S                \  --key-schema AttributeName=LockID,KeyType=HASH                                   \  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5   ![](/sites/default/files/inline/images/images/dynamodb.png)   注意,如果 Terraform 操作失败,你可能需要从 AWS 控制台手动删除锁。 但这样做时要小心。 对于 main.tf 中的 eks/vpc 模块,引用 GitHub 上提供的模块很简单: git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master   现在看一下另外两个 Terraform 文件(variables.tf 和 outputs.tf)。 第一个文件保存了 Terraform 变量: $ cat /terraform/variables.tfvariable "region" {  default = "eu-west-1"} variable "map_accounts" {  description = "Additional AWS account numbers to add to the aws-auth configmap. See examples/basic/variables.tf for example format."  type        = list(string)  default     = []} variable "map_roles" {  description = "Additional IAM roles to add to the aws-auth configmap."  type = list(object({    rolearn  = string    username = string    groups   = list(string)  }))  default = []} variable "map_users" {  description = "Additional IAM users to add to the aws-auth configmap."  type = list(object({    userarn  = string    username = string    groups   = list(string)  }))  default = [    {      userarn  = "arn:aws:iam::01234567890:user/my-user"      username = "my-user"      groups   = ["system:masters"]    }  ]}   这里最重要的部分是将 IAM 用户“my-user”添加到 map_users 变量中,但你应该使用自己的帐户 ID 替换 01234567890。 这有什么用? 当通过本地 kubectl 客户端与 EKS 通信时,它会向 Kubernetes API 服务器发送请求,每个请求都要经过身份验证和授权过程,这样 Kubernetes 就可以知道谁发送了请求,以及它们可以做什么。 因此 Kubernetes 的 EKS 版本会要求 AWS IAM 帮助进行用户身份验证。 如果发送请求的用户列在 AWS IAM 中(这里我们指向其 ARN),请求将进入授权阶段,该阶段将由 EKS 自己处理,但要依据我们的设置。 这里要指出的是,IAM 用户“my-user”非常酷(组“system: masters”)。 最后,output.tf 文件描述了 Terraform 在完成工作后应该打印的内容: $ cat /terraform/outputs.tfoutput "cluster_endpoint" {  description = "Endpoint for EKS control plane."  value       = module.eks.cluster_endpoint} output "cluster_security_group_id" {  description = "Security group ids attached to the cluster control plane."  value       = module.eks.cluster_security_group_id} output "config_map_aws_auth" {  description = "A kubernetes configuration to authenticate to this EKS cluster."  value       = module.eks.config_map_aws_auth}   Terraform 部分的描述完成。 我们很快就会回来,看看如何启动这些文件。   Kubernetes 清单 到目前为止,我们已经解决了在哪里启动应用程序的问题。 现在我们来看看要运行什么。 回想一下 /k8s/ 目录中的 docker-compose.yml(我们重命名了服务,添加了几个不久就会被 kompose 用到的标签) : $ cat /k8s/docker-compose.ymlversion: "3.7"services:  samples-bi:    container_name: samples-bi    image: intersystemsdc/iris-community:2019.4.0.383.0-zpm    ports:    - 52773:52773    labels:      kompose.service.type: loadbalancer      kompose.image-pull-policy: IfNotPresent   运行 kompose,然后添加下面突出显示的内容。 删除注释(使内容更容易理解): $ kompose convert -f docker-compose.yml --replicas=1$ cat /k8s/samples-bi-deployment.yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  replicas: 1  strategy:    type: Recreate  template:    metadata:      labels:        io.kompose.service: samples-bi    spec:      containers:      - image: intersystemsdc/iris-community:2019.4.0.383.0-zpm        imagePullPolicy: IfNotPresent        name: samples-bi        ports:        - containerPort: 52773        resources: {}        lifecycle:          postStart:            exec:              command:              - /bin/bash              - -c              - |                echo -e "write\nhalt" > test                until iris session iris < test; do sleep 1; done                echo -e "zpm\ninstall samples-bi\nquit\nhalt" > samples_bi_install                iris session iris < samples_bi_install                rm test samples_bi_install        restartPolicy: Always   我们使用 Recreate 更新策略,这意味着先删除 pod,然后重新创建。 这对于演示目的是允许的,让我们可以使用更少的资源。 我们还添加了 postStart 挂钩,该挂钩在 pod 启动后立即触发。 我们等待至 IRIS 启动,然后从默认的 zpm-repository 安装 samples-bi 包。 现在我们添加 Kubernetes 服务(同样没有注释): $ cat /k8s/samples-bi-service.yamlapiVersion: v1kind: Servicemetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  ports:  - name: "52773"    port: 52773    targetPort: 52773  selector:    io.kompose.service: samples-bi  type: LoadBalancer   是的,我们将在“默认”命名空间中部署,该命名空间适合演示。 好了,现在我们知道了运行_位置_和_内容_。 还剩下_方式_需要了解。   GitHub Actions 工作流程 我们不需要每件事都从头开始做,而是创建一个工作流程,类似于[使用 GitHub Actions 在 GKE 上部署 InterSystems IRIS 解决方案](https://community.intersystems.com/post/deploying-intersystems-iris-solution-gke-using-github-actions)中所述的工作流程。 这次,我们不必担心构建容器。 GKE 特定的部分已替换为特定于 EKS。 粗体部分与接收提交消息和在条件步骤中使用它有关: $ cat /.github/workflows/workflow.yamlname: Provision EKS cluster and deploy Samples BI thereon:  push:    branches:    - master # Environment variables.# ${{ secrets }} are taken from GitHub -> Settings -> Secrets# ${{ github.sha }} is the commit hashenv:  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  AWS_REGION: ${{ secrets.AWS_REGION }}  CLUSTER_NAME: dev-cluster  DEPLOYMENT_NAME: samples-bi jobs:  eks-provisioner:    # Inspired by:    ## https://www.terraform.io/docs/github-actions/getting-started.html    ## https://github.com/hashicorp/terraform-github-actions    name: Provision EKS cluster    runs-on: ubuntu-18.04    steps:    - name: Checkout      uses: actions/checkout@v2     - name: Get commit message      run: |        echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})     - name: Show commit message      run: echo $commit_msg     - name: Terraform init      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'init'        tf_actions_working_dir: 'terraform'     - name: Terraform validate      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'validate'        tf_actions_working_dir: 'terraform'     - name: Terraform plan      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'plan'        tf_actions_working_dir: 'terraform'     - name: Terraform plan for destroy      if: "contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'plan'        args: '-destroy -out=./destroy-plan'        tf_actions_working_dir: 'terraform'     - name: Terraform apply      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'apply'        tf_actions_working_dir: 'terraform'     - name: Terraform apply for destroy      if: "contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'apply'        args: './destroy-plan'        tf_actions_working_dir: 'terraform'   kubernetes-deploy:    name: Deploy Kubernetes manifests to EKS    needs:    - eks-provisioner    runs-on: ubuntu-18.04    steps:    - name: Checkout      uses: actions/checkout@v2     - name: Get commit message      run: |        echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})     - name: Show commit message      run: echo $commit_msg     - name: Configure AWS Credentials      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: aws-actions/configure-aws-credentials@v1      with:        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}        aws-region: ${{ secrets.AWS_REGION }}     - name: Apply Kubernetes manifests      if: "!contains(env.commit_msg, '[destroy eks]')"      working-directory: ./k8s/      run: |        aws eks update-kubeconfig --name ${CLUSTER_NAME}        kubectl apply -f samples-bi-service.yaml        kubectl apply -f samples-bi-deployment.yaml        kubectl rollout status deployment/${DEPLOYMENT_NAME}   当然,我们需要设置“terraform”用户的凭据(从 ~/.aws/credentials 文件中获取),让 Github 使用它的机密: ![](/sites/default/files/inline/images/images/secrets.png)   注意工作流程的突出显示部分。 我们可以通过推送包含短语“[destroy eks]”的提交消息来销毁 EKS 集群。 请注意,我们不会使用这样的提交消息来运行“kubernetes apply”。 运行管道,但首先要创建一个 .gitignore 文件: $ cat /.gitignore.DS_Storeterraform/.terraform/terraform/*.planterraform/*.json$ cd $ git add .github/ k8s/ terraform/ .gitignore$ git commit -m "GitHub on EKS"$ git push   在 GitHub 仓库页面的“Actions”选项卡上监视部署过程。 请等待成功完成。 第一次运行工作流程时,“Terraform apply”步骤需要 15 分钟左右,大约与创建集群的时间一样长。 下次启动时(如果未删除集群),工作流程会快很多。 你可以将此签出: $ cd $ git commit -m "Trigger" --allow-empty$ git push   当然,最好检查一下我们做了什么。 这次可以在你的笔记本电脑上使用 IAM“my-user”的凭据: $ export AWS_PROFILE=my-user$ export AWS_REGION=eu-west-1$ aws sts get-caller-identity$ aws eks update-kubeconfig --region=eu-west-1 --name=dev-cluster --alias=dev-cluster$ kubectl config current-contextdev-cluster $ kubectl get nodesNAME                                                                               STATUS   ROLES      AGE          VERSIONip-10-42-1-125.eu-west-1.compute.internal   Ready          6m20s     v1.14.8-eks-b8860f $ kubectl get poNAME                                                       READY        STATUS      RESTARTS   AGEsamples-bi-756dddffdb-zd9nw    1/1               Running    0                      6m16s $ kubectl get svcNAME                   TYPE                        CLUSTER-IP        EXTERNAL-IP                                                                                                                                                         PORT(S)                    AGEkubernetes        ClusterIP               172.20.0.1                                                                                                                                                                                443/TCP                    11msamples-bi         LoadBalancer     172.20.33.235    a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com    52773:31047/TCP  6m33s   访问 _[http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER](http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?%24NAMESPACE=USER) _(将链接替换为你的外部 IP),然后输入“_system”、“SYS”并更改默认密码。 您应该看到一系列 BI 仪表板: ![](/sites/default/files/inline/images/images/deepsee_ui.png)   点击每个仪表板的箭头可以深入了解: ![](/sites/default/files/inline/images/images/deepsee_2.png)   记住,如果重启 samples-bi pod,所有更改都将丢失。 这是有意的行为,因为这是演示。 如果你需要保留更改,我在 github-gke-zpm-registry/k8s/statefulset.tpl 仓库中创建了一个示例。 完成后,删除你创建的所有内容: $ git commit -m "Mr Proper [destroy eks]" --allow-empty$ git push   结论 在本文中,我们将 eksctl 实用程序替换成 Terraform 来创建 EKS 集群。 这是向“编纂”您的所有 AWS 基础架构迈出的一步。 我们展示了如何使用 Github Actions 和 Terraform 通过 git push 轻松部署演示应用程序。 我们还向工具箱中添加了 kompose 和 pod 的 postStart 挂钩。 这次我们没有展示 TLS 启用。 我们将在不久的将来完成这项任务。
文章
Jeff Liu · 一月 7, 2021

精华文章---面向 Google Cloud Platform (GCP) 的 InterSystems IRIS 示例参考架构

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 提供: 临时计算引擎虚拟机实例。 从 web 浏览器通过命令行访问实例。 内置代码编辑器。 5 GB 持久性磁盘存储。 预安装 Google Cloud SDK 和其他工具。 支持 Java、Go、Python、Node.js、PHP、Ruby 和 .NET 语言。 Web 预览功能。 访问 GCP 控制台项目和资源的内置授权。   客户端库 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 实例需要公共 IP 地址才能访问 GCP 服务。 谷歌建议使用防火墙规则来限制这些 VM 实例的传入,尽管这种做法可能会引起一些问题。   如果您的安全策略确实需要内部 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 个主要组件的每一个提供了安全控制、带宽保护和监视方面的灵活性。 有关各种用例的详细信息,可在此处找到。 有关创建具有多个网络接口的虚拟机实例的详细信息,可在此处找到。   这些示例中包含的子网: 用户空间网络用于入站连接用户和查询 分片网络用于分片节点之间的分片间通信 镜像网络通过同步复制和单个数据节点的自动故障转移实现高可用性。   注意:仅在单个 GCP 区域内具有低延迟互连的多个地区之间,才建议进行故障转移同步数据库镜像。 区域之间的延迟通常太高,无法提供积极的用户体验,特别是对于具有高更新率的部署更如此。   ### 内部负载均衡器 大多数 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 布局组合了所有组件,具有以下特点: 利用一个区域内的多个地区实现高可用性 提供两个区域进行灾难恢复 利用多个子网进行网络隔离 包括分别用于互联网和 VPN 连接的单独网关 使用云负载均衡器进行镜像成员的 IP 故障转移   * * * 持久性存储概述 如简介中所述,建议使用 GCP 持久性磁盘,尤其 SSD 持久性磁盘类型。 之所以推荐 SSD 持久性磁盘,是由于其拥有更高的读写 IOPS 速率以及低的延迟,适合于事务性和分析性数据库工作负载。 在某些情况下,可使用本地 SSD,但值得注意的是,本地 SSD 的性能提升会在可用性、耐用性和灵活性方面做出一定的权衡。 可在此处找到本地 SSD 数据持久性方面的详细信息,您可了解何时保存本地 SSD 数据以及何时不保存它们。   LVM 条带化 与其他的云提供商一样,GCP 在每个虚拟机实例的 IOPS、空间容量和设备数量方面都施加了众多存储限制。 有关当前的限制,请查阅 GCP 文档,可在此处找到。 由于这些限制的存在,使用 LVM 条带化实现数据库实例的单个磁盘设备的 IOPS 最大化变得非常必要。 在提供的此示例虚拟机实例中,建议使用以下磁盘布局。 与 SSD 持久性磁盘相关的性能限制可在此处找到。   注意:目前,每个虚拟机实例最多有 16 个持久性磁盘,但 GCP 近期的方案则增至 128 个(测试),这将是令人欣慰的提高。     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 文档。   注意:强烈建议同时为数据库和写入映像日志文件启用异步 IO。 有关在 Linux 上启用的详细信息,请参阅下列社区文章:https://community.intersystems.com/post/lvm-pe-striping-maximize-hyper-converged-storage-throughput   * * * 配置 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。 完全支持传统的 tar-ball 分布式安装和部署方法。 但是,建议使用 ICM,以简化云部署中的配置和管理。   容器监视 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]数据分布在集群中的所有数据节点上,非分片表数据仅物理存储在第一个数据节点上。 这种区分对用户是透明的,唯一可能的例外是,第一个节点的存储消耗可能比其他节点略高,但是由于分片表数据通常会超出非分片表数据至少一个数量级,因此这种差异可以忽略不计。 需要时,可以跨集群重新均衡分片表数据,这通常发生在添加新的数据节点后。 这将在节点之间移动数据的“存储桶”,以实现数据的近似均匀分布。 在逻辑层面,未分片的表数据和所有分片的表数据的并集在任何节点上都可见,因此客户端会看到整个数据集,这与其连接哪个节点无关。 元数据和代码也会在所有数据节点之间共享。 分片集群的基本架构图仅由在集群中看起来统一的数据节点组成。 客户端应用程序可以连接到任何节点,并且可以像在本地一样体验数据。 [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 网站上开发者社区的示例。 请访问 www.community.intersystems.com   第三个选项是 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 不会验证或认可一种备份产品是否优于其他产品。 选择备份管理软件的责任由客户个人决定。   在线备份 对于小型部署,内置在线备份工具也是可行的选择。 该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据,然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 有关在线备份的详细信息,可在此处找到。 在 GCP 中,在线备份完成后,必须将备份输出文件和系统正在使用的所有其他文件复制到该虚拟机实例之外的其他存储位置。 存储桶/对象存储是对其很好的命名。 使用 GCP 存储桶有两种选择。 直接使用 gcloud 脚本 API 来复制和操作新创建的在线备份(和其他非数据库)文件。 有关详细信息可在此处找到。 尽管云存储桶属于对象存储,但将存储桶装载为文件系统,并将其用作类似持久性磁盘的功能足以。 有关装载云存储桶(使用云存储 FUSE )的详细信息,可在此处找到。    
文章
Louis Lu · 一月 7, 2021

采用软件定义数据中心 (SDDC) 和超融合基础架构 (HCI) 解决方案的 InterSystems 客户需要重点关注的事项

本文介绍了 InterSystems 客户围绕 SDDC 和 HCI 解决方案的注意事项。 采用软件定义数据中心 (SDDC) 和超融合基础架构 (HCI) 解决方案的 InterSystems 客户需要重点关注的事项 越来越多的 IT 组织正在探究使用SDDC 和 HCI 解决方案的可行性。 这些解决方案看上去很有吸引力,其市场定位为跨异构数据中心和云基础设施可以使得 IT 管理更容易、投入的成本花费更少。 对于 IT 组织来说,潜在的好处是巨大的,许多 InterSystems 客户正在拥抱 SDDC、HCI 或两者兼有。 如果您正在考虑 SDDC 或 HCI 解决方案,请联系您的销售客户经理或销售工程师,安排与技术架构师的通话。 这对于确保成功非常重要。 这些解决方案具有高度的可配置性,组织可以从许多软件和硬件的组合中自由选择。 我们看到了我们的客户使用各种 SDDC 和 HCI 解决方案,通过这些经验,我们意识到,仔细考虑解决方案配置以避免风险是非常重要。 在某些情况下,有些客户的实施不符合关键事务型数据库系统所需的性能和弹性需求。 这导致了应用性能不佳和意外停机的出现。 如果客户的目标是为关键事务型数据库系统提供高弹性和低延迟的存储能力,则组件的选择和配置需要针对您的情况进行仔细考虑和规划,包括: * 选择适当的组件 * 正确配置这些组件 * 使用适当的操作步骤 SDDC 和 HCI 提供了灵活性和易管理性,它们在操作系统和物理存储层之间的管理程序层内或旁路运行。 这会增加不同程度的开销。 如果配置错误,会从根本上影响磁盘延迟,这对于应用的性能而言是灾难性的。 InterSystems IRIS、Caché 和 Ensemble 的设计注意事项 以下最低要求和设计注意事项列表基于我们对 SDDC 和 HCI 解决方案的内部测试。 请注意,这不是一个参考架构,意味着您的应用需求将根据您的实际情况和性能目标有所更改。 网络 * 每节点拥有两个或更多的 10Gb NIC 接口,专门用于存储流量。 * 本地两台无阻塞速率 10Gb 交换机,实现交换机的弹性连接。 * 当然也可以选择 25、40、50 或 100Gb 而不是 10Gb速率,将其作为对 HCI 的前瞻性投资,以满足特定基准和测量应用程序的要求。 **计算** * 至少一个六节点群集,以便在维护和故障期间提供更高的弹性和可预测的性能。 * 英特尔可扩展 Gold 或 Platinum 处理器或更高版本,2.2Ghz 或更高主频。 * 以每个 CPU 插槽 6 个 DDR4-2666 DIMM 为一组的形式安装 RAM(最少 384GB)。 存储 * 全闪存存储。 这是唯一推荐的存储选项。 InterSystems 强烈建议不要将混合或分层 HCI 存储用于生产工作负载。 * 每个物理节点至少两个磁盘组。 每个磁盘组应支持至少三个大容量驱动器。 * 独占使用写入密集型 12Gbps SAS SSD 或 NVMe SSD。 * 对于具有缓存和容量层的全闪存解决方案,建议将 NVMe 用于缓存层,将写入密集型 12Gbps SAS 用于容量层。 * 对 Linux 虚拟机使用 LVM PE 条带化,从而将 IO 分布在多个磁盘组(请联系 InterSystems 获得指南)。 * 对于 Linux 虚拟机上的所有数据库和写入映像日志 (WIJ) 文件使用异步 IO 及 rtkaio 库。 这样可以绕过文件系统缓存并降低写入延迟(请参见[文档](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls)或与 WRC 联系以获取有关在 Linux 上正确启用异步 IO 的帮助)。 这些最低要求建议已证明可以减轻 SDDC 和 HCI 的开销,但并不确保应用性能。 与任何新技术一样,测试您自己的应用的性能和弹性对于任何成功部署都是至关重要的。 重申一次,如果您正在考虑 SDDC 或 HCI 解决方案,请联系您的销售客户经理或销售工程师,他们会为你安排与技术架构师的通话。这对于确保成功至关重要。
文章
Louis Lu · 一月 7, 2021

创建“虚拟”的SOAP Web 服务

在 Caché 中处理 SOAP 请求时,有时需要通过直接访问(有时是编辑)所发送的 XML(即 SOAP 请求和随后的 SOAP 响应)来调试错误。 如果要调试 Caché Web 服务,使用 SoapUI (https://www.soapui.org/) 之类的工具手动创建和控制 SOAP 请求通常很有用,这样可以很容易地在 Caché Web 服务上看到调整的效果。 但是如果已经有 Web 服务(可能不是 Caché),并且想要调试相关的 Caché Web 客户端该怎么办? 您可能已将 SOAP 响应 XML 保存在文件中(例如 Caché SOAP 日志),您需要一个“虚拟”Web 服务将其发送到 Caché Web 客户端,就像实际的 Web 服务一样操作。 由于我经常在技术支持的过程中需要调试客户的 Caché Web 客户端,我创建了这样一个“虚拟”的Web 服务 – 见下文: Class JSUtil.DummyWebService Extends %CSP.Page { /// Mimic a SOAP Web Service by sending the specified SOAP Response XML. /// Typically this XML will be copied-and-pasted from a SOAP log. Parameter CONTENTTYPE = "text/xml"; /// File containing the SOAP Response XML: Parameter XMLFILENAME = "C:\data\soapresponse.txt"; ClassMethod OnPage() As %Status { set XML="" set stream = ##class(%Stream.FileCharacter).%New() set sc = stream.LinkToFile(..#XMLFILENAME) while 'stream.AtEnd { set XML = XML_stream.Read() } write XML quit $$$OK } } 要使用 JSUtil.DummyWebService 类: 1.将参数 XMLFILENAME 的值更改为包含来自 Web 服务的 SOAP 响应的 XML 的位置。 通常,此文件可内容可通过手动剪切和粘贴 Caché SOAP 日志中的响应 XML 消息来创建。 2.使用 Studio 的“View Web Page”获取此 CSP 页面的 URL,它应显示响应的XML消息内容。 3.将上面的 URL 粘贴到 Caché Web 客户端的 LOCATION 参数中。 现在,当调用 Caché Web 客户端时,它将收到参数 XMLFILENAME 指向的 SOAP 请求 XML。 我已经多次使用这种方法来帮助调试 Caché Web 客户端。 参考以下示例: SOAP 日志的“Web 客户端的输入”中包含以下错误: ERROR #6203: Unexpected Element (完整的 SOAP 日志可在此处找到:[_https://github.com/ISC-schulman/InterSystems/raw/master/soaplog.txt_](https://github.com/ISC-schulman/InterSystems/raw/master/soaplog.txt)) 我们还有 Web 服务的 WSDL ([_https://github.com/ISC-schulman/InterSystems/raw/master/example.wsdl_](https://github.com/ISC-schulman/InterSystems/raw/master/example.wsdl)),但无法访问 Web 服务本身。 (虽然这对于 InterSystems 支持来说很常见,但不可否认,对于客户可能并不常见 – 这只是一个简单的示例,说明如何使用 DummyWebService。) 首先,使用 DummyWebService 重现错误: 1.使用 SOAP 向导从提供的 WSDL 生成 Web 客户端。 所有参数均使用默认值(尽管您可以指定包名称。) 2.查看 SOAP 日志,然后将 Web 服务响应的XML(“Input to Web client”)剪切并粘贴到文件中: OK   3.通过 JSUtil.DummyWebService 中的参数 XMLFILENAME 指向此文件。 4.使用 Studio 的“Display Web Page”查看 DummyWebService – 它应显示步骤 2 中创建的文件内容。 5.将步骤 4 中的 URL 剪切并粘贴到步骤 1 中生成的 Web 客户端的 LOCATION 参数中。 6.调用 Web 客户端,例如  set client = ##class(MyWebService.RequestWSSoapHttpPort).%New()  do client.createAsynchronuosRequest("x") quit 7. 验证(例如通过 SOAP 日志)是否发生相同错误,即“ERROR #6203: Unexpected Element”。   接下来我们解决这个错误。 这里会经历一些过程或反复试验,但同样只是为了说明如何使用 DummyWebService。 1.像之前一样使用 SOAP 向导和提供的 WSDL 生成 Web 客户端 – 指定不同的包名称以防止覆盖第一个 Web 客户端。 另外,参数全部采用默认值,除了一处: 在 SOAP 向导的步骤 3 中选择“对于文档样式的 Web 方法使用未包装的消息格式(Use unwrapped message format for document style web methods)” 2.重复上面的步骤 5 和 6。 3.验证(例如通过 SOAP 日志)Web 客户端错误是否已修正。 _(注意:使用“未包装的消息格式(unwrapped message format)”是解决 Web 客户端问题的常见解决方案 – 有关详细信息,请参见我们的文档中的“使用 SOAP 向导_”。)   **总结** 可以使用 DummyWebService 类将指定的 SOAP 响应(例如,从 SOAP 日志)发送到 Caché Web 客户端,以模拟 Web 服务的响应。