1. オーナーズ・ガイド
  2. リカバリ・アプライアンスのセキュリティおよびメンテナンス
  3. リカバリ・アプライアンス・ハードウェアの保守

12 リカバリ・アプライアンス・ハードウェアの保守

この章では、リカバリ・アプライアンス・ラックのコンポーネントの保守方法について説明します。この付録には、次の項があります。

関連項目:

交換ユニット

注意事項と警告

リカバリ・アプライアンス・ハードウェアの保守時には、次の注意に従ってください。

警告:

この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。

注意:

  • 緊急時でないかぎり、リカバリ・アプライアンスの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。

  • キャビネットの前のドアと後のドアを閉めた状態にしてください。ドアを閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。

  • 空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。

サーバー・モデルの判別

次のコマンドを使用して、計算サーバーまたはストレージ・サーバーのモデルを判別します。

dmidecode -s system-product-name

リカバリ・アプライアンス・ラックの電源の投入と切断

この項の内容は次のとおりです。

緊急時の電源切断の手順

緊急時には、リカバリ・アプライアンスへの電源供給をすぐに停止します。次のような緊急時に、リカバリ・アプライアンスの電源切断が必要な場合があります。

  • 地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合

  • システムから異常な騒音、臭い、または煙が発生した場合

  • 人の安全を脅かす場合

緊急時の電源切断

緊急時には、次のいずれかの作業を実行します。

  • サーキット・ブレーカで電源を切断します。

  • コンピュータ・ルームで緊急時の電源切断スイッチを作動させます。

その後、システムの電源の復旧についてOracleサポート・サービスに連絡します。

緊急時の電源切断スイッチについて

緊急時の電源切断スイッチ(EPO)を使用すると、リカバリ・アプライアンスの電源を停止できます。

EPOスイッチは、5分より長く750を超えるボルトアンペアを供給できるバッテリがコンピュータ機器に含まれる場合に必要になります。このようなバッテリがシステムで使用される場合、そのシステムには、サイトのEPOスイッチまたはリレーに接続するための内部EPOハードウェアがあります。

リカバリ・アプライアンスの停止

緊急でない通常の状況下では、ソフトウェア・サービスおよびハードウェアの電源を正常に切断できます。

ラック・コンポーネントを停止する前にすべてのソフトウェア・サービスを停止します。

リカバリ・アプライアンス・サービスの停止

リカバリ・アプライアンス・サービス、Oracle Databaseファイル・システム、Oracle Databaseおよびクラスタ・サービスを停止する必要があります。

リカバリ・アプライアンス・サービスを停止するには:

  1. アプライアンスの停止の一環としてキーストアを無効にします。キーストアが作成されていない場合は、このステップをスキップしてください。

    キーストアが作成されている場合は、クラウド暗号化へのコピーのためにHSMウォレットを停止するのにこれが必要です。

    アプライアンスを停止する前に、次のコマンドを実行します。

    [root@myhost ~]# racli disable keystore
[root@myhost ~]# racli status keystore
       Node: zdlra41
Wallet Type: HSM
     Status: Closed
       Node: zdlra42
Wallet Type: HSM
     Status: Closed

  2. oracleとしてリカバリ・アプライアンス計算サーバーにログインします。

  3. rasysユーザーとしてOracle DatabaseへのSQL接続を開きます。 

    $ sqlplus rasys

  4. サービスのステータスをチェックします。

    SQL> SELECT state FROM ra_server;

STATE
------------
ON

  5. リカバリ・アプライアンス・サービスを停止します。

    SQL> exec dbms_ra.shutdown;

  6. Oracle Databaseから切断します。

    SQL> exit

  7. Oracle Secure Backupが構成されている場合、次の手順を実行します。

    1. rootユーザーに切り替えます。

    2. Oracle Secure Backupの現在のステータスをチェックします。

      # $GRID_HOME/bin/crsctl status res osbadmin
  NAME=osbadmin
  TYPE=cluster_resource
  TARGET=ONLINE
  STATE=ONLINE on example01adm04

    3. Oracle Secure Backupがオンラインである場合は、停止します。

      # $GRID_HOME/bin/crsctl stop res osbadmin

    4. oracleユーザーに切り替えます。

  8. Oracle Databaseのステータスをチェックします。

    $ srvctl status database -d zdlra5
Instance zdlra51 is running on node radb07
Instance zdlra52 is running on node radb08

  9. Oracle Databaseを停止します。

    $ srvctl stop database -d zdlra5

  10. Oracle Databaseが停止していることを確認します。

    $ srvctl status database -d zdlra5
Instance zdlra51 is not running on node radb07
Instance zdlra52 is not running on node radb08

  11. rootユーザーに切り替えます。

  12. クラスタのすべてのノード上の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オプションを使用してコマンドを再入力します。

  13. 計算サーバーごとに、次のコマンドを実行して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.

  14. 必要に応じて、次の順序でハードウェアを停止または再起動します。

    1. 計算サーバー

    2. ストレージ・サーバー

    3. ラックおよびスイッチ

サーバーの電源切断

サーバーの電源を切断する前に、「リカバリ・アプライアンスの停止」の説明に従って、サーバー上で動作しているサービスを停止します。

計算サーバーまたはストレージ・サーバーを停止するには:

  1. サーバーにrootとしてログインします。
  2. オペレーティング・システムを停止します。
    # shutdown -h -y now

    または、オペレーティング・システムを再起動します。

    # shutdown -r -y now

例12-1 dcliユーティリティを使用したリカバリ・アプライアンスの電源の切断

  1. すべての計算サーバー上のOracle Clusterwareを停止します。

    # GRID_HOME/grid/bin/crsctl stop cluster -all

  2. ラック内の他の計算サーバーを停止します。

    # dcli -l root -g ra-adm02 shutdown -h -y now

    前述のコマンドで、ra01adm02は2番目の計算サーバーの名前です。

  3. すべてのストレージ・サーバーを停止します。

    # dcli -l root -g cell_group shutdown -h -y now

    前述のコマンドのcell_groupは、すべてのストレージ・サーバーをリストするファイルです。

  4. ローカルの計算サーバーを停止します。

    shutdown -h -y now

  5. ラックの電源を切断します。

dcliユーティリティを使用して、複数のサーバーで同時にshutdownコマンドを実行します。コマンドによって電源が停止するサーバーからはdcliを実行しないでください。

次の例では、cell_groupというファイルにリストされたストレージ・サーバーのグループが停止します。 

# dcli -l root -g cell_group shutdown -h -y now

例12-1に、dcliユーティリティを使用して同時に複数のサーバーを停止する場合のラックの電源切断手順を示します。コマンドは計算サーバーから実行されます。

ネットワーク・スイッチの電源の投入

ゲートウェイおよびスパイン・スイッチには電源制御がありません。PDUやデータ・センターのブレーカをオフにして電力が投入されなくなると、これらの電源は切断されます。

リカバリ・アプライアンスの起動

最初にラック・コンポーネントに電源を投入してから、ソフトウェア・サービスを起動します。

リカバリ・アプライアンス・コンポーネントの起動

ラック・コンポーネントに電源を投入するには、次のいずれかの方法を使用します。

起動順序

次の手順でラック・コンポーネントに電源を投入します。

  1. ラックおよびスイッチ

    スイッチが初期化するのを数分待ってから、ストレージ・サーバーを起動します。

  2. ストレージ・サーバー

    ストレージ・サーバーですべてのサービスが開始されるまで5から10分待ちます。必ず初期化が終了してから、計算サーバーを起動します。

  3. 計算サーバー

    計算サーバーの電源が投入されると、オペレーティング・システムとOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。

リモート・サーバーの電源投入

Oracle ILOMインタフェースを使用すると、リモートでリカバリ・アプライアンス・サーバーの電源を投入できます。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ドキュメントを参照してください。

http://docs.oracle.com/cd/E19860-01/index.html

リカバリ・アプライアンス・ソフトウェアの起動

  1. rootとしてリカバリ・アプライアンス計算サーバーにログインします。

  2. Oracle Cluster Ready Services (CRS)が実行されていることを確認します。

    	# $GRID_HOME/bin/crsctl status server
	  NAME=radb07
	  STATE=ONLINE
	
	  NAME=radb08
	  STATE=ONLINE

  3. 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'
     .
     .
     .
#

  4. oracleユーザーに切り替えます。

  5. Oracle Databaseが実行されていることを確認します。

    $ srvctl status database -d zdlra5
Instance zdlra51 is not running on node radb07
Instance zdlra52 is not running on node radb08

  6. Oracle Databaseが実行されていない場合:

    1. Oracle Databaseを起動します。

      $ srvctl start database -d zdlra5

    2. Oracle Databaseが実行されていることを確認します。

      $ srvctl status database -d zdlra5
Instance zdlra51 is running on node radb07
Instance zdlra52 is running on node radb08

  7. Oracle Secure Backupが有効である場合は、起動します。

    # $GRID_HOME/bin/crsctl start res osbadmin

  8. RASYSユーザーとしてOracle Databaseに接続します。 

    $ sqlplus rasys

  9. リカバリ・アプライアンス・サービスのステータスをチェックします。

    SQL> SELECT state FROM ra_server;
 
STATE
------------
OFF

  10. サービスがオフである場合は、起動します。

    SQL> exec dbms_ra.startup;

  11. サービスが起動したことを確認します。

    SQL> /
 
STATE
------------
ON

  12. アプライアンスの起動の一環としてキーストアを有効にします。これは、クラウド暗号化へのコピーのためにHSMウォレットをオープンするのに必要なステップです。アプライアンスの再起動後、次のコマンドを実行します。

    [root@myhost ~]# racli enable keystore
[root@myhost ~]# racli status keystore
       Node: zdlra42
Wallet Type: HSM
     Status: Open
       Node: zdlra41
Wallet Type: HSM
     Status: Open

ディスク・コントローラ・バッテリの交換

