feature(Pools): Add affinity/anti-affinity support by pools

Fixes: #343
This commit is contained in:
gyptazy
2025-10-23 14:33:00 +02:00
committed by Florian Paul Azim Hoberg
parent 8a193b9891
commit 016378e37c
10 changed files with 287 additions and 29 deletions

View File

@@ -0,0 +1,2 @@
added:
- Add affinity/anti-affinity support by pools (@gyptazy). [#343]

View File

@@ -285,7 +285,8 @@ The following options can be set in the configuration file `proxlb.yaml`:
| | memory_threshold | | 75 | `Int` | The maximum threshold (in percent) that needs to be hit to perform balancing actions. (Optional) |
| | method | | memory | `Str` | The balancing method that should be used. [values: `memory` (default), `cpu`, `disk`]|
| | mode | | used | `Str` | The balancing mode that should be used. [values: `used` (default), `assigned`, `psi` (pressure)] |
| | psi | | { nodes: { memory: { pressure_full: 0.20, pressure_some: 0.20, pressure_spikes: 1.00 } } } | `Dict` | A dict of PSI based thresholds for nodes and guests |
| | psi | | { nodes: { memory: { pressure_full: 0.20, pressure_some: 0.20, pressure_spikes: 1.00 }}} | `Dict` | A dict of PSI based thresholds for nodes and guests |
| | pools | | pools: { dev: { type: affinity }, de-nbg01-db: { type: anti-affinity }} | `Dict` | A dict of pool names and their type for creating affinity/anti-affinity rules |
| `service` | | | | | |
| | daemon | | True | `Bool` | If daemon mode should be activated. |
| | `schedule` | | | `Dict` | Schedule config block for rebalancing. |
@@ -360,6 +361,14 @@ balancing:
# pressure_full: 0.20
# pressure_some: 0.20
# pressure_spikes: 1.00
pools:
dev:
type: affinity
de-nbg01-db
type: anti-affinity
pin:
- virt66
- virt77
service:
daemon: True
@@ -390,19 +399,33 @@ ProxLB provides an advanced mechanism to define affinity and anti-affinity rules
ProxLB implements affinity and anti-affinity rules through a tag-based system within the Proxmox web interface. Each guest (virtual machine or container) can be assigned specific tags, which then dictate its placement behavior. This method maintains a streamlined and secure approach to managing VM relationships while preserving Proxmoxs inherent permission model.
### Affinity Rules
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-affinity-rules.jpg"/> Affinity rules are used to group certain VMs together, ensuring that they run on the same host whenever possible. This can be beneficial for workloads requiring low-latency communication, such as clustered databases or application servers that frequently exchange data.
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-affinity-rules.jpg"/> Affinity rules are used to group certain VMs together, ensuring that they run on the same host whenever possible. This can be beneficial for workloads requiring low-latency communication, such as clustered databases or application servers that frequently exchange data. In general, there're two ways to manage affinity rules:
#### Affinity Rules by Tags
To define an affinity rule which keeps all guests assigned to this tag together on a node, users assign a tag with the prefix `plb_affinity_$TAG`:
#### Example for Screenshot
```
plb_affinity_talos
```
As a result, ProxLB will attempt to place all VMs with the `plb_affinity_web` tag on the same host (see also the attached screenshot with the same node).
### Anti-Affinity Rules
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-anti-affinity-rules.jpg"/> Conversely, anti-affinity rules ensure that designated VMs do not run on the same physical host. This is particularly useful for high-availability setups, where redundancy is crucial. Ensuring that critical services are distributed across multiple hosts reduces the risk of a single point of failure.
#### Affinity Rules by Pools
Antoher approach is by using pools in Proxmox. This way, it can easily also combined with other resources like backup jobs. However, in this approach you need to modify the ProxLB config file to your needs. Within the `balancing` section you can create a dict of pools, including the pool name and the affinity type. Please see the example for further details:
**Example Config**
```
balancing:
[...]
pools: # Optional: Define affinity/anti-affinity rules per pool
dev: # Pool name: dev
type: affinity # Type: affinity (keeping VMs together)
pin: # Pin VMs to Nodes
- virt77 # Pinning to 'virt77' which is maybe an older system for dev labs
```
### Anti-Affinity Rules by Tags
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-anti-affinity-rules.jpg"/> Conversely, anti-affinity rules ensure that designated VMs do not run on the same physical host. This is particularly useful for high-availability setups, where redundancy is crucial. Ensuring that critical services are distributed across multiple hosts reduces the risk of a single point of failure. In general, there're two ways to manage anti-affinity rules:
To define an anti-affinity rule that ensures to not move systems within this group to the same node, users assign a tag with the prefix:
@@ -413,6 +436,19 @@ plb_anti_affinity_ntp
As a result, ProxLB will try to place the VMs with the `plb_anti_affinity_ntp` tag on different hosts (see also the attached screenshot with the different nodes).
#### Anti-Affinity Rules by Pools
Antoher approach is by using pools in Proxmox. This way, it can easily also combined with other resources like backup jobs. However, in this approach you need to modify the ProxLB config file to your needs. Within the `balancing` section you can create a dict of pools, including the pool name and the affinity type. Please see the example for further details:
**Example Config**
```
balancing:
[...]
pools: # Optional: Define affinity/anti-affinity rules per pool
de-nbg01-db: # Pool name: de-nbg01-db
type: anti-affinity # Type: anti-affinity (spreading VMs apart)
```
**Note:** While this ensures that ProxLB tries distribute these VMs across different physical hosts within the Proxmox cluster this may not always work. If you have more guests attached to the group than nodes in the cluster, we still need to run them anywhere. If this case occurs, the next one with the most free resources will be selected.
### Ignore VMs
@@ -432,6 +468,7 @@ As a result, ProxLB will not migrate this guest with the `plb_ignore_dev` tag to
### Pin VMs to Specific Hypervisor Nodes
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-tag-node-pinning.jpg"/> Guests, such as VMs or CTs, can also be pinned to specific (and multiple) nodes in the cluster. This might be usefull when running applications with some special licensing requirements that are only fulfilled on certain nodes. It might also be interesting, when some physical hardware is attached to a node, that is not available in general within the cluster.
#### Pinning VMs to (a) specific Hypervisor Node(s) by Tag
To pin a guest to a specific cluster node, users assign a tag with the prefix `plb_pin_$nodename` to the desired guest:
#### Example for Screenshot
@@ -441,6 +478,22 @@ plb_pin_node03
As a result, ProxLB will pin the guest `dev-vm01` to the node `virt03`.
#### Pinning VMs to (a) specific Hypervisor Node(s) by Pools
Beside the tag approach, you can also pin a resource group to a specific hypervisor or groups of hypervisors by defining a `pin` key of type list.
**Example Config**
```
balancing:
[...]
pools: # Optional: Define affinity/anti-affinity rules per pool
dev: # Pool name: dev
type: affinity # Type: affinity (keeping VMs together)
pin: # Pin VMs to Nodes
- virt77 # Pinning to 'virt77' which is maybe an older system for dev labs
```
You can also repeat this step multiple times for different node names to create a potential group of allowed hosts where a the guest may be served on. In this case, ProxLB takes the node with the lowest used resources according to the defined balancing values from this group.
**Note:** The given node names from the tag are validated. This means, ProxLB validated if the given node name is really part of the cluster. In case of a wrongly defined or unavailable node name it continous to use the regular processes to make sure the guest keeps running.

View File

@@ -60,6 +60,14 @@ balancing:
# pressure_full: 0.20
# pressure_some: 0.20
# pressure_spikes: 1.00
pools: # Optional: Define affinity/anti-affinity rules per pool
dev: # Pool name: dev
type: affinity # Type: affinity (keeping VMs together)
de-nbg01-db: # Pool name: de-nbg01-db
type: anti-affinity # Type: anti-affinity (spreading VMs apart)
pin: # Define a pinning og guests to specific node(s)
- virt66
- virt77
service:
daemon: True

2
debian/changelog vendored
View File

@@ -1,6 +1,8 @@
proxlb (1.1.9) stable; urgency=medium
* Add pressure (PSI) based balancing for memory, cpu, disk (req. PVE9 or greater). (Closes: #339)
* Add (memory) threshold for nodes before running balancing. (Closes: #342)
* Add affinity/anti-affinity support by pools. (Closes: #343)
-- Florian Paul Azim Hoberg <gyptazy@gyptazy.com> Thu, 22 Oct 2025 09:04:13 +0002

View File

@@ -80,8 +80,8 @@ ProxLB provides an advanced mechanism to define affinity and anti-affinity rules
ProxLB implements affinity and anti-affinity rules through a tag-based system within the Proxmox web interface. Each guest (virtual machine or container) can be assigned specific tags, which then dictate its placement behavior. This method maintains a streamlined and secure approach to managing VM relationships while preserving Proxmoxs inherent permission model.
#### Affinity Rules
<img align="left" src="https://cdn.gyptazy.com/images/proxlb-affinity-rules.jpg"/> Affinity rules are used to group certain VMs together, ensuring that they run on the same host whenever possible. This can be beneficial for workloads requiring low-latency communication, such as clustered databases or application servers that frequently exchange data.
#### Affinity Rules by Tags
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-affinity-rules.jpg"/> Affinity rules are used to group certain VMs together, ensuring that they run on the same host whenever possible. This can be beneficial for workloads requiring low-latency communication, such as clustered databases or application servers that frequently exchange data.
To define an affinity rule which keeps all guests assigned to this tag together on a node, users assign a tag with the prefix `plb_affinity_$TAG`:
@@ -92,8 +92,20 @@ plb_affinity_talos
As a result, ProxLB will attempt to place all VMs with the `plb_affinity_web` tag on the same host (see also the attached screenshot with the same node).
#### Anti-Affinity Rules
<img align="left" src="https://cdn.gyptazy.com/images/proxlb-anti-affinity-rules.jpg"/> Conversely, anti-affinity rules ensure that designated VMs do not run on the same physical host. This is particularly useful for high-availability setups, where redundancy is crucial. Ensuring that critical services are distributed across multiple hosts reduces the risk of a single point of failure.
#### Affinity Rules by Pools
Antoher approach is by using pools in Proxmox. This way, it can easily also combined with other resources like backup jobs. However, in this approach you need to modify the ProxLB config file to your needs. Within the `balancing` section you can create a dict of pools, including the pool name and the affinity type. Please see the example for further details:
**Example Config**
```
balancing:
[...]
pools: # Optional: Define affinity/anti-affinity rules per pool
dev: # Pool name: dev
type: affinity # Type: affinity (keeping VMs together)
```
#### Anti-Affinity Rules by Tags
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-anti-affinity-rules.jpg"/> Conversely, anti-affinity rules ensure that designated VMs do not run on the same physical host. This is particularly useful for high-availability setups, where redundancy is crucial. Ensuring that critical services are distributed across multiple hosts reduces the risk of a single point of failure.
To define an anti-affinity rule that ensures to not move systems within this group to the same node, users assign a tag with the prefix:
@@ -106,6 +118,18 @@ As a result, ProxLB will try to place the VMs with the `plb_anti_affinity_ntp` t
**Note:** While this ensures that ProxLB tries distribute these VMs across different physical hosts within the Proxmox cluster this may not always work. If you have more guests attached to the group than nodes in the cluster, we still need to run them anywhere. If this case occurs, the next one with the most free resources will be selected.
#### Anti-Affinity Rules by Pools
Antoher approach is by using pools in Proxmox. This way, it can easily also combined with other resources like backup jobs. However, in this approach you need to modify the ProxLB config file to your needs. Within the `balancing` section you can create a dict of pools, including the pool name and the affinity type. Please see the example for further details:
**Example Config**
```
balancing:
[...]
pools: # Optional: Define affinity/anti-affinity rules per pool
de-nbg01-db: # Pool name: de-nbg01-db
type: anti-affinity # Type: anti-affinity (spreading VMs apart)
````
### Affinity / Anti-Affinity Enforcing
When a cluster is already balanced and does not require further adjustments, enabling the enforce_affinity parameter ensures that affinity and anti-affinity rules are still respected. This parameter prioritizes the placement of guest objects according to these rules, even if it leads to slight resource imbalances or increased migration overhead. Regularly reviewing and updating these rules, along with monitoring cluster performance, helps maintain optimal performance and reliability. By carefully managing these aspects, you can create a cluster environment that meets your specific needs and maintains a good balance of resources.
@@ -117,7 +141,7 @@ balancing:
*Note: This may have impacts to the cluster. Depending on the created group matrix, the result may also be an unbalanced cluster.*
### Ignore VMs / CTs
<img align="left" src="https://cdn.gyptazy.com/images/proxlb-ignore-vm-movement.jpg"/> Guests, such as VMs or CTs, can also be completely ignored. This means, they won't be affected by any migration (even when (anti-)affinity rules are enforced). To ensure a proper resource evaluation, these guests are still collected and evaluated but simply skipped for balancing actions. Another thing is the implementation. While ProxLB might have a very restricted configuration file including the file permissions, this file is only read- and writeable by the Proxmox administrators. However, we might have user and groups who want to define on their own that their systems shouldn't be moved. Therefore, these users can simpy set a specific tag to the guest object - just like the (anti)affinity rules.
<img align="left" src="https://cdn.gyptazy.com/img/proxlb-ignore-vm-movement.jpg"/> Guests, such as VMs or CTs, can also be completely ignored. This means, they won't be affected by any migration (even when (anti-)affinity rules are enforced). To ensure a proper resource evaluation, these guests are still collected and evaluated but simply skipped for balancing actions. Another thing is the implementation. While ProxLB might have a very restricted configuration file including the file permissions, this file is only read- and writeable by the Proxmox administrators. However, we might have user and groups who want to define on their own that their systems shouldn't be moved. Therefore, these users can simpy set a specific tag to the guest object - just like the (anti)affinity rules.
To define a guest to be ignored from the balancing, users assign a tag with the prefix `plb_ignore_$TAG`:

View File

@@ -23,6 +23,7 @@ from models.guests import Guests
from models.groups import Groups
from models.calculations import Calculations
from models.balancing import Balancing
from models.pools import Pools
from utils.helper import Helper
@@ -71,11 +72,12 @@ def main():
# Get all required objects from the Proxmox cluster
meta = {"meta": proxlb_config}
nodes = Nodes.get_nodes(proxmox_api, proxlb_config)
guests = Guests.get_guests(proxmox_api, nodes, meta)
pools = Pools.get_pools(proxmox_api)
guests = Guests.get_guests(proxmox_api, pools, nodes, meta, proxlb_config)
groups = Groups.get_groups(guests, nodes)
# Merge obtained objects from the Proxmox cluster for further usage
proxlb_data = {**meta, **nodes, **guests, **groups}
proxlb_data = {**meta, **nodes, **guests, **pools, **groups}
Helper.log_node_metrics(proxlb_data)
# Update the initial node resource assignments

View File

@@ -10,6 +10,7 @@ __license__ = "GPL-3.0"
from typing import Dict, Any
from utils.logger import SystemdLogger
from models.pools import Pools
from models.tags import Tags
import time
@@ -35,7 +36,7 @@ class Guests:
"""
@staticmethod
def get_guests(proxmox_api: any, nodes: Dict[str, Any], meta: Dict[str, Any]) -> Dict[str, Any]:
def get_guests(proxmox_api: any, pools: Dict[str, Any], nodes: Dict[str, Any], meta: Dict[str, Any], proxlb_config: Dict[str, Any]) -> Dict[str, Any]:
"""
Get metrics of all guests in a Proxmox cluster.
@@ -46,6 +47,8 @@ class Guests:
Args:
proxmox_api (any): The Proxmox API client instance.
nodes (Dict[str, Any]): A dictionary containing information about the nodes in the Proxmox cluster.
meta (Dict[str, Any]): A dictionary containing metadata information.
proxmox_config (Dict[str, Any]): A dictionary containing the ProxLB configuration.
Returns:
Dict[str, Any]: A dictionary containing metrics and information for all running guests.
@@ -91,10 +94,11 @@ class Guests:
guests['guests'][guest['name']]['processed'] = False
guests['guests'][guest['name']]['pressure_hot'] = False
guests['guests'][guest['name']]['tags'] = Tags.get_tags_from_guests(proxmox_api, node, guest['vmid'], 'vm')
guests['guests'][guest['name']]['affinity_groups'] = Tags.get_affinity_groups(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['anti_affinity_groups'] = Tags.get_anti_affinity_groups(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['pools'] = Pools.get_pools_for_guest(guest['name'], pools)
guests['guests'][guest['name']]['affinity_groups'] = Tags.get_affinity_groups(guests['guests'][guest['name']]['tags'], guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['anti_affinity_groups'] = Tags.get_anti_affinity_groups(guests['guests'][guest['name']]['tags'], guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['ignore'] = Tags.get_ignore(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['node_relationships'] = Tags.get_node_relationships(guests['guests'][guest['name']]['tags'], nodes)
guests['guests'][guest['name']]['node_relationships'] = Tags.get_node_relationships(guests['guests'][guest['name']]['tags'], nodes, guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['type'] = 'vm'
logger.debug(f"Resources of Guest {guest['name']} (type VM) added: {guests['guests'][guest['name']]}")
@@ -135,10 +139,11 @@ class Guests:
guests['guests'][guest['name']]['processed'] = False
guests['guests'][guest['name']]['pressure_hot'] = False
guests['guests'][guest['name']]['tags'] = Tags.get_tags_from_guests(proxmox_api, node, guest['vmid'], 'ct')
guests['guests'][guest['name']]['affinity_groups'] = Tags.get_affinity_groups(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['anti_affinity_groups'] = Tags.get_anti_affinity_groups(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['pools'] = Pools.get_pools_for_guest(guest['name'], pools)
guests['guests'][guest['name']]['affinity_groups'] = Tags.get_affinity_groups(guests['guests'][guest['name']]['tags'], guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['anti_affinity_groups'] = Tags.get_anti_affinity_groups(guests['guests'][guest['name']]['tags'], guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['ignore'] = Tags.get_ignore(guests['guests'][guest['name']]['tags'])
guests['guests'][guest['name']]['node_relationships'] = Tags.get_node_relationships(guests['guests'][guest['name']]['tags'], nodes)
guests['guests'][guest['name']]['node_relationships'] = Tags.get_node_relationships(guests['guests'][guest['name']]['tags'], nodes, guests['guests'][guest['name']]['pools'], proxlb_config)
guests['guests'][guest['name']]['type'] = 'ct'
logger.debug(f"Resources of Guest {guest['name']} (type CT) added: {guests['guests'][guest['name']]}")

View File

@@ -48,6 +48,7 @@ class Nodes:
Args:
proxmox_api (any): The Proxmox API client instance.
proxmox_config (Dict[str, Any]): A dictionary containing the ProxLB configuration.
nodes (Dict[str, Any]): A dictionary containing information about the nodes in the Proxmox cluster.
Returns:

111
proxlb/models/pools.py Normal file
View File

@@ -0,0 +1,111 @@
"""
The Pools class retrieves all present pools defined on a Proxmox cluster
including the chield objects.
"""
__author__ = "Florian Paul Azim Hoberg <gyptazy>"
__copyright__ = "Copyright (C) 2025 Florian Paul Azim Hoberg (@gyptazy)"
__license__ = "GPL-3.0"
from typing import Dict, Any
from utils.logger import SystemdLogger
from models.tags import Tags
import time
logger = SystemdLogger()
class Pools:
"""
The Pools class retrieves all present pools defined on a Proxmox cluster
including the chield objects.
Methods:
__init__:
Initializes the Pools class.
get_pools(proxmox_api: any) -> Dict[str, Any]:
Retrieve pool definitions and membership from the Proxmox cluster.
Returns a dict with a top-level "pools" mapping each poolid to
{"name": <poolid>, "members": [<member_names>...]}.
This method does not collect per-member metrics or perform node filtering.
"""
def __init__(self):
"""
Initializes the Pools class with the provided ProxLB data.
"""
@staticmethod
def get_pools(proxmox_api: any) -> Dict[str, Any]:
"""
Retrieve all pools and their members from a Proxmox cluster.
Queries the Proxmox API for pool definitions and returns a dictionary
containing each pool's id/name and a list of its member VM/CT names.
This function does not perform per-member metric collection or node
filtering — it only gathers pool membership information.
Args:
proxmox_api (any): Proxmox API client instance.
Returns:
Dict[str, Any]: Dictionary with a top-level "pools" key mapping poolid
to {"name": <poolid>, "members": [<member_names>...]}.
"""
logger.debug("Starting: get_pools.")
pools = {"pools": {}}
# Pool objects: iterate over all pools in the cluster.
# We keep pool members even if their nodes are ignored so resource accounting
# for rebalancing remains correct and we avoid overprovisioning nodes.
for pool in proxmox_api.pools.get():
logger.debug(f"Got pool: {pool['poolid']}")
pools['pools'][pool['poolid']] = {}
pools['pools'][pool['poolid']]['name'] = pool['poolid']
pools['pools'][pool['poolid']]['members'] = []
# Fetch pool details and collect member names
pool_details = proxmox_api.pools(pool['poolid']).get()
for member in pool_details.get("members", []):
logger.debug(f"Got member: {member['name']} for pool: {pool['poolid']}")
pools['pools'][pool['poolid']]['members'].append(member["name"])
logger.debug("Finished: get_pools.")
return pools
@staticmethod
def get_pools_for_guest(guest_name: str, pools: Dict[str, Any]) -> Dict[str, Any]:
"""
Return the list of pool names that include the given guest.
Args:
guest_name (str): Name of the VM or CT to look up.
pools (Dict[str, Any]): Pools structure as returned by get_pools(),
expected to contain a top-level "pools" mapping each poolid to
{"name": <poolid>, "members": [<member_names>...]}.
Returns:
list[str]: Names of pools the guest is a member of (empty list if none).
"""
logger.debug("Starting: get_pools_for_guests.")
guest_pools = []
for pool in pools.items():
for pool_id, pool_data in pool[1].items():
if type(pool_data) is dict:
pool_name = pool_data.get("name", "")
pool_name_members = pool_data.get("members", [])
if guest_name in pool_name_members:
logger.debug(f"Guest: {guest_name} is member of Pool: {pool_name}.")
guest_pools.append(pool_name)
else:
logger.debug(f"Guest: {guest_name} is NOT member of Pool: {pool_name}.")
else:
logger.debug(f"Pool data for pool_id {pool_id} is not a dict: {pool_data}")
logger.debug("Finished: get_pools_for_guests.")
return guest_pools

View File

@@ -80,15 +80,18 @@ class Tags:
return tags
@staticmethod
def get_affinity_groups(tags: List[str]) -> List[str]:
def get_affinity_groups(tags: List[str], pools: List[str], proxlb_config: Dict[str, Any]) -> List[str]:
"""
Get affinity tags for a guest from the Proxmox cluster by the API.
This method retrieves all tags for a given guest and evaluates the
affinity tags which are required during the balancing calculations.
This method retrieves all tags for a given guest or based on a
membership of a pool and evaluates the affinity groups which are
required during the balancing calculations.
Args:
tags (List): A list holding all defined tags for a given guest.
pools (List): A list holding all defined pools for a given guest.
proxlb_config (Dict): A dict holding the ProxLB configuration.
Returns:
List: A list including all affinity tags for the given guest.
@@ -99,21 +102,36 @@ class Tags:
if len(tags) > 0:
for tag in tags:
if tag.startswith("plb_affinity"):
logger.debug(f"Adding affinity group for tag {tag}.")
affinity_tags.append(tag)
else:
logger.debug(f"Skipping affinity group for tag {tag}.")
if len(pools) > 0:
for pool in pools:
if pool in proxlb_config['balancing'].get('pools', []):
if proxlb_config['balancing']['pools'][pool].get('type', None) == 'affinity':
logger.debug(f"Adding affinity group for pool {pool}.")
affinity_tags.append(pool)
else:
logger.debug(f"Skipping affinity group for pool {pool}.")
logger.debug("Finished: get_affinity_groups.")
return affinity_tags
@staticmethod
def get_anti_affinity_groups(tags: List[str]) -> List[str]:
def get_anti_affinity_groups(tags: List[str], pools: List[str], proxlb_config: Dict[str, Any]) -> List[str]:
"""
Get anti-affinity tags for a guest from the Proxmox cluster by the API.
This method retrieves all tags for a given guest and evaluates the
anti-affinity tags which are required during the balancing calculations.
This method retrieves all tags for a given guest or based on a
membership of a pool and evaluates the anti-affinity groups which
are required during the balancing calculations.
Args:
tags (List): A list holding all defined tags for a given guest.
pools (List): A list holding all defined pools for a given guest.
proxlb_config (Dict): A dict holding the ProxLB configuration.
Returns:
List: A list including all anti-affinity tags for the given guest..
@@ -124,7 +142,19 @@ class Tags:
if len(tags) > 0:
for tag in tags:
if tag.startswith("plb_anti_affinity"):
logger.debug(f"Adding anti-affinity group for tag {tag}.")
anti_affinity_tags.append(tag)
else:
logger.debug(f"Skipping anti-affinity group for tag {tag}.")
if len(pools) > 0:
for pool in pools:
if pool in proxlb_config['balancing'].get('pools', []):
if proxlb_config['balancing']['pools'][pool].get('type', None) == 'anti-affinity':
logger.debug(f"Adding anti-affinity group for pool {pool}.")
anti_affinity_tags.append(pool)
else:
logger.debug(f"Skipping anti-affinity group for pool {pool}.")
logger.debug("Finished: get_anti_affinity_groups.")
return anti_affinity_tags
@@ -155,10 +185,10 @@ class Tags:
return ignore_tag
@staticmethod
def get_node_relationships(tags: List[str], nodes: Dict[str, Any]) -> str:
def get_node_relationships(tags: List[str], nodes: Dict[str, Any], pools: List[str], proxlb_config: Dict[str, Any]) -> str:
"""
Get a node relationship tag for a guest from the Proxmox cluster by the API to pin
a guest to a node.
a guest to a node or by defined pools from ProxLB configuration.
This method retrieves a relationship tag between a guest and a specific
hypervisor node to pin the guest to a specific node (e.g., for licensing reason).
@@ -166,24 +196,44 @@ class Tags:
Args:
tags (List): A list holding all defined tags for a given guest.
nodes (Dict): A dictionary holding all available nodes in the cluster.
pools (List): A list holding all defined pools for a given guest.
proxlb_config (Dict): A dict holding the ProxLB configuration.
Returns:
Str: The related hypervisor node name.
Str: The related hypervisor node name(s).
"""
logger.debug("Starting: get_node_relationships.")
node_relationship_tags = []
if len(tags) > 0:
logger.debug("Validating node pinning by tags.")
for tag in tags:
if tag.startswith("plb_pin"):
node_relationship_tag = tag.replace("plb_pin_", "")
# Validate if the node to pin is present in the cluster
if Helper.validate_node_presence(node_relationship_tag, nodes):
logger.info(f"Tag {node_relationship_tag} is valid! Defined node exists in the cluster.")
logger.debug(f"Tag {node_relationship_tag} is valid! Defined node exists in the cluster.")
logger.debug(f"Setting node relationship because of tag {tag} to {node_relationship_tag}.")
node_relationship_tags.append(node_relationship_tag)
else:
logger.warning(f"Tag {node_relationship_tag} is invalid! Defined node does not exist in the cluster. Not applying pinning.")
if len(pools) > 0:
logger.debug("Validating node pinning by pools.")
for pool in pools:
if pool in proxlb_config['balancing'].get('pools', []):
node = proxlb_config['balancing']['pools'][pool].get('pin', None)
# Validate if the node to pin is present in the cluster
if Helper.validate_node_presence(node, nodes):
logger.debug(f"Pool pinning tag {node} is valid! Defined node exists in the cluster.")
logger.debug(f"Setting node relationship because of pool {pool} to {node}.")
node_relationship_tags.append(node)
else:
logger.warning(f"Pool pinning tag {node} is invalid! Defined node does not exist in the cluster. Not applying pinning.")
else:
logger.debug(f"Skipping pinning for pool {pool}. Pool is not defined in ProxLB configuration.")
logger.debug("Finished: get_node_relationships.")
return node_relationship_tags