高可用性デプロイ計画

計画の目的

この V2 計画は、オフラインまたはプライベート環境に論理的な Tier0 Enterprise Fleet Center をデプロイするためのものです。6 台のマシンが、業務、ミドルウェア、データベース、ストレージ、Agent の役割を分担します。ユーザーと Enterprise 内部サービスは常に固定 VIP アドレスに接続します。1 台のマシンまたは 1 つのプロキシに障害が発生した場合、Keepalived、HAProxy、repmgr、RustFS、Fleet Agent がそれぞれのレイヤーで引き継ぎます。

この計画は、同一ネットワークセグメント内の単一マシン障害からの復旧を対象にしています。これは Active/Standby の災害復旧設計であり、複数データセンター、合意ベースの選出、またはデータ損失ゼロを保証する厳密な高可用性クラスターではありません。

設計目標は次のとおりです。

現在の業務ノードに障害が発生した後、Fleet Center の入口を健全な Standby ノードへ移動できる。
PostgreSQL、Redis、RustFS は固定 VIP アドレスを使用し、バックエンドの役割が変わっても Enterprise の .env を変更しない。
App、Flow、Marimo、License などのローカル業務ファイルを Active から Standby へ同期できる。
1 つの Cluster License は 1 つの論理インストールに対応し、Enterprise が別ノードに切り替わっても再アクティベーションしない。
独立した deployer が 6 台の初期化、ロール割り当て、デプロイ、状態監視、フェイルオーバー検証を行う。
VIP フェイルオーバー、ファイル同期、独立 Redis インスタンス、データベースレプリケーション、オブジェクトストレージ冗長性を明確に分離する。

この計画は Fleet Center のみに適用されます。Branch Enterprise ノードは通常の単一マシンデプロイとしてインストールされ、この 6 台 Active/Standby 設計には参加しません。

全体トポロジー

主要なリクエスト経路は次のとおりです。