ストレージ・サーバーおよび計算サーバーのディスク・コントローラには、書込みパフォーマンスを高速化するバッテリ・バックアップ式の書込みキャッシュがあります。充電容量が低下して48時間以上電力の供給されないキャッシュ・データをバッテリで保護できない場合、書込みキャッシュが無効になり、ディスク・コントローラがライトスルー・モードに切り替わります。書込みパフォーマンスは低下しますが、データは失われません。

バッテリの充電容量は徐々に低下し、寿命は動作温度と反比例します。表12-1に、リカバリ・アプライアンスにおけるバッテリの寿命の最短のケースを示します。

表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度以上である場合は、原因を特定し、問題を解決してください。

ノート:

充電容量が不十分である、温度が高い、またはバッテリの交換が必要である場合などに、ストレージ・サーバーはアラートを生成します。

ディスク・コントローラのバッテリの交換

オラクル社は次の条件下で、故障したバッテリを無償で交換します。

  • ディスク・コントローラ内のバッテリの充電容量が最小しきい値を下回る場合

  • システムがOracle Premier Support for Systemsでカバーされているか、保証期間中の事象の場合。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にリカバリ・アプライアンスのバッテリを事前に交換します。

配電ユニットの交換

配電ユニット(PDU)は、Recovery Applianceがオンライン状態でも交換できます。ラック内の2番目のPDUは、ラック内のすべてのコンポーネントに電力を維持します。PDU-Aは、ラックを背面から見て左側、PDU-Bは右側にあります。

PDU交換のガイドライン

安全に手順を実行して可用性を損なわないために、PDUを交換する前に、次のガイドラインを確認してください。

  • PDU-Aの取外しまたは挿入中に、InfiniBandケーブルのラッチを解除すると、サーバーがクラスタから削除されるため、ラックが使用不可になります。通常、InfiniBandケーブルはラッチでしっかりと固定されているため、取扱いには注意してください。InfiniBandケーブルを無理な力で引っ張らないでください。

  • 間違った電源フィードのフックを外すと、ラックが停止します。交換するPDUから電力ケーブルを電源までたどり、それらのフィードのみを抜いてください。

  • PDU交換部品の開梱と再梱包は慌てずに行ってください。故障したユニットを同じように再梱包できるように、電源コードが梱包品の中でどのように巻かれているかに注意してください。

  • サイド・パネルを外すと、PDUの交換に必要な時間を短縮できます。ただし、サイド・パネルの取り外しは任意です。

  • コードレス・ドリルまたは電動ドライバを使用すると、PDUの交換に必要な時間を短縮できます。ハンド・レンチを使用する場合はさらに交換に時間をかけてください。ドライバにはTorx T30ビットおよびT25ビットが必要です。

  • 電力ケーブルを移動するには、サーバーのケーブル・アームの取外しが必要になる場合があります。このような場合は、ケーブル・アームのクリップを外さなくても済むように、プラグ接続をねじり、ケーブル・アーム・コネクタを曲げます。ケーブル・アームのクリップを外す必要がある場合は、片方の手でケーブルを支えて電源コードを外し、ケーブル・アームをクリップで留めます。ケーブル・アームはつるしたままにしないでください。

  • T30ねじをL金具から外す場合は、PDUをラックから取り外すまで、PDUと金具を取り付けているT25ねじまたはナットを外さないでください。

PDUの交換

PDUを交換するには、次のようにします。

  1. PDUモニターを再起動してネットワーク設定を識別します。

    1. カウント(5から0)が開始されるまで、リセット・ボタンを20秒押します。カウントダウン中にボタンを放し、再度押します。

    2. モニターが再起動したら、LCDに表示される設定やファームウェア・バージョンなどを記録します。

    PDUモニターが機能していない場合は、ネットワーク経由でPDUに接続してネットワーク設定を取得するか、ネットワーク管理者から取得します。

  2. すべてのPDUブレーカをオフにします。

  3. PDUの電源プラグをACコンセントから抜きます。

    高くした床にラックがある場合は、床の切抜き部分から電源コードを出します。最初にラックを切抜き部分の上に動かすことが必要な場合もあります。

    警告:

    電源コードが頭上の配線を使用している場合は、人に落ちたり当たったりしない場所に置きます。

  4. サイド・パネル・アクセスがなく、ラックにInfiniBandケーブル・ハーネスがないときにPDU-Bを交換する場合:

    ノート:

    ケーブル・アームに取り付けられているケーブルのストラップを外さないでください。

    1. 四角のケーブル・アームをラックに留めているT25ねじを外します。

    2. InfiniBandケーブルを邪魔にならないように中央に動かします。

  5. サーバーおよびスイッチからPDUに接続されているすべての電力ケーブルを外します。電源ケーブルをグループの束にしてまとめておきます。

  6. L金具の上部と下部からT30ねじを外し、ねじの使用位置をノートにとっておきます。

  7. ラック・フレーム内のPDUの設置位置をノートにとっておきます。

    ブレーカ・スイッチを使用できるようにするために、PDUは一般的にラック・フレームから後ろに1インチの位置にします。

  8. PDUを斜めにしてラックから取り出します。

  9. PDUを持ったまま(十分な空間がある場合は下ろし)、AC電源コードをラックに通します。ACコード・フラッシュをPDUの下部に固定するケーブル・タイを切断する必要が生じる場合があります。

  10. ラックの下部または上部のできるかぎり近くにコードを引っ張ります。サーバーの間にはコンセント・プラグを配線用の穴に通すための空間があります。

  11. 小さい方のTorx T25ねじを外し、上部および下部のナットを緩めてPDUをL金具から取り外します。ナットを外す必要はありません。

  12. L金具を新しいPDUに取り付けます。

  13. 新しいPDUをラックの横に置きます。

  14. ACコードをラックに通してコンセントまで配線します。

    ノート:

    ACコードを新しいPDUにケーブル・タイしないでください。

  15. L金具が上部および下部のレールの上に来るまで、角度と位置を調整して、新しいPDUをラック内に置きます。

  16. 穴とスロットの位置を整列し、PDUがラック・フレームの後ろ約1インチの位置になるようにします。

  17. コードのラベルに従って、電源コードを取り付けます。たとえば、G5-0は、PDUのPDUグループ5のコンセント0を示しています。

  18. ステップ4でInfiniBandケーブル・ホルダを取り外した場合は、取り付けます。ねじがすり減らないようにするには、最初にホルダのねじを手で締めることをお薦めします。

  19. AC電源コードをコンセントに接続します。

  20. ブレーカをオンにします。

  21. PDUモニターのケーブルを配線し、必要に応じてネットワークをプログラムします。

    関連項目:

    PDUモニターのプログラミングの詳細は、次のWebサイトのOracle Sun Rack II配電ユニット・ユーザーズ・ガイドを参照してください。

    http://docs.oracle.com/cd/E19844-01/html/E23956/index.html

テープ・ドライブの交換

テープ・ドライブは、Recovery Applianceがオンラインのときに交換できます。

ノート:

ブリッジ・テープ・ドライブは、基本モジュールの上位ドライブ・スロットにあります。ロボット制御は、ブリッジ・テープ・ドライブ上でLUN 1として表示されるSCSIメディア・チェンジャ・デバイスです。ライブラリがパーティション分割されている場合、ベース・モジュールに2つのテープ・ドライブが必要になり、各テープ・ドライブがその割り当てられたパーティションのロボット制御を提供します。障害の発生したドライブがブリッジ・ドライブの場合、テープ・ドライブを交換するとホストからSL150ライブラリへの接続が失われるため、SL150ライブラリをホストに対してオフラインにする必要があります。テープ・ドライブがブリッジ・ドライブでない場合は、ホット・スワップが可能です。

テープ・ドライブを交換するには、次のようにします。

  1. リカバリ・アプライアンスのsbt_libraryを一時停止します。 

    exec dbms_ra.pause_sbt_library(lib_name=>'ROBOT0');
  2. このテープ・ドライブのアクティビティを静止します。
  3. ブラウザを使用して、SL150リモート・インタフェースにログインします。
  4. (オプション)位置特定ライブラリ・インジケータを有効にします
  5. テープ・ドライブを取り外すための準備をします。
    1. リモート・インタフェースの左側にある「ライブラリ」をクリックします。
    2. 交換するドライブにカーソルを移動します。
    3. ドライブ・アイコンをクリックして、ドライブの取外しを選択します。
    4. 確認ダイアログ・ボックスで「OK 」をクリックします。ドライブ・トレーの背面にある物理的なLEDが点灯して、ドライブの取外し準備ができていることを示します。
  6. テープ・ドライブを取り外します。
    1. ライブラリの背面にアクセスします(該当する場合はラックの背面ドアを開けます)。
    2. 青色のLED (ドライブの取外し準備ができていることを示す)が点灯しているテープ・ドライブを見つけます。
    3. インタフェース・ケーブルにラベルが付いていることを確認します。必要に応じて、ラベルを貼り付けます。
    4. ドライブ・トレーの左側にあるジャックからケーブルを取り外します。
    5. ドライブ・トレーの脱落防止機構付きつまみねじを緩めます。
    6. ドライブ・トレーをつかみ、ライブラリのドライブ・スロットから引き出し、静電気防止面に平らな状態で立てて置きます。

    注意:

    ESDの損傷。電子部品または電気接点に触れないでください。
  7. 交換用のドライブをパッケージから取り出します。
  8. テープ・ドライブを交換します。
    1. ドライブ・トレーの背面の角をつかみます。
    2. ドライブ・トレーの前面をモジュール・ドライブ・スロット内に導きます。
    3. ドライブ・トレーをドライブ・スロットに完全に押し込みます。
    4. ドライブ・トレーの背面にあるLEDがアクティブになっていることを確認します。
    5. ドライブ・トレーの両側にある脱落防止機能付きつまみねじをしっかりと締めて、トレーがどの方向にも動かないようにします。
  9. ロボットCRUの位置特定インジケータを押して、消灯します(点灯している場合)。
  10. Web GUIまたはフロント操作パネルから、ライブラリがそのドライブを認識していることを確認します。
  11. ドライブ・ポートが有効にされていることを確認します。ドライブのプロパティを表示し、必要に応じてドライブの設定を変更します。
  12. インタフェースとイーサネット・ケーブルをドライブ・トレーの左側にある適切なジャックにつなぎます。
  13. SL150リモート・インタフェースからログアウトするか、タッチ・スクリーンをホームに戻します。
  14. obtoolを実行して、ドライブ・オブジェクトのシリアル番号を更新します。
    obtool chdev -S <drive_object_replaced> | obtool chdev -S robot0_tape03

  15. ZDLRAのsbt_ libraryを再開します。 

    exec dbms_ra.resume_sbt_library(lib_name=>'ROBOT0');

