OCI Storage Software Appliance

解決する課題

Storage Software Appliance が解いていたのは、REST API を直接呼べない既存アプリから、ファイルプロトコルのままオブジェクトストレージへ保存する課題です。現在は旧アプライアンスを増設するのではなく、次の依存関係と未転送データを確定して移行します。

• 既存アプリは NFS マウント前提で動いており、HTTP/REST のオブジェクトストレージ API を呼ぶように書き換えたくない
• バックアップやアーカイブの保管先を、容量に上限のあるローカル NAS から大容量のオブジェクトストレージへ移したい
• 大量の非構造データ（ログ、メディア、解析結果など）をファイルとして読み書きしつつ、実体はクラウドに蓄積したい
• 直近よく使うデータには低レイテンシでアクセスしたいが、全データを手元に置く容量は確保できない

主要概念と用語

• Storage Software Appliance: NFSv4 のフロントとオブジェクトストレージのバックを橋渡しするソフトウェア本体。ホスト上で動かし、POSIX 準拠のファイルアクセスを提供する
• アプライアンスファイルシステム: アプライアンスが NFSv4 で公開する論理的なファイル共有。書き込まれたファイルが背後のオブジェクトストレージにオブジェクトとして保存される
• キャッシュ（ローカルキャッシュ）: 直近アクセスしたデータやアップロード待ちのデータを保持するホスト側のディスク領域。クラウドへの往復を減らし I/O を高速化する
• LRU（Least Recently Used）: キャッシュが閾値に達したときに、最も長く使われていないデータから追い出す管理ポリシー
• ピン留め（Pin）: 特定ファイルをキャッシュに固定し、明示的に解除するまで追い出されないようにする機能
• I/O モード: 非同期（asynchronous）と POSIX Sync の 2 モード。前者は書き込みを後追いでアップロードし、後者は整合性を優先する
• オブジェクトストレージ（バックエンド）: アプライアンスが HTTPS でデータを保存するクラウド側の実体

仕様・制限・クォータ

• クライアントとの接続は NFSv4（ファイルプロトコル）、背後は HTTPS でオブジェクトストレージにアクセスする。アプリから見ると普通のファイル共有として振る舞う
• 書き込まれたファイルは、アプライアンスのファイルシステムを経由してオブジェクトとして保存される。直接 REST API を呼ぶ必要はない
• キャッシュは LRU ポリシーで管理され、ファイルシステムの設定で指定したキャッシュ閾値を維持する。重要ファイルはピン留めで常駐させられる
• I/O は非同期と POSIX Sync の 2 モードがあり、非同期はアップロードがバックグラウンドで進むため、書き込み直後に必ずクラウドへ反映済みとは限らない
• 性能はアプライアンスホストの CPU・メモリ・ディスク・ネットワーク帯域に律速される。低帯域回線では大容量アップロードがボトルネックになりやすい
• ファイルロックや高頻度ランダム更新を多用するプライマリの業務 NAS 用途には不向き。バックアップ・アーカイブ・参照・連携といった用途が適する
• 対応 OS・最大ファイルサイズ・推奨スペックは旧環境を調査する手掛かりに留め、新規設計の要件として流用しない

内部の仕組み

旧 Storage Software Appliance は、フロント側が NFSv4、バック側がオブジェクトストレージの HTTPS API という二面を持つソフトウェアとして動作していました。クライアントがファイルを書くと、アプライアンスはまずローカルのファイルシステム／キャッシュに保存し、その実体をオブジェクトとしてクラウドへ送ります。読み取り時はキャッシュにあればそこから返し、なければクラウドから取得してキャッシュに載せる構造でした。

• 書き込みパス: NFSv4 書き込み、ローカルファイルシステム/キャッシュ、オブジェクトストレージへ HTTPS でアップロード
• 読み取りパス: NFSv4 読み取り、キャッシュヒットなら即応答、ミスならクラウドから取得してキャッシュに格納
• キャッシュ管理: 閾値超過時に LRU で古いデータを追い出す。ピン留めしたファイルは追い出し対象外
• 整合性モード: 非同期は遅延を抑える代わりに後追いでアップロード、POSIX Sync は整合性を優先する
• アプライアンス自体はステートを持つため、キャッシュ用ディスクの信頼性と容量が安定運用の鍵になる

