# ha Published articles for ha. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## CVE-2026-123033 - TrueNAS SCALE middlewared Authentication Bypass DevFeed: [CVE-2026-123033 - TrueNAS SCALE middlewared Authentication Bypass]() Original publisher: [Read original article]() Author: CVEFEED.io; mitre.org Published: 2026-11-05T06:58:31Z Content type: article Language: en Sources: [Latest High/Critical Vulnerabilitiy Feed]() Topics: [truenas](), [Authentication](), [Access Control]() Tags: [administrator](), [api](), [api-access](), [authentication](), [authentication-bypass](), [commands](), [community-edition](), [cve](), [cve-2026-123033](), [ha](), [interface](), [network](), [node](), [peer](), [permission](), [port](), [root](), [scale](), [socket](), [truenas]() ### AI overview Before TrueNAS SCALE 25.10.8 (or the corresponding fixes in other release trains), middlewared's HA peer-authentication hook could grant unauthenticated full-administrator API access, including root command execution, to a connection from the same layer-2 network segment. The hook was registered even on non-HA, unlicensed single-node Community Edition systems. It accepted connections whose TCP peer address was 169.254.10.1 or 169.254.10.2 and whose peer port was 1024 or lower; both properties belonged to the attacker's own socket, so no spoofing was needed. The stated fix also requires the connection to terminate on the HA heartbeat listener, a local address and port the attacker cannot control. The source reports severity 8.3 (HIGH), but its affected-products table lists no products. ### Source excerpt CVE ID :CVE-2026-123033 Published : Nov. 5, 2026, 6:58 a.m. | 29 minutes ago Description :Authentication bypass in the HA heartbeat origin check in middlewared in TrueNAS SCALE before 25.10.8 (and in release trains before their respective fixes) allows an attacker on the same network segment to achieve unauthenticated full-administrator API access and execute commands as root. middlewared registers the HA peer-authentication hook (ha_permission) unconditionally, with no failover-licence or heartbeat-interface check. An unauthenticated connection whose TCP peer address is a hardcoded HA heartbeat address (169.254.10.1 or 169.254.10.2) and whose peer port is <= 1024 is granted a node credential that is authorized for every API method and treated as full administrator. Both conditions are properties of the attacker's own socket, and thus an attacker on the same layer-2 segment satisfies them without forging anything. The hook is present on non-HA, unlicensed, single-node Community Edition installations. The fix additionally requires that the connection terminate on the HA heartbeat listener (a local address/port the attacker cannot control). Severity: 8.3 | HIGH Visit the link for more details, such as CVSS details, affected products, timeline, and more... ## Demystifying VCF Automation Node Architecture & Load Balancing DevFeed: [Demystifying VCF Automation Node Architecture & Load Balancing]() Original publisher: [Read original article]() Author: vmwareblogs Published: 2026-11-04T14:00:00Z Content type: article Language: en Sources: [VMware]() Topics: [vcf automation](), [Load Balancing](), [VMware Cloud Foundation]() Tags: [3](), [architecture](), [automation](), [availability](), [balancing](), [cloud-infrastructure](), [deployment](), [external](), [ha](), [high-availability](), [home-page](), [ip](), [layer](), [load](), [load-balancing](), [native](), [node](), [vcf](), [vcf-automation](), [vip](), [virtual](), [vmware]() ### AI overview A standard VCF Automation HA deployment uses three appliance VMs on one management network interface, with five node-pool IPs: three active node addresses and two reserved for upgrades, redeployments, or scale-out. It also requires two distinct FQDNs mapped to static VIPs: a public/API endpoint and a service runtime endpoint for management traffic. The embedded kube-vip and Envoy layer hosts and fails over these VIPs and routes traffic to application pods; it remains necessary even when an external load balancer or GSLB is used. In the described external-LB design, user traffic passes through the external service to the tenant-facing VIP, while SDDC Manager and VCF Operations reach the runtime VIP directly. For the stated Aria Automation 8.18.x to VCF Automation 9.x upgrade, the text specifies nine IPs: one runtime VIP, three node IPs, two buffer IPs, and three per-node VIPs, plus two FQDNs. ### Source excerpt When deploying VCF Automation, one of the most common points of confusion on the deployment parameter screen revolves around FQDN mappings, Virtual IP (VIP) behavior, and how load balancing operates under the hood. Here is a complete breakdown structure explaining the 3-node High Availability (HA) architecture, the native load balancing layer, and how external GSLB/load ... Continued The post Demystifying VCF Automation Node Architecture & Load Balancing appeared first on VMware Blogs. ## Designing a planned switchover for minimum disruption DevFeed: [Designing a planned switchover for minimum disruption]() Original publisher: [Read original article]() Author: Shlomi Noach Published: 2026-10-29T00:00:00Z Content type: article Language: en Sources: [PlanetScale]() Topics: [neki](), [downtime](), [control-plane](), [Resilience](), [distributed algorithm](), [Production Engineering](), [health check]() Tags: [admin](), [buffer](), [candidate](), [capacity](), [client](), [cluster](), [commit](), [configuration](), [convergence](), [disruption](), [durability](), [election](), [engineering](), [failover](), [ha](), [neki](), [postgres](), [primary](), [query](), [replication](), [rollback]() ### AI overview Neki reduces disruption during planned Postgres primary switchovers by validating the shard and candidate while the old primary still serves writes, then buffering primary-bound queries before making it read-only. Admin selects a replica, disconnects the others to establish a final WAL position, and waits for the target to replay through it. With synchronous replication configured as `ANY 1`, the target can catch up without a slow replica blocking progress; Admin also prepares replication slots and requires at least one attached replica in the target's synchronous configuration. Routers replan buffered queries against the new topology, so they take longer but usually avoid errors. Failed checks or a deadline trigger rollback: the old primary can be made writable again and other replicas reconnected. Buffers have finite capacity and query deadlines, and not all Routers must acknowledge the buffering signal. Neki contrasts this with Patroni's clean-shutdown approach, which simplifies final WAL accounting but can leave no primary while the old server restarts or rewinds. Under Neki's synchronous durability policy and default `synchronous_commit = on`, acknowledged commits are present. ### Source excerpt How Neki uses preflight checks, query buffering, synchronous replication, and fast rollback to make Postgres primary switchovers less disruptive. ## 5 Things I'd Test Before Trusting Proxmox High Availability DevFeed: [5 Things I'd Test Before Trusting Proxmox High Availability]() Original publisher: [Read original article]() Author: Brandon Lee Published: 2026-10-28T12:42:33Z Content type: tutorial Language: en Sources: [Virtualization Howto]() Topics: [Proxmox](), [virtualization](), [virtual machines](), [systems](), [Availability](), [Chaos Engineering](), [Homelab]() Tags: [affinity](), [applications](), [availability](), [bridge](), [capacity](), [cluster](), [configuration](), [connectivity](), [container](), [cpu](), [database](), [datastores](), [dependencies](), [dns](), [dns-servers](), [ha](), [high-availability](), [home-lab](), [home-server](), [proxmox](), [storage](), [virtual-machines]() ### AI overview Proxmox HA restarts guests on a healthy host after a host failure, but it does not ensure application availability or guarantee every node can run every workload. The article recommends testing five failure modes: abruptly power off a node and inspect guest recovery, HA logs, quorum, and remaining n+1 capacity; isolate a powered-on node from Corosync and confirm the cluster safely prevents duplicate guests from writing to shared storage; verify each host's bridges, VLANs, network access, storage, and passthrough dependencies, using strict node affinity for workloads that need compatible hosts; test shared-storage connectivity and failover, or check Proxmox replication status for local ZFS; and stop an application inside a healthy VM to confirm the boundary of VM-level HA. For application health checks and failover, it points to Keepalived track scripts. It advises controlled testing, avoiding forced quorum or manual duplicate starts during partition tests, and recording results for periodic retesting. ### Source excerpt One of the first things that you will want to do after you create a Proxmox cluster with shared storage is enable HA for your virtual machines. HA is one... The post 5 Things I'd Test Before Trusting Proxmox High Availability appeared first on Virtualization Howto. ## Xen Orchestra 6.6 DevFeed: [Xen Orchestra 6.6]() Original publisher: [Read original article]() Author: Olivier Lambert Published: 2026-06-30T14:39:01Z Content type: release Language: en Sources: [Xen Orchestra]() Topics: [Xen](), [migration](), [cloud-infrastructure](), [Windows](), [Linux Kernel](), [Network](), [Vulnerabilities]() Tags: [ha](), [linux](), [linux-kernel](), [migrations](), [network](), [release](), [security-vulnerabilities](), [snapshots](), [storage](), [vm](), [xen]() ### AI overview Xen Orchestra 6.6 introduces scoped Storage and Network administrator roles in the REST API, automatic safety snapshots before updates, V2V migration optimizations, VM export, and a Storage tab in XO Lite. The release also covers signed Windows Guest Tools, XCP-ng maintenance and security updates, and TwinStor for two-node hyperconverged storage. ### Source excerpt XO 6.6 is out: scoped Storage and Network admin roles, VM export in XO 6, automatic XOA safety snapshots before updates, lighter V2V migrations, plus a Storage tab in XO Lite. ## How to Migrate from SQL Server to PostgreSQL HA for Dockerized Apps DevFeed: [How to Migrate from SQL Server to PostgreSQL HA for Dockerized Apps]() Original publisher: [Read original article]() Author: Jessie Baynas Published: 2026-05-28T07:18:00Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [PostgreSQL](), [sql-server](), [software-architecture](), [SQL]() Tags: [cloud-native](), [clustercontrol](), [compatibility](), [containerized](), [control](), [costs](), [data](), [database](), [database-general](), [efficiency](), [flexibility](), [ha](), [microsoft](), [microsoft-sql-server](), [migrate](), [modernization](), [open-source](), [operational-efficiency](), [postgresql](), [scalability](), [sql-server]() ### AI overview The excerpt recommends separating schema conversion from bulk data movement when migrating SQL Server to PostgreSQL: use pgloader for schema conversion, BCP to export table data as CSV, and PostgreSQL COPY to import it. The article says this provides more control for troubleshooting and validation, particularly with large databases. The proposed environment uses Dockerized application services, PostgreSQL Streaming Replication, and ClusterControl for deployment, monitoring, and failover management. The excerpt does not provide the full migration procedure or discuss detailed limitations. ### Source excerpt For many organizations, migrating from Microsoft SQL Server to PostgreSQL is no longer only about reducing licensing costs. The transition is often part of a broader modernization initiative focused on improving flexibility, scalability, and operational efficiency. PostgreSQL has evolved into one of the most mature open-source database platforms available today. It is widely adopted across [...] The post How to Migrate from SQL Server to PostgreSQL HA for Dockerized Apps appeared first on Severalnines. ## Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches DevFeed: [Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches]() Original publisher: [Read original article]() Author: Agus Syafaat Published: 2026-05-21T07:20:00Z Content type: article Language: en Sources: [SeveralNines]() Topics: [patroni](), [PostgreSQL](), [Availability](), [ClusterControl]() Tags: [architecture](), [automatic](), [automation](), [availability](), [challenges](), [clustercontrol](), [clusters](), [consensus](), [consul](), [database](), [dcs](), [distributed](), [distributed-consensus](), [election](), [failover](), [ha](), [high-availability](), [patroni](), [postgresql](), [postgresql-clusters](), [recovery-repair]() ### AI overview The excerpt describes Patroni as an open-source PostgreSQL HA tool that coordinates replication and automatic failover through a distributed configuration store such as etcd, Consul, or ZooKeeper. The primary maintains a lease; standby nodes monitor it, and if the primary stops responding, a new leader is elected using criteria including replication lag and node health. YAML configuration defines Patroni's behavior. The article says it will examine Patroni's operational challenges and how ClusterControl might complement or replace it, but the excerpt provides no details on those approaches or comparisons with repmgr and PgAutoFailover. ### Source excerpt In modern application stacks, downtime is a direct threat to business continuity, customer trust, and revenue. Regardless of whether it is an e-commerce platform, a fintech application, or a critical internal system, the expectation is 24/7 availability, underscoring the critical importance of High Availability (HA) and automated failover mechanisms within PostgreSQL clusters. HA ensures that [...] The post Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches appeared first on Severalnines. ## Active-Active MySQL Group Replication Best Practices DevFeed: [Active-Active MySQL Group Replication Best Practices]() Original publisher: [Read original article]() Author: Paul Namuag Published: 2026-03-11T12:54:52Z Content type: article Language: en Sources: [SeveralNines]() Topics: [mysql group replication](), [Transactions](), [consistency]() Tags: [best-practices](), [certification](), [cluster](), [consensus](), [consistency](), [deployment-scaling](), [engine](), [gcs](), [ha](), [high-availability](), [mgr](), [mysql](), [mysql-group-replication](), [operational](), [paxos](), [production](), [replication](), [scalability]() ### AI overview Active-active MySQL Group Replication lets every member in PRIMARY state accept reads and writes, with transactions replicated synchronously across the cluster. The Group Communication System manages membership and ordered delivery; its XCom engine uses Paxos-based consensus, while write-set certification detects conflicting transactions and resolves them automatically. This can support write scalability and high availability, but scalability depends partly on keeping write conflicts low: high contention can cause rollbacks or saturation and temporary unavailability. Active-active does not eliminate coordination overhead or internal single-writer behavior, and it does not provide unlimited or lock-free writes. The excerpt begins identifying critical applications with little tolerance for downtime as a use case, but ends before giving further detail or operational best practices. ### Source excerpt In MySQL Group Replication (MGR) or Group Replication, an active-active configuration allows multiple group members to accept concurrent write transactions. These writes are coordinated through a consensus-based group communication system (GCS) and validated via write-set certification to preserve global transactional consistency as defined by the Group Replication protocol. active-active mode is designed for write scalability. [...] The post Active-Active MySQL Group Replication Best Practices appeared first on Severalnines. ## Inside PostgreSQL: Architecture for HA, Speed & Reliability DevFeed: [Inside PostgreSQL: Architecture for HA, Speed & Reliability]() Original publisher: [Read original article]() Author: Abhimanyu Saharan Published: 2025-07-06T00:00:00Z Content type: article Language: en Sources: [Abhimanyu Saharan]() Topics: [PostgreSQL](), [Availability](), [Resilience](), [data]() Tags: [architecture](), [developers](), [ha](), [high-availability](), [integrity](), [performance](), [postgresql](), [resilience](), [software-engineering]() ### AI overview An overview of PostgreSQL architecture focused on high availability, data integrity, resilience, and performance. ### Source excerpt Explore PostgreSQL's architecture with a focus on high availability, data integrity, resilience, and performance; ideal for developers, DBAs, and tech leads. ## Automating Keycloak Deployments for Fun and Profit DevFeed: [Automating Keycloak Deployments for Fun and Profit]() Original publisher: [Read original article]() Author: brakmic Published: 2024-12-24T22:31:29Z Content type: tutorial Language: en Sources: [Harris Brakmic - Coding]() Topics: [Keycloak](), [Kubernetes](), [Software Testing](), [sealed secrets](), [ingress-nginx](), [certificates]() Tags: [automated](), [based](), [bash](), [certificate](), [charts](), [coding](), [debian](), [deploy](), [deployment](), [deployments](), [development](), [devops](), [ha](), [helm](), [high-availability](), [iam](), [java](), [keycloak](), [kubernetes](), [local](), [postgresql](), [practical](), [production](), [sealed-secrets](), [setup](), [testing]() ### AI overview The article sets up a realistic local Keycloak development and test environment on Kubernetes, using a Certificate Manager, Sealed Secrets, and highly available PostgreSQL. It offers two redeployment paths--a bash script or Helm charts--and assumes the miniDevOps Docker image, which includes tools such as Helm, Kind, and kubectl. The excerpt begins by running that image interactively with access to the host Docker socket and network, a session-file mount, and port 443 forwarded for Keycloak's Nginx Ingress, which uses self-signed certificates. The author says another Linux distribution with bash or a compatible shell can be used instead. The supplied text ends during the Docker command explanation, so later deployment steps are not available here. ### Source excerpt This article will be a practical one as I intend to showcase a fully automated setup of Keycloak for local testing. However, unlike so many examples out there, this article aims to deploy a production-level Keycloak deployment that uses a Certificate Manager, Sealed Secrets, and PostgreSQL HA (high-availability variant). The goal is to create a [...] ## Tutorial: Building a Highly Available PostgreSQL Cluster with etcd, Patroni, HAProxy, and keepalived DevFeed: [Tutorial: Building a Highly Available PostgreSQL Cluster with etcd, Patroni, HAProxy, and keepalived]() Original publisher: [Read original article]() Author: Techno Tim Published: 2024-12-07T13:00:00Z Content type: tutorial Language: en Sources: [Techno Tim]() Topics: [PostgreSQL](), [Tutorial](), [Database]() Tags: [clustering](), [ha](), [patroni](), [postgres](), [postgresql](), [production](), [self-hosted](), [tutorial]() ### AI overview A tutorial for building a highly available and fault-tolerant PostgreSQL cluster with etcd, Patroni, HAProxy, and keepalived. It covers PostgreSQL node setup, certificate-based communication, etcd configuration, and cluster verification. ### Source excerpt Today is the day that you start running PostgresSQL in a cluster! In this tutorial we'll be setting up a production ready Postgres cluster that's highly available and fault tolerant using PostgreSQL, etcd, Patroni, HA Proxy, and keepalived. This resilient combination will ensure that you can always reach your database even when a node in the cluster goes down! 📺 Watch Video Nodes # ha pr... ## Limitations of High Availability in Stateful Firewall Clusters DevFeed: [Limitations of High Availability in Stateful Firewall Clusters]() Original publisher: [Read original article]() Published: 2024-04-10T05:59:00Z Content type: opinion Language: en Sources: [ipSpace]() Topics: [Firewall](), [Availability](), [BGP](), [Network]() Tags: [bgp](), [failover](), [firewall](), [ha](), [high-availability](), [stateful]() ### AI overview The article examines single-control-plane high-availability designs for stateful firewall clusters. It explains how synchronized sessions and forwarding state can preserve traffic through failover, while BGP Graceful Restart can keep peers forwarding as the new primary rebuilds its control plane. It argues that the shared control-plane design retains potential single points of failure and downtime. ### Source excerpt Dmitry Perets wrote an excellent description of how typical firewall cluster solutions implement control-plane high availability, in particular, the routing protocol Graceful Restart feature (slightly edited): Most of the HA clustering solutions for stateful firewalls that I know implement a single-brain model, where the entire cluster is seen by the outside network as a single node. The node that is currently primary runs the control plane (hence, I call it single-brain). Sessions and the forwarding plane are synchronized between the nodes. Read more ... ## How to natively deploy Flink on Kubernetes with High-Availability (HA) DevFeed: [How to natively deploy Flink on Kubernetes with High-Availability (HA)]() Original publisher: [Read original article]() Published: 2021-02-10T00:00:00Z Content type: tutorial Language: en Sources: [Apache Flink]() Topics: [Apache Flink](), [Kubernetes](), [Availability](), [Deployment & Scaling](), [Streaming]() Tags: [deployment-scaling](), [flink](), [ha](), [high-availability](), [how-to](), [kubernetes](), [streaming]() ### AI overview A hands-on tutorial explaining how to deploy Apache Flink applications natively on Kubernetes, including Kubernetes integration, scaling and management, and high-availability architecture. ### Source excerpt Flink has supported resource management systems like YARN and Mesos since the early days; however, these were not designed for the fast-moving cloud-native architectures that are increasingly gaining popularity these days, or the growing need to support complex, mixed workloads (e.g. batch, streaming, deep learning, web services). For these reasons, more and more users are using Kubernetes to automate the deployment, scaling and management of their Flink applications. From release to release, the Flink community has made significant progress in integrating natively with Kubernetes, from active resource management to "Zookeeperless" High Availability (HA). ## Apache Airflow 2.0 is here! DevFeed: [Apache Airflow 2.0 is here!]() Original publisher: [Read original article]() Author: Apache Airflow Published: 2020-12-17T00:00:00Z Content type: release Language: en Sources: [Apache Airflow Blog]() Topics: [airflow](), [API](), [REST API](), [OpenAPI Specification](), [Resilience]() Tags: [airflow](), [announce](), [apache-airflow](), [api](), [api-documentation](), [ha](), [improvements](), [openapi](), [release](), [rest-api](), [scheduler]() ### AI overview Apache Airflow 2.0.0 has been released with the TaskFlow API for authoring DAGs, a fully supported REST API with an OpenAPI specification, scheduler performance improvements, support for multiple highly available schedulers, and Task Groups for organizing tasks. ### Source excerpt I am proud to announce that Apache Airflow 2.0.0 has been released. The full changelog is about 3,000 lines long (already excluding everything backported to 1.10), so for now I'll simply share some of the major features in 2.0.0 compared to 1.10.14: A new way of writing dags: the TaskFlow API (AIP-31) (Known in 2.0.0alphas as Functional DAGs.) DAGs are now much much nicer to author especially when using PythonOperator. Dependencies are handled more clearly and XCom is nicer to use Read more here: TaskFlow API Tutorial TaskFlow API Documentation A quick teaser of what DAGs can now look like: from airflow.decorators import dag, task from airflow.utils.dates import days_ago @dag(default_args={'owner': 'airflow'}, schedule_interval=None, start_date=days_ago(2)) def tutorial_taskflow_api_etl(): @task def extract(): return {"1001": 301.27, "1002": 433.21, "1003": 502.22} @task def transform(order_data_dict: dict) -> dict: total_order_value = 0 for value in order_data_dict.values(): total_order_value += value return {"total_order_value": total_order_value} @task() def load(total_order_value: float): print("Total order value is: %.2f" % total_order_value) order_data = extract() order_summary = transform(order_data) load(order_summary["total_order_value"]) tutorial_etl_dag = tutorial_taskflow_api_etl() Fully specified REST API (AIP-32) We now have a fully supported, no-longer-experimental API with a comprehensive OpenAPI specification Read more here: REST API Documentation. Massive Scheduler performance improvements As part of AIP-15 (Scheduler HA+performance) and other work Kamil did, we significantly improved the performance of the Airflow Scheduler. It now starts tasks much, MUCH quicker. Over at Astronomer.io we've benchmarked the scheduler--it's fast (we had to triple check the numbers as we don't quite believe them at first!) Scheduler is now HA compatible (AIP-15) It's now possible and supported to run more than a single scheduler instance. This is super useful for bot ## Customer Invisible Maintenance of the CSC Object Storage Servers DevFeed: [Customer Invisible Maintenance of the CSC Object Storage Servers]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-03-14T07:36:00Z Content type: article Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Load Balancing](), [Network](), [Domain Name System (DNS)](), [radosgw](), [ceph]() Tags: [bgp](), [ceph](), [cloud](), [configuration](), [cpouta](), [csc](), [customer](), [dns](), [exabgp](), [failover](), [ha](), [high-availability](), [linux](), [load-balancing](), [maintenance](), [network](), [network-interface](), [networking](), [node](), [object-storage](), [radosgw](), [servers](), [storage]() ### AI overview CSC describes using ExaBGP to keep Object Storage reachable during server maintenance or failure. Each Linux server announces two IP addresses through a dummy network interface, and the service DNS name points to those addresses. Round-robin DNS distributes traffic; BGP routing is intended to make an address reachable through the other node if one server goes down. CSC chose ExaBGP for its recommendation by the organization's network team, low resource use, and few dependencies; the excerpt mentions BIRD and Quagga but says CSC did not try them. The excerpt ends mid-discussion, so it does not establish further configuration details or maintenance procedures. ### Source excerpt Hello! It's the CSC Pouta Cloud Team again! You may recognize us from other object storage films such as: http://pouta.blog.csc.fi/2018/02/admin-stories-implement-object-storage.html where we go through in excruciating detail how we configured CEPH RadosGW and why we configured it like we did http://pouta.blog.csc.fi/2018/01/objectively-speaking-in-cpouta.html where we announced object storage! In this episode we're going to talk a bit about how we implemented invisible(*) maintenance for our Object Storage customers. Configuration of ExaBGP with Object Storage CSC - IT Center for Science Ltd. has a close collaboration with the Finnish University and Research Network - FUNET, and because of that we are in a great position to do some fun network stuff. Actually, as long as your network has a BGP relationship with its internet provider you can also do what we have done. When we first launched Object Storage we just had a DNS entry pointing to two IP addresses. This gave us some load balancing and if we really wanted to we could take a node out of the DNS and do maintenance. But we wanted more! *ExaBGP enters the stage* In short we installed ExaBGP on our object storage linux servers, configured one dummy network interface per server and started to announce two IP addresses from each server. Then we pointed object.pouta.csc.fi DNS entry to these two IP addresses. The objective was to use round-robin DNS for load-balancing and BGP routing for High Availability. For failover this means that if one node goes down, the other IP is reachable on the other node and stuff will keep magically(*) working! There are some other BGP softwares out there, like BIRD or Quagga. Despite this, we never actually tried any other software since ExaBG has some great qualities such as: it came recommended by the network team at CSC who uses it for some services its low resource footprint and small number of software dependencies it is not a full routing suite - it is meant to be used for basi