前述のステップの多くは、StorageTek SL150 Modular Tape Library [VCAP]のテープ・ドライブCRUの取外し/交換を行う方法(ドキュメントID 1473764.1)で説明されています。

ファームウェアを更新する前に構成を保存する

Oracle ILOMシステム・ファームウェアを更新する際には、既存のリカバリ・アプライアンス構成を保持してください。

Oracle ILOMシステム・ファームウェアの更新は、ホストの電源が入っているときに行えます。Oracle ILOMファームウェア・イメージには、サービス・プロセッサ(SP、Oracle ILOM)のファームウェアおよびサーバーのホスト・コンポーネント(FPGA)が含まれています。Oracle ILOMファームウェアの更新はただちに有効になります。一方、ホスト・コンポーネントの更新は、影響を受けるホストの電源が再投入されるまでは有効になりません。Oracle ILOMの更新はホストの電源が入っている間に行えるため、この機能によってシステムの合計停止時間が短縮されます。

Oracle ILOMコマンド行インタフェースを使用してファームウェアを更新します。

ノート:

ファームウェアのアップグレード中にリカバリ・アプライアンスの構成を保存するには、「Preserve existing SP configuration (y/n)?」と尋ねられたときに「y」(はい)と答えます。

  1. 管理者権限のあるアカウントでOracle ILOMにログインします。

  2. load -sourceコマンドの後ろにインストールするファームウェア・イメージのディレクトリ・パスを指定して、ファームウェア・イメージを格納されている場所から読み込みます。次のように入力します。

    -> load -source protocol://server_IPaddress/<path_to_image>/<image.pkg>

    ここで、protocolにはhttp、https、ftp、tftp、sftp、scpのいずれかを指定可能

    たとえば、IPアドレスが198.xxx.yyy.123で、ilom/jdoeディレクトリにあり、firmware.pkgという名前の<image.pkg>を持つtftpサーバーを介してサーバーにアクセスする場合なら、次のコマンドを入力します。

    -> load -source tftp://198.xxx.yyy.123/tftpboot/ilom/jdoe/firmware.pkg

    次の情報が表示されます:

    An upgrade takes several minutes to complete. Oracle ILOM will enter a special mode to load new firmware. No other tasks can be performed in Oracle ILOM until the firmware upgrade is complete and Oracle ILOM is reset.

    You can choose to postpone the server BIOS upgrade until the next server power off. If you do not do that, you should perform a clean shutdown of the server before continuing.

  3. 次のプロンプトに対して入力します:

    Are you sure you want to load the specified file? y

    Preserve existing SP configuration (y/n)? y

    ノート:

    このプロンプトは、ファームウェアの更新が完了した後も既存のOracle ILOM設定を保持します。「y」(はい)と答えると、既存のリカバリ・アプライアンス構成が保持されます。

    Preserve existing BIOS configuration (y/n)? y

    ノート:

    このプロンプトは、ファームウェアのアップグレードが完了した後も既存のBIOS構成設定を保持します。

    Delay BIOS upgrade until the next poweroff or reset (y/n)? y

    Delay BIOS Upgradeの質問に「Y」(はい)と答えると、ホストの電源が入っており、更新するホスト・コンポーネントがある場合、ホストの電源は投入されたままになり、ホストの電源が次回切断されて再投入されるまで(次回のリセット/リブートまで)ホスト・コンポーネントは更新されません。

    Delay BIOS Upgradeの質問に「N」(いいえ)と答えると、ホストの電源が入っており、更新するホスト・コンポーネントがある場合、ホスト・コンポーネントの更新をただちに適用できるように、強制的にホストの電源が切られます。ホストの電源が強制的に切られた場合、Oracle ILOMがリブートした後に、ホストの電源が自動的に投入されます。

    ノート:

    サーバーに保留中のBIOSアップグレードがある場合は、電源のリセットが完了するまでの時間が長くなる可能性があります。BIOSファームウェアをアップグレードするためにはサーバーの電源を切って再投入することが必要であり、これは予期された動作です。アップグレードにFPGA更新が含まれている場合は、処理が完了するまでに26分かかることがあります。

  4. Oracle ILOMのステータス・メッセージが表示されるまで待って、処理が完了したことを確認してください。

ノート:

詳細は、Oracle ILOMを使用してシステム・ファームウェアを更新するを参照してください。

無反応になったOracle ILOMのリセット

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のリセット

SSHを使用してOracle ILOMをリセットするには、次のようにします。

  1. 別のシステムからSSHを使用してOracle ILOMに接続します。
  2. ILOMプロンプトで次のコマンドを入力します。
    reset /SP

リモート・コンソールを使用したOracle ILOMのリセット

SSHを使用してOracle ILOMに接続できない場合は、リモート・コンソールにログインします。

リモート・コンソールを使用してOracle ILOMをリセットするには、次のようにします。

  1. Oracle ILOMリモート・コンソールにログインします。
  2. 「メンテナンス」タブからSPのリセットを選択します。
  3. 「SPのリセット」をクリックします。

IPMItoolを使用したOracle ILOMのリセット

SSHまたはリモート・コンソールのどちらを使用してもOracle ILOMに接続できない場合は、IPMItoolを使用します。

IPMItoolを使用してOracle ILOMをリセットするには、次のようにします。

  1. ローカル・ホスト、または管理ネットワーク上の別のホストにログインします。
  2. 次のIPMItoolコマンドを使用します。

    • ローカル・ホスト上の場合:

      $ ipmitool mc reset cold
Sent cold reset command to MC

    • 別のホスト上の場合:

      $ ipmitool -H ILOM_host_name -U ILOM_user mc reset cold
Sent cold reset command to MC

      前述のコマンドのILOM_host_nameは使用中のホスト名、ILOM_userはOracle ILOMのユーザー名です。

電源の停止によるOracle ILOMのリセット

前述のオプションを使用してOracle ILOMをリセットできない場合:

  1. 電源からサーバーのプラグを抜きます。
  2. 電源にサーバーのプラグを入れ直します。

この処置により、サーバーおよびOracle ILOMの電源が入れ直されます。

計算サーバーの保守

物理ディスクの修理のために、リカバリ・アプライアンスの計算サーバーを停止する必要はありません。ラックの停止時間は必要ありませんが、個々のサーバーに停止時間が必要になり、一時的にクラスタ外にすることが必要な場合があります。

LSI MegaRAID SAS 9261-8iディスク・コントローラは各計算サーバーのディスク・ドライブを管理します。ディスクにはRAID-5構成があります。各計算サーバーには4つのディスク・ドライブがあります。1つの仮想ドライブがRAIDセットを構成します。

関連項目:

計算サーバーのRAIDステータスの確認

計算サーバーのRAIDデバイスのステータスを定期的に確認することをお薦めします。影響は最小限です。対照的に、是正処置による影響は未対応の特定の問題によって異なり、単純な再構成から停止が必要になる場合があります。

rootとして各計算サーバーにログインして、次の手順を実行します。

RAIDステータスを検証するには、次のようにします。

  1. 現在のディスク・コントローラ構成を確認します。 
    # /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -aALL | grep "Device Present" -A 8

                Device Present
                ================
Virtual Drives    : 1 
  Degraded        : 0 
  Offline         : 0 
Physical Devices  : 5 
  Disks           : 4 
  Critical Disks  : 0 
  Failed Disks    : 0

    出力が、1つの仮想ドライブ、1つもパフォーマンスが低下したりオフラインになっていないこと、5つの物理デバイス(1つのコントローラと4つのディスク)、4つのディスク、およびクリティカルまたは障害のないディスクを示すことを確認します。

    出力が異なる場合は、問題点を調査して修正します。パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。クリティカル・ディスクや障害が発生したディスクはただちに交換します。そうしないと、サーバー内の作業中ディスクの数が、通常業務の維持に必要な数を下回る場合に、データが消失する恐れがあります。

  2. 現在の仮想ドライブ構成を確認します。
    # /opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Virtual Drive:";    \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Number Of Drives";  \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "^State" 

Virtual Drive                 : 0 (Target Id: 0)
Number Of Drives              : 4
State                         : Optimal

    仮想デバイス0に4つのドライブがあり、状態がOptimalであることを確認します。出力が異なる場合は、問題点を調査して修正します。

  3. 現在の物理ドライブ構成を確認します。
    # /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL | grep "Firmware state"
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up

    すべてのドライブがOnline, Spun Upであることを確認します。出力が異なる場合は、問題点を調査して修正します。

    出力が異なる場合は、問題点を調査して修正します。パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。クリティカル・ディスクや障害が発生したディスクはただちに交換します。そうしないと、サーバー内の作業中ディスクの数が、通常業務の維持に必要な数を下回る場合に、データが消失する恐れがあります。

計算サーバーの再イメージ化

計算サーバーが復旧不可能なダメージを負った場合は、そのサーバーを交換して、交換したサーバーを再イメージ化します。再イメージ化手順の実行中に、クラスタ内の他の計算サーバーは使用できます。クラスタに新しいサーバーを追加する際、作業中の計算サーバーから新しいサーバーにソフトウェアをコピーします。

次のタスクは計算サーバーの再イメージ化の方法を示しています:

Oracleサポート・サービスへの連絡

