OpenShift Container Platform 4 上的 SAP Data Intelligence 3

通常，SAP Data Intelligence (SDI)的安装遵循以下步骤：

• 安装 Red Hat OpenShift Container Platform
• 配置 SAP Data Intelligence Foundation 的先决条件
• 安装 SDI Observer
• 在 OpenShift Container Platform 上安装 SAP Data Intelligence Foundation

如果您对 SAP Data Hub 或 SAP Vora 的安装有兴趣，请参阅其他安装指南：

• OpenShift Container Platform 4 上的 SAP Data Hub 2
• OpenShift Container Platform 3 上的 SAP Data Hub 2
• 在 OpenShift Container Platform 上安装 SAP Data Hub 1.X Distributed Runtime
• 在 Red Hat OpenShift 3.7 上安装 SAP Vora 2.1

请注意 OpenShift Container Storage (OCS)在本文中以其新产品名称 OpenShift Data Foundation (ODF)来称呼。
请注意 OpenShift Container Platform (OCP)可以被 OpenShift Kubernetes Engine (OKE) 替代。OKE 足以支持运行 SAP Data Intelligence。

▲请注意

在安全审计过程中可能会发现已知的 SAP 镜像安全问题。红帽无法解决它们。请针对以下任一情况，开一个 SAP 支持问题单：

• SAP 容器以 root 用户身份运行
• SAP 容器无限制运行（不受 SELinux 限制）
• SAP 容器需要特权安全上下文

1.OpenShift Container Platform 验证版本矩阵

以下 SDI 3.X、OpenShift Container Platform (OCP)版本组合，RHEL 或 RHCOS 的版本组合已对生产环境进行了验证：

有关 OpenShift 版本 4.14 及更新版本支持 SAP Data Intelligence 的详情，请参考 https://access.redhat.com/articles/7042265。

SAP Data Intelligence	OpenShift Container Platform	操作系统	基础设施和(存储)	SAP 已确认并支持
3.0	4.2 †	RHCOS（节点）、RHEL 8.1+ 或 Fedora（管理主机）	VMware vSphere (ODF 4.2)	支持 †
3.0 Patch 3	4.2 †, 4.4 †	RHCOS（节点）、RHEL 8.2+ 或 Fedora（管理主机）	VMware vSphere (ODF 4)	支持 †
3.0 Patch 4	4.4 †	RHCOS（节点）、RHEL 8.2+ 或 Fedora（管理主机）	VMware vSphere (ODF 4),(NetApp Trident 20.04)	支持 †
3.0 Patch 8	4.6 †	RHCOS（节点）、RHEL 8.2+ 或 Fedora（管理主机）	KVM/libvirt (ODF 4)	支持 †
3.1	4.4 †	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	VMware vSphere (ODF 4)	不支持 ¹
3.1	4.6 †	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	VMware vSphere (ODF 4 ¡, NetApp Trident 20.10 + StorageGRID), Bare metal ∗ (ODF 4 ¡)	支持 †
3.2	4.6 †, 4.8	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	IBM Cloud™(IBM Cloud Block Storage)	支持
3.2	4.6 †, 4.8	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	VMware vSphere (ODF 4)	支持
3.2	4.8, 4.10,	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	Bare metal ∗ (ODF 4 ¡)	支持
3.3	4.8, 4.10, 4.12	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	VMware vSphere (ODF 4)	支持
3.3	4.8, 4.10, 4.12	RHCOS（节点）、RHEL 8.3+ 或 Fedora（管理主机）	Bare metal ∗ (ODF 4 ¡)	支持

†

红帽不再支持引用的 OpenShift 版本！
SAP 支持的 OpenShift 4.4 上的

¹

3.1 仅用于升级到 OpenShift 4.6

∗

在两个不同的硬件配置上验证了：

• 如需有关 IBM Cloud™ 上的 OCP 的更多信息，请参阅 开始使用 IBM Cloud 上的 Red Hat OpenShift。
  如果使用此平台，您不需要安装 OpenShift，并可以直接跳转到 IBM 文档 规划您的 SAP Data Intelligence 部署。您将获得所有安装步骤的指导，并找到指向红帽文章的合适的链接。

• (Dev/PoC 级别) Lnovo 4 裸机主机设置包括：

  • 3 个运行 ODF 和 SDI (Lenovo ThinkSystem SR530)的可调度的控制平面节点
  • 1 个运行 SDI 的计算节点(Lenovo ThinkSystem SR530)

• （生产环境级别） Dell Technologies 裸机集群包括：

  • 1 CSAH节点(Dell EMC PowerEdge R640s)
  • 3 个控制平面节点(Dell EMC PowerEdge R640s)
  • 3 个专用 ODF 节点(Dell EMC PowerEdge R640s)
  • 3 个专用的 SDI 节点(Dell EMC PowerEdge R740xd)

  CSI 支持的外部 Dell EMC 存储选项和可用的集群大小选项。
  

  CSAH

  代表 Cluster System Admin Host - 相当于 管理主机

有关被视为工作的版本组合，请参阅 兼容性矩阵。

SAP Note #2871970 列出了更多详细信息。

2.要求

2.1.硬件/VM 和操作系统要求

2.1.1.OpenShift 集群

确保查阅以下官方集群要求：

• SAP 文档中的 SAP Data Intelligence：
  • SAP Data Intelligence (3.3) / (3.2) / (3.1) 。
  • SAP Data Intelligence (3.3) / (3.2) / (3.1) 的最小大小
  • SAP Data Intelligence 的初始大小(3.3) / (3.2) / (3.1) / SAP Data Intelligence 的 T-Shirt 大小 (3.0)
• OpenShift 4 (最低资源要求(4.12) / (4.10))
• 另外，如果部署 OpenShift Data Foundation （也称为 ODF），请咨询 ODF 支持的配置(4.12) / (4.10)
• 如果在 VMware vSphere 上部署，请还考虑 VMware vSphere 基础设施要求(4.12) / (4.10)
• 如果部署 NetApp Trident，请还咨询 NetApp Hardware/VM 和操作系统要求

2.1.1.1.节点类型

有 4 种类型的节点：

• Bootstrap 节点 - OpenShift 部署所需的临时 bootstrap 节点。节点可以通过安装程序（使用基础设施置备安装 -- 也称为 IPI）销毁，或者由管理员手动删除。或者，它可以重新用作 worker 节点。如需更多信息，请参阅 安装过程(4.12) / (4.10)。
• 主节点 (4.12) / (4.10) - 控制平面管理 OpenShift Container Platform 集群。可以使控制平面 可调度 ，以便在那里也启用 SDI 工作负载。
• 计算节点 (4.12) / (4.10) - 运行实际的工作负载（如 SDI pod）。它们在三节点集群(其中主节点是可以调度的)上是可选的。
• ODF 节点 (4.12) / (4.10) - 运行 OpenShift Data Foundation （也称为 ODF）。节点可以划分为 starting （运行 OSD 和监控）和 additional 节点（仅运行 OSD）。仅在将 ODF 用作后备存储提供者时才需要。
  • 备注 ：从 ODF 4.8 开始，完全支持在 紧凑模式（在控制平面上）下运行。

• 管理主机 （也称为 管理员的工作站 或 跳板主机）- 管理主机用于：

  • 通过配置的命令行客户端(oc 或 kubectl)访问 OpenShift 集群
  • 配置 OpenShift 集群
  • 运行软件生命周期容器网桥(SLC 网桥)

用于 管理主机 的硬件/软件要求可以是：

• OS:Red Hat Enterprise Linux 8.1+, RHEL 7.6+ 或 Fedora 30+
• 磁盘空间：20GiB 用于 / ：

2.1.1.2.记录断开连接的和气隙的环境

根据术语"断开连接的主机"，它是指无法访问互联网的主机。
根据术语"断开连接的集群"，它是指每个主机都断开连接的集群。
断开连接的集群可以从连接的（可以访问互联网）或断开连接的 管理主机 进行管理。
后一种场景（集群和 管理主机 都断开连接）按术语将被称为"气隙"。
除非另有说明，否则任何适用于断开连接的主机、集群或环境的任何场景都也适用于"气隙"。

2.1.1.3.最低硬件要求

下表列出了最新经过验证的 SDI 和 OpenShift 4.X 版本的每个节点类型的 最低要求 和最少实例数。这对于 PoC （概念验证）环境足够了。

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
Bootstrap	1	RHCOS	4	16	120	m4.xlarge
Master	3	RHCOS	4	16	120	m4.xlarge
Compute	3+	RHCOS 或 RHEL 7.8 或 7.9	8	32	120	m4.2xlarge

在三节点集群上，它类似如下：

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
Bootstrap	1	RHCOS	4	16	120	m4.xlarge
Master/Compute	3	RHCOS	10	40	120	m4.xlarge

如果在内部模式下使用 ODF，则建议至少需要额外的 3 （启动） 个节点。或者，上面概述的计算节点也可以运行⑂ ODF pod。在这种情况下，硬件规格需要相应地扩展。下表列出了每个额外节点的最低要求：

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
ODF 启动 (OSD+MON)	3	RHCOS	10	24	120 + 2048 ♢	m5.4xlarge

2.1.1.4.最低生产硬件要求

最新验证的 SDI 和 OpenShift 4 的生产系统的 最低 生产要求如下：

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
Bootstrap	1	RHCOS	4	16	120	m4.xlarge
Master	3+	RHCOS	8	16	120	c5.xlarge
Compute	3+	RHCOS 或 RHEL 7.8 或 7.9	16	64	120	m4.4xlarge

在三节点集群上，它类似如下：

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
Bootstrap	1	RHCOS	4	16	120	m4.xlarge
Master/Compute	3	RHCOS	22	72	120	c5.9xlarge

如果在内部模式下使用 ODF 4，则推荐最少使用额外的 3 （启动） 个节点。或者，上面概述的计算节点也可以运行 ODF ⑂ pod。 在这种情况下，硬件规格需要相应地扩展。下表列出了每个额外节点的最低要求：

类型	数量	操作系统	vCPU ⑃	RAM (GB)	存储(GB)	AWS 实例类型
ODF 启动 (OSD+MON)	3	RHCOS	20	49	120 + 6×2048 ♢	c5a.8xlarge

♢

请参阅 ODF 平台要求(4.12) / (4.10)。

⑂

从 ODF 4.8 开始，完全支持在 紧凑模式 下运行（在控制平面上）。

⑃

当启用超线程时，1 个物理核提供 2 个 vCPU。当未启用超线程时，一个物理核提供 1 个 vCPU。

2.2.软件要求

2.2.1.兼容性矩阵

SAP Data Intelligence 的后续版本支持较新的 Kubernetes 和 OpenShift Container Platform 或 OpenShift Kubernetes Engine 版本。即使未在 上面的 OpenShift 验证版本矩阵 中列出，以下版本组合也被视为完全正常工作且被支持：

SAP Data Intelligence	OpenShift Container Platform ²	Worker 节点	管理主机	基础设施	存储	对象存储
3.0 Patch 3 或更高版本	4.3, 4.4	RHCOS	RHEL 8.1 或更新版本	Cloud ❄, VMware vSphere	ODF 4,NetApp Trident 20.04 或更新版本, vSphere 卷 ♣	ODF,NetApp StorageGRID 11.3 或更新版本
3.0 Patch 8 或更高版本	4.4, 4.5, 4.6	RHCOS	RHEL 8.1 或更新版本	Cloud ❄, VMware vSphere	ODF 4,NetApp Trident 20.04 或更新版本, vSphere 卷 ♣	ODF,NetApp StorageGRID 11.3 或更新版本
3.1	4.4, 4.5, 4.6	RHCOS	RHEL 8.1 或更新版本	Cloud ❄, VMware vSphere, Bare metal	ODF 4,NetApp Trident 20.04 或更新版本, vSphere 卷 ♣	ODF ¡, NetApp StorageGRID 11.4 或更新版本
3.2	4.6, 4.7, 4.8	RHCOS	RHEL 8.1 或更新版本	Cloud ❄, VMware vSphere, Bare metal	ODF 4,NetApp Trident 20.04 或更新版本, vSphere 卷 ♣	ODF ¡, NetApp StorageGRID 11.4 或更新版本
3.3	4.8, 4.9, 4.10, 4.11, 4.12	RHCOS	RHEL 8.1 或更新版本	Cloud ❄, VMware vSphere, Bare metal	ODF 4,NetApp Trident 20.04 或更新版本, vSphere volumes♣, NFS ♣	ODF ¡, NetApp StorageGRID 11.4 或更新版本

²

OpenShift Kubernetes Engine (OKE)是 OpenShift Container Platform (OCP)的一个可行且受支持的替代品。

❄

云表示 OpenShift Container Platform 支持的任何云提供商。有关测试过的和支持的基设施平台的完整的列表，请参阅 OpenShift Container Platform 4.x 测试过的集成。在这种情况下，云提供商必须提供持久性存储。关于受支持的存储提供商的完整的列表，请参阅 了解持久性存储(4.12) / (4.10)。

♣

此持久性存储提供商不提供 SDI 的检查点存储 所需的受支持的对象存储服务，因此仅适用于 SAP Data Intelligence 开发和 PoC 集群。它需要一个对象存储解决方案的补充，来实现完整的 SDI 功能。

¡

对于完整的功能（包括 SDI 备份和恢复），需要 ODF 4.6.4 或更新版本。或者，可以在为 SDI 备份和恢复(检查点存储)使用 RGW 时使用 ODF 外部模式。

除非另有说明，否则列出的 SDI 版本的兼容性还涵盖其所有补丁版本。

2.2.2.持久性卷

SDI 需要持久性存储。需要使用可以动态创建的存储。您可以在 了解持久性存储(4.12)/ (4.10) 文档中找到更多信息。

2.2.3.容器镜像注册中心

SDI 安装需要一个安全的镜像注册中心，其中镜像首先从 SAP 中心进行镜像，然后再传送到 OpenShift 集群节点。集成的 OpenShift Container Registry (4.12) / (4.10) 不 适合此目的。AWS ECR 注册中心也不适合。目前，需要建立另一个镜像注册中心。

此处列出的要求是 容器注册中心(3.3) / (3.2) / (3.1) 中列出的官方要求的一个子集。

此上下文中的词 安全的 表示通信是使用 TLS 加密的。理想情况下，证书由可信证书颁发机构签名。如果 注册中心也是公开的，则它必须要求身份验证和授权才能拉取 SAP 镜像。

2.2.3.1.已验证的注册中心

