アプリをセルフホストし、データベースを別のNASで運用できますか？

アプリがTCP経由でデータベースサービスに接続する場合は問題ありませんが、汎用NASマウント上にデータベースの生ファイルを配置する設計は、別物であり、よりリスクが高くなります。

アプリケーションコンテナが一方のホームサーバーで動作し、PostgreSQLまたはMariaDBが別のホストで動作する場合や、データディレクトリをNFSまたはSMBに配置する場合、これは現実的な互換性の問題になります。まずは使い捨て可能なパスまたはアカウントから始め、以前の正常な状態を利用できるようにしておき、1回限りの接続テストではなく、元のワークロードに基づいて設計を評価してください。

サポートされるアーキテクチャとリスクの高いアーキテクチャを分ける

サポートされる構成は、独自の永続的なローカルストレージとネットワークプロトコルを備えたデータベースサーバーです。対照的に、もう一方の構成は、ネットワークファイルシステムのセマンティクスを通じてデータベースの生ファイルを公開するものです。どちらの構成を変更する前にも、バージョン、ID、アドレス、マウントパス、権限、現在確認できる状態を記録してください。

関連するPostgreSQLのストレージ要件が、最初の互換性の境界を定めます。これを使って主張の範囲を限定し、そのうえで、文書化された機能だけで設計全体が動作する証拠とみなすのではなく、この正確なホームサーバー上で同じ動作を検証してください。

テスト前に判定基準を記述します。成功とは、コミット済みトランザクションが永続化され、アプリが正常に再接続し、分離されたインスタンス上でバックアップを復元できることです。失敗には、fsyncまたはロック関連のエラーが発生する、障害中にリクエストがハングする、再接続後にデータベースが不整合な状態を返す、といった状況が含まれます。これにより、部分的な接続成功やコマンドの正常終了をエンドツーエンドの互換性と誤認するのを防げます。

正確なストレージとネットワーク経路を再現する

管理対象を1つに絞った判別テストを行います。NASホスト上に使い捨て可能なデータベースサービスをデプロイし、トランザクションのレイテンシを測定し、ネットワークを切断して、アプリの再接続とクラッシュリカバリを検証します。変更したコンポーネントだけがもっともらしい原因になるよう、クライアント、ワークロード、ファイルセット、アカウント、タイミングを一定に保ってください。

ネットワークファイルシステムの注意点を使って、この経路で重要となる2つ目の観測項目を選びます。トランザクションの両側を記録してください。DNSまたはルート、ネゴシエートされたプロトコル、プロセスID、終了ステータス、レイテンシ、転送バイト数、リカバリイベントなどです。

タイトルで示されているライフサイクルイベント（再作成、再接続、再マウント、再起動、フェイルオーバー、またはクライアント変更）の後にテストを繰り返します。古いソケット、キャッシュ、または認証情報が有効な間だけ動作する設計は、合格とはいえません。

トランザクションループ -> ネットワーク切断 -> 再接続 -> 整合性チェック -> 分離環境への復元

永続性、タイムアウト、リカバリの結果を解釈する

合格: コミット済みトランザクションが永続化され、アプリが正常に再接続し、分離されたインスタンス上でバックアップを復元できること。これを実現した正確なバージョンとトポロジーを保存してください。結論が、プロトコルのあらゆる実装ではなく、その条件に適用されるためです。

不合格: fsyncまたはロック関連のエラーが発生する、障害中にリクエストがハングする、再接続後にデータベースが不整合な状態を返す、といった状況です。どちらの主要な構成に原因があると判断する前に、DNS、MTU、ID、ファイアウォールの状態、ストレージレイテンシ、キャッシュされたセッションなど、共有依存関係を確認してください。

例外: データディレクトリをデータベースがサポートするストレージへ戻し、クライアントとサーバーのプロトコル層で分離を維持します。再現可能な観測によってどの境界が失敗したかを特定するまでは、権限を広げたり、元データを削除したり、通信セキュリティを弱めたり、動作中のストレージを置き換えたりしないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

復元グレードの確認後にのみ設計を維持する

観測された構成に対応するアクションだけを適用し、その後、元のワークロードを再実行します。関連する2回のライフサイクルサイクルと想定される同時負荷の下で、コミット済みトランザクションが永続化され、アプリが正常に再接続し、分離されたインスタンス上でバックアップを復元できる場合にのみ、設計を維持してください。

データベースダンプのワークフローを使って、最も近い依存ワークフローを検証します。新しい設計が有効な間も、そのアクセス、タイミング、リカバリの動作が変わらないことが必要です。

fsyncまたはロック関連のエラーが発生した場合、障害中にリクエストがハングした場合、または再接続後にデータベースが不整合な状態を返した場合は、停止して保存済みの状態に戻してください。別の回避策を追加するのではなく、タイムスタンプ、正確なバージョン、ルートまたはマウントの証拠、最小限の再現手順を添えてエスカレーションしてください。

NFSタイムアウトの動作と結果を照合し、リスクが別のネットワーク、ID、バックアップ、またはストレージ層に移っただけにならないようにします。

したがって、別のNASにデータベースを配置する場合の条件付きの回答は、冒頭の判断であり、無条件の「はい」ではありません。観測された合格状態が受け入れ基準となり、不合格状態がロールバックの基準となります。

よくある質問

リモートのPostgreSQLサーバーは、NFSにマウントしたデータディレクトリと同じですか？

いいえ。PostgreSQLのワイヤプロトコルはリモートクライアント向けに設計されていますが、データファイルには依然としてサポート対象のファイルシステムセマンティクスが必要です。

データベースのバックアップもNASに保存すべきですか？

バックアップがアプリケーション整合性を保っており、稼働中のデータベースとは独立して復元テストを行っているのであれば、保存できます。

許容すべきレイテンシはどの程度ですか？

アプリケーションのp95トランザクションレイテンシとタイムアウト予算を基準にしてください。pingが短いだけでは、コミットレイテンシが許容範囲内であることは証明できません。