Oracleサポート・サービスでサポート・リクエストを開きます。サポート・エンジニアが障害が発生したサーバーを確認し、交換サーバーを送ります。サポート・エンジニアは、作業中の計算サーバーから実行したimagehistoryコマンドの出力結果も要求します。出力結果により、元の計算サーバーのイメージ化に使用され、システムのリストアに使用されるcomputeImageMakerファイルへのリンクが提供されます。

クラスタ検証ユーティリティの最新リリースのダウンロード

クラスタ検証ユーティリティ(cluvfy)の最新リリースは、My Oracle Support Doc ID 316817.1で入手できます。

クラスタの障害が発生した計算サーバーの削除

障害が発生した計算サーバーは、Oracle Real Application Clusters (Oracle RAC)から削除する必要があります。

このステップで、working_serverはクラスタ内の動作している計算サーバー、failed_serverは交換される計算サーバー、replacement_serverは新規サーバーです。

障害が発生した計算サーバーをOracle RACクラスタから削除するには、次のようにします。

  1. oracleユーザーとして、working_serverにログインします。

  2. 障害が発生したサーバーで実行されているリスナーを無効化します。

    $ srvctl disable listener -n failed_server
$ srvctl stop listener -n failed_server

  3. インベントリから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などのクラスタで動作している計算サーバーのリストです。

  4. 障害が発生したサーバーがクラスタから削除された(つまり、ピン解除された)ことを確認します。

    $ olsnodes -s -t

ra01db01     Inactive        Unpinned
ra01db02        Active          Unpinned

  5. 障害が発生した計算サーバーの仮想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

  6. クラスタから計算サーバーを削除します。

    # 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.

    投票ディスクを移動するには、次のようにします。

    1. 投票ディスクの現在の場所を特定します。出力例では現在の場所が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).

    2. 投票ディスクを別のディスク・グループに移動します。

      # ./crsctl replace votedisk +DATA

Successful addition of voting disk 2345667aabbdd.
...
CRS-4266: Voting file(s) successfully replaced

    3. 投票ディスクを元の場所に戻します。この例ではDBFS_DGに戻されています。

      # ./crsctl replace votedisk +DBFS_DG

    4. crsctlコマンドを繰り返してクラスタからサーバーを削除します。

  7. Oracleインベントリを更新します。

    $ cd $ORACLE_HOME/oui/bin
$ ./runInstaller -updateNodeList ORACLE_HOME=/u01/app/12.1.0/grid \
  "CLUSTER_NODES=list_of_working_servers" CRS=TRUE

  8. サーバーが正常に削除されたことを確認します。

    $ 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.

関連項目:

計算サーバーのクラスタからの削除の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください

イメージ化に使用するUSBフラッシュ・ドライブの準備

USBフラッシュ・ドライブを使用して、イメージを新しい計算サーバーにコピーします。

使用するUSBフラッシュ・ドライブを準備するには、次のようにします。

  1. 空のUSBフラッシュ・ドライブをクラスタの動作している計算サーバーに挿入します。
  2. rootユーザーとしてログインします。
  3. computeImageファイルを解凍します。
    # unzip computeImageMaker_release_LINUX.X64_release_date.platform.tar.zip

# tar -xvf computeImageMaker_release_LINUX.X64_release_date.platform.tar
  4. イメージをUSBフラッシュ・ドライブ上にロードします。
    # cd dl360
# ./makeImageMedia.sh -dualboot no

    makeImageMedia.shスクリプトにより、情報を要求されます。

  5. 計算サーバーからUSBフラッシュ・ドライブを取り外します。
  6. 動作している計算サーバーから解凍したd1360ディレクトリおよびcomputeImageMakerファイルを削除します。ディレクトリおよびファイルには、約2GBのディスク領域が必要です。

新規計算サーバーへのイメージのコピー

次の手順を実行する前に、障害のあった計算サーバーを新しいサーバーに交換します。「ストレージ・サーバーの追加によるリカバリ・アプライアンス・ラックの拡張」を参照してください。

イメージを交換サーバー上にロードするには、次のようにします。

  1. 交換サーバーのUSBポートにUSBフラッシュ・ドライブを挿入します。

  2. サービス・プロセッサを使用してコンソールにログインし、進捗状況をモニターします。

  3. 電源ボタンを押すか、Oracle ILOMを使用することで、計算サーバーの電源を投入します。

  4. マザーボードを交換した場合:

    1. BIOS中に[F2]を押します

    2. 「BIOS Setup」を選択します

    3. USBフラッシュ・ドライブを最初に設定してから、RAIDコントローラを設定します。

    そうでない場合は、BIOS中に[F8]を押して、ワンタイム起動選択メニューを選択してからUSBフラッシュ・ドライブを選択します。

  5. システムを起動できるようにします。

    システムが起動すると、CELLUSBINSTALLメディアが検出されます。イメージ化プロセスには、2つのフェーズがあります。両方のフェーズを完了してから次のステップに進んでください。

    イメージ化プロセスの1つ目のフェーズでは、古いBIOSまたはファームウェアを識別し、イメージに対応するレベルにコンポーネントをアップグレードします。コンポーネントがアップグレードまたはダウングレードされると、システムは自動的に再起動します。

    イメージ化プロセスの2つ目のフェーズでは、交換計算サーバーの工場出荷時のイメージをインストールします。

  6. システムで要求された場合、USBフラッシュ・ドライブを取り外します。

  7. [Enter]を押してサーバーの電源を切断します。

交換計算サーバーの構成

交換計算サーバーには、ホスト名、IPアドレス、DNSまたはNTP設定がありません。このタスクは、交換計算サーバーの構成方法を示しています。

情報はリカバリ・アプライアンス内のすべての計算サーバーで同じである必要があります。IPアドレスはDNSから取得できます。初期インストールからインストレーション・テンプレートのコピーも取得する必要があります。

交換計算サーバーを構成するには、次のようにします。

  1. 次の情報を組み立てます。

    • ネーム・サーバー

    • 南北アメリカ/シカゴなどのタイムゾーン

    • NTPサーバー

    • 管理ネットワークのIPアドレス情報

    • クライアント・アクセス・ネットワークのIPアドレス情報

    • InfiniBandネットワークのIPアドレス情報

    • 標準的なホスト名

    • デフォルトのゲートウェイ

  2. 交換計算サーバーの電源を投入します。システムが起動すると、構成スクリプトが自動的に実行され、情報が要求されます。
  3. 要求された場合は情報を入力して、設定を確認します。続いて起動プロセスが続行されます。

ノート:

  • 計算サーバーがすべてのネットワーク・インタフェースを使用していない場合は、構成プロセスが停止し、いずれかのネットワーク・インタフェースが切断されているという警告が出されます。検出プロセスを再試行するかどうかの確認を求められます。環境に応じて、yesまたはnoと入力します。

  • 収集ネットワークにボンディングが使用される場合、この時点でデフォルトのアクティブ/パッシブ・モードに設定されます。

クラスタの交換計算サーバーの準備

リカバリ・アプライアンスの初期インストールでは各種ファイルが変更されました。

交換計算サーバー上のファイルを変更するには、次のようにします。

  1. クラスタ内の動作している計算サーバーから、次のファイルの内容をレプリケートします。

    1. /etc/security/limits.confファイルをコピーします。

    2. /etc/hostsファイルの内容をマージします。

    3. /etc/oracle/cell/network-config/cellinit.oraファイルをコピーします。

    4. 交換計算サーバーのBONDIB0インタフェースのIPアドレスでIPアドレスを更新します。

    5. /etc/oracle/cell/network-config/cellip.oraファイルをコピーします。

    6. 10GbEなど、追加ネットワーク要件を構成します。

    7. /etc/modprobe.confファイルをコピーします。

    8. /etc/sysctl.confファイルをコピーします。

    9. 計算サーバーを再起動し、ネットワーク変更を有効にします。

  2. ユーザー名を1つ以上のグループに追加して、交換計算サーバーのOracleソフトウェア所有者を設定します。所有者は通常、oracleユーザーです。

    1. 動作している計算サーバーから現在のグループ情報を取得します。

      # id oracle
uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)

    2. groupaddコマンドを使用して、グループ情報を交換計算サーバーに追加します。この例では、前のステップで識別されたグループが追加されます。 

      # groupadd –g 1001 oinstall
# groupadd –g 1002 dba
# groupadd –g 1003 oper
# groupadd –g 1004 asmdba

    3. 動作している計算サーバーから現在のユーザー情報を取得します。

      # id oracle uid=1000(oracle) gid=1001(oinstall) \
  groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)

    4. ユーザー情報を交換計算サーバーに追加します。この例では、前のステップのグループIDがoracleユーザーIDに追加されます。 

      # useradd -u 1000 -g 1001 -G 1001,1002,1003,1004 -m -d /home/oracle -s \
  /bin/bash oracle

    5. 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

    6. cellip.oraおよびcellinit.oraファイルの所有権を変更します。所有者は通常、oracle:dbaです。 

      # chown -R oracle:dba /etc/oracle/cell/network-config

    7. リストアされた計算サーバーの安全を確保します。

      $ chmod u+x /opt/oracle.SupportTools/harden_passwords_reset_root_ssh
$ /opt/oracle.SupportTools/harden_passwords_reset_root_ssh

      計算サーバーが再起動します。

    8. rootユーザーとしてログインします。新しいパスワードを要求されたら、他の計算サーバーのrootパスワードと一致するように設定します。

    9. Oracleソフトウェア所有者のパスワードを設定します。所有者は通常、oracleです。 

      # passwd oracle

  3. oracleアカウントにSSHを設定します。

    1. 交換計算サーバー上のoracleアカウントに変更します。 

      # su - oracle

    2. Oracleクラスタのサーバーをリストする交換計算サーバーのdcliグループ・ファイルを作成します。

    3. 交換計算サーバーでsetssh-Linux.shスクリプトを実行します。この例ではスクリプトがインタラクティブに実行されます。 

      $ /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s

      スクリプトによってサーバーのoracleパスワードが要求されます。-sオプションにより、スクリプトはサイレント・モードで実行されます。

    4. 交換計算サーバー上のoracleユーザーに変更します。 

      # su - oracle

    5. SSHの同等性を検証します。

      $ dcli -g dbs_group -l oracle date

  4. 動作している計算サーバーから交換計算サーバーにカスタム・ログイン・スクリプトを設定またはコピーします。

    $ scp .bash* oracle@replacement_server:.

    前述のコマンドのreplacement_serverは、ra01db01などの新しいサーバーの名前です。

