这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

管理客户端连接

Vertica 提供了多种设置来控制客户端连接：

  • 限制用户可以同时打开的客户端连接数。

  • 限制客户端连接在自动断开之前可以处于空闲状态的时间。

  • 使用连接负载均衡将为客户端连接提供服务所产生的开销分摊到各个节点。

  • 使用 TCP keepalive 检测无响应的客户端。

  • 排空子群集以拒绝与该子群集建立的任何新客户端连接。有关详细信息，请参阅排空客户端连接。

与给定节点建立的客户端连接总数不能超过 MaxClientSessions 中设置的限值。

对客户端的 MAXCONNECTIONS 属性进行更改不会对当前会话产生影响；这些更改将仅应用于新会话。例如，如果将用户的连接模式从 DATABASE 更改为 NODE，则当前节点连接不会受到影响。此更改仅应用于 在调用节点上保留的新会话。

当 Vertica 关闭某个客户端连接时，将取消该客户端正在进行的操作（如有）。

管理 TCP keepalive 设置

Vertica 会使用 TCP keepalive 来检测无响应的客户端并确定应关闭连接的时间。

以下参数控制数据库的 TCP keepalive 策略。数据库的参数会覆盖内核级别的等效参数（tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes）：

  • KeepAliveIdleTime：发送第一个 TCP keepalive 探测器以确保客户端仍处于连接状态之前的时间（以秒为单位，默认值为 7200 秒）。

  • KeepAliveProbeInterval：keepalive 探测器之间的时间间隔（以秒为单位，默认值为 75 秒）。

  • KeepAliveProbeCount：将客户端连接视为断开并关闭之前，必须由客户端取消确认的连续 keepalive 探测器次数（默认值为 9）。

要查看当前会话的有效 TCP keepalive 设置，请使用 SHOW CURRENT：

=> SHOW CURRENT KeepAliveIdleTime, KeepAliveProbeInterval, KeepAliveProbeCount;
  level  |          name          | setting
---------+------------------------+---------
 DEFAULT | KeepAliveIdleTime      | 7200
 DEFAULT | KeepAliveProbeInterval | 75
 DEFAULT | KeepAliveProbeCount    | 9
(3 rows)

示例

以下是示例 TCP keepalive 策略：

  • 10 分钟后，将第一个 keepalive 探测器发送到客户端。

  • 每隔 30 秒发送一次连续的 keepalive 探测器。

  • 如果客户端无法响应 10 个 keepalive 探测器，则将连接视为断开并关闭。

要将此策略设为客户端连接的默认策略：

=> ALTER DATABASE DEFAULT SET KeepAliveIdleTime = 600;
=> ALTER DATABASE DEFAULT SET KeepAliveProbeInterval = 30;
=> ALTER DATABASE DEFAULT SET KeepAliveProbeCount = 10;

同样，要将此策略用于当前会话，可以使用 ALTER SESSION。这会覆盖默认/数据库级别策略：

=> ALTER SESSION SET KeepAliveIdleTime = 600;
=> ALTER SESSION SET KeepAliveProbeInterval = 30;
=> ALTER SESSION SET KeepAliveProbeCount = 10;

限制空闲会话长度

如果客户端继续响应 TCP keepalive 探测器，但未运行任何查询，则将客户端的会话视为空闲。空闲会话最终会超时。可以在三个级别设置允许会话空闲的最长时间，按优先级降序排列：

  • 以 dbadmin 身份为各个用户设置 IDLESESSIONTIMEOUT 属性。此属性会覆盖所有其他会话超时设置。

  • 用户可以使用 SET SESSION IDLESESSIONTIMEOUT 来限制当前会话的空闲时间。非超级用户只能将会话空闲时间设置为不大于自己设置的 IDLESESSIONTIMEOUT 值。如果没有为用户显式设置会话空闲时间，则该用户的会话空闲时间将从节点或数据库设置继承。

  • 以 dbadmin 身份对数据库或各个节点设置配置参数 DEFAULTIDLESESSIONTIMEOUT。您可以使用配置参数 DEFAULTIDLESESSIONTIMEOUT 来限制默认数据库群集或各个节点。此参数会为所有非超级用户设置默认超时值。

所有设置都应用于持续处于空闲状态的会话，即未在运行查询的会话。如果客户端在查询执行期间很慢或没有响应，则该时间不会应用于超时。例如，流式批量插入所需的时间不会计入超时。从开始等待来自某会话的任何类型的消息那一刻起，服务器会将该会话标识为空闲。

查看会话设置

关闭用户会话

要手动关闭用户会话，请使用 CLOSE_USER_SESSIONS：

=> SELECT CLOSE_USER_SESSIONS ('Joe');
                             close_user_sessions
------------------------------------------------------------------------------
 Close all sessions for user Joe sent. Check v_monitor.sessions for progress.
(1 row)

示例

用户执行某个查询后，由于某种原因，该查询需要很长时间才能完成（例如，由于服务器流量或查询比较复杂）。在这种情况下，用户可能会认为该查询失败并打开另一个会话来运行相同查询。现在，两个会话会使用额外的连接运行相同的查询。

为了防止出现这种情况，您可以通过修改其 MAXCONNECTIONS 用户属性来限制各个用户可以运行的会话数。这样有助于最大程度地降低运行冗余查询的概率。此外，还有助于防止用户使用数据库所设置的所有可用连接。例如，针对用户 SuzyQ 的以下设置将限制该用户在任何时候运行的数据库会话不得超过两个：

=> CREATE USER SuzyQ MAXCONNECTIONS 2 ON DATABASE;

当用户多次连接到服务器时，可限制设置客户端连接所能防止出现的另一个问题。用户连接过多会耗尽数据库配置参数 MaxClientSessions 所设置的允许连接数。

群集更改和连接

当群集发生以下变化时，客户端连接限值的行为可能会发生变化：

  • 添加或移除节点。

  • 节点发生故障或恢复。

连接请求之间的节点可用性发生变化对连接限值的影响较小。

就遵守连接限值而言，当节点在连接请求之间发生故障或恢复时，不会产生重大影响。无需执行特别操作来处理此问题。但是，如果节点发生故障，其活动会话将退出且群集中的其他节点也会删除自己的会话。这将释放连接。查询可能会挂起，在这种情况下，会话被阻止合乎情理且符合预期。

1 - 限制客户端连接的数量和长度

您可以管理用户可以向服务器打开的活动会话数，以及这些会话的持续时间。这样有助于防止过度使用可用资源，并可以提高总体吞吐量。

您可以在两个级别定义连接限值：

  • 为各个用户设置 MAXCONNECTIONS 属性。此属性指定用户可以在各个节点上或跨数据库群集同时打开的会话数。例如，以下 ALTER USER 语句允许用户 Joe 最多打开 10 个并发会话：

    => ALTER USER Joe MAXCONNECTIONS 10 ON DATABASE;

  • 对数据库或各个节点设置配置参数 MaxClientSessions。此参数指定可以在数据库群集中的节点上运行的最大客户端会话数，默认设置为 50。系统会始终为 dbadmin 用户额外保留五个会话。这使他们能够在客户端会话总数等于 MaxClientSessions 时登录。

与给定节点建立的客户端连接总数不能超过 MaxClientSessions 中设置的限值。

对客户端 MAXCONNECTIONS 属性进行更改不会对当前会话产生影响；这些更改将仅应用于新会话。例如，如果将用户的连接模式从 DATABASE 更改为 NODE，则当前节点连接不会受到影响。此更改仅应用于 在调用节点上保留的新会话。

限制空闲会话长度

空闲会话最终会超时。可以在三个级别设置允许会话空闲的最长时间，按优先级降序排列：

  • 以 dbadmin 身份为各个用户设置 IDLESESSIONTIMEOUT 属性。此属性会覆盖所有其他会话超时设置。

  • 用户可以使用 SET SESSION IDLESESSIONTIMEOUT 来限制当前会话的空闲时间。非超级用户只能将会话空闲时间设置为不大于自己设置的 IDLESESSIONTIMEOUT 值。如果没有为用户显式设置会话空闲时间，则该用户的会话空闲时间将从节点或数据库设置继承。

  • 以 dbadmin 身份对数据库或各个节点设置配置参数 DEFAULTIDLESESSIONTIMEOUT。您可以使用配置参数 DEFAULTIDLESESSIONTIMEOUT 来限制默认数据库群集或各个节点。此参数会为所有非超级用户设置默认超时值。

所有设置都应用于持续处于空闲状态的会话，即未在运行查询的会话。如果客户端在查询执行期间很慢或没有响应，则该时间不会应用于超时。例如，流式批量插入所需的时间不会计入超时。从开始等待来自某会话的任何类型的消息那一刻起，服务器会将该会话标识为空闲。

