この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco UCS® M5 サーバ HyperFlex M5を含む最新のサーバは、より高い帯域幅と低い電圧で動作するメモリ容量を提供します。
これらの傾向は、より高いアプリケーション メモリ要求と高度なマルチコア プロセッサとともに、メモリ エラーが発生する可能性を高めています。
従来、基本エラー訂正コード(ECC)機能とスクラブプロトコルは、メモリエラーの処理と軽減に高めていました。メモリおよびプロセッサテクノロジーの進化に伴い、RAS(信頼性、可用性、および有用性)機能は、新しい
課題に対処するために進化が求められています。その結果、Cisco UCS M5サーバは、サーバの復元力を向上させ、メモリの冗長性を高め、メンテナンスを合理化するために、いくつかの高度なメモリ RAS 機能を提供します。
このホワイトペーパーでは、Cisco UCS M5 サーバのメモリ エラーの分類と処理について説明します。シスコ
では、使用可能な拡張 RAS 機能を確認して、特定のアプリケーションに適した構成モードを決定することを推奨します。シスコでは、パフォーマンス、メモリ容量、およびエラー復元力の最適なバランスを実現するために、適応型ダブル デバイス データ修正(ADDDC)スペアリングを推奨しています。メモリ障害を許容できないミッション クリティカルなアプリケーションでは、メモリ ミラーリングを検討する必要があります。
メモリ エラーは、最新のサーバで最も一般的なタイプのエラーです。エラーは、メモリ ロケーションを読み取ろうとしたときに、読み取られた値が最後に書き込まれた値と一致しない場合に発生します。
メモリ エラーは、ソフトまたはハードのいずれかになります。一部のエラーは修正可能ですが、1つのメモリアクセスで複数のソフトエラーまたはハードエラーが同時に発生した場合は修正できません。
ソフト エラー
DRAM 内部または外部インターフェイスでの短時間の電気干渉に起因するエラーは、「ソフト」エラーと呼ばれ
ます。ソフト エラーは一時的なものであることが多く、常に繰り返されるわけではありません。読み取り処理中の干渉によってエラーが生じた場合、読み取りを再試行して、正しいデータが得られる可能性があります。メモリの内容を反転させる干渉によってエラーが生じた場合、メモリ ロケーションを書き換えることによりエラーが訂正され
ます。
ソフト エラー率は、特定のワークロードに固有の温度、高度、およびメモリ アクセス パターンの影響を受ける可能性があります。ワークロードはアプリケーションと直接相関しないことに注意してください。あるサーバのデュアルインラインメモリモジュール(DIMM)で修正可能なエラーをトリガーする可能性のある同じアプリケーションが、異なるデータセットでエラーを生成しない場合があります。メモリテスト アルゴリズムは、最悪の場合のワーク
ロードの動作を表すように調整されていますが、以前は検出されなかったエラーが実行時に発生する可能性があり
ます。シスコは、障害検出を改善するためにテスト アルゴリズムをレビューおよび改訂します。
ハード エラー
メモリ自身の物理的欠陥によるエラーは、従来から「ハード」エラーと呼ばれています。ハード エラーは、回路のブリッジや接合部のひび割れなど、部品の欠陥によって引き起こされる場合や、メモリ チップの欠陥による場合があります。影響を受けるメモリ コンテンツを書き換えて読み取りアクセスを試みても、ハード エラーは除去されません。エラーが存在しています。
訂正可能なエラー
エラーが検出されて修正された場合は、修正可能と見なされます。これは、読み取りを再試行するか、ECC データを使用して正しいメモリ内容を計算し、正しいデータをメモリに書き戻すことで実現できます。エラーが検出され、修正されると、Cisco®Integrated Management Controller(IMC)はシステム イベント ログにイベントを記録し
ます。
通常、修正可能なエラーはソフト エラーの結果です。修正可能なエラーが長期間にわたって同じメモリ内に存在する場合は、ハード エラーの可能性を示している可能性があります。
訂正不能な DIMM エラー
エラーは、プロセッサの ECC エンジンの訂正能力を超えると訂正不能と見なされます。
ランタイム中に修正不可能なエラーが発生すると、致命的なプロセッサ クラッシュまたはハングが発生し、サーバが停止します。これには、影響を受けるサーバの再起動と、エラーの根本にあるコンポーネントの交換が必要です。通常、これはメモリモ ジュールですが、根本原因はプロセッサ、プロセッサ ソケット、または DIMM ソケットに関連している可能性もあります。
修正不可能なエラーが発生し、サーバを再起動すると、Cisco UCS は影響を受ける DIMM を自動的にマッピングアウト(無効化)します。これにより、同じモジュールからの 2 つ目の障害を防止しながら、サーバをサービスに戻すことができます。
システムの電源投入テスト中にメモリ エラーが検出された場合は、修正不能と見なされ、モジュールがマッピングアウトされます。これは多くの場合、ハード エラーを示しており、モジュールを交換する必要があります。
初期の実稼働ランタイム エラーの最小化
一部のエラーは、DIMM ライフサイクルで予想よりも早く発生する可能性があります。前述のように、エラーは電気関連の障害または物理的な欠陥によって発生する可能性があります。一部の電気関連の障害は、デバイスを劣化させ、物理的な障害(ハード エラー)を引き起こす可能性があります。出荷前に、シスコはすべてのサーバで包括的なシステムレベルのテストを実施します。現場でのエラーを分析した結果、物理的な出荷と新しいエラーとの相関関係が示されました。この分析に基づいて、シスコは、サーバを実稼働環境に配置する前に、追加のメモリ診断を実行することが有益であると判断しました。これにより、最新メモリのテストと実稼働ワークロードの実行の間の時間間隔と潜在的なエラーが最小限に抑えられます。
同様に、シスコではメモリをアップグレードまたは交換した後、インストール エラーを特定し、潜在的な早期の障害を最小限に抑えるために、メモリ診断を実行することを推奨します。メモリのアップグレード中に発生する最も一般的なエラーは、DIMM の配置または取り付けの問題が原因です。
Cisco UCS サーバの ECC 機能
すべての Cisco UCS M5 サーバは、単一の DRAM チップ x4 に限定されたエラーを修正し、最大 2 つのデバイスでダブルビット エラーを検出できる ECC コード付きのメモリ モジュールを使用します。
スクラブ プロトコル
Cisco UCS M5 サーバは、デマンドおよびパトロール スクラブを利用して、修正可能なエラーに対処し、マルチビット エラーの可能性を軽減します。これらの機能は、すべての UCS M5 サーバでデフォルトで有効になってい
ます。
読み取りトランザクション中に修正可能なエラーが検出された場合、デマンド スクラブは修正されたデータをメモリに書き込みます。
パトロール スクラブは、すべてのメモリを 24 時間ごとにプロアクティブにスキャンします。デマンド スクラブを使用してメモリ位置を読み取り、検出されたエラーを修正します。これにより、エラーをプロアクティブに修正できるため、今後の読み取りイベント中に影響を受ける可能性が低くなります。
高度な RAS ポリシー
これまで、基本的な ECC 機能とスクラブ プロトコルは、メモリ エラーの処理と軽減に成功していました。メモリおよびプロセッサ テクノロジーの進化に伴い、RAS 機能は新しい課題に対処するために進化する必要があります。その結果、Cisco UCS M5 サーバは、サーバの復元力を向上させ、追加のメモリ冗長性オプションを提供し、メンテナンスを合理化するために、いくつかの高度なメモリ RAS ポリシーを提供します。
適応型二重デバイス データ修正(ADDDC スペアリング)
ADDDC スペアリングは、同じ領域に存在する 2 つの連続した DRAM 障害を修正できます。この機能は、修正可能なエラーを追跡し、内容を「バディ」キャッシュ ラインに予備コピーすることで、障害のあるビットを動的にマッピングします。このメカニズムは、処理されないままにしておくと修正不能になる可能性がある修正可能なエラーを軽減できます。この機能は仮想ロックステップを使用して、同じメモリ チャネル内のバディ ペアを割り当てます。スペアリング イベント後もエラーが続く場合、すべてのスペア ビットが消費されるまで、必要に応じてプロセスが繰り返されます。予備ビットは、ロックステップ プロセスによって生成された冗長 ECC ビットを再利用することで、バディ キャッシュ ライン ペアから取得されます。ADDDC イベントにアクションが必要な場合、Cisco UCS Manager と Cisco IMC は障害を生成します。ADDDC スペアリングでは、スペアのメイン メモリ領域の割り当てや使用は必要なく、オペレーティング システムで使用可能なメモリ全体が削減されることもありません。
この機能を有効にすると、わずかなメモリ遅延と帯域幅ペナルティが発生します。次の表に、ADDDC スペアリングが有効になっている場合の、メモリ集約型ベンチマーク ツールとさまざまなワークロードに対して測定された影響を示します。予備のバンクまたはランク領域が使用されると、潜在的なパフォーマンスへの影響が大きくなります。結果は実際のワークロードに依存します。
表 1. ADDDC パフォーマンス ペナルティ
% 帯域幅変更( '-' はドロップを示す) |
|
メモリ アクセス:すべての読み取り |
-4.5% |
メモリ アクセス:3 対 1 の読み取り/書き込み |
-1.3% |
メモリ アクセス:2 対 1 の読み取り |
-1.2% |
メモリ アクセス:1 対 1 の読み取り/書き込み |
+1.7% |
メモリ アクセス:ストリーミングトライアド |
-4.4% |
パフォーマンス:SPECrate2017_fp_base |
-3% |
パフォーマンス:SPECrate2017_int_base |
-2.3% |
ソフトウェア要件および構成要件
ADDDC スペアリングは、Cisco UCS Manager(UCSM)リリース4.0(4c)、Cisco IMC リリース4.0(4e)ではデフォルトで有効になっています。まれに ADDDC に影響する不具合(CSCvr79388)があるため、Cisco UCS Manager リリース 4.0(4h)および 4.1(1c)および Cisco IMC リリース 4.0(4k)および 4.1(1f)以降を推奨します。
RAS 構成向け BIOS ポリシーが [プラットフォームのデフォルト(Platform Default)] に設定されている UCSM 管理対象サーバでは、ADDDC スペアリングを有効にするために変更する必要はありません。
RAS 構成の BIOS ポリシーが [プラットフォームのデフォルト(Platform Default)] に設定されていない UCSM 管理対象サーバの場合、ADDDC を利用するには、ポリシーを [ADDDC スペアリング(ADDDC Sparing)](または [プラットフォームのデフォルト(Platform Default)])に変更する必要があります。
スタンドアロン(非 UCSM 管理型)サーバの場合、ADDDC スペアリングを有効にするために変更する必要はありません。
ADDDC スペアリング(UCSM)の有効化
● UCSM 管理対象サーバの場合、インストールされている UCS Manager のバージョンについては、 『UCS Manager サーバ管理ガイド』の「サーバ関連ポリシー、RAS メモリ BIOS 設定」という章を参照してくだ
さい。
● スタンドアロン Cisco UCS C シリーズ ラック サーバについては、『Cisco UCS C シリーズ統合管理コントローラ GUI 構成ガイド』のサーバの管理、BIOS 設定の構成」の章を参照してください。
メモリのミラーリング
メモリのミラーリングでは、システム メモリの一部を使用して、メモリの内容の複製コピーを保存します。ミラー メモリへの動的なフェールオーバー(再起動なし)は、オペレーティング システム(OS)およびアプリケーションに対して透過的であり、停止の原因となる修正不可能なエラーから保護します。
完全メモリ ミラーリングは、完全に冗長なシステム メモリを提供します。物理メモリ容量の半分は、メモリの内容の複製(ミラーリング)を保存するために使用されます。これにより、OS で使用可能なメモリが半分になります。この RAS 構成は、メモリ エラーによる個々のサーバ停止が不可能なシステムで考慮する必要があります。
表 2. フル メモリ ミラーリングのパフォーマンスの変更
パラメータ |
ミラーリング パフォーマンスのペナルティ(比率が有効/無効) |
メモリ アクセス:すべての読み取り |
1.00 |
メモリ アクセス:3 対 1 の読み取り/書き込み |
0.78 |
メモリ アクセス:2 対 1 の読み取り/書き込み |
0.68 |
メモリ アクセス:1 対 1 の読み取り/書き込み |
0.61 |
メモリ アクセス:ストリーミングトライアド |
0.66 |
パフォーマンス: SPECrate2017_fp_base |
0.88 |
パフォーマンス:SPECrate2017_int_base |
0.95 |
部分メモリ アドレス ミラーリングにより、ユーザーはミラーリングするメモリの部分を定義できます。このメモリ範囲は、OS とサーバ間のインタラクションによって決定可能で、重要なコードをより確実に動作させることができます。UCS Manager リリース 4.1 で展開されたこの機能は、大量のメモリを消費することなく信頼性を向上させることで、妥協点を確立します。部分ミラーリングには、ホストOSからのサポートが必要です。[1]
ソフトウェア要件および構成要件
部分ミラー モードは、Cisco UCS Manager リリース4.1(1a)、Cisco IMC リリース4.1(1c)で導入されま
した。
● UCSM 管理対象サーバの場合、インストールされている UCS Manager のバージョンについては、UCS Manager がインストールされているバージョンの「サーバ関連ポリシー、一部メモリのミラーリング」の章を参照してください。
● For standalone Cisco UCS C-Series Rack Servers, consult the chapter titled “Managing the server, configuring BIOS settings” in the Cisco UCS C-Series Integrated Management Controller GUI Configuration Guide.
Post-Package Repair (PPR)
ポスト パッケージ修復(PPR)は、冗長 DRAM 行を活用して、DIMM 内の障害のあるメモリ領域を永続的に修復できます。この永続的な現場での修復により、DIMMを交換することなくハードエラーから迅速に回復できます。この修復アクティビティは、パフォーマンスや OS で使用可能な合計メモリには影響しません。修復を実行するには、システムで ADDDC イベントが発生し、少なくとも 1 回再起動する必要があります。
200 回の現場障害 DIMM と DRAM エラー ビットマップの分析に基づくと、モジュールの交換を必要とすることなく、DIMM の約 40% を修復できます。40 パーセントという数値は、修正可能なエラーとしてサーバに表示される基本的な DRAM 障害の数と、PPR を実行するためにシステムを再起動する速度によって異なります。
DRAM ビット マップのパレート
ソフトウェア要件および構成要件
PPR は、Cisco UCS Manager リリース4.1(1a)、Cisco IMC リリース4.1(1c)以降でデフォルトで有効になっています。PPR を有効にするには、ADDDC スペアリングが有効になっていることを確認します。
メモリ診断の実行方法
メモリ診断の実行は、使用されている UCS 管理モードによって異なります。UCSM 管理対象サーバの場合、UCS Manager にはメモリ診断機能が組み込まれています。スタンドアロン Cisco UCS C シリーズラックサーバの場合、Cisco.com ソフトウェア ダウンロードから UCS 診断ブート可能メディアを入手できます。
次の例に示すように、「Big Chunk」サイズのメモリ バタフライ パターンを 100 ループ実行することで、現場の経験にメリットがあることが示されています。24 個の DIMM 全体で 768 GB のメモリを搭載したサーバの場合、このテストには約 8 時間かかります。ランタイムは、ループ数とメモリ容量にほぼ比例して増加します。
UCSM 管理対象サーバの診断ポリシーテストの例
UCS メモリ診断の実行の詳細については、次のドキュメントを参照してください。
● UCSM 管理対象サーバの場合、インストールされている UCS Manager のバージョンについては、『UCS Manager サーバ管理ガイド』の「診断構成」の章を参照してください。
● スタンドアロン Cisco UCS C シリーズ ラック サーバについては、 『Cisco UCS サーバ診断ユーティリティ ユーザー ガイド』を参照してください。
Cisco UCS M5 サーバは、サーバの復元力を向上させ、冗長性を高め、メンテナンスを合理化するために、いくつかの高度なメモリ RAS 機能を提供します。
シスコでは、使用可能な拡張 RAS 機能を確認して、特定のアプリケーションに適した構成モードを決定することを推奨します。
シスコでは、パフォーマンス、メモリ容量、およびエラー復元力の最適なバランスを実現するために、ADDDC スペアリングを推奨しています。
メモリ障害を許容できないミッション クリティカルなアプリケーションでは、メモリ ミラーリングを検討する必要があります。
可能であれば、サーバを実稼働環境に配置する前にメモリ診断を実行することを推奨します。