# AWS Marketplace上的KNIME Server

# 介绍

KNIME Server是企业软件，用于基于团队的协作，自动化，管理以及数据科学工作流，数据和指导性分析的部署。非专家可以通过KNIME WebPortal访问数据科学，也可以使用REST API将工作流集成为应用程序和IoT系统的分析服务。完整的概述可以在这里找到 (opens new window)。

有关用例的概述，请参见我们的解决方案页面 (opens new window)。在KNIME Summits上有关KNIME服务器使用的演示可以在这里 (opens new window)找到。

# 进一步阅读

如果要查找有关KNIME Server的其他配置选项的详细说明，可以查看《KNIME Server管理指南》 (opens new window)。

如果要安装KNIME Server，则应首先查阅《 KNIME Server安装指南》 (opens new window)。

有关从KNIME Analytics Platform连接到KNIME Server或使用KNIME WebPortal的指南，请参考以下指南：

其他资源也是《 KNIME服务器高级设置指南》 (opens new window)。

# 在AWS上部署

可以通过AWS Marketplace启动KNIME Server。有几种选择：

有关包括KNIME Analytics Platform在内的产品的完整列表，请参见此处 (opens new window)。

KNIME服务器（BYOL）实例要求您携带“自己的许可证”文件才能使用。要获取许可证文件，您应该联系您的KNIME代表或sales@knime.com。

KNIME Server Small，Medium和BYOL是单个AMI实例，最容易通过AWS控制台启动。如果您熟悉AWS CLI，则也可以使用此部署方法。

对于使用自定义基础映像的自构建部署，应查阅《 KNIME服务器安装指南》 (opens new window)。

# 先决条件

负责KNIME Server部署的人员应熟悉有关配置EC2实例的基本AWS功能。KNIME Server管理需要基本的Linux系统管理技能，例如通过CLI编辑文本文件以及启动/停止systemd服务。

KNIME Server Small，Medium和BYOL是单个AMI映像，包含所有软件要求。

对于自建实例，请查阅标准的KNIME Server安装指南 (opens new window)。

# AWS资源

启动实例需要VPC和子网。默认安全组将在端口80上启用HTTP访问，在端口443上启用HTTPS访问。通过SSH访问在端口22上管理服务器。

可以选择使用的其他AWS服务是：

AWS KMS (opens new window)：支持EBS / EFS卷加密。
AWS EFS (opens new window)：弹性文件系统可用于支持服务器故障转移设置。
AWS ELB (opens new window)：可以选择使用负载均衡器来支持服务器故障转移设置。
AWS ASG (opens new window)：在服务器故障转移设置中使用的自动扩展组，或支持KNIME Server Large的分布式KNIME执行器。

# 预先安装的软件（特定于AWS）

为了方便起见，我们已经安装并预先配置了：

# 预装软件

为了方便起见，我们已经安装并预先配置了：