查看会话设置

关闭用户会话

如有必要，您可以使用 CLOSE_USER_SESSIONS 手动关闭用户会话：

=> SELECT CLOSE_USER_SESSIONS ('Joe');
                             close_user_sessions
------------------------------------------------------------------------------
 Close all sessions for user Joe sent. Check v_monitor.sessions for progress.
(1 row)

用例示例

用户执行某个查询后，由于某种原因，该查询需要很长时间才能完成（例如，由于服务器流量或查询比较复杂）。在这种情况下，用户可能会认为该查询失败并打开另一个会话来运行相同查询。现在，两个会话会使用额外的连接运行相同的查询。

为了防止出现这种情况，您可以通过修改其 MAXCONNECTIONS 用户属性来限制各个用户可以运行的会话数。这样有助于最大程度地降低运行冗余查询的概率。此外，还有助于防止用户使用数据库所设置的所有可用连接。例如，针对用户 SuzyQ 的以下设置将限制该用户在任何时候运行的数据库会话不得超过两个：

=> CREATE USER SuzyQ MAXCONNECTIONS 2 ON DATABASE;

当用户多次连接到服务器时，可限制设置客户端连接所能防止出现的另一个问题。用户连接过多会耗尽数据库配置参数 MaxClientSessions 所设置的允许连接数。

群集更改和连接

当群集发生以下变化时，客户端连接限值的行为可能会发生变化：

  • 添加或移除节点。

  • 节点发生故障或恢复。

连接请求之间的节点可用性发生变化对连接限值的影响较小。

就遵守连接限值而言，当节点在连接请求之间发生故障或恢复时，不会产生重大影响。无需执行特别操作来处理此问题。但是，如果节点发生故障，其活动会话将退出且群集中的其他节点也会删除自己的会话。这将释放连接。查询可能会挂起，在这种情况下，会话被阻止合乎情理且符合预期。

2 - 排空客户端连接

仅限 Eon 模式

排空子群集中的客户端连接会将子群集中的所有节点标记为正在排空，从而为关闭子群集做好准备。来自现有用户会话的工作继续排空节点，但节点拒绝新的客户端连接，并且会从负载均衡操作中排除。如果客户端尝试连接到正在排空的节点，它们会收到指示节点处于排空状态的错误。负载均衡操作不包括正在排空的节点，因此只有在负载均衡策略中的所有节点都在排空时，选择加入连接负载均衡的客户端才会收到连接错误。您无需更改任何连接负载均衡配置即可使用此功能。dbadmin 仍然可以连接到正在排空的节点。

要在关闭子群集之前排空客户端连接，可以使用 SHUTDOWN_WITH_DRAIN 函数。此函数执行正常关闭以将子群集标记为正在排空，直到现有连接完成其工作并关闭或达到用户指定的超时时间。当满足这些条件之一时，此函数继续关闭子群集。Vertica 提供了多个可用于独立执行 SHUTDOWN_WITH_DRAIN 过程中每个步骤的元函数。您可以使用 START_DRAIN_SUBCLUSTER 函数将子群集标记为正在排空，然后在其连接关闭后使用 SHUTDOWN_SUBCLUSTER 函数关闭子群集。

您可以使用 CANCEL_DRAIN_SUBCLUSTER 函数将子群集中的所有节点标记为未在排空。一旦节点既处于 UP 状态又未在排空，该节点就会接受新的客户端连接。如果正在排空的子群集中的所有节点均已关闭，则其节点的排空状态会自动重置为未在排空。

您可以通过查询 DRAINING_STATUS 系统表来监控每个节点的排空状态以及客户端连接信息，例如每个节点上的活动用户会话数。

以下示例排空名为 analytics 的子群集，然后取消排空该子群集。

要将 analytics 子群集标记为正在排空，请使用负超时值调用 SHUTDOWN_WITH_DRAIN：

=> SELECT SHUTDOWN_WITH_DRAIN('analytics', -1);
NOTICE 0:  Draining has started on subcluster (analytics)

您可以通过查询 DRAINING_STATUS 系统表来确认子群集正在排空：

=> SELECT node_name, subcluster_name, is_draining FROM draining_status ORDER BY 1;
node_name          | subcluster_name    | is_draining
-------------------+--------------------+--------------
verticadb_node0001 | default_subcluster | f
verticadb_node0002 | default_subcluster | f
verticadb_node0003 | default_subcluster | f
verticadb_node0004 | analytics          | t
verticadb_node0005 | analytics          | t
verticadb_node0006 | analytics          | t

如果客户端尝试直接连接到正在排空的子群集中的节点，它们会收到以下错误消息：

$ /opt/vertica/bin/vsql -h noeIP --password password verticadb analyst
vsql: FATAL 10611:  New session rejected because subcluster to which this node belongs is draining connections

要取消 analytics 子群集的正常关闭，可以键入 Ctrl+C：

=> SELECT SHUTDOWN_WITH_DRAIN('analytics', -1);
NOTICE 0:  Draining has started on subcluster (analytics)
^CCancel request sent
ERROR 0:  Cancel received after draining started and before shutdown issued. Nodes will not be shut down. The subclusters are still in the draining state.
HINT:  Run cancel_drain_subcluster('') to restore all nodes to the 'not_draining' state

如上提示中所述，可以运行 CANCEL_DRAIN_SUBCLUSTER 将子群集中正在排空的节点的状态重置为未在排空：

=> SELECT CANCEL_DRAIN_SUBCLUSTER('analytics');
              CANCEL_DRAIN_SUBCLUSTER
--------------------------------------------------------
Targeted subcluster: 'analytics'
Action: CANCEL DRAIN

(1 row)

要确认子群集不再排空，可以再次查询 DRAINING_STATUS 系统表：

=> SELECT node_name, subcluster_name, is_draining FROM draining_status ORDER BY 1;
node_name          | subcluster_name    | is_draining
-------------------+--------------------+-------
verticadb_node0001 | default_subcluster | f
verticadb_node0002 | default_subcluster | f
verticadb_node0003 | default_subcluster | f
verticadb_node0004 | analytics          | f
verticadb_node0005 | analytics          | f
verticadb_node0006 | analytics          | f
(6 rows)

3 - 连接负载均衡

在 Vertica 群集中，主机的每个客户端连接都会产生一小部分的内存和处理器时间开销。如果多个客户端连接到单个主机，此开销可能会影响数据库性能。可通过指定某些客户端连接到群集中的特定主机来分配客户端连接的开销。但是，这种手动平衡会随着环境中添加新的客户端和主机而变得十分困难。

连接负载均衡可让主机将客户端连接重定向到其他主机，因此有助于在群集中自动分配客户端连接所产生的开销。通过重定向连接，客户端连接所产生的开销会在群集内进行分配，而无需手动为各个客户端分配特定主机。客户端可以连接到一小部分主机，它们会自然而然地重定向到群集中的其他主机。负载均衡不会将连接重定向到即将排空的主机。有关详细信息，请参阅排空客户端连接。

本机连接负载均衡概览

本机连接负载均衡是 Vertica Analytic Database 服务器和客户端库以及 vsql 的一项内置功能。服务器和客户端均需启用负载均衡才能正常工作。启用连接负载均衡后，数据库群集中的主机可以将尝试连接它的客户端重定向到群集中当前处于活动状态的其他主机。此重定向基于负载均衡策略，仅执行一次，因此客户端不会从一个主机跳跃到其他主机。

由于本机连接负载均衡并入到了 Vertica 客户端库中，因此，连接到 Vertica 的任何客户端应用程序只需设置连接参数即可透明地利用此项功能。

如何选择实施连接负载均衡功能取决于您的网络环境。由于本机连接负载均衡功能更易于实施，因此您应选择使用此项功能，除非您的网络配置要求通过防火墙将客户端与 Vertica 数据库中的主机分隔开。

有关本机连接负载均衡的详细信息，请参阅关于本机连接负载均衡。

3.1 - 关于本机连接负载均衡

本机连接负载均衡是内置在 Vertica 服务器和客户端库中的一种功能，它可以帮助分摊客户端连接在数据库中主机上产生的 CPU 和内存开销。它可以防止客户端连接在群集中的主机之间分布不均匀。

本机连接负载均衡有两种类型：

  • 群集范围的平衡 — 此方法是传统的连接负载均衡方法。它是 Vertica 9.2 版之前的唯一负载均衡类型。使用此方法，可以在整个群集中应用单个负载均衡策略。与群集的所有连接都以相同的方式处理。

  • 负载均衡策略 — 此方法允许您根据客户端连接源设置不同的负载均衡策略。例如，您可以制定一个策略，将本地网络外部的连接重定向到群集中的一组节点，并将本地网络内部的连接重定向到另一组节点。