交換計算サーバーへのパッチ・バンドルの適用

オラクル社では、リカバリ・アプライアンス用のソフトウェアのパッチ・バンドルを定期的にリリースしています。動作している計算サーバーにcomputeImageMakerファイルのリリースよりも新しいパッチ・バンドルがある場合、パッチ・バンドルを交換計算サーバーに適用する必要があります。

パッチ・バンドルが適用されたかどうか判断するには、imagehistoryコマンドを使用します。交換計算サーバーの情報を、動作している計算サーバーの情報と比較します。動作しているデータベースのリリースが新しい場合、ストレージ・サーバー・パッチ・バンドルを交換計算サーバーに適用します。

Oracle Grid Infrastructureのクローニング

次の手順では、交換計算サーバーにOracle Grid Infrastructureをクローニングする方法について説明します。コマンドのworking_serverは動作している計算サーバー、replacement_serverは交換計算サーバーです。

Oracle Grid Infrastructureをクローニングするには、次のようにします。

  1. rootとして、クラスタの動作している計算サーバーにログインします。

  2. クラスタ検証ユーティリティ(cluvfy)を使用して、ハードウェアおよびオペレーティング・システムのインストールを検証します。 

    $ cluvfy stage -post hwos -n replacement_server,working_server –verbose

    レポートの最後にPost-check for hardware and operating system setup was successfulのフレーズが表示されます。

  3. ピア互換性を検証します。

    $ 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

    障害が発生したコンポーネントだけが物理メモリー、スワップ領域およびディスク領域に関連している場合は、手順を継続できます。

  4. サーバーを追加するために必要な確認を行います。

    1. GRID_HOME/network/admin/samplesディレクトリの権限が750に設定されていることを確認します。

    2. 計算サーバーの追加を検証します。

      $ 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オプションを使用します。

  5. 交換計算サーバーをクラスタに追加します。

    $ 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

  6. 構成スクリプトを実行します。

    1. 端末のウィンドウを開きます。

    2. rootユーザーとしてログインします。

    3. 各クラスタ・サーバーでスクリプトを実行します。

    スクリプトの実行後、次のメッセージが表示されます。

    The Cluster Node Addition of /u01/app/12.1.0/grid was successful.
Please check '/tmp/silentInstall.log' for more details.

  7. 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

  8. 「クラスタの障害が発生した計算サーバーの削除」で停止したリスナー・リソースを再有効化します。 

    # 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 Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

交換計算サーバーへのOracle Databaseホームのクローニング

交換サーバーへOracle Databaseホームをクローニングするには、次のようにします。

  1. Oracle Database ORACLE_HOMEを交換計算サーバーに追加します。
    $ cd /u01/app/oracle/product/12.1.0/db_home/addnode/
$ ./addnode.sh -silent "CLUSTER_NEW_NODES={replacement_server}" -ignorePrereq

    addnodeスクリプトでは、Oracle Universal InstallerによってOracle Databaseソフトウェアが交換計算サーバーにコピーされます。 

    WARNING: The following configuration scripts need to be executed as the "root"
user in each cluster node.
/u01/app/oracle/product/12.1.0/dbhome_1/root.sh #On nodes ra01db01
To execute the configuration scripts:
Open a terminal window.
Log in as root.
Run the scripts on each cluster node.

    スクリプトの完了後、次のメッセージが表示されます。

    The Cluster Node Addition of /u01/app/oracle/product/12.1.0/dbhome_1 was
successful.
Please check '/tmp/silentInstall.log' for more details.
  2. 交換計算サーバーでroot.shスクリプトを実行します。
    # /u01/app/oracle/product/12.1.0/dbhome_1/root.sh

    スクリプトの出力に/u01/app/oracle/product/12.1.0/dbhome_1/install/root_replacement_server.company.com_date.logファイルを確認します。

  3. インスタンス・パラメータが交換したデータベース・インスタンスに設定されていることを確認します。次に、CLUSTER_INTERCONNECTSパラメータの例を示します。
    SQL> SHOW PARAMETER cluster_interconnects

NAME                                 TYPE        VALUE
------------------------------       --------    -------------------------
cluster_interconnects                string
 
SQL> ALTER SYSTEM SET cluster_interconnects='192.168.73.90' SCOPE=spfile SID='dbm1';
  4. 構成ファイルを検証し、必要に応じて修正します。

    • ORACLE_HOME/dbs/initSID.oraファイルは、Oracle ASM共有ストレージ内のサーバー・パラメータ・ファイル(SPFILE)を示します。

    • ORACLE_HOME/dbディレクトリにコピーされるパスワードは、orapwSIDに変更されています。

  5. データベース・インスタンスを再起動します。

関連項目:

Oracle Real Application Clusters管理およびデプロイメント・ガイド

ストレージ・サーバーの保守

この項では、ストレージ・サーバーの保守を実行する方法について説明します。この付録には、次の項があります。

ストレージ・サーバーの停止

ストレージ・サーバーの保守を実行する場合、サーバーの電源切断または再起動が必要になることがあります。ストレージ・サーバーを停止する前に、サーバーのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。データベース可用性の継続は、影響するディスク・グループで使用されるOracle ASM冗長性のレベルと、同じデータのミラー・コピーを含む他のストレージ・サーバーでのディスクの現在のステータスによって異なります。

注意:

  • リカバリ・アプライアンスで保守中のセルが完全に機能するようになる前に、別のセルのディスクに障害が発生した場合、二重のディスク障害が発生する可能性があります。リカバリ・アプライアンスがDELTAディスク・グループについてNORMALの冗長性でデプロイされており、このディスク障害が恒久的な場合、リカバリ・アプライアンス上のすべてのバックアップが失われます。

  • 保守中のセルが長時間オフラインでないことを確認してください。そうしないと、リバランス操作が発生し、操作の完了に十分な領域がないために問題が引き起こされます。デフォルトで、リバランス操作はセルがオフラインになってから24時間後に開始されます。

ストレージ・サーバーの電源を停止するには、次のようにします。

  1. rootとして、ストレージ・サーバーにログインします。
  2. (オプション)ストレージ・サーバーの再起動後にグリッド・ディスクがオフラインのままになるようにします。 
    CellCLI> ALTER GRIDDISK ALL INACTIVE

    複数の再起動を行う場合、またはセルが再度アクティブになったときに制御するには、このコマンドを使用します。たとえば、サーバーを使用する前に、計画保守アクティビティが成功したことを検証できます。

  3. セル・サービスを停止します。
    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ディスク・グループの冗長性がリストアされます。すべてのディスクのステータスが正常のときはコマンドを再試行します。

  4. サーバーを停止します。「サーバーの電源切断」を参照してください。
  5. 保守作業が完了したら、サーバーの電源を投入します。サービスは自動的に開始されます。起動中、Oracle ASMですべてのグリッド・ディスクが自動的にオンラインになります。
  6. すべてのグリッド・ディスクがオンラインであることを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

  7. ステップ2でグリッド・ディスクを非アクティブにした場合は、再度アクティブにします。
    CellCLI> ALTER GRIDDISK ALL ACTIVE

    ステップ2をスキップした場合は、グリッド・ディスクは自動的にアクティブになります。

関連項目:

My Oracle SupportのドキュメントID 1188080.1「ASMに影響を与えずにExadataのストレージ・セルを停止または再起動するステップ」

診断ISOを使用したネットワーク接続の有効化

正常に再起動できないストレージ・サーバーにアクセスするため、診断ISOの使用が必要になる場合があります。サーバーの起動後、ファイルをISOからサーバーにコピーすることで破損ファイルを置き換えます。

ISOは、すべてのリカバリ・アプライアンス・サーバー上の/opt/oracle.SupportTools/diagnostics.isoにあります。

注意:

USBドライブの使用など、他の再起動方法が失敗した後でのみ、診断ISOを使用してください。この手順を開始する前に、アドバイスとガイダンスを得るためOracle Supportに連絡してください。

診断ISOを使用するには、次のようにします。

  1. TelnetまたはpuTTYなどの、Webインタフェースまたはシリアル・コンソールのどちらかを使用して、サービス・プロセッサで1回のCD-ROMブートを有効にします。たとえば、シリアル・コンソールから次のコマンドを使用します。
    set boot_device=cdrom
  2. サービス・プロセッサ・インタフェースを使用して、diagnostics.isoのローカル・コピーをCD-ROMとしてマウントします。
  3. rebootコマンドを使用してサーバーを再起動します。
  4. rootユーザーとして、診断ISOのパスワードを使用してサーバーにログインします。
  5. pingを避けるには:
    alias ping="ping -c"
  6. /etc/networkという名前のディレクトリを作成します。
  7. /etc/network/if-pre-up.dという名前のディレクトリを作成します。
  8. 次の設定を/etc/network/interfacesファイルに追加して、サーバーの実際のIPアドレスおよびネットマスク、そしてゲートウェイのIPアドレスを入力します。
    iface eth0 inet static
address IP address of server
netmask netmask of server
gateway gateway IP address of server
  9. eth0インタフェースを起動します。
    # ifup eth0

    警告メッセージは無視します。

  10. FTPまたはwgetコマンドを使用して、サーバーの修理に必要なファイルを取得します。

ストレージ・サーバーの物理ディスクの保守

この項の内容は次のとおりです。

関連項目:

保守のベスト・プラクティスの詳細は、http://www.oracle.com/goto/maaのOracle Maximum Availability Architecture (MAA) Webサイトを参照してください。

システム・ディスクおよびデータ・ディスクについて