OpenJDK 8（必需）
Anaconda (opens new window) Python（请参阅更新Python配置 (opens new window)）
[R
时间（以确保系统时钟同步）
Postfix（启用KNIME服务器发送电子邮件通知）
iptables（将端口80、443上的请求重定向到端口8080、8443上运行的Tomcat）

# 与执行程序一起安装的扩展

要安装其他扩展，请参阅“安装其他扩展”部分 (opens new window)。

扩展全部来自以下更新站点：

https://update.knime.com/analytics-platform/4.0
https://update.knime.com/community-contributions/trusted/4.0

已安装以下扩展：

# 可选的外部依赖项

（可选）KNIME Server大型实例（当前仅通过BYOL许可证可用）可以选择将KNIME Server连接到外部LDAP / AD服务。完整详细信息包含在《KNIME Server高级安装指南》中 (opens new window)。

# 发行说明

有关KNIME Server软件的更改，请参见发行说明 (opens new window) 和相应的Changelog (opens new window)。

可在变更日志中 (opens new window)找到KNIME Analytics Platform的相关变更 (opens new window)。

下面我们列出了对提交给AWS Marketplace的AMI的所有AWS特定更改。

# 4.9.0

更新的操作系统软件包
更新了Anaconda Python软件包版本
已将Boto3添加到Anaconda环境
添加了符号链接（/ opt / knime / knime-latest）指向KNIME Executor /opt/knime/knime-4.0.0，以使磁盘交换更新 (opens new window)更容易。
更改了knime-server.config以通过符号链接/ opt / knime-latest引用KNIME Executor，以使磁盘交换更新 (opens new window)更容易。
添加了新的扩展（AWS ML服务，ONNX，MLI，Plotly，Erlwood Base，Continental，Slack，Marvin）

# 4.8.2

从Ubuntu 16.04 LTS更新到18.04 LTS。
更新了操作系统软件包。
更新了Anaconda Python软件包版本（默认的Python现在是3.6版）。
包含Chrony，以确保服务器时钟正确同步到AWS内部资源。
服务器和执行器（/ etc / fstab）在/ opt中的位置已更改。
向服务器回购阻止设备添加了名称标签，以支持更轻松的更新。
修正了一些小错误。

# 4.7.2

新图片：KNIME Server Small（包括30天免费试用）
更新了操作系统软件包。
添加了Anaconda Python。
修正了一些小错误。

# 4.6.4

更新的操作系统软件包
更新了系统软件包。
更新了Python软件包版本。
修正了一些小错误。

# 架构概述

提供了一般KNIME Server体系结构的概述。可在《KNIME服务器管理指南》中 (opens new window)找到有关软件体系结构的更详细描述。

# KNIME服务器中小型（AWS）

KNIME Server Small和KNIME Server Medium在VPC的单个子网中作为单个EC2实例运行。首选使用弹性IP，因为它可以简化更新/升级过程。

KNIME服务器中小型简单体系结构

# KNIME Server Large（AWS）

KNIME Server Large支持允许弹性架构的配置，以支持可伸缩性和高可用性。有关这些主题的详细讨论，请参阅推荐的AWS部署（KNIME Server小型/中型/大型（通过BYOL）） (opens new window) 部分。作为参考，我们在此处显示了一种更复杂的体系结构，以支持扩展KNIME Executor以及将服务器实例故障转移到新的可用性区域。

KNIME Server Large可以作为单个EC2实例运行，在这种情况下，可以使用上面的所有指导。

KNIME Server大型可扩展架构

# 安全

《KNIME服务器管理指南》 (opens new window)中描述了有关KNIME Server (opens new window)安全配置的一般注意事项的详细说明。

# 审计追踪

如《KNIME服务器管理指南》中 (opens new window)所述，可以通过KNIME Server AdminPortal或通过在其标准位置访问文件来访问KNIME Server日志文件。

下面介绍了特定于AWS上运行的KNIME Server的配置。

# 访问KNIME服务器实例

不需要根凭据即可访问KNIME Server实例。

# IAM角色和政策

允许访问启动EC2实例并管理EBS卷的IAM角色/策略是启动KNIME Server所必需的。假定具有Internet网关的VPC已配置且可用。

# 使用AWS进行身份验证

KNIME Server不需要使用任何AWS提供的服务进行身份验证。

# 钥匙和轮换政策

实例启动时，将通过AWS管理控制台或CLI创建或选择用于访问KNIME Server实例的SSH密钥。您有责任根据组织内设置的建议来管理此密钥。

# EC2安全组和VPC访问控制列表

默认安全组允许通过HTTP以及端口80和443上的HTTPS访问KNIME服务器。此外，还启用了通过SSH端口22的高级管理员访问。

没有定义VPC访问控制列表。

# 数据加密配置

建议为所有KNIME Server卷启用EBS加密和EBS快照加密。AWS文档中 (opens new window)提供了完整的详细信息。

启用此加密的最简单方法是在可以选择卷选项的阶段选择使用默认密钥启用磁盘加密。

启用全盘加密

# 标记资源

您可能希望标记KNIME Server的EC2实例和卷，以标识例如所有者，成本中心等。请参阅 AWS Tagging Strategy文档 (opens new window)。

# 资料位置

我们使用一种“通用”方法来描述文件位置，然后遵循我们的云市场产品所使用的默认设置。

`` / srv / knime_server

该目录包含KNIME服务器的永久数据和临时数据，例如配置信息，工作流，临时数据。您可能希望备份整个目录，或者如果想要更细粒度的方法，则应继续阅读。该目录的某些部分供进程使用，这些进程可能会从提供良好的IO性能中受益。有关磁盘选择（包括IOPS和云大小）的详细信息，请参阅调整大小 (opens new window)一节。
`` /opt/knime/knime-server-4.11.x/apache-tomcat-9.0.x

Apache Tomcat安装所需的所有数据。包括身份验证，安全性和日志记录的设置。建议备份该目录。
`` /opt/knime/knime-4.2.x

A symbolic link to the latest KNIME Executor (located in the same directory). Contains the executor executable, and all installed extensions. Backup of this directory is recommended.

For a more detailed definition of what type of data is stored in each location, please read on.

# Permanent Data

/config /srv/knime_server/config

Configuration information specific to the KNIME Server. For example the knime-server.config, knime.ini and the customization profiles. Backup of this directory is recommended.
/extensions

Contains some additional information required for extensions to the KNIME Server, such as the preview version of the Workflow Hub. Backup of this directory is recommended.
/jobs

Stores information about running jobs. Practically the jobs are a copy of a workflow from the workflows directory, that then have additional runtime data. Backup of this directory is recommended. Increasing IO provisioning for this directory will help speed up creation of new workflow jobs, or swapping jobs to/from memory.
/licenses

Stores the license file required by the KNIME Server. Backup of this directory is recommended. If you need a license file, contact your KNIME customer care representative, or sales@knime.com
/trash

The location of workflows or data files that have been moved to the KNIME Server 'Recycle Bin'. You may still want to backup this directory to ensure that restore of accidentally deleted files is possible.
/workflows

The store of all workflows that are uploaded to the KNIME Server. Additional metadata such as the permissions on the workflows, and their OpenAPI specification are stored in this directory. Backup of this directory is recommended. Increasing IO provisioning for this directory will help speed up creation of new workflows, and creation of new jobs.

# Ephemeral data

/runtime

Stores information required for locally running executors. This directory will not be used if the distributed executors feature is used. Backup of this directory is not required. It will be regenerated as required. Increasing IO provisioning for this directory will help workflow execution time, especially in the case of 'IO-bound' workflows.
/temp

This directory is used as a temporary store for the Tomcat process of the KNIME Server. E.g. when downloading large files from the server. Backup of this directory is not required.

# Sizing

There is no 'one size fits all' answer to questions around sizing of deployments. The answer will vary depending on your typical workload, number of concurrent users, desired calculation time, and so on. We provide some recommendations to help get started.

# KNIME Server Small/Medium

# Compute considerations

The most compute intensive part of the KNIME Server, is executing workflows. As an example, if you expect 10 concurrent consumers to execute the same analysis workflow on the KNIME Server at approximately the same time. The workflow requires approximately 2GB of RAM, and executes in a reasonable amount of time using 2 cores. To run the workload on a single executor would require 20 GB RAM and 20 cores.

In addition you should reserve up to 4 cores, 4GB RAM for the Tomcat Server process, which is primarily responsible for sharing workflows and data.

# Storage considerations

The Tomcat Server needs a minimum of 30 GB for the operating system, and application itself. Since the Tomcat Server also hosts the KNIME Server Workflow Repository, a minimum of 250 GB additional storage is also recommended for storing workflows, and additional runtime information.

Storing a larger number of workflows, data, or jobs will naturally require more storage.

For more details on which disk locations store which kind of information, please see the section Data locations (opens new window). The section also documents which storage locations may improve application performance as a result of increased IO provisioning.

# KNIME Server Large

Since a typical deployment of KNIME Server Large will make use of the 'Distributed Executors' feature, there are some differences to the considerations needed when sizing a deployment.

# Compute considerations

# Tomcat Server

The Tomcat Server is responsible for managing interactions with the KNIME Server repository. Therefore, when serving a large number of workflows in parallel, or when keeping a large number of jobs in the workflow repository the size of this server may need to be increased. When using distributed KNIME Executors the Tomcat Server will consume four cores from the KNIME Server license. In the majority of setups it will be sufficient to reserve 4 cores to the Tomcat Server. A default installation assigns 2GB RAM to the Tomcat process, although it may be sensible to increase the RAM available to Tomcat to 4-8 GB.

# RabbitMQ

RabbitMQ用作服务器-执行器通信的消息代理。通过队列的流量非常有限。因此，只能为该服务保留1个CPU内核和500Mb RAM。在某些部署中，可能需要将该软件安装在与Tomcat服务器相同的机器上。

# 执行者

为了支持执行大量工作流，可以启动多个执行程序。单个执行器的最小大小应通过考虑执行典型工作流程的CPU和RAM要求以及所需的工作流程并行性来确定。

考虑以下示例。您期望20个并发使用者大致在同一时间在KNIME Server上执行相同的分析工作流。该工作流程需要大约2GB的RAM，并使用2个内核在合理的时间内执行。要在单个执行程序上运行工作负载，将需要40 GB RAM和40个内核。执行程序进程运行约1-2GB的内存会占用少量内存。

如果现在用户数量增加了一倍，则有可能增加执行器机器的大小（将其增加一倍），或者启动第二个执行器，其大小与第一个执行器相同。

使用大量执行者的一个明显好处是，在执行者需求发生变化的情况下，这可以灵活地添加/删除执行者。这需要与运行执行程序的有限额外RAM需求进行权衡。

# 存储注意事项

# Tomcat服务器

KNIME Server Large与KNIME Server Small和Medium具有相同的存储注意事项。有关完整的详细信息，请参阅“存储注意事项 (opens new window)”部分。

# 兔子MQ

RabbitMQ至少需要200 MB的可用空间，并且通常可以以50 GB的根卷启动。

# 执行者

KNIME执行器至少需要30 GB的操作系统和应用程序本身。还需要一定数量的临时存储空间。由于某些KNIME工作流程的执行可能受IO约束（尤其是在有限的RAM可用时），因此建议执行者有权访问SSD级存储。

# 尺寸调整（AWS）

KNIME Server Small和KNIME Server Medium均通过AWS Marketplace出售，它们具有针对5个命名用户的内置许可证，并且最多有8个核心用于工作流执行。此外，KNIME Server Medium允许20个使用者仅通过Web浏览器访问KNIME Server WebPortal。如果您需要大量的用户，消费者或核心，请联系sales@knime.com。

有关调整KNIME Server大小的更一般性讨论，请参阅“大小调整 (opens new window)”部分。

# EC2实例选择

通常，工作流程的执行速度可以受益于其他可用实例RAM。因此，我们建议使用“ R”实例类型，因为它们提供了对RAM的最佳价值访问。

R5a.2xlarge实例具有64 Gb RAM可用，还具有8个CPU内核，因此是KNIME Server Small和KNIME Server Medium可以利用的最大实例。

有关EC2实例类型的完整详细信息，请参见此处 (opens new window)。

# 关于核心计数的注意事项

KNIME执行程序将使用JVM识别内核。在AWS上，默认情况下，KNIME Executor核心等效于vCPU。在某些情况下，您可能会发现通过选择优化每个核心的线程数，可以提高每个核心工作流的执行性能。例如，使用R5a.4xlarge实例，将每个内核的线程设置为1。更改此设置显然会以额外的基础架构成本为代价（r5a.2xlarge与r5a.4xlarge）。有关完整的详细信息，请参阅 AWS文档 (opens new window)。

# EBS音量选择

默认的根实例卷为50Gb SSD（gp2），在大多数情况下，无需增加卷大小。附加卷的默认大小为250Gb SSD（gp2），适用于许多新安装。

为了帮助确定卷的大小，您需要考虑：

预期要存储的工作流程的大小和数量
执行的作业数量和作业保留期限
工作流存储库中存储的其他文件的数量和大小

如果以后需要添加更多存储空间，请参阅“增加工作流存储库EBS卷容量”部分 (opens new window)。

# KNIME服务器大

您可以遵循有关KNIME Server小型/中型的所有建议。但是，在将KNIME Server Large部署与分布式KNIME Executors一起使用时，您可能希望对KNIME Executors使用几种同类实例类型，以便根据所需的Executor工作负载灵活地扩展实例类型。您还可以考虑将KNIME Server实例中的实例类型扩展为稍小的实例类型（不少于4个vcpus），因为现在执行是在KNIME Executor自身上进行的。由于RAM与KNIME Server实例的关联性较小，因此您可以选择“ m”实例而不是“ r”实例。

# 费用

运行KNIME服务器的成本将取决于许多因素。这些包括所需的工作流执行性能，计划存储的数据量，备份策略和计划的故障转移设置。

您的KNIME客户服务代表很乐意为您提供建议和指导，说明这些选择将如何影响您的设置。下面，我们提供一些有关典型设置的信息，以给出一些定价概念。

# 软件定价

KNIME服务器的软件定价在AWS Marketplace中定义。请参阅 AWS Marketplace定价 (opens new window) 有关BYOL许可的问题，请直接发送至sales@knime.com。

# 硬件定价

硬件定价由AWS定义。请参阅AWS定价 (opens new window)。

使用AWS Cost Calculator计算的 (opens new window)所有硬件/服务成本。

# KNIME服务器小型

# 所需的服务（中小型服务器-包括BYOL）

EC2
EBS量
数据输入/输出
可选：EBS快照

# 估计费用

在US-East-1中启动的KNIME Server Small的估计年度成本计算如下：

服务	成本
软件许可费 [ 1 (opens new window) ]的详细信息]	$ 8500.00
EC2实例费用（R5.2xlarge，每年1年全部预付）	$ 2596.00
EBS量收费（16Gb + 250Gb）	$ 360.00
EBS快照（每月+ 10％）	$ 395.88
数据输出（100 Gb /月）	$ 106.92
总计（年度费用）	$ 11958.80