3.2 - 经典连接负载均衡

经典连接负载均衡功能为与数据库的所有客户端连接应用单个策略。数据库和客户端都必须启用负载均衡选项才能对连接进行负载均衡。如果客户端和服务器都启用负载均衡，则在客户端尝试与 Vertica 建立连接时，会发生以下过程：

  1. 客户端连接数据库群集中的主机时，连接参数指示它正在请求负载均衡连接。

  2. 主机根据当前负载均衡方案，从群集中当前正在运行的主机列表中选择一个主机。在所有方案下，主机都可以选择自身。

  3. 主机告诉客户端它选择了哪个主机来处理客户端连接。

  4. 如果主机选择数据库中其他主机来处理客户端连接，客户端将断开与初始主机的连接。否则，客户端将跳到步骤 6。

  5. 客户端与将负责处理其连接的主机建立连接。客户端设置第二个连接请求，使第二个主机不会将连接解释为负载均衡请求。

  6. 客户端连接继续正常运行（如果连接已启用 SSL，则协商加密，并继续对用户进行身份验证）。

此过程对客户端应用程序是透明的。客户端驱动程序会自动断开与初始主机的连接，然后重新连接到为负载均衡选择的主机。

要求

  • 在混合 IPv4 和 IPv6 环境中，平衡仅对配置了本机连接负载均衡的地址系列起作用。例如，如果您使用 IPv4 地址配置了负载均衡，则 IPv6 客户端无法使用负载均衡，不过 IPv6 客户端仍然可以连接，只是不进行负载均衡而已。

  • 本机负载均衡器为客户端返回要使用的 IP 地址。该地址必须是客户端可以到达的地址。如果您的节点位于专用网络上，则本机负载均衡要求您通过以下两种方式之一发布公共地址：

    • 在每个节点上设置公共地址。Vertica 将该地址保存在 NODES 系统表的 export_address 字段中。

    • 在数据库上设置子网。Vertica 将该地址保存在 DATABASES 系统表的 export_subnet 字段中。

负载均衡方案

负载均衡方案控制主机如何选择哪个主机来处理客户端连接。以下是三种可用方案：

  • NONE （默认值）：禁用本机连接负载均衡。

  • ROUNDROBIN：从群集中处于启动状态的主机循环列表中选择下一个主机。例如，在包含三节点的群集中，依次迭代节点 1、节点 2 和节点 3，然后返回到节点 1。群集中的每个主机都在循环链表中维护自己的指向下一个主机的指针，而不存在一个群集范围内的状态。

  • RANDOM：从群集中所有处于启动的主机中随机选择一个主机。

您可以使用 SET_LOAD_BALANCE_POLICY 函数设置本机连接负载均衡方案。有关说明，请参阅启用和禁用本机连接负载均衡。

驱动程序注意事项

  • 本机连接负载均衡与 ADO.NET 驱动程序的连接池结合使用。客户端建立的到初始主机的连接以及到负载均衡主机的最终连接会使用池化连接（如果它们可用）。

  • 如果客户端连接将 JDBC 和 ODBC 驱动程序与第三方连接池解决方案结合使用，初始连接不会被池化，因为它不是一个完整的客户端连接。最终连接会被池化，因为它是一个标准的客户端连接。

连接故障转移

客户端库包含故障转移功能，如果连接属性中指定的主机无法到达，则通过此功能，可以连接备份主机。使用本机连接负载均衡时，故障转移功能只能用于数据库的初始连接。如果客户端重定向到的主机没有对客户端的连接请求进行响应，客户端不会尝试连接备份主机，而是向用户返回连接错误。

客户端仅重定向到已知正常运行的主机。因此，只有当目标主机在客户端被重定向到它的那一刻发生故障时，才会发生这种连接失败。有关详细信息，请参阅 ADO.NET 连接故障转移、JDBC 连接故障转移和连接故障转移。

3.2.1 - 启用和禁用经典连接负载均衡

只有数据库 超级用户才能启用或禁用群集范围的经典连接负载均衡。要启用或禁用负载均衡，请使用 SET_LOAD_BALANCE_POLICY 函数设置负载均衡策略。将负载均衡策略设置为“NONE”以外的任何其他值可在服务器中启用负载均衡。以下示例通过将负载均衡策略设置为 ROUNDROBIN 来启用本机连接负载均衡。

=> SELECT SET_LOAD_BALANCE_POLICY('ROUNDROBIN');
                  SET_LOAD_BALANCE_POLICY
--------------------------------------------------------------------------------
Successfully changed the client initiator load balancing policy to: roundrobin
(1 row)

要禁用本机连接负载均衡，请使用 SET_LOAD_BALANCE_POLICY 将此策略设置为“NONE”：

=> SELECT SET_LOAD_BALANCE_POLICY('NONE');
SET_LOAD_BALANCE_POLICY
--------------------------------------------------------------------------
Successfully changed the client initiator load balancing policy to: none
(1 row)

默认情况下，客户端连接不会进行负载均衡，即使服务器启用了连接负载均衡也是如此。客户端必须通过设置连接参数来指明其愿意对自己的连接请求进行负载均衡。 有关在客户端启用负载均衡的信息，请参阅 ADO.NET 中的负载均衡、JDBC 中的负载均衡和负载均衡。对于 vsql，使用 -C 命令行选项来启用负载均衡。

重置负载均衡状态

当负载均衡策略为 ROUNDROBIN 时，Vertica 群集中的每个主机都保持其自己的状态，即它选择哪个主机来处理下一个客户端连接。可使用 RESET_LOAD_BALANCE_POLICY 函数将此状态重置为其初始值（通常为具有最低节点 ID 的主机）：

=> SELECT RESET_LOAD_BALANCE_POLICY();
RESET_LOAD_BALANCE_POLICY
-------------------------------------------------------------------------
Successfully reset stateful client load balance policies: "roundrobin".
(1 row)

另请参阅

3.2.2 - 监控传统连接负载均衡

查询 V_CATALOG.DATABASES 的 LOAD_BALANCE_POLICY 列可确定服务器上本机连接负载均衡的状态：

=> SELECT LOAD_BALANCE_POLICY FROM V_CATALOG.DATABASES;
LOAD_BALANCE_POLICY
---------------------
roundrobin
(1 row)

确定客户端已连接到哪个节点

客户端可以通过查询 V_MONITOR.CURRENT_SESSION 表的 NODE_NAME 列来确定它已连接到哪个节点：

=> SELECT NODE_NAME FROM V_MONITOR.CURRENT_SESSION;
NODE_NAME
------------------
v_vmart_node0002
(1 row)

3.3 - 连接负载均衡策略

连接负载均衡策略基于连接的来源重定向连接，从而帮助分摊服务客户端连接的负载。这些策略还可以通过在节点之间分摊连接来帮助防止节点达到其客户端连接限制并拒绝新连接。有关客户端连接限制的详细信息，请参阅限制客户端连接的数量和长度。

负载均衡策略包括：

  • 网络地址，用于标识节点上的特定 IP 地址/端口号组合。

  • 一个或多个连接负载均衡组，由用来处理客户端连接的网络地址组成。您可以使用容错组、子群集或网络地址列表来定义负载均衡组。

  • 一个或多个路由规则，用来将一系列客户端 IP 地址映射到连接负载均衡组。

当客户端连接到启用负载均衡的数据库中的节点时，该节点会根据客户端的 IP 地址评估所有路由规则，以确定是否有任何匹配项。如果多个规则与该 IP 地址匹配，则节点应用最有针对性的规则（影响最少 IP 地址的规则）。

如果节点找到匹配规则，它会使用该规则来确定用于处理客户端连接的潜在节点池。在评估潜在目标节点时，它始终确保节点当前处于启动状态。然后，最初联系的节点根据组的分布方案选择组中的节点之一。分布方案可以是随机选择一个节点，也可以是按“循环”轮换顺序选择一个节点。例如，在一个三节点群集中，循环顺序是节点 1、节点 2、节点 3，然后再回到节点 1。

在对规则进行处理之后，如果节点确定客户端的连接应当由另一个节点处理，该节点会通知客户端它选择了哪个节点。客户端断开与初始节点的连接，并连接到所选节点以继续连接过程（在连接启用 TLS/SSL 的情况下进行协商加密，或者通过身份验证）。

如果初始节点根据路由规则选择自己，它会通知客户端继续执行连接过程的下一个步骤。

如果没有路由规则与传入 IP 地址匹配，该节点会检查 Vertica 和客户端是否均启用了经典连接负载均衡。如果是，它将根据经典负载均衡策略处理连接。有关详细信息，请参阅经典连接负载均衡。