1. (推荐) Red Hat Quay 3.6 或更高版本与 SAP Data Intelligence 镜像兼容，并支持用于此目的。Quay 注册中心可以在 OpenShift 集群本身、另一个 OpenShift 集群或独立的集群上运行。如需更多信息，请参阅 用于 SAP DI 的 Quay 注册中心。

2. (已弃用) SDI 注册中心是一个满足要求的社区支持的容器镜像注册中心。如需更多信息，请参阅 部署 SDI 注册中心。

完成后，您应该有一个启动了且运行的外部镜像注册中心。我们将使用 URL local.image.registry:5000 作为一个示例。您可以使用以下命令验证其是否已准备就绪：

\# curl -k https://local.image.registry:5000/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

2.2.4.检查点存储启用

要启用 SAP Vora 数据库流表，需要启用检查点存储。存储是特定存储后端上的一个对象存储。SDI 安装程序支持多种后端类型，它们覆盖大部分存储云提供商。

对于生产环境集群，强烈建议启用。禁用此功能的集群仅适用于测试、开发或 PoC 用例。

确保在 SDI 安装前创建所需的存储桶。如果检查点存储应该驻留在存储桶上的一个目录中，则目录也需要存在。

2.2.5.SDI Observer

是一个监控 SDI 的命名空间，并修改其中的对象，以便在 OpenShift 上运行 SDI 的 Pod 。观察程序应在专用的命名空间中运行。它必须在 SDI 安装启动前部署。SDI Observer 部分将引导您完成部署过程。

3.安装 Red Hat OpenShift Container Platform

3.1.准备管理主机

请注意，已在 RHEL 8.4 上测试了以下内容。对于基于 RPM 的其他 Linux 发行版，步骤应该类似。推荐的是 RHEL 7.7+、Fedora 30+ 和 CentOS 7+。

3.1.1.准备连接的管理主机

1. 至少向以下存储库订阅 管理主机 ：

   
   
   \# OCP_RELEASE=4.12
   # sudo subscription-manager repos                 \
       --enable=rhel-8-for-x86_64-appstream-rpms     \
       --enable=rhel-8-for-x86_64-baseos-rpms        \
       --enable=rhocp-${OCP_RELEASE:-4.12}-for-rhel-8-x86_64-rpms
   

2. 安装 jq 二进制文件。这个安装指南已使用 jq 1.6 进行了测试。

   • 在 RHEL 8 上，确保 rhocp-4.12-for-rhel-8-x86_64-rpms 存储库或新版本被启用了，并从那里安装它：

     
     
     \# dnf install jq-1.6
     

   • 在早期发行本或其他发行版本上，从上游下载二进制文件：

     
     
     \# sudo curl -L -O /usr/local/bin/jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
     
     
     \# sudo chmod a+x /usr/local/bin/jq
     

3. 下载并安装 OpenShift 客户端二进制文件。

   
   
   \# sudo dnf install -y openshift-clients
   

3.1.2.准备断开连接的 RHEL 管理主机

请参阅 KB#3176811 Creating a Local Repository and Sharing With Disconnected/Offline/Air-gapped Systems 和 KB#29269 How can we regularly update a disconnected system (A system without internet connection)?。

从本地 RPM 存储库安装 jq-1.6 和 openshift-clients。

3.2.安装 OpenShift Container Platform

在需要的集群主机上安装 OpenShift Container Platform。按照 OpenShift 安装指南(4.12) / (4.10)

在 SDI 安装之前，需要对运行 SDI 工作负载的计算节点完成几个更改。这包括：

1. 预加载所需的内核模块
2. 增加 CRI-O 容器引擎的 PID 限制

将在下一节中介绍它们。

3.3.OpenShift 安装后步骤

3.3.1. （可选） 安装 OpenShift Data Foundation

Red Hat OpenShift Data Foundation (ODF)已作为 SAP Data Intelligence 的持久性存储提供者被验证了。请参阅 ODF 文档(4.12) / (4.10)

如果您在断开连接的集群上安装，请确保阅读并遵循 断开连接的环境(4.12) / (4.10)。

3.3.2 （可选） 安装 NetApp Trident

已为 SAP Data Intelligence 和 OpenShift 验证了 NetApp Trident 和 StorageGRID 。如需更详细的信息，请参阅 带有 NetApp Trident 的OpenShift 4 上的 SAP Data Intelligence。

3.3.3.配置 SDI 计算节点

一些 SDI 组件需要在计算节点的操作系统级别上有些更改。这会影响在同一集群上运行的其他工作负载。要防止这种情况发生，建议将一组节点专用于 SDI 工作负载。需要完成以下内容：

1. 所选节点必须被标记，如使用 node-role.kubernetes.io/sdi="" 标签。
2. 需要创建特定于 SDI 的 MachineConfig，它们将只被应用到所选节点。
3. 必须创建 MachineConfigPool ，来将所选节点与新创建的 MachineConfig 关联。
   • 在此之前不会对节点进行任何更改
4. （可选） 将节点选择器应用到 sdi、sap-slcbridge 和 datahub-system 项目。
   • 可以使用 SDI_NODE_SELECTOR 参数将 SDI Observer 配置为进行此操作

在修改以下推荐的方法之前，请熟悉机器配置 Operator 的自定义池概念。

3.3.3.1.气隙环境

如果 管理主机 无法访问互联网，您需要将 sap-data-intelligence git 存储库 克隆到其他主机，并使其在 管理主机 上可用。例如：

\# cd /var/run/user/1000/usb-disk/


\

\

\# git clone https://github.com/redhat-sap/sap-data-intelligence

然后，在 管理主机 上：

• 除非本地签出已存在，否则请从磁盘复制它：

  
  
  \# git clone /var/run/user/1000/usb-disk/sap-data-intelligence ~/sap-data-intelligence
  

• 否则，将本地更改（若有的话）重新应用到最新代码：

  
  
  \# cd ~/sap-data-intelligence
  # git stash         # temporarily remove local changes
  
  
  \# git remote add drive /var/run/user/1000/usb-disk/sap-data-intelligence
  
  
  \# git fetch drive
  
  
  \# git merge drive   
  
  \# apply the latest changes from drive to the local checkout
  # git stash pop     # re-apply the local changes on top of the latest code
  

3.3.4.1.为 SAP Data Intelligence 标记计算节点

为 SDI 工作负载选择计算节点，并从 管理主机 标记它们，如下所示：

\# oc label node/sdi-worker{1,2,3} node-role.kubernetes.io/sdi=""

此步骤与 SDI Observer 功能相结合，确保特定命名空间中与 SAP DI 相关的工作负载在标记的节点上运行。SDI Observer 向相关的 SAP DI 命名空间（如 openshift.io/node-selector: node-role.kubernetes.io/sdi=）添加了一个节点选择器注解，它通常包括 SAP DI 命名空间、datahub-system 和 sap-slcbridge 命名空间。

3.3.4.2.预加载所需的内核模块

要将所需的更改应用到现有和未来的 SDI 计算节点，请创建另一个机器配置，如下所示：

• （连接的管理主机）

  
  
  \# oc apply -f https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/snippets/mco/mc-75-worker-sap-data-intelligence.yaml
  

• （断开连接的管理主机）

  
  
  \# oc apply -f sap-data-intelligence/master/snippets/mco/mc-75-worker-sap-data-intelligence.yaml
  

∇

备注 ：如果显示以下警告，则通常可以忽略。它表示资源已在集群上存在，并已由列出的命令之一创建了。在本文档的早期版本中，推荐使用简单的 oc create 。

Warning: oc apply should be used on resource created by either oc create --save-config or oc apply

3.3.4.3.更改每个容器的最大 PID 数

对于 OCP 4.10 和之前的版本，在 SDI 问题单中的 修改节点(4.10) 中描述了配置节点的过程，所需的设置是 ContainerRuntimeConfig 中的 .spec.containerRuntimeConfig.pidsLimit 。结果是每个受影响的 worker 节点上修改后的 /etc/crio/crio.conf 配置文件，pids_limit 设置为所需的值。请创建一个 ContainerRuntimeConfig，如下所示：

• （连接的管理主机）

  
  
  \# oc apply -f https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/snippets/mco/ctrcfg-sdi-pids-limit.yaml
  

• （断开连接的管理主机）

  
  
  \# oc apply -f sap-data-intelligence/master/snippets/mco/ctrcfg-sdi-pids-limit.yaml
  

从 OCP 4.11 开始，CRI-O 中的配置已弃用，取而代之的是 KubeletConfig 中的配置，默认的 podPidsLimit 变为 4096。配置节点的过程在 修改节点(4.12) 中进行了描述。在 SDI 的情况，我们需要增加 KubeletConfig 中的 pids_limit。结果是每个受影响的 worker 节点上修改后的 /etc/kubernetes/kubelet.conf 配置文件，pids_limit 设置为所需的值。请创建一个 ContainerRuntimeConfig，如下所示：

• （连接的管理主机）

  
  
  \# oc apply -f https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/snippets/mco/kubeletconfig-sdi-pids-limit.yaml
  

• （断开连接的管理主机）

  
  
  \# oc apply -f sap-data-intelligence/master/snippets/mco/kubeletconfig-sdi-pids-limit.yaml
  

3.3.4.4.将 MachineConfig 与节点关联

定义一个将 MachineConfig 与节点关联的新的 MachineConfigPool。节点将继承以 worker 和 sdi 角色为目标的所有 MachineConfig。

• （连接的管理主机）

  
  
  \# oc apply -f https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/snippets/mco/mcp-sdi.yaml
  

• （断开连接的管理主机）

  
  
  \# oc apply -f sap-data-intelligence/master/snippets/mco/mcp-sdi.yaml
  

请注意，如果 MCO 已存在，您可能会看到一条警告 ∇ 。

更改将呈现为 machineconfigpool/sdi。worker 将逐个重启，直到更改应用到所有 worker。如需更多信息，请参阅 向集群(4.12) / (4.10) 应用配置更改。

以下命令可用来等待，直到更改应用到所有 worker 节点：

\# oc wait mcp/sdi --all --for=condition=updated

执行上述更改后，您最终应该为所选节点分配了一个新角色 sdi ，以及一个包含节点的新 MachineConfigPool：

\# oc get nodes
NAME          STATUS   ROLES        AGE   VERSION
ocs-worker1   Ready    worker       32d   v1.19.0+9f84db3
ocs-worker2   Ready    worker       32d   v1.19.0+9f84db3
ocs-worker3   Ready    worker       32d   v1.19.0+9f84db3
sdi-worker1   Ready    sdi,worker   32d   v1.19.0+9f84db3
sdi-worker2   Ready    sdi,worker   32d   v1.19.0+9f84db3
sdi-worker3   Ready    sdi,worker   32d   v1.19.0+9f84db3
master1       Ready    master       32d   v1.19.0+9f84db3
master2       Ready    master       32d   v1.19.0+9f84db3
master3       Ready    master       32d   v1.19.0+9f84db3



\# oc get mcp
NAME     CONFIG                 UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADED
master   rendered-master-15f⋯   True     False     False     3             3                  3                    0
sdi      rendered-sdi-f4f⋯      True     False     False     3             3                  3                    0
worker   rendered-worker-181⋯   True     False     False     3             3                  3                    0

3.3.4.4.1.在控制平面上启用 SDI

如果控制平面（或主节点）应该用于运行 SDI 工作负载，除了上一步外，还需要执行以下操作：

1. 请确保 控制平面是可调度的