# KNIME服务器介质

# 估计费用

在US-East-1中启动的KNIME Server Medium的估计年度成本计算如下：

服务	成本
软件许可费	$ 21000.00
EC2实例费用（R5.2xlarge，每年1年全部预付）	$ 2596.00
EBS量收费（16Gb + 250Gb）	$ 360.00
EBS快照（每月+ 10％）	$ 395.88
数据输出（100 Gb /月）	$ 106.92
总计（年度费用）	$ 32458.80

# 部署方式

通过单个虚拟机部署KNIME Server Small和KNIME Server Medium。KNIME Server Large为高可用性（HA）部署提供了多个选项。

# KNIME服务器安装

《KNIME Server安装指南》 (opens new window)详细介绍了有关 KNIME Server安装的主题 (opens new window)。此外，我们通过本指南中涵盖的商城提供预配置的图像。

# 测试部署

可以通过Web浏览器登录KNIME Server WebPortal来完成部署的简单测试。某些功能仅可通过KNIME Analytics Platform进行测试。

# 通过浏览器连接

启动KNIME Server AMI后，生成的实例将自动启动KNIME Server。浏览器中提供了KNIME Server WebPortal，网址为：https:///knime

# 通过Analytics平台进行连接

通过KNIME Explorer，可以从KNIME Analytics Platform访问KNIME Server。完整文档可在 KNIME Explorer用户指南中找到。 (opens new window) 使用安装点地址：https:///knime

