清除过滤器
公告
Claire Zheng · 八月 16, 2023
嗨,开发者,
我们很高兴邀请大家参加新的以 Python 为主题的 InterSystems 在线编程竞赛!
🏆 InterSystems Python 编程大赛🏆
时间: 2023年9月4日至24日(美国东部时间)
奖金池: 14,000 美元
话题
我们邀请您在新的编程竞赛中使用Embedded Python !也欢迎您使用Native API for Python或PEX for Python 开发应用程序。
提交一个开源的应用程序,通过InterSystems IRIS或InterSystems IRIS for Health(医疗版)使用嵌入式Python或原生Python API或Python PEX。
一般要求:
有效应用程序:100%全新的Open Exchange Apps或已有的应用程序(但有显著提升)。所有参赛者/团队提交的应用程序只有经过我们团队的审核之后才会被批准参赛。
该应用程序应在 IRIS Community Edition 或 IRIS for Health Community Edition 上运行。两者都可作为host (Mac, Windows)版从Evaluation Site下载,或者可以按从InterSystems Container Registry或Community Container中提取的容器形式使用: intersystemsdc/iris-community:latest 或 intersystemsdc/irishealth-community:latest 。
该应用需开源并在GitHub上发布。
该应用的README文件应为英文,包含安装步骤,并包含视频demo或/和应用程序如何运行的描述。
一名开发者只允许提交 3 份作品。
奖品
1. 专家提名奖(Experts Nomination)——获奖者由我们特别挑选的专家团选出:
🥇第一名 - 5,000 美元
🥈第二名 - 3,000 美元
🥉第三名 - 1,500 美元
🏅第四名 - 750 美元
🏅第五名 - 500 美元
🌟第 6-10 位 - 100 美元
2. 社区提名奖(Community Nomination)- 获得总票数最多的应用程序:
🥇第一名 - 1,000 美元
🥈第二名 - 750 美元
🥉第三名 - 500 美元
🏅第四名 - 300 美元
🏅第五名 - 200 美元
如果几位参与者获得相同数量的选票,他们都将被视为获胜者,奖金由获胜者分享。
谁可以参加?
任何开发者社区的成员均可参加,InterSystems内部员工除外(InterSystems contractor员工可以参加)。还没有账号?现在来建一个!
👥开发人员可以组队创建协作应用程序。一个团队允许 2 到 5 名开发人员。
请注意,要在您的README文件中标注您的团队成员——社区用户profil
重要截止日期:
🛠 应用程序开发和注册阶段:
2023 年 9 月 4 日(美国东部时间 00:00):比赛开始。
2023 年 9月 17日(美国东部时间 23:59):提交截止日期。
✅ 投票时间:
2023 年 9月 18 日(美国东部时间 00:00):投票开始。
2023 年 9月 24 日(美国东部时间 23:59):投票结束。
注意:在整个参赛期间(开发与投票期间),开发者可持续编辑、提升其应
资源助力
1. 使用 InterSystems IRIS 开发 Python 应用程序:
Learning Path Writing Python Application with InterSystems
Embedded Python Documentation
Native API for Python Documentation
PEX Documentation
2. ObjectScript Package Manager (IPM)初学者:
How to Build, Test and Publish ZPM Package with REST Application for InterSystems IRIS
Package First Development Approach with InterSystems IRIS and ZPM
3. 如何将您的APP提交给大赛:
如何在 Open Exchange 上发布应用程序
如何提交比赛申请
4. 应用示例:
embedded-python-template
interoperability-python
interoperability-python-template
pex-demo
python-examples
django-iris-template
Python Faker
5. 视频:
Introduction to Embedded Python
Embedded Python: Bring the Python Ecosystem to Your ObjectScript App
Embedded Python for ObjectScript Developers: Working with Python and ObjectScript Side-By-Side
Embedded Python with Interoperability
InterSystems IRIS Native Python API in AWS Lambda
需要帮忙?
加入 InterSystems Discord 服务器上的竞赛频道或在本文评论中与我们交谈。
期待您的精彩提交 - 加入我们的编码大赛吧!来赢得胜利!
❗️参加本次比赛即表示您同意此处列出的比赛条款。请在继续之前仔细阅读它们。 ❗️
公告
Michael Lei · 六月 3, 2023
InterSystems 支持的硬件OS平台更新 2023年2季度
我们经常收到有关 InterSystems IRIS 数据平台支持的平台和框架列表最近和即将发生的变化的问题。此更新旨在分享最近的更改以及我们对即将发生的更改的已知的情况,但预测未来是一项棘手的工作,不应将其视为承诺的路线图。
话虽如此,关于更新……
IRIS 生产操作系统和 CPU 架构
红帽企业 Linux
近期变动
RHEL 9.2 和 RHEL 8.8 于 2023 年 5 月发布。Red Hat 计划为这些版本提供 4 年的支持。 InterSystems 计划通过我们称为“次要操作系统版本认证”的新流程对 RHEL 9.2 上的 IRIS 进行额外测试,该流程旨在提供额外的安全性,即次要操作系统更新不会破坏任何明显的内容。
随着 RHEL 9.2 的发布,Red Hat 终止了对 RHEL 9.1 的支持。这与 Red Hat 自 RHEL 8.0 以来一直使用的“奇数/偶数”支持周期一致。
RHEL 8.4 扩展维护将于 2023 年 5 月 31 日结束,这意味着 IRIS 也将在那时停止支持此次要版本。
即将发生的变化
RHEL 9.3 计划在今年晚些时候推出。这将是 Red Hat 的短期支持版本,因此 InterSystems 不会推荐将其用于生产部署。
以前的更新
IRIS 2022.1.2 添加了对RHEL 9.0的支持。 9.0 是一个主要的操作系统版本,将 Linux 内核更新到 5.14,将 OpenSSL 更新到 3.0,将 Python 更新到 3.9
IRIS 2022.2.0 移除了对 RHEL 7.x 的支持。 IRIS 的早期版本仍支持 RHEL 7.9。
进一步阅读: RHEL 发布页面
Ubuntu
近期变动
Ubuntu 22.04.02 LTS 于 2023 年 2 月 22 日发布。InterSystems 目前正在通过我们称为“次要操作系统版本认证”的新流程在 22.04.02 LTS 上对 IRIS 进行额外测试。到目前为止,一切都很好。
即将发生的变化
Ubuntu 的下一次重大更新定于 2024 年 4 月
以前的更新
IRIS 2022.1.1 增加了对Ubuntu 22.04 的支持。 22.04 是一个主要的操作系统版本,将 Linux 内核更新到 5.15,将 OpenSSL 更新到 3.0.2,将 Python 更新到 3.10.6
IRIS 2022.2.0 移除了对 Ubuntu 18.04 的支持。 IRIS 的早期版本仍然支持 Ubuntu 18.04。
IRIS 2022.1.1 及更高版本的容器基于 Ubuntu 22.04。
进一步阅读: Ubuntu 发布页面
SUSE 操作系统
即将发生的变化
SUSE Linux Enterprise Server 15 SP5 目前正在进行公测。我们预计 SUSE 将在第二季度末或第三季度初发布 15 SP5,并在此之后添加对 IRIS 的支持。 SP5 将包括 Linux 内核 5.14.21、OpenSSL 3.0.8 和 Python 3.11
SUSE 对 Linux Enterprise Server 15 SP3 的一般支持于 2022 年 12 月 31 日结束,但扩展的安全支持将持续到 2025 年 12 月。
以前的更新
IRIS 2022.3.0 增加了对SUSE Linux Enterprise Server 15 SP4的支持。 15 SP4 是一个主要的操作系统版本,将 Linux 内核更新到 5.14,将 OpenSSL 更新到 3.0,将 Python 更新到 3.9
延伸阅读: SUSE 生命周期
甲骨文Linux
即将发生的变化
根据他们的历史,Oracle Linux 9 将在 2023 年下半年的某个时候包含 RHEL 9.2。
以前的更新
IRIS 2022.3.0 添加了对Oracle Linux 9的支持。 Oracle Linux 9 是跟踪 RHEL 9 的主要操作系统版本,因此它也将 Linux 内核更新到 5.14,将 OpenSSL 更新到 3.0,将 Python 更新到 3.9
进一步阅读: Oracle Linux 支持政策
微软Windows
即将发生的变化
Windows Server 2012 的扩展支持将于 2023 年 10 月结束。如果您仍在该平台上运行,现在是计划迁移的时候了。 IRIS 2023.2 将不适用于Windows Server 2012。
以前的更新
自 IRIS 2022.1 中添加了 Windows Server 2022 以来,我们未对支持的 Windows 版本列表进行任何更改
进一步阅读: Microsoft 生命周期
AIX
即将发生的变化
InterSystems 正与 IBM 密切合作以增加对 OpenSSL 3.0 的支持。这不会包含在 IRIS 2023.2.0 中,因为 IBM 需要在进一步的 TL 版本中针对该功能。好消息是 IBM 正在寻求为 AIX 7.2 和 7.3 发布 OpenSSL 3.0,而且时间看起来应该与 IRIS 2023.3 保持一致。
以前的更新
自从在 IRIS 2022.1 中添加了 AIX 7.3 并删除了 7.1 以来,我们没有对受支持的 AIX 版本列表进行任何更改
进一步阅读: AIX 生命周期
容器
即将发生的变化
IRIS 容器将只标记年份和版本,例如“2023.2”,而不是我们过去一直使用的完整内部版本号。这样,您的应用程序可以默认获取您发布的最新维护版本。
我们还为最新的扩展维护和持续分发 IRIS 版本添加了“latest-em”和“latest-cd”标签。这些将有利于演示、示例和开发环境。
我们还将开始使用“-preview”标记预览容器,以便清楚哪个容器是最新的 GA 版本。
这些更改都将在 2023.2 GA 版本中生效。我们将在 6 月发布更多相关信息。
以前的更新
我们现在正在发布 IRIS 容器的多架构清单。这意味着拉取标记为2022.3.0.606.0的 IRIS 容器将为您的机器的 CPU 架构(Intel/AMD 或 ARM)下载正确的容器。
IRIS 开发操作系统和 CPU 架构
苹果系统
近期变动
我们在 IRIS 2023.1 中添加了对 MacOS 13 的支持
即将发生的变化
MacOS 14 将很快发布,预计将在今年晚些时候正式发布。
CentOS
我们正在考虑取消对 CentOS/CentOS Stream 的支持。请参阅下面的推理。
Red Hat 几年来一直在运行开发人员计划,该计划使开发人员能够获得非生产环境的免费许可证。鼓励当前使用 CentOS 的开发人员通过此程序切换到 RHEL。
CentOS Stream 现在是 RHEL 的“上游”,这意味着它具有 RHEL 尚未包含的错误和功能。它还每天更新,这可能会给平台上的开发人员带来问题(更不用说我们自己的测试人员了)。
自从我们在 IRIS 2022.1 中添加了对 CentOS 8-Stream 的支持并删除了对 CentOS 7.9 的支持后,我们没有对受支持的 CentOS 版本列表进行任何更改
InterSystems 组件
InterSystems API 管理器 (IAM)
IAM 3.2 于本季度发布,其中包括对容器基础映像的更改,从 Alpine 到 Amazon Linux。
Caché & Ensemble 生产操作系统和 CPU 架构
以前的更新
Cache 2018.1.7 增加了对 Windows 11 的支持
InterSystems 支持的平台文档
InterSystems 支持的平台文档是支持技术的最终列表的来源。
IRIS 2020.1 支持的服务器平台
IRIS 2021.1 支持的服务器平台
IRIS 2022.1 支持的服务器平台
IRIS 2023.1 支持的服务器平台
Caché & Ensemble 2018.1.7 支持的服务器平台
以上就是全部内容。同样,如果您想了解更多信息,请给我们留言。
公告
Jeff Liu · 十月 18, 2023
嘿开发者,
欣赏Bilibili InterSystems 中国上的新视频:
⏯如何在 2023 年全球峰会上定制 InterSystems IRIS for Health FHIR 存储库
InterSystems IRIS for Health 不仅提供世界一流的 FHIR 存储库,还提供灵活性和可扩展性。了解自定义 FHIR 存储库的选项,并了解如何通过几个具体用例来实现它们,例如强制标识符的唯一性和引用完整性。
🗣 演讲者: @Teunis.Stolker,InterSystems 高级销售工程师
享受这个视频并继续关注更多视频! 👍
公告
Claire Zheng · 九月 26, 2023
Hi 开发者们,
是时候公布2023 InterSystems Python 编程大赛的获奖者了!
感谢所有提交15 份申请的出色参与者 🔥
专家提名奖
🥇第一名和 🥈第二名以及各4,000 美元由获得相同专家票数的两个应用程序共享:
iris-vector by @Dmitry Maslennikov
iris-GenLab by @Muhammad Waseem
🥉第三名 1,500 美元 iris-recorder-helper app by @Alexey Nechae
🏅第四名 750 美元 iris-python-machinelearn app by @André Dienes Friedrich
🏅第五名 500 美元 Face Login app by @yurimarx Marx
🌟 100 美元 native-api-command-line-py-client app by @Robert Cempe
🌟 100 美元 IRIS-Cloudproof-Encryption app by @LI XU
🌟 100美元 BardPythonSample app by @xuanyou du
🌟 100 美元 iris-python-lookup-table-utils app by Johannes Heinz
🌟 100 美元 apptools-django app by @Sergey Mikhailenko
开发者社区提名奖
🥇第一名1,000 美元 iris-vector app by @Dmitry Maslennikov
🥈第二名750 美元 iris-python-machinelearn app by @André Dienes Friedrich
🥉第三名500 美元iris-GenLab app by @Muhammad Waseem
🏅第四名 300 美元 BardPythonSample app by @xuanyou du
🏅第五名 200 美元 native-api-py-demo app by @shan yue
我们向所有参赛者和获奖者表示最诚挚的祝贺!
下次再一起享受乐趣吧;)
文章
Lilian Huang · 七月 31, 2023
FHIR® SQL Builder或 Builder 是 InterSystems IRIS 医疗版数据平台 的一个组件。它是一种复杂的投射工具,用于将 InterSystems IRIS 医疗版数据平台FHIR 存储库中的数据创建为自定义的 SQL 模式,而无需将数据移动到单独的 SQL 存储库中。 Builder 专门设计用于与 InterSystems IRIS 医疗版数据平台中的 FHIR 存储库和多模型数据库配合使用。
Builder 的目标是使数据分析师和商业智能开发人员能够使用熟悉的SQL分析工具使用 FHIR,而无需学习新的查询语法。 FHIR 数据以复杂的有向图编码,无法使用标准 SQL 语法进行查询。基于图的查询语言 FHIRPath 旨在查询 FHIR 数据,但它是非关系型的。 Builder 使数据管理员能够使用表、列和索引创建其 FHIR 存储库的自定义 SQL 来投射,使数据分析师能够查询 FHIR 数据,而无需学习 FHIRPath 或 FHIR 搜索语法的复杂性。存储库将加载 FHIR 资源,您所需要做的就是配置 FHIR SQL BUILDER。对于配置,导航到http://localhost:55037/csp/fhirsql/index.csp# /有关如何进行配置的更多详细信息,请观看此教程视频
要查看配置,请导航到http://localhost:55037/csp/fhirsql/index.csp#/spec/1
现在让我们使用irisChatGPT应用程序,使用以下命令连接到终端
docker-compose exec iris iris session iris
创建 dc.irisChatGPT 类的新实例并使用 SetApiKey 方法设置 OpenAI API 密钥
set chat = ##class(dc.irisChatGPT).%New() do chat.SetAPIKey("Enter your Open API Key here")
谢谢
文章
Kelly Huang · 七月 12, 2023
在本文中,我将分享我们在 2023 年全球峰会技术交流室中提出的主题。我和@Rochael.Ribeiro
借此机会,我们就以下话题进行探讨:
用于快速 API 的开放交换工具
开放API规范
传统与快速 Api 开发
复合 API(互操作性)
规范优先或 API 优先方法
API 治理和监控
演示(视频)
用于快速 API 的开放交换工具
当我们谈论快速现代 API 开发(Rest / json)时,我们将使用两个 Intersystems Open Exchange 工具:
第一个是用于快速开发 API 的框架,我们将在本文中详细介绍。
https://openexchange.intersystems.com/package/IRIS-apiPub
第二种是使用 Swagger 作为用户界面,用于 IRIS 平台上开发的 Rest API 的规范和文档,以及它们的使用/执行。其运行的基础是开放 API 规范 (OAS) 标准,如下所述:
https://openexchange.intersystems.com/package/iris-web-swagger-ui
什么是开放 API 规范 (OAS)?
它是全球范围内用于定义、记录和使用 API 的标准。在大多数情况下,API 甚至在实现之前就已经设计好了。我将在下一个主题中详细讨论它。
它很重要,因为它定义并记录了 Rest API 供其在提供者和消费者方面使用。但这种模式也有助于加快市场上工具(Rest API 客户端)的测试和 API 调用,例如 Swagger、Postman、Insomnia 等……
使用 IRIS 发布 API 的传统方式
想象一下,我们必须从现有的 IRIS 方法构建并发布 Rest API(如下图)。
以传统方式:
1:我们必须考虑消费者会如何称呼它。例如:将使用哪个路径和动词以及如何响应。无论是 JSON 对象还是纯文本。
2:在 %CSP.REST 类中构建一个新方法,该方法将处理调用它的 http 请求。
3:处理方法对最终用户预期的 http 响应的响应。
4:考虑一下我们将如何提供成功代码以及我们将如何处理异常。
5:为我们的新方法绘制路线。
6:向最终用户提供API文档。我们可能会手动构建 OAS 内容。
7:例如,如果我们有一个请求或响应有效负载(对象),则实施时间将会增加,因为它也必须记录在 OAS 中。
我们怎样才能更快?
只需使用 [WebMethod] 属性标记 IRIS 方法即可。无论是什么,该框架都会使用 OAS 3.x 标准来处理其发布。
为什么 OAS 3.x 标准如此重要?
因为它还详细记录了输入和输出有效负载的所有属性。
这样,市场上的任何 Rest Client 工具都可以立即耦合到 API,例如 Insomnia、Postman、Swagger 等,并提供示例内容以便轻松调用它们。
使用 Swagger,我们已经可以可视化我们的 API(上图)并调用它。这对于测试也非常有用。
API定制
但是如果我需要自定义 API 该怎么办?
例如:我希望路径是其他东西,而不是方法的名称。我希望输入参数位于路径中,而不是像查询参数那样。
我们在方法之上定义了一个特定的符号,我们可以在其中补充方法本身不提供的元信息。
在此示例中,我们为 API 定义了另一条路径,并补充了信息,以便最终用户获得更友好的体验。
Rest API 的投影图
该框架支持多种类型的参数。
在此图中,我们可以突出显示复杂类型(对象)。它们将自动公开为 JSON 有效负载,并且每个属性都将为最终用户正确记录 (OAS)。
互操作性(复合 API)
通过支持复杂类型,您还可以公开互操作性服务。
这是构建复合 API 的有利场景,复合 API 使用多个外部组件(出站)的编排。
这意味着用作请求或响应的对象或消息将自动发布并由 swagger 等工具读取。
这是测试互操作性组件的绝佳方法,因为通常已经加载了有效负载模板,以便用户知道 API 使用哪些属性。
首先,开发人员可以专注于测试,然后通过定制来塑造 Api。
规范优先或 API 优先方法
当今广泛使用的另一个概念是在实现之前就定义 API。
有了这个框架,就可以导入 Open Api 规范。它自动创建方法结构(规范),只缺少它们的实现。
API 治理和监控
对于Api的治理,也建议一起使用IAM。
除了拥有多个插件之外,IAM 还可以通过 OAS 标准快速耦合到 API。
apiPub 为 API 提供额外的跟踪(参见演示视频)
演示
下载和文档
Intersystems 开放交换: https://openexchange.intersystems.com/?search=apiPub
完整文档:https: //github.com/devecchijr/apiPub
@Claudio Devecchi 致敬原创作者
文章
Johnny Wang · 十二月 19, 2021
如果您经常阅读我们的博客,您可能记得去年夏天我们进行了 InterSystems 速度测试,该测试由 ESG 验证,旨在测试数据库可以同时摄取和查询的数据量,以及这表现出的具体的影响。从那以后,我们 GitHub 页面的许多访问者一直在根据自己的想法重复验证这个测试
最初,第一次数据库速度测试将 InterSystems IRIS 数据平台与来自许多不同云和数据管理供应商的流行数据库进行了比较。令人兴奋的是,我们现在可以宣布,我们已经将数据库性能测试从 SAP HANA、AWS Aurora MySQL、SAP Sybase ASE 和 AWS RDS SQL Server 扩展到包括 PostgreSQL、MariaDB 和 Oracle Enterprise,所有这些都跑在 Amazon Web Services (AWS )上面。
我们为什么要做这一次开源速度测试?
通过模拟不支持任何特定产品的多工作负载用例,速度测试往往充当了另一种数据库性能测试工具,可以根据测试结果来确定哪个数据库或数据平台最适合业务需求来做出决策。随着许多公司继续进行数字化转型并探索传统技术的替代品,这种能力被证明是至关重要的。
数据库速度测试最大的特点就是您可以轻松地在云端或您的机器上自己体验它,并且由于我们已将测试作为可定制的开源代码发布,它可以扩展到您自己的数据和查询。
许多人将其视为微服务的首选平台,开源速度测试现在也可在 Kubernetes 上运行,以响应该应用程序在 InterSystems 开发人员社区中越来越受欢迎的现状。这意味着除了能够使用 AWS 和 Amazon Elastic Kubernetes Service (EKS) 之外,开发人员还可以了解 InterSystems IRIS 如何在 Kubernetes 集群上执行并利用 InterSystems Kubernetes Operator。
InterSystems IRIS 如何与竞争对手抗衡?
数据库速度测试着眼于同步摄取和查询性能的特定用例,这是医疗、金融、供应链和制造等许多行业实时用例的基本要求。
最新速度测试的结果发现,与 AWS MariaDB 相比,InterSystems IRIS 在测试期间摄取的记录多 620.9%,到最后摄取它们的速度提高了 717.3%。将 InterSystems IRIS 与在公共云上运行的 Sybase ASE 的性能进行比较发现,InterSystems IRIS 在测试期间摄取的记录多 4862.8%,在测试结束时摄取记录的速度提高了 6733.4%。
对于任何希望对其基础架构进行现代化改造以提高实时和接近实时的数据库性能的公司,这些指标都极为重要。此外,对于那些在 SAP Sybase ASE 上运行生产应用程序的公司,InterSystems 对 Transact-SQL 的本机支持允许这些应用程序的无缝迁移,通常不需要重写自定义代码。
不要只相信我们的话,请访问我们的 GitHub 页面,亲自对 InterSystems IRIS 进行测试,或在此处了解有关速度测试如何工作的更多信息。
阅读更多关于 Amir Samary 的 InterSystems IRIS 数据平台速度测试的博客文章
阅读更多关于去年夏天我们进行的 InterSystems 速度测试
关于作者:Amir Samary
Amir Samary 已在数据库、互操作性和 InterSystems 技术方面工作了 20 多年。 Amir 致力于为使用 InterSystems 技术为阿根廷、巴西、智利、哥伦比亚、乌拉圭和美国的各个行业构建解决方案的合作伙伴、客户和开发人员提供支持。 这使 Amir 能够理解和试验不同技术、文化和基础设施现实中的模式和架构。 Amir Samary 目前担任解决方案架构经理,他领导 InterSystems 的一组解决方案开发人员。 他主修计算机科学,辅修数学。
查看原文 阅读更多关于 Amir Samary 的 InterSystems IRIS 数据平台速度测试的博客文章
阅读更多关于去年夏天我们进行的 InterSystems 速度测试
这两个还有文中的其他链接可以换成中文链接(如果有)吗?谢谢! 关于:阅读更多关于去年夏天我们进行的 InterSystems 速度测试,请查看链接:https://cn.community.intersystems.com/post/%E6%B4%9E%E5%AF%9F%E6%96%B0%E7%9A%84-intersystems-%E9%80%9F%E5%BA%A6%E6%B5%8B%E8%AF%95
谢谢! 直接在原文里改吧
文章
Jeff Liu · 三月 15, 2021
大家好, 现在是九局下半,但在我们的技术世界大赛还留了几手 iris-analytics-package 旨在演示各公司可以如何轻松简单地在其软件中利用 InterSystems Analytics 支持。
无论是创建新的简单解决方案,还是使用 OpenExchange 改进现有解决方案。
大多数升级到 InterSystems IRIS 的公司都在利用该工具提供的所有功能;他们了解前沿技术,处于领先地位。
我们在本次竞赛中的方案有着不同的目标,即那些已使用 InterSystems 很长时间,但仍然未挖掘到其全部潜能的公司。
此项目是以其他项目为基础和灵感来创建的。 感谢 @Evgeny.Shvarov @Guillaume.Rongier7183 @Peter.Steiwer * [DeepSeeWeb](https://openexchange.intersystems.com/package/DeepSeeWeb)
* [csvgen](https://openexchange.intersystems.com/package/csvgen)
* [csvgen-ui](https://openexchange.intersystems.com/package/csvgen-ui)
* [AnalyzeThis](https://openexchange.intersystems.com/package/AnalyzeThis) 这些项目一起成就了这个简单的向导。### 导入向导
主页面看起来很简单,涉及的过程也很直接。 正确使用向导需要填写几个字段:
1. 选择 CSV 文件
2. 分隔符
3. 类名称
4. 选择是否要创建多维数据集
5. 多维数据集名称
6. 选择向导是否应创建仪表板示例
为了使创建的内容可视化,我们使用 DeepSeeWeb 来实现。
### 点击上传按钮后,gif 可能看起来定住了,但原因是记录太多。 选定的 CSV 文件超过 **15Mb**, 导入 **134100 条记录**!![]顺便说一下,此演示的数据集来自人道主义数据交换 - 一站式查找、分享和使用人道主义数据您可以尝试使用同一数据集;CSV 文件位于以下文件夹
iris-analytics-package/data
如果您喜欢这个应用程序,并认为我们值得您投票,请为 **iris-analytics-package** 投上一票! [https://openexchange.intersystems.com/contest/current](http://If%20you%20liked%20the%20app%20and%20think%20I%20deserve%20your%20vote,%20please%20vote%20for%20npm-iris!%20%20laugh%20https://openexchange.intersystems.com/contest/current)
文章
Tete Zhang · 一月 29, 2023
消息查看器可以重新发送消息,但不适合重新发送大量消息(>100)。为此,您应该使用如下的Object Script代码:
Class Sample.Resender Extends %RegisteredObject{ClassMethod Resend(){//Resend all messages sent from 'FromComponent' to 'ToComponent' between 2016-06-15 and 2016-06-20&sql(DECLARE C1 CURSOR FOR SELECT ID INTO :id FROM Ens.MessageHeader WHERE SourceConfigName='FromComponent' AND TargetConfigName='ToComponent' AND TimeCreated BETWEEN '2016-06-15' AND '2016-06-20')&sql(OPEN C1)&sql(FETCH C1)set tSC = $$$OKwhile (SQLCODE = 0) {//id holds the id for one message. Resend itset tSC = ##class(Ens.MessageHeader).ResendDuplicatedMessage(id)quit:$$$ISERR(tSC)&sql(FETCH C1)}&sql(CLOSE C1)quit tSC}}
您还可以向其中添加代码,例如不同的消息筛选条件、更好的错误检查逻辑、在出现问题时从重发列表中断处重新启动的代码等。
以下是嵌入式 SQL 和 Ens.MessageHeader 方法 ResendDuplicatedMessage 的文档:
http://docs.intersystems.com/ens20161/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_esql#GSQL_esql_cursor
http://docs.intersystems.com/ens20152/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=ENSLIB&CLASSNAME=Ens.MessageHeader#METHOD_ResendDuplicatedMessage
公告
Claire Zheng · 十月 20, 2022
2022年9月5日-10月24日(北京时间),我们正在举办🏆InterSystems开发者社区中文版首届技术征文大赛🏆(←点击链接进入参赛页面,浏览所有参赛文章)!投票截止至10月23日,你的支持与喜爱,是优秀作品获得“开发者社区奖”的关键!我们先来看看目前作品排名情况吧!距离投票截止还有三天(截止至10月23日),我们暂时无法获得专家评审分数,以下根据作品“点赞”进行排名(排名截至10月21日10时)。
N
Author
标题
点赞⬇
1
Meng Cao
Caché数据库私有apache版本升级
42
2
Zhe Wang
IRIS如何进行CRUD操作
37
3
sun yao
前端操作自动生成BS、BP、BO
26
4
John Pan
论集成标准的选择对医院信息集成平台建设的影响
23
5
lizw lizw
关于%Dictionary.CompiledClass类在实际业务中的一些应用
23
6
聆严 周
使用Prometheus监控Cache集群
21
7
Chang Liu
在国产系统上安装Healthconnect2021
19
8
Zhe Wang
IRIS快速查询服务思路分享
18
9
Zhe Wang
使用Global进行数据可视化---商业智能(BI)
18
10
John Pan
如何调用Ensemble/IRIS内置的HL7 V2 webservice - Java,PB9,Delphi7样例
17
11
zhanglianzhu zhanglianzhu
Cache死循环检测和申明式事务
16
12
Zhe Wang
Rest实现Post、Get、Put、Delete几种操作方式
15
13
shaosheng shengshao
HEALTHSHARE2018版如何实现AES(CBC)的HEX输出,并可以实现加密和解密
15
14
姚 鑫
IRIS与Caché的23种设计模式
15
15
water huang
对 %XML.PropertyParameters类的探索
15
16
Zhe Wang
小工具:IRIS管理页打开显示查询功能
15
17
聆严 周
Cache / IRIS 操作数据的3种基本方式
14
18
he hf
10分钟快速开发一个连接到InterSystems IRIS数据库的C#应用
14
19
shaosheng shengshao
windows下处理IIS在未安装但Healthshare已安装的时候,部署IIS服务并代理Healthshare
11
20
water huang
Ens.Util.JSON类的启发
11
21
bai hongtao
第三方HA软件结合MIRROR使用方法探讨
11
22
li wang
HealthConnect访问HTTPS开头地址
10
23
Liu Tangh
在Cache系统中使用负载均衡服务的探讨
9
24
yaoguai wan
IRIS架构的浅显理解以及windows10、docker安装IRIS Health详解流程及部分问题浅析
7
25
li dong
实现Cache/IRIS中zip文件的下载、解压及读取
7
26
姚 鑫
CORS请求Request携带Cookie失败占用License解决方案
5
27
Zhe Wang
COS的基本语法
5
*奖励项目详见参赛规则:点击阅读
我们此次征文大赛计分规则如下:
🥇【专家提名奖】评选规则,由经验丰富的专家评审团进行评选打分,与其他加分项综合后进行排名。
🥇【开发者社区奖】评选规则,每个点赞计分为1分,与其他加分项综合后进行排名。
🥇【入围奖】评选规则,成功参赛的其余用户都将获得特别奖励。
每位作者只可以获得一个奖项(即:您只可以获得一次专家提名奖/开发者社区奖/入围奖);
当出现票数相当的平手情况时,将以专家评选投票数作为最终票数高低的判断标准。
那么,抓住最后五天的投票时间,为你喜欢的作品“点赞”投票吧!你的点赞是优秀作品获得【开发者社区奖】的关键!
10月24日晚19:30-20:30,我们将举办“InterSystems首届技术征文大赛线上分享会”,发布获奖名单,敬请留意后续参会信息!
欢迎关注InterSystems开发者社区中文版首届技术征文大赛
文章
姚 鑫 · 二月 5, 2022
# 第四十五章 SQL函数 DATEPART
日期/时间函数,返回表示日期/时间表达式指定部分的值的整数。
# 大纲
```
DATEPART(datepart,date-expression)
```
# 参数
- `datepart` - 要返回的日期/时间信息的类型。日期或时间部分的名称(或缩写)。这个名称可以用大写或小写来指定,有或没有引号。`datepart`可以指定为文字或主机变量。
- `date-expression` - 从中返回`datepart`值的日期、时间或时间戳表达式。日期表达式必须包含`datepart`类型的值。
# 描述
`DATEPORT`函数以整数数据类型返回关于指定日期/时间表达式的`DATEPORT`信息。唯一的例外是`sqltimestamp` (sts),它以数据类型`%Library.Timestamp`返回。要以字符串形式返回日期部分信息,请使用`DATENAME`。
`DATEPART`只返回日期表达式中一个元素的值;要返回包含多个日期部分的字符串,请使用`TO_DATE`。
也可以使用`DATEPART()`方法调用从ObjectScript调用此函数:
```sql
$SYSTEM.SQL.Functions.DATEPART(datepart,date-expression)
```
提供`DATEPART`是为了与Sybase和Microsoft SQL Server兼容。
# Datepart 参数
日期部分参数可以是下列日期/时间组件之一,可以是全名(日期部分列)或其缩写(缩写列)。这些`datepart`组件名称和缩写不区分大小写。
Date Part| Abbreviations| Return Values
---|---|---
year| yyyy, yy |0001-9999
quarter| qq, q| 1-4
month| mm, m| 1-12
week| wk, ww| 1-53
weekday |dw| 1-7 (Sunday,...,Saturday)
dayofyear| dy, y| 1-366
day |dd, d| 1-31
hour| hh| 0-23
minute |mi, n| 0-59
second| ss, s| 0-59
millisecond |ms |0-999 (with precision of 3)
microsecond| mcs |0–999999 (with precision of 6)
nanosecond |ns |0–999999999 (with precision of 9)
sqltimestamp |sts| SQL_TIMESTAMP: yyyy-mm-dd hh:mm:ss
上表显示了不同日期部分的默认返回值。可以使用带有各种时间和日期选项的“设置选项”命令来修改其中几个日期部分的返回值。
`week`:可以配置为使用默认算法或ISO 8601标准算法来确定给定日期的一年中的星期。
`weekday`:对`weekday`的默认设置是将星期日指定为一周的第一天(`weekday=1`)。但是,可以将一周的第一天配置为另一个值,或者可以应用ISO 8601标准,将星期一指定为一周的第一天。请注意,ObjectScript `$ZDATE`和`$ZDATETIME`函数计算的周天数是从0到6(而不是从1到7)。
`second`:如果日期表达式包含小数秒,将秒作为十进制数返回,整数秒作为整数部分,小数秒作为小数部分。精度不会被截断。
`millisecond`:返回三个小数位数的精度,去掉尾随零。如果日期表达式的精度超过三位数会将其截断为三位数。
`sqltimestamp`: 将输入数据转换为时间戳格式,并在必要时为时间元素提供零值。`sqltimestamp`(缩写为sts) `datepart`值仅用于`datepart`。不要试图在其他上下文中使用此值。
`datepart`可以指定为带引号的字符串,不带引号,或者在带引号的字符串周围加上括号。无论如何指定,都不会对`datepart`执行文字替换;对日期表达式执行文字替换。所有datepart值都返回一个数据类型`INTEGER`值,但`sqltimestamp`(或sts)除外,它以数据类型`timestamp`的字符串形式返回其值。
# 日期输入格式
日期表达式参数可以采用以下任何格式:
- %Date logical value (+$H)
- %PosixTime (%Library.PosixTime) logical value (an encoded 64-bit signed integer)
- %TimeStamp (%Library.TimeStamp) logical value (YYYY-MM-DD HH:MM:SS.FFF), also known as ODBC format.
- IRIS %String (or compatible) value
%String(或兼容)值可以是以下任何格式:
- 99999,99999 ($H format)
- Sybase/SQL-Server-date Sybase/SQL-Server-time
- Sybase/SQL-Server-time Sybase/SQL-Server-date
- Sybase/SQL-Server-date (default time is 00:00:00)
- Sybase/SQL-Server-time (default date is 01/01/1900)
Sybase/SQL-Server-date是这五种格式之一:
```
mmdelimiterdddelimiter[yy]yy dd Mmm[mm][,][yy]yy dd [yy]yy Mmm[mm] yyyy Mmm[mm] dd yyyy [dd] Mmm[mm]
```
其中分隔符是斜杠(`/`)、连字符(`-`)或句点(`.`)).
Sybase/SQL服务器时间代表这三种格式之一:
```
HH:MM[:SS:SSS][{AM|PM}] HH:MM[:SS.S] HH['']{AM|PM}
```
如果日期表达式指定了时间格式,但没有指定日期格式,则`DATENAME`默认为日期`1900–01–01`,该日期的工作日值为2(星期一)。
对于`sqltimestamp`,时间以24小时制返回。分数秒被截断。
# 无效的参数错误代码
如果指定无效的`datepart`选项,`DATEPART`将生成一个`SQLCODE -8`错误代码,并且以下`%msg: 'badopt' is not a recognized DATEPART option`.
如果指定了无效的日期表达式值(例如,字母文本字符串),`DATEPART`将生成`SQLCODE -400`错误代码和以下 `%msg: Invalid input to DATEPART() function: DATEPART('year','badval')`。如果指定的日期表达式未通过验证(如下所述),`datepart`将生成一个`SQLCODE -400`错误代码,并显示以下`%msg: Unexpected error occurred: datepart`.
# 范围和值检查
`DATEPART`对日期表达式值执行以下检查。如果值未通过检查,则返回空字符串。
- 有效的日期表达式可以由日期字符串(`yyyy-mm-dd`)、时间字符串(`hh:mm:ss`)或日期和时间字符串(`yyy-mm-dd hh:mm:ss`)组成。如果同时指定了日期和时间,则两者都必须有效。例如,如果未指定时间字符串,则可以返回年份值,但是如果指定了无效的时间字符串,则不能返回年份值。
- 日期字符串必须完整且格式正确,每个元素都有适当数量的元素和数字,以及适当的分隔符。例如,如果省略了“日”值,则不能返回“年”值。年份必须指定为四位数。
- 时间字符串必须用适当的分隔符正确格式化。因为时间值可以为零,所以可以省略一个或多个时间元素(保留或省略分隔符),这些元素将以零值返回。因此,`' hh:mm:ss '`,`' hh:mm '`,`' hh:mm '`,`' hh:ss '`,`' hh:'`,和`':::'`都是有效的。要省略`Hour`元素,日期表达式不能包含字符串的日期部分,并且必须至少保留一个分隔符(`:`)。
- 日期和时间值必须在有效范围内。年份:`0001`到`9999`。月份:`1`到`12`。天数:`1`到`31`天。小时:`0`到`23`。分钟:`0`到`59`。秒:`0`到`59`。
- 一个月中的天数必须与月和年相匹配。例如,日期`“02–29”`仅在指定年份为闰年时有效。
- 大多数小于`10`的日期和时间值可能包含或省略前导零。但是,如果小时值是日期时间字符串的一部分,则小于`10`的小时值必须包含前导零。不允许其他非规范整数值。因此,`“07”`或`“7”`的“日”值有效,但`“007”`、`“7.0”`或`“7a”`无效。
- 如果日期表达式指定了时间格式,但没有指定日期格式,则`DATEPART`不会对时间分量值执行范围验证。
# 示例
在下面的示例中,每个`DATEPART`将日期时间字符串的年份部分(在本例中为`2018`年)作为整数返回。请注意,日期表达式可以有多种格式,`datepart`可以指定为`datepart`名称或`datepart`缩写,带引号或不带引号:
```sql
SELECT DATEPART('yy','2018-02-22 12:00:00') AS YearDTS,
DATEPART('year','2018-02-22') AS YearDS,
DATEPART(YYYY,'02/22/2018') AS YearD,
DATEPART(YEAR,64701) AS YearHD,
DATEPART('Year','64701,23456') AS YearHDT
2018 2018 2018 2018 2018
```
以下示例基于`$HOROLOG`值返回当前年份和季度:
```sql
SELECT DATEPART('yyyy',$HOROLOG) AS Year,DATEPART('q',$HOROLOG) AS Quarter
2022 1
```
下面的嵌入式SQL示例使用主机变量来提供`DATEPART`参数值:
```sql
SET x="year"
SET datein="2018-02-22"
&sql(SELECT DATEPART(:x,:datein)
INTO :partout)
WRITE "the ",x," is ",partout
```
下面的示例返回`Sample.Person`表的出生日期(按星期几排序):
```sql
SELECT Name,DOB,DATEPART('weekday',DOB) AS bday
FROM Sample.Person
ORDER BY bday,DOB
```
在以下示例中,每个`DATEPART`返回20作为日期表达式字符串的分钟部分:
```sql
SELECT DATEPART('mi','2018-2-20 12:20:07') AS Minutes,
DATEPART('n','2018-02-20 10:20:') AS Minutes,
DATEPART(MINUTE,'2018-02-20 10:20') AS Minutes
20 20 20
```
在下面的示例中,每个`DATEPART`返回0作为日期表达式字符串的秒部分:
```sql
SELECT DATEPART('ss','2018-02-20 03:20:') AS Seconds,
DATEPART('S','2018-02-20 03:20') AS Seconds,
DATEPART('Second','2018-02-20') AS Seconds
0 0 0
```
以下示例以`TIMESTAMP`数据类型返回完整的SQL `TIMESTAMP`。`DATEPART`填充缺失的时间信息以返回时间戳`‘2018-02-25 00:00:00’`:
```sql
SELECT DATEPART(sqltimestamp,'2/25/2018') AS DTStamp
2018/2/25 0:00:00
```
以下示例以`$HOROLOG`格式提供日期和时间,并返回时间戳`‘2018-02-22 06:30:56’`:
```sql
SELECT DATEPART(sqltimestamp,'64701,23456') AS DTStamp
2018/2/22 6:30:56
```
下面的示例使用带有`DATEPART`的子查询来返回生日为闰年日(2月29日)的那些人:
```sql
SELECT Name,DOB
FROM (SELECT Name,DOB,DATEPART('dd',DOB) AS DayNum,DATEPART('mm',DOB) AS Month FROM Sample.Person)
WHERE Month=2 AND DayNum=29
```
文章
Jeff Liu · 一月 7, 2021
假设你想了解 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”:

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 控制台中查看:

觉得厌烦时就清理掉:
$ 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

注意,如果 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 使用它的机密:

注意工作流程的突出显示部分。 我们可以通过推送包含短语“[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 仪表板:

点击每个仪表板的箭头可以深入了解:

记住,如果重启 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 启用。 我们将在不久的将来完成这项任务。
文章
Li Yan · 一月 11, 2021
Amazon Web Services (AWS) 云提供广泛的云基础设施服务,例如计算资源、存储选项和网络,这些都非常实用:按需提供,几秒内就可用,采用即付即用定价的模式。 新服务可得到快速配置,且前期无需支出大量资金。 这使得大企业、初创公司、中小型企业以及公共部门的客户可以访问他们所需的基础设施,从而快速响应不断变化的业务需求。
更新日期:2019 年 10 月 15 日
以下概述和详细信息由 Amazon 提供,并可以在此处找到。
概述
AWS 全球基础设施
AWS 云基础设施围绕区域和可用性地区 (AZ) 构建。 区域就是地球上的物理位置,我们拥有多个 AZ。 AZ 由一个或多个离散的数据中心组成,每个数据中心都拥有冗余电源、网络和连接,并安置在单独的设施中。 这些 AZ 可让您能够以比在单个数据中心更高的可用性、容错能力和可伸缩性运行生产应用程序和数据库。
有关 AWS 全球基础设施的详细信息,可在此处找到。AWS 安全性和合规性
云端的安全性与您本地数据中心的安全性非常相似,只是没有维护设施和硬件的成本。 在云端,您无需管理物理服务器或存储设备。 相反,您使用基于软件的安全工具来监控和保护进出云资源的信息流。
AWS 云实现了共享责任模型。 虽然 AWS 管理云的安全性,但您负责云中的安全性。 这意味着您保留了对您选择实施的安全性的控制,以保护您自己的内容、平台、应用程序、系统和网络,与您在现场数据中心中的做法没有区别。
有关 AWS 云安全的详细信息,可在此处找到。
AWS 为其客户提供的 IT 基础设施是按照最佳安全实践和各种 IT 安全标准进行设计和管理的。有关 AWS 遵守的保证计划的完整列表,可在此处找到。
AWS 云平台
AWS 由多种云服务组成,您可以根据您的业务或组织需求进行组合使用。 以下小节按类别介绍了 InterSystems IRIS 部署中常用的主要 AWS 服务。 还有许多其他服务也可能对您的具体应用有着潜在用途。 请务必根据需要加以研究。
要访问这些服务,您可以使用 AWS 管理控制台、命令行界面或软件开发套件 (SDK)。
AWS 云平台
组件
详细信息
AWS 管理控制台
有关 AWS 管理控制台的详细信息,可在此处找到。
AWS 命令行界面
有关 AWS 命令行界面 (CLI) 的详细信息,可在此处找到。
AWS 软件开发套件 (SDK)
有关 AWS 软件开发套件 (SDK) 的详细信息,可在此处找到。
AWS 计算
有许多选项可供选择: 有关 Amazon Elastic Cloud Computing (EC2) 的详细信息,可在此处找到 有关 Amazon EC2 Container Service (ECS) 的详细信息,可在此处找到 有关 Amazon EC2 Container Registry (ECR) 的详细信息,可在此处找到 有关 Amazon Auto Scaling 的详细信息,可在此处找到
AWS 存储
有许多选项可供选择: 有关 Amazon Elastic Block Store (EBS) 的详细信息,可在此处找到 有关 Amazon Simple Storage Service (S3) 的详细信息,可在此处找到 有关 Amazon Elastic File System (EFS) 的详细信息,可在此处找到
AWS 网络
有许多选项可供选择: 有关 Amazon Virtual Private Cloud (VPC) 的详细信息,可在此处找到 有关 Amazon Elastic IP Addresses 的详细信息,可在此处找到 有关 Amazon Elastic Network Interfaces 的详细信息,可在此处找到 有关 Amazon Enhanced Networking for Linux 的详细信息,可在此处找到 有关 Amazon Elastic Load Balancing (ELB) 的详细信息,可在此处找到 有关 Amazon Route 53 的详细信息,可在此处找到
InterSystems IRIS 示例架构
本文部分内容阐述了面向 AWS 的 InterSystems IRIS 部署示例,旨在为特定应用程序的部署抛砖引玉。这些示例可用作很多部署方案的指南。此参考架构拥有非常强大的部署选项,从最小规模的部署,到满足计算和数据需求的大规模可伸缩工作负载,不一而足。
本文介绍了高可用性和灾难恢复选项以及其他建议的系统操作。个体可对这些进行相应的修改以支持其组织的标准实践和安全策略。
针对您的特定应用,就基于 AWS 的 InterSystems IRIS 部署,您可联系 InterSystems 进一步探讨。示例参考架构
以下示例架构按照容量和功能逐步升级的顺序讲述了几种不同的配置,分别为小型开发/生产/大型生产/分片集群生产。先从中小型配置讲起,然后讲述具有跨地区高可用性以及多区域灾难恢复的大规模可缩放性解决方案。此外,还讲述了一个将 InterSystems IRIS 数据平台的新的分片功能用于大规模处理并行 SQL 查询的混合工作负载的示例。
小型开发配置
在本示例中,显示了一个能支持 10 名开发人员和 100GB 数据的小型开发环境,这基本是最小规模的配置。只要适当地更改虚拟机实例类型并增加 EBS 卷存储,即可轻松支持更多的开发人员和数据。
这足以支持开发工作,并让您熟悉 InterSystems IRIS 功能以及 Docker 容器的构建和编排(如果需要的话)。小型配置通常不采用具有高度可用性的数据库镜像,但是如果需要高可用性,则可随时添加。
小型配置示例图
示例图 2.1.1-a 显示了图表 2.1.1-b 中的资源。其中包含的网关只是示例,可做相应地调整以适应您组织的标准网络实践。
图 2.1.1-a:小型开发架构示例
下列 AWS VPC 资源是针对最小规模的配置提供的。可根据需求添加或删除 AWS 资源。
小型配置 AWS 资源
下表提供了小型配置 AWS 资源的示例。
图 2.1.1-b:小型配置 AWS 资源表示例
需要考虑适当的网络安全和防火墙规则,以防止对 VPC 的不必要访问。Amazon 提供网络安全最佳做法供您入门使用,可在此处找到:
https://docs.aws.amazon.com/vpc/index.html#lang/en_us
https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html#best-practices
注意:VM 实例需要公共 IP 地址才能访问 AWS 服务。 AWS 建议使用防火墙规则来限制传入到这些 VM 实例的流量,尽管这种做法可能会引起一些问题。
如果您的安全策略确实需要内部 VM 实例,则您需要在网络上手动设置 NAT 代理和相应的路由,以便内部实例可以访问互联网。 务必要明确,您无法使用 SSH 直接完全连接到内部 VM 实例。 要连接到此类内部机器,必须设置具有外部 IP 地址的堡垒机实例,然后通过它建立隧道。 可以配置堡垒主机,以提供进入 VPC 的外部入口点。
有关使用堡垒主机的详细信息,可在此处找到:
https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/
https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html
生产配置
在本示例中,展示了一个规模较大的生产配置,其采用 InterSystems IRIS 数据库镜像功能来支持高可用性和灾难恢复。
此配置包括 一对InterSystems IRIS 数据库服务器同步镜像,该镜像服务器在区域 1 内分为两个可用性地区,用于自动故障转移,在区域 2 内的第三个 DR 异步镜像成员用于灾难恢复,以防万一整个 AWS 区域宕机。
有关采用多 VPC 连接的多区域的详细信息,可在此处找到。
InterSystems Arbiter 和 ICM 服务器部署在单独的第三个地区,以提高弹性。 此示例架构还包括一组可选的负载均衡 web 服务器,用于支持启用 Web 的应用程序。这些使用 InterSystems 网关的 Web 服务器可以根据需要进行缩放。
生产配置示例图
示例图 2.2.1-a 显示了图表 2.2.1-b 中的资源。 其中包含的网关只是示例,可做相应地调整以适应您组织的标准网络实践。
图 2.2.1-a:具有高可用性和灾难恢复的生产架构示例
建议将以下 AWS VPC 资源作为支持 Web 应用程序生产工作负载的最低配置。可根据需求添加或删除 AWS 资源。
生产配置 AWS 资源
下表提供了生产配置 AWS 资源的示例。 .png)
图 2.2.1-b:生产配置 AWS 资源表(续)
大型生产配置
在本示例中,提供了一个大规模可伸缩性配置。该配置通过扩展 InterSystems IRIS 功能也引入使用 InterSystems 企业缓存协议 (ECP) 的应用程序服务器,实现对用户的大规模横向伸缩。本示例甚至包含了更高级别的可用性,因为即使在数据库实例发生故障转移的情况下,ECP 客户端也会保留会话细节。多个 AWS 可用性地区与基于 ECP 的应用程序服务器和部署在多个区域中的数据库镜像成员一起使用。此配置能够支持每秒数千万次的数据库访问和数万亿字节数据。
生产配置示例图
示例图 2.3.1-a 显示了图表 2.3.1-b 中的资源。 其中包含的网关只是示例,可做相应地调整以适应您组织的标准网络实践。
此配置中包括一对故障转移镜像,四个或更多的 ECP 客户端(应用程序服务器),以及每个应用程序服务器对应一个或多个 Web 服务器。 故障转移数据库镜像对在同一区域中的两个不同 AWS 可用性地区之间进行划分,以提供故障域保护,而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中,以提高弹性。
灾难恢复扩展至第二个 AWS 区域和可用性地区,与上一示例中的情况类似。如果需要,可以将多个 DR 区域与多个 DR 异步镜像成员目标一起使用。
图 2.3.1-a:采用 ECP 应用程序服务器的大型生产架构示例
建议将以下 AWS VPC 项目中的资源作为分片集群部署的最低配置。可根据需求添加或删除 AWS 资源。
大型生产配置 AWS 资源
下表提供了大型生产配置 AWS 资源的示例。
图 2.3.1-b:具有 ECP 应用程序服务器 AWS 资源的大型配置表
图 2.3.1-b:具有 ECP 应用程序服务器 AWS 资源的大型配置表(续)
图 2.3.1-b:具有 ECP 应用程序服务器 AWS 资源的大型配置表(续)
* * *
采用 InterSystems IRIS 分片集群的生产配置
在此示例中,提供了一个针对 SQL 混合工作负载的横向伸缩性配置,其包含 InterSystems IRIS 新的分片集群功能,可实现 SQL 查询和数据表的跨多个系统的大规模横向伸缩。本文的第 9 节将详细讨论 InterSystems IRIS 分片集群及其功能。
采用分片集群的生产配置示例图
示例图 2.4.1-a 显示了图表 2.4.1-b 中的资源。 其中包含的网关只是示例,可做相应地调整以适应您组织的标准网络实践。
此配置中包括四对镜像,它们为数据节点。每对故障转移数据库镜像在同一区域中的两个不同 AWS 可用性地区之间进行划分,以提供故障域保护,而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中,以提高弹性。
此配置允许从集群中的任何数据节点使用所有的数据库访问方法。大型 SQL 表数据在物理上跨所有数据节点进行分区,以实现查询处理和数据卷的大规模并行。将所有这些功能组合在一起,就可以支持复杂的混合工作负载,比如大规模分析 SQL 查询及插入的新数据,所有这一切均在一个 InterSystems IRIS 数据平台中执行。
图 2.4.1-a:具有高可用性的采用分片集群的生产配置示例
注意,上面图表中以及下表“资源类型”列中的术语“EC2”是一个表示 AWS 虚拟服务器实例的 AWS 术语,将在本文的 3.1节中做进一步介绍。 它并不表示或暗示第 9 章所描述的集群架构中对“计算节点”的使用。
建议将以下 AWS VPC 中的资源作为分片集群部署的最低配置。可根据需求添加或删除 AWS 资源。
采用分片集群 AWS 资源的生产配置
下表提供了采用分片集群 AWS 资源的生产配置的示例。
图 2.4.1-b:采用分片集群 AWS 资源的生产配置示例表
* * *
云概念简介
Amazon Web Services (AWS) 为基础设施即服务 (IaaS) 提供功能丰富的云环境,使其具备完备的功能,支持所有的 InterSystems 产品,包括支持基于容器的 DevOps 及最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样,必须留心以确保考虑到环境的各个方面,例如性能、可用性、系统操作、高可用性、灾难恢复、安全控制和其他管理程序。本文档将介绍所有云部署涉及的三个主要组件:计算、存储和网络。
计算引擎(虚拟机)
AWS EC2 中存在数个针对计算引擎资源的选项,以及众多虚拟 CPU 和内存规范及相关存储选项。在 AWS EC2 中值得注意的一点是,对给定机器类型中 vCPU 数量的引用等于一个 vCPU,其是虚拟机监控程序层上物理主机中的一个超线程。
就本文档的目的而言,将使用 m5* 和 r5* EC2 实例类型,这些实例类型在大多数 AWS 部署区域中广泛可用。但是,对于在缓存内保留了大量数据的超大型工作数据集而言,使用 x1 *(拥有大内存)或 i3 *(具有 NVMe 本地实例存储)等其他专门的实例类型才是最佳的选择。 有关 AWS 服务水平协议 (SLA) 的详细信息,可在此处找到。
磁盘存储
与 InterSystems 产品最直接相关的存储类型是持久性磁盘类型,但是,如果了解并适应数据可用性限制,本地存储可以用于高水平的性能。 还有其他一些选项,例如 S3(存储桶)和 Elastic File Store (EFS),但是这些选项更特定于个别应用程序的需求,而非支持 InterSystems IRIS 数据平台的操作。
与大多数其他云提供商一样,AWS 对可与单个计算引擎关联的持久性存储的量施加了限制。这些限制包括每个磁盘的最大容量、关联到每个计算引擎的持久性磁盘的数量,以及每个持久性磁盘的 IOPS 数量,对单个计算引擎实例 IOPS 设置上限。此外,对每 GB 磁盘空间设有 IOPS 限制,因此有时需要调配更多磁盘容量才能达到所需的 IOPS 速率。
这些限制可能会随着时间而改变,可在适当时与 AWS 确认。
磁盘卷有三种类型的持久性存储类型:EBS gp2(SSD)、EBS st1(HDD)和 EBS io1(SSD)。标准 EBS gp2 磁盘更适合于那些要求可预测性低延迟 IOPS 和高吞吐量的生产工作负载。标准持久性磁盘对于非生产开发和测试或归档类型的工作负载,是一种更经济的选择。
有关各种磁盘类型及限制的详细信息,可在此处找到。
VPC 网络
强烈建议采用虚拟私有云 (VPC) 网络来支持 InterSystems IRIS 数据平台的各个组件,同时提供正确的网络安全控制、各种网关、路由、内部 IP 地址分配、网络接口隔离和访问控制。本文档中提供了一个详细的 VPC 示例。
有关 VPC 网络和防火墙的详细信息,可在此处找到。
* * *
虚拟私有云 (VPC) 概述
此处提供有关 AWS VPC 的详细信息。
在大多数大型云部署中,采用多个 VPC 将各种网关类型与以应用为中心的 VPC 进行隔离,并利用 VPC 对等进行入站和出站通信。 有关适合您的公司使用的子网和任何组织防火墙规则的详细信息,强烈建议您咨询您的网络管理员。本文档不阐述 VPC 对等方面的内容。
在本文档提供的示例中,使用 3 个子网的单一 VPC 用于提供各种组件的网络隔离,以应对各种 InterSystems IRIS 组件的可预测延迟和带宽以及安全性隔离。
网络网关和子网定义
本文档的示例中提供了两种网关,以支持互联网和安全 VPN 连接。要求每个入口访问都具有适当的防火墙和路由规则,从而为应用程序提供足够的安全性。有关如何使用 VPC 路由表的详细信息,可在此处找到。
提供的示例架构中使用了 3 个子网,它们与 InterSystems IRIS 数据平台一起使用。这些单独的网络子网和网络接口的使用为上述 3 个主要组件的每一个提供了安全控制、带宽保护和监视方面的灵活性。有关创建具有多个网络接口的虚拟机实例的详细信息,可在此处找到。
这些示例中包含的子网:
用户空间网络用于入站连接用户和查询
分片网络用于分片节点之间的分片间通信
镜像网络通过同步复制和单个数据节点的自动故障转移实现高可用性。
注意:仅在单个 AWS 区域内具有低延迟互连的多个地区之间,才建议进行故障转移同步数据库镜像。 区域之间的延迟通常太高,无法提供良好的用户体验,特别是对于具有高更新率的部署更如此。
内部负载均衡器
大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力,这种地址通常用在自动化数据库故障转移设计中。 为了解决这一问题,InterSystems IRIS 中增强了几种最常用的连接方法,尤其是 ECP 客户端和 Web 网关,从而不再依赖 VIP 功能使它们实现镜像感知和自动化。
xDBC、直接 TCP/IP 套接字等连接方法,或其他的直接连接协议,均需要使用类 VIP 地址。为了支持这些入站协议,InterSystems 数据库镜像技术使用称作<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span>的健康检查状态页面为 AWS 中的这些连接方法提供自动化故障转移,以与负载均衡器进行交互,实现负载均衡器的类 VIP 功能,仅将流量重定向至活动的主镜像成员,从而在 AWS 内实现完整且强大的高可用性设计。
有关 AWS Elastic 负载均衡器 (ELB) 的详细信息,可在此处找到。
图 4.2-a:无虚拟 IP 地址的自动故障转移
此处提供了使用负载均衡器实现类 VIP 功能的详细信息。
示例 VPC 拓扑
下图 4.3-a 中的 VPC 布局组合了所有组件,具有以下特点:
利用一个区域内的多个地区实现高可用性
提供两个区域进行灾难恢复
利用多个子网进行网络隔离
包括分别用于 VPC 对等、互联网和 VPN 连接的单独网关
使用云负载均衡器进行镜像成员的 IP 故障转移
请注意,在 AWS 中,每个子网必须完全位于一个可用性地区内,并且不能跨越地区。 因此,在下面的示例中,需要正确定义网络安全性或路由规则。 有关 AWS VPC 子网的详细信息,可在此处找到。
图 4.3-a:VPC 网络拓扑示例
* * *
持久性存储概述
如简介中所述,建议使用 AWS Elastic Block Store(EBS)卷,尤其是 EBS gp2 卷类型。之所以推荐 EBS gp2 卷,是由于其拥有更高的读写 IOPS 速率以及低的延迟,适合于事务性和分析性数据库工作负载。在某些情况下,可使用本地 SSD,但值得注意的是,本地 SSD 的性能提升会在可用性、耐用性和灵活性方面做出一定的权衡。
可在此处找到本地 SSD 数据持久性方面的详细信息,您可了解何时保存本地 SSD 数据以及何时不保存它们。
LVM PE 条带化
与其他的云提供商一样,AWS 在 IOPS、空间容量和每个虚拟机实例的设备数量方面都施加了众多存储限制。有关当前的限制,请查阅 AWS 文档,可在此处找到。
由于这些限制的存在,使用 LVM 条带化实现数据库实例的单个磁盘设备的 IOPS 最大化变得非常必要。在提供的此示例虚拟机实例中,建议使用以下磁盘布局。与 SSD 持久性磁盘相关的性能限制可在此处找到。
注意:尽管 AWS 资源功能经常更改,但每个 Linux EC2 实例当前最多有 40 个 EBS 卷,因此请查阅 AWS 文档以了解当前限制。
图 5.1-a:LVM 卷组分配示例
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
示例: <span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span>
步骤 4:创建逻辑卷
lvcreate n -L -i -I 4MB
示例: <i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i>
步骤 5:创建文件系统
mkfs.xfs K
示例: <i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i>
步骤 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 个备用日志磁盘。
图 5.1-b:InterSystems IRIS LVM 配置
为了增长,LVM 允许在需要的情况下不中断地扩展设备和逻辑卷。有关持续管理和扩展 LVM 卷的最佳做法,请查阅 Linux 文档。
注意:强烈建议同时为数据库和写入映像日志文件启用异步 IO。 请参阅社区文章获取在 Linux 上启用的详细信息。
* * *
配置
InterSystems IRIS 新增了 InterSystems Cloud Manager (ICM)。ICM 执行众多任务,并提供许多用于配置 InterSystems IRIS 数据平台的选项。 ICM 作为 Docker 映像提供,其拥有配置强大的、基于 AWS 云的解决方案所需的一切。
ICM 当前支持以下平台上的配置:
Amazon Web Services,包括 GovCloud (AWS / GovCloud)
Google Cloud Platform (GCP)
Microsoft Azure Resource Manager,包括 Government (ARM / MAG)
VMware vSphere (ESXi)
ICM 和 Docker 可以从台式机/笔记本电脑工作站运行,也可以具有中央专用的适度“配置”服务器和中央存储库。
ICM 在应用程序生命周期中的作用是“定义->配置->部署->管理”
有关安装和使用 ICM 及 Docker 的详细信息,可在此处找到。
注意:任何云部署都非必须使用 ICM。完全支持传统的 tar-ball 分布式安装和部署方法。但是,建议使用 ICM,以简化云部署中的配置和管理。
容器监视
I针对基于容器的部署,CM 包括两个基本的监视工具: Rancher 和 Weave Scope。 默认情况下不会部署这两个工具,需要在默认的文件中使用监视器字段指定。有关使用 ICM 进行监视、编排和调度的详细信息,可在此处找到。
有关 Rancher 的概述和相关文档,可在此处找到。
有关 Weave Scope 的概述和相关文档,可在此处找到。
* * *
高可用性
InterSystems 数据库镜像可在任何云环境中提供最高级别的可用性。AWS 不会为单个 EC2 实例提供任何可用性保证,因此数据库镜像是必需的,其还要与负载均衡和自动伸缩组结合使用。
前面的部分讨论了云负载均衡器如何通过数据库镜像为虚拟 IP(类 VIP)功能提供自动 IP 地址故障转移。云负载均衡器使用前面内部负载均衡器部分中提到的 mirror_status.cxw 健康检查状态页面。数据库镜像有两种模式——自动故障转移同步镜像、异步镜像。在本示例中,将介绍同步故障转移镜像。有关镜像的详细信息,可在此处找到。
最基本的镜像配置是仲裁器控制配置中的一对故障转移镜像成员。仲裁器放置在同一区域内的第三个地区中,以防止潜在的地区可用性中断影响仲裁器和其中一个镜像成员。
在网络配置中,有多种方法专供设置镜像。在本示例中,我们将使用本文档前述网络网关和子网定义部分中定义的网络子网。下一部分内容将提供 IP 地址方案示例,并且基于本部分内容,将仅描述网络接口和指定的子网。
图 7-a:采用仲裁器的镜像配置示例
* * *
灾难恢复
InterSystems 数据库镜像将支持灾难恢复的高可用性功能扩展到另一个 AWS 地理区域,以在整个 AWS 区域万一宕机的情况下支持操作弹性。应用程序如何忍受此类中断取决于恢复时间目标 (RTO) 和恢复点目标 (RPO)。这些将为设计适当的灾难恢复计划进行的分析提供初始框架。以下链接中的指南提供了您在为自己的应用程序制定灾难恢复计划时要考虑的事项。 https://aws.amazon.com/disaster-recovery/
以下链接中的指南提供了您在为自己的应用制定灾难恢复计划时要考虑的事项。
异步数据库镜像
InterSystems IRIS 数据平台的数据库镜像提供强大的功能,可在 AWS 可用性地区和区域之间异步复制数据,以帮助支持您的灾难恢复计划的 RTO 和 RPO 目标。有关异步镜像成员的详细信息,可在此处找到。
与上述高可用性部分中讲述的内容相似,云负载均衡器也使用上文内部负载均衡器部分中提到过的 mirror_status.cxw 健康检查状态页面为虚拟 IP(类 VIP)功能提供自动化 IP 地址故障转移,以进行 DR 异步镜像。
在本示例中,将介绍 DR 异步故障转移镜像,并介绍 AWS Route53 DNS 服务,以便为上游系统和客户端工作站提供单个 DNS 地址,而不管您的 InterSystems IRIS 部署是否在哪个可用性区域或地区中运行。
有关 AWS Route53 的详细信息,可在此处找到。
图 8.1-a:采用 AWS Route53 的 DR 异步镜像示例
在上述示例中,两个区域的 Elastic 的负载均衡器 (ELB) (前端 InterSystems IRIS 实例)的 IP 地址都提供给了 Route53,它会将流量仅定向到承担主要镜像的镜像成员,而不论其位于哪个可用性地区或区域。
* * *
分片集群
InterSystems IRIS 包括一套全面的功能来伸缩您的应用程序,根据您的工作负载的性质以及所面临的特定挑战,可单独或者组合应用这些功能。 分片功能是这些功能中的一种,可跨多个服务器对数据及其关联的缓存进行分区,从而为查询和数据引入提供灵活、高性价比的性能扩展,同时通过高效的资源利用最大化基础设施的价值。 InterSystems IRIS 分片集群可以为各种应用提供显著的性能优势,尤其对于工作负载包括以下一项或多项的应用更是如此:
大容量或高速数据写入,或两者的组合。
相对较大的数据集、返回大量数据的查询,或两者的组合。
执行大量数据处理的复杂查询,例如扫描磁盘上大量数据或涉及大量计算工作的查询。
这些场景的使用都是分片集群的潜在优势,但组合的应用场景可能会最大化分片集群的优势起来使用它们可能会增加优势。 例如,这 3 个场景的组合——快速引入大量数据、大型数据集、检索和处理大量数据的复杂查询——使得当今的许多分析性工作负载非常适合进行分片。
注意,这些特征都与数据有关;InterSystems IRIS 分片的主要功能是缩放数据量。 不过,当涉及某些或所有这些与数据相关的场景的工作负载也经历大量用户的超高查询量时,分片群集也能提供用户量伸缩功能。 分片也可以与纵向伸缩相结合。
操作概述
分片架构的核心是跨多个系统对数据及其关联的缓存进行分区。 分片集群跨多个 InterSystems IRIS 实例(称为数据节点)以行方式对大型数据库表进行物理上的横向分区,同时允许应用通过任何节点透明地访问这些表,但仍将整个数据集看作一个逻辑并集。 该架构具有 3 个优点:
并行处理
查询在数据节点上并行运行,各个结果被应用程序所连接的节点合并、组合,然后以完整的查询结果返回给应用程序,这在许多情况下显着提高了执行速度。
分区缓存
每个数据节点都有自己的缓存,专用于它存储的分片表数据分区,而非为整个数据集提供服务的单个实例的缓存,这大大降低了缓存溢出的风险,以及强制进行读取性能较低的磁盘的风险。
并行加载
数据可以并行加载到数据节点上,这降低了插入工作负载和查询工作负载之间缓存和磁盘的争用,从而提高两者的性能。
有关 InterSystems IRIS 分片集群的详细信息,可在此处找到。
分片组件和实例类型
分片集群包含至少一个数据节点,如果特定性能或工作负载有需要,则可添加一定数量的计算节点。 这两种节点类型提供简单的构建基块,显示了一个简单、透明和高效的缩放模型。
数据节点
数据节点存储数据。 在物理层面,分片表[1]数据分布在集群中的所有数据节点上,非分片表数据仅物理存储在第一个数据节点上。 这种区分对用户是透明的,唯一可能的例外是,第一个节点的存储消耗可能比其他节点略高,但是由于分片表数据通常会超出非分片表数据至少一个数量级,因此这种差异可以忽略不计。
需要时,可以跨集群重新均衡分片表数据,这通常发生在添加新的数据节点后。 这将在节点之间移动数据的“存储桶”,以实现数据的近似均匀分布。
在逻辑层面,未分片的表数据和所有分片的表数据的并集在任何节点上都可见,因此客户端会看到整个数据集,这与其连接哪个节点无关。 元数据和代码也会在所有数据节点之间共享。
分片集群的基本架构图仅由在集群中看起来统一的数据节点组成。 客户端应用程序可以连接到任何节点,并且获得像数据是存储在本地一样体验。
图 9.2.1-a:基本分片集群图
[1]为方便起见,术语“分片表数据”在整个文档中用于表示支持分片的任何数据模型的“盘区”数据(标记为已分片)。 术语“未分片表数据”和“未分片数据”用于表示处于可分片盘区但却未这样标记的数据,或表示尚不支持分片的数据模型。
计算节点
对于要求低延迟(可能存在不断涌入数据的冲突)的高级方案,可以添加计算节点以提供用于服务查询的透明缓存层。
计算节点缓存数据。 每个计算节点都与一个数据节点关联,为其缓存相应的分片表数据,此外,它还根据需要缓存非分片表数据,以满足查询的需要。
图 9.2.2-a:具有计算节点的分片集群
由于计算节点物理上并不存储任何数据,其只是支持查询执行,因此可对其硬件配置文件进行调整以满足需求,调整方法如:通过强调内存和 CPU、将存储空间保持在最低限度等。 当“裸露”应用程序代码在计算节点上运行时,引入数据会被驱动程序 (xDBC, Spark) 直接或被分片管理器代码间接转发到数据节点。
分片集群说明
分片集群部署有多种组合。下列各图说明了最常见的部署模型。这些图不包括网络网关及细节,仅侧重于分片群集组件。
基本分片集群
下图是在一个区域和一个地区中部署了 4 个数据节点的最简单分片群集。AWS Elastic 负载均衡器 (ELB) 用于将客户端连接分发到任何一个分片集群节点。
图 9.3.1-a:基本分片集群
在此基本模型中,除了 AWS 为单个虚拟机及其连接的 SSD 持久性存储提供的弹性或高可用性外,没有其他弹性或高可用性。建议使用两个单独的网络接口适配器,一则为入站客户端连接提供网络安全隔离,二则为客户端流量和分片集群通信之间提供带宽隔离。
具有高可用性的基本分片集群
下图是在一个区域中部署了 4 个镜像数据节点的最简单分片集群,每个节点的镜像在地区之间进行了划分。AWS 负载均衡器用于将客户端连接分发到任何分片集群节点。
InterSystems 数据库镜像的使用带来了高可用性,其会在该区域内的第二地区中维护一个同步复制的镜像。
建议使用 3 个单独的网络接口适配器,一方面为入站客户端连接提供网络安全隔离,另一方面为客户端流量、分片集群通信、节点对之间的同步镜像流量之间提供带宽隔离。
图 9.3.2-a:具有高可用性的基本分片集群
此部署模型也引入了本文前面所述的镜像仲裁器。
具有单独计算节点的分片集群
下图采用单独的计算节点和 4 个数据节点扩展了分片集群,以此来应对大量的用户/查询并发。云负载均衡器服务器池仅包含计算节点的地址。数据更新和数据插入将像以前一样继续直接更新到数据节点,以维持超低延迟性能,并避免由于实时数据插入而在查询/分析工作负载之间造成资源的干扰和拥挤。
使用此模型,可以根据计算/查询和数据插入的规模单独微调资源分配,从而在“适时”需要的地方提供最佳资源,实现经济而简单的解决方案,而非只是进行计算或数据的调整,浪费不必要的资源。
计算节点非常适合直接使用 AWS 自动伸缩分组(亦称自动伸缩),允许基于负载的增加或减少自动从托管实例组添加或删除实例。 自动伸缩的工作原理为:负载增加时,将更多的实例添加到实例组(扩展);对实例的需求降低时将其删除(缩减)。
有关 AWS 自动伸缩的详细信息,可在此处找到。
图 9.3.3-a:具有单独计算节点和数据节点的分片集群
自动伸缩可帮助基于云的应用程序轻松应对流量增加的情况,并在资源需求降低时降低成本。 只需简单地定义策略,自动伸缩器就会根据测得的负载执行自动伸缩。
* * *
备份操作
备份操作有多个选项。以下 3 个选项可供您通过 InterSystems IRIS 进行 AWS 部署。
下面的前 2 个选项(下文详细说明)采用快照类型的过程,该过程会在创建快照之前将数据库写入操作挂起到磁盘上,然后在快照成功后恢复更新。
可采取以下高级别步骤通过任一快照方法来创建洁净的备份:
通过数据库冻结外部 API 调用暂停对数据库的写入。
创建操作系统和数据磁盘的快照。
通过解冻外部 API 调用恢复数据库写入。
将快照存档备份到备份位置
有关冻结/解冻 外部API 的详细信息,可在此处找到。
注意:本文档未包含备份示例脚本,但您可定期检查发布到 InterSystems 网站上开发者社区的示例。 www.community.intersystems.com
第三个选项是 InterSystems 在线备份。这是小型部署的入门级方法,具有非常简单的用例和界面。但是,随着数据库的增大,建议将使用快照技术的外部备份作为最佳做法,因为其具有以下优势:备份外部文件、更快的恢复时间,以及企业范围的数据和管理工具。
可以定期添加诸如完整性检查之类的其他步骤,以确保洁净且一致的备份。
决定使用哪种选项取决于您组织的运营要求和策略。InterSystems 可与您详细讨论各种选项。
AWS Elastic Block Store (EBS) 快照备份
可以使用 AWS CLI 命令行 API 以及 InterSystems 冻结/解冻外部API 功能来实现备份操作。 这允许实现真正的 24x7 全天候操作弹性保证,并确保干净的常规备份。有关管理、创建和自动化 AWS EBS 快照的详细信息,可在此处找到。
逻辑卷管理器 (LVM) 快照
或者,可以在 VM 本身中部署单个备份代理,利用文件级备份,并结合逻辑卷管理器 (LVM) 快照,来使用市面上的许多第三方备份工具。
该模型的主要优点之一是能够对基于 Windows 或 Linux 的 VM 进行文件级恢复。此解决方案需要注意的几点是,由于 AWS 和大多数其他 IaaS 云提供商都不提供磁带媒体,因此所有的备份存储库对于短期归档均基于磁盘,并利用 Blob 或存储桶类型的低成本存储来进行长期保留 (LTR)。强烈建议您使用此方法来使用支持重复数据删除技术的备份产品,以最有效地利用基于磁盘的备份存储库。
这些具有云支持的备份产品的示例包括但不限于:Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。InterSystems 不会验证或认可一种备份产品是否优于其他产品。
在线备份
对于小型部署,内置在线备份工具也是可行的选择。该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据,然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 有关在线备份的详细信息,可在此处找到。
在 AWS 中,在线备份完成后,必须将备份输出文件和系统正在使用的所有其他文件复制到该虚拟机实例之外的其他存储位置。存储桶/对象存储是很好的选择。
使用 AWS Single Storage Space(S3)存储桶有两种选择。
直接使用 AWS CLI 脚本 API 来复制和操作新创建的在线备份(和其他非数据库)文件
有关详细信息可在此处找到。
装载 Elastic File Store (EFS) 卷,将其类似地用作持久性磁盘,这样做成本低。
有关 EFS 的详细信息,可在此处找到。
* * *
文章
Li Yan · 一月 13, 2021
本文提供了一个参考架构,作为示例说明基于 InterSystems Technologies(适用于 Caché、Ensemble、HealthShare、TrakCare 以及相关的嵌入式技术,例如 DeepSee、iKnow、Zen 和 Zen Mojo)提供的强大性能和高可用性应用。Azure 有两种用于创建和管理资源的不同部署模型:Azure Classic 和 Azure Resource Manager。 本文中的详细信息基于 Azure Resource Manager (ARM) 模型。
摘要
Microsoft Azure 云平台为基础设施即服务 (IaaS) 提供功能丰富的环境,其作为云提供完备的功能,支持所有的 InterSystems 产品。 与任何平台或部署模型一样,必须留心以确保考虑到环境的各个方面,例如性能、可用性、操作和管理程序。 本文将阐述所有这些方面。
性能
在 Azure ARM 中,有多个可用于计算虚拟机 (VM) 的选项以及相关的存储选项,与 InterSystems 产品最直接相关的是网络连接 的IaaS 磁盘,其作为 VHD 文件存储在 Azure 页面的 Blob 存储中。 还有其他几个选项,例如_ Blob(块)、文件_等,但是这些选项更特定于单个应用程序的要求,而非支持 Caché 的操作。 磁盘存储有两种类型的存储:“高级存储”和“标准存储”。 高级存储更适合这样的生产工作负载:要求保证可预测的低延迟每秒输入/输出操作 (IOP) 和吞吐量。 标准存储是针对非生产或存档类型工作负载的更经济选择。 选择特定的 VM 类型时务必小心,因为并非所有的 VM 类型都可以访问高级存储。
虚拟 IP 地址和自动故障转移
大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力,这种地址通常用在数据库故障转移设计中。 为解决这一问题,Caché 中增强了几种最常用的连接方法,尤其是 ECP 客户端和 CSP 网关,从而不再依赖 VIP 功能使它们实现镜像状态感知。
xDBC、直接 TCP/IP 套接字等连接方法,或其他的直接连接协议,均需要使用 VIP。 为解决这些问题,InterSystems 数据库镜像技术使用 API 与 Azure 内部负载均衡器(ILB)交互以实现类 VIP 功能,使得 Azure 中的那些连接方法实现自动故障转移,从而在 Azure 中提供完整而强大的高可用性设计 。 有关详细信息,请参见社区文章无虚拟 IP 地址的数据库镜像。
备份操作
无论使用传统的文件级备份,还是基于快照的备份,在云部署中执行备份都面临着挑战。 如今,在 Azure ARM 平台中,使用 Azure Backup 和 Azure Automation Run Books 配合 InterSystems 外部冻结及解冻 API 功能,即可实现这一切,从而实现真正的 24x7 全天候操作弹性并确保干净的常规备份。 或者,可以在 VM 本身中部署备份代理,利用文件级备份,并结合逻辑卷管理器 (LVM) 快照,来使用市面上的许多第三方备份工具。
示例架构
作为本文档的一部分,这里为您提供一个示例 Azure 架构,作为您特定应用部署的入门参考,并可用作各种部署的可能性的指南。 此参考架构显示了一个强大的 Caché 数据库部署,其中包括可实现高可用性的数据库镜像成员、使用 InterSystems 企业缓存协议(ECP)的应用程序服务器、使用 InterSystems CSP 网关的 Web 服务器,以及内部和外部 Azure 负载均衡器。
Azure 架构
在 Microsoft Azure 上部署任何基于Caché 的应用都需要特别注意某些方面。 本部分讨论通用的方面,对于您的应用的特定技术要求不做阐述。
本文档中提供了两个示例,一个基于_ InterSystems TrakCare 统一医疗信息系统,另一个基于完整的 InterSystems HealthShare 健康信息学平台部署,包括:_Information Exchange、Patient Index、Health Insight、Personal Community 和 Health Connect。
虚拟机
Azure 虚拟机 (VM) 分为两层:基本层和标准层。 两种类型提供对规模的选择。 基本层不提供标准层中的某些功能,例如负载均衡和自动伸缩。 因此,将标准层用于 TrakCare 部署。
标准层 VM 具有不同规模,按不同系列分组,即: A、D、DS、F、FS、G 和 GS。 DS、GS 和新的 FS 支持 Azure 高级存储的使用。
生产服务器通常需要使用高级存储来实现可靠性、低延迟和高性能。 因此,本文档中详细介绍的示例 TrakCare 和 HealthShare 部署架构将使用 FS、DS 或 GS 系列 VM。 注意,并非所有的虚拟机规模在所有区域中都可用。
有关虚拟机规模的详细信息,请参见:
Windows 虚拟机规模
Linux 虚拟机规模
存储
TrakCare 和 HealthShare 服务器需要 Azure 高级存储。 高级存储将数据存储在固态硬盘 (SSD) 上,以低延迟提供高吞吐量;而标准存储将数据存储在硬盘驱动器 (HDD) 上,会导致性能的降低。
Azure 存储属于冗余且高度可用的系统,但是,请务必注意,可用性集合当前不提供跨存储故障域的冗余,在极少数情况下,这可能会导致问题。 Microsoft 有缓解方案,并正在努力使此过程对最终客户广泛可用且更容易使用。 建议您直接与当地的 Microsoft 团队合作以确定是否需要任何缓解方案。
当针对高级存储帐户配置磁盘时,IOPS 和吞吐量(带宽)取决于磁盘的大小。 当前,有三种类型的高级存储磁盘:P10、P20 和 P30。 每种对 IOPS 和吞吐量都有特定的限制,如下表所示。
高级磁盘类型
P4
P6
P10
P15
P20
P30
P40
P50
磁盘容量
32GB
64GB
128GB
256GB
512GB
1024GB
2048GB
4096GB
每个磁盘的 IOPS
120
240
500
1100
2300
5000
7500
7500
每个磁盘的吞吐量
25MB/s
50MB/s
100MB/s
125MB/s
150MB/s
200MB/s
250MB/s
250MB/s
注意:确保给定的 VM 上有足够的可用带宽来驱动磁盘流量。
例如,STANDARD_DS13 VM 具有每秒 256 MB 的专用带宽,可用于所有高级存储磁盘流量。
这意味着连接到该虚拟机的四个 P30 高级存储磁盘的吞吐量限制为每秒 256 MB,而不是四个 P30 磁盘理论上可以提供的每秒 800 MB 的速度。
有关高级存储磁盘的更多详细信息和限制,包括预配置的容量、性能、大小、IO 大小、缓存命中率、吞吐量目标和限制,请参阅:
高级存储
高可用性
InterSystems 建议在已定义的可用性集合中拥有两个或更多虚拟机。 之所以需要此配置,是因为在计划内或计划外的维护活动期间,至少有一个虚拟机可用于满足 99.95% 的 Azure SLA。 这很重要,因为在数据中心更新期间,VM 会被并行关闭、升级并以不特定的顺序重新联机,导致应用程序在此维护窗口期不可用。
因此,高度可用的架构需要每种服务器至少部署两台,这些服务器包括负载均衡 Web 服务器、数据库镜像、多个应用程序服务器等。
有关 Azure 高可用性最佳做法的更多信息,请参见:
管理可用性
Web 服务器负载均衡
基于 Caché 的应用程序可能需要外部和内部负载均衡 Web 服务器。 外部负载均衡器用于通过 Internet 或 WAN(VPN 或 Express Route)进行的访问,而内部负载均衡器则通常用于内部流量。 Azure 负载均衡器是 4 层 (TCP, UDP) 的负载均衡器,可在负载均衡器集合中定义的云服务或虚拟机中的健康服务实例之间分配传入的流量。
Web 服务器负载均衡器必须配置客户端 IP 地址会话持续性(2 个元组)和可能的最短探测超时(当前为 5 秒)。 TrakCare 需要在用户登录期间保持会话持续性。
Microsoft 提供的下图显示了 ARM 部署模型中一个简单的 Azure 负载均衡器示例。
有关 Azure 负载均衡器的功能(例如分配算法、端口转发、服务监视、源 NAT )和其他类型的可用负载均衡器的详细信息,请参阅:
负载均衡器概述
除了 Azure 外部负载均衡器,Azure 还提供 Azure 应用程序网关。 Application Gateway 是一个 L7 负载均衡器 (HTTP/HTPS),支持基于 cookie 的会话相关性和 SSL 终端(SSL 卸载)。 SSL 卸载可减轻 Web 服务器的加密/解密开销,因为 SSL 连接会在负载均衡器处终止。 这种方法简化了管理,因为 SSL 证书是在网关中部署和管理,而不是在 Web 场中的所有节点上。
有关详细信息,请参阅︰
应用程序网关概述
使用 Azure Resource Manager 为 SSL 卸载配置应用程序网关
数据库镜像
在 Azure 上部署基于 Caché 的应用程序时,要为 Caché 数据库服务器提供高可用性,需要使用同步数据库镜像,以在给定的主 Azure 区域中提供高可用性,并可能使用异步数据库镜像将数据复制到辅助 Azure 区域中的热备用数据库中,以根据您的运行时间服务水平协议要求来进行灾难恢复。
数据库镜像是两个数据库系统的逻辑分组,也就是所说的故障转移成员,它们在物理上是仅通过网络连接的独立系统。 在这两个系统之间进行仲裁后,镜像会自动将其中一个指定为主系统。 另一个自动成为备份系统。 外部客户端工作站或其他计算机通过镜像虚拟 IP (VIP) 连接到镜像,该虚拟 IP 在镜像配置期间指定。 镜像 VIP 会自动绑定到镜像主系统上的接口。
注意:在 Azure 中,无法配置镜像 VIP,因此已设计了替代解决方案。
当前,在 Azure 中部署数据库镜像时,建议在同一 Azure 可用性集中配置三个 VM(主 VM、备份 VM、仲裁器)。 这样可确保在任何给定的时间,Azure 都可以保证至少与其中两个 VM 以 99.95% 的 SLA 建立外部连接,并且每个 VM 都位于不同的更新域和故障域中。 这样可以为数据库数据本身提供足够的隔离和冗余。
可在下列位置找到更多详细信息:
Azure 可用性集
Azure 服务水平协议 (SLA)
包括 Azure 在内的任何 IaaS 云提供程序所面临的挑战,就是在没有虚拟 IP 功能的情况下,如何处理连接到应用程序的客户端的自动故障转移。 为了保持客户端连接的自动故障转移,已采取了两种策略。
首先,InterSystems 对 CSP 网关进行了增强,使其能够感知镜像,以此使得采用 CSP 网关的 Web 服务器到数据库服务器的连接不再需要 VIP。 CSP 网关将自动与两个镜像成员进行协商,并重定向到确定的主镜像成员。 如果使用 ECP 客户端,则将与其已经具备的镜像感知协同工作。
其次,CSP 网关和 ECP 客户端外部的连接仍然需要类 VIP 功能。 InterSystems 建议将轮询方法与_ mirror_status.cxw _运行状况检查状态页面介绍的内容结合使用,该页面在社区文章无虚拟 IP 地址的数据库镜像中进行了详细说明。
Azure 内部负载均衡器 (ILB) 将提供单一 IP 地址作为类 VIP 功能,将所有网络流量定向到主镜像成员。 ILB 只会将流量分配给主镜像成员。 此方法不会依赖轮询,且在镜像配置内的任何镜像成员成为主成员时,允许立即重定向。 在某些使用 Azure Traffic Manager 的灾难恢复方案中,可将此方法与轮询结合使用。
备份与恢复
备份操作有多个选项。 以下 3 个选项可供您通过 InterSystems 产品进行 Azure 部署。 下面的前 2 个选项采用快照类型的过程,该过程会在创建快照之前将数据库写入到磁盘的操作挂起,然后在快照成功后恢复更新。 可采取以下高级别步骤通过任一快照方法来创建洁净的备份:
通过数据库冻结 API 调用暂停对数据库的写入。
创建操作系统和数据磁盘的快照。
通过数据库解冻 API 调用恢复 Caché 写入。
将设施存档备份到备份位置
可以定期添加诸如完整性检查之类的其他步骤,以确保洁净且一致的备份。
决定使用哪种选项取决于您组织的运营要求和策略。 InterSystems 可与您详细讨论各种选项。
Azure 备份
如今,在 Azure ARM 平台中,使用 Azure Backup 和 Azure Automation Run Books 配合 InterSystems 外部冻结及解冻 API 功能,即可实现备份操作,从而实现真正的 24x7 全天候操作弹性并确保干净的常规备份。 有关管理和自动化 Azure 备份的详细信息,可在此处找到。
逻辑卷管理器快照
或者,可以在 VM 本身中部署单个备份代理,利用文件级备份,并结合逻辑卷管理器 (LVM) 快照,来使用市面上的许多第三方备份工具。
该模型的主要优点之一是能够对基于 Windows 或 Linux 的 VM 进行文件级恢复。 此解决方案需要注意的几点是,由于 Azure 和大多数其他 IaaS 云提供商都不提供磁带媒体,因此所有的备份存储库对于短期归档均基于磁盘,并利用 Blob 或存储桶类型的低成本存储来进行长期保留 (LTR)。 强烈建议您使用此方法来使用支持重复数据删除技术的备份产品,以最有效地利用基于磁盘的备份存储库。
这些具有云支持的备份产品的示例包括但不限于:Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。 InterSystems 不会验证或认可一种备份产品是否优于其他产品。
Caché 在线备份
对于小型部署,内置 Caché 在线备份工具也是可行的选择。 该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据,然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。
在 Azure 中,在线备份完成后,必须将备份输出文件和系统正在使用的所有其他文件复制到 Azure 文件共享中。 该过程需要在虚拟机中编写脚本并执行。
Azure 文件共享应使用 Azure RA-GRS 存储帐户以实现最大可用性。 注意,Azure 文件共享的最大共享大小为 5TB,最大文件大小为 1TB,每个共享(所有客户端共享)的最大吞吐量为 60 MB/s。
在线备份是入门级方法,适合于希望实施低成本备份解决方案的小型站点。 但是,随着数据库的增大,建议将使用快照技术的外部备份作为最佳做法,因为其具有以下优势:备份外部文件、更快的恢复时间,以及企业范围的数据和管理工具。
灾难恢复
在 Azure 上部署基于 Caché 的应用程序时,建议将包括网络、服务器和存储在内的灾难恢复 (DR) 资源放置在不同的 Azure 区域中。 指定的 DR Azure 区域所需的容量取决于您组织的需求。 在大多数情况下,以 DR 模式运行时需要 100% 的生产能力,但是,在需要更多的生产能力作为弹性模型之前,可以配置较小的生产能力。
异步数据库镜像用于连续复制到 DR Azure 区域的虚拟机。 镜像使用数据库事务日志在 TCP/IP 网络上复制更新,其采用对主系统性能影响最小的方式。 强烈建议对这些 DR 异步镜像成员配置压缩和加密。
互联网上希望访问应用程序的所有外部客户端都将通过 Azure Traffic Manager 作为 DNS 服务进行路由。 Microsoft Azure Traffic Manager(ATM)用作交换机,负责将流量定向到当前活动的数据中心。 Azure Traffic Manager 支持多种算法来确定如何将最终用户路由到各个服务端点。 有关各种算法的详细信息,可在此处找到。
本文档中,“优先级”流量路由方法将与 Traffic Manager 端点监视和故障转移结合使用。 有关端点监视和故障转移的详细信息,可在此处找到。
Traffic Manager 的工作是向每个端点发出常规请求,然后验证响应。 如果端点未提供有效的响应,则 Traffic Manager 会将其状态显示为“降级”。 它将不会再被包含在 DNS 响应中,而是会返回一个备用的可用端点。 通过这种方式,将用户流量从失败的端点定向到可用端点。
使用上述方法,只有特定区域和特定镜像成员才允许流量通过。 这由端点定义控制,可从 InterSystems CSP 网关的 mirror_status 页面设置端点定义。 只有主镜像成员才能通过监控器探测来报告 HTTP 200 为“成功”。
Microsoft 提供的下图在高级别上显示了优先级流量例程算法。
Azure Traffic Manager 会产生一个所有客户端都可以连接到的端点,例如:“ https://my-app.trafficmanager.net ”。 此外,可以配置 A 记录来提供虚 URL,例如“ https://www.my-app-domain.com ”。Azure Traffic Manager 必须配置一个包含两个区域端点地址的配置文件。
在任何给定时间,只有其中的一个区域会根据端点监视在线报告。 这样可以确保流量在给定的时间仅流向一个区域。 区域之间的故障转移无需其他步骤,因为端点监控将检测到主 Azure 区域中的应用程序已关闭,并且该应用程序现在位于辅助 Azure 区域中。 这是因为 DR 异步镜像成员被提升为主成员,然后允许 CSP 网关将 HTTP 200 报告给 Traffic Manager 端点监视。
上述解决方案有很多替代方案,可以根据您组织的运营要求和服务水平协议进行自定义。
网络连接
根据您应用程序的连接要求,有多种连接模型可用:使用 Internet、IPSEC VPN 的连接模型,或使用 Azure Express Route 的专用链接。 选择方法取决于应用程序和用户需求。 三种方法的带宽使用情况各不相同,最好与您的 Azure 代表或 Azure 门户联系以确认给定区域的可用连接选项。
如果您正在使用 Express Route,则可为灾难恢复方案启用包括多线路和多区域访问在内的多个选项。 与 Express Route 提供商合作以了解他们支持的高可用性和灾难恢复方案至关重要。
安全
决定在公共云提供程序中部署应用程序时需要格外小心。 应遵循您组织的标准安全策略或专门为云开发的新安全策略,以维护您组织的安全合规性。 就客户端数据中心之外的数据以及物理安全控制方面,云部署的风险逐渐加大。 强烈建议对静态数据(数据库和日志)及飞行数据(网络通信)使用 InterSystems 数据库和日志加密,分别使用 AES 和 SSL/TLS 加密。
与所有加密密钥管理一样,您需要按照您组织的政策记录并遵循正确的程序,以确保数据安全,防止不必要的数据访问或安全漏洞。
当允许通过互联网进行访问时,可能需要第三方防火墙设备来实现其他功能,例如入侵检测、拒绝服务保护等。
架构图示例
下图说明了典型的 Caché 安装,其以数据库镜像(同步故障转移和 DR 异步)、使用 ECP 的应用程序服务器,以及多个负载均衡 Web 服务器的方式提供高可用性。
TrakCare 示例
下图说明了典型的 TrakCare 部署,其中包含多个负载均衡 Web 服务器,两个作为 ECP 客户端的 EPS 打印服务器,以及数据库镜像配置。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 ECP 客户端和 CSP 网关可感知镜像,不需要 VIP。
下图中的示例参考架构包括活动或主区域中的高可用性,可在主 Azure 区域不可用的情况下,执行灾难恢复到另一个 Azure 区域。 同样,在此示例中,数据库镜像包含 TrakCare DB、TrakCare Analytics 和 Integration 命名空间,这些都在一个镜像集群中。
TrakCare Azure 参考架构图 - 物理架构
另外,下图显示了该架构的逻辑图,包含架构所安装的相关高级软件产品及其功能用途。
TrakCare Azure 参考架构图 - 逻辑架构
HealthShare 示例
下图显示了一个典型的 HealthShare 部署,其具有多个负载均衡 Web 服务器,以及多个 HealthShare 产品,包括 Information Exchange、Patient Index、Personal Community、Health Insight 和 Health Connect。 这些产品中的每一个都包含一对数据库镜像,以在 Azure 可用性集合中提供高可用性。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 HealthShare 产品之间用于 Web 服务通信的 CSP 网关可感知镜像,不需要 VIP。
下图中的示例参考架构包括活动或主区域中的高可用性,可在主 Azure 区域不可用的情况下,执行灾难恢复到另一个 Azure 区域。
HealthShare Azure 参考架构图 - 物理架构
另外,下图显示了该架构的逻辑图,包含架构所安装的相关高级软件产品、连接要求、方法及相应的功能用途。
HealthShare Azure 参考架构图 - 逻辑架构
文章
Qiao Peng · 一月 14, 2021
本文以及后面两篇该系列文章,是为需要在其基于 InterSystems 产品的应用程序中使用 OAuth 2.0 框架(下文简称为 OAUTH)的开发人员或系统管理员提供的指南。
作者:InterSystems 高级销售工程师 Daniel Kutac
# 发布后校正和更改历史记录
* 2016 年 8 月 3 日 - 修正了 Google 客户端配置屏幕截图,更新了 Google API 屏幕截图以反映新版本的页面
* 2016 年 8 月 28 日 - 更改了 JSON 相关代码,反映了对 Cache 2016.2 JSON 支持的更改
* 2017 年 5 月 3 日 - 更新了文本和屏幕,以反映 Cache 2017.1 的新 UI 和功能
* 2018 年 2 月 19 日 - 将 Caché 更改为 InterSystems IRIS 以反映最新的发展。 但是请记住,尽管产品名称发生更改,但**文章涵盖所有的 InterSystems 产品**——InterSystems IRIS 数据平台、Ensemble 和 Caché。
* 2020 年 8 月 17 日 - 大面积更改,软件方面更改更大。 要获取 Google 的更新版 Oauth2 的网址,请咨询 Micholai Mitchko。
_第 1 部分 客户端_
# **简介**
有关开放式授权框架 InterSystems 实现的相关内容,我们分 3 部分讲述,这是第 1 部分。
在第 1 部分中,我们对该主题进行了简短介绍,并提供了一个 InterSystems IRIS 应用程序担当授权服务器客户端并请求一些受保护资源的简单方案。
第 2 部分将讲述一个复杂一些的方案,在该方案中 InterSystems IRIS 本身通过 OpenID Connect 担当授权服务器和身份验证服务器。
本系列的最后一部分将描述 OAUTH 框架类的各个部分,它们由 InterSystems IRIS 实现。
## **什么是开放授权框架 [1] **
许多人已经听说过有关开放授权框架及其用途的信息。 因此这里只做简单介绍,以备未听说过的人参考。
开放授权框架 (OAUTH) 当前为 2.0 版,其是一种协议,允许基于 Web 的主应用程序通过在客户端(应用程序请求数据)和资源所有者(应用程序保存请求的数据)之间建立间接信任来以安全的方式交换信息。 信任本身由客户端和资源服务器都认可并信任的主体提供。 该主体称为授权服务器。
简单举例如下:
假设 Jenny(使用 OAUTH 术语,就是资源所有者)在开展 JennyCorp 公司的一个工作项目。 她为一个潜在的大型业务创建了项目计划,并邀请 JohnInc 公司的业务伙伴 John(客户端用户)审阅此文档。 不过,她并不愿意让 John 访问自己公司的 VPN,因此她将文档放在 Google 云端硬盘(资源服务器)或其他类似的云存储中。 她这样做,已经在她和 Google(授权服务器)之间建立了信任。 她标记了要与 John 共享的文档(John 已经使用 Google 云端硬盘服务,Jenny 知道他的电子邮件)。
当 John 想要阅读该文档时,他进行了 Google 帐户身份验证,然后通过移动设备(平板电脑、笔记本电脑等)启动文档编辑器(客户端服务器)并加载 Jenny 的项目文件。
这听起来很简单,但是两个人与 Google 之间有很多通信。 所有交流均遵循 OAuth 2.0 规范,因此 John 的客户端(阅读器应用程序)必须首先向 Google 进行身份验证(OAUTH 不涵盖此步骤),然后 John 申请获取 Google 对提供表格的同意,经过授权后,Google 就会发出一个访问令牌,授权阅读器应用程序访问文档。 阅读器应用程序使用该访问令牌向 Google 云端硬盘服务发出请求,以检索 Jenny 的文件。
下图说明了各方之间的通信

请注意:虽然所有的 OAUTH 2.0 通信都使用 HTTP 请求,但服务器不必非得是 Web 应用程序。
让我们通过 InterSystems IRIS 来说明这一简单方案。
# **简单 Google 云端硬盘演示**
在本演示中,我们将创建一个基于 CSP 的小型应用程序,该应用程序将使用我们自己的帐户(以及作为奖励的日历列表)来请求存储在 Google 云端硬盘服务中的资源(文件列表)。
## **基本要求**
开始应用程序编码之前,我们需要准备环境。 这包括启用 SSL 的 Web 服务器和 Google 配置文件。
### **Web 服务器配置**
如上所述,我们需要使用 SSL 与授权服务器进行通信,因为默认情况下 OAuth 2.0 要求如此。 我们需要确保数据安全,对吧?
解释如何配置 Web 服务器来支持 SSL 的内容超出了本文讨论的范围,因此,请以您喜欢的方式参阅相应 Web 服务器的用户手册。 为了您的好奇心(我们稍后可能会显示一些屏幕截图),在此特定示例中,我们将使用 Microsoft IIS 服务器。
### **Google 配置**
为了向 Google 注册,我们需要使用 Google API Manager-[ https://console.developers.google.com/apis/library?project=globalsummit2016demo ](https://console.developers.google.com/apis/library?project=globalsummit2016demo)
为了进行演示,我们创建了一个帐户 GlobalSummit2016Demo。 确保我们已启用 Drive API

现在,该定义凭据了

请注意以下事项:
_Authorized JavaScript – _我们仅允许本地生成的脚本(相对于调用页面)
_Authorized redirect URIs – 从理论上讲,我们可以将客户端应用程序重定向到任何站点,但是当使用 InterSystems IRIS OAUTH 实现时,我们必须重定向到** https://localhost/csp/sys/oauth2/OAuth2.Response.cls**。您可以定义多个授权的重定向 URI,如屏幕截图所示,但是对于本演示,我们只需要两者中的第二个条目。
最后,我们需要将 InterSystems IRIS 配置为 Google 授权服务器的客户端
### **Caché /IRIS配置**
InterSystems IRIS OAUTH2 客户端配置需要两步。 首先,我们需要创建服务器配置。
在 SMP 中,导航至**系统管理 > 安全性 > OAuth 2.0 > 客户端配置**。
点击**创建服务器配置**按钮,填写表格并保存。

输入到表格的所有信息可以在 Google 开发者控制台网站上找到。 请注意,InterSystems IRIS 支持自动 Open ID 发现。 但是,由于我们没有使用它,因此我们手动输入所有信息
现在,点击新创建的 Issuer Endpoint
旁边的“客户端配置”链接。并点击**创建客户端配置**按钮。

将“客户端信息”和“JWT 设置”选项卡保留为空(默认值),并填写客户端凭据。

请注意:我们正在创建机密客户端(这比公共客户端更安全,这意味着客户端秘密永远不会离开客户端服务器应用程序(永远不会传输到浏览器)
此外,请确保选中**“使用 SSL/TLS**”,并提供主机名(本地主机,因为我们将本地重定向到客户端应用程序),最后提供端口和前缀(当同一台机器上有多个 InterSystems IRIS 实例时,这非常有用)。 根据输入的信息,会计算客户端重定向 URL 并显示在上一行中。
在上面的屏幕截图中,我们提供了一个名为 GOOGLE 的 SSL 配置。 该名称本身实际上仅用于帮助您确定此特定通信通道使用的可能是众多 SSL 配置中的哪个。 Caché 使用 SSL/TLS 配置存储所有必要的信息,以建立与服务器(在本例中,为 Google OAuth 2.0 URI)的安全流量。
有关详细信息,请参阅[文档](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_aboutconfigs) 。
Supply Client ID 和 Client Secret 值从 Google 凭据定义表中获得(使用手动配置时)。
现在,我们完成了所有的配置步骤,可以开始编写 CSP 应用程序代码。
## **客户端应用程序**
客户端应用程序是基于 Web 的简单 CSP 应用程序。 因此,它包含由 Web 服务器定义和执行的服务器端源代码,以及由 Web 浏览器向用户公开的用户界面。 下文提供的示例代码期望客户端应用程序在 GOOGLE 名称空间中运行。 请将路径 /csp/google/ 修改为您的命名空间。
## **客户端服务器**
客户端服务器是一个简单的两页应用程序。 在该应用程序内,我们将:
· 将 URL 重定向到 Google 授权服务器
· 执行向 Google Drive API 和 Google Calendar API 的请求并显示结果
### **第 1 页**
这是应用程序的一页,我们决定在此处调用 Google 的资源。
以下是此页面上简单但功能齐全的代码。
Class Web.OAUTH2.Google1N Extends %CSP.Page
{
Parameter OAUTH2CLIENTREDIRECTURI = "https://localhost/csp/google/Web.OAUTH2.Google2N.cls";
Parameter OAUTH2APPNAME = "Google";
ClassMethod OnPage() As %Status
{
&html
// we need to supply openid scope to authenticate to Google
set scope="openid https://www.googleapis.com/auth/userinfo.email "_
"https://www.googleapis.com/auth/userinfo.profile "_
"https://www.googleapis.com/auth/drive.metadata.readonly "_
"https://www.googleapis.com/auth/calendar.readonly"
set properties("approval_prompt")="force"
set properties("include_granted_scopes")="true"
set url=##class(%SYS.OAuth2.Authorization).GetAuthorizationCodeEndpoint(..#OAUTH2APPNAME,scope,
..#OAUTH2CLIENTREDIRECTURI,.properties,.isAuthorized,.sc)
w !,""
&html
Quit $$$OK
}
ClassMethod OnPreHTTP() As %Boolean [ ServerOnly = 1 ]
{
#dim %response as %CSP.Response
set scope="openid https://www.googleapis.com/auth/userinfo.email "_
"https://www.googleapis.com/auth/userinfo.profile "_
"https://www.googleapis.com/auth/drive.metadata.readonly "_
"https://www.googleapis.com/auth/calendar.readonly"
if ##class(%SYS.OAuth2.AccessToken).IsAuthorized(..#OAUTH2APPNAME,,scope,.accessToken,.idtoken,.responseProperties,.error) {
set %response.ServerSideRedirect="Web.OAUTH2.Google2N.cls"
}
quit 1
}
}
代码的简要说明如下:
1. OnPreHTTP 方法 - 首先,我们有机会时检查一下,我们是否由于 Google 授权而获得了有效的访问令牌——这种情况可能会发生,例如当我们只是刷新页面时。 如果没有,我们需要授权。 如果我们有令牌,我们只需将页面重定向到显示结果的页面
2. OnPage 方法 - 只有在我们没有可用的有效访问令牌时,我们才到这里,因此我们需要开始通信——向 Google 进行身份验证和授权,以便它向我们授予访问令牌。
3. 我们定义了作用域字符串和属性数组,用于修改 Google 身份验证对话框的行为(我们需要先向 Google 进行身份验证,然后它才能根据我们的身份对我们进行授权)。
4. 最后,我们收到 Google 登录页面的 URL,然后将其提供给用户,接着提供同意页面。
还有一点注意事项:
我们在 OAUTH2CLIENTREDIRECTURI 参数的 中指定真正的重定向页面。 但是,我们在 Google 凭据定义中使用了 InterSystems IRIS OAUTH 框架的系统页面! 重定向由我们的 OAUTH 处理程序类在内部处理。
### **第 2 页**
此页面显示 Google 授权的结果,如果成功,我们将调用 Google API 调用以检索数据。 同样,此代码简单,但功能齐全。 相比读者的想象,我们以更结构化的方式来显示输入数据。
Include %occInclude
Class Web.OAUTH2.Google2N Extends %CSP.Page
{
Parameter OAUTH2APPNAME = "Google";
Parameter OAUTH2ROOT = "https://www.googleapis.com";
ClassMethod OnPage() As %Status
{
&html
// Check if we have an access token
set scope="openid https://www.googleapis.com/auth/userinfo.email "_
"https://www.googleapis.com/auth/userinfo.profile "_
"https://www.googleapis.com/auth/drive.metadata.readonly "_
"https://www.googleapis.com/auth/calendar.readonly"
set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(..#OAUTH2APPNAME,,scope,.accessToken,.idtoken,.responseProperties,.error)
if isAuthorized {
// Google has no introspection endpoint - nothing to call - the introspection endpoint and display result -- see RFC 7662.
w "Data from GetUserInfo API"
// userinfo has special API, but could be also retrieved by just calling Get() method with appropriate url
try {
set tHttpRequest=##class(%Net.HttpRequest).%New()
$$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).AddAccessToken(tHttpRequest,"query","GOOGLE",..#OAUTH2APPNAME))
$$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).GetUserinfo(..#OAUTH2APPNAME,accessToken,,.jsonObject))
w jsonObject.%ToJSON()
} catch (e) {
w "ERROR: ",$zcvt(e.DisplayString(),"O","HTML")_""
}
/******************************************
* *
* Retrieve info from other APIs *
* *
******************************************/
w ""
do ..RetrieveAPIInfo("/drive/v3/files")
do ..RetrieveAPIInfo("/calendar/v3/users/me/calendarList")
} else {
w "Not authorized!"
}
&html
Quit $$$OK
}
ClassMethod RetrieveAPIInfo(api As %String)
{
w "Data from "_api_""
try {
set tHttpRequest=##class(%Net.HttpRequest).%New()
$$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).AddAccessToken(tHttpRequest,"query","GOOGLE",..#OAUTH2APPNAME))
$$$THROWONERROR(sc,tHttpRequest.Get(..#OAUTH2ROOT_api))
set tHttpResponse=tHttpRequest.HttpResponse
s tJSONString=tHttpResponse.Data.Read()
if $e(tJSONString)'="{" {
// not a JSON
d tHttpResponse.OutputToDevice()
} else {
w tJSONString
w ""
/*
// new JSON API
&html
s tJSONObject={}.%FromJSON(tJSONString)
set iterator=tJSONObject.%GetIterator()
while iterator.%GetNext(.key,.value) {
if $isobject(value) {
set iterator1=value.%GetIterator()
w "",key,""
while iterator1.%GetNext(.key1,.value1) {
if $isobject(value1) {
set iterator2=value1.%GetIterator()
w "",key1,""
while iterator2.%GetNext(.key2,.value2) {
write !, "",key2, "",value2,""
}
// this way we can go on and on into the embedded objects/arrays
w ""
} else {
write !, "",key1, "",value1,""
}
}
w ""
} else {
write !, "",key, "",value,""
}
}
&html
*/
}
} catch (e) {
w "ERROR: ",$zcvt(e.DisplayString(),"O","HTML")_""
}
}
}
让我们快速看一下代码:
1. 首先,我们需要检查一下我们是否具有有效的访问令牌(即我们是否被授权)
2. 如果是,我们可以向 Google 提供且由已发布访问令牌覆盖的 API 发出请求
3. 为此,我们使用标准的 %Net.HttpRequest 类,但根据 API 规范,我们将访问令牌添加到 GET 或 POST 方法中
4. 如您所见,为了方便您,OAUTH 框架已实现 GetUserInfo()方法,但是您可以使用 Google API 规范直接检索用户信息,就像我们在 RetrieveAPIInfo()助手方法中所做的一样。
5. 由于在 OAUTH 世界中以 JSON 格式交换数据司空见惯,因此我们只读取传入的数据,然后简单地将其转储到浏览器。 应用程序开发人员可以解析和格式化接收到的数据,以便用户可以看明白。 但这超出了本演示的范围。 (尽管一些代码有注释,显示了如何完成解析。)
下图是一个输出屏幕截图,显示了原始 JSON 数据。

继续阅读[第 2 部分](https://community.intersystems.com/post/cach%C3%A9-open-authorization-framework-oauth-20-implementation-part-2),该部分讲述 InterSystems IRIS 担当授权服务器和 OpenID Connect 提供程序相关的内容。
[1] https://tools.ietf.org/html/rfc6749, https://tools.ietf.org/html/rfc6750