2. 为主节点复制机器配置：

   
   
   \# oc get -o json mc -l machineconfiguration.openshift.io/role=sdi | jq  '.items[] |
       select((.metadata.annotations//{}) |
           has("machineconfiguration.openshift.io/generated-by-controller-version") | not) |
       .metadata |= ( .name   |= sub("^(?<i>(\\d+-)*)(worker-)?"; "\(.i)master-") |
                      .labels |= {"machineconfiguration.openshift.io/role": "master"} )' | oc apply -f -
   

   请注意，如果之前已经完成此操作，您可能会看到一些警告 ∇。

3. 使主机器配置池继承 PID 限制更改：

   
   
   \# oc label mcp/master workload=sapdataintelligence
   

以下命令可用来等待，直到更改应用到所有 worker 节点：

\# oc wait mcp/master --all --for=condition=updated

3.3.4.6.节点配置的验证

以下步骤假设 node-role.kubernetes.io/sdi="" 标签已应用到运行 SDI 工作负载的节点。所有命令都应该在 管理主机 上执行。所有诊断命令将在这样的节点上并行运行。

1. （仅限断开连接的环境） 使其中一个工具镜像可供集群使用：

   • 使用镜像流 openshift/tools：

     1. 确保镜像流已填充：

        
        
        \# oc get -n openshift istag/tools:latest
        

        输出示例：

        NAME           IMAGE REFERENCE                                                UPDATED
        tools:latest   quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:13c...   17 hours ago
        

        否则，确保您的 注册中心镜像 CA 证书是可信的。

     2. 设置以下变量：

        
        
        \# ocDebugArgs="--image-stream=openshift/tools:latest"
        

   • 或者在本地注册中心提供 registry.redhat.io/rhel8/support-tools 镜像：

     
     
     \# LOCAL_REGISTRY=local.image.registry:5000
     
     
     \# podman login registry.redhat.io
     # podman login "$LOCAL_REGISTRY"    # if the local registry requires authentication
     
     
     \# skopeo copy --remove-signatures \
         docker://registry.redhat.io/rhel8/support-tools:latest \
         docker://"$LOCAL_REGISTRY/rhel8/support-tools:latest"
     
     
     \# ocDebugArgs="--image=$LOCAL_REGISTRY/rhel8/support-tools:latest"
     

2. 验证 PID 限制是否已增加到 16384：

对于 OCP 4.10 及之前的版本，请检查是否已在运行应用程序容器的节点上设置了 CRI-O pids_limit ：

    

\

\

\# oc get nodes -l node-role.kubernetes.io/sdi= -o name | \
        xargs -P 6 -n 1 -i oc debug $ocDebugArgs {} -- chroot /host /bin/bash -c \
            "crio-status config | awk '/pids_limit/ {
                print ENVIRON[\"HOSTNAME\"]\":\t\"\$0}'" |& grep pids_limit

请注意 ：仅在断开连接的环境中设置 $ocDebugArgs ，否则它应该为空。

输出示例类似如下：

    sdi-worker3:    pids_limit = 16384
    sdi-worker1:    pids_limit = 16384
    sdi-worker2:    pids_limit = 16384

对于 OCP 4.11 及之后的版本，请运行以下命令来检查是否在 /etc/kubernetes/kubelet.conf 中设置了 kubelet podPidsLimit ：

    

\

\

\# oc get nodes -l node-role.kubernetes.io/sdi= -o name | \
        xargs -P 6 -n 1 -i oc debug $ocDebugArgs {} -- chroot /host /bin/bash -c \
            "cat /etc/kubernetes/kubelet.conf" | jq '.podPidsLimit'

2. 验证内核模块是否已载入：

   
   
   \
   
   \
   
   \# oc get nodes -l node-role.kubernetes.io/sdi= -o name | \
       xargs -P 6 -n 1 -i oc debug $ocDebugArgs {} -- chroot /host /bin/sh -c \
           "lsmod | awk 'BEGIN {ORS=\":\t\"; print ENVIRON[\"HOSTNAME\"]; ORS=\",\"}
               /^(nfs|ip_tables|iptable_nat|[^[:space:]]+(REDIRECT|owner|filter))/ {
                   print \$1
               }'; echo" 2>/dev/null
   

   输出示例类似如下：

   sdi-worker2:  iptable_filter,iptable_nat,xt_owner,xt_REDIRECT,nfsv4,nfs,nfsd,nfs_acl,ip_tables,
   sdi-worker3:  iptable_filter,iptable_nat,xt_owner,xt_REDIRECT,nfsv4,nfs,nfsd,nfs_acl,ip_tables,
   sdi-worker1:  iptable_filter,iptable_nat,xt_owner,xt_REDIRECT,nfsv4,nfs,nfsd,nfs_acl,ip_tables,
   

   如果任何 SDI 节点上都缺少以下模块，则模块加载无法正常工作：iptable_nat、nfsv4、nfsd ip_tables。 xt_owner

   要进一步调试缺少的模块，您也可以执行以下命令：

   
   
   \
   
   \
   
   \# oc get nodes -l node-role.kubernetes.io/sdi= -o name | \
       xargs -P 6 -n 1 -i oc debug $ocDebugArgs {} -- chroot /host /bin/bash -c \
            "( for service in {sdi-modules-load,systemd-modules-load}.service; do \
                printf '%s:\t%s\n' \$service \$(systemctl is-active \$service); \
            done; find /etc/modules-load.d -type f \
                -regex '.*\(sap\|sdi\)[^/]+\.conf\$' -printf '%p\n';) | \
            awk '{print ENVIRON[\"HOSTNAME\"]\":\t\"\$0}'" 2>/dev/null
   

   请确保 systemd 服务都处于 active 状态，且至少为每个主机列出了一个 *.conf 文件，如以下输出示例中所示：

   sdi-worker3:  sdi-modules-load.service:       active
   sdi-worker3:  systemd-modules-load.service:   active
   sdi-worker3:  /etc/modules-load.d/sdi-dependencies.conf
   sdi-worker1:  sdi-modules-load.service:       active
   sdi-worker1:  systemd-modules-load.service:   active
   sdi-worker1:  /etc/modules-load.d/sdi-dependencies.conf
   sdi-worker2:  sdi-modules-load.service:       active
   sdi-worker2:  systemd-modules-load.service:   active
   sdi-worker2:  /etc/modules-load.d/sdi-dependencies.conf
   

3.3.5.部署持久性存储提供商

除非您的平台已提供了受支持的持久性存储提供商，否则需要部署一个。如需了解可能的选项的概述，请参阅 理解持久性存储(4.12) / (4.10)。

在 OpenShift 上，可以在 OpenShift 节点上部署聚合运行的 OpenShift Data Foundation (ODF) (4.12) / (4.10)，来提供持久性卷和对象存储。如需更多信息和安装说明，请参阅 ODF 规划您的部署(4.12) / (4.10) 和 部署 OpenShift Data Foundation (4.12) / (4.10)。

也可以在断开连接的环境中部署(4.12) / 4.10 中部署 ODF 。

对于基于 NFS 的持久性存储，动态存储配置方法是一个先决条件。请参阅以下文章，以了解有关"如何在 OpenShift 环境中为 NFS 动态存储配置创建一个存储类？"的详细信息

3.3.6.配置 S3 访问和存储桶

SDI 的以下功能需要对象存储：

• 提供 SDI 服务数据的定期备份的 备份&恢复 (以前的检查点存储)功能
• 用于机器学习场景的 SDL Data Lake 连接(3.3) / (3.2) / (3.1)

SDI 支持到对象存储的多个接口。S3 接口是其中之一。请查阅 所需的输入参数(3.3) / (3.2) / (3.1) 处的检查点存储，以获取完整列表。SAP 帮助页 涵盖了对象存储的准备(3.3) / (3.2) / (3.1)。

可针对 ODF NooBaa 的 S3 端点启用备份&恢复，只要 ODF 是 4.6.4 或更新版本，或者在外部模式下部署 ODF 时针对 RADOS 对象网关 S3 端点启用备份&恢复。

3.3.6.1.使用 NooBaa 或 RADOS 对象网关 S3 端点作为对象存储

ODF 包含 用于混合和多云环境的 NooBaa 对象数据服务，它提供了可与 SAP Data Intelligence 一起使用的 S3 API 。从 ODF 版本 4.6.4 开始，它也可用于 SDI 的 备份&恢复功能。另外，也可以针对 RADOS 对象网关 S3 端点启用功能（从现在起只是 RGW），当 ODF 在 外部模式(4.12) / (4.10) 下部署时，该功能可用。

对于 SDI，需要提供以下内容：

• 带有 https:// 或 http:// 前缀的 S3 主机 URL
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• 存储桶名称

备注 ：如果是 https://，端点必须由可信证书颁发机构签名的证书进行保护。截止到目前，自签名 CA 还不能开箱即用。

部署 ODF 后，可以使用以下方法之一创建访问密钥和存储桶：

• （仅限内部模式） 默认情况下通过 NooBaa 管理控制台在 noobaa-mgmt-openshift-storage.apps.. 处公开
• （内部和外部模式） 通过 CLI 使用 mksdibuckets 脚本

在这两种情况下，截止到目前，提供给 SAP Data Intelligence 的 S3 端点无法使用自签名证书进行保护。除非端点使用合适的签名证书进行了保护，否则必须使用不安全的 HTTP 连接。NooBaa 和 RGW 都有可以从集群内部(在 SDN 内)访问的这样一种不安全服务，除非 通过例如路由 公开，否则无法从集群外解析。

以下两个 URL 是部署了 ODF 的 OpenShift 集群上的示例端点。

1. http://s3.openshift-storage.svc.cluster.local - NooBaa S3 端点始终可用
2. http://rook-ceph-rgw-ocs-external-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local:8080 - 当在外部模式下部署 ODF 时，应该最好使用 RGW 端点

3.3.6.1.1.使用 CLI 创建 S3 存储桶

可以通过从 管理主机 执行以下命令来创建存储桶。在执行以下命令或向其附加参数 -n SDI_NAMESPACE 之前，请务必先切换到合适的项目/命名空间（例如 sdi）。

• （连接的管理主机）

  
  
  \# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/mksdibuckets)
  

• （断开连接的管理主机）

  
  
  \# bash sap-data-intelligence/master/utils/mksdibuckets
  

默认情况下，将创建两个存储桶。您可以以这种方式列出它们：

• （连接的管理主机）

  
  
  \
  
  \# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/mksdibuckets) list
  

• （断开连接的管理主机）

  
  
  \
  
  \# bash sap-data-intelligence/master/utils/mksdibuckets list
  

输出示例：

Bucket claim namespace/name:  sdi/sdi-checkpoint-store  (Status: Bound, Age: 7m33s)
  Cluster internal URL:       http://s3.openshift-storage.svc.cluster.local
  Bucket name:                sdi-checkpoint-store-ef4999e0-2d89-4900-9352-b1e1e7b361d9
  AWS_ACCESS_KEY_ID:          LQ7YciYTw8UlDLPi83MO
  AWS_SECRET_ACCESS_KEY:      8QY8j1U4Ts3RO4rERXCHGWGIhjzr0SxtlXc2xbtE
Bucket claim namespace/name:  sdi/sdi-data-lake  (Status: Bound, Age: 7m33s)
  Cluster internal URL:       http://s3.openshift-storage.svc.cluster.local
  Bucket name:                sdi-data-lake-f86a7e6e-27fb-4656-98cf-298a572f74f3
  AWS_ACCESS_KEY_ID:          cOxfi4hQhGFW54WFqP3R
  AWS_SECRET_ACCESS_KEY:      rIlvpcZXnonJvjn6aAhBOT/Yr+F7wdJNeLDBh231



\# 

\# NOTE: for more information and options, run the command with --help

上面的例子使用 ODF NooBaa 的 S3 端点，该端点始终是 ODF 内部模式的首选。

声明 sdi-checkpoint-store 的值应该在 SDI 安装期间传递给以下 SLC Bridge 参数，以便启用备份&恢复（以前称为）检查点存储功能。

参数	示例值
对象存储类型	S3 compatible object store
访问密钥	LQ7YciYTw8UlDLPi83MO
Secret 密钥	8QY8j1U4Ts3RO4rERXCHGWGIhjzr0SxtlXc2xbtE
端点	http://s3.openshift-storage.svc.cluster.local
路径	sdi-checkpoint-store-ef4999e0-2d89-4900-9352-b1e1e7b361d9
禁用证书验证	是

3.3.6.1.2.增加对象存储桶限制

注意 ：仅适用于 RGW (ODF 外部模式)

当在 SDI 安装过程中执行检查点存储验证时，安装程序将创建一个临时存储桶。要使其与 RGW 一起工作，需要增加存储桶的所有者对最大可分配存储桶的限制。限制默认设置为 1。

您可以使用以下命令对分配给备份&恢复(检查点存储)的存储桶执行所需的更改。请在外部 Red Hat Ceph Storage 集群的管理节点上执行（或在运行外部 RGW 服务的主机上）。最后一个参数是 "Bucket name"，不是 "Bucket claim name"。

• （连接的管理主机）

  
  
  \# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/rgwtunebuckets) \
          sdi-checkpoint-store-ef4999e0-2d89-4900-9352-b1e1e7b361d9
  

• （断开连接的管理主机）

  
  
  \# bash sap-data-intelligence/master/utils/rgwtunebuckets \
          sdi-checkpoint-store-ef4999e0-2d89-4900-9352-b1e1e7b361d9
  

如需更多信息和附加选项，请在末尾附加 --help 参数。

3.3.7.设置容器镜像注册中心

如果您还没有这样做，请按照 容器镜像注册中心先决条件 操作。

备注 ：现在，需要使用 TLS 为 SDI 保护的注册中心。纯 HTTP 将不会这样做。

如果注册中心是由合适的可信（不是自签名）证书签名的，则可以跳过此项。

有两种方式使 OpenShift 使用自签名证书颁发机构签名的证书信任其它注册中心：

• （推荐） 更新 OpenShift 镜像配置中的 CA 证书信任。
• （不太安全） 将注册中心标记为不安全

3.3.8.为 SDI 配置 OpenShift 集群

3.3.8.1.成为 cluster-admin

以下的许多命令都需要 集群 admin 特权。要成为 cluster-admin，您可以执行以下操作之一：

• 在安装 OpenShift 集群期间，使用在工作目录中产生的 auth/kubeconfig ：

  INFO Install complete!
  INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
  INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
  INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
  INFO Login to the console with user: kubeadmin, password: <provided>
  
  
  \# export KUBECONFIG=working_directory/auth/kubeconfig
  
  
  \# oc whoami
  system:admin
  

• 以 system:admin 用户身份或 cluster-admin 组的成员身份，使另一个用户成为集群 admin，以允许其执行 SDI 安装：

  1. 作为 cluster-admin ，配置身份验证(4.12) / (4.10) ，并添加所需的用户（如 sdiadmin）。

  2. 以 cluster-admin 身份，授予用户管理集群的权限：

     
     
     \# oc adm policy add-cluster-role-to-user cluster-admin sdiadmin
     

您可以在 集群角色和本地角色文章(4.12) / (4.10) 中了解更多有关 cluster-admin 角色的信息

4.SDI Observer

SDI Observer 监控 SDI 和 SLC 网桥命名空间，并对 SDI 部署应用更改，以允许 SDI 在 OpenShift 上运行。另外，它执行以下操作：

• 向 vsystem-vrep StatefulSet 添加额外的持久性卷，以允许它在 RHCOS 系统上运行
• 向日志授予 fluentd pod 权限
• 重新配置 fluentd pod，以解析 OpenShift 4 节点上的纯文本文件容器日志
• 公开 SDI 系统管理服务
• 公开 SLC 网桥服务
• （可选） 部署适合镜像、存储和服务 SDI 镜像的 SDI 注册中心，并由 Pipeline Modeler 使用
• （可选） 创建 cmcertificates secret ，以允许 SDI 在安装过程中与由自签名 CA 证书保护的容器镜像注册中心进行通信

它被部署为 OpenShift 模板。其行为由模板的参数控制，这些参数被镜像为其环境变量。

在其自己的 k8s 命名空间中部署 SDI Observer （如 sdi-observer）。有关当前尝试解决的问题的完整列表，请参阅 其文档。

4.1.先决条件

在部署 SDI Observer 前，必须满足以下条件：

• OpenShift 集群必须健康，包括所有集群 operator。
• OpenShift 集成的镜像注册中心(4.12) / (4.10) 必须可以被正确配置且正常工作。

4.2.1.连接的 OpenShift 集群的先决条件

要构建 SDI Observer 需要的镜像，需要在 SDI Observer 命名空间中为 registry.redhat.io 创建一个带有凭证的 secret。要获取 OpenShift secret，请访问 红帽注册中心服务账号 。如需了解更多详细信息，请参阅 红帽容器注册中心身份验证。我们将把文件称为 rht-registry-secret.yaml。下面将介绍导入到 OpenShift 集群。

4.2.2.断开连接的 OpenShift 集群的先决条件

在断开连接的 OpenShift 集群上，需要将 SDI Observer 的预构建镜像镜像到本地容器镜像注册中心。请按照 断开连接的 OpenShift 集群说明 进行操作。

4.2.3.Observer 的模板的实例化

假设 SDI 将在 SDI_NAMESPACE 中运行，它与 observer NAMESPACE 不同，使用默认的参数对模板进行实例化，如下所示：

1. 根据您系统的连接性准备脚本和镜像。

   • 在连接的环境中，从 git 存储库下载 run 脚本，如下所示：

     
     
     \
     
     \# curl -O https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/observer/run-observer-template.sh
     

   • 在断开连接的环境中，管理主机 是 连接的 。

     将 SDI Observer 镜像镜像到本地注册中心。例如，在 RHEL8 上：

     # podman login local.image.registry:5000    # if the local registry requires authentication
     
     
     \
     
     \
     
     \
     
     \# skopeo copy \
         docker://quay.io/redhat-sap-cop/sdi-observer:latest-ocp4.12 \
         docker://local.image.registry:5000/sdi-observer:latest-ocp4.12
     

     请确保根据 OpenShift 服务器次版本修改 4.12 后缀。

   • 在气隙环境中（假设 observer 存储库已克隆到 管理主机）：

     1. 在可以访问互联网的主机上，将 SDI Observer 镜像复制到 USB 驱动器上的一个存档中。例如，在 RHEL8 上：

        
        
        \
        
        \
        
        \
        
        \# skopeo copy \
            docker://quay.io/redhat-sap-cop/sdi-observer:latest-ocp4.12 \
            oci-archive:/var/run/user/1000/usb-disk/sdi-observer.tar:latest-ocp4.12
        

     2. 将 USB 驱动器插入到 管理主机（没有互联网访问），并将其中的镜像镜像到您的 local.image.registry:5000 ：

        
        
        \
        
        \
        
        \
        
        \# skopeo copy \
            oci-archive:/var/run/user/1000/usb-disk/sdi-observer.tar:latest-ocp4.12 \
            docker://local.image.registry:5000/sdi-observer:latest-ocp4.12
        

2. 在您首选的编辑器中编辑下载的 run-observer-template.sh 文件。特别是，注意 FLAVOUR、NAMESPACE 和 SDI_NAMESPACE 参数。

   • 对于 ubi-build flavour，确保设置 之前 下载的 REDHAT_REGISTRY_SECRET_PATH=to/your/rht-registry-secret.yaml
   • 对于断开连接的环境，请确保将 FLAVOUR 设置为 ocp-prebuilt，将 IMAGE_PULL_SPEC 设置为您的 local.image.registry:5000
   • 对于气隙环境，还要设置 SDI_OBSERVER_REPOSITORY=to/local/git/repo/checkout

3. 在 bash 中运行它，如下所示：

   
   
   \
   
   \# bash ./run-observer-template.sh
   

4. 保留修改后的脚本以备更新。

4.2.4.（可选） SDI Observer 注册中心

备注：SDI Observer 只能选择性地在 连接的 OpenShift 集群上部署 SDI 注册中心。对于 断开连接的 环境，请参阅 断开连接的环境的通用实例化。

如果 observer 被配置为通过 DEPLOY_SDI_REGISTRY=true 参数部署 SDI 注册中心，则它将部署 deploy-registry 作业，该作业执行以下操作：

1. (仅连接的)构建 container-image-registry 镜像，并将其推送到集成的 OpenShift 镜像注册中心
2. 生成或使用为注册中心配置的凭证
3. 部署 container-image-registry 部署配置，其反过来部署相应的 pod

4. 使用路由公开注册中心

   • 如果设置了 observer 的 SDI_REGISTRY_ROUTE_HOSTNAME 参数，它将被用作其主机名
   • 否则，注册中心的主机名将是 container-image-registry-${NAMESPACE}.apps..

4.2.4.1.SDI 注册中心模板参数

以下 Observer 的模板参数会影响 SDI 注册中心的部署：

参数	示例值	描述
DEPLOY_SDI_REGISTRY	true	是否出于 SAP Data Intelligence 的目的而部署 SDI 注册中心。
REDHAT_REGISTRY_SECRET_NAME	123456-username-pull-secret	带有 registry.redhat.io registry 的凭证的 secret 的名称。请访问 红帽注册中心服务账户 来获取 OpenShift secret。如需了解更多详细信息，请参阅 红帽容器注册中心身份验证。必须提供，以构建注册中心的镜像。
SDI_REGISTRY_ROUTE_HOSTNAME	registry.cluster.tld	此变量在创建相应的路由时将用作 SDI 注册中心的主机名。默认为 container-image-registry-$NAMESPACE..。如果设置了，域名必须解析为入口路由器的 IP。
INJECT_CABUNDLE	true	将 CA 证书捆绑到 SAP Data Intelligence pod。可以使用 CABUNDLE_SECRET_NAME 指定捆绑包。如果注册中心是由自签名证书保护的，则需要它。
CABUNDLE_SECRET_NAME	custom-ca-bundle	包含应注入到 Data Intelligence pod 的证书颁发机构捆绑包的 secret 的名称。默认情况下，secret 捆绑包从 openshift-ingress-operator 命名空间获取，其中 router-ca secret 包含用于签名所有边缘和重新加密路由的证书颁发机构，这些路由主要用于 SDI_REGISTRY 和 S3 API 服务。secret 名称可以选择 $namespace/ 前缀。
SDI_REGISTRY_STORAGE_CLASS_NAME	ocs-storagecluster-cephfs	除非指定，否则将使用默认的存储类。如果可能，首选带有 ReadWriteMany(RWX)访问模式的卷。
REPLACE_SECRETS	true	默认情况下，如果已存在，现有的 SDI_REGISTRY_HTPASSWD_SECRET_NAME secret 将不会被替换。如果在使用相同的 secret 名称时应该更改注册中心凭证，则必须将其设置为 true。
SDI_REGISTRY_AUTHENTICATION	none	如果注册中心不需要任何验证，则设置为 none。默认是保护带有 htpasswd 文件的注册中心，如果注册中心是公开提供的（例如，通过全局可解析的入口路由公开时），则这是必须的。
SDI_REGISTRY_USERNAME	registry-user	将用于生成 htpasswd 文件，以便向 sdi注册中心服务提供身份验证数据，只要 SDI_REGISTRY_HTPASSWD_SECRET_NAME 不存在或者 REPLACE_SECRETS 为 true。除非指定，否则它将由作业自动生成。
SDI_REGISTRY_PASSWORD	secure-password	ditto
SDI_REGISTRY_HTPASSWD_SECRET_NAME	registry-htpasswd	具有 htpasswd 文件的机密，其中包含 sdi 镜像容器的身份验证数据。如果指定了，且secret 存在，则会使用它，而不是 SDI_REGISTRY_USERNAME 和 SDI_REGISTRY_PASSWORD。默认为 container-image-registry-htpasswd。请确保遵循 生成 htpasswd 文件的官方指南。
SDI_REGISTRY_VOLUME_CAPACITY	250Gi	为容器镜像提供的卷空间。默认为 120Gi。
SDI_REGISTRY_VOLUME_ACCESS_MODE	ReadWriteMany	如果给定了 SDI_REGISTRY_STORAGE_CLASS_NAME 或默认存储类支持 ReadWriteMany("RWX")访问模式，请把它改为 ReadWriteMany。例如：由 ODF operator 部署的 ocs-storagecluster-cephfs 存储类确实支持它。

要使用它们，请在 上述部分 的 run-observer-template.sh 脚本中设置所需的参数。

监控注册中心的部署

\# oc logs -n "${NAMESPACE:-sdi-observer}" -f job/deploy-registry

您可以在附录中找到更多信息：
- 更新说明
- 确定注册中心的凭证
- 验证

4.3.管理 SDI Observer

4.3.1.查看和更改当前配置

查看 SDI Observer 的当前配置：

\# oc set env --list -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer

更改设置：

• 建议您修改 run-observer-template.sh ，并重新运行它

• 还可以在不触发镜像构建的情况下直接设置所需的参数：

  
  
  \# 
  
  \# instruct the observer to schedule SDI pods only on the matching nodes
  
  
  \# oc set env -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer SDI_NODE_SELECTOR="node-role.kubernetes.io/sdi="
  

4.3.2.重新部署 SDI Observer

在以下情况下很有用：

• SDI Observer 将被更新至最新版本。
• SDI 已被卸载，其命名空间已删除和/或重新创建。
• 在多个资源（不仅仅是在 DeploymentConfig 中）中反映的参数需要更改（例如 OCP_MINOR_RELEASE）
• 应该观察其他命名空间中的不同的 SDI 实例。

在更新到最新的 SDI Observer 代码前，请务必检查 更新说明。

备注 ：重新部署会保留生成的 secret 和持久性卷，除非 REPLACE_SECRETS 或 REPLACE_PERSISTENT_VOLUMES 是 true。

1. 备份之前的 run-observer-template.sh 脚本，并在可用前打开它。如果不可用，请运行以下命令来查看之前的环境变量：

   
   
   \# oc set env --list dc/sdi-observer -n "${NAMESPACE:-sdi-observer}"
   

2. 从 git 存储库下载 run 脚本，如下所示：

   
   
   \
   
   \# curl -O https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/observer/run-observer-template.sh
   

3. 在您首选的编辑器中编辑下载的 run-observer-template.sh 文件。特别是，请注意 FLAVOUR、NAMESPACE、SDI_NAMESPACE 和 OCP_MINOR_RELEASE 参数。将其与旧的 run-observer-template.sh 或 oc set env --list dc/sdi-observer 的输出进行比较，并相应地更新参数。

4. 在 bash 中运行它，如下所示：

   
   
   \
   
   \# bash ./run-observer-template.sh
   

5. 保留修改后的脚本以备更新。

5.在 OpenShift 上安装 SDI

5.1.安装软件生命周期容器网桥

请按照 官方文档(3.3)/ / (3.2) / (3.1) 操作。

5.1.1.重要的参数

参数	条件	描述
模式	总是	确保选择 Expert 模式。
容器镜像存储库的地址	总是	如果注册中心是由 SDI Observer 部署的，则这是 observer 命名空间中 container-image-registry 路由的 Host 值。
镜像注册中心用户名	if … ‡	请参阅注册中心配置。如果使用 SDI 注册中心，请遵循 决定注册中心的凭证。
镜像注册中心密码	if … ‡	ditto
SLC 网桥的命名空间	总是	如果您覆盖默认值(sap-slcbridge)，请确保使用相应的 SLCB_NAMESPACE 值 部署 SDI Observer。
服务类型	SLC 网桥基础安装	在 vSphere 上，确保使用 NodePort。在 AWS 上，请使用 LoadBalancer。
集群没有代理	与 HTTPS 代理值一起需要	请确保按照 为 SLC 网桥配置 HTTP 代理 部分来操作。

‡

如果注册中心需要身份验证。Red Hat Quay 或 SDI 注册中心 需要。

如需了解更多详细信息，请参阅 配置集群范围的代理(4.12) / 4.10

在 NAT 内部集群上，为了访问 slcbridgebase-service NodePort 服务，需要有直接访问一个 SDI 计算节点的权限，或者修改外部负载均衡器，来向服务添加额外的路由。

5.1.2.安装 SLC 网桥

请根据 使 SLC 网桥基础在 Kubernetes 上可用(3.3) / (3.2) / (3.1) ，来安装 SLC 网桥，同时注意对 安装参数 的备注。

5.1.2.1.使用 OpenShift 入口控制器公开 SLC 网桥

对于 SLC 网桥，唯一可能的 TLS 终止类型是 passthrough，除非入口控制器被配置为使用全局信任的证书。

建议让 SDI Observer （至少 0.1.15）管理路由创建或更新。如果 SDI Observer 已使用 MANAGE_SLCB_ROUTE=true 部署了，可以跳过本节。要配置它，请执行以下操作：

\# oc set env -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer MANAGE_SLCB_ROUTE=true


\# 

\# wait for the observer to get re-deployed


\

\

\

\# oc rollout status -n "${NAMESPACE:-sdi-observer}" -w dc/sdi-observer

不久之后，网桥将在 https://sap-slcbridge.apps../docs/index.html 上可用。您可以等待路由的可用性，如下所示：

\

\

\

\# oc get route -w -n "${SLCB_NAMESPACE:-sap-slcbridge}"
NAME            HOST/PORT                                         PATH   SERVICES                PORT    TERMINATION            WILDCARD
sap-slcbridge   <SLCB_NAMESPACE>.apps.<cluster_name>.<base_domain>       slcbridgebase-service   <all>   passthrough/Redirect   None

5.1.2.1.1.手动公开带有入口的 SLC 网桥

或者，您可以使用此方法手动公开 SLC 网桥。

1. 查找 slcbridgebase-service 服务：

   # oc project "${SLCB_NAMESPACE:-sap-slcbridge}"            # switch to the Software Lifecycle Bridge project
   
   
   \# oc get services | grep 'NAME\|slcbridge'
   NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
   slcbridgebase-service   NodePort    172.30.206.105   <none>        32455:31477/TCP   14d
   

2. 为服务创建路由：

   
   
   \# oc create route passthrough sap-slcbridge --service=slcbridgebase-service \
       --insecure-policy=Redirect --dry-run=client -o json | \
       oc annotate --local -f - haproxy.router.openshift.io/timeout=10m -o json | oc apply -f -
   

   您也可以使用 --hostname 参数设置所需的主机名。确保它解析为路由器的 IP。

3. 获取生成的主机名：

   
   
   \
   
   \
   
   \# oc get route
   NAME      HOST/PORT                                                  PATH  SERVICES  PORT      TERMINATION           WILDCARD
   vsystem   vsystem-<SDI_NAMESPACE>.apps.<cluster_name>.<base_domain>        vsystem   vsystem   passthrough/Redirect  None
   

4. 确保配置外部负载均衡器，以将此特定主机名的 WebSocket 连接的超时时间至少增加到 10 分钟。例如，在 HAProxy 中，它是 timeout tunnel 10m。

5. 访问位于 https://vsystem-.apps.. 的系统管理服务，以进行验证。

5.1.2.2.使用外部负载均衡器访问 SLC 网桥的 NodePort

注意 ：仅在"Service Type"被设置为"NodePort"时才适用。

部署 SLC 网桥后，应确定其 NodePort ，以指向负载均衡器。

\# oc get svc -n "${SLCB_NAMESPACE:-sap-slcbridge}" slcbridgebase-service -o jsonpath='{.spec.ports[0].nodePort}{"\n"}'
31875

负载平衡器应指向运行 SDI 工作负载的所有计算节点。以下是 HAProxy 负载均衡器的一个示例：

\# 

\# in the example, the <cluster_name> is "boston" and <base_domain> is "ocp.vslen"


\# cat /etc/haproxy/haproxy.cfg
....
frontend        slcb
    bind        *:9000
    mode        tcp
    option      tcplog
    # # commented blocks are useful for multiple OpenShift clusters or multiple SLC Bridge services
    #tcp-request inspect-delay      5s
    #tcp-request content accept     if { req_ssl_hello_type 1 }

    use_backend  boston-slcb       #if { req_ssl_sni -m end -i boston.ocp.vslen  }
    #use_backend raleigh-slcb      #if { req_ssl_sni -m end -i raleigh.ocp.vslen }

backend         boston-slcb
    balance     source
    mode        tcp
    server      sdi-worker1        sdi-worker1.boston.ocp.vslen:31875   check
    server      sdi-worker2        sdi-worker2.boston.ocp.vslen:31875   check
    server      sdi-worker3        sdi-worker3.boston.ocp.vslen:31875   check

backend         raleigh-slcb
....

然后可以在 URL https://boston.ocp.vslen:9000/docs/index.html 访问 SLC 网桥，只要 boston.ocp.vslen 可以正确解析为负载均衡器的 IP。

5.2.SDI 安装参数

请按照有关配置 SDI 的 SAP 的指南，同时注意以下附加的注释：

名称	条件	建议
Kubernetes 命名空间	总是	必须与 项目设置 中所选的项目名称匹配（例如 sdi）
安装类型	安装或更新	如果您需要指定是否选择特定的存储类，或者是否没有 默认的存储类(4.12) / 4.10 集合，或者您要在同一集群上部署多个 SDI 实例，请选择 Advanced Installation。
容器镜像存储库	安装	必须设置为 容器镜像注册中心。
集群代理设置	高级安装或更新	如果必须使用本地 HTTP (S)代理来访问外部 Web 资源，请选择 yes。
集群没有代理	当配置了 Cluster Proxy Settings 时。	请参阅 HTTP 代理配置。
备份配置	从没有启用备份的系统安装或升级	对于生产环境，请选择 yes。⁴
检查点存储配置	安装	建议用于生产环境部署。如果启用了备份，则它默认被启用。
检查点存储类型	如果启用了 检查点存储配置 参数。	如果作为对象存储用于 ODF 或 NetApp StorageGRID ，则设置为 S3 兼容对象存储。如需了解更多详细信息，请参阅 使用 NooBaa 作为对象存储网关 或 NetApp StorageGRID。
禁用证书验证	如果启用了 检查点存储配置 参数。	如果对有自签名 CA 的证书保护的对象存储端点使用 HTTPS ，请选择 yes。对于 ODF NooBaa，您可以将其设置为 no。
检查点存储验证	安装	请确保在安装过程中验证连接。否则，如果提供了不正确的值，安装将在稍后失败。
Pipeline Modeler 的容器注册中心设置	高级安装	如果将同一注册中心用于多个 SAP Data Intelligence 实例，则应进行更改。另一个 或不同的 或两者都可以。
StorageClass 配置	高级安装	如果要为不同的 SDI 组件选择不同的动态存储置备程序，或者没有 默认的存储类(4.12)/ / (4.10) 集合，或者您想为 SDI 组件选择非默认存储类，请配置这个。
默认的 StorageClass	高级安装，且如果存储类已配置	如果没有 默认d 存储类(4.12) / (4.10) 集合，或者您要为 SDI 组件选择非默认存储类，请设置这个。
启用 Kaniko 使用率	高级安装	必须在 OpenShift 4 上启用。
SAP Data Intelligence Modeler 的容器镜像存储库设置	高级安装或升级	如果对多个 SDI 实例使用同一个注册中心，请选择 "yes"。
Pipeline Modeler 的容器注册中心	高级安装，并且如果在上一个选择中选择了"Use different one"选项。	如果对多个 SDI 实例使用同一个注册中心，则需要使用不同的前缀（如 local.image.registry:5000/mymodelerprefix2）或不同的注册中心。
加载 NFS 模块	高级安装	尽管说"不"。只要配置了 所需内核模块的加载 ，这就不再是问题。
其他安装程序参数	高级安装	请包括 -e vsystem.vRep.exportsMask=true。如果省略，且 SDI Observer 正在运行，它将代表您应用此参数。

⁴

请注意，经过验证的 S3 API 端点提供者是 ODF NooBaa 4.6.4 或更新版本，外部模式下的 ODF 4.6 以及 NetApp StorageGRID

5.3.项目设置

假设在 SDI Observer 先决条件 过程中 sdi 项目已创建。

以 cluster-admin 身份登录 OpenShift，并为安装执行以下配置：

\

\# change to the SDI_NAMESPACE project using: oc project "${SDI_NAMESPACE:-sdi}"
oc adm policy add-scc-to-group anyuid "system:serviceaccounts:$(oc project -q)"
oc adm policy add-scc-to-user privileged -z default
oc adm policy add-scc-to-user privileged -z mlf-deployment-api
oc adm policy add-scc-to-user privileged -z vora-vflow-server
oc adm policy add-scc-to-user privileged -z "vora-vsystem-$(oc project -q)"
oc adm policy add-scc-to-user privileged -z "vora-vsystem-$(oc project -q)-vrep"

在 SDI 3.3 中重命名了两个监控服务帐户。对于 SDI 3.2 及之前的版本，以下命令将为两个服务帐户授予特权：

oc adm policy add-scc-to-user privileged -z "$(oc project -q)-elasticsearch"
oc adm policy add-scc-to-user privileged -z "$(oc project -q)-fluentd"

对于 SDI 3.3 版本，请运行以下命令：

oc adm policy add-scc-to-user privileged -z "diagnostics-elasticsearch"
oc adm policy add-scc-to-user privileged -z "diagnostics-fluentd"

在 SDI 3.3 的恢复过程中，您可能会遇到 hana StatefulSet 的错误。如果您面临类似如下的错误消息：

create Pod hana-0 in StatefulSet hana failed error: pods "hana-0" is forbidden: unable to validate against any security context constraint: [provider anyuid: .initContainers[0].capabilities.add: Invalid value: "CHOWN": capability may not be added

要解决这个问题，并成功启动 hana pod，请执行以下命令：

\# change to the restoring SDI_NAMESPACE project using: oc project "${SDI_NAMESPACE:-sdi}"
oc adm policy add-scc-to-user privileged -z "hana-service-account"

红帽已了解到更改不符合最佳实践，且大大降低了集群的安全性。因此不建议与其他工作负载共享 Data Intelligence 节点。如 之前 所述，如果您希望改进，请直接咨询 SAP。

5.4.安装 SDI

请按照 在具有互联网访问的 Kubernetes 集群上使用 SLC 网桥进行安装(3.3) / (3.2) / (3.1) 的官方流程操作。

5.5.SDI 安装后步骤

5.5.1.（可选） 在外部公开 SDI 服务

如何使 SDI 服务在集群外可以访问有多种可能。与 Kubernetes 相比，OpenShift 提供了额外的方法，建议用于大多数场景，包括 SDI 系统管理服务。它基于 OpenShift Ingress Operator (4.12) / (4.10)

对于 SAP Vora Transaction Coordinator 和 SAP HANA Wire，请使用 适用于您环境的官方推荐的方法(3.3) / (3.2) / (3.1)。

5.5.1.1.使用 OpenShift Ingress Operator

请注意 不要使用此手动方法，现在建议让 SDI Observer 管理路由创建和更新。如果 SDI Observer 已使用 MANAGE_VSYSTEM_ROUTE 部署了，可以跳过本节。要配置它，请执行以下操作：

\

\# oc set env -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer MANAGE_VSYSTEM_ROUTE=true


\# 

\# wait for the observer to get re-deployed


\

\

\

\# oc rollout status -n "${NAMESPACE:-sdi-observer}" -w dc/sdi-observer

或者请继续手动路由创建。

OpenShift 允许您通过 入口控制器(4.12) / (4.10)，而不是常规的 NodePorts (4.12) / (4.10) 访问 Data Intelligence 服务。例如，在服务公开后，通过 https://worker-node.example.com:32322 访问 vsystem，这样您将能够在 https://vsystem-sdi.apps.. 访问它。这是 公开内部服务(3.3) / (3.2) / (3.1) 的官方指南文档的一种替代方法。

有两种使用 TLS 保护的路由。一种 reencrypt 允许使用自定义签名或自签名证书。另一种是 passthrough，它使用生成或传递给安装程序的预安装证书。

5.5.1.1.1.使用重新加密路由导出服务

使用这种路由，在客户端和路由的服务器端上使用不同的证书。路由器位于中间，使用对应于对方的证书对来自任何一方的通信进行重新加密。在这种情况下，客户端由提供的证书保护，服务侧使用生成的或传递给 SAP Data Intelligence 安装程序的原始证书加密。这是自动创建的同种类型的路由 SDI Observer 。

重新加密路由允许使用正确签名的证书保护客户端连接。

1. 查找 vsystem 服务：

   # oc project "${SDI_NAMESPACE:-sdi}"            # switch to the Data Intelligence project
   
   
   \
   
   \# oc get services | grep "vsystem "
   vsystem   ClusterIP   172.30.227.186   <none>   8797/TCP   19h
   

   导出后，生成的主机名将类似 vsystem-${SDI_NAMESPACE}.apps..。但是，只要它可以正确解析路由器的 IP，就可以选择任意主机名。

2. 得到、生成或使用路由的默认证书。在本例中，路由器使用的默认自签名证书用来保护客户端和 OpenShift 路由器之间的连接。客户端的 CA 证书可以从 openshift-ingress-operator 命名空间中的 router-ca secret 获取：

   
   
   \
   
   \# oc get secret -n openshift-ingress-operator -o json router-ca | \
       jq -r '.data as $d | $d | keys[] | select(test("\\.crt$")) | $d[.] | @base64d' >router-ca.crt
   

3. 获取 SDI 安装时生成的 SDI 的根证书颁发机构捆绑包。生成的捆绑包在 sdi 命名空间中的 ca-bundle.pem secret 中提供。

   
   
   \
   
   \# oc get -n "${SDI_NAMESPACE:-sdi}" -o go-template='{{index .data "ca-bundle.pem"}}' \
       secret/ca-bundle.pem | base64 -d >sdi-service-ca-bundle.pem
   

4. 为 vsystem 服务创建重新加密路由，如下所示：

   
   
   \# oc create route reencrypt -n "${SDI_NAMESPACE:-sdi}" --dry-run -o json \
           --dest-ca-cert=sdi-service-ca-bundle.pem --service vsystem \
           --insecure-policy=Redirect | \
       oc annotate --local -o json -f - haproxy.router.openshift.io/timeout=2m | \
       oc apply -f -
   
   
   \
   
   \
   
   \# oc get route
   NAME      HOST/PORT                                                  SERVICES  PORT      TERMINATION         WILDCARD
   vsystem   vsystem-<SDI_NAMESPACE>.apps.<cluster_name>.<base_domain>  vsystem   vsystem   reencrypt/Redirect  None
   

5. 验证连接：

   
   
   \# 
   
   \# use the HOST/PORT value obtained from the previous command instead
   
   
   \# curl --cacert router-ca.crt https://vsystem-<SDI_NAMESPACE>.apps.<cluster_name>.<base_domain>/
   

5.5.1.1.2.使用 passthrough 路由导出服务

通过 passthrough 路由，到客户端的通信由 SDI 服务的证书全程加密。

备注 ：如果可能的话，首选 reencrypt 路由，因为 vsystem 证书的主机名不能被客户端验证，如以下输出中所示：

\

\# oc get -n "${SDI_NAMESPACE:-sdi}" -o go-template='{{index .data "ca-bundle.pem"}}' \
    secret/ca-bundle.pem | base64 -d >sdi-service-ca-bundle.pem


\# openssl x509 -noout -subject -in sdi-service-ca-bundle.pem
subject=C = DE, ST = BW, L = Walldorf, O = SAP, OU = Data Hub, CN = SAPDataHub

1. 查找 vsystem 服务：

   # oc project "${SDI_NAMESPACE:-sdi}"            # switch to the Data Intelligence project
   
   
   \
   
   \# oc get services | grep "vsystem "
   vsystem   ClusterIP   172.30.227.186   <none>   8797/TCP   19h
   

2. 创建路由：

   
   
   \# oc create route passthrough --service=vsystem --insecure-policy=Redirect
   
   
   \
   
   \
   
   \# oc get route
   NAME      HOST/PORT                                                  PATH  SERVICES  PORT      TERMINATION           WILDCARD
   vsystem   vsystem-<SDI_NAMESPACE>.apps.<cluster_name>.<base_domain>        vsystem   vsystem   passthrough/Redirect  None
   

   您可以使用 --hostname 参数修改主机名。确保它解析为路由器的 IP。

3. 访问位于 https://vsystem-.apps.. 的系统管理服务，以进行验证。

5.5.1.2.使用 NodePort

请注意，对于 OpenShift，首选使用 路由，虽然只可能适用于系统管理服务（也称为 vsystem）。

公开 SAP Data Intelligence vsystem

• 使用自动生成的节点端口：

  
  
  \# oc expose service vsystem --type NodePort --name=vsystem-nodeport --generator=service/v2
  
  
  \# oc get -o jsonpath='{.spec.ports[0].nodePort}{"\n"}' services vsystem-nodeport
  30617
  

• 或使用特定节点端口（例如 32123）：

  
  
  \
  
  \# oc expose service vsystem --type NodePort --name=vsystem-nodeport --generator=service/v2 --dry-run -o yaml | \
      oc patch -p '{"spec":{"ports":[{"port":8797, "nodePort": 32123}]}}' --local -f - -o yaml | oc apply -f -
  

原始服务像以前一样在 ClusterIP:Port 上保持可访问。另外，它现在可以从集群外部，在节点端口下访问。

公开 SAP Vora Transaction Coordinator 和 HANA Wire

\# oc expose service vora-tx-coordinator-ext --type NodePort --name=vora-tx-coordinator-nodeport --generator=service/v2


\# oc get -o jsonpath='tx-coordinator:{"\t"}{.spec.ports[0].nodePort}{"\n"}hana-wire:{"\t"}{.spec.ports[1].nodePort}{"\n"}' \
    services vora-tx-coordinator-nodeport
tx-coordinator: 32445
hana-wire:      32192

输出显示为新公开的服务生成的节点端口。

5.5.2.配置到 Data Lake 的连接

请按照 配置到 DI_DATA_LAKE (3.3) / (3.2) / (3.1) 的连接中的官方安装后说明进行操作。

如果 ODF 用作后备对象存储提供者，请确保使用 HTTP 服务端点，如 使用 NooBaa 或 RADOS Object Gateway S3 端点作为对象存储 中所述。

根据该部分中的示例输出，配置可能类似如下：

参数	值
连接类型	SDL
Id	DI_DATA_LAKE
对象存储类型	S3
端点	http://s3.openshift-storage.svc.cluster.local
访问密钥 ID	cOxfi4hQhGFW54WFqP3R
Secret 访问密钥	rIlvpcZXnonJvjn6aAhBOT/Yr+F7wdJNeLDBh231
根路径	sdi-data-lake-f86a7e6e-27fb-4656-98cf-298a572f74f3

5.5.3.SDI 验证

在 OpenShift 上验证 SDI 安装，以确保一切都按预期工作。请按照 测试您的安装(3.3) / (3.2) / (3.1) 中的说明进行操作。

5.5.3.1.登录到 SAP Data Intelligence Launchpad

如果 vsystem 服务已使用 路由公开了，则可以按如下方式确定 URL：

\

\

\

\

\# oc get route -n "${SDI_NAMESPACE:-sdi}"
NAME      HOST/PORT                                                  SERVICES  PORT      TERMINATION  WILDCARD
vsystem   vsystem-<SDI_NAMESPACE>.apps.<cluster_name>.<base_domain>  vsystem   vsystem   reencrypt    None

然后 HOST/PORT 值需要使用 https:// 前缀，例如：

https://vsystem-sdi.apps.boston.ocp.vslen

5.5.3.2.检查机器学习设置

为了使用 ML Data Manager 上传培训和测试数据集，需要给用户分配 app.datahub-app-data.fullAcces（从 3.2 开始）或 sap.dh.metadata（最多 3.1）策略。请确保遵循 使用 SAP Data Intelligence 策略管理(3.3) / (3.2) / (3.1) ，来向需要它们的用户分配策略。

5.5.4.其他租户的配置

创建新租户时（例如使用 管理集群说明(3.3) / (3.2) / (3.1)），它不会被配置为与容器镜像注册中心一起使用。因此，Pipeline Modeler 不可用，并将无法启动，直到被配置了为止。

对于每个新租户，都需要执行几个步骤：

• 如果 CA 证书是自签名的，则通过 SDI Connection Manager 为注册中心导入 CA 证书
• 只要使用 modeler 的不同注册中心，拉取 secret 需要被导入到 SDI_NAMESPACE
• 使用 SDI 系统管理创建并导入凭证 secret，如果容器镜像注册中心需要身份验证，请更新 modeler secret

如果使用了 Red Hat Quay，请按照 配置额外的 SDI 租户 进行操作。

如果使用了 SDI 注册中心，请按照 SDI Observer 注册中心租户配置 进行操作。否则，请确保按照您的注册中心配置，执行以下文章中的官方说明：

• 为密码保护的容器注册中心提供访问凭证(3.3) / (3.2) / (3.1)（只要 Pipeline Modeler 的注册中心使用带有自签名 CA 的 TLS）
• (3.3) / 管理证书(3.2) / (3.1)（只要您的注册中心需要身份验证）

6.OpenShift Container Platform 升级

作为执行 OpenShift 升级至相同次版本的最新异步发行版本 ⁿ 或升级到运行的 SDI 实例支持的较新的次版本，而无需升级 SDI 本身的指南,本节很有用。

6.1.预升级流程

1. 让您自己熟悉 OpenShift 的升级指南 (4.8 ⇒ 4.9) / (4.9 ⇒ 4.10) / (4.10 ⇒ 4.11) / (4.11 ⇒ 4.12)。
2. 计划 SDI 停机时间。
3. 确保 重新配置 SDI 计算节点。

6.1.1.停止 SAP Data Intelligence

为了加快集群升级和/或确保 SDI 的一致性，可以在执行升级之前停止 SDI。

流程在 官方管理指南(3.3) / (3.2) / (3.1) 中进行了概述。简而言之，命令是：

\

\# oc -n "${SDI_NAMESPACE}" patch datahub default --type='json' -p '[
    {"op":"replace","path":"/spec/runLevel","value":"Stopped"}]'

6.2.升级 OpenShift

以下说明概述了 OpenShift 升级到比当前版本高的次发行版本 2 的过程。如果只需要升级到同一次版本的最新异步版本 ⁿ，请跳过第 5 和第 6 步。

1. 将 OpenShift 升级到更高的次版本或最新的异步发行版本(⇒ 4.12)。
2. 如果部署了 OpenShift Data Foundation，请按照 互操作性指南 将 ODF 更新至当前 OpenShift 版本的最新支持的版本。

3. 更新 管理主机 上的 OpenShift 客户端工具，以匹配目标 ※ OpenShift 发行版本。在 RHEL 8 上可以执行以下操作，如下所示：

   
   
   \
   
   \# current=4.10; new=4.12
   
   
   \
   
   \# sudo subscription-manager repos \
       --disable=rhocp-${current}-for-rhel-8-x86_64-rpms --enable=rhocp-${new}-for-rhel-8-x86_64-rpms
   
   
   \
   
   \# sudo dnf update -y openshift-clients
   

4. 通过遵循 重新使用之前的参数重新部署 SDI Observer ，更新 SDI Observer，以使用与目标 ※ OpenShift 发行版本匹配的 OpenShift 客户端工具。

5. 将 OpenShift 升级到更高的次版本或最新的异步版本(⇒ 4.12) ⁿ。
6. 如果部署了 OpenShift Data Foundation，请按照 互操作性指南 将 ODF 更新至当前 OpenShift 版本的最新支持的版本。

※

对于初始 OpenShift 版本 4.X，目标发行版本是 4.(X+2) ；如果只执行最新的异步发行版本 ⁿ 升级，目标发行版本是 4.X

6.3.升级后的流程

1. 按照 官方管理指南(3.3) / (3.2) / (3.1) 中所述，启动 SAP Data Intelligence。简而言之，命令是：

   
   
   \
   
   \# oc -n "${SDI_NAMESPACE}" patch datahub default --type='json' -p '[
       {"op":"replace","path":"/spec/runLevel","value":"Started"}]'
   

7.SAP Data Intelligence 升级或更新

请注意，本节涵盖了 SAP Data Intelligenc 升级到较新的次版本、微版本或补丁版本。只与前者或后者相关的章节将使用以下注释进行注释：

• （升级） 表示特定于从 Data Intelligence 升级到较新的次版本的章节(3.X ⇒ 3.(X+1))
• (更新) 表示特定于从 Data Intelligence 更新到较新的微/补丁发行版本的章节(3.X.Y ⇒ 3.X.(Y+1))
• 无注释章节是与两者相关的章节

必须按给定顺序执行以下步骤。除非需要 OpenShift 升级，否则可以跳过标记为 (ocp-upgrade) 的步骤。

7.1.预升级或预更新流程

1. 确保熟悉 官方 SAP 升级指南(3.0 ⇒ 3.1) / (3.1 ⇒ 3.2) / (3.2 ⇒ 3.3)。
2. (OCP-upgrade) 使自己熟悉 OpenShift 的升级指南(4.8 ⇒ 4.9) / (4.9 ⇒ 4.10) / (4.10 ⇒ 4.11)/ (4.11 ⇒ 4.12)。
3. 计划停机。
4. 确保 重新配置 SDI 计算节点。

7.1.1.执行 SDI 的预升级流程

请按照 官方预升级流程(3.0 ⇒ 3.1) / (3.1 ⇒ 3.2) / (3.2 ⇒ 3.3) 操作。

7.1.1.1.自动路由删除

SDI Observer 现在允许管理 vsystem 路由的创建和更新,以供外部访问。它负责在 SDI 更新过程中更新路由的目的地证书。也可以指示保留删除的路由，这在 SDI 更新过程中很有用。您可以指示 SDI Observer 删除路由，如下所示：

1. 确保 SDI Observer 已在管理路由：

   
   
   \# oc set env -n "${NAMESPACE:-sdi-observer}" --list dc/sdi-observer | grep MANAGE_VSYSTEM_ROUTE
   MANAGE_VSYSTEM_ROUTE=true
   

   如果没有输出，或 MANAGE_VSYSTEM_ROUTE 不是 true、yes 或 1，请按照 手动删除路由 操作。

2. 指示 observer 保持删除的路由：

   
   
   \# oc set env -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer MANAGE_VSYSTEM_ROUTE=removed
   
   
   \# 
   
   \# wait for the observer to get re-deployed
   
   
   \
   
   \
   
   \
   
   \# oc rollout status -n "${NAMESPACE:-sdi-observer}" -w dc/sdi-observer
   

7.1.1.2. 手动删除路由

如果使用路由公开 vsystem 服务，请删除路由：

\# 

\# note the hostname in the output of the following command


\

\

\

\

\# oc get route -n "${SDI_NAMESPACE:-sdi}"


\# 

\# delete the route


\# oc delete route -n "${SDI_NAMESPACE:-sdi}" --all

7.1.2 （升级） 准备 SDI 项目

从 项目设置 中执行命令，为新服务帐户授予所需的安全性上下文约束。备注 ：重新运行已运行的命令，不会有任何伤害。

7.2.更新或升级 SDI

7.2.1.更新软件生命周期容器网桥

在更新 SLC 网桥之前，请考虑 通过入口控制器公开它。

如果您决定继续使用外部负载均衡器负载均衡的 NodePort 服务，请确保记下当前的服务节点端口：

\# oc get -o jsonpath='{.spec.ports[0].nodePort}{"\n"}' -n sap-slcbridge \
    svc/slcbridgebase-service
31555

请按照 官方文档(3.3) / (3.2) / (3.1) 获取二进制文件，并更新其在 OpenShift 集群上的资源。

如果通过入口控制器公开了，您可以跳过下一步。否则，将 nodePort 重新设置回之前的值，因此不需要在负载均衡器端进行任何更改。

    # nodePort=31555    # change your value to the desired one
    # oc patch --type=json -n sap-slcbridge svc/slcbridgebase-service -p '[{
        "op":"add", "path":"/spec/ports/0/nodePort","value":'"$nodePort"'}]'