# 测试工作流程执行

单击WebPortal存储库树中的任何工作流程，然后等待页面加载。如果出现“开始”按钮，则说明工作流执行正常。有关自动测试策略，请参阅部分：操作 (opens new window)。

# 推荐的AWS部署（KNIME Server小型/中型/大型（通过BYOL））

# 部署简单

根据上一大小调整（AWS） (opens new window) 部分中的大小调整准则进行的简单部署如下所示：

03简单拱

# 简单故障转移

一个简单的，非自动化的部署（例如，定期对实例进行快照）可确保在实例损坏时进行灾难恢复。然后，如果需要灾难恢复，只需将Elastic IP从旧实例切换到新实例。

在AWS上进行简单的故障转移

# 冷待机（EFS）

通过将/ srv目录的内容从EBS卷移动到 AWS EFS (opens new window)，可以设置一个故障转移系统，该系统可以准备KNIME Server工作流存储库的最新状态。

系统的故障转移前设置

新实例启动并加载存储库内容时，故障转移将花费几分钟。

系统故障转移

使用此设置可同时恢复实例故障和可用区故障。

	从技术上讲，可以将两个KNIME Server实例连接到同一工作流存储库，但是这样做会导致数据丢失。

# 冷待机（EBS）

在AWS上进行部署使得在实例故障的情况下提供冷备用非常简单。在这种情况下，您可以选择迁移工作流存储库的EBS卷，或者需要对数据块设备进行定期快照。

系统的故障转移前设置

确保要启动冷备份服务器的区域中的快照可用。

系统故障转移

使用AWS Marketplace映像实施此设置时，您将需要修改AMI，以便在实例故障转移时不重置管理员密码。如果使用BYOL映像和KNIME Server Large许可证，建议的解决问题的方法是使用LDAP / Active Directory执行身份验证。对于LDAP不可用的KNIME Server Small / Medium，您将需要通过重命名来禁用密码设置脚本 /opt/init_db.sh

您将需要实现用于管理附加/分离要迁移到故障转移实例的EBS卷的用户数据脚本，并且如果需要迁移到新的可用性区域，则还需要对实例进行快照。由于这种复杂性以及确保可用性区域故障弹性的额外复杂性，在大多数情况下，首选使用AWS EFS的冷备用。

# 推荐的AWS部署（KNIME Server Large）

根据上一“大小调整” (opens new window) 部分中的大小调整指南，典型部署如下所示：

KNIME服务器大型架构

# 默认的KNIME服务器密码

我们没有为KNIME服务器设置固定的默认密码，因为这是已知的不良安全做法。因此，默认密码将在首次启动KNIME Server时设置为AMI的实例ID。这可以在AWS控制台上找到，也可以通过从KNIME Server AMI实例发出命令来找到：

卷http：// 169.254.169.254 / latest / meta-data / instance-id`

首次登录时，建议您创建一个新的管理员用户，然后删除该knimeadmin用户。

