企业需要快速有效地扩展和管理其全球计算基础设施，同时优化和管理资本成本及支出。

本文介绍了 InterSystems 客户围绕 SDDC 和 HCI 解决方案的注意事项。

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

越来越多的 IT 组织正在探究使用SDDC 和 HCI 解决方案的可行性。 这些解决方案看上去很有吸引力，其市场定位为跨异构数据中心和云基础设施可以使得 IT 管理更容易、投入的成本花费更少。 对于 IT 组织来说，潜在的好处是巨大的，许多 InterSystems 客户正在拥抱 SDDC、HCI 或两者兼有。

如果您正在考虑 SDDC 或 HCI 解决方案，请联系您的销售客户经理或销售工程师，安排与技术架构师的通话。 这对于确保成功非常重要。

当您首次使用InterSystems IRIS时，通常只需安装最低安全级别的系统。您输入密码的次数会比较少，这样有利于快速了解和操作开发服务和Web应用程序。而且，最低的安全性有时更便于部署开发项目或解决方案。

然而，有时需要将项目移出开发环境，迁移到一个可能很不友好的互联网环境中。在部署到生产环境之前，需要使用最大的安全设置（即，完全锁定）对其进行测试。这就是我们在本文中将要讨论的内容。

如果想更全面地了解InterSystems Caché、Ensemble和IRIS中的DBMS安全性问题，请阅读我的另一篇文章《在生产环境中安装InterSystems Caché DBMS的相关建议》。

InterSystems IRIS中安全系统的设计概念是针对不同的类别（用户、角色、服务、资源、特权和应用程序）应用不同的安全设置。

可以为用户分配角色。用户和角色可以对资源（数据库、服务和应用程序）拥有不同的读、写和使用权限。用户和角色还可以对数据库中的SQL表拥有SQL权限。

在最近的项目里，多方同时连接同一个数据库并执行增删改查等各项数据操作。研发人员不时发现一些数据在不合规的情况下被新增甚至删除。因此，在实际工作中会有监控数据操作以便识别和处理异常操作的需求。本文将以监控和识别删除操作为例，介绍如何通过IRIS的审计功能实现对数据操作的监控和查询。

我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。

IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。

IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。

大家好！

我想跟大家分享一个个人项目，该项目始于工作中的一个简单需求：“能否知道我们使用了多少个Caché许可证？”

在阅读社区的其他文章时，我发现了一篇David Loveluck写的非常棒的文章：APM——使用Caché History Monitor。

我根据David的这篇文章，开始使用Caché History Monitor并显示所有这些信息。

在面临“选择哪种很酷的技术”这个问题时，我决定使用简单而强大的CSP，这样我的客户可以认识到Caché不仅仅是MUMPS/终端。

在创建了页面以显示许可、数据库增长和CSP会话的历史记录后，我决定为System Dashboard和进程页面创建一个新设计。

我的Caché实例运行得良好。

但是，如果使用IRIS呢？

下一篇：
案例: 建立只能使用SQL的用户

IRIS通过认证（Authentication）与授权（Authorization）两项机制控制外部用户对系统及应用、数据资源的可访问性。因此。如需要进行权限控制，则需要通过配置认证和授权进行。

现在，InterSystems 系统警报和监视（简称 InterSystems SAM）第 1 版 (v1.0) 发布了预览版本。
  
InterSystems SAM v1.0 为基于 InterSystems IRIS 的产品提供现代化的监视解决方案。 其可对集群进行高级别查看，并且能够以单节点方式可视化深入探视指标，同时提供警报通知。 该第 1 个版本提供对一百多个 InterSystems IRIS 内核指标的可视化，并且用户可以根据自己的喜好扩展默认提供的 Grafana 模板。

V1.0 旨在成为简单直观的基准。 请进行尝试并向我们发送反馈，帮助我们使其变得更棒！

从版本 2019.4 开始，SAM 可以显示来自基于 InterSystems 的实例中的信息

SAM 仅以容器格式提供。 您将需要 SAM 管理器容器，以及一小组额外的开源组件（Prometheus 和 Grafana），它们由组合文件自动添加。

可从以下位置获取 SAM 组件和 SAM 管理器社区版

• WRC 预览页面：分别为“SAM 组件”和“SAM 管理器”
• 如果您要在 docker-compose 运行之前下载，可通过外部源SAM 组件 Github repo & Docker Hub 上的 SAM 管理器（后一个链接可能在几个小时内不可用，但容器是可获取的）

如果您正在旅行，或偏爱通过语音收听有关什么是 SAM 方面的提问与回答，我们为您准备了以下播客：

InterSystems产品有四种备份方法:
(1) 外部备份
(2) 在线备份
(3) 冷备份
(4) 传统的并行外部备份
有关这些方法的细节请参考在线文档 https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...

以下是对每种备份方法的简要描述:

大家好！

不久前，我将SQL Runtime 统计中的配置更改为“Turn on Stats code generation to gather stats at the Open and Close of a query” 。进行此更改后， CACHE的基础（ cache / mgr / cache / ）增长了很多，达到198GB 。

昨天，我将SQL运行时统计信息的配置恢复为默认值“关闭统计信息代码生成” ，并且缓存基数不再增长。

我的问题是？

如何删除在CACHE基础（cache / mgr / cache /）中创建的此数据，以及可以删除哪些数据而不影响系统。

谢谢，
法比奥（FábioLouly）。

这次我想谈一谈不专门针对 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 容器进行工作的环境。 我们开始吧...

供应商或内部团队要求说明如何为 VMware vSphere 上运行的大型生产数据库进行 CPU 容量规划。

总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：

• 为每个物理 CPU 核心规划一个 vCPU。
• 考虑 NUMA 并按理想情况调整虚拟机规模，以使 CPU 和内存对于 NUMA 节点是本地的。
• 合理调整虚拟机规模。 仅在需要时才添加 vCPU。

通常，这会引出几个常见问题：

• 由于使用超线程技术，VMware 创建的虚拟机的 CPU 数量可以是物理 CPU 数量的两倍。 那不就是双倍容量吗？ 创建的虚拟机不应该有尽可能多的 CPU 吗？
• 什么是 NUMA 节点？ 我应该在意 NUMA 吗？
• 虚拟机应该合理调整规模，但我如何知道什么时候合理？

我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。

本帖将展示为 InterSystems 数据平台上运行的数据库应用调整共享内存需求（包括 global 和例程缓冲区、gmheap 以及 locksize）的方法，以及在配置服务器和虚拟化 Caché 应用程序时应考虑的一些性能提示。 和以往一样，当我谈到 Caché 时，我指的是所有数据平台（Ensemble、HealthShare、iKnow 和 Caché）。

本系列其他帖子的列表

当我最初开始使用 Caché 时，大多数客户的操作系统是 32 位的，Caché 应用程序的内存有限且昂贵。 通常部署的英特尔服务器只有几个核心，唯一的扩展方式是选择大型服务器，或者使用 ECP 横向扩展。 现在，即使是基本的生产级服务器也具有多个处理器、几十个核心，并且最小内存为 128 或 256 GB，可能达到 TB。 对于大多数数据库安装，ECP 已被遗忘，我们现在可以在单台服务器上大幅提高应用事务处理速率。