最后，如果数据库在 Eon 模式下运行，节点会尝试应用默认的内部负载均衡规则。请参阅下面的默认子群集内部负载均衡策略。

如果没有路由规则与传入 IP 地址和经典负载均衡匹配，并且默认子群集内部负载均衡规则不适用，则节点将自行处理连接。如果节点无法遵循负载均衡规则，它也会自行处理连接。例如，如果负载均衡组中作为规则目标的所有节点都已关闭，则最初联系的节点会自行处理客户端连接。在这种情况下，节点不会尝试应用任何其他具有较少限制且适用于传入连接的负载均衡规则。它仅尝试应用单个负载均衡规则。

用例

使用负载均衡策略，可以：

  • 确保来自内部网络内外的连接被定向到客户端的有效 IP 地址。例如，假设您的 Vertica 节点有两个 IP 地址：一个用于外部网络，另一个用于内部网络。这些网络相互排斥。您无法从公共网络访问专用网络，也无法从专用网络访问公共网络。负载均衡规则需要为客户端提供它们实际可以访问的 IP 地址。


  • 允许访问 NAT 路由器后面的多个 Vertica 群集节点。NAT 路由器可通过单个 IP 地址从外部网络访问。NAT 路由器专用网络内的系统可以使用不同的端口号在这个 IP 地址上访问。您可以创建一个负载均衡策略，将客户端连接重定向到 NAT 的 IP 地址，但使用不同的端口号。


  • 指定多组节点来为源自一个 IP 地址范围的客户端连接提供服务。例如，如果为您的 ETL 系统设置了一个 IP 地址范围，您可以仅允许 ETL 系统的客户端连接到任意一组 Vertica 节点、一个子群集或一个容错组。这种技术可用于隔离服务客户端连接到几个节点所需的开销。当您在 Eon 模式数据库中使用子群集来隔离工作负载时，这种技术很有用（有关详细信息，请参阅子群集）。

针对 IPv4 和 IPv6 使用连接负载均衡策略

连接负载均衡策略适用于 IPv4 和 IPv6。就负载均衡策略而言，这两个地址系列代表不同的网络。如果您希望负载均衡策略既能够处理 IPv4 地址又能够处理 IPv6 地址，则必须为每个协议创建单独的网络地址、负载均衡组和规则集。当客户端建立与群集中某个节点的连接时，它使用的寻址协议将确定 Vertica 在决定是否以及如何平衡连接时参考哪组规则。

默认子群集内部负载均衡策略

在 Eon 模式下运行的数据库具有默认连接负载均衡策略，该策略有助于在子群集中的节点之间分摊客户端连接的处理负载。如果客户端在连接到节点的同时选择加入连接负载均衡，节点将检查有无适用于客户端 IP 地址的负载均衡策略。如果它没有找到任何适用的负载均衡规则，并且没有启用经典负载均衡，则节点将回退到默认的内部负载均衡规则。此规则在与最初联系的节点相同的子群集中的节点之间分布连接。

与其他连接负载均衡策略一样，子群集中的节点必须定义一个网络地址，以便它们有资格处理客户端连接。如果子群集中不存在具有网络地址的节点，则该节点不应用默认的子群集内部负载均衡规则，并且不会对连接进行负载均衡。

当您主要对每个子群集内的负载均衡连接感兴趣时，此默认规则很方便。您只需为子群集中的节点创建网络地址，而无需创建负载均衡组或规则。选择加入负载均衡的客户端随后会在子群集中的节点之间自动平衡。

针对多个网络地址的内部负载均衡策略

如果您的节点有多个网络地址，默认的子群集内部负载均衡规则会选择最先创建的地址作为负载均衡规则的目标。例如，假设您在一个节点上为专用 IP 地址 192.168.1.10 创建一个网络地址，然后为公共 IP 地址 233.252.0.1 的节点创建另一个网络地址。默认子群集内部连接负载均衡规则始终选择 192.168.1.10 作为规则的目标。

如果您希望默认内部负载均衡规则选择不同的网络地址作为其目标，请删除节点上的其他网络地址，然后重新创建它们。删除并重新创建其他地址会使您希望规则选择的地址成为最旧的地址。例如，假设您希望规则使用在专用地址 (192.168.1.10) 之后创建的公共地址 (233.252.0.1)。在这种情况下，您可以删除 192.168.1.10 的地址，然后重新创建它。之后，在默认情况下，该规则使用旧的公共地址 233.252.0.1。

如果您打算为子群集中的节点创建多个网络地址，请先创建要用于默认子群集内部负载均衡的网络地址。例如，假设您想使用默认子群集内部负载均衡规则来对大多数客户端连接进行负载均衡。但是，您还想创建一个连接负载均衡策略来管理源自一组 ETL 系统的连接。在这种情况下，首先创建要用于默认内部负载均衡规则的网络地址，然后为 ETL 系统创建网络地址。

负载均衡策略与经典负载均衡

经典负载均衡功能与负载均衡策略功能有以下几个区别：

  • 在经典连接负载均衡中，您只需在客户端和服务器上启用负载均衡选项，并启用负载均衡。实施负载均衡策略的步骤更多：必须创建地址、组和规则，然后在客户端上启用负载均衡。

  • 经典连接负载均衡仅支持使用群集范围的单个策略来重定向连接。使用连接负载均衡策略，可以根据连接的来源选择哪些节点处理客户端连接。这使您可以更灵活地处理复杂的情况。例如，通过基于 NAT 的路由器路由连接，或者让可通过多个 IP 地址访问的节点位于不同的网络上。

  • 在经典连接负载均衡中，群集中的每个节点只能通过一个 IP 地址访问。此地址在 NODES 系统表的 EXPORT_ADDRESS 列中设置。使用连接负载均衡策略，可以为与节点关联的每个 IP 地址创建一个网络地址。然后，创建用于重定向到这些地址的规则。

用于创建负载均衡策略的步骤

您必须遵循以下三个步骤来创建负载均衡策略：

  1. 为要参与连接负载均衡策略的每个节点创建一个或多个网络地址。

  2. 创建一个或多个负载均衡组作为路由规则的目标。负载均衡组可以将特定网络地址的集合作为目标。或者，可以从容错组或子群集创建一个组。您可以使用 IP 地址筛选器将负载均衡组的成员限制为容错组或子群集的子集。

  3. 创建一个或多个路由规则。

尽管并不绝对必需，但最好始终测试负载均衡策略以确保它按预期方式工作。

完成这些步骤后，Vertica 会将负载均衡策略应用于选择加入连接负载均衡的客户端连接。 有关在客户端启用负载均衡的信息，请参阅 ADO.NET 中的负载均衡、JDBC 中的负载均衡和负载均衡。对于 vsql，使用 -C 命令行选项来启用负载均衡。

这些步骤在此部分的其他主题中有说明。

另请参阅

3.3.1 - 创建网络地址

网络地址为节点上的 IP 地址和端口号分配名称。在定义负载均衡组时使用这些地址。一个节点可以有多个与之关联的网络地址。例如，假设一个节点有一个 IP 地址只能从本地网络外部访问，而另一个 IP 地址只能从网络内部访问。在这种情况下，您可以使用外部 IP 地址定义一个网络地址，并使用内部地址定义另一个网络地址。然后，您可以创建两个不同的负载均衡策略，一个用于外部客户端，另一个用于内部客户端。

您可以使用 CREATE NETWORK ADDRESS 语句创建网络地址。此语句采用：

  • 要分配给网络地址的名称

  • 节点的名称

  • 要与网络地址关联的节点的 IP 地址

  • 节点用于接受客户端连接的端口号（可选）

以下示例演示了如何创建三个网络地址，每个地址对应于三节点数据库中的每个节点。

=> SELECT node_name,node_address,node_address_family FROM v_catalog.nodes;
    node_name     | node_address | node_address_family
------------------+--------------+----------------------
 v_vmart_node0001 | 10.20.110.21 | ipv4
 v_vmart_node0002 | 10.20.110.22 | ipv4
 v_vmart_node0003 | 10.20.110.23 | ipv4
(4 rows)


=> CREATE NETWORK ADDRESS node01 ON v_vmart_node0001 WITH '10.20.110.21';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02 ON v_vmart_node0002 WITH '10.20.110.22';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03 on v_vmart_node0003 WITH '10.20.110.23';
CREATE NETWORK ADDRESS

为 IPv6 地址创建网络地址的方式相同：

=> CREATE NETWORK ADDRESS node1_ipv6 ON v_vmart_node0001 WITH '2001:0DB8:7D5F:7433::';
CREATE NETWORK ADDRESS

Vertica 不会对您在 CREATE NETWORK ADDRESS 语句中提供的 IP 地址执行任何测试。您必须测试您提供给此语句的 IP 地址，确认它们对应于正确的节点。

