Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
「ログディスク枯渇」アラートは、vCenter Server Appliance（VCSA）の/storage/logパーティション容量が逼迫した状態を指し、通常使用率75％を超えると通知されます。このパーティションにはSSO、VMwareディレクトリサービス、vpxdを含むvCenter基盤サービス全てのログが保存されます。
完全に容量が埋まると、データ破損を防ぐためvCenterはログ出力を停止し、基幹サービスをシャットダウンします。容量を解放または拡張しない限りvSphereクライアントにアクセスできなくなり、ESXiホストの管理が不可能になります。
容量圧迫の発生源を特定することが恒久的な解決策への第一歩です。vCenterの/storage/log領域が肥大化する主な要因は以下6点です。
vCenter 7.0、8.0に既知の不具合としてVMware認証基盤デーモン（vmafdd）の問題が存在します。
レジストリの不整合によりサービスがログローテーションルールを無視し、単一の巨大ログファイルがパーティション全体を消費する状況が発生します。
vCenter 8.0 Update3より前のバージョンでは、トラブルシューティング用に生成したサポートバンドルが自動的に消去されないケースがあります。これらのバンドルは圧縮ファイルでサイズが大きく、複数蓄積するとVCSAのログディスク枯渇を即時引き起こします。
vCenter 7.0 Update3cより古い環境では証明書検証エラーによりログ出力が無限ループする不具合があります。システムが重複するエラーログであるpod-startup.logを連続生成し、急速にディスクを埋め尽くします。
高負荷環境やAPI呼び出しが頻繁な環境ではlocalhost_access.logとcatalina.logのファイルサイズが大幅に増加します。
これらのファイルはシングルサインオン（SSO）およびルックアップサービス配下に格納されており、6.x、7.xの旧ビルドではローテーションが正常に動作しない場合があります。
/storage/logの標準割り当て容量10GBは、数百台のホストや数千台の仮想マシンを保有する大規模環境では容量不足となるケースが多いです。ログ出力詳細度が高い、またはオブジェクトの作成・削除が頻繁な環境では想定より早く容量上限に達します。
vCenterはインベントリと設定情報を保存する組み込みPostgreSQLデータベースを使用します。STIG強化ガイドラインに準拠した環境ではデータベース監査用にpgauditを有効化する場合があります。
設定に不備があると全てのデータベーストランザクションが記録され、ログパーティションが急速に埋まります。
ファイル削除またはディスク拡張を実施する前に、容量を消費しているファイルを正確に特定してください。診断なしで作業を実施すると、重要なシステムデータを誤って削除したり、根本的な恒久的不具合を見落としたりするリスクがあります。
ディスク操作やファイル削除を行う前に、VCSAの仮想マシンレベルスナップショットまたは最新のバックアップを取得してください。安全策なしでディスクサイズ変更を行うとパーティションテーブル破損が発生し、VCSAが起動不可になる恐れがあります。vCenterがリンクドモードグループに属する場合は作業前に復旧時の影響を確認してください。
管理画面が正常に開く場合は、https://<vcenter-FQDN>:5480にアクセスしvCenterアプライアンス管理インターフェース（VAMI）にログインします。
/storage/logと記載されたパーティションを確認。正常性ステータスが危険、または使用率75％超過であればアラートの原因と断定できます。VAMIが応答しない場合はrootユーザーでSSH経由VCSAにログインします。アプライアンスシェルが起動した場合はshellと入力しBashインターフェースに切り替えます。
人間が読みやすい単位でディスク使用量を表示するコマンドを実行します。
df -h
使用率78％以上のパーティションのみ抽出する場合は下記コマンドを実行します。
df -h | awk '0+$5 >= 78 {print}'
/storage/logが原因と確認できたら、下記コマンドで容量上位20件のファイル・ディレクトリを一覧表示します。
du -ah /storage/log/ | sort -h -r | head -n 20
数GB規模の巨大ファイル、または大量の重複する小型ログファイルが存在しないか確認します。
sort -rを使用しバイト数で比較してください。ディスクに空き容量が残っているにも関わらず埋まっていると認識されるケースはiノード枯渇が原因です。iノードはファイルシステムが各ファイルを管理するインデックス情報です。数百万個の微小ログファイルが存在すると、ディスク容量は残っていてもiノードが枯渇します。
iノード使用状況確認コマンド：
df -i
/storage/logのIUse％が100％または100％に近い数値の場合、iノード枯渇が根本原因と判断できます。
手順4でiノード使用率が高いことを確認した場合、下記コマンドを実行しファイル数が最も多いディレクトリを特定します。
find /storage/log -type d -exec sh -c "echo -n '{}: '; ls -1 '{}' | wc -l" \; | sort -n -k 2
原因特定後、不要なログデータを削除するか、ストレージ容量を拡張する2通りの手法で問題を解決できます。診断結果に応じて適切な方法を選択してください。
vCenter 7、8系で発生するログディスク枯渇の多くはログのローテーション・圧縮処理が正常に動作しないソフトウェア不具合が起因します。作業実施前に下表を確認し、使用中のバージョンに既知の不具合が該当する場合は先に対応策を適用してください。
| vCenterバージョン | 既知の不具合内容 | 解決策 |
|---|---|---|
| vCenter 6.0 U3以前 | cloudvm-ram-size.logのローテーション処理が破損 | 最新6.0/6.5ビルドへアップグレード |
| vCenter 7.0 U1以前 | SSOログが圧縮されない | 7.0 U1以降へアップグレード |
| vCenter 7.0 U3c以前 | pod-startup.logの無限出力 | ナレッジベースの回避策適用、または7.0 U3cへアップグレード |
| vCenter 7.0 / 8.0 U1以前 | vmafdd.logのレジストリ不整合 | レジストリ修正（ナレッジベース318575） |
| vCenter 8.0 U3以前 | サポートバンドルが自動削除されない | 手動クリーンアップ、または8.0 U3へアップグレード |
古いローテーション済み圧縮アーカイブファイルを削除し、即時容量を確保する手法です。削除対象は拡張子.gz、.zip、.log.1の圧縮・世代分けされたアーカイブファイルのみに限定してください。.logの生ログファイルは絶対に削除しないでください。
find /storage/log -name "*.gz" -mtime +7 -type f -delete
rm -rf /storage/log/vc-support-bundles/*
service-control --stop --all && service-control --start --all
環境規模が標準10GBの割り当て容量を超過している場合、ディスク拡張が恒久的な解決策となります。
/usr/lib/applmgmt/support/scripts/autogrow.sh
仮想マシンスナップショットは簡易な保護手段ですが、正式なバックアップの代わりにはなりません。スナップショットはVCSAと同一のデータストアに保存されるため、今回解消しようとしているストレージ障害でスナップショットが破損する可能性があります。本番vCenter環境ではディスク・ファイル操作を実施する前に、独立した信頼性の高い復旧ポイントを作成する専用バックアップ製品を使用してください。
i2BackupはVMwareネイティブ仮想化APIを活用しエージェントレスでVMバックアップを実行するエンタープライズ向けバックアップソリューションで、VCSA本体にエージェントをインストールする必要がありません。
作業実施前に
ディスクサイズ変更やファイル削除を行う前に、Info2soft製i2BackupでVCSAの完全バックアップを取得してください。対応作業中に障害が発生した場合、正常な復旧ポイントが存在するかどうかで短時間復旧とvCenterの再構築の分かれ目となります。
Q1：/storage/log配下のファイルを削除しても安全ですか？
削除対象ファイルによります。拡張子.gz、.zip、.log.1の圧縮アーカイブファイルは削除しても問題ありません。.logの生ログファイルは絶対に削除しないでください。実行中のサービスが異常停止し、vCenterの予期せぬ動作不良を引き起こします。
Q2：SSHアクセスなしでログディスク枯渇を解消できますか？
基本的に不可能です。VAMIはディスク使用量の確認機能のみ提供し、ログファイル削除やパーティション拡張のツールは搭載されていません。
本ガイドに記載のクリーンアップ・ディスク拡張作業にはSSHアクセスが必須です。SSHが無効化されている場合はVAMIの「アクセス」→「編集」から一時的に有効化してください。
Q3：ログディスク枯渇とSEATディスク枯渇の違いは何ですか？
/storage/logパーティションはvCenter各コンポーネントが出力するサービスログを保管します。SEAT（統計・イベント・アラーム・タスク）ディスク（通常/storage/seat）は過去のパフォーマンスデータとイベント履歴を格納します。
双方が独立して容量逼迫する可能性があり、症状は類似しますが解消作業の対象パーティション・ファイルが異なります。
Q4：/storage/archiveが常に100％使用状態ですが正常ですか？
正常な動作です。/storage/archiveパーティションはログアーカイブの一時保管領域として設計されており、常時100％近い使用率で運用される仕様です。システムが自動的に内部データを管理するため、容量100％でもアラート対象外、対応作業は不要です。
Q5：ディスク拡張による業務停止は発生しますか？
VCSAはホットディスク拡張に対応しているため、アプライアンスをシャットダウンせずに仮想ディスク容量を増やせます。ただしパーティションが完全に埋まりサービスが停止している場合は一時的な管理停止が発生します。
このような状況の場合は先に方法1で容量を確保してからディスク拡張を実施してください。
Q6：vCenterにアクセスできない（503エラー発生）場合の対応は？
vSphereクライアントで503エラーが表示されSSHも応答しない場合、ディスク容量フルによりアプライアンスの大半のサービスが停止しています。vCenter経由せずESXiホストのIPに直接vSphereクライアントを接続し、ESXi上のVMコンソールからVCSAに直接アクセスしてください。
コンソールからログイン後.gzファイルを削除し容量を確保し、service-control –start –allでサービスを再起動します。ディスクへの書き込みすら不可能なほど埋まっている場合はESXiホスト側でVMDKファイルの容量拡張を実施してからアプライアンスを復旧させます。
vCenterのログディスク枯渇は復旧可能な障害ですが速やかな対応が必須です。仮想マシン自体は稼働し続けていても、/storage/logがフルになると管理基盤がオフライン状態になります。
解消作業の流れは単純で、バックアップ取得→容量消費ファイル診断→使用バージョンに既知不具合が存在するか確認→ログクリーンアップまたはパーティション拡張のいずれかを実施、となります。標準10GBの容量では足りない大規模環境にはディスク拡張が長期的な解決策となります。
障害解消後はi2Backupなど専用ツールでVCSAの定期バックアップスケジュールを設定し、次回メンテナンス作業前に常に正常な復旧ポイントを確保できる体制を整備することを推奨します。