# 将许可证文件应用于AWS（BYOL）上的KNIME Server

对于KNIME服务器（BYOL），您需要应用许可证文件。这可以通过https:///knime从Web浏览器访问来完成。

使用管理员用户名：knimeadmin和密码：登录，将您重定向到许可证上载页面。您可以在此处应用许可证文件。有效的许可证文件将立即应用，您可以开始使用所有KNIME Server功能。

您可以在AWS控制台（EC2页面）中找到所需实例的。或者，您可以通过SSH登录实例并发出命令：

卷曲http://169.254.169.254/latest/meta-data/instance-id

# 模板化部署

特别是在KNIME Server Large的情况下，可能需要部署多个实例，并带有网络，安全组和访问策略等其他设置，我们强烈建议您考虑使用模板化部署。模板化部署可以确保不丢失任何重要设置，并且在必要时可以完全复制该部署。

# 模板引擎

在本文档中，我们将为您选择的云平台使用“本机”模板工具来描述一种方法，例如，适用于AWS的CloudFormation或适用于Azure的Azure资源管理器（ARM）。您可能还希望考虑使用第三方工具，例如Terraform。我们没有显示使用Hashicorp Terraform的 (opens new window)特定示例，但是从本机示例进行的翻译应该很简单。

# 模板化的VM构建

在您选择构建自己的映像的情况下，几乎可以肯定，出于与自动化基础结构部署相同的原因，该过程要自动化。使用诸如Hashicorp Packer之 (opens new window)类的工具可以做到这一点。

除了适用于KNIME Server的Marketplace映像（小型，中型，大型或BYOL），您还可以选择从头开始安装和配置KNIME Server。在这种情况下，《KNIME服务器安装指南》中 (opens new window)介绍了安装过程。《KNIME服务器管理指南》 (opens new window)中描述了KNIME Server的 (opens new window)其他配置。

如果要自动构建KNIME服务器“黄金映像”，则应将上述两个文档视为必填信息。然后，有必要调整您的内部构建过程以遵循此过程。不需要任何提及的工具，您可以选择使用其他工具。

我们将详细介绍在KNIME上用于生成Azure Marketplace映像的步骤。我们使用工具Hashicorp Packer (opens new window)来自动化该过程。

该描述并非要详尽列出，而是概述您需要考虑的各种事情。

# KNIME Server小型/中型的打包程序步骤

我们遵循以下步骤：

定义“基本”图像。我们选择Ubuntu 18.04 LTS。
应用最新的操作系统补丁
上载配置文件（preferences.epf，knime.ini，license.xml，autoinstall.xml等）
创建VM用户（knime）
安装所需的依赖项（Java JDK 8）
运行自动化的KNIME Server安装程序
安装可选的依赖项（Python，R，Chrony等）
配置端口转发/防火墙或前端Web服务器
清理图像并泛化

# KNIME Server Large的打包程序步骤

按照KNIME Server Small / Medium的步骤构建“服务器”映像。您可能希望禁用安装执行程序的构建部分。然后执行以下步骤：

定义“基本”图像。我们选择Ubuntu 18.04 LTS。
应用最新的操作系统补丁
上载配置文件（knime.ini，执行程序启动脚本）
创建VM用户（knime）
下载并解压缩KNIME Server Executor
安装可选的依赖项（Python，R，Chrony等）
清理图像并泛化

# AWS CloudFormation模板部署

Whilst it is easy and convenient to deploy the KNIME Server through the AWS Console, there are strong arguments for using a templated deployment using CloudFormation templates (opens new window).

AWS CloudFormation templates allow to describe the full state of the final deployment such that it may be redeployed identically in the future. Similarly it is possible to alter a master template which allows for easy reuse of shared configurations, and customizations where required.

For an overview of the types of deployments possible with a CloudFormation template see the AWS documentation Quickstart templates (opens new window).

# Creating a CloudFormation template

The CloudFormation template describes the AWS infrastructure that is required to be launched for the KNIME Server.

Unresolved directive in index.adoc - include::../common/07b_aws_autoscaling.adoc[]

# KNIME Executors with Auto Scaling Groups

Three components are needed for Auto Scaling KNIME Executors on AWS:

A VPC that hosts KNIME Server, RabbitMQ and the KNIME Executors
An AWS Auto Scaling Group that manages the startup and shutdown of KNIME Executors

	KNIME Server should be deployed in a public subnet, while KNIME Executors should be deployed in a private subnet.

# Setting up the VPC

A Virtual Private Cloud (VPC) within the AWS cloud platform provides a secure networking environment for KNIME Software. Each VPC provides its own networking domain which provides access to and protections from the outside networking world. The divisions are well defined, and layers of network security are provided.

When deploying the KNIME Server within a VPC it is usually deployed within a public subnet. This will allow connections to be made to the Server from the external internet. Security Groups can be used to control access to the KNIME Server (I.e. open ports to specific IP addresses or a range of IP addresses). There are scenarios where the KNIME Server can be deployed within a private subnet. The use cases for this deployment include: all access of the Server will be made within the VPC or the VPC is connected through a VPN to a company’s private network.

KNIME Executors are generally deployed within private subnets. The reasoning here is that the outside world does not need to connect to Executors. Executors only communicate with the KNIME Server and RabbitMQ. When run within an Auto-scaling Group (ASG), the Executors should be run within subnets that are contained in different Availability Zones. This provides a level of resilience to the Executors. If networking within an AZ becomes unavailable, the ASG will automatically initiate new Executors in the still functioning AZ. While overall compute capacity may be lowered in the period while the new Executors are starting up, the service of Executors is not disrupted. And within a short period of time, the desired level of compute capacity will be regained.

