はじめに
このドキュメントでは、Unified Computing System Manager(UCSM)3.1.3aリリースで導入されたData Management Engine(DME)データベース(DB)に関連する機能について説明します。
前提条件
要 件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- UCSMソフトウェアバージョン3.1.3a
- ファブリックインターコネクト(FI)6200シリーズおよび6332モデル
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
DMEは、システム状態情報を保持するUCSMソフトウェアアーキテクチャの主要コンポーネントです。情報は次の場所に保存されます
dme DBと呼ばれる組み込みデータベースの形式のローカルストレージFIデバイス。
ストレージハードウェアデバイスの障害により、データベースのデータ整合性が破損する可能性があります。UCSM 3.1.3aリリースでは、多数の新機能が追加されました
定期的なDBヘルスチェック、破損したDBのシームレスなリカバリ、およびDME DBの自動バックアップによるデータ保護を使用して、UCSMの復元力を高めるために追加されます。
UCSM DMEデータベースのヘルスチェック機能
データベースの定期的なヘルスチェック
UCS Managerは、定期的な間隔でDBのヘルスチェックを開始し、データの整合性を検証します。
このシステムでは、ユーザが手動でヘルスチェックを実行し、DBの整合性を確認することもできます。
デフォルト設定の確認
デフォルトでは、ヘルスチェックは12時間ごとに実行され、現在のステータスを表示するには、次のコマンドを使用します。
UCS # scope system
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 12
Last Integrity Check Time: 2017-05-07T14:42:47.019
Internal Backup Interval (days): 14
Last Internal Backup Time: 2017-04-28T14:52:12.648
UCS /system #
間隔を変更する
時間間隔を変更したり、ヘルスチェックを無効にしたりすることはできますが、デフォルト設定を変更しないことを強くお勧めします。
注意:これらの値は、デフォルトから変更しないことを強くお勧めします
この例では、間隔を12時間から48時間に変更しています。
UCS /system # set mgmt-db-check-policy health-check-interval 48
UCS /system* # commit-buffer
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 48
Last Integrity Check Time: 2017-05-07T14:42:47.019
Internal Backup Interval (days): 14
Last Internal Backup Time: 2017-04-28T14:52:12.648
ヘルスチェックを無効にするには、値を0に設定します。
手動でヘルスチェックを実行する
DBヘルスチェックを確認するには、次のコマンドを実行します。端末にメッセージが表示されない場合は、DBは良好な状態です。
UCS # scope system
UCS /system # start-db-check
UCS /system* # commit-buffer
また、エラーメッセージはプライマリFI DMEログファイル(UCSM techsupportバンドルの一部)に記録されます。
[prt:executeHealthCheck] Health Check complete with no corruption
このコマンドを使用すると、DBステータスをさらに確認できます。
UCS # scope system
UCS /system # show mgmt-db
Management Database Status:
Fabric Id Corrupted Count Last Occurrence Time
--------- ----------------------- --------------------
A 0 1970-01-01T00:00:00.000
B 0 1970-01-01T00:00:00.000
DBの破損:ユーザレベルの障害およびリカバリメカニズム
ヘルスチェック中にUCSMがDBの破損を検出すると、障害メッセージが生成されます。
INFOレベルのエラーは、1回だけ発生した場合に発生します。破損が2回以上発生している場合は、MAJORレベルのエラーがログに記録されます。このログを記録するには、さらに対処してCisco TACに連絡する必要があります。techsupportバンドルを収集します。
ucs /system # show fault
Severity Code Last Transition Time ID Description
--------- -------- ------------------------ -------- -----------
Info F1899 2017-04-28T01:09:23.332 263649 Management database corruption detected and recovered on Fabric Interconnect B. Number of corruption events: 1. Last corruption event timestamp: 2017-04-28T01:09:23.332
Major F1900 2017-05-02T00:52:07.846 263651 High number of management database corruption events on Fabric Interconnect A. Number of corruption events: 3. Last corruption event timestamp: 2017-05-02T01:06:06.387
リカバリメカニズム
UCSMは、サービスやデータプレーントラフィックに影響を与えずに破損を自動的に解決し、メモリからDBを上書きするか、ピアFIから正常なDBをコピーします。
| 破損イベント |
システム回復メカニズム |
| プライマリFi |
データベースはメモリ管理情報ツリー( MIT )からリカバリされます。 |
| 下位FI |
プライマリFIからデータベース・ファイルを取得 |
破損カウントのリセット
DBの破損は、手動でクリアされるまで続きます。たとえば、破損を解決するためのさらなる調査に基づいてFIハードウェアを交換した場合、このコマンドを実行して破損の障害カウントをリセットできます。
ucs-A # scope system
ucs-A /system # set mgmt-db-check-policy reset-corruption-count yes
ucs-A /system* # commit-buffer
定期的なバックアップ
データ保護を最大化するために、UCSMはUCSMコンフィギュレーション(DME DB)のフルステートバックアップを2週間ごとに実行します。このバックアップはリカバリに使用できます。
さらに、バックアップに良好な状態からの設定が含まれるように、DB整合性チェックが検証されます。
完全な状態のバックアップファイルは、各FIの/workspace/backupディレクトリに保存されます。
UCS # connect local-mgmt
UCS(local-mgmt)# dir backup/
1 1823454 Apr 28 14:53:23 2017 internalBackup.1493391132.tgz
バックアップジョブの間隔の変更
バックアップジョブの頻度は、1日から60日に変更できます。この例に示すように、値を28日に変更しました。
UCS # scope system
UCS /system # set mgmt-db-check-policy internal-backup-interval 28
UCS /system* # commit-buffer
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 24
Last Integrity Check Time: 2017-05-10T10:35:24.909
Internal Backup Interval (days): 28
Last Internal Backup Time: 2017-04-28T14:52:12.648
UCS /system #
関連情報