7.2.2. （升级） 将 SAP Data Intelligence 升级到较新的次版本

根据 官方说明 (DH 3.0 ⇒ 3.1) / (DH 3.1 ⇒ 3.2) / (DH 3.2 ⇒ 3.3) 执行 SDI 升级。

7.3. (OCP-upgrade) 升级 OpenShift

根据目标 SDI 版本，OpenShift 集群必须升级到较新的次版本，或升级到当前次版本的最新异步发行版本ⁿ。

升级/当前 SDI 发行版本	所需的且已验证的 OpenShift 发行版本
3.3	4.12
3.3	4.10
3.3	4.8
3.2	4.8
3.1	4.6
3.0	4.6

如果当前的 OpenShift 发行版本比所需版本落后两个或更多版本，必须将 OpenShift 集群迭代升级到每个连续的次版本，直到达到所需的版本。

1. （可选） 停止 SAP Data Intelligence，因为它将加快集群更新，并确保 SDI 的一致性。

2. 确保遵循您升级路径的官方升级说明：

   • 4.8 ⇒ 4.9 ⇒ 4.10
   • 4.10 ⇒ 4.11 ⇒ 4.12

3. 在 OpenShift 4.11 上，请按照 重新部署 SDI Observer 更新 observer。请确保将 MANAGE_VSYSTEM_ROUTE 设置为 remove，直到 SDI 更新完成为止。请设置所需的 OpenShift 次版本（如 OCP_MINOR_RELEASE=4.12）。