Vertica 不限制您提供的地址，因为它通常不知道可通过哪些网络地址访问节点。例如，您的节点可从外部网络，通过一个未配置 Vertica 使用的 IP 地址进行访问。或者，您的节点可能同时具有 IPv4 和 IPv6 地址，Vertica 只知道其中一个地址。

例如，假设上例中的 v_vmart_node0003 不能 通过 IP 地址 192.168.1.5 not 访问。您仍然可以使用该地址为该节点创建网络地址：

=> CREATE NETWORK ADDRESS node04 ON v_vmart_node0003 WITH '192.168.1.5';
CREATE NETWORK ADDRESS

如果您创建的网络组和路由规则以该地址为目标，客户端连接将连接到错误的节点，或者由于连接到不属于 Vertica 群集的主机而失败。

在网络地址中指定端口号

默认情况下，CREATE NETWORK ADDRESS 语句假设节点客户端连接的端口号是默认值 5433。有时，您可能有一个节点在不同的端口上侦听客户端连接。您可以使用 PORT 关键字为网络地址提供备用端口号。

例如，假设您的节点位于 NAT 路由器后面。在这种情况下，您可以让您的节点侦听不同的端口号，以便 NAT 路由器可以将连接路由到这些端口号。在为这些节点创建网络地址时，您需要提供 NAT 路由器的 IP 地址，以及节点正在侦听的端口号。例如：

=> CREATE NETWORK ADDRESS node1_nat ON v_vmart_node0001 WITH '192.168.10.10' PORT 5433;
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node2_nat ON v_vmart_node0002 with '192.168.10.10' PORT 5434;
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node3_nat ON v_vmart_node0003 with '192.168.10.10' PORT 5435;
CREATE NETWORK ADDRESS

3.3.2 - 创建连接负载均衡组

为节点创建网络地址后，您可以创建网络地址的集合，以便您可以使用路由规则将它们确定为目标。这些网络地址的集合称为负载均衡组。您可以通过两种方法选择要包括在负载均衡组中的地址：

  • 网络地址列表

  • 一个或多个容错组或子群集的名称，加上采用 CIDR 格式的 IP 地址范围。根据地址范围可以选择 Vertica 将容错组或子群集中的哪些网络地址添加到负载均衡组中。只有属于所提供的 IP 地址范围的网络地址才会添加到负载均衡组。此筛选器可用于让负载均衡组基于构成容错组或子群集的部分节点。

您可以使用 CREATE LOAD BALANCE GROUP 语句创建负载均衡组。当您的组基于地址列表时，此语句采用组名和地址列表。以下示例演示了为四个节点创建地址，然后基于这些节点创建两个组。

=> CREATE NETWORK ADDRESS addr01 ON v_vmart_node0001 WITH '10.20.110.21';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS addr02 ON v_vmart_node0002 WITH '10.20.110.22';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS addr03 on v_vmart_node0003 WITH '10.20.110.23';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS addr04 on v_vmart_node0004 WITH '10.20.110.24';
CREATE NETWORK ADDRESS
=> CREATE LOAD BALANCE GROUP group_1 WITH ADDRESS addr01, addr02;
CREATE LOAD BALANCE GROUP
=> CREATE LOAD BALANCE GROUP group_2 WITH ADDRESS addr03, addr04;
CREATE LOAD BALANCE GROUP

=> SELECT * FROM LOAD_BALANCE_GROUPS;
    name    |   policy   |     filter      |         type          | object_name
------------+------------+-----------------+-----------------------+-------------
 group_1    | ROUNDROBIN |                 | Network Address Group | addr01
 group_1    | ROUNDROBIN |                 | Network Address Group | addr02
 group_2    | ROUNDROBIN |                 | Network Address Group | addr03
 group_2    | ROUNDROBIN |                 | Network Address Group | addr04
(4 rows)

一个网络地址可以是任意多个负载均衡组的一部分。但是，每个组的每个节点只能有一个网络地址。您不能将两个属于同一节点的网络地址添加到同一负载均衡组中。

从容错组创建负载均衡组

要从一个或多个容错组创建负载均衡组，请提供：

  • 负载均衡组的名称

  • 一个或多个容错组的名称

  • CIDR 格式的 IP 地址筛选器，根据容错组的 IP 地址筛选要添加到负载均衡组的容错组。Vertica 会排除容错组中不属于此范围的任何网络地址。如果您希望将容错组中的所有节点都添加到负载均衡组中，请指定筛选器 0.0.0.0/0。

以下示例从容错组创建两个负载均衡组。第一个通过对所有 IP 地址使用 CIDR 表示法，包括容错组中的所有网络地址。第二个使用 IP 地址筛选器，将容错组限制在容错组中的三个节点（共四个）。

=> CREATE FAULT GROUP fault_1;
CREATE FAULT GROUP
=> ALTER FAULT GROUP fault_1 ADD NODE  v_vmart_node0001;
ALTER FAULT GROUP
=> ALTER FAULT GROUP fault_1 ADD NODE  v_vmart_node0002;
ALTER FAULT GROUP
=> ALTER FAULT GROUP fault_1 ADD NODE  v_vmart_node0003;
ALTER FAULT GROUP
=> ALTER FAULT GROUP fault_1 ADD NODE  v_vmart_node0004;
ALTER FAULT GROUP
=> SELECT node_name,node_address,node_address_family,export_address
   FROM v_catalog.nodes;
    node_name     | node_address | node_address_family | export_address
------------------+--------------+---------------------+----------------
 v_vmart_node0001 | 10.20.110.21 | ipv4                | 10.20.110.21
 v_vmart_node0002 | 10.20.110.22 | ipv4                | 10.20.110.22
 v_vmart_node0003 | 10.20.110.23 | ipv4                | 10.20.110.23
 v_vmart_node0004 | 10.20.110.24 | ipv4                | 10.20.110.24
(4 rows)

=> CREATE LOAD BALANCE GROUP group_all WITH FAULT GROUP fault_1 FILTER
   '0.0.0.0/0';
CREATE LOAD BALANCE GROUP

=> CREATE LOAD BALANCE GROUP group_some WITH FAULT GROUP fault_1 FILTER
   '10.20.110.21/30';
CREATE LOAD BALANCE GROUP

=> SELECT * FROM LOAD_BALANCE_GROUPS;
      name      |   policy   |     filter      |         type          | object_name
----------------+------------+-----------------+-----------------------+-------------
 group_all      | ROUNDROBIN | 0.0.0.0/0       | Fault Group           | fault_1
 group_some     | ROUNDROBIN | 10.20.110.21/30 | Fault Group           | fault_1
(2 rows)

您还可以为 CREATE LOAD BALANCE GROUP 语句提供多个容错组：

=> CREATE LOAD BALANCE GROUP group_2_faults WITH FAULT GROUP
   fault_2, fault_3 FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP

从子群集创建负载均衡组

从子群集创建负载均衡组类似于从容错组创建负载均衡组。只需在 CREATE LOAD BALANCE GROUP 语句中使用 WITH SUBCLUSTER 而不是 WITH FAULT GROUP 即可。

=> SELECT node_name,node_address,node_address_family,subcluster_name
   FROM v_catalog.nodes;
      node_name       | node_address | node_address_family |  subcluster_name
----------------------+--------------+---------------------+--------------------
 v_verticadb_node0001 | 10.11.12.10  | ipv4                | load_subcluster
 v_verticadb_node0002 | 10.11.12.20  | ipv4                | load_subcluster
 v_verticadb_node0003 | 10.11.12.30  | ipv4                | load_subcluster
 v_verticadb_node0004 | 10.11.12.40  | ipv4                | analytics_subcluster
 v_verticadb_node0005 | 10.11.12.50  | ipv4                | analytics_subcluster
 v_verticadb_node0006 | 10.11.12.60  | ipv4                | analytics_subcluster
(6 rows)

=> CREATE NETWORK ADDRESS node01 ON v_verticadb_node0001 WITH '10.11.12.10';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02 ON v_verticadb_node0002 WITH '10.11.12.20';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03 ON v_verticadb_node0003 WITH '10.11.12.30';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node04 ON v_verticadb_node0004 WITH '10.11.12.40';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node05 ON v_verticadb_node0005 WITH '10.11.12.50';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node06 ON v_verticadb_node0006 WITH '10.11.12.60';
CREATE NETWORK ADDRESS

=> CREATE LOAD BALANCE GROUP load_subcluster WITH SUBCLUSTER load_subcluster
   FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP
=> CREATE LOAD BALANCE GROUP analytics_subcluster WITH SUBCLUSTER
   analytics_subcluster FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP

设置组的分布策略