The diagram below depicts the typical deployment of KNIME Server with KNIME Executors within a VPC in AWS.

AWS上的VPC设置

# CloudFormation Templates

KNIME provides a CloudFormation (opens new window) template along with the AWS Marketplace AMIs to simplify the creation of the AutoScalingGroup.

# executors.yaml

This stack creates the AutoScalingGroup that governs the KNIME Executors, as well as the security group for those instances; the AMIs for KNIME Executor instances are available on the AWS marketplace.

Open the yaml file in a text editor and edit the RegionMap which specifies the KNIME Executor AMI. Make sure to also set the correct AWS region.

Fill out the template as prompted in the CloudFormation console and create the stack. Select the VPC which the server instance is in. In the Executor Configuration section you need to set the private IP that was assigned to the server instance; do not enter the public IP since the KNIME Executor instances are not allowed to communicate outside of the VPC. Set the target average CPU utilization for the scaling group.

	Using a value here that is too low might cause ASG to scale up twice even though only one scale up is desired. A value of 90% should be an appropriate starting point. It is possible to tweak those settings at a later point in the AutoScalingGroups console.

此外，您需要指定应该启动多少个执行程序的最小和最大限制。如果您不希望动态扩展，而是使用BYOL执行器，则最小值和最大值应设置为相同的值。对于这些情况，ASG允许您在失败的情况下保持正确数量的执行程序运行。

创建堆栈后，将启动指定的最小数量的KNIME Executor实例，它们应自动连接到服务器上的RabbitMQ。

完成此步骤后，即可使用Auto Scaling KNIME执行器。

# 终止KNIME执行器

如果要停止使用此设置，则只需在AWS的CloudFormation部分中删除堆栈。

	这也意味着服务器实例上的所有数据都将丢失，除非已在删除之前对其进行了备份。

# 运作方式

作为任何KNIME Server部署的一部分，您应该考虑监视服务的可用性。KNIME Server具有多个可用于确定系统运行状况的端点。

# 应用故障

对已部署的KNIME服务器的简单REST调用应始终返回200响应，并带有类似于以下内容的有效负载：

卷曲https：// <公共主机名> / knime / rest

rest_response

{
  "@controls" : {
    "self" : {
      "href" : "https://<public-hostname>/knime/rest/",
      "method" : "GET"
    },
    "knime:v4" : {
      "href" : "https://<public-hostname>/knime/rest/v4",
      "title" : "KNIME Server API v4",
      "method" : "GET"
    }
  },
  "version" : {
    "major" : 4,
    "minor" : 8,
    "revision" : 0,
    "qualifier" : ""
  },
  "mountId" : "<public-hostname>",
  "@namespaces" : {
    "knime" : {
      "name" : "http://www.knime.com/server/rels#"
    }
  }
}

不同的响应表示配置问题或应用程序故障。

也有可能测试执行者的可用性。这需要针对KNIME服务器进行身份验证并调用以下REST端点。

curl -X GET“ https：// <公共主机名> / knime / rest / v4 / repository / Examples /测试工作流程（为数据库添加您自己的）/ 01-测试基本工作流程-数据混合：execution？reset = true＆timeout = 300000“ -H” accept：application / vnd.mason + json“

# AZ故障

由于KNIME Server中小型服务器在单个AZ中运行，因此将通过以下所述的应用程序故障检测方法来检测AZ故障。

请参阅“冷备用（EFS）”部分， (opens new window)以查看可应对可用区故障的体系结构示例。

# 实例故障

可以使用AWS Cloudwatch监视实例运行状况来检测实例故障。请参阅冷备用（EFS）部分 (opens new window)以查看可抵抗实例故障的体系结构示例。

# 存储容量

您可以使用标准技术和服务（例如AWS CloudWatch）来监视两个EBS卷（根和数据）的存储容量。有关更多详细信息，请参见此处 (opens new window)。

我们建议在两个卷上的可用空间小于5％时触发警报。

# 安全证书到期

如果基本服务器检查失败并显示HTTP 400状态代码，则证书过期将被捕获。

# 备份与恢复

# 后备

可以根据《KNIME服务器管理指南》中 (opens new window)提供的信息来备份KNIME Server (opens new window)。

重要数据位置在“数据位置 (opens new window)”部分中进行了详细说明

通常，最简单的备份解决方案是为OS卷拍摄快照，再为数据卷拍摄第二张快照。

# 复苏

使用上述“全卷快照”备份方法时，最好通过从快照映像启动新实例来完成系统还原。

# 备份（AWS）

建议使用AWS EBS Snapshot功能。请参阅有关获取EBS快照 (opens new window)的AWS文档部分。

# 恢复（AWS）

要还原AWS EBS快照，请参阅关于还原EBS卷 (opens new window)的AWS文档部分。

# 例行维修

# 启动KNIME服务器

当实例使用标准systemd命令启动时，KNIME Server将自动启动。Tomcat应用程序一旦成功启动，它将自动启动并执行。这意味着在正常操作中，您将不需要以下命令。

如果您需要启动停止的KNIME服务器，则可以在终端上使用以下命令将其启动：

sudo systemctl启动knime-server.service

# 停止KNIME服务器

通过执行以下命令来停止KNIME服务器：

sudo systemctl停止knime-server.service

# 重新启动KNIME服务器

通过执行以下命令来重新启动KNIME服务器：

sudo systemctl重新启动knime-server.service

# Bootnote, for versions older than KNIME Server 4.7

Note that starting, stopping and restarting differs from version 4.7 and older of KNIME Server, where knime-server.service was replaced with apache-tomcat.service