4. 对于 SDI 3.2 到 3.3 的升级，需要通过运行以下命令为以下两个服务帐户授予特权：

   
   
   \
   
   \# change to the SDI_NAMESPACE project using: oc project "${SDI_NAMESPACE:-sdi}"
   oc adm policy add-scc-to-user privileged -z "diagnostics-elasticsearch"
   oc adm policy add-scc-to-user privileged -z "diagnostics-fluentd"
   

5. （可选） 如果已达到所需的 OpenShift 版本，请再次 启动 SAP Data Intelligence。

6. 在 管理主机 上升级 OpenShift 客户端工具。以下示例可在 RHEL 8 上使用：

   
   
   \
   
   \# current=4.10; new=4.12
   
   
   \
   
   \# sudo subscription-manager repos \
       --disable=rhocp-${current}-for-rhel-8-x86_64-rpms --enable=rhocp-${new}-for-rhel-8-x86_64-rpms
   
   
   \
   
   \# sudo dnf update -y openshift-clients
   

7.4.SAP Data Intelligence 升级后流程

1. 执行 SDH (3.3) / (3.2) / (3.1) 的升级后流程。

2. 使用以下方法之一为 vsystem 服务重新创建路由：

   • （推荐） 指示 SDI Observer 管理路由：

     
     
     \
     
     \# oc set env -n "${NAMESPACE:-sdi-observer}" dc/sdi-observer MANAGE_VSYSTEM_ROUTE=true
     
     
     \# 
     
     \# wait for the observer to get re-deployed
     
     
     \
     
     \
     
     \
     
     \# oc rollout status -n "${NAMESPACE:-sdi-observer}" -w dc/sdi-observer
     

   • 按照 在外部公开 SDI 服务，来手动从头开始重新创建路由