负载均衡组有一个策略设置确定最初联系的节点如何从组中选择目标。CREATE LOAD BALANCE GROUP 支持以下三种策略：

  • ROUNDROBIN（默认值）将在负载均衡组的可用成员之间轮转。最初联系的节点会跟踪它上次选择的节点，并选择群集中的下一个节点。

  • RANDOM 从组中随机选择一个可用节点。

  • NONE 禁用负载均衡。

以下示例演示了如何使用 RANDOM 分布策略创建负载均衡组。

=> CREATE LOAD BALANCE GROUP group_random WITH ADDRESS node01, node02,
   node03, node04 POLICY 'RANDOM';
CREATE LOAD BALANCE GROUP

下一步

在创建负载均衡组后，必须添加负载均衡路由规则，该规则通知 Vertica 如何将传入的连接重定向到组。请参阅创建负载均衡路由规则。

3.3.3 - 创建负载均衡路由规则

创建一个或多个连接负载均衡组后，便可以创建负载均衡路由规则了。这些规则通知 Vertica 如何根据 IP 地址重定向客户端连接。

您可以使用 CREATE ROUTING RULE 语句创建路由规则。向此语句传递以下内容：

  • 规则的名称

  • 规则适用的 CIDR 格式的源 IP 地址范围（IPv4 或 IPv6）

  • 用来处理连接的负载均衡组的名称

以下示例创建两个规则。第一个将来自 IP 地址范围 192.168.1.0 到 192.168.1.255 的连接重定向到名为 group_1 的负载均衡组。第二个将来自 IP 范围 10.20.1.0 到 10.20.1.255 的连接路由到名为 group_2 的负载均衡组。

=> CREATE ROUTING RULE internal_clients ROUTE '192.168.1.0/24' TO group_1;
CREATE ROUTING RULE

=> CREATE ROUTING RULE external_clients ROUTE '10.20.1.0/24' TO group_2;
CREATE ROUTING RULE

创建全方位路由规则

Vertica 按照从最具针对性到最不具针对性的顺序应用路由规则。此行为可用于创建用来处理所有传入连接的“全方位”规则。然后，您可以针对特定用途创建规则来处理较小的 IP 地址范围。例如，假设您想创建一个全方位的规则与上例中创建的规则结合使用。然后，您可以创建一个新规则，将 0.0.0.0/0（所有 IP 地址的 CIDR 表示法）路由到一个组，该组应处理未由先前创建的任一规则处理的连接。例如：

=> CREATE LOAD BALANCE GROUP group_all WITH ADDRESS node01, node02, node03, node04;
CREATE LOAD BALANCE GROUP

=> CREATE ROUTING RULE catch_all ROUTE '0.0.0.0/0' TO group_all;
CREATE ROUTING RULE

在运行上述语句后，任何不是源自 IP 地址范围 192.168.1.* 或 10.20.1.* 的连接都会路由到 group_all 组。

3.3.4 - 测试连接负载均衡策略

创建路由规则后，您应当测试它们以验证它们是否按预期方式执行。测试规则的最佳方法是使用 IP 地址调用 DESCRIBE_LOAD_BALANCE_DECISION 函数。此函数评估路由规则并报告 Vertica 如何从 IP 地址路由客户端连接。它使用的逻辑与 Vertica 用来处理客户端连接的逻辑相同，因此结果反映了您将从客户端连接中看到的实际连接负载均衡结果。它还反映了 Vertica 群集的当前状态，因此它不会将连接重定向到已关闭的节点。

以下示例演示了如何测试一组规则。一条规则处理从 192.168.1.0 到 192.168.1.255 范围内的所有连接，而另一条规则处理源自 192 子网的所有连接。第三个调用演示了当没有规则适用于您提供的 IP 地址时会发生什么。

=> SELECT describe_load_balance_decision('192.168.1.25');
                        describe_load_balance_decision
--------------------------------------------------------------------------------
 Describing load balance decision for address [192.168.1.25]
Load balance cache internal version id (node-local): [2]
Considered rule [etl_rule] source ip filter [10.20.100.0/24]... input address
does not match source ip filter for this rule.
Considered rule [internal_clients] source ip filter [192.168.1.0/24]... input
address matches this rule
Matched to load balance group [group_1] the group has policy [ROUNDROBIN]
number of addresses [2]
(0) LB Address: [10.20.100.247]:5433
(1) LB Address: [10.20.100.248]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [10.20.100.248] port [5433]

(1 row)

=> SELECT describe_load_balance_decision('192.168.2.25');
                        describe_load_balance_decision
--------------------------------------------------------------------------------
 Describing load balance decision for address [192.168.2.25]
Load balance cache internal version id (node-local): [2]
Considered rule [etl_rule] source ip filter [10.20.100.0/24]... input address
does not match source ip filter for this rule.
Considered rule [internal_clients] source ip filter [192.168.1.0/24]... input
address does not match source ip filter for this rule.
Considered rule [subnet_192] source ip filter [192.0.0.0/8]... input address
matches this rule
Matched to load balance group [group_all] the group has policy [ROUNDROBIN]
number of addresses [3]
(0) LB Address: [10.20.100.247]:5433
(1) LB Address: [10.20.100.248]:5433
(2) LB Address: [10.20.100.249]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [10.20.100.248] port [5433]

(1 row)

=> SELECT describe_load_balance_decision('1.2.3.4');
                         describe_load_balance_decision
--------------------------------------------------------------------------------
 Describing load balance decision for address [1.2.3.4]
Load balance cache internal version id (node-local): [2]
Considered rule [etl_rule] source ip filter [10.20.100.0/24]... input address
does not match source ip filter for this rule.
Considered rule [internal_clients] source ip filter [192.168.1.0/24]... input
address does not match source ip filter for this rule.
Considered rule [subnet_192] source ip filter [192.0.0.0/8]... input address
does not match source ip filter for this rule.
Routing table decision: No matching routing rules: input address does not match
any routing rule source filters. Details: [Tried some rules but no matching]
No rules matched. Falling back to classic load balancing.
Classic load balance decision: Classic load balancing considered, but either
the policy was NONE or no target was available. Details: [NONE or invalid]

(1 row)

DESCRIBE_LOAD_BALANCE_DECISION 函数还考虑了群集范围的经典负载均衡设置：

=>  SELECT SET_LOAD_BALANCE_POLICY('ROUNDROBIN');
                            SET_LOAD_BALANCE_POLICY
--------------------------------------------------------------------------------
 Successfully changed the client initiator load balancing policy to: roundrobin
(1 row)

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('1.2.3.4');
                            describe_load_balance_decision
--------------------------------------------------------------------------------
 Describing load balance decision for address [1.2.3.4]
Load balance cache internal version id (node-local): [2]
Considered rule [etl_rule] source ip filter [10.20.100.0/24]... input address
does not match source ip filter for this rule.
Considered rule [internal_clients] source ip filter [192.168.1.0/24]... input
address does not match source ip filter for this rule.
Considered rule [subnet_192] source ip filter [192.0.0.0/8]... input address
does not match source ip filter for this rule.
Routing table decision: No matching routing rules: input address does not
match any routing rule source filters. Details: [Tried some rules but no matching]
No rules matched. Falling back to classic load balancing.
Classic load balance decision: Success. Load balance redirect to: [10.20.100.247]
port [5433]

(1 row)

此函数还可以帮助您调试在使用负载均衡策略后发现的连接问题。例如，如果您注意到一个节点正在处理大量客户端连接，您可以对照您的策略测试客户端 IP 地址，以了解连接不平衡的原因。

3.3.5 - 负载均衡策略示例

以下示例演示了连接负载均衡策略的一些常见用例。

启用来自多个网络的客户端连接

假设您有一个可从两个（或更多）不同网络访问的 Vertica 群集。下面是这种情形的一些示例：

  • 您有一个内部网络和一个外部网络。在这种配置中，您的数据库节点通常有两个或多个 IP 地址，每个地址只能从其中一个网络访问。在云环境中运行 Vertica 时，此配置很常见。在许多情况下，您可以创建适用于所有 IP 地址的全方位规则，然后为内部子网添加其他路由规则。

  • 无论客户端使用 IPv4 还是 IPv6 协议，您都希望客户端进行负载均衡。从数据库的角度来看，IPv4 和 IPv6 连接是不同的网络，因为每个节点都有单独的 IPv4 和 IPv6 IP 地址。

在为可从多个网络访问的数据库创建负载均衡策略时，必须将客户端连接定向到网络上可供它们访问的 IP 地址。最好的解决方案是为分配给节点的每组 IP 地址创建负载均衡组。然后创建路由规则，将客户端连接重定向到可从其所在的网络访问的 IP 地址。

