リカバリ・アプライアンス拡張の準備
ラックを拡張する前に、配線要件を確認し、現在のラックに関する情報を収集します。この項には次のトピックが含まれます:
RDMAネットワーク・ファブリックのケーブル経路の長さの見積り
設置に必要な本数と長さのRDMAネットワーク・ファブリックのケーブルがあることを確認します。ケーブル経路はできるだけ短くしてください。ケーブル経路の長さを計算したら、経路が長くなる可能性がある次の状況を考慮してください。その上で、必要な長さを満たす一番短いケーブルを選択します。
次の点を考慮してください:
-
ケーブル経路にカーブがある場合、ケーブルに必要な長さが増加します。ケーブルがコネクタ同士を直線で接続できることはめったにありません。ケーブル経路にカーブが必要ですが、カーブによって全体の長さが増加します。
-
結束すると、必要なケーブル長が長くなります。結束すれば、1本または複数のケーブルが同じ経路を使用することになります。ただし、ケーブルの結束内の位置によって、曲げ半径が異なります。結束が大きくてまとまっておらず、カーブがたくさんある場合、カーブの内側にのみ曲がるケーブルもあれば、外側にのみ曲がるケーブルもでてきます。この場合、必要なケーブル長の差はかなり大きくなります。
-
床下にRDMAネットワーク・ファブリックのケーブル経路を設定している場合、ケーブル経路の長さを計算する際は上げ床の高さを考慮してください。
現在の構成情報の取得
リカバリ・アプライアンス・ラックの現在の構成は、パッチ適用要件の計画、新しいIPアドレスの構成などに使用します。
ラックの1台目の計算サーバーにログインし、次の情報を収集します。
-
ラックの
exachk
レポート。exachk
ユーティリティの詳細は、My Oracle SupportのドキュメントID 1070954.1を参照してください。 -
# dcli -g ~/all_group -l root "imagehistory" > imagehistory.txt
-
すべてのストレージ・サーバーおよび計算サーバーの現在のIPアドレス。次のコマンドを使用します。
# dcli -g ~/all_group -l root "ifconfig" > ifconfig_all.txt
-
ストレージ・サーバーの構成、ディスク、フラッシュ・ログおよびIORM計画。次のコマンドを使用します。
# dcli -g ~/cell_group -l root "cellcli -e list cell detail" > cell_detail.txt # dcli -g ~/cell_group -l root "cellcli -e list physicaldisk detail" > \ physicaldisk_detail.txt # dcli -g ~/cell_group -l root "cellcli -e list griddisk attributes name,offset,size,status,asmmodestatus,asmdeactivationoutcome" > griddisk.txt # dcli -g ~/cell_group -l root "cellcli -e list flashcache detail" > fc_detail.txt # dcli -g ~/cell_group -l root "cellcli -e list flashlog detail" > fl_detail.txt # dcli -g ~/cell_group -l root "cellcli -e list iormplan detail" > iorm_detail.txt
-
計算サーバーのHugePagesメモリー構成。次のコマンドを使用します。
dcli -g ~/dbs_group -l root "cat /proc/meminfo | grep 'HugePages'" > hugepages.txt
-
InfiniBandスイッチの情報。次のコマンドを使用します。
# ibswitches > ibswitches.txt
-
Sun Datacenter InfiniBand Switch 36スイッチのファームウェア・バージョン。各スイッチで
nm2version
コマンドを実行します。 -
ラックの1台目の計算サーバーにある次のネットワーク・ファイル。
-
/etc/resolv.conf
-
/etc/ntp.conf
-
/etc/network
-
/etc/sysconfig/network-scripts/ifcfg-*
-
-
新しいサーバーで作成する必要があるクラスタ管理サービス用に作成された任意のユーザー、ユーザー識別子、グループおよびグループ識別子。
-
/etc/passwd
-
/etc/group
-
-
現在のクラスタのステータス。次のコマンドを使用します。
# crsctl stat res -t > crs_stat.txt
-
グリッド・インフラストラクチャおよびOracleホームからのパッチ情報。グリッド・インフラストラクチャ・ホームおよびOracleホームの所有者として、次のコマンドを実行します。
/u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch lsinventory -oh \ GRID_HOME -detail -all_nodes > opatch_grid.txt /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch lsinventory -oh \ ORACLE_HOME -detail -all_nodes >> opatch_oracle.txt
このコマンドのGRID_HOMEは、グリッド・インフラストラクチャ・ホーム・ディレクトリのパスで、ORACLE_HOMEはOracleホーム・ディレクトリのパスです。
ネットワーク構成ファイルの生成
新しいサーバーのIPアドレスをリストするには、Oracle Exadata Deployment Assistantを使用します。新しいサーバーの数のみ指定します。Oracleホームの場所や所有者など、その他すべての項目を既存のラック構成と同じように定義します。特に、新しいサーバーのボンディング構成は、ラック内の既存のサーバーと一致する必要があります。ボンディングのタイプは、Oracle Exadata Deployment Assistantの「インフィニバンド・ネットワーク構成」ページで選択できます。
リカバリ・アプライアンス・ソフトウェアは、新しいストレージ・サーバーをラックに設置した後にインストールする必要があります。
監査ファイルおよび診断ファイルの移動
$GRID_HOME/rdbms/audit
ディレクトリおよび$GRID_HOME/log/diagnostics
ディレクトリのファイルは、クラスタを拡張する前に移動して削除する必要があります。十分に時間をかけられるよう、拡張予定の1日または2日前にこのタスクを実行することをお薦めします。
リリースおよびパッチ・レベルの同期
追加先のラックよりも、サーバーのリリースまたはパッチ・レベルの方が新しいということが多々あります。ラックを今よりも新しいリリースに更新するか、新しいサーバーが現在のラックに一致するよう再イメージ化することが可能です。どちらの場合でも、すべてのサーバーおよびすべてのSun Datacenter InfiniBand Switch 36スイッチが同じパッチ・レベルになるようにしてください。
また、グリッド・インフラストラクチャとデータベース・ホームのリリース、およびバンドル・パッチ更新の対応方法も考慮してください。新しいパッチを適用する場合は、既存のサーバーを更新し、拡張手順の一環として新しいサーバーにそのリリースが継承されるようにすることをお薦めします。そうすることで、パッチを適用するサーバーが少なくなります。あらかじめ既存のサーバーにパッチを適用しておくと、拡張の最中に実行を必要とする作業の全体量を減らせます。