ストレージ・サーバーの最初の2枚のディスクは、システム・ディスクです。ストレージ・サーバー・ソフトウェアのシステム・ソフトウェアは、各システム・ディスクに割り当てられます。システム・ディスクのこの割り当てられた部分は、システム領域と呼ばれます。システム・ディスクのシステム領域以外は、データ・パーティションと呼ばれ、通常のデータ・ストレージに使用されます。ストレージ・サーバーのその他のディスクはすべて、データ・ディスクと呼ばれます。

物理ディスクのステータスのモニタリング

CellCLI LIST PHYSICALDISKコマンドで属性を確認して、物理ディスクをモニターできます。たとえば、failedまたはwarning - predictive failureステータスの物理ディスクに問題が発生し、交換が必要と思われる場合です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、サーバー・ソフトウェアではなくドライブによって決定されます。

次のリストは、ストレージ・サーバーの物理ディスク・ステータスを示しています。

ストレージ・サーバーの物理ディスク・ステータス

  • 物理ディスク・ステータス
  • normal
  • normal - dropped for replacement
  • normal - confinedOnline
  • normal - confinedOnline - dropped for replacement
  • not present
  • failed
  • failed - dropped for replacement
  • failed - rejected due to incorrect disk model
  • failed - rejected due to incorrect disk model - dropped for replacement
  • failed - rejected due to wrong slot
  • failed - rejected due to wrong slot - dropped for replacement
  • warning - confinedOnline
  • warning - confinedOnline - dropped for replacement
  • warning - peer failure
  • warning - poor performance
  • warning - poor performance - dropped for replacement
  • warning - poor performance, write-through caching
  • warning - predictive failure, poor performance
  • warning - predictive failure, poor performance - dropped for replacement
  • warning - predictive failure, write-through caching
  • warning - predictive failure
  • warning - predictive failure - dropped for replacement
  • warning - predictive failure, poor performance, write-through caching
  • warning - write-through caching

ディスク・エラー発生時の状況

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は、パフォーマンスの低いディスクをアクティブ構成から自動的に識別して削除します。次に、リカバリ・アプライアンスで一連のパフォーマンス・テストが実行されます。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 ID date_time info "Hard disk entered confinement status. The LUN
 n_m changed status to warning - confinedOnline. CellDisk changed status to normal
 - confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
 Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release 
 Slot Number: m  Cell Disk: cell_disk_name  Grid 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

障害が発生した物理ディスクの交換

物理ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。したがって、できるだけ早く障害が発生したディスクを新しいディスクに交換します。

障害発生時にディスクを交換するには、次のようにします。

  1. 障害が発生したディスクを特定します。 
    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL

         name:                   28:5
         deviceId:               21
         diskType:               HardDisk
         enclosureDeviceId:      28
         errMediaCount:          0
         errOtherCount:          0
         foreignState:           false
         luns:                   0_5
         makeModel:              "SEAGATE ST360057SSUN600G"
         physicalFirmware:       0705
         physicalInterface:      sas
         physicalSerial:         A01BC2
         physicalSize:           558.9109999993816G
         slotNumber:             5
         status:                 failed

    スロット番号はディスクの場所、ステータスはディスクに障害が発生したことを示します。

  2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  3. ストレージ・サーバー上の物理ディスクを交換し、3分待ちます。物理ディスクはホット・プラガブルで、電源の投入時に交換できます。
  4. ディスクがオンラインでステータスがNORMALであることを確認します。
    CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status

    物理ディスクを交換する際、使用できるようになるには、RAIDコントローラが交換ディスクを認識する必要があります。認識はすぐに終了します。

  5. ファームウェアが正しいことを確認します。
    ALTER CELL VALIDATE CONFIGURATION

    ファームウェアが更新され、論理ユニット番号(LUN)が再ビルドされたことを確認するため、ms-odl.trcファイルも参照できます。

  6. そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクを再作成します。「データのリバランスについて」を参照してください。

関連項目:

障害のある物理ディスクの交換

ディスクがwarning - predictive failureステータスのため、物理ディスクの交換が必要な場合があります。このステータスは、物理ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。

交換する前にドライブに障害が発生した場合は、「障害が発生した物理ディスクの交換」を参照してください。

障害発生前にディスクを交換するには、次のようにします。

  1. 障害のあるディスクを特定します。
    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
        "warning - predictive failure" DETAIL

         name:                   28:3
         deviceId:               19
         diskType:               HardDisk
         enclosureDeviceId:      28
         errMediaCount:          0
         errOtherCount:          0
         foreignState:           false
         luns:                   0_3
         makeModel:              "SEAGATE ST360057SSUN600G"
         physicalFirmware:       0705
         physicalInterface:      sas
         physicalSerial:         E07L8E
         physicalSize:           558.9109999993816G
         slotNumber:             3
         status:                 warning - predictive failure

    前のコマンドの出力例で、スロット番号はディスクの場所、ステータスはディスクに障害が発生する可能性があることを示します。

  2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  3. 影響を受けるOracle ASMディスクが削除されるまで待機します。ステータスを確認するには、Oracle ASMインスタンスでV$ASM_DISK_STATビューに問合せを行います。

    注意:

    最初の2つのスロットのディスクは、オペレーティング・システムおよびリカバリ・アプライアンス・ストレージ・サーバー・ソフトウェアを格納するシステム・ディスクです。1つのシステム・ディスクを稼働して、サーバーを作動する必要があります。

    他のシステム・ディスクを交換する前に、ALTER CELL VALIDATE CONFIGURATIONにRAID mdadmエラーが表示されなくなるまで待機します。この出力は、システム・ディスクの再同期化が完了したことを示します。

    関連項目:

    V$ASM_DISK_STATビューの問合せの詳細は、『Oracle Databaseリファレンス』を参照してください。

  4. ストレージ・サーバー上の物理ディスクを交換し、3分待ちます。物理ディスクはホット・プラガブルで、電源の投入時に交換できます。
  5. ディスクがオンラインでステータスがNORMALであることを確認します。
    CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status

    物理ディスクを交換する際、使用できるようになるには、RAIDコントローラが交換ディスクを認識する必要があります。認識はすぐに終了します。

  6. ファームウェアが正しいことを確認します。
    ALTER CELL VALIDATE CONFIGURATION
  7. そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクを再作成します。「データのリバランスについて」を参照してください。

関連項目:

パフォーマンスの低い物理ディスクの取外し

不良物理ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。問題のあるディスクはシステムから取り外す必要があります。

不良ディスクの識別後に物理ディスクを削除するには、次のようにします。

  1. 物理ドライブ・サービスLEDを点灯し、交換するドライブを識別します。
    cellcli -e 'alter physicaldisk disk_name serviceled on'

    前述のコマンドでdisk_nameは、20:2などの交換する物理ディスクの名前です。

  2. 不良ディスク上のすべてのグリッド・ディスクを識別して、その使用を停止するようにOracle ASMに指示します。
    ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name
  3. ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  4. V$ASM_DISK_STATビューの問合せを実行して、不良ディスクの影響を受けるOracle ASMディスクが正しく削除されたことを確認します。
  5. 不良ディスクを取り外します。

    ディスクを削除すると、アラートが送信されます。

  6. 新しいディスクを使用できる場合、それをシステムに設置します。セル・ディスクおよびグリッド・ディスクが新しい物理ディスクに自動的に作成されます。
  7. ディスクがオンラインでステータスがNORMALであることを確認します。
    CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status

    物理ディスクを交換する際、使用できるようになるには、RAIDコントローラが交換ディスクを認識する必要があります。認識はすぐに終了します。

関連項目:

パフォーマンスの低いディスクの検出について

ストレージ・サーバーから別のストレージ・サーバーへのすべてのドライブの移動

ストレージ・サーバーから別のストレージ・サーバーへのすべてのドライブの移動が必要になることがあります。この状況になる可能性があるのは、マザーボードやOracle ILOMなどのシャーシレベルのコンポーネント障害がある場合、またはハードウェアの問題のトラブルシューティングを行う場合です。

ストレージ・サーバー間でドライブを移動するには、次のようにします。

  1. 次のディレクトリのファイルをバックアップします。

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

  2. すべてのグリッド・ディスクを非アクティブにして、ストレージ・サーバーを停止します。「ストレージ・サーバーの停止」を参照してください。
  3. 別のストレージ・サーバーでグリッド・ディスクをアクティブ化する前にOracle ASMによってディスクが削除されないように、Oracle ASMのdisk_repair_time属性に大きい値が設定されていることを確認してください。
  4. 物理ディスク、フラッシュ・ディスク、ディスク・コントローラおよびUSBフラッシュ・ドライブを元のストレージ・サーバーから新しいストレージ・サーバーに移動します。

    注意:

    • システム・ディスクの最初の2つのディスクが同じ最初の2つのスロットにあることを確認してください。そうしないと、ストレージ・サーバーが正常に機能しません。

    • フラッシュ・カードが元のストレージ・サーバーと同じPCIeスロットに設置されていることを確認してください。

  5. 新しいストレージ・サーバーの電源を投入します。サービス・プロセッサ・インタフェースを使用するか、電源ボタンを押すことができます。
  6. サービス・プロセッサを使用して、コンソールにログインします。
  7. 次のディレクトリのファイルを確認します。バックアップから破損ファイルをリストアします。

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

  8. ifconfigコマンドを使用して、eth0、eth1、eth2およびeth3の新しいMACアドレスを取得します。この例は、eth0 MACアドレス(HWaddr)が00:14:4F:CA:D9:AEであることを示しています。
    # ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:14:4F:CA:D9:AE
          inet addr:10.204.74.184  Bcast:10.204.75.255  Mask:255.255.252.0
          inet6 addr: fe80::214:4fff:feca:d9ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:141455 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6340 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9578692 (9.1 MiB)  TX bytes:1042156 (1017.7 KiB)
          Memory:f8c60000-f8c80000
  9. /etc/sysconfig/network-scriptsディレクトリで、次のファイルを編集してHWADDRをステップ8で返された値に変更します。
    • ifcfg-eth0
    • ifcfg-eth1
    • ifcfg-eth2
    • ifcfg-eth3

    次に、編集されたifcfg-eth0ファイルの例を示します。 

    #### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.204.74.184