7.5.验证 SAP Data Intelligence

在 OpenShift 上验证 SDI 安装，以确保一切都按预期工作。请按照 测试您的安装(3.3) / (3.2) / (3.1) 中的说明进行操作。

8.附录

8.1.SDI 卸载

请按照 SAP 文档 使用 SLC 网桥卸载 SAP Data Intelligence (3.3) / (3.2) / (3.1) 操作。

另外，请确保还删除 sdi 项目和 datahub-system，例如：

\# oc delete project sdi

然后删除 datahub-system 项目，例如：

\# oc delete project datahub-system

备注 ：因此，SDI Observer 丢失了查看和修改已删除命名空间中的资源的权限。如果要进行新的 SDI 安装，则需要重新部署 SDI observer 。

另外，也可删除 SDI Observer 的命名空间，例如：

\

\# oc delete project sdi-observer

注意 ：如果使用 SDI Observer 部署了，这也会删除 SDI 注册中心，这意味着需要在新安装过程中再次执行镜像。如果需要为下次安装保留 SDI Observer（包括注册中心及其数据），请确保在重新创建 sdi 项目后，重新部署它。

完成后，您可以继续在同一个或者另一个命名空间中进行 新一轮安装。

8.2.SDI 的 Quay 注册中心

Red Hat Quay 注册中心已经过验证，来托管 SAP Data Intelligence 镜像。Quay 注册中心可以在 OpenShift 集群上与 SDI 一起运行 或在另一个 OpenShift 集群上或独立运行。

备注：Red Hat Quay 3.6 或更新版本与 SDI 镜像兼容。

根据文档部署 Red Hat Quay 后，请确保将 OpenShift 集群配置为信任注册中心。

8.2.1.Quay 命名空间、用户和帐户准备

1. 创建新机构。在本示例中，我们将机构称为 sdi。

   • 此机构将托管 SLC 网桥、SAP DI 和 SAP DI operator 所需的所有镜像。

2. 以 Quay Superadmin 身份 创建一个新用户（如 sdi_slcb）。请注意凭证。用户将被 SLC 网桥和 OpenShift（而不是被人类）用作机器人帐户。目前，无法使用常规的 Quay 机器人帐户，因为机器人帐户无法在推送时创建存储库。

