From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E39CF1FF13F for ; Thu, 09 Apr 2026 13:42:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3F5E2D6F; Thu, 9 Apr 2026 13:42:49 +0200 (CEST) From: Daniel Kral To: pve-devel@lists.proxmox.com Subject: [PATCH docs 08/18] ha-manager: crs: improve introduction Date: Thu, 9 Apr 2026 13:41:34 +0200 Message-ID: <20260409114224.323102-9-d.kral@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260409114224.323102-1-d.kral@proxmox.com> References: <20260409114224.323102-1-d.kral@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775734879857 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.082 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: WZ5TGLA43WIHD6PO6ZP4GOJZ2GSKKL6N X-Message-ID-Hash: WZ5TGLA43WIHD6PO6ZP4GOJZ2GSKKL6N X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Add some lighter introductory paragraphs, which introduce the responsibilities of the CRS and a general overview of how it operates. The previous introductory CRS section focuses on only a handful of scenarios where the CRS takes some action, but there are many more scenarios, which are already listed in the "CRS Scheduling Points" section below, so link to the section directly. Furthermore, the CRS mode paragraph does focus only on the detail that the mode changes which usage information the HA Manager will work with, but not how the CRS operates itself. Signed-off-by: Daniel Kral --- ha-manager.adoc | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/ha-manager.adoc b/ha-manager.adoc index 07f6958..7c7b1d5 100644 --- a/ha-manager.adoc +++ b/ha-manager.adoc @@ -1412,19 +1412,25 @@ cluster is in a healthy state before re-arming. Cluster Resource Scheduling --------------------------- -The cluster resource scheduler (CRS) mode controls how HA selects nodes for the -recovery of a service as well as for migrations that are triggered by a -shutdown policy. The default mode is `basic`, you can change it in the Web UI -(`Datacenter` -> `Options`). +The Cluster Resource Scheduler (CRS) is responsible for selecting new node +placements for HA resources and keeping HA resources on their allowed nodes. + +In every HA Manager round, the scheduler goes through every HA resource and +checks whether the HA resource needs any new node placement. This new node +placement can be caused by different actions, such as recovering HA resources +from a fenced node or a new HA affinity rule. See the section +xref:ha_manager_crs_scheduling_points[CRS Scheduling Points] for a more +thorough description, which actions the CRS takes for specific changes in the +cluster. [thumbnail="screenshot/gui-datacenter-options-crs.png"] -The change will be in effect starting with the next manager round (after a few -seconds). - -For each HA resource that needs to be recovered or migrated, the scheduler -iteratively chooses the best node among the nodes that are available to -the HA resource according to their HA rules, if any. +The CRS scheduling mode controls how the CRS will calculate the usage +information for the cluster. This usage information is used as a basis for the +scheduling decisions. The CRS mode can be changed in the web interface +(`Datacenter` -> `Options` -> `Cluster Resource Scheduling`). The default mode +is `basic`. The change will take effect starting with the next HA Manager +round, which should take no longer than 10 seconds. NOTE: There are plans to add modes for (static and dynamic) load-balancing in the future. @@ -1455,18 +1461,12 @@ committed node) are considered. IMPORTANT: The more HA resources the more possible combinations there are, so it's currently not recommended to use it if you have thousands of HA resources. - +[[ha_manager_crs_scheduling_points]] CRS Scheduling Points ~~~~~~~~~~~~~~~~~~~~~ -The CRS algorithm is not applied for every HA resource in every round, since -this would mean a large number of constant migrations. Depending on the -workload, this could put more strain on the cluster than could be avoided by -constant balancing. -That's why the {pve} HA manager favors keeping HA resources on their current -node. - -The CRS is currently used at the following scheduling points: +In every HA Manager round, the CRS checks whether any HA resources need a new +node placement, which can be caused by any of the following scheduling points: - HA resource recovery (always active). When a node with active HA resources fails, all its HA resources need to be recovered to other nodes. The CRS -- 2.47.3