# Restarting the executor (KNIME Server Small/Medium/Large)

It is possible to restart the executor by issuing the following command:

sudo -u knime touch /srv/knime_server/rmirestart

This will launch a new executor, leaving the existing executor running. All existing jobs will continue to run on the old executor, and all new jobs will be launched on the new executor. That is helpful when updating executor preference files without needing to interrupt existing running jobs. When the rmirestart file is automatically deleted, the new executor has been launched.

It is possible to perform a hard kill on a running instance, by issuing the command:

sudo -u knime kill -9 <PID>

where is the process ID of the running executor. You can find the by running:

ps aux | grep knime

and looking for the process(es) that are not the apache-tomcat instance.

# Restarting the executor (KNIME Server Large - Distributed Executors)

In most cases you will want to restart the entire instance that is running the Executor. But in certain cases you may wish to do this by restarting the Executor application itself. That can be acheived either by stopping the executor process, and starting again from the terminal. Or by restarting the systemd service, if it is being used.

sudo systemctl restart knime-executor.service

# Managing Certificates

Detailed steps for managing the SSL certificate for KNIME Server can be found in the KNIME Server Administration Guide (opens new window)

# 默认证书

KNIME Server随附了默认的SSL证书。这允许客户端和服务器之间的加密通信。但是，由于无法为正在运行的服务器预先生成证书，因此不会将其识别为有效证书。因此，我们建议根据“管理证书”中的准则管理自己的证书 (opens new window)。

使用默认证书进行测试时，现代浏览器将发出如下警告。选择忽略警告，将允许您访问KNIME WebPortal进行测试。

10证书发行

# 更新Python配置

我们使用Anaconda Python定义默认的python环境。当前的Yaml文件可在/home/knime/python/py36_knime.yaml中找到。

有关管理Anaconda的详细文档，请参阅 Anaconda文档 (opens new window)。

yaml文件示例如下所示。我们选择了众所周知的使用良好的软件包，或者使用了KNIME深度学习 (opens new window) 软件包所需的软件包。通常，我们固定版本号以确保兼容性。您可以选择取消固定版本号。另外，您可能希望添加一个新的Python软件包，在这种情况下，您可以将该软件包添加到yaml文件中并运行以下命令：

须藤-u knime / home / knime / python / anaconda / bin / conda env更新-f /home/knime/python/py36_knime.yml --prune

py36_knime.yml，来源，yaml (opens new window)

# 应用操作系统补丁

KNIME Server 4.11 AMI基于Ubuntu Server 18.04 LTS。应该使用标准的Ubuntu过程定期修补操作系统。

Java JDK更新后，必须重新启动KNIME服务器。

# 更新KNIME服务器

KNIME服务器论坛上将发布KNIME服务器的更新和补丁。您可以订阅该主题 (opens new window)。

在应用功能更新（例如版本4.8.2→4.9.0）之前，应阅读发行说明和更新指南。这将记录可能影响安装的对参数，功能和设置的任何更改。

如果是补丁更新（例如版本4.8.1→4.8.2），则无需更改所需的设置。

有两种策略可以应用功能或KNIME Server的补丁更新。首先是通过终端（就地更新）遵循《 KNIME服务器更新指南》中的说明。第二个是将工作流存储库块设备的快照迁移到新的KNIME Server实例（磁盘交换更新）。

# 到位更新

要进行功能更新，您可以选择遵循《 KNIME服务器更新指南》中的说明 (opens new window)。

# 安装其他扩展

我们安装了一套我们认为在许多情况下有用的扩展程序 (opens new window)，请参阅与Executors一起安装 (opens new window)的扩展程序 (opens new window)。如果您在本地开发的工作流使用不在列表中的扩展名，则需要将扩展名安装到执行程序中。

# KNIME服务器小型/中型/ BYOL

要安装新的扩展名。

Stop the KNIME Server sudo systemctl stop knime-server
Find the extension on KNIME Hub (opens new window) by searching for the node of interest, and clicking the link to the extensions page.
Determine the `` by modifying the URL, e.g. https://hub.knime.com/knime/extensions/com.knime.features.gateway.remote/latest → com.knime.features.gateway.remote.feature.group
Run the command:

 sudo -u knime /opt/knime-latest/knime -application org.eclipse.equinox.p2.director -nosplash
  -consolelog -r https://update.knime.org/analytics-platform/4.0,https://update.knime.com/community-contributions/trusted/4.0
  -i <extension-identifier> -d /opt/knime/knime-latest

	如果要从另一个更新站点安装扩展，则需要将其添加到命令中。您还需要`` 从KNIME Analytics Platform中已安装的扩展列表中找到“功能组名称”或“功能组名称”。

# KNIME Server Large（分布式执行器）

即将添加说明。

# 磁盘交换更新（AWS）

登录到现有服务器，然后停止KNIME Server服务。请参阅“停止KNIME服务器” (opens new window)部分。
创建工作流存储库块设备的快照。
- 查找需要快照的块设备（在AWS EC2控制台中）
- 创建块设备的快照
- 给快照起个名字
使用先前创建的快照从AWS Marketplace启动新的KNIME Server实例。
- 在AWS控制台上启动新实例
- 将快照分配给新实例
对于从市场图像版本4.7.2进行的更新，需要遵循以下部分中的说明。