NETMASK=255.255.252.0
NETWORK=10.204.72.0
BROADCAST=10.204.75.255
GATEWAY=10.204.72.1
HOTPLUG=no
IPV6INIT=no
HWADDR=00:14:4F:CA:D9:AE
  10. ストレージ・サーバーを再起動します。
  11. グリッド・ディスクをアクティブ化します。
    CellCLI> ALTER GRIDDISK ALL ACTIVE

    Oracle ASMディスクが削除されていなかった場合は、自動的にオンラインになって使用が開始されます。

  12. 構成を検証します。
    CellCLI> ALTER CELL VALIDATE CONFIGURATION
  13. ASRのOracle ILOMをアクティブ化します。

同じ物理ディスクの取外しおよび交換

誤った物理ディスクを取り外してそれを置き直した場合、Recovery ApplianceはそのディスクをOracle ASMディスク・グループに自動的に追加し直して、そのデータを再同期化します。

ノート:

障害のある、または障害が発生したディスクを交換する際は、ディスク上の点灯するLEDを探します。LEDの点灯によって、不良ディスクを特定することができます。

拒否された物理ディスクの再有効化

Recovery Applianceは、物理ディスクが誤ったスロット内にあるとそのディスクを拒否します。

注意:

物理ディスクの再有効化では、そのディスクに格納されたすべてのデータが削除されます。

  • 拒否された物理ディスクを再有効化するには、次のコマンドで、hard_disk_nameおよびhard_disk_idを適切な値に置き換えます。 

    CellCLI> ALTER PHYSICALDISK hard_disk_name/hard_disk_id reenable force
Physical disk hard_disk_name/hard_disk_id  was reenabled.

ストレージ・サーバーのフラッシュ・ディスクの保守

この項では、フラッシュ・ディスクの保守を実行する方法について説明します。内容は次のとおりです。

フラッシュ・ディスクについて

リカバリ・アプライアンスではストレージ・サーバー間でデータがミラー化され、少なくとも2つのストレージ・サーバーに書込み操作が送信されます。1つのストレージ・サーバーのフラッシュ・カードに問題が発生すると、リカバリ・アプライアンスでは別のストレージ・サーバーのミラー化されたデータを使用して読取りおよび書込み操作が実行されます。サービスは中断されません。

フラッシュ・カードに障害が発生すると、ストレージ・サーバー・ソフトウェアは、残存ミラーからデータを読み取り、フラッシュ・キャッシュのデータを確認します。次に、障害が発生したフラッシュ・カードのあるサーバーにデータが書き込まれます。障害の発生時、障害が発生したフラッシュ・キャッシュ内での損失データの場所がソフトウェアによって保存されます。復元では次に損失データがミラー・コピーに置き換えられます。復元中、グリッド・ディスクのステータスは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リバランスでデータの冗長性のリストアが開始されます。

関連項目:

障害ステータス・インジケータ

次のステータス・インジケータはアラートを生成します。アラートには、フラッシュ・ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。

warning - peer failure

同じ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
warning - predictive failure

フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

1つのフラッシュ・ディスクがpredictive failureステータスになると、データがコピーされます。ライトバック・フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクからグリッド・ディスクにデータがフラッシュされます。

warning - poor performance

フラッシュ・ディスクが極端に低いパフォーマンスを示しており、できるだけすぐに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、ストレージ・サーバーの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。

warning - write-through caching

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は、パフォーマンスの低いディスクをアクティブ構成から自動的に識別して削除します。次に、リカバリ・アプライアンスで一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。表12-2に、ディスク制限のトリガーとなる状況を示します。状況は、物理ディスクおよびフラッシュ・ディスクの両方とも同じです。

問題が一時的なものであり、ディスクがテストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。そうでない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。

ディスク・ステータスの変更はサーバー・アラート履歴に記録されます。

MESSAGE ID date_time info "Hard disk entered confinement status. The LUN
 n_m changed status to warning - confinedOnline. CellDisk changed status to normal
 - confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
 Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release 
 Slot Number: m  Cell Disk: cell_disk_name  Grid 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カードはホット・プラガブルではないため、フラッシュ・ディスクまたはカードを交換する前にストレージ・サーバーの電源を切断する必要があります。

次の手順を実行する前に、サーバーを停止します。「ストレージ・サーバーの停止」を参照してください。

障害が発生したフラッシュ・ディスクを交換するには、次のようにします。

  1. 障害が発生したフラッシュ・ディスクを交換します。PCI番号およびFDOM番号を使用して、障害が発生したディスクを特定します。白色のセルLEDが点灯し、影響を受けているサーバーを特定できます。
  2. サーバーの電源を投入します。サービスは自動的に開始されます。サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にオンラインになります。
  3. すべてのグリッド・ディスクがオンラインであることを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

関連項目:

障害のあるフラッシュ・ディスクの交換

注意:

PCIeカードはホット・プラガブルではないため、フラッシュ・ディスクまたはカードを交換する前にストレージ・サーバーの電源を切断する必要があります。

次の手順を実行する前に、「障害のあるフラッシュ・ディスクの安全な交換時期」のトピックを確認してください。

障害のあるフラッシュ・ディスクを交換するには、次のようにします。

  1. すべてのグリッド・ディスクのcachedBy属性をチェックするには、次のコマンドを使用します。 
    CellCLI> LIST GRIDDISK ATTRIBUTES name, cachedBy

    フラッシュ・ディスクのセル・ディスクは、グリッド・ディスクのcachedBy属性には表示されません。フラッシュ・ディスクをグリッド・ディスクとフラッシュ・キャッシュの両方に使用する場合は、アラートを受信し、セル・ディスクがグリッド・ディスクのcachedBy属性に表示されなくなるまで待機します。

  2. すべてのサービスを停止します。
    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ディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常になってからコマンドを再試行してください。

  3. サーバーを停止します。
    「ストレージ・サーバーの停止」を参照してください。
  4. 障害が発生したフラッシュ・ディスクを交換します。PCI番号およびFDOM番号を使用して、障害が発生したディスクを特定します。白色のセルLEDが点灯し、影響を受けているサーバーを特定できます。
  5. サーバーの電源を投入します。サービスは自動的に開始されます。サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にオンラインになります。
  6. すべてのグリッド・ディスクがオンラインであることを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

次のように、新しいフラッシュ・ディスクがシステムによって自動的に使用されます。

  • フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。

  • グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。

  • グリッド・ディスクがOracle ASMディスク・グループの一部だった場合は、ディスクはディスク・グループに追加し直されます。ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、データがそこでリバランスされます。

パフォーマンスの低いフラッシュ・ディスクの取外し

1つの不良フラッシュ・ディスクが、他の正常なフラッシュ・ディスクのパフォーマンスを低下させることがあります。問題のあるフラッシュ・ディスクは取り外す必要があります。「パフォーマンスの低いフラッシュ・ディスクの識別」を参照してください。

パフォーマンスの低いフラッシュ・ドライブを取り外すには、次のようにします。

  1. フラッシュ・ディスクがフラッシュ・キャッシュに使用される場合:

    1. ディスクと同期されていないデータ(ダーティ・データ)が、フラッシュ・キャッシュからグリッド・ディスクにフラッシュされるようにします。

      CellCLI> ALTER FLASHCACHE ... FLUSH

    2. フラッシュ・キャッシュを無効化して、新しいフラッシュ・キャッシュを作成します。フラッシュ・キャッシュを作成する場合、不良フラッシュ・ディスクを使用しないでください。

      CellCLI > DROP FLASHCACHE
CellCLI > CREATE FLASHCACHE CELLDISK='fd1,fd2,fd3,fd4, ...'

  2. グリッド・ディスクにフラッシュ・ディスクを使用する場合、不良ディスクの使用をすぐに停止するよう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

  3. 不良フラッシュ・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。フラッシュ・ディスクを安全に交換できるようになると、ストレージ・サーバー・ソフトウェアによって自動的にアラートが送信されます。

  4. サービスを停止します。

    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ディスク・グループの冗長性がリストアされます。すべてのディスクのステータスが正常のときはコマンドを再試行します。

  5. サーバーを停止します。「ストレージ・サーバーの停止」を参照してください。

  6. 不良フラッシュ・ディスクを取り外して、新しいフラッシュ・ディスクと交換します。

  7. サーバーの電源を投入します。サービスが自動的に開始されます。サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にオンラインになります。

  8. 新規フラッシュ・ディスクをフラッシュ・キャッシュに追加します。

    CellCLI> DROP FLASHCACHE
CellCLI> CREATE FLASHCACHE ALL

  9. すべてのグリッド・ディスクがオンラインであることを確認します。

    CellCLI> LIST GRIDDISK ATTRIBUTES asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

次のようにフラッシュ・ディスクが追加されます。

  • グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。

  • これらのグリッド・ディスクがOracle ASMディスク・グループの一部であり、DROP...FORCEをステップ2で使用した場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加し直され、データがリバランスされます。

  • ステップ2でDROP...NOFORCEが使用された場合、グリッド・ディスクをOracle ASMディスク・グループに手動で追加し直す必要があります。

ライトバック・フラッシュ・キャッシュについて

リカバリ・アプライアンスでライトバック・フラッシュ・キャッシュの設定を変更することはできません。

ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換

ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、計算サーバーおよびストレージ・サーバーのドライブ・トレイにあります。ディスク・コントローラBBUを停止時間なしで交換できます。次の手順では、ディスク・コントローラBBUを交換する方法について説明します。

ノート:

この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。

計算サーバーのディスク・コントローラBBUの交換

次の手順では、計算サーバーのディスク・コントローラBBUを交換する方法について説明します。

  1. 交換対象のディスク・コントローラBBUを削除します。
    # /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -drop_bbu_for_replacement
  2. 交換対象のディスク・コントローラBBUが削除されたことを確認します。
    # /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status

