<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>Quorate — cluster engineering notes</title><description>Technical writing on Kubernetes, Ceph, PostgreSQL high availability, Slurm, GPU scheduling and infrastructure operations — including the parts where the conventional answer is wrong.</description><link>https://quorate.esgmedia.com.hk/</link><language>en-us</language><item><title>Backups you have never restored are not backups</title><link>https://quorate.esgmedia.com.hk/blog/backups-you-have-never-restored/</link><guid isPermaLink="true">https://quorate.esgmedia.com.hk/blog/backups-you-have-never-restored/</guid><description>The backup job going green every night is the most reassuring and least informative signal in infrastructure. Here is a method for turning it into a number you can quote, and the failure modes that hide behind a successful job.</description><pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate><category>Backup &amp; DR</category><category>Operations</category><category>Risk</category><author>Quorate</author></item><item><title>Kubernetes DRA: what actually changes for GPU clusters</title><link>https://quorate.esgmedia.com.hk/blog/kubernetes-dra-gpu-clusters/</link><guid isPermaLink="true">https://quorate.esgmedia.com.hk/blog/kubernetes-dra-gpu-clusters/</guid><description>Dynamic Resource Allocation replaces the device plugin model with something closer to how GPUs really work — but the operational questions it answers are narrower than the marketing suggests. Here is what changes, and what does not.</description><pubDate>Thu, 08 Oct 2026 00:00:00 GMT</pubDate><category>Kubernetes</category><category>HPC &amp; AI</category><category>GPU</category><author>Quorate</author></item><item><title>PostgreSQL HA: Patroni, repmgr and pgpool, compared honestly</title><link>https://quorate.esgmedia.com.hk/blog/postgresql-ha-patroni-repmgr-pgpool/</link><guid isPermaLink="true">https://quorate.esgmedia.com.hk/blog/postgresql-ha-patroni-repmgr-pgpool/</guid><description>These three tools are frequently compared as if they solve the same problem. They do not. One manages cluster state, one manages replication, and one is a router that people mistake for a failover mechanism.</description><pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate><category>Databases</category><category>PostgreSQL</category><category>High availability</category><author>Quorate</author></item><item><title>Ceph CRUSH map mistakes we keep finding</title><link>https://quorate.esgmedia.com.hk/blog/ceph-crush-map-mistakes/</link><guid isPermaLink="true">https://quorate.esgmedia.com.hk/blog/ceph-crush-map-mistakes/</guid><description>Durability in Ceph comes from the CRUSH map, not from the replication number. A three-replica pool whose copies land on three OSDs in the same host is a one-copy pool with extra ceremony. These are the configurations we find most often.</description><pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate><category>Distributed storage</category><category>Ceph</category><category>Failure domains</category><author>Quorate</author></item><item><title>Why your HA cluster has never actually failed over</title><link>https://quorate.esgmedia.com.hk/blog/why-your-ha-cluster-has-never-failed-over/</link><guid isPermaLink="true">https://quorate.esgmedia.com.hk/blog/why-your-ha-cluster-has-never-failed-over/</guid><description>Fencing is not a feature of high availability — it is the precondition for it. A cluster that cannot isolate a failed peer will, on a split, run both sides and write to the same data. Here is how to find out whether yours can.</description><pubDate>Fri, 18 Sep 2026 00:00:00 GMT</pubDate><category>High availability</category><category>Pacemaker</category><category>Failure domains</category><author>Quorate</author></item></channel></rss>