クライアント / 現場システム
    -> Business VIP :8088
    -> 現在の Active Enterprise (D / E / F)
    |-- PostgreSQL VIP :5432 -> D/E HAProxy -> A/B の現在の書き込み可能 Primary
    |-- Redis VIP      :6379 -> C または F の独立 Redis
    `-- RustFS VIP     :19000 -> A/B HAProxy -> C/D/E/F RustFS クラスター

4 つの VIP は業務設定内の固定入口です。Enterprise がノードを切り替えたり、ミドルウェアのバックエンドロールが変わったりしても、クライアントと Enterprise は接続アドレスを変更しません。

計画 IP アドレス

次のアドレスは例です。実装前に、現場の同一 IPv4 サブネット内の実アドレスに置き換えてください。4 つの VIP は DHCP、静的ホスト、または他の VRRP インスタンスで使用されていてはいけません。

名前	例 IP	説明
deployer-controller	`10.60.10.20`	独立 deployer。6 台の業務マシンには含めない
ent-ha-01 / A	`10.60.10.11`	PostgreSQL Primary と関連ロール
ent-ha-02 / B	`10.60.10.12`	PostgreSQL Standby と関連ロール
ent-ha-03 / C	`10.60.10.13`	Witness、Redis-1、RustFS-1
ent-ha-04 / D	`10.60.10.14`	初期 Active Enterprise と関連ロール
ent-ha-05 / E	`10.60.10.15`	Enterprise Standby と関連ロール
ent-ha-06 / F	`10.60.10.16`	Enterprise Standby と関連ロール
Business VIP	`10.60.10.101`	Enterprise 統一入口、デフォルト `8088`
PostgreSQL VIP	`10.60.10.102`	データベース統一入口、デフォルト `5432`
Redis VIP	`10.60.10.103`	Redis 統一入口、デフォルト `6379`
RustFS VIP	`10.60.10.104`	S3 統一入口、デフォルト `19000`

実装前に、業務 NIC 名、IPv4 プレフィックス、ゲートウェイ、DNS、NTP、ホスト名、SSH ユーザー、ディスクマウントポイント、ファイアウォール許可リストを確認してください。VIP、ノード IP、NIC をスクリプトで推測して本番に直接使用してはいけません。

6 台の役割

マシン	デフォルトでデプロイするコンポーネント	主な責務
A	PostgreSQL Primary、RustFS HAProxy、Keepalived	初期データベース Primary、1 番目の RustFS プロキシ候補
B	PostgreSQL Standby、RustFS HAProxy、Keepalived	ストリーミング Standby、2 番目の RustFS プロキシ候補
C	PostgreSQL Witness、Redis-1、RustFS-1	データベース Witness/状態記録、Redis と RustFS のデータノード
D	PG HAProxy、Keepalived、RustFS-2、Enterprise、Fleet Agent、rsync	初期業務 Active、1 番目の PostgreSQL プロキシ候補
E	PG HAProxy、Keepalived、RustFS-3、Enterprise、Fleet Agent、rsync	業務 Standby、2 番目の PostgreSQL プロキシ候補
F	Redis-2、RustFS-4、Enterprise、Fleet Agent、rsync	業務 Standby、2 番目の Redis インスタンス

この割り当ては単一マシン障害への耐性と、6 台全体のリソースバランスを目的としています。deployer はホスト名/IP アドレスの自然順でマシンを A-F に対応付け、デフォルトロールを選択しますが、最終割り当ては現場のディスク構成と障害ドメインに照らして確認する必要があります。

マシン構成チェックリスト

Enterprise 業務レイヤーは Single Active/Standby です。任意の時点で、Business VIP を保持するノードだけが業務リクエストを処理します。業務レイヤーの拡張は、1 台の業務ノードの CPU、メモリ、ディスクを増強する垂直拡張で行います。Enterprise ノード数を掛け算して同時処理能力を見積もらないでください。

マシン	ノード種別	vCPU	メモリ	基本ストレージ	ディスク推奨
A	PostgreSQL Primary ノード	8C	16G	1T	`/` は約 80G、残りは PostgreSQL データ、WAL、バックアップ staging 用
B	PostgreSQL Standby ノード	8C	16G	1T	`/` は約 80G、残りは PostgreSQL データ、WAL、バックアップ staging 用
C	Witness / ミドルウェアノード	4C	8G	500G	システム、Redis、RustFS データ用の固定マウントポイントを割り当てる
D	初期 Active Enterprise ノード	8C	32G	500G	システム、コンテナ、Enterprise 同期ファイル、RustFS データ用の固定マウントポイントを割り当てる
E	Standby Enterprise ノード	8C	32G	500G	D と同じ
F	Standby Enterprise ノード	8C	32G	500G	D と同じ

カテゴリー	台数	1 台あたり仕様	vCPU 小計	メモリ小計	ストレージ小計
PostgreSQL データベースノード	2	`8C / 16G / 1T`	16C	32G	2T
Witness / ミドルウェアノード	1	`4C / 8G / 500G`	4C	8G	500G
Enterprise 業務ノード	3	`8C / 32G / 500G`	24C	96G	1.5T
合計	6	-	44C	136G	4T

構成サマリー

Enterprise 統一接続設定

D、E、F は同じ Enterprise 構成を保持します。

依存先	構成方針
PostgreSQL	A/B ノード IP ではなく PostgreSQL VIP に接続する
Redis	C/F ノード IP ではなく Redis VIP に接続する
File storage	`FILESTORE_DRIVER=s3` を使用し、S3 endpoint を RustFS VIP に向ける
Fleet identity	3 ノードが 1 つの論理 `installationId` を共有し、各ノードは独自の `memberId` を持つ
Fleet Agent	各 Enterprise ノードで 1 つのプロセスレベル Fleet Agent を実行する
License	Business VIP 経由で 1 回だけアクティベートし、Bundle を HA fileset に含める

installationId と memberId はインストールプロセスで生成、永続化されます。運用者が手動で作成したり、マシン間で memberId をコピーしたりしないでください。

VIP と候補ノード

VIP	候補ノード	ヘルス判定	引き継ぎ結果
Business VIP	D, E, F	Fleet Agent readiness、業務コンテナ状態、同期 generation	Owner だけが Enterprise HA 業務グループを起動する
PostgreSQL VIP	D, E	HAProxy/Keepalived 状態。HAProxy は書き込み可能 Primary のみにルーティングする	Enterprise は同じデータベースアドレスを使い続ける
Redis VIP	C, F	Redis `PING` とローカルサービス状態	もう一方の独立インスタンスへ切り替わる。キャッシュ/セッションは失われる可能性がある
RustFS VIP	A, B	HAProxy と RustFS backend のヘルス	S3 アドレスを変えずにプロキシ入口だけが移動する

コンポーネントデプロイ設計

Enterprise、Fleet Agent、Business VIP

D、E、F は同じ完全な Enterprise オフライン ZIP をインストールする。
Fleet Agent はホストレベルのプロセスサービスであり、業務コンテナではない。
Keepalived は Business VIP を管理し、Fleet Agent readiness endpoint を呼び出してローカルノードが VIP を保持できるか判断する。
Business VIP Owner だけが業務グループを実行し、他の 2 台は Standby にとどまる。
VIP を失ったノードは業務グループを停止しなければならない。復旧したノードはまず Standby として再参加する。
EMQX は Single Active 業務グループの一部として実行する。Agent 制御外で再起動したり、3 台間で別の選出機構を作ったりしない。

PostgreSQL Primary/Standby、Witness、統一入口

A は Primary、B は Streaming Standby、C は repmgr Witness として開始する。
Witness はクラスター状態を記録し、障害判断に参加する。完全な業務データは保存せず、読み書きも処理しない。
Primary に障害が発生した場合、repmgr は健全な Standby を新しい Primary に昇格させる。
D/E HAProxy は 5432 トラフィックを現在の書き込み可能 Primary のみにルーティングする。
PostgreSQL VIP は D/E プロキシノード間を移動する。プロキシフェイルオーバーとデータベース Primary/Standby フェイルオーバーは分離されている。
受け入れでは「書き込み可能 Primary が 1 つだけであること」と「Standby が streaming を再開すること」の両方を証明する必要がある。

Redis 独立インスタンス

C と F はそれぞれ 1 つの standalone Redis インスタンスを実行する。
2 つの Redis は Sentinel、Cluster、Primary/Replica レプリケーションを構成しない。
Redis VIP は接続入口だけを切り替える。現在のインスタンスに障害が発生すると、VIP はもう一方の健全なインスタンスへ移動する。
Redis には失われてもよい、または再構築できるデータだけを保存する。切り替え後の空キャッシュや再ログインは設計境界内である。
将来 Redis が破棄できない状態を保存する場合は、独立インスタンス前提を維持せず、レプリケーション/仲裁設計へアップグレードする。

RustFS 4 ノードクラスター

C、D、E、F は 4 ノードの分散 RustFS オブジェクトストレージクラスターを構成する。
A と B の HAProxy は健全な RustFS backend へプロキシする。
RustFS VIP は A と B の間を移動する。Enterprise は常にこの VIP 経由で S3 にアクセスする。
単一 RustFS ノード障害はクラスター機構で処理し、単一プロキシ障害は VIP フェイルオーバーで処理する。
オブジェクトデータを rsync、ホットコピー、または RustFS マウントディレクトリの直接編集で同期しない。
RustFS のノード数、ディスク数、erasure coding の可用性境界は、デプロイされたバージョンのクラスター検査結果に従う。

App、Flow、Marimo、License ファイル同期

Fleet Agent は、PostgreSQL/RustFS に直接置けないが、新しい Active ノードに存在する必要があるローカル業務ファイルだけを同期します。

App runtime ディレクトリと node_modules
Flow、Marimo、Notebook、および関連するローカル runtime ファイル
License Bundle
現在の実装で明示的に登録されたその他の HA fileset

同期は、deployer が管理する業務ノード間の SSH trust 上で system rsync を使用します。各リリースは完全な generation/manifest を作成します。Standby ノードは generation が完全であることを確認してからのみ引き継げます。PostgreSQL データディレクトリ、Redis データディレクトリ、RustFS データディレクトリはこの同期範囲に含まれません。

接続方法とネットワーク基準

アクセス関係

Source	Target	Purpose
ユーザー / 現場システム	Business VIP	Web/API 業務アクセス
D/E/F Enterprise	PostgreSQL VIP	業務データベースの読み書き
D/E/F Enterprise	Redis VIP	キャッシュとセッション
D/E/F Enterprise	RustFS VIP	S3 オブジェクトの読み書き
Deployer controller	A-F	SSH、デプロイ、状態収集、運用
D/E/F	D/E/F	rsync/SSH ファイル同期
A/B/C	A/B/C	PostgreSQL streaming replication、repmgr、Witness 通信
RustFS members/proxies	C/D/E/F	RustFS クラスターと S3 backend 通信
同じ VIP を共有するノード	対応する候補ノード	VRRP advertisement と VIP 移動

ポートとプロトコル

ポートは、必要最小限の source-to-target 関係で許可してください。すべての管理ポートをユーザーネットワークへ直接公開しないでください。

Port / protocol	推奨許可範囲	用途
`22/TCP`	Deployer -> A-F; D/E/F 相互同期	SSH、デプロイ、rsync
`8088/TCP`	ユーザーネットワーク -> Business VIP	Enterprise 業務入口
`5432/TCP`	D/E/F -> PostgreSQL VIP; PG/proxy 内部アクセス	PostgreSQL、streaming replication、proxy
`6379/TCP`	D/E/F -> Redis VIP; health-check nodes -> C/F	Redis アクセスとヘルスチェック
`19000/TCP`	D/E/F -> RustFS VIP	Enterprise 固定 S3 入口
`9000/TCP`	A/B -> C/D/E/F; RustFS members	RustFS S3 backend/cluster 通信。バージョンごとに確認
`9001/TCP`	管理対象運用ネットワーク -> RustFS admin entry	任意の RustFS admin endpoint。ユーザーネットワークへ公開しない
`19731/TCP`	Localhost / Keepalived / 管理対象運用ネットワーク	Fleet Agent HTTP health/control interface
`18080/TCP`	運用ネットワーク -> deployer controller	Deployer HTTPS UI
`112/VRRP`	各 VIP の候補ノード	Keepalived VIP 移動。TCP/UDP ではなく IP プロトコル番号
`1883/8883`	現場デバイスネットワーク -> 業務入口。製品設定に従う	MQTT/MQTTS

フェイルオーバーと機能境界

障害シナリオ	期待される動作	境界
D Active 業務ノード障害	Business VIP が E または F に移動し、新しい Owner が readiness 通過後に業務グループを起動する	Standby 上で最新 HA fileset generation が完了している必要がある
PostgreSQL A Primary 障害	B が Primary に昇格し、PostgreSQL VIP は D/E proxy 経由で書き込み可能 Primary にルーティングし続ける	データ損失は streaming replication の状態に依存する
現在の Redis ノード障害	Redis VIP がもう一方の独立 Redis インスタンスへ移動する	キャッシュ/セッションは失われる可能性がある
RustFS proxy A または B 障害	RustFS VIP がもう一方の proxy へ移動する	RustFS データは 4 ノードクラスターの健全性に依存する
単一 RustFS データノード障害	冗長性条件が満たされていれば RustFS クラスターはサービスを継続する	実際の境界はディスク数と erasure coding 構成に依存する

ネットワーク分断、複数ノード同時障害、誤った VRRP priority、ディスク満杯、時刻ずれ、deployer 外の手動変更は通常の自動復旧保証の範囲外であり、運用手順で扱う必要があります。

バックアップ、監視、点検

PostgreSQL は独立した論理または物理バックアップとリストア検証が必要です。
RustFS は容量、ディスク、クラスターのヘルス監視が必要です。
Redis は将来のレプリケーション設計が導入されるまではキャッシュ/セッションとして扱う必要があります。
D/E/F の Fleet Agent と Keepalived 状態を監視する必要があります。
rsync generation lag を監視する必要があります。古い generation の Standby は業務トラフィックを引き継いではいけません。
定期フェイルオーバードリルには、Business VIP、PostgreSQL 昇格、Redis VIP 切り替え、RustFS proxy 切り替え、バックアップからの復元を含める必要があります。

本番前チェック

deployer controller から 6 台すべてへ SSH で到達できる。
ホスト名、IP アドレス、NIC 名、NTP、DNS、ファイアウォールルールが固定され、記録されている。
4 つの VIP が未使用で、候補ノード間を移動できる。
ディスクマウントポイントが固定され、再起動後も維持される。
Enterprise、PostgreSQL、Redis、RustFS、Keepalived、HAProxy、repmgr、Fleet Agent、rsync の構成が deployer により生成され、レビューされている。
Cluster License が Business VIP 経由で 1 回だけアクティベートされている。
本番トラフィック投入前にバックアップとリストア手順をリハーサルしている。

実装手順

deployer controller と 6 台のマシンを準備する。
IP、VIP、NIC、ディスク、DNS、NTP、SSH、ファイアウォール情報を確認する。
Enterprise オフラインパッケージと構成資料をアップロードする。
PostgreSQL primary/standby と Witness をデプロイする。
Redis 独立インスタンスと Redis VIP をデプロイする。
RustFS 4 ノードクラスターと RustFS VIP をデプロイする。
D/E/F に Enterprise、Fleet Agent、rsync fileset、Business VIP をデプロイする。
Business VIP 経由で License をアクティベートする。
機能検証とフェイルオーバードリルを実行する。
最終トポロジー、パスワード/キー、バックアップポリシー、監視対象、復旧手順を記録する。

受け入れ基準

機能受け入れ

ユーザーは Business VIP 経由で Enterprise にアクセスできる。
Enterprise は PostgreSQL VIP 経由でのみ PostgreSQL を読み書きする。
Enterprise は Redis VIP 経由でのみ Redis を使用する。
Enterprise は RustFS VIP 経由でのみ RustFS を使用する。
フェイルオーバー後、App、Flow、Marimo、Notebook、License ファイルが Active ノードに存在する。
Branch Enterprise は引き続き独立してインストールでき、この 6 台 HA グループには参加しない。

フェイルオーバードリル受け入れ

Active 業務ノードを停止する: Business VIP が健全な Standby に移動し、業務グループはそこだけで起動する。
PostgreSQL Primary を停止する: Standby が昇格し、PostgreSQL VIP は書き込み可能 Primary を指し続ける。
Redis VIP owner を停止する: Redis VIP がもう一方のインスタンスへ移動し、キャッシュ/セッション損失を許容する。
RustFS proxy owner を停止する: RustFS VIP がもう一方の proxy へ移動する。
RustFS データノードを 1 台停止する: オブジェクトアクセスは実際の RustFS 冗長性境界内で維持される。
障害ノードを復旧する: Standby または健全な member として復帰し、新しいデータやファイルを上書きしない。

リスクと現場確認項目

ネットワークが VRRP protocol 112 を許可するか。
4 つの VIP アドレスが本当に未使用か。
ディスクマウント構成と容量が実際のファイル保持と RustFS 冗長性要件を満たすか。
Redis が破棄可能なデータだけを保存しているか。
PostgreSQL replication lag とバックアップポリシーが業務 RPO を満たすか。
運用担当者が VIP フェイルオーバー、ファイル同期、データベースレプリケーション、オブジェクトストレージ冗長性の違いを理解しているか。

結論

現在の計画は、6 台のマシン、4 つの固定 VIP、Single Active Enterprise を中心にしています。業務入口、データベース入口、キャッシュ入口、オブジェクトストレージ入口を分離します。同一ネットワークセグメント内で一般的な単一マシン障害をカバーでき、フェイルオーバー後に接続構成を変更したり、License を再アクティベートしたり、App ファイルを手動コピーしたりする作業を大幅に減らします。

同時に、3 つの境界を受け入れる必要があります。Redis はデータをレプリケートせず、業務 fileset は非同期で同期され、ネットワーク分断には合意仲裁がありません。したがって、この計画は Fleet Center 6 台 Single Active Active/Standby 災害復旧計画 として定義するのが適切です。ゼロ中断、ゼロデータ損失、またはデータセンター間の厳密な高可用性を外部に約束してはいけません。