有关升级到4.8.2+的注意事项为了更好地支持更新的EC2实例类型，例如使用NVMe块设备的m5，c5和t3系列实例，需要进行一些更改。这意味着从较旧的实例类型进行更新时，需要额外的手动步骤。如果无法执行此步骤，则意味着https://可以访问处的Tomcat管理页面，但https://hostname/knime不能访问处的KNIME服务器。此处 (opens new window)提供有关AWS上NVMe设备的详细信息。lsblk从屏幕截图中，您可以标识将采用nvmeXnY形式的块设备。这是与250GB设备相对应的nvme0n1。临时安装工作流程存储库以设置卷标。确保编辑上一步中的值。nvmeXnY``sudo mount -t /dev/nvmeXnY /test接下来，将“ knime-repo”卷标粘贴到块设备上。完全使用“ knime-repo”将意味着您无需在后续更新中执行此步骤。sudo e2label /dev/nvmeXnY knime-repo如果您使用的卷标与“ knime-repo”不同，则还需要编辑/ etc / fstab以使用相应的卷标将块设备安装到/ srv。编辑/srv/knime_server/config/knime-server.config以将现有行更改为：com.knime.server.executor.knime_exe=/opt/knime/knime-3.7.2/knime重新启动服务器以应用更改。sudo shutdown -r now

# 通过SSH访问AWS上的KNIME Server

通过AWS提供的一般说明， (opens new window)通过SSH访问KNIME Server实例。

始终使用ubuntu用户和KNIME Server实例进行连接，并在实例启动时指定SSH密钥。SSH连接字符串的示例是：

ssh -i  ubuntu@

所有相关的KNIME Server安装和运行时文件均归knime用户所有。为了对这些文件进行更改，需要假定knime用户的身份：

sudo su knime

使用说明始终包含在AWS控制台Usage Instructions选项卡中。

AWS使用说明标签上的KNIME Server

# 更改实例类型

# 升级/降级软件版本

KNIME Server有三种不同的版本，即Small，Medium和Large。可以在此处 (opens new window)找到每个版本的完整功能列表。如果您希望升级以添加更多功能，或者如果不需要某些功能，则希望降级，则可以按照以下说明切换到新版本。

除了更改可用功能之外，还可以增加该软件的许可用户数量。当前，虽然可以通过BYOL许可证使用更多用户，但AWS Marketplace计费映像仅支持5个用户。如果您想向您的AWS Marketplace计费图像添加更多用户，请联系support@knime.com。

# KNIME服务器BYOL

AWS上的KNIME服务器（BYOL）提供了应用从KNIME或KNIME合作伙伴获得的任何有效许可证文件的选项。由于所有功能或许可用户的数量都与许可证文件相关联，因此可以交换许可证文件并立即从新功能中受益。有关如何应用许可证文件的完整详细信息，请参见 [aws-apply-license-file]部分 (opens new window)。

有关分布式KNIME执行器的说明当前在AWS上的KNIME服务器（BYOL）映像是单个AMI，可以支持KNIME Server的Small，Medium或Large功能。如果您希望使用KNIME Server Large和使用服务器映像和KNIME Executor映像的分布式KNIME Executors功能，则需要使用AWS Marketplace中的KNIME Server Large解决方案模板，或联系support @ knime。 com协助您自己构建此部署。

# AWS Small / Medium / Large上的KNIME Server

仅在遵循磁盘交换更新（AWS） (opens new window)说明的情况下在版本之间进行升级/降级。在这种情况下，新启动的映像应为所需的新版本，并且快照磁盘应由现有的安装工作流存储库块设备制成。

# 扩展KNIME服务器实例

如果您的KNIME Server实例永久以高CPU负载运行，则您可能希望扩展到更大的实例大小。相反，可能是从一个太大的实例大小开始的。在这两种情况下，都可以停止KNIME服务器，然后使用其他实例类型重新启动它。

为此，您应该按照此处 (opens new window)的说明进行操作。

# 增加工作流存储库EBS卷容量

启动实例后，可以增加工作流存储库EBS卷的容量（默认大小：250 Gb）。请按照此处 (opens new window)的说明进行操作。

不需要更改根卷的大小。该过程比增加工作流程存储库EBS卷的大小更困难。

# 按键旋转

这里 (opens new window)详细介绍了 (opens new window)管理用于访问KNIME服务器的SSH密钥。

# 紧急维修

如果KNIME Server REST API不可用，则需要重新启动Tomcat Server。

如果REST API可用，但是执行API不能按预期工作，则必须首先重新启动执行程序，如果该程序不起作用，则需要重新启动Tomcat。

有关详细信息，请参见“例行维护” (opens new window)部分。

# 紧急维护（AWS）

如果由于可用区（AZ）性能下降，EC2实例故障等导致KNIME服务器不可用。可以还原快照并启动新实例。

# AZ恢复

通过使用最近的快照 (opens new window)将新实例启动到未受影响的AZ中来管理AZ恢复。

然后将弹性IP从受影响的实例附加到新实例。

# 区域恢复

通过使用最新快照 (opens new window)将新实例启动到不受影响的区域来管理区域恢复。

然后将弹性IP从受影响的实例附加到新实例。

# 支持

KNIME Server通过在KNIME Server论坛中 (opens new window)提交问题来提供小型支持。

通过联系support@knime.com电子邮件地址，还提供了KNIME Server Medium和KNIME Server Large支持。

与KNIME支持人员联系时，您将需要包括您的产品代码，实例ID和AWS账户ID。我们希望在48小时内回答您的问题。

# 查找您的产品详细信息。

查找您的产品代码，实例ID和AWS账户ID：

该AWS文档 (opens new window) 介绍了如何获得访问包含有关实例的信息EC2元数据。您也可以从EC2 Web管理控制台中确定此信息。

# 支持费用

如果您需要其他支持，请联系sales@knime.com了解更多信息。

← KNIME WebPortal管理指南 Azure市场上的KNIME服务器 →