BBU status: dropped for replacement.
  3. ドライブ・キャディの固定を解除し、トレイをゆっくり引き出して、交換用のトレイをスロットの中にスライドさせることによって、ディスク・コントローラBBUを交換します。ディスク・コントローラBBUはスロット7にあります。
  4. 新しいディスク・コントローラBBUが検出されることを確認します。これは数分かかる場合があります。
    # /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status

BBU status: present
  5. 現在の論理ディスク・ドライブのキャッシュ・ポリシーでwritebackモードが使用されていることを確認します。 
    # /opt/MegaRAID/MegaCli/MegaCli64 -ldinfo -lall -a0 | egrep         \
'Default Cache|Current Cache'
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if
Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if
Bad BBU

    キャッシュ・ポリシーがwritebackになっていない場合は、ステップ6に進みます。そうでない場合は、ステップ7に進みます。

  6. バッテリ状態がOperationalであることを確認します。このステップは、ステップ5のキャッシュ・ポリシー出力がwritebackでない場合にのみ必要です。
    # /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -getbbustatus -a0|grep Battery 
BatteryType: iBBU08
Battery State : Operational
Battery Pack Missing : No
Battery Replacement required : No

    バッテリ状態がOperationalでない場合は、問題を調査して修正してください。

  7. My Oracle Support Doc ID 1274318.1の説明に従って、バッテリ・チェックを実行します。このチェックによって予期しない結果が返された場合は、ノートで追加情報および指示を確認してください。
  8. (オプション) exachkツールを使用してシステムの状態を検証します。My Oracle Support Doc ID 1070954.1を参照してください。

ストレージ・サーバーのディスク・コントローラBBUの交換

ストレージ・サーバーのディスク・コントローラBBUを交換するには、次のようにします。

  1. 次のコマンドを使用して、交換対象のディスク・コントローラBBUを削除します。
    # cellcli -e alter cell bbu drop for replacement
  2. 次のコマンドを使用して、交換対象のディスク・コントローラBBUが削除されたことを確認します。
    # cellcli -e list cell attributes bbustatus

BBU status: dropped for replacement.
  3. ドライブ・キャディの固定を解除し、トレイをゆっくり引き出して、交換用のトレイをスロットの中にスライドさせることによって、ディスク・コントローラBBUを交換します。ディスク・コントローラBBUは、サーバーの後部スロット1にあります。
  4. ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
    # cellcli -e list cell attributes bbustatus

BBU status: normal
  5. My Oracle Support Doc ID 1274318.1の説明に従って、バッテリ・チェックを実行します。このチェックによって予期しない結果が返された場合は、ノートで追加情報および指示を確認してください。
  6. (オプション) exachkツールを使用してシステムの状態を検証します。このツールはMy Oracle Support Doc ID 1070954.1から入手できます。

ストレージ・サーバーのレスキュー手順の使用

各ストレージ・サーバーはソフトウェアのコピーをUSBスティックに保管します。システム構成が変更されるときは常にサーバーがUSBスティックを更新します。このUSBスティックは、ハードウェア交換またはソフトウェア障害の後のサーバーのリカバリに使用できます。システムをリストアするのは、システム・ディスクに障害が発生した場合、オペレーティング・システムに破損ファイル・システムがある場合、または起動エリアがダメージを負っている場合です。ディスク、カード、CPU、メモリーなどを交換して、サーバーをリカバリすることができます。USBスティックを別のサーバーに挿入すると、そのサーバーで古いサーバーが複製されます。

1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、ストレージ・サーバーのCELLBOOT USBフラッシュ・ドライブで提供されるレスキュー機能を使用します。

この項の内容は次のとおりです。

ストレージ・サーバーのレスキュー前の最初のステップ

ストレージ・サーバーのレスキュー前に、そのサーバーに格納されているデータを保護するためのステップを踏む必要があります。このステップは、システムが通常の冗長性または高い冗長性のどちらで設定されているかによって異なります。

サーバーに通常の冗長性がある場合

通常の冗長性を使用している場合、サーバーにあるミラー・コピーは1つです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。

ミラー・コピーの複製を作成することをお薦めします。

  1. ミラー・コピーのデータの完全なバックアップを作成します。

  2. ただちにミラー・コピー・サーバーをオフラインにします。これによって、レスキューを始める前の新たなデータの変更を防ぎます。

この手順により、レスキュー・プロセス中は、障害が発生したサーバーのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。

Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスします。

関連項目:

タイマーのリセットの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。

サーバーに高い冗長性がある場合

サーバーに高い冗長性のディスク・グループがあり、障害が発生したサーバーのすべてのグリッド・ディスクに対する複数のミラー・コピーがOracle ASMにあるような場合は、障害が発生したセルをオフラインにします。Oracle ASMのタイムアウト時間が過ぎると、破損したサーバーのグリッド・ディスクが自動的に削除され、ミラー・コピーを使用してデータのリバランスが開始されます。

デフォルトのタイムアウトは、2時間です。サーバーのレスキューに2時間以上かかる場合、Oracle ASMのレスキュー・セルのグリッド・ディスクを再作成する必要があります。

レスキュー手順について

レスキュー手順を使用する前に、次の点に注意してください。

  • レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失うおそれがあります。レスキューを開始する前に、必ず適切な事前ステップを済ませておいてください。「サーバーに通常の冗長性がある場合」または「サーバーに高い冗長性がある場合」を参照してください。

  • この手順を使用する場合は十分に注意し、プロンプトを確認してください。一部またはすべてのディスクのデータを損失してもかまわない場合にOracleサポート・サービスの支援だけでレスキュー手順を使用することが理想的です。

  • レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。

  • レスキュー手順は、最後の正常な起動中にサーバー上に存在したパッチを含めて、ストレージ・サーバー・ソフトウェアを同じリリースにリストアします。

  • レスキュー手順は次の構成設定をリストアしません。

    • アラート構成、SMTP情報、管理者の電子メール・アドレスなどのサーバー構成

    • ILOM構成。ただし、サーバー・ソフトウェアに障害が発生してもILOM構成は一般的に損われません。

  • リカバリ手順は次の構成設定をリストアします。

  • レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、このレスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。

レスキューが正常に完了したら、サーバーを再構成する必要があります。データを保存する場合は、セル・ディスクをインポートします。それ以外の場合は、新規のセル・ディスクおよびグリッド・ディスクを作成します。

関連項目:

CellCLIユーティリティを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください

CELLBOOT USBフラッシュ・ドライブを使用したサーバーのレスキュー

注意:

データを損失しないように注意して、レスキュー手順に従います。

CELLBOOT USBフラッシュ・ドライブを使用してサーバーをレスキューするには、次のようにします。

  1. レスキューされるサーバーのOracle ILOMサービス・プロセッサ(SP)に接続します。HTTPSまたはSSHを使用できます。
  2. サーバーを起動します。スプラッシュ画面が表示されたらすぐに、キーボードの任意のキーを押します。スプラッシュ画面の表示は、5秒間のみです。
  3. ブート・オプションの表示リストで、最後のオプションのCELL_USB_BOOT_CELLBOOT_usb_in_rescue_modeを選択し、[Enter]を押します。
  4. レスキュー・オプションを選択して、レスキュー手順に進みます。
  5. レスキューの第一フェーズの最後で、シェルに入るオプションを選択します。システムを再起動しないでください
  6. レスキューのrootパスワードを使用してシェルにログインします。
  7. シェルからrebootコマンドを使用します。
  8. サーバーが再起動したら、スプラッシュ画面が表示される前に[F8]を押します。F8キーを押すと、起動デバイス選択メニューが開きます。
  9. 起動デバイスとしてRAIDコントローラを選択します。これにより、サーバーがハード・ディスクからブートされるようになります。

ノート:

機能が制限されたレスキュー・モードのLinuxログイン・シェルを入力できる追加オプションを使用できる場合があります。Oracleサポート・サービスから提供されたパスワードを使用してrootユーザーとしてシェルにログインして、サーバーの追加診断および修復を手動で実行できます。詳細は、Oracleサポート・サービスの担当者に連絡してください。

レスキューされたストレージ・サーバーの再構成

レスキューが成功した後、サーバーを構成する必要があります。データ・パーティションを維持した場合は、レスキュー手順の実行時にセル・ディスクが自動的にインポートされます。

  1. 交換したサーバーについては、セル・ディスクおよびグリッド・ディスクを再作成します。
  2. Oracle ASMインスタンスにログインし、次のコマンドを使用して各ディスク・グループのディスクをONLINEに設定します。
    SQL> ALTER DISKGROUP disk_group_name ONLINE DISKS IN FAILGROUP \
cell_name WAIT;
  3. ALTER CELLコマンドを使用して、セルを再構成します。次に、最も一般的なパラメータの例を示します。
    CellCLI> ALTER CELL
smtpServer='my_mail.example.com', -
smtpFromAddr='john.doe@example.com', -
smtpFromPwd=email_address_password, -
smtpToAddr='jane.smith@example.com', -
notificationPolicy='critical,warning,clear', -
notificationMethod='mail,snmp'
  4. I/Oリソース管理(IORM)プランを再作成します。
  5. メトリックしきい値を再作成します。

関連項目:

IORMプランおよびメトリックしきい値の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

損傷したCELLBOOT USBフラッシュ・ドライブの再作成

CELLBOOT USBフラッシュ・ドライブの紛失または損傷が発生した場合、新しいドライブを作成できます。

CELLBOOTフラッシュ・ドライブを作成するには、次のようにします。

  1. rootユーザーとして、サーバーにログインします。
  2. 1GBから8GBの容量の新しいUSBフラッシュ・ドライブを取り付けます。
  3. システムから他のUSBフラッシュ・ドライブを取り外します。
  4. ディレクトリを変更します。
    cd /opt/oracle.SupportTools
  5. サーバー・ソフトウェアをフラッシュ・ドライブにコピーします。
    ./make_cellboot_usb -verbose -force