横にスクロール

移行設計 / ベストプラクティス

• 新規書き込みを止める: 切り替え時間を決め、アプリケーションから旧NFS共有への書き込みを停止する
• 未転送分を確定する: 非同期モードの待ち行列を空にし、Object Storage側のファイル数・容量・検査値を記録する
• 旧依存を棚卸しする: マウントパス、利用者、POSIX操作、ロック、属性、読み書き比率、帯域、ピン留めを一覧化する
• 要件別に候補を試す: 同期、読み取りマウント、共有ファイル、API直接利用を分け、小さなデータセットで互換性と性能を測る
• 段階的に切り替える: 読み取り専用期間、差分同期、最終照合、利用者切り替えの順に進める
• 撤去条件を決める: 復旧試験と監視移管に合格し、切り戻し期限を過ぎてから旧ホストと資格情報を撤去する

旧構成の運用と移行監視

• アップロード未完了量（同期遅延）を最重要指標として確認し、移行前に未アップロードデータが残っていないことを確定する
• キャッシュ使用率を監視し、逼迫したらピン留め方針の見直しやディスク増設を検討する
• アプライアンスホストの CPU・メモリ・ディスク I/O・ネットワーク帯域をシステム指標として取得する
• 障害切り分けの基本は、まずクライアントからアプライアンスへの NFS 到達性、次にアプライアンスからオブジェクトストレージへの到達性と認証情報、最後にキャッシュディスクの空き、の順で確認する
• オブジェクトストレージ側のオブジェクト数・容量増加は監視や使用状況レポートで傾向を把握する

コスト

旧構成では、背後のオブジェクトストレージ利用とアプライアンスを動かすインフラがコストの中心でした。移行費用には、新旧二重保存、データ照合、回線、検証、旧ホストの保守リスクも含めます。

セキュリティ

• 保存時暗号化: 実体が置かれるオブジェクトストレージはデフォルトで暗号化され、Vault（KMS）の顧客管理キーも利用できる
• 転送時暗号化: アプライアンスからオブジェクトストレージへの通信は HTTPS で保護される。クライアントからアプライアンスへの NFS は内部ネットワークに閉じ、必要に応じて経路を分離・暗号化する
• 認証情報の管理: アプライアンスがオブジェクトストレージへアクセスするための資格情報を安全に保管し、権限は対象範囲への最小限に絞る
• ネットワーク分離: NFS は認証が弱いため、アプライアンスへの到達元を信頼できるネットワーク・送信元に限定する

関連サービス・比較

Storage Software Appliance と OCI Storage Gateway は、どちらもファイルアクセスをオブジェクトストレージへ橋渡しした旧製品です。Storage GatewayもEOLのため、移行先として比較する表ではなく、既存環境を識別するための相違として扱います。

ハンズオン / CLI例

廃止済みのアプライアンスを新規構築する手順は掲載しません。以下は旧マウントと保存先を読み取り中心で棚卸しする例です。実データの同期は小さな検証範囲で挙動を確認し、削除・上書き・属性の扱いを承認してから実行します。

# 旧NFSv4マウントの接続元・オプションを記録
nfsstat --mounts
findmnt -t nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS

# 同じファイルシステム内で件数と容量を採取
find /mnt/old-appliance -xdev -type f -printf '.' | wc -c
du -sx --block-size=1 /mnt/old-appliance

# Object Storage側の保存先とオブジェクトを読み取り専用で確認
NAMESPACE=$(oci os ns get --query 'data' --raw-output)
oci os object list \
  --namespace-name "$NAMESPACE" \
  --bucket-name "legacy-appliance" \
  --all \
  --query 'data[].{name:name,size:size}'