Syncing Proxmox Hosts in a Cluster via API Calls

[Lotan81]

Hi! I’m interested in working with Proxmox through API calls.
I have a cluster with three hosts, and I perform various actions on VMs such as cloning, resizing, setting configurations, and starting/stopping them.

While sending requests to a specific host works successfully, I encounter issues when making requests to different hosts for the same VM, which are routed via a load balancer.

For example, I sent a change configurations request for a specific VM to “Host1” using “POST /api2/json/nodes/{node}/qemu/{vmid}/config” - and it worked correctly.

Then, I sent another request to “Host2” using “GET /api2/json/cluster/resources” to search for the newly created VM by its new name, but unfortunately, I couldn't find it in the list of returning VMs.

To resolve this issue, I wonder if I need to reconfigure my cluster settings or introduce more time intervals between API calls.

Additionally, I'm curious to know if there’s a way to determine which host sent me the response for a specific request.

Thanks!

 

[gurubert]

introduce more time intervals between API calls.

Yes. Your API script should always talk to the same backend for best results.

The load balancer should load balance the same client to the same backend (as long as it's available) and not do a round-robing style load balancing.

Our HA-proxy configuration looks like this:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
    log    global
    mode    http
    option    httplog
    option    dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend web
    bind *:443
    mode tcp
    option tcplog
    default_backend pveweb

backend pveweb
    mode tcp
    balance source
    server node1 192.0.2.5:8006 check
    server node2 192.0.2.6:8006 check
    server node3 192.0.2.7:8006 check
    server node4 192.0.2.8:8006 check

frontend spice
    bind *:3128
    mode tcp
    option tcplog
    default_backend pvespice

backend pvespice
    mode tcp
    balance source
    server node1 192.0.2.5:3128 check
    server node2 192.0.2.6:3128 check
    server node3 192.0.2.7:3128 check
    server node4 192.0.2.8:3128 check

This also binds the web port to 443 and not 8006. This is a passthrough SSL configuration, i.e. the certificates served by the Proxmox nodes have to match this server's hostname.