下面的例子：

  1. 创建两组网络地址：一组用于内部网络，另一组用于外部网络。

  2. 创建两个负载均衡组：一个用于内部网络，一个用于外部网络。

  3. 创建三个路由规则：一个用于内部网络，两个用于外部网络。内部路由规则涵盖其中一个外部规则涵盖的一部分网络。

  4. 使用内部和外部 IP 地址测试路由规则。

=> CREATE NETWORK ADDRESS node01_int ON v_vmart_node0001 WITH '192.168.0.1';
CREATE NETWORK ADDRESS

=> CREATE NETWORK ADDRESS node01_ext ON v_vmart_node0001 WITH '203.0.113.1';
CREATE NETWORK ADDRESS

=> CREATE NETWORK ADDRESS node02_int ON v_vmart_node0002 WITH '192.168.0.2';
CREATE NETWORK ADDRESS

=> CREATE NETWORK ADDRESS node02_ext ON v_vmart_node0002 WITH '203.0.113.2';
CREATE NETWORK ADDRESS

=> CREATE NETWORK ADDRESS node03_int ON v_vmart_node0003 WITH '192.168.0.3';
CREATE NETWORK ADDRESS

=> CREATE NETWORK ADDRESS node03_ext ON v_vmart_node0003 WITH '203.0.113.3';
CREATE NETWORK ADDRESS

=> CREATE LOAD BALANCE GROUP internal_group WITH ADDRESS node01_int, node02_int, node03_int;
CREATE LOAD BALANCE GROUP

=> CREATE LOAD BALANCE GROUP external_group WITH ADDRESS node01_ext, node02_ext, node03_ext;
CREATE LOAD BALANCE GROUP

=> CREATE ROUTING RULE internal_rule ROUTE '192.168.0.0/24' TO internal_group;
CREATE ROUTING RULE

=> CREATE ROUTING RULE external_rule ROUTE '0.0.0.0/0' TO external_group;
CREATE ROUTING RULE

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('198.51.100.10');
                         DESCRIBE_LOAD_BALANCE_DECISION
-------------------------------------------------------------------------------
 Describing load balance decision for address [198.51.100.10]
Load balance cache internal version id (node-local): [3]
Considered rule [internal_rule] source ip filter [192.168.0.0/24]... input
address does not match source ip filter for this rule.
Considered rule [external_rule] source ip filter [0.0.0.0/0]... input
address matches this rule
Matched to load balance group [external_group] the group has policy [ROUNDROBIN]
number of addresses [3]
(0) LB Address: [203.0.113.1]:5433
(1) LB Address: [203.0.113.2]:5433
(2) LB Address: [203.0.113.3]:5433
Chose address at position [2]
Routing table decision: Success. Load balance redirect to: [203.0.113.3] port [5433]

(1 row)

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('198.51.100.10');

                         DESCRIBE_LOAD_BALANCE_DECISION
-------------------------------------------------------------------------------
 Describing load balance decision for address [192.168.0.79]
Load balance cache internal version id (node-local): [3]
Considered rule [internal_rule] source ip filter [192.168.0.0/24]... input
address matches this rule
Matched to load balance group [internal_group] the group has policy [ROUNDROBIN]
number of addresses [3]
(0) LB Address: [192.168.0.1]:5433
(1) LB Address: [192.168.0.3]:5433
(2) LB Address: [192.168.0.2]:5433
Chose address at position [2]
Routing table decision: Success. Load balance redirect to: [192.168.0.2] port
[5433]

(1 row)

隔离工作负载

您可能希望控制特定类型的客户端使用群集中的哪些节点。例如，您可能希望将执行数据加载任务的客户端限制为一组节点，并保留其余节点来运行查询。以这种方式分离工作负载对于 Eon 模式数据库尤为常见。有关在 Eon 模式数据库中使用负载均衡策略来控制客户端连接到哪个子群集的示例，请参阅控制查询的运行位置。

如果执行某些任务类型的客户端始终源自有限的 IP 地址范围，您可以创建支持工作负载隔离的客户端负载均衡策略。例如，如果用来将数据加载到系统中的客户端始终属于特定子网，则可以创建一个策略来限制这些客户端可以访问哪些节点。

在以下示例中：

  • 通过两个容错组（group_a 和 group_b）来分离 Eon 模式数据库中的工作负载。这些组用作负载均衡组的基础。

  • ETL 客户端连接全部源自 203.0.113.0/24 子网。

  • 用户连接源自 192.0.0.0 到 199.255.255.255 的范围。

=> CREATE NETWORK ADDRESS node01 ON v_vmart_node0001 WITH '192.0.2.1';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02 ON v_vmart_node0002 WITH '192.0.2.2';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03 ON v_vmart_node0003 WITH '192.0.2.3';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node04 ON v_vmart_node0004 WITH '192.0.2.4';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node05 ON v_vmart_node0005 WITH '192.0.2.5';
CREATE NETWORK ADDRESS
                                                     ^
=> CREATE LOAD BALANCE GROUP lb_users WITH FAULT GROUP group_a FILTER '192.0.2.0/24';
CREATE LOAD BALANCE GROUP
=> CREATE LOAD BALANCE GROUP lb_etl WITH FAULT GROUP group_b FILTER '192.0.2.0/24';
CREATE LOAD BALANCE GROUP
=> CREATE ROUTING RULE users_rule ROUTE '192.0.0.0/5' TO lb_users;
CREATE ROUTING RULE
=> CREATE ROUTING RULE etl_rule ROUTE '203.0.113.0/24' TO lb_etl;
CREATE ROUTING RULE

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('198.51.200.129');
                          DESCRIBE_LOAD_BALANCE_DECISION
-------------------------------------------------------------------------------
 Describing load balance decision for address [198.51.200.129]
Load balance cache internal version id (node-local): [6]
Considered rule [etl_rule] source ip filter [203.0.113.0/24]... input address
does not match source ip filter for this rule.
Considered rule [users_rule] source ip filter [192.0.0.0/5]... input address
matches this rule
Matched to load balance group [lb_users] the group has policy [ROUNDROBIN]
number of addresses [3]
(0) LB Address: [192.0.2.1]:5433
(1) LB Address: [192.0.2.2]:5433
(2) LB Address: [192.0.2.3]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [192.0.2.2] port
[5433]

(1 row)

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('203.0.113.24');
                             DESCRIBE_LOAD_BALANCE_DECISION
-------------------------------------------------------------------------------
 Describing load balance decision for address [203.0.113.24]
Load balance cache internal version id (node-local): [6]
Considered rule [etl_rule] source ip filter [203.0.113.0/24]... input address
matches this rule
Matched to load balance group [lb_etl] the group has policy [ROUNDROBIN] number
of addresses [2]
(0) LB Address: [192.0.2.4]:5433
(1) LB Address: [192.0.2.5]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [192.0.2.5] port
[5433]

(1 row)

=> SELECT DESCRIBE_LOAD_BALANCE_DECISION('10.20.100.25');
                           DESCRIBE_LOAD_BALANCE_DECISION
-------------------------------------------------------------------------------
 Describing load balance decision for address [10.20.100.25]
Load balance cache internal version id (node-local): [6]
Considered rule [etl_rule] source ip filter [203.0.113.0/24]... input address
does not match source ip filter for this rule.
Considered rule [users_rule] source ip filter [192.0.0.0/5]... input address
does not match source ip filter for this rule.
Routing table decision: No matching routing rules: input address does not match
any routing rule source filters. Details: [Tried some rules but no matching]
No rules matched. Falling back to classic load balancing.
Classic load balance decision: Classic load balancing considered, but either the
policy was NONE or no target was available. Details: [NONE or invalid]

(1 row)

启用默认子群集内部负载均衡策略

如果没有其他负载均衡策略适用于传入连接并且未启用经典负载均衡，Vertica 会尝试应用默认的子群集内部负载均衡策略。有关此规则的说明，请参阅默认子群集内部负载均衡策略。

要启用默认子群集内部负载均衡，必须为子群集中的节点创建网络地址。创建地址后，Vertica 会在没有其他规则适用时尝试应用此规则来对子群集内的连接进行负载均衡。

以下示例确认数据库没有负载均衡组或规则。然后它将可公开访问的网络地址添加到主子群集中的节点。添加这些地址后，Vertica 应用默认的子群集内部负载均衡策略。

=> SELECT * FROM LOAD_BALANCE_GROUPS;
 name | policy | filter | type | object_name
------+--------+--------+------+-------------
(0 rows)

=> SELECT * FROM ROUTING_RULES;
 name | source_address | destination_name
------+----------------+------------------
(0 rows)

=> CREATE NETWORK ADDRESS node01_ext ON v_verticadb_node0001 WITH '203.0.113.1';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02_ext ON v_verticadb_node0002 WITH '203.0.113.2';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03_ext ON v_verticadb_node0003 WITH '203.0.113.3';
CREATE NETWORK ADDRESS

