系统要求
ACAL Lynxus 可以运行在简单的笔记本电脑上，也可以跨多台企业级服务器进行集群。因此，所需的硬件和内存量将取决于数据流的规模和性质。数据在 Lynxus 处理时存储在磁盘上。因此，Lynxus 需要为其各种存储库分配足够的磁盘空间，特别是内容存储库、FlowFile 存储库和溯源存储库（有关这些存储库的更多信息，请参阅系统属性部分）。Lynxus 具有以下最低系统要求：
-
需要 Java 21
-
使用基于 Python 的处理器（测试版功能）需要 Python 3.10、3.11 或 3.12
-
支持的操作系统：
-
Linux
-
Unix
-
Windows
-
macOS
-
-
支持的 Web 浏览器：
-
Microsoft Edge：当前版本和前一版本
-
Mozilla FireFox：当前版本和前一版本
-
Google Chrome：当前版本和前一版本
-
Safari：当前版本和前一版本
-
| 在持续和极高的吞吐量下，可能需要调整 CodeCache 设置以避免突然的性能下降。有关更多信息，请参阅引导属性部分。 |
如何安装和启动 Lynxus
-
Linux/Unix/macOS
-
解压并解包到所需的安装目录
-
在
<installdir>/conf下的文件中进行所需的编辑-
至少，我们建议编辑 lynxus.properties 文件并为
lynxus.sensitive.props.key输入密码（参见下方系统属性）
-
-
从
<installdir>/bin目录，通过输入./lynxus.sh <command>执行以下命令：-
start：在后台启动 Lynxus -
stop：停止后台运行的 Lynxus -
status：提供 Lynxus 的当前状态 -
run：在前台运行 Lynxus 并等待 Ctrl-C 启动 Lynxus 关闭
-
-
-
Windows
-
解压到所需的安装目录
-
在
<installdir>\conf下的文件中进行所需的编辑-
至少，我们建议编辑 lynxus.properties 文件并为
lynxus.sensitive.props.key输入密码（参见下方系统属性）
-
-
从
<installdir>\bin目录，通过输入.\lynxus.cmd <command>执行以下命令：-
start：在后台启动 Lynxus -
stop：停止后台运行的 Lynxus -
status：提供 Lynxus 的当前状态
-
-
Lynxus 首次启动时，将创建以下文件和目录：
-
content_repository -
database_repository -
flowfile_repository -
provenance_repository -
work目录 -
logs目录 -
在
conf目录内，创建 flow.json.gz 文件
| 出于安全目的，当未提供安全配置时，Lynxus 现在默认绑定到 127.0.0.1，UI 只能通过此回环接口访问。应配置 HTTPS 属性以从其他接口访问 Lynxus。请参阅安全配置了解如何执行此操作。 |
有关配置 Lynxus 存储库和配置文件的更多信息，请参阅本指南的系统属性部分。
构建自定义分发版
Apache 镜像提供的 ACAL Lynxus 二进制构建不包含官方版本的每个 NAR 文件。这是由于镜像对减少托管如此大型项目相关费用的大小限制。开发者指南有一个列表列出了可选的 Maven 配置文件，可以激活这些配置文件来构建具有这些额外功能的 Lynxus 二进制分发版。
构建和运行 ACAL Lynxus 需要 Java 21。
下一步是从 Lynxus 下载页面 下载 ACAL Lynxus 源代码。您需要源代码构建的原因是它包含一个名为 lynxus-assembly 的模块，这是构建二进制分发的 Maven 模块。展开归档并运行 Maven 清理构建。以下示例展示了如何构建一个分发版，激活 graph 和 media 包配置文件以添加对图数据库和 Apache Tika 内容及元数据提取的支持。
cd <lynxus_source_folder>/lynxus-assembly
./mvnw clean install -Pinclude-grpc,include-graph,include-media
还有一个特定的配置文件允许您使用所有默认不包含的额外包构建 Lynxus：
./mvnw clean install -Pinclude-all
这将包含所有可选包。
端口配置
Lynxus
下表列出了 Lynxus 使用的默认端口以及 lynxus.properties 文件中的相应属性。
| 功能 | 属性 | 默认值 |
|---|---|---|
HTTPS 端口 |
|
|
远程输入套接字端口* |
|
|
集群节点协议端口* |
|
|
集群节点负载均衡端口 |
|
|
| 标有星号 (*) 的端口在 lynxus.properties 中默认具有空白属性值。 |
嵌入式 ZooKeeper
下表列出了 嵌入式 ZooKeeper 服务器 使用的默认端口以及 zookeeper.properties 文件中的相应属性。
| 功能 | 属性 | 默认值 |
|---|---|---|
ZooKeeper 客户端端口（已弃用：自 Lynxus 1.10.x 起不再单独指定客户端端口） |
|
|
ZooKeeper 服务器仲裁和领导者选举端口 |
|
无 |
ZooKeeper 服务器端口的注释示例以 server.N=lynxus-nodeN-hostname:2888:3888;2181 的形式包含在 zookeeper.properties 文件中。
|
配置最佳实践
如果您在 Linux 上运行，请考虑以下最佳实践。典型的 Linux 默认设置不一定针对像 Lynxus 这样的 IO 密集型应用程序的需求进行了良好的调优。对于所有这些领域，您的发行版要求可能有所不同。将这些部分作为建议，但请咨询您的发行版特定文档，了解如何最佳实现这些建议。
最大文件句柄数::Lynxus 在任何时候都可能打开大量的文件句柄。通过编辑 /etc/security/limits.conf 增加限制，添加类似以下内容
* hard nofile 50000 * soft nofile 50000
最大分叉进程数::Lynxus 可以配置为生成大量线程。要增加允许的数量，编辑 /etc/security/limits.conf
* hard nproc 10000 * soft nproc 10000
您的发行版可能还需要编辑 /etc/security/limits.d/90-nproc.conf，添加以下内容
* soft nproc 10000
增加可用的 TCP 套接字端口数量::如果您的流将在短时间内建立和拆除大量套接字，这特别重要。
sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"
设置套接字关闭后在 TIMED_WAIT 状态下的停留时间::您不希望套接字坐在那里太久，因为您希望能够快速建立和拆除新套接字。最好阅读更多相关信息并调整为类似
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait="1"
告诉 Linux 您永远不希望 Lynxus 使用交换空间::交换空间对某些应用程序很有用。但对于像 Lynxus 这样始终希望运行的东西来说并不好。要告诉 Linux 您希望关闭交换空间，可以编辑 /etc/sysctl.conf 添加以下行
vm.swappiness = 0
对于处理各种 Lynxus 存储库的分区，关闭 atime 等功能。这样做可以显著提高吞吐量。编辑 /etc/fstab 文件，并为感兴趣的分区添加 noatime 选项。
建议的杀毒软件排除项
杀毒软件可能需要很长时间来扫描大型目录及其中的大量文件。此外，如果杀毒软件在扫描期间锁定文件或目录，这些资源将无法被 Lynxus 进程使用，导致 Lynxus 实例/集群中出现延迟或不可用。为了防止这些性能和可靠性问题的发生，强烈建议配置杀毒软件跳过以下 Lynxus 目录的扫描：
-
content_repository -
flowfile_repository -
logs -
provenance_repository -
state
日志配置
Lynxus 使用 logback 作为运行时日志记录实现。conf 目录包含一个标准的 logback.xml 配置，带有默认的 appender 和级别设置。logback 手册提供了可用选项的完整参考。
标准日志文件
标准的 logback 配置包括以下 appender 定义和关联的日志文件：
| 文件 | 描述 |
|---|---|
|
应用日志，包含框架和组件消息 |
|
引导日志，包含启动和关闭消息 |
|
弃用日志，包含已弃用组件和功能的警告 |
|
HTTP 请求日志，包含用户界面和 REST API 访问消息 |
|
用户日志，包含身份验证和授权消息 |
映射诊断上下文属性
组件日志提供以下 MDC 命名值：
-
processGroupId包含 Process Group 的 UUID -
processGroupIdPath包含 Process Group 的 UUID 层次结构及分隔符 -
processGroupName包含 Process Group 的名称 -
processGroupNamePath包含 Process Group 的名称层次结构及分隔符
在 Connector 管理的流中运行的组件还携带框架提供的 MDC 值，用于标识所属的 Connector：
-
connectorId包含 Connector 的 UUID -
connectorName包含 Connector 的用户可见名称 -
connectorComponent包含 Connector 实现的完全限定类名 -
connectorBundleGroup、connectorBundleArtifact、connectorBundleVersion标识 Connector 加载来源的 NAR 包
框架的 ConnectorConfigurationProvider 扩展可通过 getLoggingAttributes(String connectorId) 提供额外的实现特定 MDC 值。框架在 Connector 创建时咨询提供程序并将结果与上述框架管理的键合并。框架保留的键（上述列出的键）不能被覆盖；尝试覆盖将被丢弃并记录为 WARN。
MDC 命名值可以使用 mdc 转换字添加到 Logback 模式布局中。
<pattern>%date %level [%thread] %mdc{connectorId} %mdc{processGroupId} %logger{40} %msg%n</pattern>非扩展组件的日志不包含 MDC 命名值。使用模式布局格式化的日志在找不到 MDC 命名值时将包含一个空空格。
弃用日志记录
lynxus-deprecation.log 包含描述将在后续版本中移除的组件和功能的警告消息。应评估并处理弃用警告，以避免在升级到新主版本时出现破坏性变更。解决弃用警告涉及升级到新组件、更改组件属性设置或重构自定义组件类。
弃用日志记录提供了一种在从一个主版本升级到另一个主版本之前检查兼容性的方法。升级到最新的次版本将提供最准确的弃用警告集。
需要注意的是，弃用日志记录同时适用于组件和功能。弃用功能的日志记录需要运行时引用受影响的属性或方法。具有弃用属性或方法的已禁用组件不会生成弃用日志。因此，重要的是对所有已配置的组件进行足够长时间的测试，以覆盖标准流行为。
弃用日志记录可能会根据组件配置和使用模式生成重复的消息。可以通过在 logback.xml 中添加 logger 元素来禁用特定组件类的弃用日志记录。name 属性必须以 deprecation 开头，后跟组件类。将 level 属性设置为 OFF 可禁用指定组件的弃用日志记录。
<logger name="deprecation.cn.org.acal.lynxus.processors.ListenLegacyProtocol" level="OFF" />Python 配置
Lynxus 是一个基于 Java 的应用程序。Lynxus 2.0 引入了对基于 Python 的处理器 API 的支持。此功能仍被视为“测试版”模式，不应在生产环境中使用。默认情况下，对基于 Python 的处理器的支持是禁用的。要启用它，必须在 Lynxus 节点上安装 Python 3.10、3.11 或 3.12。
以下属性可用于配置 Python 3 安装和进程管理。这些属性都位于 lynxus.properties 文件的“Python Extensions”标题下：
| 属性名 | 默认值 | 描述 |
|---|---|---|
lynxus.python.command |
python3 |
用于启动 Python 的命令。默认情况下，此属性设置为“python3”但被注释掉。要启用基于 Python 的处理器，取消注释此行并将其设置为应用于调用 Python 3 的命令。 |
lynxus.python.framework.source.directory |
./python/framework |
包含用于 Python 和 Java 进程之间通信的 Python 框架的目录。API 预期位于此目录的兄弟目录中。例如，如果此属性的值为 |
lynxus.python.extensions.source.directory.default |
./python/extensions |
Lynxus 应查找基于 Python 的处理器的目录。请注意，此属性默认提供，但可以通过添加前缀为 |
lynxus.python.working.directory |
./work/python |
Lynxus 应存储工件的工作目录，例如作为 Python 处理器的依赖项下载的任何第三方库。 |
lynxus.python.max.processes.per.extension.type |
10 |
为任何一类处理器应生成的最大 Python 进程数。由于 Python 无法纵向扩展，在同一个 Python 进程中添加许多 Lynxus 处理器会导致性能很差。相反，Lynxus 为添加到画布的每个 Python 处理器创建一个 Python 进程，但有限制。此属性指示可以为任何特定类型的处理器创建的最大 Python 进程数。例如，如果画布上有 5 个 TransformFoo 处理器实例，且此值设置为 10，则添加另一个 TransformFoo 将生成另一个 Python 进程。但是，在第十个进程之后，添加第十一个 TransformFoo 实例将导致将第二个 TransformFoo 处理器添加到第一个 Python 进程中。这可能导致性能较差，但限制了可以为每种类型的处理器分配的计算资源数量。 |
lynxus.python.max.processes |
100 |
所有处理器合计可生成的最大 Python 进程数。达到此限制后，如果将另一个处理器添加到 Lynxus 画布，新添加的处理器将被添加到为其他相同类型处理器分配的现有 Python 进程之一。如果没有为相同类型分配其他 Python 进程，将抛出异常并且处理器不会被添加到画布中。 |
安全配置
Lynxus 提供了多种不同的安全配置选项。最重要的属性是 lynxus.properties 文件中“security properties”标题下的属性。要安全运行，必须设置以下属性：
| 属性名 | 描述 |
|---|---|
|
包含服务器私钥和证书条目的密钥库文件路径。 |
|
包含一个或多个 X.509 证书的 |
|
包含对应 |
|
密钥库类型。支持的类型包括 |
|
密钥库密码。当未配置 |
|
密钥库中服务器私钥条目的密码。当未配置此属性时，将使用 |
|
包含一个或多个 TLS 连接信任机构证书的信任库文件路径。 |
|
包含一个或多个 X.509 证书的 |
|
信任库类型。支持的类型包括 |
|
信任库密码。 |
配置上述属性后，我们可以启用通过 HTTPS 而非 HTTP 访问用户界面。这通过设置 lynxus.web.https.host 和 lynxus.web.https.port 属性来实现。lynxus.web.https.host 属性指示服务器应运行在哪个主机名上。如果希望从所有网络接口都可以访问 HTTPS 接口，应使用值 0.0.0.0。为了允许管理员配置应用程序仅在特定网络接口上运行，可以指定 lynxus.web.http.network.interface* 或 lynxus.web.https.network.interface* 属性。
启用 HTTPS 时，重要的是 lynxus.web.http.port 属性未设置。Lynxus 仅支持在 HTTP 或 HTTPS 上运行，不能同时运行两者。
|
Lynxus 的 Web 服务器在未配置需要单向 SSL 的替代身份验证机制（例如 LDAP、OpenID Connect 等）时，将要求基于证书客户端身份验证来访问用户界面。启用替代身份验证机制将配置 Web 服务器要求基于证书的客户端身份验证。这将允许它支持具有证书的用户和可能使用凭据登录的无证书用户。有关更多详细信息，请参阅用户身份验证。
现在用户界面已经安全，我们可以轻松地保护站点到站点连接和集群内部通信。这通过将 lynxus.remote.input.secure 属性设置为 true 来实现。这些通信将始终要求双向 SSL，因为节点将使用其配置的密钥库/信任库进行身份验证。
可以使用以下属性启用 Lynxus Web SSL 上下文工厂的自动刷新：
| 属性名 | 描述 |
|---|---|
|
指定当检测到密钥库和信任库的更新时，是否应自动重新加载 SSL 上下文工厂。默认情况下，它设置为 |
|
指定检查密钥库和信任库更新的间隔。仅在 |
将 lynxus.security.autoreload.enabled 属性设置为 true 后，对配置的密钥库和信任库的任何有效更改都将导致 Lynxus 的 SSL 上下文工厂被重新加载，允许客户端获取更改。此功能旨在于允许更新密钥库中的过期证书并在信任库中添加新的信任证书，所有这些都无需重启 Lynxus 服务器。
对任何 lynxus.security.keystore* 或 lynxus.security.truststore* 属性的更改不会被自动刷新逻辑获取，该逻辑假设密码和存储路径保持不变。
|
TLS 密码套件
Java 运行时环境提供了指定自定义 TLS 密码套件的能力，供服务器在接受客户端连接时使用。有关更多信息，请参阅 此处。要为 Lynxus Web 服务使用此功能，可以设置以下 Lynxus 属性：
| 属性名 | 描述 |
|---|---|
|
传入客户端连接可用的密码集。如果设置，则替换系统默认值。 |
|
传入客户端连接不得使用的密码集。如果设置，则过滤可用密码。 |
每个属性应采用逗号分隔的通用密码名列表的形式，如 此处 所指定。也可以指定正则表达式（例如 ^.*GCM_SHA256$）。
语义与以下 Jetty API 的使用相匹配：
用户身份验证
Lynxus 支持使用多种可配置的协议和策略进行用户身份验证。
用户名和密码身份验证由“登录身份提供程序”执行。登录身份提供程序是一种可插拔的机制，用于通过用户名/密码验证用户。使用哪个登录身份提供程序在 lynxus.properties 文件中配置。目前 Lynxus 提供用户名/密码的登录身份提供程序选项，包括单用户、轻量级目录访问协议 (LDAP)和Kerberos。
lynxus.login.identity.provider.configuration.file 属性指定登录身份提供程序的配置文件。默认情况下，此属性设置为 ./conf/login-identity-providers.xml。
lynxus.security.user.login.identity.provider 属性指示应使用哪个已配置的登录身份提供程序。此属性的默认值为 single-user-provider，支持使用生成的用户名和密码进行身份验证。
对于单点登录身份验证，Lynxus 将在返回 Lynxus 之前将用户重定向到身份提供程序。然后 Lynxus 将处理响应并将属性转换为应用程序令牌信息。
| Lynxus 不能同时配置多个身份验证策略。如果未配置其他策略，Lynxus 将要求客户端证书用于通过 HTTPS 进行用户身份验证。 |
除非 lynxus.security.allow.anonymous.authentication 设置为 true，否则用户无法匿名向安全 Lynxus 实例进行身份验证。如果是这种情况，Lynxus 还必须配置一个支持授权匿名用户的 Authorizer。目前，Lynxus 没有附带任何支持此功能的 Authorizer。
| 允许匿名身份验证在后续版本中已弃用并将被移除。 |
设置 lynxus.security.allow.anonymous.authentication 时需要考虑三种场景。当用户直接调用端点而未尝试身份验证时，lynxus.security.allow.anonymous.authentication 将控制请求是被身份验证还是拒绝。另外两种场景是请求被代理时。这可能是由 Lynxus 节点（例如 Lynxus 集群中的节点）代理，或者是由单独的代理为匿名用户代理请求。在这些代理场景中，lynxus.security.allow.anonymous.authentication 将控制请求是被身份验证还是拒绝。在这三种场景中，如果请求被身份验证，随后将根据请求的资源进行正常的授权。
| Lynxus 不通过 HTTP 执行用户身份验证。使用 HTTP 时，所有用户将被授予所有角色。 |
单用户
默认的单用户登录身份提供程序支持自动生成用户名和密码凭据。
生成的用户名将是一个随机 UUID，包含 36 个字符。生成的密码将是一个随机字符串，包含 32 个字符，并使用 bcrypt 哈希存储。
lynxus.properties 中的默认配置启用单用户身份验证：
lynxus.security.user.login.identity.provider=single-user-provider
默认的 login-identity-providers.xml 包含一个空白的提供程序定义：
<provider> <identifier>single-user-provider</identifier> <class>cn.org.acal.lynxus.authentication.single.user.SingleUserLoginIdentityProvider</class> <property name="Username"/> <property name="Password"/> </provider>
可以使用以下命令更改用户名和密码：
$ ./bin/lynxus.sh set-single-user-credentials <username> <password>轻量级目录访问协议 (LDAP)
以下是配置与目录服务器集成以验证用户的登录身份提供程序的示例和描述。
在 lynxus.properties 中设置以下内容以启用 LDAP 用户名/密码身份验证：
lynxus.security.user.login.identity.provider=ldap-provider
修改 login-identity-providers.xml 以启用 ldap-provider。以下是文件中提供的示例：
<provider>
<identifier>ldap-provider</identifier>
<class>cn.org.acal.lynxus.ldap.LdapProvider</class>
<property name="Authentication Strategy">START_TLS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url"></property>
<property name="User Search Base"></property>
<property name="User Search Filter"></property>
<property name="Identity Strategy">USE_DN</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
ldap-provider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
与 LDAP 服务器的连接如何进行身份验证。可能的值为 |
|
用于绑定到 LDAP 服务器以搜索用户的管理员的 DN。 |
|
用于绑定到 LDAP 服务器以搜索用户的管理员的密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库路径。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库类型（例如 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库路径。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库类型（例如 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时的客户端身份验证策略。可能的值为 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的协议（例如 |
|
指定在关闭目标上下文之前是否应优雅地关闭 TLS。默认为 false。 |
|
处理引用的策略。可能的值为 |
|
连接超时的持续时间（例如 |
|
读取超时的持续时间（例如 |
|
LDAP 服务器 URL 的空格分隔列表（例如 |
|
搜索用户的基准 DN（例如 |
|
针对 |
|
识别用户的策略。可能的值为 |
|
用户身份验证有效的持续时间。如果用户从未注销，则在此持续时间后需要重新登录。 |
| 要使 lynxus.properties 和 login-identity-providers.xml 的更改生效，需要重启 Lynxus。如果 Lynxus 是集群的，配置文件在所有节点上必须相同。 |
Kerberos
| Kerberos 提供程序在后续版本中已弃用并将被移除。 |
以下是配置与 Kerberos 密钥分发中心 (KDC) 集成以验证用户的登录身份提供程序的示例和描述。
在 lynxus.properties 中设置以下内容以启用 Kerberos 用户名/密码身份验证：
lynxus.security.user.login.identity.provider=kerberos-provider
修改 login-identity-providers.xml 以启用 kerberos-provider。以下是文件中提供的示例：
<provider>
<identifier>kerberos-provider</identifier>
<class>cn.org.acal.lynxus.kerberos.KerberosProvider</class>
<property name="Default Realm">LYNXUS.ACAL.ORG.CN</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
kerberos-provider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
当用户输入不完整的用户主体时提供的默认域（例如 |
|
用户身份验证有效的持续时间。如果用户从未注销，则在此持续时间后需要重新登录。 |
另请参阅[kerberos_service]以允许通过客户端 Kerberos 票据进行单点登录访问。
| 要使 lynxus.properties 和 login-identity-providers.xml 的更改生效，需要重启 Lynxus。如果 Lynxus 是集群的，配置文件在所有节点上必须相同。 |
OpenID Connect
OpenID Connect 集成提供使用指定授权服务器的单点登录功能。该实现支持 RFC 6749 第 4.1 节 和 OpenID Connect Core 第 3.1.1 节 中描述的授权码授予类型。
授权码授予类型实现支持 RFC 7636 代码交换的密钥证明作为身份验证过程的一部分。PKCE 支持使用 S256 代码挑战方法。
与授权服务器成功身份验证后，Lynxus 生成一个应用 Bearer Token，其过期时间基于 OAuth2 Access Token 的过期时间。Lynxus 使用本地 State Provider 存储已授权的令牌，并使用应用程序敏感属性密钥加密序列化信息。
该实现启用了 OpenID Connect RP-Initiated Logout 1.0，当授权服务器在 OpenID Discovery 配置中包含 end_session_endpoint 元素时。
OpenID Connect 集成支持使用 Refresh Token，如 OpenID Connect Core 第 12 节 所述。Lynxus 跟踪应用 Bearer Token 的过期时间，并根据配置的令牌刷新窗口使用存储的 Refresh Token 在 Bearer Token 过期之前续期访问。Lynxus 不要求 OpenID Connect 提供程序支持 Refresh Token。当 OpenID Connect 提供程序未返回 Refresh Token 时，Lynxus 要求用户在应用 Bearer Token 过期时发起新会话。
Refresh Token 实现允许 Lynxus 会话在 Refresh Token 有效且用户代理提供有效 Bearer Token 的情况下继续。令牌刷新窗口的默认值为 60 秒。对于过期时间为一小时的 Access Token，Lynxus 将在身份验证 Access Token 后 59 分钟收到 HTTP 请求时尝试使用 Refresh Token 续期访问。被撤销的 Refresh Token 或过期的应用 Bearer Token 会导致标准会话超时行为，要求用户发起新会话。
OpenID Connect 实现支持 RFC 7009 中定义的 OAuth 2.0 令牌撤销。OpenID Connect Discovery 配置必须包含支持 RFC 7009 标准的 revocation_endpoint 元素。当已身份验证的资源所有者发起注销过程时，应用程序发送 Refresh Token 的撤销请求。
该实现包含一个定时过程，用于在相应的 Access Token 已过期时移除和撤销过期的 Refresh Token，表明资源所有者已终止应用程序会话。定时会话终止发生在用户关闭浏览器而未发起注销过程时。定时过程避免为不再与应用程序交互的用户长期存储 Refresh Token。
OpenID Connect 实现还支持 RFC 6749 第 4.4 节 中描述的 OAuth 2 客户端凭据授予类型。启用 OpenID Connect 集成后，Lynxus 评估名为 iss 的 JSON Web Token 颁发者声明，并委托给配置的授权服务器或内部处理进行签名验证。当 iss 声明值与 OpenID Connect Discovery Configuration 中的 issuer 匹配时，Lynxus 使用授权服务器的 JSON Web Keys 进行签名验证。在所有其他情况下，Lynxus 使用内部公钥验证 JSON Web Token 签名。
客户端凭据授予类型启用机器到机器身份验证，并需要在 Lynxus 本身之外处理令牌请求以获取 Access Token。Lynxus 还必须配置为基于签名 Access Token 中定义的身份来授权请求。使用客户端凭据授予类型获取的 Access Token 不包含标准的 email，这需要配置回退声明来识别机器用户。最常见的识别声明是名为 sub 的主题声明，其中包含客户端 ID。
OpenID Connect 集成支持在 lynxus.properties 中配置以下设置。
| 属性名 | 描述 |
|---|---|
|
OpenID Connect 提供程序的 Discovery 配置 URL。支持 |
|
与 OpenID Connect 提供程序通信时的套接字连接超时。默认值为 |
|
与 OpenID Connect 提供程序通信时的套接字读取超时。默认值为 |
|
在 OpenID Connect 提供程序注册的 Lynxus 客户端 ID |
|
在 OpenID Connect 提供程序注册的 Lynxus 客户端密钥 |
|
验证身份令牌的首选算法。如果此值为空，则默认为 |
|
除了 |
|
标识已身份验证用户的声明。默认值为 |
|
当 |
|
ID 令牌中包含用户所属组名数组的声明名。应用组必须由具有匹配名称的用户组提供程序提供，以便授权过程使用 ID 令牌声明组。默认值为 |
|
HTTPS 证书信任库策略定义 Lynxus 与 OpenID Connect 提供程序通信时使用的证书颁发机构来源。 |
|
令牌刷新窗口指定在 Lynxus 授权会话过期之前应用程序将尝试使用缓存的 Refresh Token 续期访问的时间量。默认为 |
SAML
要通过 SAML 启用身份验证，必须在 lynxus.properties 中配置以下属性。
配置元数据 URL 和实体标识符可使 ACAL Lynxus 充当 SAML 2.0 依赖方，允许用户使用通过 SAML 2.0 断言方管理的帐户进行身份验证。
| 属性名 | 描述 |
|---|---|
|
获取身份提供程序元数据的 URL。可以通过 |
|
服务提供程序（即 Lynxus）的实体 ID。此值将用作 SAML 身份验证请求的 |
|
包含用户身份的 SAML 断言属性名。此属性是可选的，如果未指定或找不到该属性，则将使用主题的 NameID。 |
|
包含用户所属组名的 SAML 断言属性名。此属性是可选的，但如果填充，组将传递给授权过程。 |
|
控制从 |
|
控制从 |
|
签名 SAML 消息时使用的算法。有关有效值列表，请参阅 Open SAML 签名常量。如果未指定，将使用默认值 SHA-256。默认值为 |
|
SAML 身份验证响应成功后生成的 Lynxus JWT 的过期时间。默认值为 |
|
启用 SAML 单点注销，使 Lynxus 注销时同时注销身份提供程序。默认情况下，Lynxus 注销仅移除 Lynxus JWT。默认值为 |
|
当 IDP 元数据 URL 以 https 开头时的信任库策略。 |
|
与 SAML IDP 通信时的连接超时。默认值为 |
|
与 SAML IDP 通信时的读取超时。默认值为 |
SAML REST 资源
SAML 身份验证启用以下 REST API 资源，用于与 SAML 2.0 断言方集成：
| 资源路径 | 描述 |
|---|---|
/lynxus-api/access/saml/local-logout/request |
完成 SAML 2.0 注销处理而不与断言方通信 |
/lynxus-api/access/saml/login/consumer |
使用 HTTP-POST 或 HTTP-REDIRECT 绑定处理 SAML 2.0 登录请求断言 |
/lynxus-api/access/saml/metadata |
以 XML 格式检索 SAML 2.0 实体描述符元数据 |
/lynxus-api/access/saml/single-logout/consumer |
使用 HTTP-POST 或 HTTP-REDIRECT 绑定处理 SAML 2.0 单点注销请求断言。需要启用单点注销。 |
/lynxus-api/access/saml/single-logout/request |
完成 SAML 2.0 单点注销处理，发起向断言方的请求。需要启用单点注销。 |
JSON Web Token
Lynxus 使用 JSON Web Token 在初始登录过程之后提供已身份验证的访问。生成的 JSON Web Token 包括已身份验证的用户身份以及配置的登录身份提供程序的颁发者和过期时间。
Lynxus 使用生成的 Ed25519 密钥对来支持 JSON Web 签名的 EdDSA 算法。系统使用配置的本地 State Provider 存储 Ed25519 公钥，并在内存中保留私钥。此方法支持在登录身份提供程序中配置的过期时间内进行签名验证，而无需持久化私钥。
JSON Web Token 支持包括注销时使用 JSON Web Token 标识符进行撤销。系统基于登录身份提供程序配置拒绝过期令牌的访问，但撤销在过期之前使令牌无效。系统使用配置的本地 State Provider 存储已撤销的标识符，并运行定时命令在关联过期后删除已撤销的标识符。
可以在 lynxus.properties 中配置以下设置来控制 JSON Web Token 签名。
| 属性名 | 描述 |
|---|---|
|
JSON Web 签名密钥轮换周期定义系统生成新 RSA 密钥对的频率，表示为 ISO 8601 持续时间。默认为一小时： |
X.509 客户端证书
Lynxus 支持在启用 HTTPS 运行时使用双向 TLS 和 X.509 客户端证书进行身份验证，作为标准配置的一部分。客户端证书身份验证在集群部署中 Lynxus 节点之间的通信中是必需的，不能禁用。
Lynxus 在 TLS 握手期间发送证书请求，如 RFC 8446 第 4.3.2 节 中针对 TLS 1.3 所述。当配置为使用登录身份提供程序或单点登录进行身份验证时，Lynxus 发送证书请求但不要求客户端响应。在没有其他身份验证策略的情况下，Lynxus 要求客户端在 TLS 握手过程中提供证书。Lynxus 安全信任库属性定义接受为客户端证书颁发者的证书颁发机构。
代理实体链
Lynxus 支持结合 X.509 客户端证书身份验证的代理实体访问。为双向 TLS 身份验证提供受信任证书的客户端可以通过指定的 HTTP 请求头发送代理身份信息。基于配置的 Authorizer，客户端证书主题主体必须被授权发送代理请求。
授权的代理可以使用 HTTP 请求头和用尖括号字符分隔的值来提供一个或多个代理身份。
-
请求头名称：
X-ProxiedEntitiesChain -
值：
<user-identity>
可以指定多个代理实体以表示代理链。
-
请求头名称：
X-ProxiedEntitiesChain -
值：
<user-identity><proxy-server-identity>
包含超出 US-ASCII 字符的代理身份必须使用 Base64 编码并用额外的尖括号包装。
-
请求头名称：
X-ProxiedEntitiesChain -
值：
<<dXNlci1pZGVudGl0eQ>>
Lynxus 在成功身份验证带有代理实体的 HTTP 请求时包含 HTTP 响应头。
-
请求头名称：
X-ProxiedEntitiesAccepted -
值：
true
Lynxus 在代理实体身份验证失败时包含描述错误的 HTTP 响应头。
-
请求头名称：
X-ProxiedEntitiesDetails -
值：错误消息
跨站请求伪造保护
Lynxus 1.15.0 引入了基于会话 cookie 的用户界面访问的 跨站请求伪造 保护。CSRF 保护在标准 Spring Security 功能 的基础上实现，并采用 双重提交 cookie 策略。实现策略依赖于服务器在会话开始时生成并发送随机请求令牌 cookie。客户端浏览器存储 cookie，JavaScript 应用代码读取 cookie，并在后续请求中将值设置在自定义 HTTP 头中。
Lynxus 将 SameSite 属性设置为 Strict 应用于会话 cookie，指示支持的 Web 浏览器避免在第三方发起的请求上发送 cookie。这些保护措施可以缓解多种潜在威胁。
Cookie 名不被视为公共 REST API 的一部分，可能在次版本中更改。对 Lynxus REST API 的编程 HTTP 请求应使用标准 HTTP Authorization 头发送访问令牌，而不是 Lynxus 用户界面使用的会话 cookie。
包含使用会话亲和性的 HTTP 负载均衡访问的 Lynxus 部署依赖于自定义 HTTP cookie，要求编程客户端在已身份验证会话期间存储和发送 cookie。这些场景中的编程客户端应将 cookie 存储限制为特定于 HTTP 负载均衡器的 cookie 名，以避免与 CSRF 过滤相关的 HTTP 403 Forbidden 错误。
CSRF 实现发送以下 HTTP cookie 来设置会话的随机请求令牌：
-
Cookie 名称：
__Secure-Request-Token -
值：随机 UUID
CSRF 安全过滤器期望在 POST 或 PUT 等非幂等方法上包含以下 HTTP 请求头：
-
请求头名称：
Request-Token -
值：与
__Secure-Request-Tokencookie 头匹配的 UUID
多租户授权
在配置 Lynxus 安全运行并配置身份验证机制后，您必须配置谁有权访问系统以及其访问级别。您可以使用“多租户授权”来实现此目的。多租户授权使多个用户组（租户）能够以不同的授权级别控制、指挥和观察数据流的不同部分。当已身份验证的用户尝试查看或修改 Lynxus 资源时，系统会检查用户是否有权限执行该操作。这些权限由您可以应用于系统范围或单个组件的策略定义。
授权器配置
“授权器”通过在启动时创建初步授权来授予用户管理用户和策略的权限。
授权器使用 lynxus.properties 文件中的两个属性进行配置：
-
lynxus.authorizer.configuration.file属性指定定义授权器的配置文件。默认情况下，选择位于根安装 conf 目录中的 authorizers.xml 文件。 -
lynxus.security.user.authorizer属性指示使用 authorizers.xml 文件中哪个已配置的授权器。
Authorizers.xml 设置
authorizers.xml 文件用于定义和配置可用的授权器。默认授权器是 StandardManagedAuthorizer。托管授权器由 UserGroupProvider 和 AccessPolicyProvider 组成。用户、组和访问策略将通过这些提供程序加载并可选地配置。托管授权器将基于这些提供的用户、组和访问策略做出所有访问决策。
在启动期间，会检查是否存在具有相同身份/名称的两个用户/组。无论配置的实现如何，都会执行此检查。这是必要的，因为这是用户在访问决策期间标识和授权的方式。
FileUserGroupProvider
默认的 UserGroupProvider 是 FileUserGroupProvider，但是您可以开发额外的 UserGroupProvider 作为扩展。FileUserGroupProvider 具有以下属性：
-
Users File - FileUserGroupProvider 存储用户和组的文件。默认情况下，选择
conf目录中的 users.xml。 -
Legacy Authorized Users File - 现有 authorized-users.xml 的完整路径，将自动用于将用户和组加载到 Users File 中。
-
Initial User Identity - 用于种子 Users File 的用户或系统的身份。每个属性的名称必须唯一，例如：“Initial User Identity A”、“Initial User Identity B”、“Initial User Identity C”或“Initial User Identity 1”、“Initial User Identity 2”、“Initial User Identity 3”
-
Initial Group Identity - 用于种子 Users File 的用户组的身份。每个属性的名称必须唯一，例如：“Initial Group Identity A”、“Initial Group Identity B”、“Initial Group Identity C”或“Initial Group Identity 1”、“Initial Group Identity 2”、“Initial Group Identity 3”
LdapUserGroupProvider
UserGroupProvider 的另一个选项是 LdapUserGroupProvider。默认情况下，此选项被注释掉，但可以配置为替代 FileUserGroupProvider。这将从目录服务器同步用户和组，并以只读形式在 Lynxus UI 中显示它们。
LdapUserGroupProvider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
如何身份验证与 LDAP 服务器的连接。可能的值为 |
|
用于绑定到 LDAP 服务器以搜索用户的管理员 DN。 |
|
用于绑定到 LDAP 服务器以搜索用户的管理员密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库路径。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的密钥库类型（如 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库路径。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库密码。 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的信任库类型（如 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时的客户端身份验证策略。可能的值为 |
|
使用 LDAPS 或 START_TLS 连接 LDAP 时使用的协议（如 |
|
指定在关闭目标上下文之前是否应优雅地关闭 TLS。默认为 false。 |
|
处理引用策略。可能的值为 |
|
连接超时时长（如 |
|
读取超时时长（如 |
|
LDAP 服务器 URL 的空格分隔列表（如 |
|
设置检索用户和组时的页大小。如果未指定，则不进行分页。 |
|
设置组成员身份决策是否区分大小写。当推断用户或组时（通过未指定用户或组搜索基准或用户身份属性或组名属性），由于要使用的用户身份或组名值存在歧义，将强制区分大小写。默认为 false。 |
|
同步用户和组之间的时间间隔（如 |
|
搜索用户的基准 DN（如 |
|
标识用户的对象类（如 |
|
搜索用户的搜索范围（ |
|
针对 |
|
用于提取用户身份的属性（如 |
|
用于定义组成员身份的属性（如 |
|
如果为空，则期望 |
|
搜索组的基准 DN（如 |
|
标识组的对象类（如 |
|
搜索组的搜索范围（ |
|
针对 |
|
用于提取组名的属性（如 |
|
用于定义组成员身份的属性（如 |
|
如果为空，则期望 |
| 在 lynxus.properties 中指定的任何身份映射规则也将应用于用户身份。组名不进行映射。 |
组合实现
UserGroupProvider 的另一个选项是组合实现。这意味着可以配置和组合多个来源/实现。例如，管理员可以配置用户/组从文件和目录服务器加载。有两种组合实现，一种支持多个 UserGroupProvider，另一种支持多个 UserGroupProvider 和一个可配置的 UserGroupProvider。
CompositeUserGroupProvider 支持从多个来源检索用户和组。CompositeUserGroupProvider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
要加载的用户组提供程序的标识符。每个属性的名称必须唯一，例如：“User Group Provider A”、“User Group Provider B”、“User Group Provider C”或“User Group Provider 1”、“User Group Provider 2”、“User Group Provider 3” |
| 在 lynxus.properties 中指定的任何身份映射规则在此实现中不适用。此行为需要由基础实现应用。 |
CompositeConfigurableUserGroupProvider 支持从多个来源检索用户和组。此外，需要一个可配置的用户组提供程序。来自可配置用户组提供程序的用户是可配置的，但从 User Group Provider [unique key] 加载的用户则不可配置。CompositeConfigurableUserGroupProvider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
可配置的用户组提供程序。 |
|
要加载的用户组提供程序的标识符。每个属性的名称必须唯一，例如：“User Group Provider A”、“User Group Provider B”、“User Group Provider C”或“User Group Provider 1”、“User Group Provider 2”、“User Group Provider 3” |
FileAccessPolicyProvider
默认的 AccessPolicyProvider 是 FileAccessPolicyProvider，但您也可以开发额外的 AccessPolicyProvider 作为扩展。FileAccessPolicyProvider 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
上述定义的用户组提供程序的标识符，将用于访问用户和组以用于管理的访问策略。 |
|
FileAccessPolicyProvider 存储策略的文件。 |
|
初始管理员用户的身份，将被授予访问 UI 的权限，并能创建额外的用户、组和策略。此属性的值在使用证书或 LDAP 时可以是 DN，或者是 Kerberos 主体。此属性仅在没有其他策略定义时使用。如果指定了此属性，则不能指定 Legacy Authorized Users File。如果同时指定了 |
|
初始管理员组的身份，将被授予访问 UI 的权限，并能创建额外的用户、组和策略。此属性的值在使用证书或 LDAP 时可以是 DN，或者是 Kerberos 主体。此属性仅在没有其他策略定义时使用。如果指定了此属性，则不能指定 Legacy Authorized Users File。 |
|
现有 authorized-users.xml 的完整路径，将自动转换为新的授权模型。如果指定了此属性，则不能指定 Initial Admin Identity 或 Initial Admin Group，且此属性仅在没有其他用户、组和策略定义时使用。 |
|
Lynxus 集群节点的身份。在集群模式下，应为每个节点定义一个属性，以便每个节点都知道其他所有节点。如果不是集群模式，可以忽略这些属性。每个属性的名称必须唯一，例如对于三节点集群：“Node Identity A”、“Node Identity B”、“Node Identity C”或“Node Identity 1”、“Node Identity 2”、“Node Identity 3” |
|
包含 Lynxus 集群节点的组名。典型用途是在节点动态添加/移除集群时使用。 |
| 在 Initial Admin Identity、Initial Admin Group、Node Identity 属性中配置的身份，或在 Legacy Authorized Users File 中发现的身份，必须在配置的用户组提供程序中可用。 |
| 旧版用户文件中的任何用户必须在配置的用户组提供程序中找到。 |
| 在 lynxus.properties 中指定的任何身份映射规则也将应用于节点身份，因此值应为未映射的身份（即证书中的完整 DN）。此身份必须在配置的用户组提供程序中找到。 |
StandardManagedAuthorizer
默认的授权器是 StandardManagedAuthorizer，但您也可以开发额外的授权器作为扩展。StandardManagedAuthorizer 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
上述定义的访问策略提供程序的标识符。 |
FileAuthorizer
FileAuthorizer 已被更细粒度的 StandardManagedAuthorizer 方法所替代，如上所述。但是，出于向后兼容性的原因，它仍然可用。FileAuthorizer 具有以下属性：
| 属性名 | 描述 |
|---|---|
|
FileAuthorizer 存储策略的文件。默认情况下，选择 |
|
FileAuthorizer 存储用户和组的文件。默认情况下，选择 |
|
初始管理员用户的身份，被授予访问 UI 的权限，并能创建额外的用户、组和策略。此属性仅在没有其他用户、组和策略定义时使用。 |
|
现有 authorized-users.xml 的完整路径，将自动转换为多租户授权模型。此属性仅在没有其他用户、组和策略定义时使用。 |
|
Lynxus 集群节点的身份。在集群模式下，应为每个节点定义一个属性，以便每个节点都知道其他所有节点。如果不是集群模式，可以忽略这些属性。 |
| 在 lynxus.properties 中指定的任何身份映射规则也将应用于初始管理员身份，因此值应为未映射的身份。 |
| 在 lynxus.properties 中指定的任何身份映射规则也将应用于节点身份，因此值应为未映射的身份（即证书中的完整 DN）。 |
初始管理员身份（新 Lynxus 实例）
如果您是首次设置安全的 Lynxus 实例，必须在 authorizers.xml 文件中手动指定“Initial Admin Identity”。此初始管理员用户被授予访问 UI 的权限，并能创建额外的用户、组和策略。此属性的值可以是 DN（使用证书或 LDAP 时）或 Kerberos 主体。如果您是 Lynxus 管理员，请将您自己添加为“Initial Admin Identity”。或者，指定“Initial Admin Group”可以将管理访问权限授予一组用户，从而减少对单个人的依赖或避免使用共享帐户。
编辑并保存 authorizers.xml 文件后，重启 Lynxus。“Initial Admin Identity”用户和管理策略将在重启期间添加到 users.xml 和 authorizations.xml 文件中。Lynxus 启动后，“Initial Admin Identity”用户能够访问 UI 并开始管理用户、组和策略。
| 对于全新的安全数据流，提供“Initial Admin Identity”可以让该用户访问 UI 并管理用户、组和策略。但如果该用户想要开始修改数据流，他们需要为自己授予根进程组的策略。系统无法自动执行此操作，因为在新数据流中，根进程组的 UUID 在 flow.json.gz 生成之前不是永久的。如果 Lynxus 实例是从现有的 flow.json.gz 升级的，或者是一个从不安全转为安全的 1.x 实例，则“Initial Admin Identity”用户将自动获得修改数据流的权限。 |
下面描述一些常见用例。
基于文件（LDAP 身份验证）
以下是使用 John Smith 名称的 LDAP 条表示例：
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileUserGroupProvider</class>
<property name="Users File">./conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Initial User Identity 1">cn=John Smith,ou=people,dc=example,dc=com</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">file-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">cn=John Smith,ou=people,dc=example,dc=com</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
基于文件（Kerberos 身份验证）
以下是使用 John Smith 名称和 LYNXUS.ACAL.ORG.CN 域的 Kerberos 条表示例：
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileUserGroupProvider</class>
<property name="Users File">./conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Initial User Identity 1">johnsmith@LYNXUS.ACAL.ORG.CN</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">file-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">johnsmith@LYNXUS.ACAL.ORG.CN</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
基于 LDAP 的用户/组（引用用户 DN）
以下是从 LDAP 加载用户和组的示例。组成员身份将通过每个组的 member 属性驱动。授权仍将使用基于文件的访问策略：
dn: cn=User 1,ou=users,o=lynxus
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 1
sn: User1
uid: user1
dn: cn=User 2,ou=users,o=lynxus
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 2
sn: User2
uid: user2
dn: cn=admins,ou=groups,o=lynxus
objectClass: groupOfNames
objectClass: top
cn: admins
member: cn=User 1,ou=users,o=lynxus
member: cn=User 2,ou=users,o=lynxus
<authorizers>
<userGroupProvider>
<identifier>ldap-user-group-provider</identifier>
<class>cn.org.acal.lynxus.ldap.tenants.LdapUserGroupProvider</class>
<property name="Authentication Strategy">ANONYMOUS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://localhost:10389</property>
<property name="Page Size"></property>
<property name="Sync Interval">30 mins</property>
<property name="Group Membership - Enforce Case Sensitivity">false</property>
<property name="User Search Base">ou=users,o=lynxus</property>
<property name="User Object Class">person</property>
<property name="User Search Scope">ONE_LEVEL</property>
<property name="User Search Filter"></property>
<property name="User Identity Attribute">cn</property>
<property name="User Group Name Attribute"></property>
<property name="User Group Name Attribute - Referenced Group Attribute"></property>
<property name="Group Search Base">ou=groups,o=lynxus</property>
<property name="Group Object Class">groupOfNames</property>
<property name="Group Search Scope">ONE_LEVEL</property>
<property name="Group Search Filter"></property>
<property name="Group Name Attribute">cn</property>
<property name="Group Member Attribute">member</property>
<property name="Group Member Attribute - Referenced User Attribute"></property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">ldap-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">John Smith</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
Initial Admin Identity 的值将根据 User Identity Attribute 的值从 John Smith 的条目的 cn 中加载。
基于 LDAP 的用户/组（引用用户属性）
以下是从 LDAP 加载用户和组的示例。组成员身份将通过每个组的 member uid 属性驱动。授权仍将使用基于文件的访问策略：
dn: uid=User 1,ou=Users,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user1
cn: User 1
dn: uid=User 2,ou=Users,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user2
cn: User 2
dn: cn=Managers,ou=Groups,dc=local
objectClass: posixGroup
cn: Managers
memberUid: user1
memberUid: user2
<authorizers>
<userGroupProvider>
<identifier>ldap-user-group-provider</identifier>
<class>cn.org.acal.lynxus.ldap.tenants.LdapUserGroupProvider</class>
<property name="Authentication Strategy">ANONYMOUS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://localhost:10389</property>
<property name="Page Size"></property>
<property name="Sync Interval">30 mins</property>
<property name="Group Membership - Enforce Case Sensitivity">false</property>
<property name="User Search Base">ou=Users,dc=local</property>
<property name="User Object Class">posixAccount</property>
<property name="User Search Scope">ONE_LEVEL</property>
<property name="User Search Filter"></property>
<property name="User Identity Attribute">cn</property>
<property name="User Group Name Attribute"></property>
<property name="User Group Name Attribute - Referenced Group Attribute"></property>
<property name="Group Search Base">ou=Groups,dc=local</property>
<property name="Group Object Class">posixGroup</property>
<property name="Group Search Scope">ONE_LEVEL</property>
<property name="Group Search Filter"></property>
<property name="Group Name Attribute">cn</property>
<property name="Group Member Attribute">memberUid</property>
<property name="Group Member Attribute - Referenced User Attribute">uid</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">ldap-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">John Smith</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
组合 - 基于文件和 LDAP 的用户/组
以下是从 LDAP 和本地文件加载用户和组的组合实现示例。组成员身份将通过每个组的 member 属性驱动。来自 LDAP 的用户将是只读的，而从文件加载的用户将在 UI 中可配置。
dn: cn=User 1,ou=users,o=lynxus
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 1
sn: User1
uid: user1
dn: cn=User 2,ou=users,o=lynxus
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 2
sn: User2
uid: user2
dn: cn=admins,ou=groups,o=lynxus
objectClass: groupOfNames
objectClass: top
cn: admins
member: cn=User 1,ou=users,o=lynxus
member: cn=User 2,ou=users,o=lynxus
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileUserGroupProvider</class>
<property name="Users File">./conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Initial User Identity 1">cn=lynxus-node1,ou=servers,dc=example,dc=com</property>
<property name="Initial User Identity 2">cn=lynxus-node2,ou=servers,dc=example,dc=com</property>
</userGroupProvider>
<userGroupProvider>
<identifier>ldap-user-group-provider</identifier>
<class>cn.org.acal.lynxus.ldap.tenants.LdapUserGroupProvider</class>
<property name="Authentication Strategy">ANONYMOUS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://localhost:10389</property>
<property name="Page Size"></property>
<property name="Sync Interval">30 mins</property>
<property name="Group Membership - Enforce Case Sensitivity">false</property>
<property name="User Search Base">ou=users,o=lynxus</property>
<property name="User Object Class">person</property>
<property name="User Search Scope">ONE_LEVEL</property>
<property name="User Search Filter"></property>
<property name="User Identity Attribute">cn</property>
<property name="User Group Name Attribute"></property>
<property name="User Group Name Attribute - Referenced Group Attribute"></property>
<property name="Group Search Base">ou=groups,o=lynxus</property>
<property name="Group Object Class">groupOfNames</property>
<property name="Group Search Scope">ONE_LEVEL</property>
<property name="Group Search Filter"></property>
<property name="Group Name Attribute">cn</property>
<property name="Group Member Attribute">member</property>
<property name="Group Member Attribute - Referenced User Attribute"></property>
</userGroupProvider>
<userGroupProvider>
<identifier>composite-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.CompositeConfigurableUserGroupProvider</class>
<property name="Configurable User Group Provider">file-user-group-provider</property>
<property name="User Group Provider 1">ldap-user-group-provider</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">composite-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">John Smith</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1">cn=lynxus-node1,ou=servers,dc=example,dc=com</property>
<property name="Node Identity 2">cn=lynxus-node2,ou=servers,dc=example,dc=com</property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
在此示例中，用户和组从 LDAP 加载，但服务器在本地文件中管理。Initial Admin Identity 的值基于 User Identity Attribute 从 LDAP 条目的属性中加载。Node Identity 的值使用 Initial User Identity 属性在本地文件中建立。
旧版授权用户（Lynxus 实例升级）
如果您正在从 0.x Lynxus 实例升级，可以将之前配置的用户和角色转换为多租户授权模型。在 authorizers.xml 文件中，在 Legacy Authorized Users File 属性中指定现有 authorized-users.xml 文件的位置。
以下是条表示例：
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileUserGroupProvider</class>
<property name="Users File">./conf/users.xml</property>
<property name="Legacy Authorized Users File">/Users/johnsmith/config_files/authorized-users.xml</property>
<property name="Initial User Identity 1"></property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">file-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity"></property>
<property name="Legacy Authorized Users File">/Users/johnsmith/config_files/authorized-users.xml</property>
<property name="Node Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
编辑并保存 authorizers.xml 文件后，重启 Lynxus。来自 authorized-users.xml 文件的用户和角色将被转换并作为身份和策略添加到 users.xml 和 authorizations.xml 文件中。应用启动后，之前拥有旧版管理员角色的用户可以访问 UI 并开始管理用户、组和策略。
如果 Lynxus 实例存在现有的 flow.json.gz，以下表格总结了分配给每个旧版角色的全局和组件策略：
全局访问策略
| Admin | DFM | Monitor | Provenance | Lynxus | Proxy | |
|---|---|---|---|---|---|---|
view the UI |
* |
* |
* |
|||
access the controller - view |
* |
* |
* |
* |
||
access the controller - modify |
* |
|||||
access parameter contexts - view |
||||||
access parameter contexts - modify |
||||||
query provenance |
* |
|||||
access restricted components |
* |
|||||
access all policies - view |
* |
|||||
access all policies - modify |
* |
|||||
access users/user groups - view |
* |
|||||
access users/user groups - modify |
* |
|||||
retrieve site-to-site details |
* |
|||||
view system diagnostics |
* |
* |
||||
proxy user requests |
* |
|||||
access counters |
根进程组上的组件访问策略
| Admin | DFM | Monitor | Provenance | Lynxus | Proxy | |
|---|---|---|---|---|---|---|
view the component |
* |
* |
* |
|||
modify the component |
* |
|||||
view the data |
* |
* |
* |
|||
modify the data |
* |
* |
||||
view provenance |
* |
有关表格中各个策略的详细信息，请参阅访问策略。
如果同时存在 Initial Admin Identity（或 Initial Admin Group）和 Legacy Authorized Users File 属性的值，Lynxus 将无法重启。您只能指定其中一个值来初始化授权。
|
| 不要手动编辑 authorizations.xml 文件。仅在初始设置期间以及之后使用 Lynxus UI 创建授权。 |
集群节点身份
如果您在集群环境中运行 Lynxus，必须指定每个节点的身份。节点通信所需的授权策略在启动期间创建。
例如，如果您正在设置一个 2 节点集群，每个节点的 DN 如下：
cn=lynxus-1,ou=people,dc=example,dc=com cn=lynxus-2,ou=people,dc=example,dc=com
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileUserGroupProvider</class>
<property name="Users File">./conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Initial User Identity 1">johnsmith@LYNXUS.ACAL.ORG.CN</property>
<property name="Initial User Identity 2">cn=lynxus-1,ou=people,dc=example,dc=com</property>
<property name="Initial User Identity 3">cn=lynxus-2,ou=people,dc=example,dc=com</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>cn.org.acal.lynxus.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">file-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">johnsmith@LYNXUS.ACAL.ORG.CN</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1">cn=lynxus-1,ou=people,dc=example,dc=com</property>
<property name="Node Identity 2">cn=lynxus-2,ou=people,dc=example,dc=com</property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>cn.org.acal.lynxus.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
| 在集群中，所有节点必须具有相同的 authorizations.xml 和 users.xml。唯一的例外是节点在加入集群之前具有空的 authorizations.xml 和 user.xml 文件。在这种情况下，节点将在启动期间从集群继承它们。 |
现在初始授权已创建，可以在 Lynxus UI 中创建和管理额外的用户、组和授权。
配置用户和访问策略
根据配置的 UserGroupProvider 和 AccessPolicyProvider 的功能，用户、组和策略可以在 UI 中配置。如果扩展不可配置，则用户、组和策略在 UI 中将是只读的。如果配置的授权器不使用 UserGroupProvider 和 AccessPolicyProvider，则用户和策略可能在 UI 中可见且可配置，具体取决于底层实现。
本节假设用户、组和策略可以在 UI 中配置，并描述以下内容：
-
如何创建用户和组
-
如何使用访问策略定义授权
-
如何查看在用户上设置的策略
-
如何通过具体示例配置访问策略
| 需要与 UI 交互的说明假定应用由 User1 访问，该用户具有管理员权限，例如“Initial Admin Identity”用户或转换的旧版管理员用户（参见Authorizers.xml 设置）。 |
创建用户和组
从 UI 中，从全局菜单选择“Users”。这将打开一个对话框来创建和管理用户和组。
点击添加图标 (
)。要创建用户，请输入与为保护 Lynxus 实例而选择的身份验证方法相关的“Identity”信息。点击确定。
要创建组，选择“Group”单选按钮，输入组名并选择要包含在组中的用户。点击确定。
访问策略
您可以使用“访问策略”管理用户和组查看或修改 Lynxus 资源的能力。可以应用于资源的访问策略有两种类型：
-
查看 — 如果为资源创建了查看策略，则只有添加到该策略的用户或组能够查看该资源的详细信息。
-
修改 — 如果资源有修改策略，则只有添加到该策略的用户或组可以更改该资源的配置。
您可以在全局和组件级别创建和应用访问策略。
全局访问策略
全局访问策略管理以下系统级授权：
| 策略 | 权限 | 全局菜单选择 | 资源描述符 |
|---|---|---|---|
查看 UI |
允许用户查看 UI |
不适用 |
|
访问控制器 |
允许用户查看/修改控制器，包括管理 Controller Service、报告任务、注册表客户端、参数提供程序和集群中的节点 |
控制器设置 |
|
访问参数上下文 |
允许用户查看/修改参数上下文。对参数上下文的访问继承自“访问控制器”策略，除非被覆盖。 |
参数上下文 |
|
访问连接器 |
允许用户查看/修改连接器 |
不适用 |
|
查询溯源 |
允许用户提交溯源搜索和请求事件谱系 |
数据溯源 |
|
访问受限组件 |
允许用户创建/修改受限组件，前提是其他权限足够。受限组件可能指示需要哪些特定权限。可以为特定限制授予权限，也可以不考虑限制而授予权限。如果不考虑限制授予权限，用户可以创建/修改所有受限组件。 |
不适用 |
|
访问所有策略 |
允许用户查看/修改所有组件的策略 |
策略 |
|
访问用户/用户组 |
允许用户查看/修改用户和用户组 |
用户 |
|
检索站点到站点详细信息 |
允许其他 Lynxus 实例检索站点到站点详细信息 |
不适用 |
|
查看系统诊断 |
允许用户查看系统诊断 |
摘要 |
|
代理用户请求 |
允许代理机器代表他人发送请求 |
不适用 |
|
访问计数器 |
允许用户查看/修改计数器 |
计数器 |
|
组件级访问策略
组件级访问策略管理以下组件级授权：
| 策略 | 权限 | 资源描述符和操作 |
|---|---|---|
查看组件 |
允许用户查看组件配置详细信息 |
|
修改组件 |
允许用户修改组件配置详细信息 |
|
操作组件 |
允许用户通过更改组件运行状态（启动/停止/启用/禁用）、远程端口传输状态或终止处理器线程来操作组件 |
|
查看溯源 |
允许用户查看此组件生成的溯源事件 |
|
查看数据 |
允许用户在出站连接的 FlowFile 队列中以及通过溯源事件查看此组件的元数据和内容 |
|
修改数据 |
允许用户清空出站连接中的 FlowFile 队列并通过溯源事件提交重放 |
|
查看策略 |
允许用户查看可以查看/修改组件的用户列表 |
|
修改策略 |
允许用户修改可以查看/修改组件的用户列表 |
|
通过站点到站点接收数据 |
允许端口从 Lynxus 实例接收数据 |
|
通过站点到站点发送数据 |
允许端口从 Lynxus 实例发送数据 |
|
| 要访问连接的列出队列或删除队列，用户需要对组件的“查看数据”和“修改数据”策略具有权限。在集群环境中，所有节点也必须添加到这些策略中，因为用户请求可能通过集群中的任何节点复制。 |
访问策略继承
管理员不需要为数据流中的每个组件手动创建策略。为了减少管理员在授权管理上花费的时间，策略从父资源继承到子资源。例如，如果用户被赋予查看和修改进程组的权限，该用户也可以查看和修改进程组中的组件。策略继承使管理员能够一次性分配策略，并使策略应用于整个数据流。
您可以覆盖继承的策略（如下面移动处理器示例中所述）。覆盖策略将移除继承的策略，断开从父到子的继承链，并创建替换策略以根据需要添加用户。继承策略及其用户可以通过删除替换策略来恢复。
| “View the policies” and “modify the policies” component-level access policies are an exception to this inherited behavior. When a user is added to either policy, they are added to the current list of administrators. They do not override higher level administrators. For this reason, only component specific administrators are displayed for the “view the policies” and “modify the policies" access policies. |
| 您不能修改继承策略上的用户/组。只能从父策略或覆盖策略中添加或移除用户和组。 |
查看用户上的策略
从 UI 中，从全局菜单选择"Users"。这将打开 Lynxus 用户对话框。
选择查看用户策略图标 (
)。
用户策略窗口显示已为所选用户设置的全局和组件级策略。选择前往图标 (
) 导航到画布中的该组件。
访问策略配置示例
了解如何创建和应用访问策略的最有效方法是通过一些常见示例。以下场景假定 User1 是管理员，User2 是仅被授予访问 UI 权限的新添加用户。
让我们从画布上的两个处理器开始作为起点：GenerateFlowFile 和 LogAttribute。
User1 可以向数据流添加组件，并且能够移动、编辑和连接所有处理器。根进程组和处理器的详细信息和属性对 User1 可见。
User1 希望保持其对数据流及其组件的当前权限。
User2 无法向数据流添加组件或移动、编辑或连接组件。根进程组和处理器的详细信息和属性对 User2 隐藏。
移动处理器
要允许 User2 在数据流中移动 GenerateFlowFile 处理器且仅限该处理器，User1 执行以下步骤：
-
选择 GenerateFlowFile 处理器使其高亮显示。2. 从操作面板中选择访问策略图标 (
)，打开访问策略对话框。3. 从策略下拉菜单中选择"修改组件"。处理器（子级）上当前存在的"修改组件"策略是从根进程组（父级）继承的"修改组件"策略，User1 在该策略上具有权限。+
image::processor-modify-policy.png["Processor Modify Policy"] -
选择策略继承消息中的"覆盖"链接。创建替换策略时，您可以选择用继承策略的副本或空策略进行覆盖。选择"覆盖"按钮创建副本。+ image::override_policy_copy_empty.png["Create Override Policy"]
-
在创建的替换策略上，选择添加用户图标 (
)。在用户身份字段中查找或输入 User2，然后选择确定。通过这些更改，User1 保持在画布上移动两个处理器的能力。User2 现在可以移动 GenerateFlowFile 处理器但不能移动 LogAttribute 处理器。+
image::processor-replacement-modify-policy.png["Processor Replacement Modify Policy"]
编辑处理器
在上面的"移动处理器"示例中，User2 被添加到 GenerateFlowFile 的"修改组件"策略中。如果没有查看处理器属性的能力，User2 无法修改处理器的配置。要编辑组件，用户必须同时位于"查看组件"和"修改组件"策略上。为此，User1 执行以下步骤：
-
选择 GenerateFlowFile 处理器。2. 从操作面板中选择访问策略图标 (
)，打开访问策略对话框。3. 从策略下拉菜单中选择"查看组件"。处理器（子级）上当前存在的"查看组件"策略是从根进程组（父级）继承的"查看组件"策略，User1 在该策略上具有权限。+
image::processor-view-policy.png["Processor View Policy"] -
选择策略继承消息中的"覆盖"链接，保留默认的"复制策略"，然后选择"覆盖"按钮。5. 在创建的覆盖策略上，选择添加用户图标 (
)。在用户身份字段中查找或输入 User2，然后选择确定。通过这些更改，User1 保持在画布上查看和编辑处理器的能力。User2 现在可以查看和编辑 GenerateFlowFile 处理器。+
image::processor-replacement-view-policy.png["Processor Replacement View Policy"]
创建连接
按照前两个示例中所述配置访问策略后，User1 能够将 GenerateFlowFile 连接到 LogAttribute：
User2 无法建立连接：
这是因为：
-
User2 没有进程组的修改访问权限。
-
尽管 User2 对源组件（GenerateFlowFile）具有查看和修改访问权限，但 User2 对目标组件（LogAttribute）没有访问策略。
要允许 User2 将 GenerateFlowFile 连接到 LogAttribute，以 User1 身份：
-
选择根进程组。操作面板将更新为根进程组的详细信息。2. 从操作面板中选择访问策略图标 (
)，打开访问策略对话框。3. 从策略下拉菜单中选择"修改组件"。
[start=4]4. 选择添加用户图标 ()。查找或输入 User2，然后选择确定。
通过将 User2 添加到进程组的"修改组件"策略中，User2 通过策略继承被添加到 LogAttribute 处理器的"修改组件"策略中。要确认这一点，请高亮显示 LogAttribute 处理器并从操作面板中选择访问策略图标 ()：
通过这些更改，User2 现在可以将 GenerateFlowFile 处理器连接到 LogAttribute 处理器。
编辑连接
假定 User1 或 User2 向根进程组添加一个 ReplaceText 处理器：
User1 可以选择并更改现有连接（在 GenerateFlowFile 和 LogAttribute 之间），将 GenerateFlowFile 连接到 ReplaceText：
User2 无法执行此操作。
要允许 User2 将 GenerateFlowFile 连接到 ReplaceText，以 User1 身份：
-
选择根进程组。操作面板将更新为根进程组的详细信息。2. 选择访问策略图标 (
)。3. 从策略下拉菜单中选择"查看组件"。
[start=4]4. 选择添加用户图标 ()。查找或输入 User2，然后选择确定。
被添加到进程组的查看和修改策略后，User2 现在可以将 GenerateFlowFile 处理器连接到 ReplaceText 处理器。
加密配置
EncryptContent 处理器支持对 Lynxus 内部和外部来源的数据进行加密和解密。此处理器使用 Java 密码体系结构 (JCA) 执行加密和解密。
密钥派生函数
密钥派生函数 (KDF) 是将人类可读信息（通常是密码）转换为适合在加密算法中使用的加密密钥的机制。
Lynxus Legacy KDF
-
Lynxus 用于 PBE 内部密钥派生的原始 KDF，使用 SHA-256 进行 1000 次迭代的 PBKDF2。
-
此 KDF 在 Lynxus 0.5.0 中已弃用，仅应用于与使用原始 KDF 加密的现有 flow.json.gz 的向后兼容。
Bcrypt
-
此 KDF 在 v0.5.0 中添加。 Lynxus 使用
lynxus.sensitive.props.algorithm属性中指定的算法加密敏感属性值。 -
由于 Bcrypt 派生的哈希长度始终为 184 位，因此哈希输出被截断或填充到所需的密钥长度。
在此之前，完整输出（算法、工作因子、盐和哈希输出，共 480 位）被提供给 SHA-512 摘要函数。Lynxus 可以透明地处理使用通过此旧流程派生的密钥加密的数据（10 MiB 以下）。 -
推荐的最小工作因子为 12（212 次密钥派生轮次）（截至 2/1/2017）。
-
盐格式为
$2a$10$ABCDEFGHIJKLMNOPQRSTUV。盐以$分隔，三个部分如下：-
2a- 格式版本。详细说明可在 此处 找到。Lynxus 目前对所有内部生成的盐使用2a。 -
10- 工作因子。这实际上是 log2 值，因此总迭代次数为 210（1024）。 -
ABCDEFGHIJKLMNOPQRSTUV- 22 个字符、Radix64 编码、无填充的原始盐值。这将解码为密钥派生中使用的 16 字节盐。 以下表格描述了每个 KDF 的属性：NOTE: Bcrypt 的 Radix64 编码与标准 MIME Base64 编码*不*兼容。
-
Scrypt
-
此 KDF 在 v0.5.0 中添加。
-
Scrypt 是一种自适应函数，设计为在计算上密集但在内存上受限。
-
推荐的最小成本为
N=214（16,384）、r=8、p=1（截至 2/1/2017）。 -
盐格式为
$s0$e0101$ABCDEFGHIJKLMNOPQRSTUV。盐以$分隔，三个部分如下：-
s0- 格式版本。Lynxus 目前对所有生成的盐使用s0。 以下算法可用于加密和解密数据流中的敏感属性值：-
某些外部库以
$4000$1$1$的形式分别编码N、r和p（N以十六进制编码存储为0x4000，即0d16384，或 214 因为0xe=0d14）。ScryptCipherProvider#translateSalt()提供了一个工具方法，可将外部形式转换为内部形式。
-
-
ABCDEFGHIJKLMNOPQRSTUV- 12-44 个字符、Base64 编码、无填充的原始盐值。这将解码为密钥派生中使用的 8-32 字节盐。
-
PBKDF2
-
此 KDF 在 v0.5.0 中添加。
-
PBKDF2 是一种密钥派生函数。
-
PRF 推荐使用
HMAC/SHA-256或HMAC/SHA-512。使用 HMAC 密码学哈希函数可以防止长度扩展攻击。 -
推荐的最小迭代次数为 160,000（截至 2/1/2016）。 以下表格描述了每个加密算法的属性：
Argon2
-
此 KDF 在 v1.12.0 中添加。
-
Argon2 是一种密钥派生函数。
-
推荐的最小成本为
memory=216（65,536）KiB、iterations=5、parallelism=8（截至 2020/4/22 在商用硬件上）。Argon2 规范文档 (PDF) 第 9 节描述了一种用于确定推荐参数的算法。这些参数应增加到合法系统遇到有害延迟的阈值（使用Argon2SecureHasherTest#testDefaultCostParamsShouldBeSufficient()计算安全最小值）。 -
盐格式为
$argon2id$v=19$m=65536,t=5,p=8$ABCDEFGHIJKLMNOPQRSTUV。盐以$分隔，四个部分如下：-
argon2id- 算法"类型"（2i、2d、2id）。Lynxus 目前对所有内部生成的盐使用argon2id。 -
v=19- 算法版本（十进制0d19=0x13）。Lynxus 目前对所有内部生成的盐使用0d19。 -
m=65536,t=5,p=8- 成本参数。依次包含内存、迭代次数和并行度。 -
ABCDEFGHIJKLMNOPQRSTUV- 12-44 个字符、Base64 编码、无填充的原始盐值。这将解码为密钥派生中使用的 8-32 字节盐。
-
盐和 IV 编码
最初，EncryptContent 处理器只有一种从用户提供的密码派生加密密钥的方法。现在称为 LynxusLegacy 模式，实际上是 MD5 摘要，1000 次迭代。在 v0.4.0 中，添加了另一种派生密钥的方法 OpenSSL PKCS#5 v1.5 EVP_BytesToKey，用于与使用 openssl 命令行工具在 Lynxus 外部加密的内容兼容。这两种密钥派生函数（KDF）都具有硬编码的摘要函数和迭代次数，盐格式也是硬编码的。在 v0.5.0 中，引入了具有可变迭代次数、工作因子和盐格式的额外 KDF。此外，还引入了*原始密钥加密*。这需要能够将任意盐和初始化向量 (IV) 编码到密码流中，以便 Lynxus 或后续系统可以恢复它们来解密这些消息。
对于现有的 KDF，盐格式没有改变。
Lynxus Legacy
输入的前 8 或 16 字节是盐。盐长度根据所选算法的密码块长度确定。如果无法确定密码块大小（例如使用 RC4 等流密码），则使用默认值 8 字节。在解密时，读入盐并与密码组合以派生加密密钥和 IV。
OpenSSL PKCS#5 v1.5 EVP_BytesToKey
OpenSSL 允许有盐或无盐的密钥派生。*无盐密钥派生存在安全风险，不推荐使用。*如果存在盐，输入的前 8 字节是 ASCII 字符串 “Salted__”（0x53 61 6C 74 65 64 5F 5F），接下来的 8 字节是 ASCII 编码的盐。在解密时，读入盐并与密码组合以派生加密密钥和 IV。如果没有盐头，则整个输入被视为密文。
对于允许非确定性 IV 的新 KDF，IV 必须与密文一起存储。这不是漏洞，因为 IV 不需要保密，只需要对使用相同密钥加密的消息是唯一的，以降低密码攻击的成功率。对于这些 KDF，输出由盐组成，后跟盐分隔符 UTF-8 字符串 “LynxusSALT”（0x4E 69 46 69 53 41 4C 54），然后是 IV，后跟 IV 分隔符 UTF-8 字符串 “LynxusIV”（0x4E 69 46 69 49 56），最后是密文。
数据流中的加密密码
Lynxus 提供了在 lynxus.properties 文件中加密敏感属性值的能力，以防止它们以明文形式存储。使用的加密算法由 lynxus.sensitive.props.algorithm 指定，派生加密密钥的密码由 lynxus.properties 中的 lynxus.sensitive.props.key 指定（更多信息请参见安全配置）。当通过 Lynxus UI 或 Lynxus Toolkit CLI 工具设置值时，将应用加密。Lynxus 支持多种配置选项，使用 AES Galois/Counter Mode (AES-GCM) 提供带关联数据的认证加密 (AEAD)。Lynxus 支持使用多种算法加密敏感属性值。默认算法为 AES/GCM/NoPadding。每个密钥派生函数使用静态盐，以支持跨集群节点的流配置比较。每个密钥派生函数还使用相关安全哈希实现类中定义的默认迭代和成本参数。
属性加密算法
可以在 lynxus.sensitive.props.algorithm 属性中配置以下强加密方法：
-
LYNXUS_ARGON2_AES_GCM_256 -
LYNXUS_PBKDF2_AES_GCM_256
每个密钥派生函数使用以下默认参数：
-
Argon2
-
迭代次数：5
-
内存：65536 KB
-
并行度：8
-
-
PBKDF2
-
迭代次数：160,000
-
伪随机函数族：SHA-512
-
所有选项都需要密码（lynxus.sensitive.props.key 值）至少 12 个字符。
在 1.14.0 或更高版本的新独立安装中，当 lynxus.sensitive.props.key 为空时，Lynxus 会生成一个随机值。Lynxus 将生成的值写入 lynxus.properties 并记录警告。
Lynxus 的集群安装要求所有节点配置相同的值。
Lynxus 工具包管理工具
Lynxus 工具包还包含命令行实用程序，供管理员在独立和集群环境中支持 Lynxus 维护。
-
CLI —
cli工具使管理员能够与 Lynxus 和 Lynxus Registry 实例交互，以自动化部署版本化流程和管理进程组及集群节点等任务。
有关每个实用程序的更多信息，请参阅 Lynxus 工具包指南。
集群配置
本节提供 Lynxus 集群的快速概述以及如何设置基本集群的说明。将来，我们希望提供涵盖 Lynxus 集群架构的补充文档。
无领导者集群
Lynxus 采用无领导者集群范式。集群中的每个节点都有相同的数据流，并对数据执行相同的任务，但每个节点操作不同的数据集。集群自动在所有活动节点之间分配数据。
其中一个节点自动通过 Apache ZooKeeper 选举为集群协调器。集群中的所有节点将向此节点发送心跳/状态信息，此节点负责断开一段时间内未报告任何心跳状态的节点。此外，当新节点选择加入集群时，新节点必须首先连接到当前选举的集群协调器以获取最新的数据流。如果集群协调器确定允许该节点加入（基于其配置的防火墙文件），则当前数据流将提供给该节点，并且该节点能够加入集群，前提是节点的数据流副本与集群协调器提供的副本匹配。如果节点的数据流配置版本与集群协调器的版本不同，则节点不会加入集群。
为什么要集群？
Lynxus 管理员或数据流管理员 (DFM) 可能会发现在单个服务器上使用一个 Lynxus 实例不足以处理其数据量。因此，一种解决方案是在多个 Lynxus 服务器上运行相同的数据流。但是，这会产生管理问题，因为每次 DFM 想要更改或更新数据流时，都必须在每个服务器上进行更改，然后单独监视每个服务器。通过对 Lynxus 服务器进行集群，可以在增加处理能力的同时通过单一界面进行数据流更改和监视数据流。集群允许 DFM 只进行一次更改，然后将该更改复制到集群的所有节点。通过单一界面，DFM 还可以监视所有节点的健康状态和状态。
术语
Lynxus 集群具有独特性，有自己的术语。在设置集群之前，了解以下术语很重要：
Lynxus 集群协调器：Lynxus 集群协调器是 Lynxus 集群中负责执行任务以管理哪些节点允许加入集群以及向新加入节点提供最新数据流的节点。当数据流管理员在集群中管理数据流时，他们可以通过集群中任何节点的用户界面来实现。所做的任何更改都会复制到集群中的所有节点。
节点：每个集群由一个或多个节点组成。节点执行实际的数据处理。
主节点：每个集群有一个主节点。在此节点上，可以运行“隔离处理器”（见下文）。ZooKeeper 用于自动选举主节点。如果该节点因任何原因与集群断开连接，将自动选举新的主节点。用户可以通过查看用户界面的集群管理页面来确定当前哪个节点被选为主节点。
隔离处理器：在 Lynxus 集群中，相同的数据流在所有节点上运行。因此，流中的每个组件都在每个节点上运行。但是，可能存在 DFM 不希望每个处理器在每个节点上运行的情况。最常见的情况是使用与外部服务通信的处理器，该服务使用不能很好扩展的协议。例如，GetSFTP 处理器从远程目录拉取。如果 GetSFTP 处理器在集群中的每个节点上运行并同时尝试从同一远程目录拉取，则可能会出现竞争条件。因此，DFM 可以将主节点上的 GetSFTP 配置为隔离运行，这意味着它仅在该节点上运行。通过适当的数据流配置，它可以拉入数据并在集群的其余节点之间进行负载均衡。请注意，虽然此功能存在，但使用独立的 Lynxus 实例拉取数据并将其提供给集群也是非常常见的。这取决于可用资源以及管理员决定如何配置集群。
心跳：节点通过“心跳”与当前选举的集群协调器通信其健康和状态，让协调器知道它们仍然连接到集群并正常工作。默认情况下，节点每 5 秒发出心跳，如果集群协调器在 40 秒内（= 5 秒 * 8）未收到来自节点的心跳，则因“缺少心跳”而断开该节点。5 秒和 8 次设置可在 lynxus.properties 文件中配置（有关更多信息，请参阅集群通用属性部分）。集群协调器断开节点连接的原因是协调器需要确保集群中的每个节点都是同步的，如果定期未收到节点的消息，协调器无法确定它是否仍与集群的其余部分同步。如果在 40 秒后节点确实发送了新的心跳，协调器将自动请求节点重新加入集群，包括重新验证节点的数据流。由于缺少心跳而断开连接以及收到心跳后重新连接都会在用户界面中报告给 DFM。
集群内的通信
如前所述，节点通过心跳与集群协调器通信。当选举集群协调器时，它会更新 Apache ZooKeeper 中的一个知名 ZNode，其中包含其连接信息，以便节点了解将心跳发送到哪里。如果其中一个节点宕机，集群中的其他节点不会自动接管缺失节点的负载。DFM 可以为故障转移应急情况配置数据流；但是，这取决于数据流设计，不会自动发生。
当 DFM 对数据流进行更改时，接收更改流请求的节点会将这些更改通信给所有节点，并等待每个节点响应，指示它已在本地流上进行了更改。
管理节点
断开节点
DFM 可以手动将节点从集群中断开。节点也可能因其他原因断开连接，例如网络故障或节点崩溃。
断开的节点可能仍在正常工作。这可能由几个原因造成。
需要注意的是，已断开连接的节点的数据流允许被更改。但是，任何更改都应谨慎进行，因为当节点重新连接到集群时，这些更改将被还原。此外，如果还原更改会导致数据丢失，则该节点将不允许重新加入集群。如果在断开连接的节点上已经创建了新的数据流，就可能发生这种情况。
要手动断开节点，请从节点行中选择"断开连接"图标 (
)。
已断开连接的节点可以重新连接 (
)、卸载 (
) 或删除 (
)。
| 并非所有处于"已断开连接"状态的节点都可以卸载。如果节点已断开连接且无法访问，则节点无法接收卸载请求以开始卸载。此外，防火墙规则可能会中断或阻止卸载。 |
卸载节点
断开连接节点上剩余的 FlowFile 可以通过卸载重新平衡到集群中的其他活动节点。在"集群管理"对话框中，为已断开的节点选择"卸载"图标 ()。这将停止所有处理器、终止所有处理器、停止所有远程进程组的传输，并将 FlowFile 重新平衡到集群中其他已连接的节点。
由于遇到错误（内存不足、无网络连接等）而保持在"卸载中"状态的节点，可以通过在节点上重启 Lynxus 来重新连接到集群。已卸载的节点可以重新连接到集群（通过选择"连接"或在节点上重启 Lynxus）或从集群中删除。
删除节点
在某些情况下，DFM 可能希望继续对数据流进行更改，即使节点未连接到集群。在这种情况下，DFM 可以选择从集群中完全删除该节点。在"集群管理"对话框中，为已断开或已卸载的节点选择"删除"图标 ()。删除后，节点在重启之前无法重新加入集群。
Lynxus CLI 节点命令
作为 UI 的替代方案，以下 Lynxus CLI 命令可用于检索单个节点、检索节点列表，以及连接/断开/卸载/删除节点：
-
lynxus get-node -
lynxus get-nodes -
lynxus connect-node -
lynxus disconnect-node -
lynxus offload-node -
lynxus delete-node
有关更多信息，请参阅 Lynxus CLI 部分（位于 Lynxus 工具包指南）。
流程选举
当集群首次启动时，Lynxus 必须确定哪些节点具有"正确"版本的数据流。这是通过对每个节点的数据流进行投票来完成的。当节点尝试连接到集群时，它会将其本地数据流的副本以及（如果策略提供程序允许通过 Lynxus 进行配置）其用户、组和策略提供给集群协调器。如果尚未选举出"正确"的数据流，则将该节点的数据流与其他每个节点的数据流进行比较。如果另一个节点的数据流与此节点匹配，则为该数据流投一票。如果尚无其他节点报告相同的数据流，则将此数据流添加到可能当选的数据流池中，并计一票。在经过一段时间（通过设置 lynxus.cluster.flow.election.max.wait.time 属性配置）或一定数量的节点已投票（通过设置 lynxus.cluster.flow.election.max.candidates 属性配置）后，一个数据流被选为"正确"的数据流副本。
任何数据流、用户、组和策略与当选结果冲突的节点将备份任何冲突的资源，并用集群中的资源替换本地资源。备份的方式取决于配置的访问策略提供程序和用户组提供程序。对于基于文件的访问策略提供程序，备份将写入与现有文件相同的目录（例如 $LYNXUS_HOME/conf），并使用相同的文件名但附加 "." 和时间戳后缀。例如，如果数据流本身在 2020 年 1 月 1 日 12:05:03与集群的数据流冲突，节点的 flow.json.gz 文件将被复制为 flow.json.gz.2020-01-01-12-05-03，然后集群的数据流将写入 flow.json.gz。类似地，users.xml 和 authorizations.xml 文件也会这样处理。这样做是为了在必要时可以手动还原数据流，例如通过将备份文件重命名回 flow.json.gz。需要注意的是，在继承当选数据流之前，Lynxus 将首先读取 FlowFile 存储库和任何交换文件，以确定需要注意的是，在继承当选数据流之前，Lynxus 将首先读取 FlowFile 存储库和任何交换文件，以确定数据流中哪些队列当前持有数据。如果数据流中存在包含 FlowFile 的队列，则该队列也必须存在于当选的数据流中。如果该队列不存在于当选的数据流中，节点将不会继承数据流、用户、组和策略。相反，Lynxus 将记录相关错误日志并无法启动。这确保即使节点在连接中存储了数据，而集群的数据流不同，重启节点也不会导致数据丢失。选举根据"多数票"进行，但有一个例外：除非所有数据流都为空，否则当选者永远不会是"空数据流"。这允许管理员删除节点的 flow.json.gz 文件并重启节点，知道该节点的数据流不会被选为"正确"的数据流，除非没有找到其他数据流。如果有两个非空数据流获得相同的票数，将选择其中一个数据流。用于确定选择哪个数据流的方法未定义，可能随时更改而不另行通知。
基本集群设置
本节描述了一个简单的三节点非安全集群的设置，由三个 Lynxus 实例组成。
对于每个实例，需要更新 lynxus.properties 文件中的某些属性。特别是 Web 和集群属性应根据您的情况进行评估并相应调整。所有属性都在本指南的系统属性部分中描述；但是，在本节中，我们将重点介绍简单集群必须设置的最少属性。
对于所有三个实例，集群通用属性可以保留默认设置。但请注意，如果您更改这些设置，则必须在集群中的每个实例上设置相同。
对于每个节点，要配置的最少属性如下：
-
在 Web 属性 部分，设置您希望节点运行的 HTTP 或 HTTPS 端口。 此外，请考虑是否需要设置 HTTP 或 HTTPS 主机属性。集群中的所有节点应使用相同的协议设置。
-
在 状态管理 部分，将
lynxus.state.management.provider.cluster属性 设置为集群状态提供程序的标识符。确保集群状态提供程序已在 state-management.xml 文件中配置。更多信息请参见配置状态提供程序。 -
在 集群节点属性 下，设置以下内容：
-
lynxus.cluster.is.node- 设置为 true。 -
lynxus.cluster.node.address- 设置为节点的完全限定主机名。如果留空，则默认为localhost。 -
lynxus.cluster.node.protocol.port- 设置为高于 1024 的开放端口（低于 1024 需要 root 权限）。 -
lynxus.cluster.node.protocol.max.threads- 用于与集群中其他节点通信的最大线程数。此属性 默认为50。线程池用于向所有节点复制请求。线程池将增加活动线程数到此属性设置的限制。通常建议将此属性设置为集群节点数的 4-8 倍。对于给定请求，最多可能有n+2个线程，其中n= 集群中的节点数。例如，如果发出 4 个请求，5 节点集群将使用4 * 7 = 28个线程。 -
lynxus.cluster.flow.election.max.wait.time- 指定在选举数据流为"正确"数据流之前等待的时间量。 如果已投票的节点数等于lynxus.cluster.flow.election.max.candidates`属性指定的数量，集群不会等待这么长时间。默认值为 `5 mins。请注意，时间从第一次投票开始计算。 -
lynxus.cluster.flow.election.max.candidates- 指定集群中导致提前选举数据流所需的节点数。 这允许集群中的节点在达到至少此数量的节点时，避免长时间等待后才开始处理。集群中至少有此数量的节点。
-
ZooKeeper 集群
以下应用属性支持使用 Apache ZooKeeper 进行集群：
-
lynxus.cluster.leader.election.implementation
领导者选举实现必须设置为 CuratorLeaderElectionManager 才能使用 Apache ZooKeeper 进行集群。未指定此属性时，实现默认使用基于 ZooKeeper 的集群。
-
lynxus.zookeeper.connect.string
连接到 Apache ZooKeeper 所需的连接字符串。这是一个逗号分隔的主机名:端口对列表。例如 localhost:2181,localhost:2182,localhost:2183。这应包含 ZooKeeper仲裁中所有 ZooKeeper 实例的列表。
-
lynxus.zookeeper.root.node
应在 ZooKeeper 中使用的根 ZNode。ZooKeeper 提供类似目录的结构用于存储数据。此结构中的每个"目录"称为 ZNode。这表示应用于存储数据的根 ZNode 或"目录"。默认值为 /root。正确设置此项很重要，因为Lynxus 实例尝试加入的集群取决于它连接的 ZooKeeper 实例和指定的 ZooKeeper 根节点。
Kubernetes 集群
Kubernetes 集群需要授权才能使用以下API 请求动词 与 Kubernetes Leases 交互：
-
create -
get -
update
以下应用属性支持使用 Kubernetes 进行集群：
-
lynxus.cluster.leader.election.implementation
领导者选举实现必须设置为 KubernetesLeaderElectionManager 才能使用 Kubernetes 进行集群。该实现创建和管理 Kubernetes Leases，用于集群协调和主节点跟踪。
Lynxus 运行所在的服务帐户必须被授予成功集群操作所需的权限。
-
lynxus.cluster.leader.election.kubernetes.lease.prefix
应用于 Kubernetes Leases 的前缀字符串默认为空字符串。在单独的Kubernetes 命名空间中运行 ACAL Lynxus 集群是使用默认应用属性的标准预期。当在同一 Kubernetes 命名空间中运行多个 Lynxus 集群时，需要配置唯一的租约前缀以避免租约对象冲突。
集群防火墙配置
Lynxus 集群支持使用自定义防火墙配置进行网络访问限制。lynxus.cluster.firewall.file 属性可以配置为指向包含允许节点的主机名、IP 地址或子网的文件路径。集群协调器使用此配置来确定是接受还是拒绝来自潜在集群成员的心跳和连接请求。
配置文件格式为每行一个条目，忽略以 # 字符开头的行。Lynxus 使用标准 Java 主机名解析将名称转换为 IP 地址。Java 主机名解析利用本地机器配置和网络服务（如 DNS）的组合。配置文件支持使用 CIDR 表示法的 IPv4 地址或子网范围。以下示例集群防火墙配置包含了支持的条目组合：
# Cluster Node Hostnames lynxus0.example.com lynxus1.example.com lynxus3.example.com # Cluster Node Addresses 192.168.0.1 192.168.0.2 192.168.0.3 # Cluster Subnet Address 192.168.0.0/29 # Address Range from 192.168.0.1 to 192.168.0.6
状态管理
Lynxus 提供了一种机制，使处理器、报告任务、控制器服务以及框架本身能够持久化状态。这使例如处理器能够在 Lynxus 重启后从上次停止的地方恢复。此外，它允许处理器存储某些信息，以便处理器可以从集群中的所有不同节点访问该信息。这允许一个节点从另一个节点停止的地方继续，或者在集群中的所有节点之间进行协调。
配置状态提供程序
当组件决定存储或检索状态时，它通过提供 Scope（要么是对节点本地的 Local，要么适用于整个 Cluster）来实现。组件实现代码和配置属性确定请求的 Scope，框架根据状态管理配置提供。lynxus.properties 配置包含用于管理这些状态提供程序的多个属性。
属性 |
描述 |
|
配置文件指定外部 XML 文件的路径，框架使用该文件配置状态提供程序。此 XML 文件可能包含多个提供程序的配置。 |
|
本地提供程序存储当前本地状态信息。属性值标识状态管理配置中的本地提供程序，框架将使用该提供程序为请求组件存储和检索本地状态。 |
|
集群提供程序存储当前集群状态信息。属性值标识状态管理配置中的集群提供程序，框架将使用该提供程序为请求组件存储和检索集群状态。 |
|
上一个集群状态提供程序启用从现有提供程序填充当前集群状态。属性值标识状态管理配置中的集群提供程序，当当前集群状态提供程序没有存储任何信息时，框架将使用该提供程序作为集群状态的初始来源。 当节点成为主节点时，框架枚举当前集群提供程序，并在当前集群提供程序不包含任何组件信息时继续检查上一个集群提供程序。在集群启动后从备份成功恢复集群状态后，可以将上一个集群提供程序属性值设置为空。 默认值为空。 |
此 XML 文件由一个顶级 state-management 元素组成，该元素具有一个或多个 local-provider 和零个或多个 cluster-provider 元素。这些元素中的每一个都包含一个 id 元素，用于指定可以在 lynxus.properties 文件中引用的标识符，以及一个 class 元素，指定用于实例化状态提供程序的完全限定类名。最后，这些元素中的每一个可能有零个或多个 property 元素。每个 property 元素有一个属性 name，它是状态提供程序支持的 property 的名称。属性元素的文本内容是属性的值。
在 state-management.xml 文件（或配置的任何文件）中配置了这些状态提供程序后，可以通过其标识符引用它们。
虽然不需要为这些提供程序配置很多属性，但它们被外部化为单独的 state-management.xml 文件，而不是通过 lynxus.properties 文件配置，只是因为不同的实现可能需要不同的属性，并且在基于 XML 的文件中维护和理解配置比将提供程序的属性与其他 Lynxus 框架特定属性混合在一起更容易。
需要注意的是，如果处理器和其他组件使用集群 Scope 保存状态，则如果实例是独立实例（不在集群中）或与集群断开连接，则将使用本地状态提供程序。这也意味着，如果将独立实例迁移为集群，则该状态将不再可用，因为组件将开始使用集群状态提供程序而不是本地状态提供程序。
如果 Lynxus 配置为以独立模式运行，则 state-management.xml 文件中不需要填充 cluster-provider 元素，如果填充了它们实际上会被忽略。但是，local-provider 元素必须始终存在并填充。此外，如果 Lynxus 在集群中运行，则每个节点还必须存在并正确配置 cluster-provider 元素。否则，Lynxus 将无法启动。
ZooKeeper 集群状态提供程序
默认集群状态提供程序配置为 ZooKeeperStateProvider。默认的基于 ZooKeeper 的提供程序必须先填充其 Connect String 属性才能使用。如果多个 Lynxus 实例将使用相同的 ZooKeeper 实例，还建议更改 Root Node 属性的值。例如，可以将值设置为 /lynxus/<team name>/production。Connect String 采用逗号分隔的 <host>:<port> 元组的形式，例如 my-zk-server1:2181,my-zk-server2:2181,my-zk-server3:2181。如果未为任何主机指定端口，则假设使用 ZooKeeper 默认值 2181。
向 ZooKeeper 添加数据时，访问控制有两个选项：Open 和 CreatorOnly。如果 Access Control 属性设置为 Open，则任何人都可以登录 ZooKeeper 并拥有完全权限来查看、更改、删除或管理数据。如果指定了 CreatorOnly，则只有创建数据的用户才允许读取、更改、删除或管理数据。要使用 CreatorOnly 选项，Lynxus 必须提供某种形式的身份验证。有关如何配置身份验证的更多信息，请参阅下面的ZooKeeper 访问控制部分。
Kubernetes ConfigMap 集群状态提供程序
Kubernetes ConfigMap 状态提供程序支持在 Kubernetes 中运行时共享集群状态。
该提供程序将组件状态存储在Kubernetes ConfigMaps中，并需要使用以下API 请求动词 与 ConfigMap 交互的授权：
-
create -
delete -
get -
list -
patch -
update
如 Kubernetes 文档中所述，ConfigMap 中存储的数据限制为 1 MB。使用集群状态的组件必须限制存储的信息量。
Kubernetes ConfigMap 状态提供程序支持以下配置属性：
-
ConfigMap 名称前缀
应用于 Kubernetes ConfigMap 名称的前缀字符串默认为空字符串。在单独的Kubernetes 命名空间中运行 ACAL Lynxus 集群是使用默认应用属性的标准预期。当在同一 Kubernetes 命名空间中运行多个 Lynxus 集群时，需要配置唯一的 ConfigMap 前缀以避免 ConfigMap 对象冲突。
嵌入式 ZooKeeper 服务器
如上所述，集群范围状态的默认状态提供程序是 ZooKeeperStateProvider。在撰写本文时，这是唯一用于处理集群范围状态的状态提供程序。这意味着 Lynxus 依赖于 ZooKeeper 才能作为集群运行。但是，在许多部署 Lynxus 的环境中，没有维护现有的 ZooKeeper 集合。为了避免迫使管理员也维护单独的 ZooKeeper 实例的负担，Lynxus 提供了启动嵌入式 ZooKeeper 服务器的选项。
属性 |
描述 |
|
指定此 Lynxus 实例是否应运行嵌入式 ZooKeeper 服务器 |
|
当 |
这可以通过在应运行嵌入式 ZooKeeper 服务器的节点上将 lynxus.properties 中的 lynxus.state.management.embedded.zookeeper.start 属性设置为 true 来实现。通常，建议在 3 个或 5 个节点上运行 ZooKeeper。运行少于 3 个节点在故障时的持久性较低。运行超过 5 个节点通常会产生比必要更多的网络流量。此外，运行 4 个节点的 ZooKeeper 并不比运行 3 个节点提供更多好处，ZooKeeper 需要大多数节点处于活动状态才能运行。但是，由管理员确定最适合特定 Lynxus 部署的节点数。
如果 lynxus.state.management.embedded.zookeeper.start 属性设置为 true，则 lynxus.properties 中的`lynxus.state.management.embedded.zookeeper.properties` 属性也将变得相关。这指定要使用的 ZooKeeper 属性文件。至少，此属性文件需要填充 ZooKeeper 服务器列表。服务器以 server.1、server.2 到 server.n 的形式指定为属性。自 Lynxus 1.10.x 起，ZooKeeper 已升级到 3.5.5，服务器的定义方式现在按照 ZooKeeper 文档 在末尾附加客户端端口。因此，每个服务器的配置格式为 <hostname>:<quorum port>[:<leader election port>][:role];[<client port address>:]<client port>。简单示例为 server.1 = myhost:2888:3888;2181。此节点列表应与 Lynxus 集群中 lynxus.state.management.embedded.zookeeper.start 属性设置为 true 的节点相同。另请注意，由于 ZooKeeper 将监听这些端口，可能需要配置防火墙以打开这些端口用于传入流量，至少在集群中的节点之间。
使用嵌入式 ZooKeeper 时，./conf/zookeeper.properties 文件有一个名为 dataDir 的属性。默认情况下，此值设置为 ./state/zookeeper。如果多个 Lynxus 节点运行嵌入式 ZooKeeper，告诉服务器它是哪个很重要。这可以通过创建一个名为 myid 的文件并将其放在 ZooKeeper 的数据目录中来实现。此文件的内容应为 server.<number> 指定的服务器索引。因此对于其中一个 ZooKeeper 服务器，我们将通过执行以下命令来完成此操作：
cd $LYNXUS_HOME
mkdir state
mkdir state/zookeeper
echo 1 > state/zookeeper/myid对于将运行 ZooKeeper 的下一个 Lynxus 节点，我们可以通过执行以下命令来完成此操作：
cd $LYNXUS_HOME
mkdir state
mkdir state/zookeeper
echo 2 > state/zookeeper/myid依此类推。
有关用于管理 ZooKeeper 的属性的更多信息，请参见ZooKeeper 管理员指南。
有关保护嵌入式 ZooKeeper 服务器安全的信息，请参见下方的使用 Kerberos 保护 ZooKeeper部分。
ZooKeeper 访问控制
ZooKeeper 通过访问控制列表 (ACL) 机制提供对其数据的访问控制。当数据写入 ZooKeeper 时，Lynxus 将提供一个 ACL，指示允许任何用户对数据拥有完全权限，或者指示只有创建数据的用户才允许访问数据。使用哪个 ACL 取决于 ZooKeeperStateProvider 的 Access Control 属性值（有关更多信息，请参阅配置状态提供程序部分）。
要使用指示只有创建者才允许访问数据的 ACL，我们需要告诉 ZooKeeper 创建者是谁。有三种方法可以实现此目的。第一种方法是使用 Kerberos 提供身份验证。有关更多信息，请参阅为 Lynxus 的 ZooKeeper 客户端配置 Kerberos。
第二种选项还确保网络通信加密，是在启用 TLS 的 ZooKeeper 服务器上使用 X.509 证书进行身份验证。有关更多信息，请参阅使用 TLS 保护 ZooKeeper。
第三种选项是使用用户名和密码。通过为 ZooKeeperStateProvider 的 Username 和 Password 属性指定值来配置（有关更多信息，请参阅配置状态提供程序部分）。但是，重要的是要记住，ZooKeeper 将以明文形式传递密码。这意味着使用用户名和密码不应在以下情况之外使用：ZooKeeper 作为单实例集群在 localhost 上运行，或者与 ZooKeeper 的通信仅通过加密通信（如 VPN 或 SSL 连接）进行。
使用 Kerberos 保护 ZooKeeper
当 Lynxus 与 ZooKeeper 通信时，默认情况下所有通信都是不安全的，任何登录 ZooKeeper 的人都可以查看和操作存储在 ZooKeeper 中的所有 Lynxus 状态。为了防止这种情况，一种选项是使用 Kerberos 来管理身份验证。
要使用 Kerberos 保护通信，我们需要确保客户端和服务器都支持相同的配置。以下提供了配置 Lynxus ZooKeeper 客户端和嵌入式 ZooKeeper 服务器使用 Kerberos 的说明。
如果您的环境中尚未设置 Kerberos，可以在 Red Hat 客户门户：配置 Kerberos 5 服务器 找到有关安装和设置 Kerberos 服务器的信息。本指南假设 Lynxus 运行的环境中已安装 Kerberos。
请注意，以下在 Lynxus 节点中对嵌入式 ZooKeeper 服务器进行 Kerberization 以及对 ZooKeeper Lynxus 客户端进行 Kerberization 的过程需要安装Kerberos 客户端库。这在基于 Fedora 的 Linux 发行版中通过以下方式完成：
yum install krb5-workstation完成后，需要根据组织的 Kerberos 环境适当配置 /etc/krb5.conf。
为嵌入式 ZooKeeper 服务器配置 Kerberos
运行嵌入式 ZooKeeper 服务器的系统上的 krb5.conf 文件应与运行 krb5kdc 服务的系统上的文件相同。使用嵌入式 ZooKeeper 服务器时，我们可以选择使用 Kerberos 保护服务器。所有配置为启动嵌入式 ZooKeeper 并使用 Kerberos 的节点应遵循这些步骤。
为了使用 Kerberos，我们首先需要为 ZooKeeper 服务器生成 Kerberos 主体。以下命令在运行krb5kdc 服务的服务器上执行。这通过 kadmin 工具完成：
kadmin: addprinc "zookeeper/myHost.example.com@EXAMPLE.COM"这里，我们创建了一个主体，主名为 zookeeper/myHost.example.com，使用域 EXAMPLE.COM。我们需要使用名为 <service name>/<instance name> 的主体。在这种情况下，服务是 zookeeper，实例名是 myHost.example.com（我们主机的完全限定名）。
接下来，我们需要为此主体创建 KeyTab，此命令在运行带有嵌入式 ZooKeeper 服务器的 Lynxus 实例的服务器上执行：
kadmin: xst -k zookeeper-server.keytab zookeeper/myHost.example.com@EXAMPLE.COM这将在当前目录中创建一个名为 zookeeper-server.keytab 的文件。我们现在可以将该文件复制到 $LYNXUS_HOME/conf/ 目录。我们应确保只有运行 Lynxus 的用户才被允许读取此文件。
我们需要对每个将运行嵌入式 ZooKeeper 服务器的 Lynxus 实例重复上述步骤，确保将 myHost.example.com 替换为`myHost2.example.com`，或 ZooKeeper 服务器将运行的任何完全限定主机名。
现在我们已经获得了每个将运行 Lynxus 的服务器的 KeyTab，我们需要配置 Lynxus 的嵌入式 ZooKeeper 服务器以使用此配置。ZooKeeper 使用 Java 认证和授权服务 (JAAS)，所以我们需要创建一个 JAAS 兼容的文件。在 $LYNXUS_HOME/conf/ 目录中，创建一个名为 zookeeper-jaas.conf 的文件（如果客户端已配置为通过 Kerberos 认证，该文件将已存在。没关系，只需添加到文件中）。我们将向此文件添加以下代码片段：
Server {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="./conf/zookeeper-server.keytab"
storeKey=true
useTicketCache=false
principal="zookeeper/myHost.example.com@EXAMPLE.COM";
};确保将上述 principal 的值替换为适当的主体，包括服务器的完全限定域名。
接下来，我们需要告诉 Lynxus 使用此文件作为我们的 JAAS 配置。这通过设置 JVM 系统属性完成，所以我们将编辑 conf/bootstrap.conf 文件。如果客户端已配置为使用 Kerberos，则不需要此操作，因为上面已经完成了。否则，我们将向 bootstrap.conf 文件添加以下行：
java.arg.15=-Djava.security.auth.login.config=./conf/zookeeper-jaas.conf| 文件中的这个额外行不必是第 15 行，只需添加到 bootstrap.conf 文件中即可。使用适合您配置的任何编号。 |
我们将通过运行以下命令初始化 Kerberos 票据：
kinit –kt zookeeper-server.keytab "zookeeper/myHost.example.com@EXAMPLE.COM"同样，确保将主体替换为适当的值，包括您的域和完全限定主机名。
最后，我们需要告诉 Kerberos 服务器使用 SASL 认证提供程序。为此，我们编辑 $LYNXUS_HOME/conf/zookeeper.properties 文件并添加以下行：
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
kerberos.removeHostFromPrincipal=true
kerberos.removeRealmFromPrincipal=true
jaasLoginRenew=3600000
requireClientAuthScheme=saslkerberos.removeHostFromPrincipal 和 kerberos.removeRealmFromPrincipal 属性用于在将身份与Znode 上应用的 ACL 进行比较之前规范化用户主体名称。默认情况下使用完整主体名称，但将 kerberos.removeHostFromPrincipal 和 kerberos.removeRealmFromPrincipal 属性设置为 true 将指示ZooKeeper 从登录用户身份中移除主机和域以进行比较。在 Lynxus 节点（在同一集群内）使用具有不同主机/域值的主体的情况下，可以配置这些 Kerberos 属性以确保节点身份将被规范化，并且节点将拥有对 ZooKeeper 中共享 Znode 的适当访问权限。
最后一行是可选的，但指定客户端必须使用 Kerberos 与我们的 ZooKeeper 实例通信。
现在，我们可以启动 Lynxus，嵌入式 ZooKeeper 服务器将使用 Kerberos 作为认证机制。
为 Lynxus 的 ZooKeeper 客户端配置 Kerberos
| 运行嵌入式 ZooKeeper 服务器的 Lynxus 节点也需要遵循以下过程，因为它们同时也充当客户端。同时。 |
与 ZooKeeper 进行用户认证的首选机制是使用 Kerberos。为了使用 Kerberos 进行认证，我们必须配置一些系统属性，以便 ZooKeeper 客户端知道用户是谁以及 KeyTab 文件在哪里。所有配置为使用 ZooKeeperStateProvider 存储集群范围状态并使用 Kerberos 的节点应遵循这些步骤。
首先，我们必须创建与 ZooKeeper 通信时使用的主体。这通常通过 kadmin 工具完成：
kadmin: addprinc "lynxus@EXAMPLE.COM"Kerberos 主体由三部分组成：主名、实例和域。这里，我们创建了一个主体，主名为 lynxus，无实例，域为 EXAMPLE.COM。主名（在本例中为 lynxus）是在通过 Kerberos 认证时用于标识用户的标识符。
创建主体后，我们需要为该主体创建 KeyTab：
kadmin: xst -k lynxus.keytab lynxus@EXAMPLE.COM此 keytab 文件可以复制到其他带有嵌入式 ZooKeeper 服务器的 Lynxus 节点。
这将在当前目录中创建一个名为 lynxus.keytab 的文件。我们现在可以将该文件复制到 $LYNXUS_HOME/conf/ 目录。我们应确保只有运行 Lynxus 的用户才被允许读取此文件。
接下来，我们需要配置 Lynxus 使用此 KeyTab 进行认证。由于 ZooKeeper 使用 Java 认证和授权服务 (JAAS)，我们需要创建一个 JAAS 兼容的文件。在 $LYNXUS_HOME/conf/ 目录中，创建一个名为 zookeeper-jaas.conf 的文件，并向其添加以下代码片段：
Client {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="./conf/lynxus.keytab"
storeKey=true
useTicketCache=false
principal="lynxus@EXAMPLE.COM";
};然后我们需要告诉 Lynxus 使用此文件作为我们的 JAAS 配置。这通过设置 JVM 系统属性完成，所以我们将编辑 conf/bootstrap.conf 文件。我们在此文件的任何位置添加以下行，以告诉 Lynxus JVM 使用此配置：
java.arg.15=-Djava.security.auth.login.config=./conf/zookeeper-jaas.conf最后，我们需要更新 lynxus.properties，以确保 Lynxus 知道为其将在 ZooKeeper 中创建的用于集群管理的 Znode 应用 SASL 特定的 ACL。要启用此功能，在 $LYNXUS_HOME/conf/lynxus.properties 文件中编辑以下属性如下所示：
lynxus.zookeeper.auth.type=sasl
lynxus.zookeeper.kerberos.removeHostFromPrincipal=true
lynxus.zookeeper.kerberos.removeRealmFromPrincipal=true
kerberos.removeHostFromPrincipal 和 kerberos.removeRealmFromPrincipal 应与 ZooKeeper 配置中的设置一致。
|
我们可以通过运行以下命令初始化 Kerberos 票据：
kinit -kt lynxus.keytab lynxus@EXAMPLE.COM现在，当我们启动 Lynxus 时，它将使用 Kerberos 以 lynxus 用户身份与 ZooKeeper 进行认证。
Kerberos 配置故障排除
使用 Kerberos 时，务必使用完全限定域名而不是 localhost。请确保在以下位置使用每个服务器的完全限定主机名：
-
conf/zookeeper.properties 文件应为
server.1、server.2、…、server.N值使用 FQDN。 -
ZooKeeperStateProvider 的
Connect String属性 -
/etc/hosts 文件也应将 FQDN 解析为*不是*
127.0.0.1的 IP 地址。
如果不这样做，可能会导致类似以下的错误：
2016-01-08 16:08:57,888 ERROR [pool-26-thread-1-SendThread(localhost:2181)] o.a.zookeeper.client.ZooKeeperSaslClient An error: (java.security.PrivilegedActionException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - LOOKING_UP_SERVER)]) occurred when evaluating ZooKeeper Quorum Member's received SASL token. ZooKeeper Client will go to AUTH_FAILED state.如果在与 Kerberos 通信或认证方面遇到问题，此故障排除指南 可能会有所帮助。
上述故障排除指南中最重要的注意事项之一是启用 Kerberos 调试输出的机制。这通过设置 sun.security.krb5.debug 环境变量来完成。在 Lynxus 中，这可以通过将以下行添加到 $LYNXUS_HOME/conf/bootstrap.conf 文件来实现：
java.arg.16=-Dsun.security.krb5.debug=true这将使调试输出写入 Lynxus Bootstrap 日志文件。默认情况下，此文件位于 $LYNXUS_HOME/logs/lynxus-bootstrap.log。此输出可能相当详细，但为排查 Kerberos 故障提供了极其有价值的信息。
使用 TLS 保护 ZooKeeper
如上所述，与 ZooKeeper 的通信默认是不安全的。安全认证和与 ZooKeeper 通信的第二种选项是使用启用 TLS 的 ZooKeeper 服务器（自 ZooKeeper 3.5.x 版本起可用）进行基于证书的身份验证。在外部 ZooKeeper 集群上启用 TLS 的说明可在ZooKeeper 管理员指南 中找到。
拥有启用 TLS 的 ZooKeeper 实例后，可以通过设置 lynxus.zookeeper.client.secure=true 为 Lynxus 客户端启用 TLS。默认情况下，ZooKeeper 客户端将使用现有的 lynxus.security.* 属性作为密钥库和信任库。如果您需要为 ZooKeeper 单独配置 TLS，可以创建单独的密钥库和信任库并配置以下属性在 $LYNXUS_HOME/conf/lynxus.properties 文件中：
| 属性名 | 描述 | 默认值 |
|---|---|---|
|
是否启用 ZooKeeper 客户端 Ensemble 跟踪。 |
true |
|
是否使用客户端 TLS 访问 ZooKeeper。 |
false |
|
与 ZooKeeper 通信时使用的包含私钥的密钥库文件名。 |
无 |
|
可选。密钥库的类型。必须为 |
无 |
|
密钥库的密码。 |
无 |
|
用于验证 ZooKeeper 服务器的信任库文件名。 |
无 |
|
可选。信任库的类型。必须为 |
无 |
|
信任库的密码。 |
无 |
无论是使用默认安全属性还是 ZooKeeper 特定属性，密钥库和信任库必须包含与 ZooKeeper 一起使用的适当密钥和证书（即密钥和证书需要与 ZooKeeper 配置对齐）。
更新上述属性并启动 Lynxus 后，与 ZooKeeper 的网络通信将是安全的，ZooKeeper 现在将使用 Lynxus 节点的证书主体名称在认证访问时。这将反映在 ZooKeeper 服务器上的日志消息中，如下所示：
2020-02-24 23:37:52,671 [myid:2] - INFO [nioEventLoopGroup-4-1:X509AuthenticationProvider@172] - Authenticated Id 'CN=lynxus-node1,OU=LYNXUS' for Scheme 'x509'ZooKeeper 使用 Netty 支持网络加密和基于证书的身份验证。启用 TLS 后，ZooKeeper 服务器及其客户端都必须配置为使用基于 Netty 的连接而不是默认的 NIO 实现。当 lynxus.zookeeper.client.secure 设置为 true 时，Lynxus 会自动配置此项。启用 Netty 后，您应该在 $LYNXUS_HOME/logs/lynxus-app.log 中看到如下日志消息：
2020-02-24 23:37:54,082 INFO [nioEventLoopGroup-3-1] o.apache.zookeeper.ClientCnxnSocketNetty SSL handler added for channel: [id: 0xa831f9c3]
2020-02-24 23:37:54,104 INFO [nioEventLoopGroup-3-1] o.apache.zookeeper.ClientCnxnSocketNetty channel is connected: [id: 0xa831f9c3, L:/172.17.0.4:56510 - R:8e38869cd1d1/172.17.0.3:2281]使用 TLS 的嵌入式 ZooKeeper
Lynxus 集群可以使用嵌入在 Lynxus 本身中的 ZooKeeper 实例进行部署，所有节点都可以与之通信。自 Lynxus 1.13.0 起，节点与此嵌入式 ZooKeeper 之间的通信现在可以通过 TLS 保护。1.13 之前的 Lynxus 版本不使用嵌入式 ZooKeeper 的安全客户端访问。连接客户端侧的配置方式与外部 ZooKeeper 相同。即，默认使用 lynxus.properties 文件中的 lynxus.security.* 属性，除非您使用 lynxus.zookeeper.security.* 指定显式的 ZooKeeper 密钥库/信任库属性，如上所述。
服务器配置方式与不安全的嵌入式服务器相同，但设置了 secureClientPort（通常为端口 2281）。
示例 $LYNXUS_HOME/conf/zookeeper.properties 文件：
secureClientPort=2281
initLimit=10
autopurge.purgeInterval=24
syncLimit=5
tickTime=2000
dataDir=./state/zookeeper
autopurge.snapRetainCount=30
server.1=lynxus1.example.com:2888:3888
server.2=lynxus2.example.com:2888:3888
server.3=lynxus3.example.com:2888:3888当与三节点 Lynxus 集群一起使用时，上述配置文件将建立一个三节点 ZooKeeper 仲裁，每个节点在安全端口 2281 上监听与 Lynxus 的客户端连接，2888 用于仲裁通信，3888 用于领导者选举。
| 使用安全服务器时，安全嵌入式 ZooKeeper 服务器忽略 $LYNXUS_HOME/conf/zookeeper.properties 中指定的任何 clientPort 或 clientPortAddress。即，如果 Lynxus 嵌入的 ZooKeeper 暴露了 secureClientPort，则无论配置如何，它都不会暴露不安全的 clientPort。这是嵌入式服务器与外部 ZooKeeper 服务器之间的行为差异，确保嵌入式 ZooKeeper 要么安全运行，要么不安全运行，但不会混合运行。 |
以下是在 $LYNXUS_HOME/conf/lynxus.properties 中设置的相关属性的示例，用于运行和连接到此仲裁：
lynxus.security.keystore=./conf/keystore.jks
lynxus.security.keystoreType=jks
lynxus.security.keystorePasswd=password
lynxus.security.keyPasswd=password
lynxus.security.truststore=./conf/truststore.jks
lynxus.security.truststoreType=jks
lynxus.security.truststorePasswd=password
lynxus.security.user.authorizer=managed-authorizer
lynxus.zookeeper.connect.string=lynxus1.example.com:2281,lynxus2.example.com:2281,lynxus3.example.com:2281
lynxus.zookeeper.connect.timeout=10 secs
lynxus.zookeeper.session.timeout=10 secs
lynxus.zookeeper.root.node=/lynxus
lynxus.zookeeper.client.secure=true
lynxus.state.management.embedded.zookeeper.start=true
lynxus.state.management.embedded.zookeeper.properties=./conf/zookeeper.properties
lynxus.state.management.configuration.file=./conf/state-management.xml
lynxus.state.management.provider.cluster=zk-provider引导属性
conf 目录中的 bootstrap.conf 文件允许用户配置 Lynxus 的启动方式。这包括 Java 堆大小、要运行的 Java 命令和 Java 系统属性等参数。
在此，我们将介绍文件中可用的不同属性。对这些属性的任何更改仅在 Lynxus 停止并重新启动后生效。
属性 |
描述 |
|
指定要运行的完全限定 Java 命令。默认情况下，它仅为 |
|
运行 Lynxus 的用户名。例如，如果 Lynxus 应作为 |
|
使用 |
|
Lynxus 使用的 lib 目录。默认情况下，此值设置为 |
|
Lynxus 使用的 conf 目录。默认情况下，此值设置为 |
|
当指示 Lynxus 关闭时，引导程序将等待此秒数让进程正常关闭。到达此时间后，如果服务仍在运行，引导程序将 |
|
在进程启动时，可以将任意数量的 JVM 参数传递给 Lynxus JVM。这些参数通过在 bootstrap.conf 中添加以`java.arg.` 开头的属性来定义。属性名的其余部分不相关，仅用于区分属性名，将被忽略。默认包括最小和最大 Java 堆大小、使用的垃圾回收器、Java IO 临时目录等属性。 |
|
Lynxus 监听管理请求的 HTTP URL。未指定时默认为 |
代理配置
Lynxus 支持对外部 HTTP 和 HTTPS 请求使用代理服务器。
-
Lynxus 由多个 Web 应用程序（Web UI、Web API、文档、自定义 UI、数据查看器等）组成，因此需要为*根路径*配置映射。这样所有上下文 路径都会相应传递。例如，如果仅映射了
/lynxus上下文路径，UpdateAttribute 的自定义 UI 将无法工作，因为它在/update-attribute-ui-<version>处可用。 -
Lynxus 的 REST API 将为画布上的每个组件生成 URI。由于请求通过代理传入，生成的 URI 的某些元素需要被覆盖。如果不 覆盖，用户将能够查看画布上的数据流，但无法修改现有组件。请求将尝试直接回调 Lynxus，而不是通过代理。可以通过在代理生成对 Lynxus 实例的 HTTP 请求时添加以下 HTTP 头来覆盖 URI 的元素：
X-ProxyScheme - the scheme to use to connect to the proxy X-ProxyHost - the host of the proxy X-ProxyPort - the port the proxy is listening on X-ProxyContextPath - the path configured to map to the Lynxus instance
-
Lynxus 期望
X-ProxyHost或X-Forwarded-Host头值中包含单个主机或主机与端口组合。通过多个服务器路由请求时，某些代理服务器会追加到现有 值，生成由多个主机组成的逗号分隔字符串。Lynxus 以HTTP 421状态拒绝逗号分隔的值。反向代理服务器必须配置为禁止追加到现有值，或在转发请求之前取消设置输入值。诸如 Apache HTTP mod_proxy 等服务器应将ProxyAddHeaders设置为`Off` 以避免生成无效的逗号分隔值。 -
启用 HTTPS 运行时，必须授权所有代理服务器代理用户请求。这些可以在 Lynxus UI 中通过全局菜单配置。一旦这些权限就位，代理 就可以开始代理用户请求。最终用户身份必须在 HTTP 头中传递。例如，如果最终用户向代理发送请求，代理必须认证用户。之后代理可以将请求发送到 Lynxus。在此请求中，应按如下方式添加 HTTP 头。
X-ProxiedEntitiesChain: <end-user-identity>
如果代理配置为发送到另一个代理，则从第二个代理到 Lynxus 的请求应包含如下头。
X-ProxiedEntitiesChain: <end-user-identity><proxy-1-identity>
设置所需属性的 Apache 代理配置示例可能如下所示。完整的代理配置不在本文档的范围内。请参阅代理的文档以获取有关部署环境和用例的指导。
...
<Location "/my-lynxus">
...
SSLEngine On
SSLCertificateFile /path/to/proxy/certificate.crt
SSLCertificateKeyFile /path/to/proxy/key.key
SSLCACertificateFile /path/to/ca/certificate.crt
SSLVerifyClient require
RequestHeader add X-ProxyScheme "https"
RequestHeader add X-ProxyHost "proxy-host"
RequestHeader add X-ProxyPort "443"
RequestHeader add X-ProxyContextPath "/my-lynxus"
RequestHeader add X-ProxiedEntitiesChain "<%{SSL_CLIENT_S_DN}>"
ProxyPass https://lynxus-host:8443
ProxyPassReverse https://lynxus-host:8443
...
</Location>
...
-
必须更新额外的 Lynxus 代理配置以允许预期的 Host 和上下文路径 HTTP 头。
-
配置启用 HTTPS 时，
Host头中的名称必须与配置的服务器 X.509 证书上的 DNS 主题备用名称 之一匹配。框架服务器还会在 TLS 握手期间验证服务器证书中服务器名称指示扩展提供的名称。当请求的Host头不满足这些要求时，服务器返回 HTTP400 Bad Request 状态。 -
该应用程序支持通过
X-ProxyHost或X-Forwarded-Host头提供备用主机地址。这些头之一提供的主机地址必须在lynxus.web.proxy.host属性中配置。应用程序使用提供的备用主机地址构建与反向代理的公共地址匹配的 URL。当请求的代理头值未列在代理主机地址属性中时，服务器返回 HTTP 421 Misdirected Request 状态。 -
Lynxus 仅接受带有 X-ProxyContextPath、X-Forwarded-Context 或 X-Forwarded-Prefix 头的 HTTP 请求（如果该值在 lynxus.properties 的
lynxus.web.proxy.context.path属性中被允许）。 此属性接受以逗号分隔的预期值列表。如果传入请求的 X-ProxyContextPath、X-Forwarded-Context 或 X-Forwarded-Prefix 头值不在允许列表中，将显示"发生意外错误"页面，并将错误写入 lynxus-app.log。
-
-
需要在代理服务器和 Lynxus 集群两端进行额外配置，才能使 Lynxus 站点到站点在反向代理后面工作。详见反向代理的站点到站点路由属性。
-
为了通过反向代理使用站点到站点协议传输数据，代理和站点到站点客户端 Lynxus 用户需要具有以下策略："retrieve site-to-site details"、输入端口的"receive data via site-to-site"以及输出端口的"send data via site-to-site"。
-
会话亲和性
来自单个客户端的所有 HTTP 请求在认证会话期间必须路由到同一个 ACAL Lynxus 节点。这适用于基于浏览器的用户和访问 REST API 的编程客户端。对于独立部署或直接网络访问 ACAL Lynxus，这不是问题，但通过代理服务器或负载均衡器访问集群节点需要启用会话亲和性，也称为粘性会话。会话亲和性对于传统集群部署的中介访问以及使用以下平台的容器化部署是必需的：
通过网关访问集群部署需要会话亲和性，原因如下：
-
每个节点使用本地密钥签名和验证 JSON Web Token
-
每个节点使用本地缓存跟踪配置变更事务
尝试通过没有会话亲和性的网关访问集群节点将导致各种类型的间歇性故障。使用用户名和密码凭据认证到 ACAL Lynxus 时，缺少会话亲和性通常会导致 HTTP 401 Unauthorized 响应，表示节点未接受 JSON Web Token。这些故障可能在不同时间发生，具体取决于负载均衡策略。使用 X.509证书访问 ACAL Lynxus 可避免与 JSON Web Token 相关的验证问题，但仍然会遇到与跨集群节点的配置变更事务处理相关的问题。
会话亲和性配置
启用会话亲和性需要根据提供访问的产品或服务进行不同的设置。会话亲和性配置的超时时间必须大于使用用户名和密码凭据认证时的会话过期时间，这一点至关重要。
Apache HTTP 服务器配置
Apache HTTP Server 在mod_proxy 模块中支持会话亲和性，使用ProxyPass 指令和stickysession 参数配置用于请求路由的 Cookie 名称。
Kubernetes Nginx Ingress 控制器
Kubernetes Nginx Ingress 控制器支持使用部署注解配置粘性会话（使用 Cookie）。部署注解提供了配置 Cookie 属性（包括过期时间）的能力。
分析框架
Lynxus 提供了一个分析框架，用于收集和分析有关系统和数据流的指标。
为了生成预测，系统会查询本地状态快照历史以获取足够的数据来生成模型。默认情况下，组件状态快照每分钟捕获一次。内部模型至少需要 2 个或更多观测值才能生成预测，因此默认情况下可能需要 2 分钟或更长时间才能提供预测。如果需要比默认值更快的预测，可以使用 lynxus.properties 中的 lynxus.components.status.snapshot.frequency 值调整快照的时间间隔。
Lynxus 在发送预测信息之前，默认使用模型的 R 平方值评估模型的有效性。需要注意的一点是：R 平方是衡量回归线拟合观测数据程度的指标，而非预测准确度的指标；因此可能存在一定的误差。如果计算模型的 R 平方值达到配置的阈值（由 lynxus.analytics.connection.model.score.threshold 定义），则该模型将用于预测。否则该模型将不被使用，在生成得分超过阈值的模型之前，预测将不可用。默认 R 平方阈值值为 .90，但可以根据预测需求进行调整。
预测间隔 lynxus.analytics.predict.interval 可以配置为预测更远的将来何时会出现反压。预测查询间隔 lynxus.analytics.query.interval 也可以配置，以确定应查询多远时间范围内的过去观测值来生成模型。对这些设置的调整可能需要调整模型的得分阈值值，以选择能够提供合理预测的得分。
有关配置分析属性的完整信息，请参见分析属性。
系统属性
conf 目录中的 lynxus.properties 文件是控制 Lynxus 运行方式的主配置文件。
| 时间段和数据大小的值必须包含度量单位，例如 "10 secs" 或 "10 MB"，而不仅仅是 "10"。 |
| 修改 lynxus.properties 后，请重启 Lynxus 以使更改生效。 |
核心属性
lynxus.properties 文件的第一部分是核心属性。这些属性适用于整个 Lynxus 实例。
属性 |
描述 |
|
基于 JSON 的数据流配置文件的位置。默认值为 |
|
指定 Lynxus 是否在数据流更新时自动创建备份副本。默认值为 |
|
归档目录的位置，flow.json 的备份副本保存在此目录中。默认值为 |
|
归档 flow.json 文件的生命周期。如果指定了此属性，Lynxus 在更新 flow.json 时将删除过期的归档文件。过期时间基于当前系统时间和归档 flow.json 的最后修改时间戳确定。如果 lynxus.properties 中未指定归档限制，Lynxus 移除超过 |
|
归档 flow.json 文件允许的总数据大小。如果指定了此属性，Lynxus 将删除最旧的归档文件，直到总归档文件大小小于此配置值。如果 lynxus.properties 中未指定归档限制，Lynxus 使用 |
|
允许的归档文件数量。如果指定了此属性，Lynxus 将删除最旧的归档文件，只保留最新的 N 个归档。 |
|
指示重启时 Lynxus 图上的组件（包括处理器、控制器服务和其他可调度的组件）是否应恢复到其最后的状态。在集群中运行时，所有节点应具有相同的值。默认值为 |
|
指示关闭等待时间。默认值为 |
|
指定 Lynxus 将数据流配置与 Flow Registry 客户端同步的默认循环间隔。默认值为 |
|
当对 flow.json 进行了许多更改时，此属性指定在写出更改之前等待多长时间，以便将更改批量写入。默认值为 |
|
如果组件允许意外异常逃逸，则视为错误。因此，框架将暂停（或管理性暂停）组件此时间段。这样做是为了使组件不会消耗大量系统资源，因为已知其在当前状态下存在问题。默认值为 |
|
当组件没有工作要做（即"空闲"）时，这是它在检查是否有新数据要处理之前等待的时间量。这样，它不会通过过于频繁地检查新工作来消耗 CPU 资源。设置此属性时，请注意它可能会为不持续有工作要做的组件增加额外延迟，因为一旦进入这种"空闲"状态，它们将等待此时间量再检查更多工作。默认值为 |
|
在两个组件之间绘制新连接时，这是该连接的反压对象阈值的默认值。默认值为 |
|
在两个组件之间绘制新连接时，这是该连接的反压数据大小阈值的默认值。默认值为 |
|
这是指定授权器定义方式的文件位置。默认值为 |
|
这是指定用户名/密码身份验证执行方式的文件位置。此文件仅在配置了 |
|
某些提供程序（例如 UserGroupProvider）将查找先前配置以从中恢复的位置。没有默认值。 |
|
nar 库的位置。默认值为 |
|
nar 工作目录的位置。默认值为 |
|
如果设置为 |
|
等待处理器生命周期操作（ |
状态管理
属性文件的状态管理部分为组件持久化状态提供了本地和集群范围机制的配置。有关如何使用此功能的更多信息，请参见状态管理部分。
属性 |
描述 |
|
包含本地和集群范围状态提供程序配置的 XML 文件。默认值为 |
|
要使用的本地状态提供程序的 ID。此值必须与 state-management.xml 文件中某个 |
|
要使用的集群状态提供程序的 ID。此值必须与 state-management.xml 文件中某个 |
|
指定此 Lynxus 实例是否应启动嵌入式 ZooKeeper 服务器。这与 ZooKeeperStateProvider 一起使用。默认值为 |
|
指定包含启动的嵌入式 ZooKeeper 服务器配置的属性文件（如果 |
数据库设置
数据库设置部分定义内部数据库的设置，该数据库跟踪数据流配置历史。
属性 |
描述 |
|
数据流配置历史数据库目录的位置。默认值为 |
流程动作报告器
流程动作报告器是一个框架接口，支持使用自定义实现类导出数据流配置更改。
属性 |
描述 |
|
从 |
组件指标报告器
组件指标报告器是一个框架接口，支持使用自定义实现类导出处理指标，包括计数器和仪表盘。
属性 |
描述 |
|
从 |
FlowFile 存储库
FlowFile 存储库跟踪系统中每个 FlowFile 的属性和当前状态。默认情况下，此存储库安装在与其他所有存储库相同的根安装目录中；但是，建议在可用时将其配置在单独的驱动器上。
FlowFile 存储库目前有三种实现，详见下文。
属性 |
描述 |
|
FlowFile 存储库实现。默认值为 |
| 切换存储库实现只应在零排队 FlowFile 的实例上进行，并且应谨慎操作。 |
预写 FlowFile 存储库
WriteAheadFlowFileRepository 是默认实现。它将 FlowFile 持久化到磁盘，并且可以选择配置为将所有更改同步到磁盘。这非常消耗资源，会显著降低 Lynxus 性能。但是，如果设置为 false，在突然断电或操作系统崩溃的情况下，可能会导致数据丢失。默认值为 false。
属性 |
描述 |
|
FlowFile 存储库的位置。默认值为 |
|
FlowFile 存储库检查点间隔。默认值为 |
|
如果设置为 |
易失性 FlowFile 存储库
此实现将 FlowFile 存储在内存中而不是磁盘上。在断电/机器故障或 Lynxus 重启时，它*会*导致数据丢失。要使用此实现，请将 lynxus.flowfile.repository.implementation 设置为 cn.org.acal.lynxus.controller.repository.VolatileFlowFileRepository。
交换管理
Lynxus 将 FlowFile 信息保存在内存（JVM）中，但在传入数据激增期间，FlowFile 信息可能开始占用大量 JVM 空间，导致系统性能下降。为了对抗这种效应，Lynxus 将 FlowFile 信息"交换"到磁盘临时存储，直到更多 JVM 空间可用。这些属性控制此过程的执行方式。
属性 |
描述 |
|
交换管理器实现。默认值为 |
|
Lynxus 开始将 FlowFile 信息交换到磁盘的队列阈值。默认值为 |
| 当队列开始向磁盘交换时，Lynxus 不保证队列中所有 FlowFile 按优先级排序器 在队列上配置的顺序排序。到达队列的新 FlowFile 在写入交换文件时不考虑优先级排序器。它们在交换文件读回内存时进行优先级排序。 |
内容存储库
内容存储库保存系统中所有 FlowFile 的内容。默认情况下，它安装在与其他所有存储库相同的根安装目录中；但是，管理员可能希望在可用时将其配置在单独的驱动器上。至少，内容存储库最好不要与 FlowFile 存储库在同一驱动器上。在处理大量数据的数据流中，内容存储库可能会占满磁盘，如果 FlowFile 存储库也在同一磁盘上，则可能会损坏。为避免这种情况，请将这些存储库配置在不同的驱动器上。
属性 |
描述 |
|
内容存储库实现。默认值为 |
文件系统内容存储库属性
属性 |
描述 |
|
内容存储库实现。默认值为 |
|
当 Lynxus 处理许多小型 FlowFile 时，这些 FlowFile 的内容存储在内容存储库中，但我们不会将每个单独的 FlowFile 的内容作为内容存储库中的单独文件存储。如果每个 120 字节的 FlowFile 都写入自己的文件，这样做将对性能造成极大损害。相反，我们继续写入同一文件，直到达到某个阈值。此属性配置该阈值。设置值太小可能导致性能下降，因为读取和写入太多文件。但是，只有在没有 FlowFile 指向文件时，才能从内容存储库中删除该文件。因此，设置值太大可能导致数据在内容存储库中保留更长时间，可能导致内容存储库磁盘空间不足。默认值为 |
|
内容存储库的位置。默认值为 |
|
如果启用归档（参见下方 |
|
如果启用归档（参见下方 |
|
此属性用于控制内容存储库磁盘使用百分比，达到该百分比时对写入内容存储库的进程施加反压。达到此百分比后，内容存储库将拒绝任何额外写入。写入将被拒绝，直到归档删除过程将内容存储库磁盘使用百分比降至 |
|
要启用内容归档，将此设置为 |
|
如果设置为 |
|
安排内容归档清理任务的频率。默认值为 |
|
当内容存储库文件被多个 FlowFile 共享时（参见 |
溯源存储库
溯源存储库包含与数据来源相关的信息。以下四个部分用于溯源存储库属性。
属性 |
描述 |
|
溯源存储库实现。默认值为`cn.org.acal.lynxus.provenance.WriteAheadProvenanceRepository`。要将溯源事件存储在内存中而不是磁盘上（在这种情况下所有事件将在重启时丢失，事件将以先进先出的顺序被驱逐），将此属性设置为 |
|
在文件翻转之前应写入单个事件文件的最大事件数。默认值为 |
预写溯源存储库属性
属性 |
描述 |
|
溯源存储库的位置。默认值为 |
|
保留数据来源信息的最长时间。默认值为 |
|
同时存储的数据来源信息的最大量。默认值为 |
|
写入单个"事件文件"的数据量。默认值为 |
|
用于溯源存储库查询的线程数。默认值为 |
|
用于索引溯源事件以使其可搜索的线程数。默认值为 |
|
指示在"事件文件"翻转时是否压缩溯源信息。默认值为 |
|
如果设置为 |
|
这是一个逗号分隔的字段列表，应被索引并可搜索。未索引的字段将不可搜索。有效字段为： |
|
这是一个逗号分隔的 FlowFile 属性列表，应被索引并可搜索。默认情况下为空。但一些值得考虑的好示例是 |
|
存储库使用 Apache Lucene 执行索引和搜索功能。此值指示 Lucene 索引应在存储库开始写入新索引之前变得多大。较大的分片大小值将在搜索溯源存储库时导致更多 Java 堆使用，但应提供更好的性能。默认值为 NOTE: 此值应小于（不超过一半） |
|
指示从存储库检索溯源事件时 FlowFile 属性的最大长度。如果任何属性的长度超过此值，则在检索事件时将被截断。默认值为 |
|
Apache Lucene 在索引中创建多个"段"。这些段定期合并以提供更快的查询。此属性指定每个存储目录允许使用的最大线程数。默认值为 |
|
每次运行溯源查询时，查询必须首先搜索 Apache Lucene 索引（至少在大多数情况下 - 有些查询经常运行，结果被缓存以避免搜索 Lucene 索引）。当首次打开 Lucene 索引时，可能非常消耗资源并需要几秒钟。这因有许多不同的索引而加剧，可能导致溯源查询花费更长时间。在索引打开后，操作系统的磁盘缓存通常会保留足够的数据，使重新打开索引更快 - 至少持续一段时间，直到磁盘缓存驱逐这些数据。如果设置了此值，Lynxus 将定期打开每个 Lucene 索引然后关闭它，以"预热"缓存。这将使溯源存储库很大时查询速度更快。与所有好东西一样，它也有代价。预热缓存确实需要一些 CPU 资源，但更重要的是它将从操作系统磁盘缓存中驱逐其他数据，并将导致从磁盘读取（可能大量）数据。这可能导致 Lynxus 性能下降。但是，如果 Lynxus 在 CPU 和磁盘未充分利用的环境中运行，此功能可以使溯源查询速度快得多。此属性的默认值为空（即禁用）。 |
持久化溯源存储库属性
属性 |
描述 |
|
溯源存储库的位置。默认值为 |
|
保留数据来源信息的最长时间。默认值为 |
|
同时存储的数据来源信息的最大量。默认值为 |
|
在翻转最新数据来源信息之前等待的时间，以便在用户界面中可用。默认值为 |
|
一次翻转的信息量。默认值为 |
|
用于溯源存储库查询的线程数。默认值为 |
|
用于索引溯源事件以使其可搜索的线程数。默认值为 |
|
指示在翻转时是否压缩溯源信息。默认值为 |
|
如果设置为 |
|
应用于序列化溯源事件数据的日志文件数量。增加此值将允许更多任务同时更新存储库，但会导致后续日志文件合并更加消耗资源。此值理想情况下应等于预期同时更新存储库的线程数，但在大多数环境中 16 往往效果良好。默认值为 |
|
这是一个逗号分隔的字段列表，应被索引并可搜索。未索引的字段将不可搜索。有效字段为： |
|
这是一个逗号分隔的 FlowFile 属性列表，应被索引并可搜索。默认情况下为空。但一些值得考虑的好示例是 |
|
较大的分片大小值将在搜索溯源存储库时导致更多 Java 堆使用，但应提供更好的性能。默认值为 |
|
指示从存储库检索溯源事件时 FlowFile 属性的最大长度。如果任何属性的长度超过此值，则在检索事件时将被截断。默认值为 |
状态历史存储库
状态历史存储库包含用户界面中组件状态历史和节点状态历史工具的信息。以下属性控制这些工具的工作方式。
属性 |
描述 |
|
状态历史存储库实现。默认值为 |
|
此值指示捕获组件状态历史快照的频率。默认值为 |
内存存储库
如果属性 lynxus.components.status.repository.implementation 的值为 VolatileComponentStatusRepository，则状态历史数据将存储在内存中。如果应用程序停止，所有收集的信息将丢失。
buffer.size 和 snapshot.frequency 共同决定要保留的历史数据量。例如，要配置两天的历史数据，数据点快照每 5 分钟发生一次，您需要将`snapshot.frequency` 配置为 "5 mins"，buffer.size 配置为 "576"。进一步解释此示例，每 60 分钟有12 个（60 / 5）快照窗口。要将该数据保留 48 小时（12 * 48），最终缓冲区大小为576。
属性 |
描述 |
|
指定状态历史存储库的缓冲区大小。默认值为 |
持久化存储库
如果属性 lynxus.components.status.repository.implementation 的值为 cn.org.acal.lynxus.controller.status.history.questdb.EmbeddedQuestDbStatusHistoryRepository，则状态历史数据将以持久方式存储在磁盘上。数据将在重启之间保留。要使用持久化存储库，必须使用启用的 include-questdb 配置文件重新构建 QuestDB NAR。
属性 |
描述 |
|
节点状态数据（如存储库磁盘空间、垃圾收集信息等）将保留的天数。默认值为 |
|
组件状态数据（即每个处理器、连接等的统计数据）将保留的天数。默认值为 |
|
持久化状态历史存储库的位置。默认值为 |
|
数据库损坏并重新创建时数据库备份的位置。默认值为 |
|
基于 QuestDb 的状态历史存储库以批量方式持久化收集的状态信息。批量大小决定给定时间的最大持久化状态记录数。默认值为 |
|
持久化收集的状态记录的频率。默认值为 |
站点到站点属性
这些属性控制此 Lynxus 实例在数据流中配置了远程进程组时与远程 Lynxus 实例的通信方式。远程进程组可以选择 RAW 和 HTTP 传输协议。以 lynxus.remote.input.socket.* 命名的属性是 RAW 传输协议特定的。类似地，lynxus.remote.input.http.* 是 HTTP 传输协议特定属性。
属性 |
描述 |
|
将提供给客户端以连接到此 Lynxus 实例进行站点到站点通信的主机名。默认情况下，它是 |
|
这指示此 Lynxus 实例与远程 Lynxus 实例之间的通信是否应是安全的（即安全站点到站点）。默认情况下，它设置为 |
|
站点到站点通信的远程输入套接字端口。默认情况下，它为空白，但必须有一个值才能使用 RAW 套接字作为站点到站点的传输协议。 |
|
指定是否应在此主机上启用 HTTP 站点到站点。默认情况下，它设置为 |
|
指定事务在服务器上可以保持存活的时间。默认情况下，它设置为 |
|
指定 Lynxus 在通过站点到站点通信时应缓存远程 Lynxus 实例信息的时间。默认情况下，Lynxus 将缓存远程系统的响应 |
反向代理的站点到站点路由属性
站点到站点需要客户端与远程 Lynxus 节点之间的点对点通信。例如，如果远程 Lynxus 集群有 3 个节点（lynxus0、lynxus1 和 lynxus2），则客户端请求必须可达每个远程节点。
如果计划通过互联网或公司防火墙从/向站点到站点客户端传输数据，可以在 Lynxus 集群节点前面部署反向代理服务器作为网关，将客户端请求路由到上游 Lynxus 节点，以减少需要暴露的服务器和端口数量。
在此类环境中，同一 Lynxus 集群也将被期望被同一网络内的站点到站点客户端访问。在 Lynxus 集群节点之间进行 FlowFile 负载均衡以进行分发是一个典型的示例。在这种情况下，客户端请求应直接路由到节点而不经过反向代理。
为了支持此类部署，远程 Lynxus 集群需要根据客户端请求上下文动态暴露其站点到站点端点。以下属性配置如何向客户端暴露对等体。路由定义由 4 个属性组成：when、hostname、port 和 secure，按 protocol 和 name 分组。可以配置多个路由定义。protocol 表示站点到站点传输协议，即 RAW 或 HTTP。
属性 |
描述 |
|
布尔值， |
|
指定将引入给站点到站点客户端用于进一步通信的主机名。 |
|
指定将引入给站点到站点客户端用于进一步通信的端口号。 |
|
布尔值， |
以上所有路由属性都可以使用 Lynxus 表达式语言从请求上下文计算目标对等体描述。可用变量为：
变量名 |
描述 |
|
请求来源的源主机名和原始目标。 |
|
与上述相同，用于端口。源端口可能没有用，因为它只是客户端 TCP 端口。 |
|
与上述相同，用于是否安全。 |
|
正在使用的站点到站点协议名称， |
|
当前请求类型的名称， |
|
HTTP 请求头值可以通过其名称引用。 |
站点到站点协议序列
正确配置这些属性需要对站点到站点协议序列有一定了解。
-
客户端通过向指定的远程 URL 发送 HTTP(S) 请求来启动站点到站点协议，以获取远程集群的站点到站点信息。具体来说，是 '/lynxus-api/site-to-site'。此请求称为
SiteToSiteDetail。2. 远程 Lynxus 节点响应其输入和输出端口，以及 RAW 和 TCP 传输协议的 TCP 端口号。3. 客户端使用 #2 返回的 TCP 端口号发送另一个请求以获取远程对等体。从此请求开始，RAW 传输协议使用原始套接字通信，而 HTTP 继续使用 HTTP(S)。此请求称为Peers。4. 远程 Lynxus 节点响应可用远程对等体列表，包含主机名、端口、安全性和工作量（如排队的 FlowFile 数量）。从此刻起，进一步的通信在客户端和远程 Lynxus 节点之间进行。5. 客户端根据工作量信息决定从/向哪个对等体传输数据。6. 客户端向远程 Lynxus 节点发送创建事务的请求。7. 远程 Lynxus 节点接受事务。8. 数据发送到目标对等体。多个数据包可以批量方式发送。9. 当没有更多数据要发送，或达到批量限制时，通过计算发送数据的 CRC32 哈希在两端确认事务。10. 事务在两端提交。
反向代理配置
大多数反向代理软件实现 HTTP 和 TCP 代理模式。对于 Lynxus RAW 站点到站点协议，需要 HTTP 和 TCP 代理配置，至少需要开放 2 个端口。Lynxus HTTP 站点到站点协议可以将反向代理上所需的开放端口数量最少化为 1 个。
在反向代理处设置正确的 HTTP 头对于 Lynxus 正确工作至关重要，不仅用于路由请求，还用于授权客户端请求。详情请参见代理配置。
有两种类型的请求到 Lynxus 节点映射技术可以应用于反向代理服务器。一种是"服务器名称到节点"，另一种是"端口号到节点"。
使用"服务器名称到节点"，相同的端口可以根据请求的服务器名称（例如 lynxus0.example.com、lynxus1.example.com）将请求路由到不同的上游 Lynxus 节点。主机名解析应配置为将不同的主机名映射到相同的反向代理地址，这可以通过添加 /etc/hosts 文件或 DNS 服务器条目来完成。此外，如果反向代理的客户端使用 HTTPS，反向代理服务器证书应具有通配符通用名或 SAN，以便通过不同的主机名访问。
某些反向代理技术不支持服务器名称路由规则，在这种情况下，使用"端口号到节点"技术。"端口号到节点"映射在反向代理处需要 N 个开放端口对应由 N 个节点组成的 Lynxus 集群。
请参考以下示例了解实际配置。
站点到站点和反向代理示例
以下是一些示例反向代理和 Lynxus 设置，以说明配置文件的样子。
以下图中的 Client1 表示无法直接访问 Lynxus 节点的客户端，它通过反向代理访问，而 Client2 具有直接访问权限。
在此示例中，Nginx 用作反向代理。
示例 1：RAW - 服务器名称到节点映射
-
Client1 启动站点到站点协议，请求被路由到上游 Lynxus 节点之一。Lynxus 节点计算 RAW 的站点到站点端口。根据下方 lynxus.properties 中的路由规则 example1，返回端口 10443。2. Client1 向
lynxus.example.com:10443询问对等体，请求被路由到lynxus0:8081。Lynxus 节点计算可用对等体，根据 example1 路由规则，lynxus0:8081被转换为lynxus0.example.com:10443，lynxus1和lynxus2也是如此。结果返回lynxus0.example.com:10443、lynxus1.example.com:10443和lynxus2.example.com:10443。3. Client1 决定使用lynxus2.example.com:10443进行进一步通信。4. 另一方面，Client2 有两个站点到站点引导 URI，并使用其中一个启动协议。example1 路由不匹配此请求，返回端口 8081。5. Client2 从lynxus1:8081询问对等体。example1 不匹配，因此原始的lynxus0:8081、lynxus1:8081和lynxus2:8081按原样返回。6. Client2 决定使用lynxus2:8081进行进一步通信。
在 lynxus.properties 中定义的路由规则 example1（所有节点具有相同的路由配置）：
# S2S Routing for RAW, using server name to node
lynxus.remote.route.raw.example1.when=\
${X-ProxyHost:equals('lynxus.example.com'):or(\
${s2s.source.hostname:equals('lynxus.example.com'):or(\
${s2s.source.hostname:equals('192.168.99.100')})})}
lynxus.remote.route.raw.example1.hostname=${s2s.target.hostname}.example.com
lynxus.remote.route.raw.example1.port=10443
lynxus.remote.route.raw.example1.secure=true
nginx.conf :
http {
upstream lynxus {
server lynxus0:8443;
server lynxus1:8443;
server lynxus2:8443;
}
# Use dnsmasq so that hostnames such as 'lynxus0' can be resolved by /etc/hosts
resolver 127.0.0.1;
server {
listen 443 ssl;
server_name lynxus.example.com;
ssl_certificate /etc/nginx/nginx.crt;
ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_certificate /etc/nginx/nginx.crt;
proxy_ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_trusted_certificate /etc/nginx/lynxus-cert.pem;
location / {
proxy_pass https://lynxus;
proxy_set_header X-ProxyScheme https;
proxy_set_header X-ProxyHost nginx.example.com;
proxy_set_header X-ProxyPort 17590;
proxy_set_header X-ProxyContextPath /;
proxy_set_header X-ProxiedEntitiesChain <$ssl_client_s_dn>;
}
}
}
stream {
map $ssl_preread_server_name $lynxus {
lynxus0.example.com lynxus0;
lynxus1.example.com lynxus1;
lynxus2.example.com lynxus2;
default lynxus0;
}
resolver 127.0.0.1;
server {
listen 10443;
proxy_pass $lynxus:8081;
}
}
示例 2：RAW - 端口号到节点映射
example2 路由使用 equals 和 ifElse 表达式将原始主机名（lynxus0、lynxus1 和 lynxus2）映射到不同的代理端口（10443、10444 和 10445）。
在 lynxus.properties 中定义的路由规则 example2（所有节点具有相同的路由配置）：
# S2S Routing for RAW, using port number to node
lynxus.remote.route.raw.example2.when=\
${X-ProxyHost:equals('lynxus.example.com'):or(\
${s2s.source.hostname:equals('lynxus.example.com'):or(\
${s2s.source.hostname:equals('192.168.99.100')})})}
lynxus.remote.route.raw.example2.hostname=lynxus.example.com
lynxus.remote.route.raw.example2.port=\
${s2s.target.hostname:equals('lynxus0'):ifElse('10443',\
${s2s.target.hostname:equals('lynxus1'):ifElse('10444',\
${s2s.target.hostname:equals('lynxus2'):ifElse('10445',\
'undefined')})})}
lynxus.remote.route.raw.example2.secure=true
nginx.conf :
http {
# Same as example 1.
}
stream {
map $ssl_preread_server_name $lynxus {
lynxus0.example.com lynxus0;
lynxus1.example.com lynxus1;
lynxus2.example.com lynxus2;
default lynxus0;
}
resolver 127.0.0.1;
server {
listen 10443;
proxy_pass lynxus0:8081;
}
server {
listen 10444;
proxy_pass lynxus1:8081;
}
server {
listen 10445;
proxy_pass lynxus2:8081;
}
}
示例 3：HTTP - 服务器名称到节点映射
在 lynxus.properties 中定义的路由规则 example3（所有节点具有相同的路由配置）：
# S2S Routing for HTTP
lynxus.remote.route.http.example3.when=${X-ProxyHost:contains('.example.com')}
lynxus.remote.route.http.example3.hostname=${s2s.target.hostname}.example.com
lynxus.remote.route.http.example3.port=443
lynxus.remote.route.http.example3.secure=true
nginx.conf :
http {
upstream lynxus_cluster {
server lynxus0:8443;
server lynxus1:8443;
server lynxus2:8443;
}
# If target node is not specified, use one from cluster.
map $http_host $lynxus {
lynxus0.example.com:443 "lynxus0:8443";
lynxus1.example.com:443 "lynxus1:8443";
lynxus2.example.com:443 "lynxus2:8443";
default "lynxus_cluster";
}
resolver 127.0.0.1;
server {
listen 443 ssl;
server_name ~^(.+\.example\.com)$;
ssl_certificate /etc/nginx/nginx.crt;
ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_certificate /etc/nginx/nginx.crt;
proxy_ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_trusted_certificate /etc/nginx/lynxus-cert.pem;
location / {
proxy_pass https://$lynxus;
proxy_set_header X-ProxyScheme https;
proxy_set_header X-ProxyHost $1;
proxy_set_header X-ProxyPort 443;
proxy_set_header X-ProxyContextPath /;
proxy_set_header X-ProxiedEntitiesChain <$ssl_client_s_dn>;
}
}
}
Web 属性
这些属性与基于 Web 的用户界面相关。
属性 |
描述 |
|
HTTP 主机名。默认值为空白。 |
|
HTTP 端口。默认值为空白。 |
|
将传入 HTTP 请求转发到 |
|
Lynxus 应为 HTTP 请求绑定的网络接口名称。默认情况下为空白。 |
|
HTTPS 主机名。默认值为 |
|
HTTPS 端口。默认值为 |
|
与 |
|
用于初始化 Jetty HTTPS 端口 SSLContext 的密码套件。如果未指定，则使用运行时 SSLContext 默认值。 |
|
SSL 客户端可能无法用于建立与 Jetty 连接的密码套件。如果未指定，则使用运行时 SSLContext 默认值。 |
|
是否应在 HTTP 响应中包含 Server 头。默认值为 在 Chrome 中，可以在"开发者工具"插件的"安全"标签页中查看与 Jetty 协商的 SSL 密码。在 Firefox 中，可以在浏览器地址栏左侧的"安全连接"小部件中查看与 Jetty 协商的 SSL 密码。 |
|
Lynxus 应为 HTTPS 请求绑定的网络接口名称。默认情况下为空白。 |
|
启用 HTTPS 运行时支持的应用协议的空格分隔列表。 默认值为 该值可以设置为 该值可以设置为 |
|
Jetty 工作目录的位置。默认值为 |
|
Jetty 线程数。默认值为 |
|
请求和响应头允许的最大大小。默认值为 |
|
当应用程序通过反向代理接收请求时，在启用 HTTPS 运行时考虑的允许头值的逗号分隔列表。每个值可以包含域名，如`lynxus.acal.org.cn` 或带端口号的域名，如 包含无效端口的 反向代理服务器负责过滤输入请求头并向应用程序提供允许的代理主机值。代理主机头值必须限制为包含域名，不包含端口号。 |
|
要考虑的允许的 HTTP X-ProxyContextPath、X-Forwarded-Context 或 X-Forwarded-Prefix 头值的逗号分隔列表。默认情况下，此值为空白，表示包含代理上下文路径的所有请求都被拒绝。配置此属性将允许代理路径包含在此列表中的请求。 |
|
PUT 和 POST 请求允许的最大大小（HTTP |
|
每个连接每秒的最大请求数。超过此数量的请求首先被延迟，然后被限制。默认值为 |
|
每个连接每秒的登录访问令牌最大请求数。超过此数量的请求将被 HTTP 429 拒绝。默认值为 |
|
IP 地址的逗号分隔列表。用于指定可以超过每秒最大请求数（ |
|
Web 请求的请求超时。运行时间超过此时间的请求将被强制以 HTTP 503 Service Unavailable 响应结束。默认值为 |
|
HTTP 请求日志消息的参数化格式。格式属性支持 JettyCustomRequestLog 中描述的修饰符和代码。 默认值使用组合格式，遵循通用日志格式，并添加了 `%{client}a - %u %t "%r" %s %O "%{Referer}i" "%{User-Agent}i" CustomRequestLog 使用以下 SLF4J 记录器写入格式化消息：
|
|
控制 REST API 允许返回的 JMX MBean 名称的正则表达式。默认值为空，阻止所有 MBean。配置 |
安全属性
这些属性与 Lynxus 中的各种安全功能相关。其中许多属性在本管理员指南的安全配置 部分中有更详细的介绍。
属性 |
描述 |
|
这是用于加密在处理器中配置的任何敏感属性值的密码。默认情况下为空白，但系统管理员应为其提供值。它可以是任意长度的字符串，但推荐最小长度为 10 个字符。请注意，一旦设置了此密码并配置了一个或多个敏感处理器属性，就不应更改此密码。 |
|
用于加密敏感属性的算法。默认值为 |
|
指定是否应在检测到密钥库和信任库更新时自动重新加载 SSL 上下文工厂。默认情况下设置为 |
|
指定检查密钥库和信任库更新的间隔。仅在 |
|
密钥库的完整路径和名称。默认值为 |
|
密钥库类型。默认值为 |
|
密钥库密码。默认情况下为空白。 |
|
密钥密码。默认情况下为空白。 |
|
信任库的完整路径和名称。默认值为 |
|
信任库类型。默认值为 |
|
信任库密码。默认情况下为空白。 |
|
指定使用 authorizers.xml 文件中哪个已配置的授权器。默认情况下设置为 |
|
在通过 HTTPS 运行时是否允许匿名认证。如果设置为 true，则不需要客户端证书即可通过 TLS 连接。默认值为 |
|
这指示使用何种类型的登录身份提供程序。可以设置为 |
身份映射属性
这些属性可用于规范化用户身份。实施后，由不同身份提供程序（证书、LDAP、Kerberos）认证的身份在 Lynxus 内部被视为相同。因此，避免了重复用户，用户特定配置（如授权）只需为每个用户设置一次。
以下示例演示了从证书中规范化 DN 和从 Kerberos 中规范化主体：
lynxus.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$ lynxus.security.identity.mapping.value.dn=$1@$2 lynxus.security.identity.mapping.transform.dn=NONE lynxus.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$ lynxus.security.identity.mapping.value.kerb=$1@$2 lynxus.security.identity.mapping.transform.kerb=NONE
每个属性的最后一段是用于将模式与替换值关联的标识符。当用户向 Lynxus 发出请求时，会检查其身份是否按字典顺序匹配每个模式。对于第一个匹配的模式，使用 lynxus.security.identity.mapping.value.xxxx 属性中指定的替换。因此，使用 CN=localhost, OU=ACAL Lynxus, O=Apache, L=Santa Monica, ST=CA, C=US 登录将匹配上述 DN 映射模式，并应用 DN 映射值 $1@$2。用户被规范化为 localhost@ACAL Lynxus。
除了映射之外，还可以应用转换。支持的版本为 NONE（不应用转换）、LOWER（身份小写）和 UPPER（身份大写）。如果未指定，默认值为 NONE。
| 这些映射也应用于 authorizers.xml 文件中的"初始管理员身份"、"集群节点身份"和任何旧版用户，以及从 LDAP 导入的用户（参见Authorizers.xml 设置）。 |
组名也可以被映射。以下示例将接受现有组名但将其小写。当与外部授权器一起使用时，这可能有帮助。
lynxus.security.group.mapping.pattern.anygroup=^(.*)$ lynxus.security.group.mapping.value.anygroup=$1 lynxus.security.group.mapping.transform.anygroup=LOWER
| 这些映射应用于 authorizers.xml 中引用的任何旧版组以及从 LDAP 导入的组。 |
集群通用属性
设置 Lynxus 集群时，这些属性应在所有节点上以相同方式配置。
属性 |
描述 |
|
节点应向集群协调器发送心跳的间隔。默认值为 |
|
集群协调器在将节点状态更新为已断开连接之前可以错过的最大心跳数。默认值为 |
集群节点属性
为集群节点配置这些属性。
属性 |
描述 |
|
如果实例是集群中的节点，则将此设置为 |
|
集群领导者选举实现类名或简单类名。 默认值为 该实现可以设置为 |
|
应用于 Kubernetes Leases 的前缀字符串，用于跟踪集群领导者选举。在同一 Kubernetes 命名空间中运行多个ACAL Lynxus 集群时，配置前缀是必需的。默认值为空白。 |
|
节点的完全限定地址。默认情况下为空白。 |
|
节点的协议端口。默认情况下为空白。 |
|
用于与集群中其他节点通信的最大线程数。此属性默认为 |
|
当集群中节点的状态发生更改时，会生成一个事件，可以在集群页面中查看。此值指示为每个节点保留多少个事件在内存中。默认值为 |
|
连接到集群中的另一个节点时，指定此节点在认为连接失败之前应等待多长时间。默认值为 |
|
与集群中的另一个节点通信时，指定此节点在认为与节点的通信失败之前应等待从远程节点接收信息多长时间。默认值为 |
|
可以复制到集群中节点的未完成 Web 请求的最大数量。如果超过此数量的请求，嵌入式 Jetty 服务器将返回 "409: Conflict" 响应。此属性默认为 |
|
节点防火墙文件的位置。这是一个可用于列出所有允许连接到集群的节点的文件。它提供了额外的安全层。默认情况下此值为空白，表示不使用防火墙文件。有关文件格式详情，请参见集群防火墙配置。 |
|
指定在选举数据流为"正确"数据流之前等待的时间量。如果已投票的节点数等于`lynxus.cluster.flow.election.max.candidates` 属性指定的数量，集群不会等待这么长时间。默认值为 |
|
指定集群中导致提前选举数据流所需的节点数。这允许集群中的节点避免在达到至少此数量的节点时长时间等待后才开始处理。 |
|
指定监听传入连接的端口，用于在集群中负载均衡数据。默认值为 |
|
指定监听传入连接的主机名，用于在集群中负载均衡数据。如果未指定，将默认使用`lynxus.cluster.node.address` 属性的值。此处设置的值不必是集群外部可访问的主机名/IP 地址。但是，集群中的所有节点必须能够使用此主机名/IP 地址连接到节点。 |
|
此节点与集群中每个其他节点之间要创建的最大连接数。例如，如果集群中有 5 个节点且此值设置为 4，则最多将建立 20 个套接字连接用于负载均衡目的（5 x 4 = 20）。默认值为 |
|
用于将此节点的数据传输到集群中其他节点的最大线程数。虽然给定线程一次只能写入单个套接字，但单个线程能够同时服务多个连接，因为给定连接在任何给定时间可能不可用于读取/写入。默认值为 NOTE: 增加此值将允许使用额外的线程与集群中的其他节点通信并将数据写入内容和 FlowFile 存储库。但是，如果此属性设置的值大于集群中的节点数乘以每个节点的连接数（ |
|
与另一个节点通信时，如果从套接字读取或写入时经过此时间量而没有取得任何进展，则将抛出 TimeoutException。然后这将导致数据要么被重试，要么被发送到集群中的另一个节点，具体取决于配置的负载均衡策略。默认值为 |
ZooKeeper 属性
Lynxus 依赖 Apache ZooKeeper 来确定集群中哪个节点应扮演主节点的角色，以及哪个节点应扮演集群协调器的角色。必须配置这些属性才能使 Lynxus加入集群。
属性 |
描述 |
|
连接到 Apache ZooKeeper 所需的连接字符串。这是一个逗号分隔的主机名:端口对列表。例如 |
|
连接到 ZooKeeper 时等待多长时间后认为连接失败。默认值为 |
|
失去与 ZooKeeper 的连接后等待多长时间后会话过期。默认值为 |
|
应在 ZooKeeper 中使用的根 ZNode。ZooKeeper 提供类似目录的结构用于存储数据。此结构中的每个"目录"称为 ZNode。这表示应用于存储数据的根 ZNode 或"目录"。默认值为 |
|
是否使用客户端 TLS 访问 ZooKeeper。默认值为 |
|
与 ZooKeeper 通信时使用的包含私钥的密钥库文件名。 |
|
可选。密钥库的类型。必须为 |
|
密钥库的密码。 |
|
用于验证 ZooKeeper 服务器的信任库文件名。 |
|
可选。信任库的类型。必须为 |
|
信任库的密码。 |
|
发送到 ZooKeeper 和从 ZooKeeper 接收的数据包的最大缓冲区大小（以字节为单位）。遵循 ZooKeeper 默认 ZooKeeper 管理员指南 将此属性归类为*不安全选项*。更改此属性*需要*在 ZooKeeper 服务器上设置 |
Kerberos 属性
属性 |
描述 |
|
krb5 文件的位置（如果使用）。默认情况下为空白。目前，每个 Lynxus 实例只允许指定一个 krb5 文件，因此此属性在此处配置以支持服务主体，而不是在各个处理器中配置。如有必要，krb5 文件可以支持多个域。示例： |
|
Lynxus Kerberos 服务主体的名称（如果使用）。默认情况下为空白。请注意，此属性用于 Lynxus 作为客户端认证到其他系统。示例： |
|
Lynxus Kerberos keytab 的文件路径（如果使用）。默认情况下为空白。请注意，此属性用于 Lynxus 作为客户端认证到其他系统。示例： |
分析属性
这些属性决定内部 Lynxus 预测分析功能的行为，例如反压预测，应在所有节点上以相同方式配置。
属性 |
描述 |
|
这指示是否应为集群启用预测。默认值为 |
|
进行分析预测（例如队列饱和）的时间间隔。默认值为 |
|
查询过去观测数据（例如最近 3 分钟的快照）的时间间隔。默认值为 |
|
用于进行连接预测的状态分析模型的实现类。默认值为 |
|
应用于评估模型的评分类型名称。默认值为 |
|
评分值的阈值（模型分数应高于给定阈值）。默认值为 |
运行时监控属性
长时间运行任务监视器定期检查 Lynxus 处理器执行线程，并为运行时间较长的线程生成警告日志和公告消息。它可用于检测可能卡住/挂起的处理器任务。请注意任务监视器的性能影响：它为每次运行创建线程转储，可能会影响正常的数据流执行。长时间运行任务监视器可以通过不为其属性定义值来禁用，默认情况下已禁用。要启用它，lynxus.monitor.long.running.task.schedule 和 lynxus.monitor.long.running.task.threshold 属性都需要配置有效的时间段。
属性 |
描述 |
|
长时间运行任务监视器连续执行之间的时间段（例如 |
|
任务被视为长时间运行（即卡住/挂起）的时间段阈值（例如 |
性能跟踪属性
Lynxus 默认通过用户界面暴露大量指标。但是，有时可能需要额外的指标来帮助诊断瓶颈并改善 Lynxus 数据流的性能。
lynxus.performance.tracking.percentage 属性可用于启用额外指标的跟踪。但是，收集这些指标需要系统调用，这在某些系统上可能消耗较大。因此，此属性默认值为 0，表示 0% 的时间捕获指标。即，此功能默认禁用。要启用此功能，将此属性的值设置为 0 到 100 之间（含）的整数值。这表示 Lynxus 应在多少百分比的时间内收集这些指标。
例如，如果值设置为 20，则 Lynxus 将在处理器运行的约 20% 的时间内为每个处理器收集这些指标。其余时间，它将使用已捕获的值来推断额外运行的指标。
收集的指标包括处理器利用 CPU 的时间百分比（相对于等待 I/O 完成或因监视器/锁争用而阻塞），处理器从内容存储库读取、写入内容存储库、因垃圾回收而阻塞等的时间百分比。
因此，继续我们的示例，如果我们设置了 lynxus.performance.tracking.percentage 的值，处理器被触发运行 1,000 次，则 Lynxus 将测量在200 次迭代（即 1,000 的 20%）期间消耗了多少 CPU时间。假设这相当于 500 毫秒的 CPU 时间。此外，让我们考虑处理器完成这 200 次调用花费了 5,000 毫秒，因为大部分时间花在阻塞 Socket I/O 上。由此，Lynxus 将计算出 CPU大约 10% 的时间被使用（500 / 5,000 * 100%）。现在，让我们考虑完成所有 1,000 次调用处理器花费了 35 秒。Lynxus 将计算，处理器使用了大约 3.5 秒（或 3500 毫秒）的 CPU 时间。因此，如果我们将此属性的值设置得更高，最高到 100，我们将获得更准确的结果。但是，监控可能更消耗资源。
要查看这些指标，我们可以通过运行命令 lynxus.sh diagnostics <filename> 收集诊断信息并检查生成的文件。更多信息请参见[lynxus_diagnostics]。
NAR 提供程序属性
这些属性用于所有已配置的提供程序。
属性 |
描述 |
|
轮询之间的间隔。默认值为 |
|
要使用的冲突解决策略的名称。默认为 |
|
如果为 true，提供程序将阻止 Lynxus 启动，直到第一次成功获取资源。 |
以下属性允许配置一个或多个 NAR 提供程序。NAR 提供程序从外部源检索 NAR 并将其复制到 lynxus.nar.library.autoload.directory 指定的目录。
每个 NAR 提供程序属性遵循格式 lynxus.nar.library.provider.<identifier>.<property-name>，每个提供程序必须至少有一个名为 implementation 的属性。
HDFS NAR 提供程序
HDFS NAR 提供程序使用 Hadoop FileSystem API 检索 NAR。这可以与传统的 HDFS 实例或云存储（如 s3a 或 abfs）一起使用。要使用云存储，必须使用启用的云存储配置文件重新构建 Hadoop Libraries NAR。
属性 |
描述 |
|
实现类的完全限定类名，即 |
|
配置资源的逗号分隔列表，如 |
|
可选的存储位置，如 |
|
存储位置中 NAR 所在的目录。 |
|
可选的 Kerberos 主体用于认证。如果指定，还必须指定 keytab 或密码之一。 |
|
可选的 Kerberos keytab 用于认证。 |
|
可选的 Kerberos 密码用于认证。 |
Lynxus Registry NAR 提供程序
Lynxus Registry NAR 提供程序从 Lynxus Registry 实例检索 NAR。在安全安装中，此提供程序将从 Lynxus 服务器被授权读取的所有存储桶中检索 NAR。
属性 |
描述 |
|
实现类的完全限定类名，即 |
|
Lynxus Registry 实例的 URL，如 |
密钥管理器属性
这些属性配置密钥管理器，负责解析连接器使用的密钥。密钥管理器委托参数提供程序检索密钥值。
属性 |
描述 |
|
密钥管理器实现的完全限定类名。默认为 |
|
解析的密钥值在从底层参数提供程序刷新之前缓存的持续时间。接受任何 Lynxus 时间持续时间值，如 |
从版本化进程组迁移连接器
Lynxus 支持一次性路径，将新创建的连接器从源版本化进程组迁移到独立的连接器。源版本化进程组用作参考：连接器读取它并更新自己的配置。源数据流本身不会安装到连接器上。只有实现迁移支持的连接器才能使用此功能。
本地迁移的先决条件
当源是同一 Lynxus 实例上的本地进程组时，进程组必须满足先决条件。
-
源进程组必须处于版本控制下。
-
源进程组必须与最新发布的版本保持
UP_TO_DATE。 -
源进程组中的所有处理器必须已停止。
-
源进程组中的所有控制器服务必须已禁用。
-
源进程组中的所有队列必须为空。
-
源进程组不得引用其外部的控制器服务。
-
目标连接器必须尚未配置、已停止，且之前未迁移过。
-
迁移开始时，目标连接器的活动数据流必须为空。连接器
如果源进程组未处于版本控制下，请导出它并使用
迁移路径
运行迁移有两种方式：
-
本地迁移 - 源和目标在同一个 Lynxus 实例中。2. 远程迁移 - 源在一个 Lynxus 实例中，目标在另一个 Lynxus 实例中。Lynxus 在开始迁移之前会验证上述先决条件。
-
上传有效载荷迁移： 要运行本地迁移，请使用 Lynxus CLI：此路径适用于非版本控制的源、从另一个 Lynxus 实例导出的源，或任何无法满足本地版本控制要求的源。
-
对于上传的有效载荷，Lynxus 不要求源流处于版本控制之下。要运行远程迁移，源和目标 Lynxus 实例都必须启用站点到站点。
运行迁移
-
创建一个新的连接器实例。
-
如果源进程组是本地的且基于注册表，请从连接器迁移源列表中选择它。 迁移过程将以下内容从源进程组转移到目标连接器：
-
启动连接器迁移请求。
-
处理器配置和连接
-
控制器服务配置
-
参数上下文绑定
-
Lynxus 迁移的内容
在迁移过程中，Lynxus 向连接器提供导出的流程定义、参数上下文、引用的资产以及任何附加的 @Stateful 组件状态。连接器执行流程翻译并更新其管理的流程以镜像源。迁移成功后：对于本地迁移，连接器还可以将引用的资产从源进程组复制到连接器自己的资产命名空间中。
- 验证目标连接器的数据流是否正确。
- 移除源进程组。
- 如果不再需要，取消版本控制。
迁移后，在启动连接器之前，使用任何缺少的密钥值配置连接器。
迁移成功后的清理
在集群环境中，迁移遵循以下规则：这样可以清楚地表明源流已被用作连接器迁移的基础。 - 组件状态与集群拓扑一起存储。 - 迁移后，状态与新拓扑关联。 - 如果目标连接器在不同节点上，状态将自动迁移。 - 确保所有节点都已完成迁移过程。 === 组件状态的集群拓扑规则
当要迁移的源流程包含有状态组件的 LOCAL 组件状态（例如 @Stateful 处理器或控制器服务）时，目标集群的连接节点数必须至少与源流程导出的状态引用数一样多。迁移管理器应用的规则是：
size(component.localNodeStates) <= number of connected nodes in the destination cluster
这与将版本化进程组导入目标集群时适用的规则相同。Lynxus 对本地迁移路径和上传有效载荷路径都强制执行此规则，以便 LOCAL 状态可以明确地分布到目标集群中。
当迁移请求失败并显示类似 Cannot import flow with component state: the flow definition contains local state from N source node(s) but the destination cluster has only M connected node(s) 的消息时，请执行以下操作之一：
-
重新连接所有已断开的集群节点，使目标集群至少有
N个连接节点，然后重新运行迁移。 -
重新导出源流程（不包含组件状态）（取消选中"include component state"选项）并重新上传有效载荷。 连接器将在每个目标节点上以空的 LOCAL 状态启动，这在 LOCAL 状态可从上游系统重现时适用。
-
迁移到至少有
N个连接节点的集群中。
当任何集群节点在提交请求时处于 CONNECTING、DISCONNECTED 或 DISCONNECTING 状态时，迁移请求也会被拒绝，因为组件状态和资产内容无法同步到当前未连接的节点。重新连接已断开的节点并重新提交请求。
升级 Lynxus
以下是从 1.x.0 版本升级到另一个版本时应遵循的一般步骤。
升级前，您应该查看要升级到的版本的发行说明。
| 集群中的所有节点必须升级到相同的 Lynxus 版本，因为同一集群中不支持不同 Lynxus 版本的节点。 |
保留自定义处理器
如果您有任何自定义 NAR，请将它们存储在 Lynxus 安装目录之外的集中位置以在升级期间保留它们。
-
创建第二个库目录，称为
custom_lib。2. 将您的自定义 NAR 移动到此新的库目录。3. 在 lynxus.properties 文件中添加新行以指定此新 lib 目录：lynxus.nar.library.directory=./lib lynxus.nar.library.directory.custom=/opt/configuration_resources/custom_lib
保留修改的 NAR
如果您修改了任何默认 NAR 文件，升级将覆盖这些修改。
-
识别并保存您对默认 NAR 文件所做的更改。2. 执行 Lynxus 升级。3. 在新的 Lynxus 实例中实施相同的 NAR 文件更改。
安装新的 Lynxus 版本
在新的 Lynxus 版本上：
-
安装新的 Lynxus 版本。2. 将现有 Lynxus 安装中的 conf 目录复制到新安装中。3. 将现有 Lynxus 安装中的任何自定义 lib 目录复制到新安装中。4. 更新新 Lynxus 安装中的 lynxus.properties 文件以反映任何更改。5. 启动新的 Lynxus 实例。 |-→ opt/ |-→ existing-lynxus |-→ new-lynxus 从旧 Lynxus 安装复制配置文件后，必须更新某些属性：主机 - 节点 21. 更新 lynxus.properties： |-→ existing-lynxus
-
验证
lynxus.flow.configuration.file指向正确的位置。 -
验证所有存储库目录路径是否正确。
-
如果使用集群，更新集群相关属性。 |-→ opt/
-
-
更新 authorizers.xml： |-→ new-lynxus
-
验证用户和组文件路径。
-
验证初始用户身份。
-
更新新 Lynxus 安装的配置文件
如果 Lynxus 配置了敏感属性加密，则必须更新算法：使用现有 Lynxus 安装中的配置文件手动更新新 Lynxus 部署中的相应属性。如果从使用旧加密算法的版本升级，请更新 lynxus.properties 中的`lynxus.sensitive.props.algorithm` 以匹配新算法。
使用以下表格指导更新位于 <installation-directory>/conf 中的配置文件。如果敏感属性密钥需要更改：[options="header"]1. 使用 Lynxus 工具包迁移敏感属性。2. 运行 lynxus.sh migrate 命令进行密钥转换。
|authorizers.xml | 将在现有 authorizers.xml 中配置的 <authorizer>…</authorizer> 复制到新 Lynxus 文件中。
启动新 Lynxus 后：
-
验证所有处理器和控制器服务是否正确加载。2. 验证数据流是否完整。3. 启动处理器并监控数据流。4. 验证集群状态（如果适用）。如果通过 lynxus.properties 中的敏感属性密钥加密数据流中的敏感组件属性，请确保在复制 flow.json.gz 时使用相同的密钥。如果需要更改密钥，请参见下面的[sensitive_flow_migration]部分。
|使用现有的 lynxus.properties 在新 Lynxus 文件中填充相同的属性。
注意： 此文件包含大部分 Lynxus 配置设置，因此请确保已正确复制这些值。
|如果您遵循了 Lynxus 最佳实践，以下属性应指向 Lynxus 基础安装路径之外的外部目录。
如果以下属性指向 Lynxus 基础安装路径内的目录，则必须将目标目录复制到新 Lynxus。在执行此操作之前，请停止现有的 Lynxus 安装。
|lynxus.flow.configuration.file=
如果您保留了默认值 (./conf/flow.json.gz)，请将 flow.json.gz 从现有 Lynxus 复制到新 Lynxus 的基础安装 conf 目录。
如果将流程存储到外部位置，请更新属性值以指向该位置。
|lynxus.flow.configuration.archive.dir=
如果要保留 flow.json.gz 的归档副本，同样适用上述说明。
|lynxus.database.directory=
最佳实践建议为每个存储库使用外部位置。将新 Lynxus 指向相同的外部数据库存储库位置。
|lynxus.flowfile.repository.directory=
最佳实践建议为每个存储库使用外部位置。将新 Lynxus 指向相同的外部 FlowFile 存储库位置。
Warning: You may experience data loss if flowfile repositories are not accessible to the new Lynxus.
|lynxus.content.repository.directory.default=
最佳实践建议为每个存储库使用外部位置。将新 Lynxus 指向相同的外部内容存储库位置。
您现有的 Lynxus 可能定义了多个内容存储库。确保使用完全相同的属性名称并指向相应的匹配内容存储库位置。例如：
lynxus.content.repository.directory.content1=
lynxus.content.repository.directory.content2=
Warning: You may experience data loss if content repositories are not accessible to the new Lynxus.
Warning: You may experience data loss if property names are wrong or the property points to the wrong content repository.
|lynxus.provenance.repository.directory.default=
最佳实践建议为每个存储库使用外部位置。将新 Lynxus 指向相同的外部溯源存储库位置。
您现有的 Lynxus 可能定义了多个溯源存储库。确保使用完全相同的属性名称并指向相应的匹配溯源存储库位置。例如：
lynxus.provenance.repository.directory.provenance1=
lynxus.provenance.repository.directory.provenance2=
Note: You may not be able to query old events if provenance repos are not moved correctly or properties are not updated correctly.
local-provider 状态提供程序，验证本地目录的位置。如果您保留了默认位置 (./state/local)，请将完整的目录树复制到新 Lynxus。如果正在复制此目录，应停止现有的 Lynxus，因为它在运行时可能会持续写入此目录。
配置最佳实践建议将状态移动到外部目录（如 /opt/lynxus/configuration-resources/），以便于后续升级。
| For a Lynxus cluster, the cluster-provider
| 对于 Lynxus 集群，cluster-provider ZooKeeper"Connect String"属性应设置为与现有 Lynxus 安装相同的外部 ZooKeeper。
| 对于 Lynxus 集群，确保 cluster-provider ZooKeeper"Root Node"属性与现有 Lynxus 中使用的值完全匹配。
| 如果您还在设置新的外部 ZooKeeper，请参阅[zookeeper_migrator]部分，了解如何将 ZooKeeper 信息从一个集群移动到另一个集群并迁移 ZooKeeper 节点所有权。
WARNING: 仔细检查所有配置的属性是否有拼写错误。 ==== 更新敏感属性算法 以下命令可用于读取现有流程配置并在 lynxus.properties 中设置新的敏感属性算法：
该命令从 lynxus.properties 读取以下流程配置文件属性： - 该命令检查每个文件是否存在，并更新找到的敏感属性值。 有关支持的值，请参见属性加密算法。 ==== 更新敏感属性密钥 从 1.14.0 版本开始，Lynxus 需要 lynxus.properties 中 以下命令可用于读取现有流程配置并在 lynxus.properties 中设置新的敏感属性密钥：
该命令从 lynxus.properties 读取以下流程配置文件属性： - 该命令检查文件是否存在，并更新找到的敏感属性值。 新敏感属性密钥所需的最小长度为 12 个字符。 === 启动新 Lynxus 在新的 Lynxus 安装中： 1. 启动每个新的 Lynxus 实例。2. 验证：
* 所有数据流已恢复运行状态。某些处理器可能具有需要配置的新属性，在这种情况下它们将被停止并标记为无效 ( NOTE: 如果原始 Lynxus 配置为作为服务运行，请更新任何符号链接或服务脚本以指向新的 Lynxus 版本可执行文件。 == 处理器位置 Lynxus 为处理器位置提供了 3 种配置选项。即： lynxus.nar.library.directory lynxus.nar.library.directory.<custom> lynxus.nar.library.autoload.directory NOTE: 使用这些选项设置的路径相对于 Lynxus 主目录。例如，如果 Lynxus 主目录为
lynxus.nar.library.directory.myCustomLibs=./my-custom-nars/lib lynxus.nar.library.directory.otherCustomLibs=./other-custom-nars/lib
lynxus.nar.library.autoload.directory=./autoload/lib === 安装自定义处理器 本节描述了安装自定义处理器的原始过程，每次更改后都需要重启 Lynxus。 在 lynxus.properties 中添加： lynxus.nar.library.directory.myCustomLibs=./my-custom-nars/lib 确保此目录存在并具有 lynxus 用户的适当权限。 将自定义 NAR 文件复制到此目录并重启 Lynxus。 确保文件对 lynxus 用户和组具有适当的权限。 Lynxus 支持自动加载自定义处理器。配置自动加载目录： 在 lynxus.properties 中：
=== 自动加载自定义处理器
lynxus.nar.autoload.directory=./autoload/lib
本节介绍如何使用自定义处理器的自动加载功能。Lynxus 将监控此目录中的新 NAR 文件并自动加载它们。要使用自动加载功能，必须将 例如：NAR 提供程序支持从远程源加载 NAR。 lynxus.nar.library.autoload.directory=./extensions有关更多信息，请参见NAR 提供程序属性。现在，我们必须将自定义处理器 nar 放在配置的目录中。配置的目录相对于 Lynxus 主目录；例如，假设我们的 Lynxus 主目录为 刷新浏览器页面，现在在将新处理器添加到数据流时应该可以使用自定义处理器了。HDFS 外部资源提供程序从 HDFS 加载 NAR。 === NAR 提供程序 - 默认情况下，轮询每 5 分钟进行一次。可以通过指定 默认情况下，如果 |
| 名称 | 描述 | IGNORE | 不会替换文件：如果目录中已存在同名文件，则不会再次下载。 | REPLACE | 如果源中有可用文件且修改日期更新，则将替换目标目录中的文件。
在每个提供程序的首次外部资源收集成功之前，该服务会阻止 Lynxus 完成启动。要覆盖此行为，需要声明 值为 外部资源提供程序可以通过添加
==== HDFS 外部资源提供程序 此实现能够从 HDFS 文件系统下载文件。
[options="header"] |
| 名称 | 描述 | resources | HDFS 资源列表，以逗号分隔。 | source.directory | HDFS 中 NAR 文件的源目录。注意：该提供程序不会递归检查文件。 | storage.location | 可选。如果设置，core-site.xml 中定义的存储位置将被此值覆盖。 | kerberos.principal | 可选。用于认证的 Kerberos 主体。 | kerberos.keytab | 可选。与主体关联的 Kerberos keytab。 | kerberos.password | 可选。与主体关联的 Kerberos 密码。
示例配置： lynxus.nar.library.provider.hdfs1.implementation=cn.org.acal.lynxus.flow.resource.hadoop.HDFSExternalResourceProvider lynxus.nar.library.provider.hdfs1.resources=/etc/hadoop/core-site.xml lynxus.nar.library.provider.hdfs1.source.directory=/customNars lynxus.nar.library.provider.hdfs2.implementation=cn.org.acal.lynxus.flow.resource.hadoop.HDFSExternalResourceProvider lynxus.nar.library.provider.hdfs2.resources=/etc/hadoop/core-site.xml lynxus.nar.library.provider.hdfs2.source.directory=/other/dir/for/customNars 可以通过执行以下命令从 Lynxus 节点获取诊断数据：
如果未指定文件参数，信息将添加到 在诊断命令执行期间，Lynxus 引导进程向正在运行的 Lynxus 实例发送请求以收集诊断信息。
Lynxus 可以配置为在事件发生时自动执行诊断命令。 这在排查启动问题或崩溃时特别有用。 |
属性 |
*描述*自动诊断可以配置在以下事件中运行： |
|
(true 或 false) 此属性决定是否以详细模式运行 Lynxus 诊断。默认值为 |
|
此属性指定诊断目录允许的最大大小。如果超过限制，将删除最旧的文件。默认值为 如果诊断过程耗时较长，Lynxus 可能在命令执行完成之前终止。 === 内存溢出错误时的自动堆转储 可以在 java.arg.heapDumpPath=-XX:HeapDumpPath=./work java.arg.heapDumpOnOutOfMemory=-XX:+HeapDumpOnOutOfMemoryError 这些属性值（如示例中设置）将导致在发生内存溢出错误时生成堆转储。 堆转储文件的位置可以通过 Lynxus 支持通过 Java Management Extensions (JMX) 暴露指标。 Lynxus 支持通过 Java 管理扩展 (JMX) 公开指标。 要启用 JMX，请在 bootstrap.conf 中添加以下参数：此属性为空表示不返回任何 MBean。默认值阻止所有 MBean，必须更改才能返回java.arg.jmx=-Dcom.sun.management.jmxremote 这允许 JMX 客户端（如 JConsole 或 VisualVM）连接到 Lynxus JVM。 可以配置以下 JMX 相关属性：将此参数留空表示列出所有 MBean，但被阻止过滤模式过滤的除外。
- |