3. 授予 sdi_slcb 用户至少访问 sdi 机构的 Creator 权限。

   • 将用户添加到"Teams and Membership"窗格中的 owners team 中。
   • 或者在 sdi 机构中 创建一个新 team，例如 pushers，Creator 分配了team 角色，并将 sdi_slcb 用户添加为成员。

4. (可选)作为 Superadmin，为管道模型器 创建另一个用户（例如 sdi_default_modeler，其中 default 代表默认租户）。

   • 为每个租户的管道模型器提供单独的注册中心命名空间和用户的好处：
     • 可以基于每个租户对镜像轻松删除。一旦不再需要 SDI 租户，可以删除相应的 Quay 用户，并且其镜像将自动从注册中心中删除，并恢复空间。
     • 改进了安全性。SDI 租户用户无法访问其他 SDI 租户的镜像。
   • 此用户将被再次用作机器人帐户，类似于 sdi_slcb。
   • 对于用户的电子邮件地址，只要其在所有 Quay 用户中是唯一的，任何虚假地址都可以。
   • 用户的名称同时也是镜像将被推送到的和从中拉取的命名空间。
   • 确保记下凭据。
   • 用户必须能够从 sdi 机构拉取。

   要让用户从 sdi 机构拉取，请确保也执行以下操作。

   1. 作为 sdi 机构的所有者，请转至其"Teams and Membership"窗格，使用 Member Team 角色 创建一个新 team （如 pullers）。
   2. 点击 "Set for pullers" ，并确保 team 可以读取已在 sdi 机构中存在的所有存储库。
   3. 点 puller team，搜索 sdi_default_modeler 用户，并 将其添加到 team 中。
   4. 返回到 sdi 机构的 Default Permissions，点 "Create Default Permission"，并将 Anyone 创建的存储库的 "Read" 权限添加到 puller team。

5. (可选)对您要创建的任何其他 SDI 租户重复上一步。

8.2.2.确定镜像存储库

镜像存储库 输入参数 由 / 组成。

• 在 OpenShift 集群上运行的 Quay 的注册中心 可以在管理主机 上决定，如下所示：

  
  
  \
  
  \
  
  \
  
  \# oc get route --all-namespaces -o jsonpath='{range .items[*]}{.spec.host}{"\n"}{end}' \
          -l quay-component=quay-app-route
  

  输出示例：

  quay.apps.cluster.example.com
  

  如果本地 Quay 注册中心在 OpenShift 集群外运行，则需要通过其他方法确定其主机名。

• 是机构名称或用户名。对于 sdi 机构， 是 sdi。

在本例中，生成的镜像存储库参数将是 quay.apps.cluster.example.com/sdi。

8.2.3.将 Quay 的 CA 证书导入到 OpenShift

如果还没有做，请确保使 OpenShift 集群信任 Quay 注册中心。

1. 如果 Quay 注册中心在 OpenShift 集群上运行，获取 secret 的 router-ca.crt，如 SDI 注册中心验证部分 中所述。否则，请获取外部 Quay 注册中心的自签名 CA 证书。
2. 按照章节 配置 OpenShift 以信任容器镜像注册中心操作，以使注册中心可信。

8.2.4.配置额外的 SDI 租户

对于每个新 SDI 租户，有三个步骤需要执行：

• 如果 CA 证书是自签名的，则通过 SDI Connection Manager 为注册中心导入 CA 证书
• 创建拉取 secret ，并将其导入到 OpenShift 命名空间
• 使用 SDI 系统管理创建并导入凭证 secret，并更新 modeler secret

在本例中，我们将使用新创建的租户 blue 进行操作，我们假定名为 blue_modeler 的新 Quay 注册中心用户已创建。

8.2.4.1.将 Quay 的 CA 证书导入到 SAP DI

1. 请按照 将 Quay 的 CA 证书导入到 OpenShift 中的步骤 1 操作，来将本地 CA 证书获取为 router-ca.crt 。
2. 按照 管理证书指南(3.3) / (3.2) / (3.1) ，通过 SDI 连接管理导入 router-ca.crt。

8.2.4.2.创建 vflow 拉取 secret ，并将其导入到 OpenShift

只有在对每个租户使用不同的 Quay 命名空间时才需要这样做。

1. 以用户 blue_modeler 身份登录到您的 Quay 注册中心。
2. 点击右上角的用户头像，进到 "Account Settings" -> "User Settings"，点 "Create Application Token"。我们使用 blue_modeler_quay_token 作为令牌名称。
3. 生成应用程序令牌后，点它并下载相应的"Kubernetes Secret"。在这个示例中，下载的文件为 blue-modeler-quay-token-secret.yaml。

4. 在 管理主机 上，将 secret 导入到 OpenShift 集群上的 SDI_NAMESPACE 中，例如：

   
   
   \# oc apply -n "${SDI_NAMESPACE:-sdi}" -f blue-modeler-quay-token-secret.yaml
   

5. 在 blue 租户的 SDI "System Management" 中，进到 Applications 选项卡，搜索 pull，点 Edit 按钮并将 "Modeler:Docker image pull secret for Modeler" 设置为导入的 secret 的名称（如 blue-modeler-quay-token-pull-secret）。

8.2.4.3.将凭证 secret 导入到 SDI 租户

如果您已将 vflow 拉取 secret 导入到 OpenShift 集群中，您可以将导入的 secret 转换成 SDI 的正确文件格式，如下所示：

\# secret=blue-modeler-quay-token-pull-secret


\# oc get -o json -n "${SDI_NAMESPACE:-sdi}" "secret/$secret" | \
    jq -r '.data[".dockerconfigjson"] | @base64d' | jq -r '.auths as $auths | $auths | keys |
        map(. as $address | $auths[.].auth | @base64d | capture("^(?<username>[^:]+):(?<password>.+)$") |
        {"address": $address, "username": .username, "password": .password})' | \
    json2yaml | tee vsystem-registry-secret.txt

否则，手动创建 secret，如下所示：

\# cat >/tmp/vsystem-registry-secret.txt <<EOF
- username: "blue_modeler"
  password: "CHANGEME"
  address: "quay.apps.cluster.example.com"
EOF

请注意，地址不得包含任何 / 后缀！

按照官方 为密码保护的容器注册中心提供访问凭证 (3.3) / (3.2) / (3.1)，使用 SDI 系统管理导入 secret。

8.3.（已弃用）手动部署 SDI 注册中心

适合在 OpenShift 集群上托管 SAP Data Intelligence 镜像的安全容器镜像注册中心。

8.3.1.部署

SDI 注册中心的 kubernetes 资源在 OpenShift 模板中定义。要选择正确的模板并为其提供正确的参数，建议使用下面记录的部署脚本。

8.3.1.1.先决条件

1. OpenShift 集群必须健康，包括所有集群 operator。
2. jq >= 1.6 管理主机上提供的二进制文件

8.3.1.2.模板实例化

1. 在您的管理主机上提供 git 存储库。

   
   
   \
   
   \
   
   \# git clone https://github.com/redhat-sap/sap-data-intelligence
   

2. 检查部署脚本的可用参数：

   
   
   \
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh --help
   

3. 选择合适的参数集，并试运行以查看发生了什么。默认情况下将选择 ubi-prebuilt flavour。镜像将从 quay.io/redhat-sap-cop/container-image-registry 中拉取。

   
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh --dry-run
   

4. 接着，真正部署 SDI 注册中心，并等待其部署：

   
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh --wait
   

8.3.1.3.断开连接的环境的通用实例化

必须在 OpenShift 集群外有另一个容器镜像注册中心在运行，以托管 SDI 注册中心的镜像。该注册中心应该还用来托管 SAP Data Intelligence 镜像，只要它兼容。否则，请按照本指南操作。

1. 将 SDI 注册中心的预构建镜像镜像到本地注册中心。例如，在 RHEL8 上：

   • 其中管理主机可以访问互联网：

     # podman login local.image.registry:5000    # if the local registry requires authentication
     
     
     \
     
     \
     
     \
     
     \# skopeo copy \
         docker://quay.io/redhat-sap-cop/container-image-registry:latest \
         docker://local.image.registry:5000/container-image-registry:latest
     

   • 其中管理主机 无法 访问互联网。

     i. 在有互联网连接的主机上复制 USB 闪存中的镜像：

         
     
     \
     
     \
     
     \
     
     \# skopeo copy \
             docker://quay.io/redhat-sap-cop/contaimer-image-registry:latest \
             oci-archive:/var/run/user/1000/usb-disk/container-image-registry:latest
     

     ii.将 USB 驱动器插到管理主机，并将其中的镜像镜像到您的 local.image.registry:5000：

         
     
     \
     
     \
     
     \
     
     \# skopeo copy \
             oci-archive:/var/run/user/1000/usb-disk/container-image-registry:latest \
             docker://local.image.registry:5000/container-image-registry:latest
     

2. 在您的管理主机上提供 git 存储库。

   
   
   \
   
   \
   
   \# git clone https://github.com/redhat-sap/sap-data-intelligence
   

3. 检查部署脚本的可用参数：

   
   
   \
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh --help
   

4. 选择合适的参数集，并试运行，以查看将发生什么：

   
   
   \
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh \
       --image-pull-spec=local.image.registry:5000/container-image-registry:latest --dry-run
   

5. 接着，真正部署 SDI 注册中心，并等待其部署：

   
   
   \
   
   \# ./sap-data-intelligence/registry/deploy-registry.sh \
       --image-pull-spec=local.image.registry:5000/container-image-registry:latest --wait
   

6. 请确保备份参数，以用于将来的更新。

8.3.2.更新说明

到目前为止，需要手动执行更新。

请按照 模板实例化 中概述的步骤操作。重新运行部署脚本将仅更改需要更改的内容。

8.3.3.确定注册中心的凭证

用户名和密码在 SDI_REGISTRY_HTPASSWD_SECRET_NAME secret 中用冒号隔开：

\# 

\# make sure to change the "sdi-registry" to your SDI Registry's namespace


\# oc get -o json -n "sdi-registry" secret/container-image-registry-htpasswd | \
    jq -r '.data[".htpasswd.raw"] | @base64d'
user-qpx7sxeei:OnidDrL3acBHkkm80uFzj697JGWifvma

8.3.4.验证

1. 获取入口的默认自签名 CA 证书：

   
   
   \
   
   \# oc get secret -n openshift-ingress-operator -o json router-ca | \
       jq -r '.data as $d | $d | keys[] | select(test("\\.crt$")) | $d[.] | @base64d' >router-ca.crt
   

2. 将 nm 变量设置为运行 SDI 注册中心的 Kubernetes 命名空间：

   
   
   \# nm=sdi-registry
   

3. 使用 curl 做一个简单的测试：

   
   
   \# 
   
   \# determine registry's hostname from its route
   
   
   \
   
   \# hostname="$(oc get route -n "$nm" container-image-registry -o jsonpath='{.spec.host}')"
   
   
   \# curl -I --user user-qpx7sxeei:OnidDrL3acBHkkm80uFzj697JGWifvma --cacert router-ca.crt \
       "https://$hostname/v2/"
   HTTP/1.1 200 OK
   Content-Length: 2
   Content-Type: application/json; charset=utf-8
   Docker-Distribution-Api-Version: registry/2.0
   Date: Sun, 24 May 2020 17:54:31 GMT
   Set-Cookie: d22d6ce08115a899cf6eca6fd53d84b4=9176ba9ff2dfd7f6d3191e6b3c643317; path=/; HttpOnly; Secure
   Cache-control: private
   

4. （可选）使证书在您的管理主机上可信（本例适用于 RHEL7 或更新版本）：

   
   
   \# sudo cp -v router-ca.crt /etc/pki/ca-trust/source/anchors/router-ca.crt
   
   
   \# sudo update-ca-trust
   

5. 使用 podman ：

   
   
   \# 
   
   \# determine registry's hostname from its route
   
   
   \
   
   \# hostname="$(oc get route -n "$nm" container-image-registry -o jsonpath='{.spec.host}')"
   
   
   \# sudo mkdir -p "/etc/containers/certs.d/$hostname"
   
   
   \# sudo cp router-ca.crt "/etc/containers/certs.d/$hostname/"
   
   
   \# podman login -u user-qpx7sxeei "$hostname"
   Password:
   Login Succeeded!
   

8.3.5.配置后

默认情况下，SDI 注册中心由自签名 CA 证书签名的入口控制器的证书保护。自签名证书不被 OpenShift 或 SDI 信任。

如果注册中心是由合适的可信（不是自签名）证书签名的，则可以跳过此项。

8.3.5.1.使 SDI 注册中心被 OpenShift 信任

要使注册中心被 OpenShift 集群信任，请按照 配置 OpenShift ，以信任容器镜像注册中心 操作。您可以在 bash 中确定注册中心主机名，如下所示：

\# nm="sdi-registry"   

\# namespace where registry runs


\# registry="$(oc get route -n "$nm" \
    container-image-registry -o jsonpath='{.spec.host}')"; echo "$registry"

8.3.5.2.SDI Observer 注册中心租户配置

只要以下条件之一为真，默认租户就会被自动配置：

• SDI Observer 正在运行，并使用 INJECT_CABUNDLE=true 进行了配置，且 CA 证书使用其中一个 CABUNDLE_* 环境变量进行了配置（默认值通常就可以）。
• 已遵循 设置证书 。

备注 ：只有在 SDI 安装 完成后才适用。

每个新创建的租户需要被配置为能够与 SDI 注册中心进行通信。初始租户(default)不需要手动配置，因为它在安装过程中配置了。

对于每个新租户，有两个步骤需要执行：

• 如果 CA 证书是自签名的，则通过 SDI Connection Manager 为注册中心导入 CA 证书
• 使用 SDI 系统管理创建并导入凭证 secret，并更新 modeler secret

导入 CA 证书

1. 获取 secret 的 router-ca.crt，如 上一节 中所述。
2. 按照 管理证书指南(3.3) / (3.2) / (3.1) ，通过 SDI 连接管理导入 router-ca.crt。

导入凭证 secret

根据官方 为密码保护的容器注册中心提供访问凭证 (3.3) / (3.2) / (3.1)，确定凭证 ，并使用 SDI 系统管理导入它们。

作为步骤 "1 的替代方案。创建包含容器注册中心凭证和 …" 的 secret 文件，您也可以使用以下方法创建 vsystem-registry-secret.txt 文件：

\# 

\# determine registry's hostname from its route


\# hostname="$(oc get route -n "${NAMESPACE:-sdi-observer}" container-image-registry -o jsonpath='{.spec.host}')"