=> SELECT describe_load_balance_decision('11.0.0.100');
                                describe_load_balance_decision
-----------------------------------------------------------------------------------------------
Describing load balance decision for address [11.0.0.100] on subcluster [default_subcluster]
Load balance cache internal version id (node-local): [2]
Considered rule [auto_rr_default_subcluster] subcluster interior filter  [default_subcluster]...
current subcluster matches this rule
Matched to load balance group [auto_lbg_sc_default_subcluster] the group has policy
[ROUNDROBIN] number of addresses [3]
(0) LB Address: [203.0.113.1]:5433
(1) LB Address: [203.0.113.2]:5433
(2) LB Address: [203.0.113.3]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [203.0.113.2] port [5433]

(1 row)

对 IPv4 和 IPv6 连接进行负载均衡

连接负载均衡策略将 IPv4 和 IPv6 连接视为不同的网络。要对两种类型的传入客户端连接进行负载均衡，请创建两组网络地址、至少两个负载均衡组和两个负载均衡，对于每个网络地址系列各创建一次。

以下示例为默认子群集创建两个负载均衡策略：一个用于 IPv4 网络地址（192.168.111.31 到 192.168.111.33），另一个用于 IPv6 网络地址（fd9b:1fcc:1dc4:78d3::31 到 fd9b:1fcc:1dc4:78d3::33）。

=> SELECT node_name,node_address,subcluster_name FROM NODES;
      node_name       |  node_address  |  subcluster_name
----------------------+----------------+--------------------
 v_verticadb_node0001 | 192.168.111.31 | default_subcluster
 v_verticadb_node0002 | 192.168.111.32 | default_subcluster
 v_verticadb_node0003 | 192.168.111.33 | default_subcluster

=> CREATE NETWORK ADDRESS node01 ON v_verticadb_node0001 WITH
   '192.168.111.31';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node01_ipv6 ON v_verticadb_node0001 WITH
   'fd9b:1fcc:1dc4:78d3::31';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02 ON v_verticadb_node0002 WITH
   '192.168.111.32';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02_ipv6 ON v_verticadb_node0002 WITH
   'fd9b:1fcc:1dc4:78d3::32';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03 ON v_verticadb_node0003 WITH
   '192.168.111.33';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03_ipv6 ON v_verticadb_node0003 WITH
   'fd9b:1fcc:1dc4:78d3::33';
CREATE NETWORK ADDRESS

=> CREATE LOAD BALANCE GROUP group_ipv4 WITH SUBCLUSTER default_subcluster
   FILTER '192.168.111.0/24';
CREATE LOAD BALANCE GROUP
=> CREATE LOAD BALANCE GROUP group_ipv6 WITH SUBCLUSTER default_subcluster
   FILTER 'fd9b:1fcc:1dc4:78d3::0/64';
CREATE LOAD BALANCE GROUP

=> CREATE ROUTING RULE all_ipv4 route '0.0.0.0/0' TO group_ipv4;
CREATE ROUTING RULE
=> CREATE ROUTING RULE all_ipv6 route '0::0/0' TO group_ipv6;
CREATE ROUTING RULE

=> SELECT describe_load_balance_decision('203.0.113.50');
                                                                                                                                                                                                                                                                                   describe_load_balance_decision
-----------------------------------------------------------------------------------------------
Describing load balance decision for address [203.0.113.50] on subcluster [default_subcluster]
Load balance cache internal version id (node-local): [3]
Considered rule [all_ipv4] source ip filter [0.0.0.0/0]... input address matches this rule
Matched to load balance group [ group_ipv4] the group has policy [ROUNDROBIN] number of addresses [3]
(0) LB Address: [192.168.111.31]:5433
(1) LB Address: [192.168.111.32]:5433
(2) LB Address: [192.168.111.33]:5433
Chose address at position [2]
Routing table decision: Success. Load balance redirect to: [192.168.111.33] port [5433]

(1 row)

=> SELECT describe_load_balance_decision('2001:0DB8:EA04:8F2C::1');
                                                                                                                                                                                                                                                                                                                                                                    describe_load_balance_decision
---------------------------------------------------------------------------------------------------------
Describing load balance decision for address [2001:0DB8:EA04:8F2C::1] on subcluster [default_subcluster]
Load balance cache internal version id (node-local): [3]
Considered rule [all_ipv4] source ip filter [0.0.0.0/0]... input address does not match source ip filter for this rule.
Considered rule [all_ipv6] source ip filter [0::0/0]... input address matches this rule
Matched to load balance group [ group_ipv6] the group has policy [ROUNDROBIN] number of addresses [3]
(0) LB Address: [fd9b:1fcc:1dc4:78d3::31]:5433
(1) LB Address: [fd9b:1fcc:1dc4:78d3::32]:5433
(2) LB Address: [fd9b:1fcc:1dc4:78d3::33]:5433
Chose address at position [2]
Routing table decision: Success. Load balance redirect to: [fd9b:1fcc:1dc4:78d3::33] port [5433]

(1 row)

其他示例

有关使用连接负载均衡的其他示例，请参阅以下主题：

3.3.6 - 查看负载均衡策略配置

查询 V_CATALOG 架构中的以下系统表以查看数据库中定义的负载均衡策略：

  • NETWORK_ADDRESSES 列出数据库中定义的所有网络地址。

  • LOAD_BALANCE_GROUPS 列出负载均衡组的内容。

  • ROUTING_RULES 列出数据库中定义的所有路由规则。

此示例演示了如何查询每个负载均衡策略系统表。

=> \x
Expanded display is on.
=> SELECT * FROM V_CATALOG.NETWORK_ADDRESSES;
-[ RECORD 1 ]----+-----------------
name             | node01
node             | v_vmart_node0001
address          | 10.20.100.247
port             | 5433
address_family   | ipv4
is_enabled       | t
is_auto_detected | f
-[ RECORD 2 ]----+-----------------
name             | node02
node             | v_vmart_node0002
address          | 10.20.100.248
port             | 5433
address_family   | ipv4
is_enabled       | t
is_auto_detected | f
-[ RECORD 3 ]----+-----------------
name             | node03
node             | v_vmart_node0003
address          | 10.20.100.249
port             | 5433
address_family   | ipv4
is_enabled       | t
is_auto_detected | f
-[ RECORD 4 ]----+-----------------
name             | alt_node1
node             | v_vmart_node0001
address          | 192.168.1.200
port             | 8080
address_family   | ipv4
is_enabled       | t
is_auto_detected | f
-[ RECORD 5 ]----+-----------------
name             | test_addr
node             | v_vmart_node0001
address          | 192.168.1.100
port             | 4000
address_family   | ipv4
is_enabled       | t
is_auto_detected | f

=> SELECT * FROM LOAD_BALANCE_GROUPS;
-[ RECORD 1 ]----------------------
name        | group_all
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node01
-[ RECORD 2 ]----------------------
name        | group_all
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node02
-[ RECORD 3 ]----------------------
name        | group_all
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node03
-[ RECORD 4 ]----------------------
name        | group_1
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node01
-[ RECORD 5 ]----------------------
name        | group_1
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node02
-[ RECORD 6 ]----------------------
name        | group_2
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node01
-[ RECORD 7 ]----------------------
name        | group_2
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node02
-[ RECORD 8 ]----------------------
name        | group_2
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node03
-[ RECORD 9 ]----------------------
name        | etl_group
policy      | ROUNDROBIN
filter      |
type        | Network Address Group
object_name | node01

=> SELECT * FROM ROUTING_RULES;
-[ RECORD 1 ]----+-----------------
name             | internal_clients
source_address   | 192.168.1.0/24
destination_name | group_1
-[ RECORD 2 ]----+-----------------
name             | etl_rule
source_address   | 10.20.100.0/24
destination_name | etl_group
-[ RECORD 3 ]----+-----------------
name             | subnet_192
source_address   | 192.0.0.0/8
destination_name | group_all

3.3.7 - 维护负载均衡策略

创建负载均衡策略后，您可以使用以下语句对其进行维护：

  • ALTER NETWORK ADDRESS 允许您重命名和更改 IP 地址以及启用或禁用网络地址。

  • ALTER LOAD BALANCE GROUP 允许您重命名、添加或移除网络地址或容错组；更改容错组 IP 地址筛选；更改负载均衡组的策略。

  • ALTER ROUTING RULE 允许您重命名和更改源 IP 地址以及规则的目标负载均衡组。

有关示例，请参阅这些语句的参考页面。

删除负载均衡策略对象

您还可以使用以下语句删除现有的负载均衡策略对象：