| Zero Data Loss Recovery Applianceオーナーズ・ガイド リリース12.1 E57738-09 |
|
 前 |
 次 |
この章では、Recovery Applianceラックのコンポーネントの保守方法について説明します。この付録には、次の項があります。
関連項目:
Recovery Applianceハードウェアの保守時には、次の注意に従ってください。
警告:
この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。
注意:
緊急時でないかぎり、Recovery Applianceの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。
キャビネットの前のドアと後のドアを閉めた状態にしてください。ドアを閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。
空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。
この項の内容は次のとおりです。
緊急時には、Recovery Applianceへの電源供給をすぐに停止します。次のような緊急時に、Recovery Applianceの電源切断が必要な場合があります。
地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合
システムから異常な騒音、臭い、または煙が発生した場合
人の安全を脅かす場合
緊急時には、次のいずれかの作業を実行します。
サーキット・ブレーカで電源を切断します。
コンピュータ・ルームで緊急時の電源切断スイッチを作動させます。
その後、システムの電源の復旧についてOracleサポート・サービスに連絡します。
緊急でない通常の状況下では、ソフトウェア・サービスおよびハードウェアの電源を正常に切断できます。
ラック・コンポーネントを停止する前にすべてのソフトウェア・サービスを停止します。
Recovery Applianceサービス、Oracle Databaseファイル・システム、Oracle Databaseおよびクラスタ・サービスを停止する必要があります。
Recovery Applianceサービスを停止する手順:
oracleとしてRecovery Appliance計算サーバーにログインします。
rasysユーザーとしてOracle DatabaseへのSQL接続を開きます。
$ sqlplus rasys
サービスのステータスをチェックします。
SQL> SELECT state FROM ra_server;
STATE
------------
ON
Recovery Applianceサービスを停止します。
SQL> exec dbms_ra.shutdown;
Oracle Databaseから切断します。
SQL> exit
Oracle Secure Backupが構成されている場合、次の手順を実行します。
rootユーザーに切り替えます。
Oracle Secure Backupの現在のステータスをチェックします。
# $GRID_HOME/bin/crsctl status res osbadmin
NAME=osbadmin
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on example01adm04
Oracle Secure Backupがオンラインである場合は、停止します。
# $GRID_HOME/bin/crsctl stop res osbadmin
oracleユーザーに切り替えます。
Oracle Databaseファイル・システム(DBFS)マウントのステータスをチェックします。
$ $GRID_HOME/bin/crsctl status res ob_dbfs rep_dbfs
NAME=ob_dbfs
TYPE=local_resource
TARGET=ONLINE , ONLINE
STATE=ONLINE on radb07, ONLINE on radb08
NAME=rep_dbfs
TYPE=local_resource
TARGET=ONLINE , ONLINE
STATE=ONLINE on radb07, ONLINE on radb08
DBFSを停止します。
$ $GRID_HOME/bin/crsctl stop res ob_dbfs rep_dbfs
CRS-2673: Attempting to stop 'ob_dbfs' on 'radb08'
CRS-2673: Attempting to stop 'rep_dbfs' on 'radb07'
CRS-2673: Attempting to stop 'ob_dbfs' on 'radb07'
CRS-2673: Attempting to stop 'rep_dbfs' on 'radb08'
CRS-2677: Stop of 'rep_dbfs' on 'radb07' succeeded
CRS-2677: Stop of 'ob_dbfs' on 'radb07' succeeded
CRS-2677: Stop of 'rep_dbfs' on 'radb08' succeeded
CRS-2677: Stop of 'ob_dbfs' on 'radb08' succeeded
DBFSマウントがオフラインであることを確認します。
$ $GRID_HOME/bin/crsctl status res ob_dbfs rep_dbfs
NAME=ob_dbfs
TYPE=local_resource
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE
NAME=rep_dbfs
TYPE=local_resource
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE
Oracle Databaseのステータスをチェックします。
$ srvctl status database -d zdlra5
Instance zdlra51 is running on node radb07
Instance zdlra52 is running on node radb08
Oracle Databaseを停止します。
$ srvctl stop database -d zdlra5
Oracle Databaseが停止していることを確認します。
$ srvctl status database -d zdlra5
Instance zdlra51 is not running on node radb07
Instance zdlra52 is not running on node radb08
rootユーザーに切り替えます。
クラスタのすべてのノード上のOracle Clusterwareスタックを停止します。
# $GRID_HOME/bin/crsctl stop cluster -all
CRS-2673: Attempting to stop 'ora.crsd' on 'zdlradb07'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on
'zdlradb07'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN2.lsnr' on 'zdlradb07'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'zdlradb07'
.
.
.
#
コマンドが失敗した場合は、-fオプションを使用してコマンドを再入力します。
計算サーバーごとに、次のコマンドを実行してOracle Cluster Ready Services (CRS)を停止します。
# $GRID_HOME/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'radb08'
CRS-2673: Attempting to stop 'ora.crf' on 'radb08'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'radb08'
.
.
.
CRS-2677: Stop of 'ora.crf' on 'radb08' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'radb08' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'radb08' has completed
CRS-4133: Oracle High Availability Services has been stopped.
必要に応じて、次の順序でハードウェアを停止または再起動します。
計算サーバー
ストレージ・サーバー
ラックおよびスイッチ
サーバーの電源を切断する前に、「Recovery Applianceの停止」の説明に従って、サーバー上で動作しているサービスを停止します。
計算サーバーまたはストレージ・サーバーを停止する手順:
例12-1 dcliユーティリティを使用したRecovery Applianceの電源の切断
すべての計算サーバー上のOracle Clusterwareを停止します。
# GRID_HOME/grid/bin/crsctl stop cluster -all
ラック内の他の計算サーバーを停止します。
# dcli -l root -g ra-adm02 shutdown -h -y now
前述のコマンドで、ra01adm02は2番目の計算サーバーの名前です。
すべてのストレージ・サーバーを停止します。
# dcli -l root -g cell_group shutdown -h -y now
前述のコマンドのcell_groupは、すべてのストレージ・サーバーをリストするファイルです。
ローカルの計算サーバーを停止します。
shutdown -h -y now
ラックの電源を切断します。
dcliユーティリティを使用して、複数のサーバーで同時にshutdownコマンドを実行します。コマンドによって電源が停止するサーバーからはdcliを実行しないでください。
次の例では、cell_groupというファイルにリストされたストレージ・サーバーのグループが停止します。
# dcli -l root -g cell_group shutdown -h -y now
例12-1に、dcliユーティリティを使用して同時に複数のサーバーを停止する場合のラックの電源切断手順を示します。コマンドは計算サーバーから実行されます。
最初にラック・コンポーネントに電源を投入してから、ソフトウェア・サービスを起動します。
ラック・コンポーネントに電源を投入するには、次のいずれかの方法を使用します。
コンポーネントの前面にある電源ボタンを押します。
Oracle ILOMにログインして、システムに電源を供給します。「リモート・サーバーの電源投入」を参照してください。
次の手順でラック・コンポーネントに電源を投入します。
ラックおよびスイッチ
スイッチが初期化するのを数分待ってから、ストレージ・サーバーを起動します。
ストレージ・サーバー
ストレージ・サーバーですべてのサービスが開始されるまで5から10分待ちます。必ず初期化が終了してから、計算サーバーを起動します。
計算サーバー
計算サーバーの電源が投入されると、オペレーティング・システムとOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。
Oracle ILOMインタフェースを使用すると、リモートでRecovery Applianceサーバーの電源を投入できます。Oracle ILOMにアクセスするには、Webコンソール、コマンドライン・インタフェース(CLI)、Intelligent Platform Management Interface (IPMI)またはSimple Network Management Protocol (SNMP)を使用します。
たとえば、IPMIを使用してサーバーra01cel01に電源を供給するには、次のようなコマンドでそのOracle ILOMを使用します。
# ipmitool -H ra01cel01-ilom -U root chassis power on
コマンドを使用するサーバーにIPMItoolがインストールされている必要があります。
関連項目:
Oracle ILOMを使用してサーバーの電源を投入する方法の詳細は、Oracle Integrated Lights Out Manager (ILOM) 3.0ドキュメントを参照してください。
rootとしてRecovery Appliance計算サーバーにログインします。
Oracle Cluster Ready Services (CRS)が実行されていることを確認します。
# $GRID_HOME/bin/crsctl status server
NAME=radb07
STATE=ONLINE
NAME=radb08
STATE=ONLINE
CRSが実行されていない場合は、起動します。
# $GRID_HOME/bin/crsctl start cluster -all
CRS-2672: Attempting to start 'ora.evmd' on 'radb07'
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'radb07'
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'radb08'
.
.
.
#
oracleユーザーに切り替えます。
Oracle Databaseが実行されていることを確認します。
$ srvctl status database -d zdlra5
Instance zdlra51 is not running on node radb07
Instance zdlra52 is not running on node radb08
Oracle Databaseが実行されていない場合:
Oracle Databaseを起動します。
$ srvctl start database -d zdlra5
Oracle Databaseが実行されていることを確認します。
$ srvctl status database -d zdlra5
Instance zdlra51 is running on node radb07
Instance zdlra52 is running on node radb08
データベース・ファイル・システム(DBFS)マウントがオフラインであることを確認します。
$ $GRID_HOME/bin/crsctl status res ob_dbfs rep_dbfs
NAME=ob_dbfs
TYPE=local_resource
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE
NAME=rep_dbfs
TYPE=local_resource
TARGET=OFFLINE, OFFLINE
STATE=OFFLINE, OFFLINE
DBFSがオフラインである場合は、起動します。
$ $GRID_HOME/bin/crsctl start res ob_dbfs rep_dbfs
CRS-2672: Attempting to start 'rep_dbfs' on 'zdlradb07'
CRS-2672: Attempting to start 'ob_dbfs' on 'zdlradb07'
CRS-2672: Attempting to start 'ob_dbfs' on 'zdlradb08'
.
.
.
$
RASYSユーザーとしてOracle Databaseに接続します。
$ sqlplus rasys
Recovery Applianceサービスのステータスをチェックします。
SQL> SELECT state FROM ra_server;
STATE
------------
OFF
サービスがオフである場合は、起動します。
SQL> exec dbms_ra.startup;
サービスが起動したことを確認します。
SQL> /
STATE
------------
ON
ストレージ・サーバーおよび計算サーバーのディスク・コントローラには、書込みパフォーマンスを高速化するバッテリ・バックアップ式の書込みキャッシュがあります。充電容量が低下して48時間以上電力の供給されないキャッシュ・データをバッテリで保護できない場合、書込みキャッシュが無効になり、ディスク・コントローラがライトスルー・モードに切り替わります。書込みパフォーマンスは低下しますが、データは失われません。
バッテリの充電容量は徐々に低下し、寿命は動作温度と反比例します。表12-1に、Recovery Applianceにおけるバッテリの寿命の最短のケースを示します。
表12-1 バッテリの寿命
| 注入温度 | バッテリの寿命 |
|---|---|
< 摂氏25度(華氏77度) |
3年 |
< 摂氏32度(華氏89.6度) |
2年 |
計算サーバーのバッテリの変更容量をモニターする場合:
# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep "Full Charge" -A5 | sort \ | grep Full -A1
次に、コマンドの出力例を示します。
Full Charge Capacity: 1357 mAh Max Error: 2 %
容量が800ミリアンペア時(mAh)を下回り、最大エラー率が10%を下回る場合は、予防的にバッテリを交換してください。容量が674mAhを下回るか、最大エラー率が10%を超えた場合は、ただちにバッテリを交換してください。
バッテリの温度をモニターする場合:
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep BatteryType; \ /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep -i temper
次に、コマンドの出力例を示します。
BatteryType: iBBU08 Temperature: 38 C Temperature : OK Over Temperature : No
バッテリの温度が摂氏55度以上である場合は、原因を特定し、問題を解決してください。
注意:
充電容量が不十分である、温度が高い、またはバッテリの交換が必要である場合などに、ストレージ・サーバーはアラートを生成します。
配電ユニット(PDU)は、Recovery Applianceがオンライン状態でも交換できます。ラック内の2番目のPDUは、ラック内のすべてのコンポーネントに電力を維持します。PDU-Aは、ラックを背面から見て左側、PDU-Bは右側にあります。
安全に手順を実行して可用性を損なわないために、PDUを交換する前に、次のガイドラインを確認してください。
PDU-Aの取外しまたは挿入中に、InfiniBandケーブルのラッチを解除すると、サーバーがクラスタから削除されるため、ラックが使用不可になります。通常、InfiniBandケーブルはラッチでしっかりと固定されているため、取扱いには注意してください。InfiniBandケーブルを無理な力で引っ張らないでください。
間違った電源フィードのフックを外すと、ラックが停止します。交換するPDUから電力ケーブルを電源までたどり、それらのフィードのみを抜いてください。
PDU交換部品の開封と再梱包は慌てずに行ってください。故障したユニットを同じように再梱包できるように、電源コードが梱包品の中でどのように巻かれているかに注意してください。
サイド・パネルを外すと、PDUの交換に必要な時間を短縮できます。ただし、サイド・パネルの取り外しは任意です。
コードレス・ドリルまたは電動ドライバを使用すると、PDUの交換に必要な時間を短縮できます。ハンド・レンチを使用する場合はさらに交換に時間をかけてください。ドライバにはTorx T30ビットおよびT25ビットが必要です。
電力ケーブルを移動するには、サーバーのケーブル・アームの取外しが必要になる場合があります。このような場合は、ケーブル・アームのクリップを外さなくても済むように、プラグ接続をねじり、ケーブル・アーム・コネクタを曲げます。ケーブル・アームのクリップを外す必要がある場合は、片方の手でケーブルを支えて電源コードを外し、ケーブル・アームをクリップで留めます。ケーブル・アームはつるしたままにしないでください。
T30ねじをL金具から外す場合は、PDUをラックから取り外すまで、PDUと金具を取り付けているT25ねじまたはナットを外さないでください。
PDUを交換するには、次のようにします。
PDUモニターを再起動してネットワーク設定を識別します。
カウント(5から0)が開始されるまで、リセット・ボタンを20秒押します。カウントダウン中にボタンを放し、再度押します。
モニターが再起動したら、LCDに表示される設定やファームウェア・バージョンなどを記録します。
PDUモニターが機能していない場合は、ネットワーク経由でPDUに接続してネットワーク設定を取得するか、ネットワーク管理者から取得します。
すべてのPDUブレーカをオフにします。
PDUの電源プラグをACコンセントから抜きます。
高くした床にラックがある場合は、床の切抜き部分から電源コードを出します。最初にラックを切抜き部分の上に動かすことが必要な場合もあります。
警告:
電源コードが頭上の配線を使用している場合は、人に落ちたり当たったりしない場所に置きます。
サイド・パネル・アクセスがなく、ラックにInfiniBandケーブル・ハーネスがないときにPDU-Bを交換する場合:
注意:
ケーブル・アームに取り付けられているケーブルのストラップを外さないでください。
四角のケーブル・アームをラックに留めているT25ねじを外します。
InfiniBandケーブルを邪魔にならないように中央に動かします。
サーバーおよびスイッチからPDUに接続されているすべての電力ケーブルを外します。電源ケーブルをグループの束にしてまとめておきます。
L金具の上部と下部からT30ねじを外し、ねじの使用位置をメモしておきます。
ラック・フレーム内のPDUの設置位置をメモしておきます。
ブレーカ・スイッチを使用できるようにするために、PDUは一般的にラック・フレームから後ろに1インチの位置にします。
PDUを斜めにしてラックから取り出します。
PDUを持ったまま(十分な空間がある場合は下ろし)、AC電源コードをラックに通します。ACコード・フラッシュをPDUの下部に固定するケーブル・タイを切断する必要が生じる場合があります。
ラックの下部または上部のできるかぎり近くにコードを引っ張ります。サーバーの間にはコンセント・プラグを配線用の穴に通すための空間があります。
小さい方のTorx T25ねじを外し、上部および下部のナットを緩めてPDUをL金具から取り外します。ナットを外す必要はありません。
L金具を新しいPDUに取り付けます。
新しいPDUをラックの横に置きます。
ACコードをラックに通してコンセントまで配線します。
注意:
ACコードを新しいPDUにケーブル・タイしないでください。
L金具が上部および下部のレールの上に来るまで、角度と位置を調整して、新しいPDUをラック内に置きます。
穴とスロットの位置を整列し、PDUがラック・フレームの後ろ約1インチの位置になるようにします。
コードのラベルに従って、電源コードを取り付けます。たとえば、G5-0は、PDUのPDUグループ5のコンセント0を示しています。
手順4でInfiniBandケーブル・ホルダを取り外した場合は、取り付けます。ねじがすり減らないようにするには、最初にホルダのねじを手で締めることをお薦めします。
AC電源コードをコンセントに接続します。
ブレーカをオンにします。
PDUモニターのケーブルを配線し、必要に応じてネットワークをプログラムします。
関連項目:
PDUモニターのプログラミングの詳細は、次のWebサイトのOracle Sun Rack II配電ユニット・ユーザーズ・ガイドを参照してください。
Oracle Integrated Lights Out Manager (Oracle ILOM)は無反応になる場合があります。その場合は、手動でOracle ILOMのサービス・プロセッサ(SP)をリセットする必要があります。
次の手順でOracle ILOMのリセット方法を示します。
関連項目:
次のWebサイトのOracle Integrated Lights Out Manager (ILOM) 3.0のドキュメント
http://docs.oracle.com/cd/E19860-01/E21549/bbgiedhj.html#z4000b491400243
SSHを使用してOracle ILOMに接続できない場合は、リモート・コンソールにログインします。
リモート・コンソールを使用してOracle ILOMをリセットするには、次のようにします。
SSHまたはリモート・コンソールのどちらを使用してもOracle ILOMに接続できない場合は、IPMItoolを使用します。
IPMItoolを使用してOracle ILOMをリセットするには、次のようにします。
物理ディスクの修理のために、Recovery Applianceの計算サーバーを停止する必要はありません。ラックの停止時間は必要ありませんが、個々のサーバーに停止時間が必要になり、一時的にクラスタ外にすることが必要な場合があります。
関連項目:
LEDの詳細は、「LEDステータスの説明」を参照してください
修理手順は、「計算サーバーの部品」を参照してください
LSI MegaRAID SAS 9261-8iディスク・コントローラは各計算サーバーのディスク・ドライブを管理します。ディスクにはRAID-5構成があります。各計算サーバーには4つのディスク・ドライブがあります。1つの仮想ドライブがRAIDセットを構成します。
計算サーバーが復旧不可能なダメージを負った場合は、そのサーバーを交換して、交換したサーバーを再イメージ化します。再イメージ化手順の実行中に、クラスタ内の他の計算サーバーは使用できます。クラスタに新しいサーバーを追加する際、作業中の計算サーバーから新しいサーバーにソフトウェアをコピーします。
次の作業は計算サーバーの再イメージ化の方法を示しています。
Oracleサポート・サービスでサポート・リクエストを開きます。サポート・エンジニアが障害が発生したサーバーを確認し、交換サーバーを送ります。サポート・エンジニアは、作業中の計算サーバーから実行したimagehistoryコマンドの出力結果も要求します。出力結果により、元の計算サーバーのイメージ化に使用され、システムのリストアに使用されるcomputeImageMakerファイルへのリンクが提供されます。
障害が発生した計算サーバーは、Oracle Real Application Clusters (Oracle RAC)から削除する必要があります。
関連項目:
計算サーバーのクラスタからの削除の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください
この手順で、working_serverはクラスタ内の動作している計算サーバー、failed_serverは交換される計算サーバー、replacement_serverは新規サーバーです。
障害が発生した計算サーバーをOracle RACクラスタから削除するには、次のようにします。
oracleユーザーとして、working_serverにログインします。
障害が発生したサーバーで実行されているリスナーを無効化します。
$ srvctl disable listener -n failed_server $ srvctl stop listener -n failed_server
インベントリからOracleホーム・ディレクトリを削除します。
$ cd $ORACLE_HOME/oui/bin $ ./runInstaller -updateNodeList ORACLE_HOME= \ /u01/app/oracle/product/12.1.0/dbhome_1 "CLUSTER_NODES=list_of_working_servers"
前述のコマンドのlist_of_working_serversは、ra01db02やra01db03などのクラスタで動作している計算サーバーのリストです。
障害が発生したサーバーがクラスタから削除された(つまり、ピン解除された)ことを確認します。
$ olsnodes -s -t
ra01db01 Inactive Unpinned
ra01db02 Active Unpinned
障害が発生した計算サーバーの仮想IP (VIP)リソースを停止して削除します。
# srvctl stop vip -i failed_server-vip PRCC-1016 : failed_server-vip.example.com was already stopped # srvctl remove vip -i failed_server-vip Please confirm that you intend to remove the VIPs failed_server-vip (y/[n]) y
クラスタから計算サーバーを削除します。
# crsctl delete node -n failed_server CRS-4661: Node failed_server successfully deleted.
次のようなエラー・メッセージを受領したら、投票ディスクを移動します。
CRS-4662: Error while trying to delete node ra01db01. CRS-4000: Command Delete failed, or completed with errors.
投票ディスクを移動するには、次のようにします。
投票ディスクの現在の場所を特定します。出力例では現在の場所がDBFS_DGであると示されています。
# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ----------
1. ONLINE 123456789abab (o/192.168.73.102/DATA_CD_00_ra01cel07) [DBFS_DG]
2. ONLINE 123456789cdcd (o/192.168.73.103/DATA_CD_00_ra01cel08) [DBFS_DG]
3. ONLINE 123456789efef (o/192.168.73.100/DATA_CD_00_ra01cel05) [DBFS_DG]
Located 3 voting disk(s).
投票ディスクを別のディスク・グループに移動します。
# ./crsctl replace votedisk +DATA
Successful addition of voting disk 2345667aabbdd.
...
CRS-4266: Voting file(s) successfully replaced
投票ディスクを元の場所に戻します。この例ではDBFS_DGに戻されています。
# ./crsctl replace votedisk +DBFS_DG
crsctlコマンドを繰り返してクラスタからサーバーを削除します。
Oracleインベントリを更新します。
$ cd $ORACLE_HOME/oui/bin $ ./runInstaller -updateNodeList ORACLE_HOME=/u01/app/12.1.0/grid \ "CLUSTER_NODES=list_of_working_servers" CRS=TRUE
サーバーが正常に削除されたことを確認します。
$ cluvfy stage -post nodedel -n failed_server -verbose Performing post-checks for node removal Checking CRS integrity... The Oracle clusterware is healthy on node "ra01db02" CRS integrity check passed Result: Node removal check passed Post-check for node removal was successful.
USBフラッシュ・ドライブを使用して、イメージを新しい計算サーバーにコピーします。
使用するUSBフラッシュ・ドライブを準備するには、次のようにします。
イメージを交換サーバー上にロードするには、次のようにします。
障害が発生した計算サーバーを新規サーバーに置き換えます。「ストレージ・サーバーの追加によるRecovery Applianceラックの拡張」を参照してください。
交換サーバーのUSBポートにUSBフラッシュ・ドライブを挿入します。
サービス・プロセッサを使用してコンソールにログインし、進捗状況をモニターします。
電源ボタンを押すか、Oracle ILOMを使用することで、計算サーバーの電源を投入します。
マザーボードを交換した場合:
BIOS中に[F2]を押します
「BIOS Setup」を選択します
USBフラッシュ・ドライブを最初に設定してから、RAIDコントローラを設定します。
そうでない場合は、BIOS中に[F8]を押して、ワンタイム起動選択メニューを選択してからUSBフラッシュ・ドライブを選択します。
システムを起動できるようにします。
システムが起動すると、CELLUSBINSTALLメディアが検出されます。イメージ化プロセスには、2つのフェーズがあります。両方のフェーズを完了してから次の手順に進んでください。
イメージ化プロセスの1つ目のフェーズでは、古いBIOSまたはファームウェアを識別し、イメージに対応するレベルにコンポーネントをアップグレードします。コンポーネントがアップグレードまたはダウングレードされると、システムは自動的に再起動します。
イメージ化プロセスの2つ目のフェーズでは、交換計算サーバーの工場出荷時のイメージをインストールします。
システムで要求された場合、USBフラッシュ・ドライブを取り外します。
[Enter]を押してサーバーの電源を切断します。
交換計算サーバーには、ホスト名、IPアドレス、DNSまたはNTP設定がありません。この作業は、交換計算サーバーの構成方法を示しています。
情報はRecovery Appliance内のすべての計算サーバーで同じである必要があります。IPアドレスはDNSから取得できます。初期インストールからインストレーション・テンプレートのコピーも取得する必要があります。
交換計算サーバーを構成するには、次のようにします。
注意:
計算サーバーがすべてのネットワーク・インタフェースを使用していない場合は、構成プロセスが停止し、いずれかのネットワーク・インタフェースが切断されているという警告が出されます。検出プロセスを再試行するかどうかの確認を求められます。環境に応じて、yesまたはnoと入力します。
収集ネットワークにボンディングが使用される場合、この時点でデフォルトのアクティブ/パッシブ・モードに設定されます。
Recovery Applianceの初期インストールでは各種ファイルが変更されました。
交換計算サーバー上のファイルを変更するには、次のようにします。
クラスタ内の動作している計算サーバーから、次のファイルの内容をレプリケートします。
/etc/security/limits.confファイルをコピーします。
/etc/hostsファイルの内容をマージします。
/etc/oracle/cell/network-config/cellinit.oraファイルをコピーします。
交換計算サーバーのBONDIB0インタフェースのIPアドレスでIPアドレスを更新します。
/etc/oracle/cell/network-config/cellip.oraファイルをコピーします。
10GbEなど、追加ネットワーク要件を構成します。
/etc/modprobe.confファイルをコピーします。
/etc/sysctl.confファイルをコピーします。
計算サーバーを再起動し、ネットワーク変更を有効にします。
ユーザー名を1つ以上のグループに追加して、交換計算サーバーのOracleソフトウェア所有者を設定します。所有者は通常、oracleユーザーです。
動作している計算サーバーから現在のグループ情報を取得します。
# id oracle
uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)
groupaddコマンドを使用して、グループ情報を交換計算サーバーに追加します。この例では、前の手順で識別されたグループが追加されます。
# groupadd –g 1001 oinstall # groupadd –g 1002 dba # groupadd –g 1003 oper # groupadd –g 1004 asmdba
動作している計算サーバーから現在のユーザー情報を取得します。
# id oracle uid=1000(oracle) gid=1001(oinstall) \ groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)
ユーザー情報を交換計算サーバーに追加します。この例では、前の手順のグループIDがoracleユーザーIDに追加されます。
# useradd -u 1000 -g 1001 -G 1001,1002,1003,1004 -m -d /home/oracle -s \ /bin/bash oracle
ORACLE_BASEおよびGrid Infrastructureディレクトリを作成します。この例では、/u01/app/oracleおよび/u01/app/12.1.0/gridが作成されます。
# mkdir -p /u01/app/oracle # mkdir -p /u01/app/12.1.0/grid # chown -R oracle:oinstall /u01/app
cellip.oraおよびcellinit.oraファイルの所有権を変更します。所有者は通常、oracle:dbaです。
# chown -R oracle:dba /etc/oracle/cell/network-config
リストアされた計算サーバーの安全を確保します。
$ chmod u+x /opt/oracle.SupportTools/harden_passwords_reset_root_ssh $ /opt/oracle.SupportTools/harden_passwords_reset_root_ssh
計算サーバーが再起動します。
rootユーザーとしてログインします。新しいパスワードを要求されたら、他の計算サーバーのrootパスワードと一致するように設定します。
Oracleソフトウェア所有者のパスワードを設定します。所有者は通常、oracleです。
# passwd oracle
oracleアカウントにSSHを設定します。
交換計算サーバー上のoracleアカウントに変更します。
# su - oracle
Oracleクラスタのサーバーをリストする交換計算サーバーのdcliグループ・ファイルを作成します。
交換計算サーバーでsetssh-Linux.shスクリプトを実行します。この例ではスクリプトがインタラクティブに実行されます。
$ /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s
スクリプトによってサーバーのoracleパスワードが要求されます。-sオプションにより、スクリプトはサイレント・モードで実行されます。
交換計算サーバー上のoracleユーザーに変更します。
# su - oracle
SSHの同等性を検証します。
$ dcli -g dbs_group -l oracle date
動作している計算サーバーから交換計算サーバーにカスタム・ログイン・スクリプトを設定またはコピーします。
$ scp .bash* oracle@replacement_server:.
前述のコマンドのreplacement_serverは、ra01db01などの新しいサーバーの名前です。
オラクル社では、Recovery Appliance用のソフトウェアのパッチ・バンドルを定期的にリリースしています。動作している計算サーバーにcomputeImageMakerファイルのリリースよりも新しいパッチ・バンドルがある場合、パッチ・バンドルを交換計算サーバーに適用する必要があります。
パッチ・バンドルが適用されたかどうか判断するには、imagehistoryコマンドを使用します。交換計算サーバーの情報を、動作している計算サーバーの情報と比較します。動作しているデータベースのリリースが新しい場合、ストレージ・サーバー・パッチ・バンドルを交換計算サーバーに適用します。
次の手順では、交換計算サーバーにOracle Grid Infrastructureをクローニングする方法について説明します。コマンドのworking_serverは動作している計算サーバー、replacement_serverは交換計算サーバーです。
関連項目:
クローニングの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。
Oracle Grid Infrastructureをクローニングするには、次のようにします。
rootとして、クラスタの動作している計算サーバーにログインします。
クラスタ検証ユーティリティ(cluvfy)を使用して、ハードウェアおよびオペレーティング・システムのインストールを検証します。
$ cluvfy stage -post hwos -n replacement_server,working_server –verbose
レポートの最後にPost-check for hardware and operating system setup was successfulのフレーズが表示されます。
ピア互換性を検証します。
$ cluvfy comp peer -refnode working_server -n replacement_server \ -orainv oinstall -osdba dba | grep -B 3 -A 2 mismatched
次に、出力の例を示します。
Compatibility check: Available memory [reference node: ra01db02] Node Name Status Ref. node status Comment ------------ ----------------------- ----------------------- ---------- ra01db01 31.02GB (3.2527572E7KB) 29.26GB (3.0681252E7KB) mismatched Available memory check failed Compatibility check: Free disk space for "/tmp" [reference node: ra01db02] Node Name Status Ref. node status Comment ------------ ----------------------- ---------------------- ---------- ra01db01 55.52GB (5.8217472E7KB) 51.82GB (5.4340608E7KB) mismatched Free disk space check failed
障害が発生したコンポーネントだけが物理メモリー、スワップ領域およびディスク領域に関連している場合は、手順を継続できます。
サーバーを追加するために必要な確認を行います。
GRID_HOME/network/admin/samplesディレクトリの権限が750に設定されていることを確認します。
計算サーバーの追加を検証します。
$ cluvfy stage -ignorePrereq -pre nodeadd -n replacement_server \
-fixup -fixupdir /home/oracle/fixup.d
障害が発生したコンポーネントだけがスワップ領域に関連している場合は、手順を継続できます。
次のように、投票ディスクにエラーが発生する場合があります。
ERROR:
PRVF-5449 : Check of Voting Disk location "o/192.168.73.102/ \
DATA_CD_00_ra01cel07(o/192.168.73.102/DATA_CD_00_ra01cel07)" \
failed on the following nodes:
Check failed on nodes:
ra01db01
ra01db01:No such file or directory
...
PRVF-5431 : Oracle Cluster Voting Disk configuration check failed
このエラーが発生する場合は、次の手順でaddnodeスクリプトの実行時に-ignorePrereqオプションを使用します。
交換計算サーバーをクラスタに追加します。
$ cd /u01/app/12.1.0/grid/addnode/
$ ./addnode.sh -silent "CLUSTER_NEW_NODES={replacement_server}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={replacement_server-vip}"[-ignorePrereq]
addnodeスクリプトでは、Oracle Universal InstallerによってOracle Clusterwareソフトウェアが交換計算サーバーにコピーされます。次のようなメッセージが表示されます。
WARNING: A new inventory has been created on one or more nodes in this session. However, it has not yet been registered as the central inventory of this system. To register the new inventory please run the script at '/u01/app/oraInventory/orainstRoot.sh' with root privileges on nodes 'ra01db01'. If you do not register the inventory, you may not be able to update or patch the products you installed. The following configuration scripts need to be executed as the "root" user in each cluster node: /u01/app/oraInventory/orainstRoot.sh #On nodes ra01db01 /u01/app/12.1.0/grid/root.sh #On nodes ra01db01
構成スクリプトを実行します。
端末のウィンドウを開きます。
rootユーザーとしてログインします。
各クラスタ・サーバーでスクリプトを実行します。
スクリプトの実行後、次のメッセージが表示されます。
The Cluster Node Addition of /u01/app/12.1.0/grid was successful. Please check '/tmp/silentInstall.log' for more details.
orainstRoot.shおよびroot.shスクリプトを実行します。
# /u01/app/oraInventory/orainstRoot.sh Creating the Oracle inventory pointer file (/etc/oraInst.loc) Changing permissions of /u01/app/oraInventory. Adding read,write permissions for group. Removing read,write,execute permissions for world. Changing groupname of /u01/app/oraInventory to oinstall. The execution of the script is complete. # /u01/app/12.1.0/grid/root.sh
/u01/app/12.1.0/grid/install/のログ・ファイルで、root.shスクリプトの出力結果を確認します。出力ファイルで、交換した計算サーバーのリスナー・リソースの起動が失敗したことが報告されます。これは予測される出力の例です。
/u01/app/12.1.0/grid/bin/srvctl start listener -n ra01db01 \ ...Failed /u01/app/12.1.0/grid/perl/bin/perl \ -I/u01/app/12.1.0/grid/perl/lib \ -I/u01/app/12.1.0/grid/crs/install \ /u01/app/12.1.0/grid/crs/install/rootcrs.pl execution failed
「クラスタの障害が発生した計算サーバーの削除」で停止したリスナー・リソースを再有効化します。
# GRID_HOME/grid/bin/srvctl enable listener -l LISTENER \ -n replacement_server # GRID_HOME/grid/bin/srvctl start listener -l LISTENER \ -n replacement_server
この項では、ストレージ・サーバーの保守を実行する方法について説明します。この付録には、次の項があります。
ストレージ・サーバーの保守を実行する場合、サーバーの電源切断または再起動が必要になることがあります。ストレージ・サーバーを停止する前に、サーバーのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。データベース可用性の継続は、影響するディスク・グループで使用されるOracle ASM冗長性のレベルと、同じデータのミラー・コピーを含む他のストレージ・サーバーでのディスクの現在のステータスによって異なります。
注意:
Recovery Applianceで保守中のセルが完全に機能するようになる前に、別のセルのディスクに障害が発生した場合、二重のディスク障害が発生する可能性があります。Recovery ApplianceがDELTAディスク・グループについてNORMALの冗長性でデプロイされており、このディスク障害が恒久的な場合、Recovery Appliance上のすべてのバックアップが失われます。
保守中のセルが長時間オフラインでないことを確認してください。そうしないと、リバランス操作が発生し、操作の完了に十分な領域がないために問題が引き起こされます。デフォルトで、リバランス操作はセルがオフラインになってから24時間後に開始されます。
ストレージ・サーバーの電源を停止するには、次のようにします。
関連項目:
My Oracle SupportのドキュメントID 1188080.1「ASMに影響を与えずにExadataのストレージ・セルを停止または再起動する手順」
正常に再起動できないストレージ・サーバーにアクセスするため、診断ISOの使用が必要になる場合があります。サーバーの起動後、ファイルをISOからサーバーにコピーすることで破損ファイルを置き換えます。
ISOは、すべてのRecovery Applianceサーバー上の/opt/oracle.SupportTools/diagnostics.isoにあります。
注意:
USBドライブの使用など、他の再起動方法が失敗した後でのみ、診断ISOを使用してください。この手順を開始する前に、アドバイスとガイダンスを得るためOracle Supportに連絡してください。
診断ISOを使用するには、次のようにします。
この項の内容は次のとおりです。
関連項目:
保守のベスト・プラクティスの詳細は、http://www.oracle.com/goto/maaのOracle Maximum Availability Architecture (MAA) Webサイトを参照してください。
ストレージ・サーバーの最初の2枚のディスクは、システム・ディスクです。ストレージ・サーバー・ソフトウェアのシステム・ソフトウェアは、各システム・ディスクに割り当てられます。システム・ディスクのこの割り当てられた部分は、システム領域と呼ばれます。システム・ディスクのシステム領域以外は、データ・パーティションと呼ばれ、通常のデータ・ストレージに使用されます。ストレージ・サーバーのその他のディスクはすべて、データ・ディスクと呼ばれます。
CellCLI LIST PHYSICALDISKコマンドで属性を確認して、物理ディスクを監視できます。たとえば、failedまたはwarning - predictive failureステータスの物理ディスクに問題が発生し、交換が必要と思われる場合です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、サーバー・ソフトウェアではなくドライブによって決定されます。
ストレージ・サーバーの物理ディスク・ステータス
Oracle ASMはハードウェア・エラーによる読取りエラーの障害範囲の修理を実行します。ディスクはオンラインのままで、アラートは送信されません。
ディスクに障害が発生した場合:
関連するOracle ASMディスクがFORCEオプションで自動的に削除され、Oracle ASMリバランスでデータの冗長性がリストアされます。
ドライブの青色のLEDと黄色のLEDが点灯し、この場合、ディスクの交換を進めてもかまいません。ドライブのLEDは純色のままになります。予測障害および低いパフォーマンスのLEDステータス・ライトの詳細は、「LEDステータスの説明」を参照してください。
サーバーによってアラートが生成され、それにはディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。
ディスクに障害ステータスがある場合:
物理ドライブのグリッド・ディスクに関連するOracle ASMディスクが自動的に削除されます。
Oracle ASMリバランスは予測障害ディスクから他のディスクにデータを再配置します。
ドライブの青色のLEDが点灯し、この場合、ディスクの交換を進めてもかまいません。
「障害のある物理ディスクの交換」を参照してください。
Oracle ASMが物理的に対処されたメタデータ・ブロックに関する読取りエラーを取得すると、ブロックはミラーリングされません。
Oracle ASMはディスクをオフラインにします。
Oracle ASMはFORCEオプションでディスクを削除します。
ストレージ・サーバー・ソフトウェアは、ディスクが交換できることを示すアラートを送信します。
ASRは、パフォーマンスの低いディスクをアクティブ構成から自動的に識別して削除します。次に、Recovery Applianceで一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。表12-2に、ディスク制限のトリガーとなる状況を示します。
表12-2 パフォーマンスの低いディスクを示すアラート
| アラート・コード | 原因 |
|---|---|
CD_PERF_HANG |
ディスクの応答停止 |
CD_PERF_SLOW_ABS |
サービス時間のしきい値が高い(スロー・ディスク) |
CD_PERF_SLOW_RLTV |
相対的サービス時間のしきい値が高い(スロー・ディスク) |
CD_PERF_SLOW_LAT_WT |
書込みでの長いレイテンシ |
CD_PERF_SLOW_LAT_RD |
読取りでの長いレイテンシ |
CD_PERF_SLOW_LAT_RW |
読取りおよび書込みでの長いレイテンシ |
CD_PERF_SLOW_LAT_ERR |
個々のI/Oでの頻繁な長い絶対レイテンシ |
CD_PERF_IOERR |
I/Oエラー |
問題が一時的なものであり、ディスクがテストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。そうでない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。「パフォーマンスの低い物理ディスクの取外し」を参照してください。
ディスク・ステータスの変更はサーバー・アラート履歴に記録されます。
MESSAGE IDdate_timeinfo "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer:nameModel Number:modelSize:sizeSerial Number:serial_numberFirmware:fw_releaseSlot Number:mCell Disk:cell_disk_nameGrid Disk: grid disk 1, grid disk 2 . . . Reason for confinement: threshold for service time exceeded"
次のメッセージがストレージ・セルのアラート・ログに入力されます。
CDHS: Mark cd health state change cell_disk_name with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
.
.
.
物理ディスクを交換したら、そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクを再作成する必要があります。これらのグリッド・ディスクがOracle ASMグループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクをディスク・グループに追加し直して、データをリバランスします。
ディスクを削除または追加すると、Oracle ASMリバランスが発生します。リバランスのステータスを確認する場合:
リバランス操作は正しく実行されましたか。
Oracle ASMアラート・ログを確認してください。
リバランス操作は現在実行中ですか。
GV$ASM_OPERATIONビューを確認してください。
リバランス操作は失敗しましたか。
V$ASM_OPERATION.ERRORビューを確認してください。
障害の発生した物理ディスクに複数のディスク・グループのASMディスクが含まれる場合、複数のディスク・グループのリバランス操作を同じクラスタの異なるOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作がキューに入れられます。
各ストレージ・サーバーのハード・ディスク・コントローラは、定期的にコントローラのバッテリの放電と充電を実行します。操作中は、書込みキャッシュ・ポリシーにより、ライトバック・キャッシュからライトスルー・キャッシュに変更されます。ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、ストレージ・サーバーの電源が落ちたり障害が発生したりすると、ライトバック・キャッシュ・モードの場合はデータ損失のリスクがあります。操作は、たとえば1月、4月、7月および10月の17日の01:00、のように3か月ごとに実行されます。
次の例は、論理ドライブのキャッシュ・モードのステータスに関してストレージ・サーバーによって生成されるアラート情報を示しています。
HDD disk controller battery on disk contoller at adapter 0 is going into a learn cycle. This is a normal maintenance activity that occurs quarterly and runs for approximately 1 to 12 hours. The disk controller cache might go into WriteThrough caching mode during the learn cycle. Disk write throughput might be temporarily lower during this time. The message is informational only, no action is required.
次のコマンドを使用して、定期的な書込みキャッシュ・ポリシーへの変更を管理します。
学習サイクルの開始時間を変更するには、次の例のようなコマンドを使用します。
CellCLI> ALTER CELL bbuLearnCycleTime="2013-01-22T02:00:00-08:00"
サイクルが終了すると、時間はデフォルト学習時間に戻ります。
次の学習サイクルの時間を確認する場合:
CellCLI> LIST CELL ATTRIBUTES bbuLearnCycleTime
バッテリのステータスを表示する場合:
# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0 BBU status for Adapter: 0 BatteryType: iBBU08 Voltage: 3721 mV Current: 541 mA Temperature: 43 C BBU Firmware Status: Charging Status : Charging Voltage : OK Temperature : OK Learn Cycle Requested : No Learn Cycle Active : No Learn Cycle Status : OK Learn Cycle Timeout : No I2c Errors Detected : No Battery Pack Missing : No Battery Replacement required : No Remaining Capacity Low : Yes Periodic Learn Required : No Transparent Learn : No Battery state: GasGuageStatus: Fully Discharged : No Fully Charged : No Discharging : No Initialized : No Remaining Time Alarm : Yes Remaining Capacity Alarm: No Discharge Terminated : No Over Temperature : No Charging Terminated : No Over Charged : No Relative State of Charge: 7 % Charger System State: 1 Charger System Ctrl: 0 Charging current: 541 mA Absolute state of charge: 0 % Max Error: 0 % Exit Code: 0x00
物理ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。したがって、できるだけ早く障害が発生したディスクを新しいディスクに交換します。
関連項目:
Oracle Databaseリファレンス(V$ASM_OPERATION ビューの詳細)
ディスクがwarning - predictive failureステータスのため、物理ディスクの交換が必要な場合があります。このステータスは、物理ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。
交換する前にドライブに障害が発生した場合は、「障害が発生した物理ディスクの交換」を参照してください。
障害発生前にディスクを交換するには、次のようにします。
関連項目:
V$ASM_OPERATION ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
不良物理ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。問題のあるディスクはシステムから取り外す必要があります。
不良ディスクの識別後に物理ディスクを削除するには、次のようにします。
この項では、フラッシュ・ディスクの保守を実行する方法について説明します。内容は次のとおりです。
Recovery Applianceではストレージ・サーバー間でデータがミラー化され、少なくとも2つのストレージ・サーバーに書込み操作が送信されます。1つのストレージ・サーバーのフラッシュ・カードに問題が発生すると、Recovery Applianceでは別のストレージ・サーバーのミラー化されたデータを使用して読取りおよび書込み操作が実行されます。サービスは中断されません。
フラッシュ・カードに障害が発生すると、ストレージ・サーバー・ソフトウェアは、残存ミラーからデータを読み取り、フラッシュ・キャッシュのデータを確認します。次に、障害が発生したフラッシュ・カードのあるサーバーにデータが書き込まれます。障害の発生時、障害が発生したフラッシュ・キャッシュ内での損失データの場所がソフトウェアによって保存されます。復元では次に損失データがミラー・コピーに置き換えられます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。
各ストレージ・サーバーには、4枚のPCIeカードがあります。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。
障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL
name: FLASH_5_3
diskType: FlashDisk
luns: 5_3
makeModel: "Sun Flash Accelerator F40 PCIe Card"
physicalFirmware: TI35
physicalInsertTime: 2012-07-13T15:40:59-07:00
physicalSerial: 5L002X4P
physicalSize: 93.13225793838501G
slotNumber: "PCI Slot: 5; FDOM: 3"
status: failed
カードのnameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。
サーバー・ソフトウェアによって障害が検出されると、フラッシュ・ディスク(およびそのディスク上のLUN)に障害が発生したことを示すアラートが生成されます。アラート・メッセージには、フラッシュ・カードのPCIスロット番号および正確なFDOM番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。
フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。障害が発生したディスクをできるだけ早く交換します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、サーバーの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによって関連するOracle ASMディスクがOracle ASMディスク・グループから自動的に削除され、Oracle ASMリバランスでデータの冗長性のリストアが開始されます。
関連項目:
部品番号情報およびサービス・ガイドのリンクは、「ストレージ・サーバーの部品」を参照してください
V$ASM_OPERATION ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
次のWebサイトの『Sun Flash Accelerator F80 PCIe Card User's Guide』
次のステータス・インジケータはアラートを生成します。アラートには、フラッシュ・ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。
同じSun Flash Accelerator PCIeカード上のフラッシュ・ディスクの1つに、障害が発生したか、問題があります。たとえば、FLASH5_3に障害が発生すると、FLASH5_0、FLASH5_1およびFLASH5_2がpeer failureステータスになります。
CellCLI> LIST PHYSICALDISK
36:0 L45F3A normal
36:1 L45WAE normal
36:2 L45WQW normal
.
.
.
FLASH_5_0 5L0034XM warning - peer failure
FLASH_5_1 5L0034JE warning - peer failure
FLASH_5_2 5L002WJH warning - peer failure
FLASH_5_3 5L002X4P failed
フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。
1つのフラッシュ・ディスクがpredictive failureステータスになると、データがコピーされます。ライトバック・フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクからグリッド・ディスクにデータがフラッシュされます。
フラッシュ・ディスクが極端に低いパフォーマンスを示しており、できるだけすぐに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、ストレージ・サーバーの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。
PCIeカードでデータ・キャッシュのサポートに使用されるキャパシタに障害が発生しており、カードをできるだけすぐに交換する必要があります。
特定の状態ステータスのフラッシュ・ディスクを識別するには、LIST PHYSICALDISKコマンドを使用します。この例では、warning - predictive failureステータスの問合せが行われます。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \ 'warning - predictive failure' DETAIL name: FLASH_5_3 diskType: FlashDisk luns: 5_3 makeModel: "Sun Flash Accelerator F40 PCIe Card" physicalFirmware: TI35 physicalInsertTime: 2012-07-13T15:40:59-07:00 physicalSerial: 5L002X4P physicalSize: 93.13225793838501G slotNumber: "PCI Slot: 1; FDOM: 2" status: warning - predictive failure
ASRは、パフォーマンスの低いディスクをアクティブ構成から自動的に識別して削除します。次に、Recovery Applianceで一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。表12-2に、ディスク制限のトリガーとなる状況を示します。状況は、物理ディスクおよびフラッシュ・ディスクの両方とも同じです。
問題が一時的なものであり、ディスクがテストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。そうでない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。
ディスク・ステータスの変更はサーバー・アラート履歴に記録されます。
MESSAGE IDdate_timeinfo "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer:nameModel Number:modelSize:sizeSerial Number:serial_numberFirmware:fw_releaseSlot Number:mCell Disk:cell_disk_nameGrid Disk: grid disk 1, grid disk 2 ... Reason for confinement: threshold for service time exceeded"
次のメッセージがストレージ・セルのアラート・ログに入力されます。
CDHS: Mark cd health state change cell_disk_name with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
.
.
.
サーバー・ソフトウェアがライト・バック・フラッシュ・キャッシュに使用されるフラッシュ・ディスクで予測障害またはピア障害を検出し、1つのFDOMだけに問題がある場合、サーバー・ソフトウェアは不良FDOMでデータを復元し、他の3つのFDOMでデータをフラッシュします。有効なグリッド・ディスクがある場合は、サーバー・ソフトウェアはディスクのOracle ASMリバランスを開始します。タスクが完了し、ディスクの準備完了がアラートで示されるまで、不良ディスクを交換することはできません。
Oracle ASMディスクが削除されている場合は、アラートが送信され、フラッシュ・ディスクを安全に交換できます。フラッシュ・ディスクをライトバック・フラッシュ・キャッシュに使用する場合、フラッシュ・ディスクによってキャッシュされるグリッド・ディスクがなくなるまで待機します。
注意:
PCIeカードはホット・プラガブルではないため、フラッシュ・ディスクまたはカードを交換する前にストレージ・サーバーの電源を切断する必要があります。
障害が発生したフラッシュ・ディスクを交換するには、次のようにします。
関連項目:
部品番号およびサービス・ガイドのリンクは、「ストレージ・サーバーの部品」を参照してください
V$ASM_OPERATION ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
次のWebサイトの『Sun Flash Accelerator F80 PCIe Card User's Guide』
注意:
PCIeカードはホット・プラガブルではないため、フラッシュ・ディスクまたはカードを交換する前にストレージ・サーバーの電源を切断する必要があります。
障害のあるフラッシュ・ディスクを交換するには、次のようにします。
次のように、新しいフラッシュ・ディスクがシステムによって自動的に使用されます。
フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。
グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。
グリッド・ディスクがOracle ASMディスク・グループの一部だった場合は、ディスクはディスク・グループに追加し直されます。ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、データがそこでリバランスされます。
1つの不良フラッシュ・ディスクが、他の正常なフラッシュ・ディスクのパフォーマンスを低下させることがあります。問題のあるフラッシュ・ディスクは取り外す必要があります。「パフォーマンスの低いフラッシュ・ディスクの識別」を参照してください。
パフォーマンスの低いフラッシュ・ドライブを取り外すには、次のようにします。
フラッシュ・ディスクがフラッシュ・キャッシュに使用される場合:
ディスクと同期されていないデータ(ダーティ・データ)が、フラッシュ・キャッシュからグリッド・ディスクにフラッシュされるようにします。
CellCLI> ALTER FLASHCACHE ... FLUSH
フラッシュ・キャッシュを無効化して、新しいフラッシュ・キャッシュを作成します。フラッシュ・キャッシュを作成する場合、不良フラッシュ・ディスクを使用しないでください。
CellCLI > DROP FLASHCACHE CellCLI > CREATE FLASHCACHE CELLDISK='fd1,fd2,fd3,fd4, ...'
グリッド・ディスクにフラッシュ・ディスクを使用する場合、不良ディスクの使用をすぐに停止するようOracle ASMに指示します。
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name FORCE
オフライン・パートナによって、FORCEオプションを使用したDROPコマンドが失敗する可能性があります。前述のコマンドが失敗した場合、次のいずれかを実行してください。
他のサーバーまたはディスクの障害を修正して、Oracle ASMデータ冗長性をリストアします。その後、DROP...FORCEコマンドを再試行してください。
データを不良ディスクからリバランスするようにOracle ASMに指示します。
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name NOFORCE
不良フラッシュ・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。フラッシュ・ディスクを安全に交換できるようになると、ストレージ・サーバー・ソフトウェアによって自動的にアラートが送信されます。
サービスを停止します。
CellCLI> ALTER CELL SHUTDOWN SERVICES ALL
前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、サービスが停止されます。
次のエラーは、サービスの停止によって冗長性の問題が引き起こされ、ディスク・グループが強制的にマウント解除される可能性を示しています。
Stopping the RS, CELLSRV, and MS services... The SHUTDOWN of ALL services was not successful. CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be forced to dismount due to reduced redundancy. Getting the state of CELLSRV services... running Getting the state of MS services... running Getting the state of RS services... running
このエラーが発生した場合は、Oracle ASMディスク・グループの冗長性がリストアされます。すべてのディスクのステータスが正常のときはコマンドを再試行します。
サーバーを停止します。
関連項目:
不良フラッシュ・ディスクを取り外して、新しいフラッシュ・ディスクと交換します。
サーバーの電源を投入します。サービスが自動的に開始されます。サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にオンラインになります。
新規フラッシュ・ディスクをフラッシュ・キャッシュに追加します。
CellCLI> DROP FLASHCACHE CellCLI> CREATE FLASHCACHE ALL
すべてのグリッド・ディスクがオンラインであることを確認します。
CellCLI> LIST GRIDDISK ATTRIBUTES asmmodestatus
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。
次のようにフラッシュ・ディスクが追加されます。
ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、計算サーバーおよびストレージ・サーバーのドライブ・トレイにあります。ディスク・コントローラBBUを停止時間なしで交換できます。次の手順では、ディスク・コントローラBBUを交換する方法について説明します。
注意:
この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。
各ストレージ・サーバーはソフトウェアのコピーをUSBスティックに保管します。システム構成が変更されるときは常にサーバーがUSBスティックを更新します。このUSBスティックは、ハードウェア交換またはソフトウェア障害の後のサーバーのリカバリに使用できます。システムをリストアするのは、システム・ディスクに障害が発生した場合、オペレーティング・システムに破損ファイル・システムがある場合、または起動エリアがダメージを負っている場合です。ディスク、カード、CPU、メモリーなどを交換して、サーバーをリカバリすることができます。USBスティックを別のサーバーに挿入すると、そのサーバーで古いサーバーが複製されます。
1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、ストレージ・サーバーのCELLBOOT USBフラッシュ・ドライブで提供されるレスキュー機能を使用します。
この項の内容は次のとおりです。
ストレージ・サーバーのレスキュー前に、そのサーバーに格納されているデータを保護するための手順を踏む必要があります。この手順は、システムが通常の冗長性または高い冗長性のどちらで設定されているかによって異なります。
通常の冗長性を使用している場合、サーバーにあるミラー・コピーは1つです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。
ミラー・コピーの複製を作成することをお薦めします。
ミラー・コピーのデータの完全なバックアップを作成します。
ただちにミラー・コピー・サーバーをオフラインにします。これによって、レスキューを始める前の新たなデータの変更を防ぎます。
この手順により、レスキュー・プロセス中は、障害が発生したサーバーのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。
Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスします。
関連項目:
タイマーのリセットの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
レスキュー手順を使用する前に、次の点に注意してください。
レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失うおそれがあります。レスキューを開始する前に、必ず適切な事前作業を済ませておいてください。「サーバーに通常の冗長性がある場合」または「サーバーに高い冗長性がある場合」を参照してください。
この手順を使用する場合は十分に注意し、プロンプトを確認してください。一部またはすべてのディスクのデータを損失してもかまわない場合にOracleサポート・サービスの支援だけでレスキュー手順を使用することが理想的です。
レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。
レスキュー手順は、最後の正常な起動中にサーバー上に存在したパッチを含めて、ストレージ・サーバー・ソフトウェアを同じリリースにリストアします。
レスキュー手順は次の構成設定をリストアしません。
アラート構成、SMTP情報、管理者の電子メール・アドレスなどのサーバー構成
ILOM構成。ただし、サーバー・ソフトウェアに障害が発生してもILOM構成は一般的に損われません。
リカバリ手順は次の構成設定をリストアします。
レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、このレスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。
レスキューが正常に完了したら、サーバーを再構成する必要があります。データを保存する場合は、セル・ディスクをインポートします。それ以外の場合は、新規のセル・ディスクおよびグリッド・ディスクを作成します。
関連項目:
CellCLIユーティリティを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください
注意:
データを損失しないように注意して、レスキュー手順に従います。
CELLBOOT USBフラッシュ・ドライブを使用してサーバーをレスキューするには、次のようにします。
注意:
機能が制限されたレスキュー・モードのLinuxログイン・シェルを入力できる追加オプションを使用できる場合があります。Oracleサポート・サービスから提供されたパスワードを使用してrootユーザーとしてシェルにログインして、サーバーの追加診断および修復を手動で実行できます。詳細は、Oracleサポート・サービスの担当者に連絡してください。
レスキューが成功した後、サーバーを構成する必要があります。データ・パーティションを維持した場合は、レスキュー手順の実行時にセル・ディスクが自動的にインポートされます。
関連項目:
IORMプランおよびメトリックしきい値の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