\# oc get -o json -n "${NAMESPACE:-sdi-observer}" secret/container-image-registry-htpasswd | \
    jq -r '.data[".htpasswd.raw"] | @base64d | sub("^\\s*Credentials:\\s+"; "") | gsub("\\s+"; "") | split(":") |
        [{"username":.[0], "password":.[1], "address":"'"$hostname"'"}]' | \
    json2yaml | tee vsystem-registry-secret.txt

注意 ：除了 jq，remarshal 项目 中的 json2yaml 二进制文件也 必须安装 在 管理主机 上

8.4.将 OpenShift 配置为信任容器镜像注册中心

如果注册中心的证书是由自签名证书颁发机构签名的，则必须让 OpenShift 知道它。

如果注册中心运行在 OpenShift 集群本身上，并通过 reencrypt 或带有默认 TLS 设置的 edge 路由公开，则使用的 CA 证书在 openshift-ingress-operator 命名空间中的 secret router-ca 中可用。

要使注册中心通过这样信任的路由可用，请将路由的主机名设置为 registry 变量，并在 bash 中执行以下代码：

\# registry="local.image.registry:5000"


\# caBundle="$(oc get -n openshift-ingress-operator -o json secret/router-ca | \
    jq -r '.data as $d | $d | keys[] | select(test("\\.(?:crt|pem)$")) | $d[.] | @base64d')"


\# 

\# determine the name of the CA configmap if it exists already


\# cmName="$(oc get images.config.openshift.io/cluster -o json | \
    jq -r '.spec.additionalTrustedCA.name // "trusted-registry-cabundles"')"


\# if oc get -n openshift-config "cm/$cmName" 2>/dev/null; then
    # configmap already exists -> just update it
    oc get -o json -n openshift-config "cm/$cmName" | \
        jq '.data["'"${registry//:/..}"'"] |= "'"$caBundle"'"' | \
        oc replace -f - --force
  else
      # creating the configmap for the first time
      oc create configmap -n openshift-config "$cmName" \
          --from-literal="${registry//:/..}=$caBundle"
      oc patch images.config.openshift.io cluster --type=merge \
          -p '{"spec":{"additionalTrustedCA":{"name":"'"$cmName"'"}}}'
  fi

如果使用在 OpenShift 外运行的或不是由默认入口 CA 证书保护的注册中心，请参阅官方指南 为镜像注册中心 Operator 配置 ConfigMap (4.12) / (4.10)。

要验证 CA 证书是否已部署，请执行以下操作，并检查所提供的注册中心名称是否在输出中的文件名中出现：

\# oc rsh -n openshift-image-registry "$(oc get pods -n openshift-image-registry -l docker-registry=default | \
        awk '/Running/ {print $1; exit}')" ls -1 /etc/pki/ca-trust/source/anchors
container-image-registry-sdi-observer.apps.boston.ocp.vslen
image-registry.openshift-image-registry.svc..5000
image-registry.openshift-image-registry.svc.cluster.local..5000

如果这不可行，也可以 将注册中心标记为不安全。

8.5.配置不安全的注册中心

作为 配置 OpenShift 以信任容器镜像注册中心 的一种不太安全的替代方案，注册中心也可以被标记为不安全，这构成了潜在的安全风险。请按照 配置镜像设置(4.12) / (4.10) ，并将注册中心添加到 .spec.registrySources.insecureRegistries 数组中。例如：

apiVersion: config.openshift.io/v1
kind: Image
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  name: cluster
spec:
  registrySources:
    insecureRegistries:
    - local.image.registry:5000

注意 ：重新配置节点可能需要几十分钟。您可以使用以下命令来监控进度：

• watch oc get machineconfigpool
• watch oc get nodes

8.6.在单个 OpenShift 集群上运行多个 SDI 实例

在单个 OpenShift 集群上并行运行两个 SAP Data Intelligence 实例已被验证。可以运行更多实例，但大多数实例可能需要 SAP 的额外支持声明。

在将多个 SDI 实例部署到集群前，请考虑以下几点：

• 每个 SAP Data Intelligence 实例都必须在其自己的命名空间/项目中运行。
• 每个 SAP Data Intelligence 实例必须对 Pipeline Modeler 使用不同的前缀或容器镜像注册中心。例如，第一个实例可以将 "Pipeline Modeler 的容器注册中心设置" 配置为 local.image.registry:5000/sdi30blue，第二个实例被配置为 local.image.registry:5000/sdi30green。
• 建议 将特定节点专用于 每个 SDI 实例。
• 建议您将 网络策略(4.12) / 4.10 (4.10) SDN 模式用于完全精细的网络隔离配置，并提高了安全性。检查 网络策略配置(4.12) / (4.10) ，以获取进一步的参考和示例。但是，在 OpenShift 安装 后无法进行这方面的更改。
• 如果在单个 OpenShift 集群上运行生产环境和测试（也称为蓝-绿）SDI 部署，请注意以下几点：
  • 在 SDI 升级前，没有办法测试 OpenShift 集群的升级。
  • 空闲（非生产）环境应具有与实时（生产）环境相同的网络安全性。

要将新的 SDI 实例部署到 OpenShift 集群，请从第 6 点开始，使用新的项目名称，重复 项目设置 中的步骤，并继续 SDI 安装。

8.7.在 RHEL 上安装 remarshal 工具

对于本指南中的几个示例片段，需要 yaml2json 或 json2yaml 脚本。

它们由 remarshal 项目 提供，除了 jq ，还需要在 管理主机 上安装。在 RHEL 8.2 上，可以以这种方式安装它：

\# sudo dnf install -y python3-pip


\# sudo pip3 install remarshal

8.8. (脚注 ⁿ)从最新的异步版本升级到下一个次版本

如果 OpenShift 集群订阅了 stable 渠道，则当前次版本的最新可用微版本可能无法升级到较新的次版本。

考虑以下示例：

• OpenShift 集群的版本是 4.11.24。
• stable-4.11 渠道中提供的最新异步发行版本是 4.11.30。
• 最新的 stable 4.12 版本是 4.12.15（在 stable-4.12 渠道中提供）。
• 从 4.11.24 微版本，可以升级到 4.11.27、4.11.28、4.11.30、4.12.13 或 4.12.15
• 但是，从 4.11.30 无法升级到任何更新的版本，因为在 stable 渠道中还没有验证/提供升级路径。

因此，如果 OpenShift 集群首次升级到最新的异步版本 4.11.30，而不是直接升级到 4.12 次版本之一，则 OpenShift 集群可能会在 4.11 版本上卡住。但是同时，fast-4.12 渠道 包含带有 4.11.30 的升级路径的 4.12.16 版本。在 4.12.16 首先在 fast 渠道 中引入之后，其迟早会出现在 stable-4.12 渠道中。

要在不等待升级路径出现在 stable 渠道 中的情况下修改这种情况：

1. 临时 切换 到 fast-4.X 渠道。
2. 执行升级。
3. 切回到 stable-4.X 渠道。
4. 继续升级到 stable-4.X 渠道 中提供的最新微版本。

8.9.HTTP 代理配置

HTTP (S)代理必须在不同的地方配置。相应的 No Proxy 设置被不同的组件区别对待。

• 管理主机
• OpenShift 集群
• SLC 网桥
• SAP Data Intelligence

以下部分假设：
- 集群的基本域是 example.com
- 集群名称是 foo，意味着其 API 正在侦听 api.foo.example.com:6443
- 本地代理服务器正在侦听 http://proxy.example.com:3128
- 管理主机 的主机名为 jump.example.com，我们应该将其短名称(jump)添加到 NO_PROXY
- 本地网络 CIDR 是 192.168.128.0/24
- OpenShift 的服务网络有默认的 172.30.0.0/16 范围

8.9.1.在管理主机上配置 HTTP 代理

请根据您的 Linux 发行版，在您的 管理主机 上导出代理环境变量。对于 RHEL，请按照 如何应用系统范围的代理 操作。例如，在 BASH 中：

\# sudo cp /dev/stdin /etc/profile.d/http_proxy.sh <<EOF
export http_proxy=http://proxy.example.com:3128
export https_proxy=http://proxy.example.com:3128
export no_proxy=localhost,127.0.0.1,jump,.example.com,192.168.128.0/24
EOF


\# source /etc/profile.d/http_proxy.sh

其中 .example.com 是与任何子域（如 foo.example.com）匹配的通配符模式。

8.9.2.在 OpenShift 集群上配置 HTTP 代理

通常，OpenShift 在安装过程 中被配置为使用代理。

但是 也可以设置/重新配置其 ex-post。

一个配置示例可能类似如下：

\# oc get proxy/cluster -o json | jq '.spec'
{
  "httpProxy": "http://proxy.example.com:3128",
  "httpsProxy": "http://proxy.example.com:3128",
  "noProxy": "192.168.128.0/24,jump,.local,.example.com",
  "trustedCA": {
    "name": "user-ca-bundle"
  }
}

请记住，OpenShift 不支持通配符（如 *.example.com）。

为容器和服务网络以及额外的服务名称扩展的完整的 no_proxy 列表被自动生成，并存储在 proxy 对象的 .status.noProxy 字段中：

\# oc get proxy/cluster -o json | jq -r '.status.noProxy'
.cluster.local,.local,.example.com,.svc,10.128.0.0/14,127.0.0.1,172.30.0.0/16,192.168.128.0/24,api-int.foo.example.com,localhost,jump

8.9.3.为 SLC 网桥配置 HTTP 代理

SLC 网桥二进制文件将使用 之前配置的 管理主机 上的环境中的代理设置。这对于允许 SLCB 与 SAP 镜像注册中心（代理的）、本地镜像注册中心和 OpenShift API （未代理）进行通信非常重要。

在 SLC 网桥的初始阶段，它在 OpenShift 集群上将桥接部署为一个容器，在提示时必须设置代理设置。以下是示例值：

\# ./slcb init
...
***************************************************************************
* Choose whether you want to run the deployment in typical or expert mode *
***************************************************************************

     1. Typical Mode
   > 2. Expert Mode
Choose action <F12> for Back/<F1> for help
  possible values [1,2]: 2
...
************************
*    Proxy Settings    *
************************

   Configure Proxy Settings: y
Choose action <F12> for Back/<F1> for help
  possible values [yes(y)/no(n)]: y

************************
*     HTTPS Proxy      *
************************

Enter the URL of the HTTPS Proxy to use
Choose action <F12> for Back/<F1> for help
  HTTPS Proxy: http://proxy.example.com:3128

到目前为止，这毫不奇怪。但是，对于 No Proxy，建议从 OpenShift 的代理对象 复制并追加 .status.noProxy 设置。

************************
*   Cluster No Proxy   *
************************

Specify the NO_PROXY setting for the cluster.
The value cannot contain white space and it must be comma-separated.
You have to include the address range configured for the kubernetes cluster in this list (e.g. "10.240.0.0/20").
Choose action <F12> for Back/<F1> for help
  Cluster No Proxy: 10.128.0.0/14,127.0.0.1,172.30.0.0/16,192.168.128.0/24,localhost,jump,169.254.169.254,sap-slcbridge,.local,.example.com,.svc,.internal

注意 ：您可以使用以下脚本从 OpenShift 的代理设置生成值：

\

\# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/get_no_proxy.sh) --slcb

请确保附加 --slcb 参数。

8.9.4.在其安装过程中为 SAP DI 配置 HTTP 代理

在 SDI 安装 过程中，必须对"Installation Type"选择"Advanced Installation"，以配置代理。

然后，如下是代理设置的示例：

**************************
* Cluster Proxy Settings *
**************************

   Choose if you want to configure proxy settings on the cluster: y
Choose action <F12> for Back/<F1> for help
  possible values [yes(y)/no(n)]: y

************************
*  Cluster HTTP Proxy  *
************************

Specify the HTTP_PROXY value for the cluster.
Choose action <F12> for Back/<F1> for help
  HTTP_PROXY: http://proxy.example.com:3128

************************
* Cluster HTTPS Proxy  *
************************

Specify the HTTPS_PROXY value for the cluster.
Choose action <F12> for Back/<F1> for help
  HTTPS_PROXY: http://proxy.ocpoff.vslen:3128

************************
*   Cluster No Proxy   *
************************

Specify the NO_PROXY value for the cluster. NO_PROXY value cannot contain white spaces and it must be comma-separated.
Choose action <F12> for Back/<F1> for help
  NO_PROXY: 10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,192.168.0.0/16,192.168.128.2,localhost,jump,169.254.169.254,auditlog,datalake,diagnostics-prometheus-pushgateway,hana-service,storagegateway,uaa,vora-consul,vora-dlog,vora-prometheus-pushgateway,vsystem,vsystem-internal,*.local,*.example.com,*.svc,*.internal

注意：

值可使用以下脚本生成：

\# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/get_no_proxy.sh)



\# 

\# to see the usage and options, append `--help`


\

\# bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-data-intelligence/master/utils/get_no_proxy.sh) --help

在设置 No Proxy 时，请注意以下几点：

• 通配符域必须包含通配符。相反，OpenShift 的代理设置 不得包含通配符。
• 从 SLC 网桥 1.1.72 开始，NO_PROXY 不得以通配符域开头。换句话说，请将通配符域放在 NO_PROXY 的末尾。

• 除了 OpenShift 代理的 .status.noProxy 值外，列表还应该包括以下服务名称：

  • vora-consul,hana-service,uaa,auditlog,vora-dlog,vsystem-internal,vsystem,vora-prometheus-pushgateway,diagnostics-prometheus-pushgateway,storagegateway,datalake

8.9.5.在 SAP DI 安装后配置 HTTP 代理

1. 以 clusterAdmin 身份登录到 system 租户，并打开 System Management。
2. 点 Cluster，然后点 Tenants。
3. 对于每个租户，单击租户行。
4. 点 "View Application Configuration and Secrets"。
5. 搜索 PROXY ，并点击 Edit 按钮。
6. 根据需要编辑值。您可以使用 上面的get_no_proxy.sh 脚本 生成 No proxy 值。
7. 点击 Update 按钮。
8. （如果处理 system 租户，请跳过这一步，直到最后。）返回到租户概述。这次，单击"Delete all Instances"。请注意，这将导致租户的当前用户轻微停机。
9. 对其他租户重复第 3 步。
10. 对 system 租户也执行第 8 步。

8.10.在 OCP 上为 SDI 启用 GPU

要在 OCP 上为 SDI 启用 GPU 的使用，请参阅 在 OCP 上为 SDI 启用 GPU。

9.故障排除

有关详细的故障排除指南，请参阅 https://access.redhat.com/articles/7018550。