プライマリ・コンテンツに移動

Oracle® Big Data Applianceオーナーズ・ガイド リリース4 (4.6) E79718-01 |
| 目次 | 索引

前 | 次 |

# 12 サーバー・ディスクの交換

ディスクの障害がOracle Big Data Applianceにとって致命的になることはありません。ユーザー・データは何も失われません。HDFSまたはOracle NoSQL Databaseに格納されているデータは、自動的にレプリケートされます。

この章は次の項で構成されています:

- ディスク交換プロセスの概要

- ディスク・ドライブ識別子について

- 障害ディスクを交換するための前提条件

- サーバーが再起動しない場合の対処方法

- ディスク・ドライブの交換

- マウントされているパーティションのエラーの修正

- ディスク・ドライブの機能の識別

- オペレーティング・システム・ディスクの構成

- HDFSディスクまたはOracle NoSQL Databaseディスクの構成

- ディスク構成の確認

関連項目:

My Oracle SupportドキュメントID 1581331.1 My Oracle SupportドキュメントID 1581331.1

## 12.1 ディスク交換プロセスの概要

次に、サーバー・ディスク・ドライブを交換するための基本手順を示します。

1. 障害ディスク・ドライブを交換します。
2. 新しいディスクの基本構成手順を実行します。
3. 障害ディスクの固有の機能がオペレーティング・システム・ディスク、HDFSディスクまたはOracle NoSQL Databaseディスクのいずれであるかを識別します。
4. ディスクをその固有の機能用に構成します。
5. 構成が正しいことを確認します。
6. Oracle Big Data Applianceソフトウェアをインストールします。

関連項目:

次の場所にあるOracle Server X6-2Lサービス・マニュアルのストレージ・ドライブおよびリア・ドライブの修理に関する項

`http://docs.oracle.com/cd/E62172_01/html/E62184/z400001c165586.html#scrolltoc`

次の場所にあるOracle Server X5-2Lサービス・マニュアルのストレージ・ドライブおよびリア・ドライブの修理に関する項

`http://docs.oracle.com/cd/E41033_01/html/E48325/cnpsm.z40000091011460.html#scrolltoc`

次の場所にあるSun Fire X4270 M2 Serverサービス・マニュアルのストレージ・ドライブおよびブート・ドライブの修理に関する項を参照してください。

`http://docs.oracle.com/cd/E19245-01/E21671/hotswap.html#50503714_61628`

## 12.2 ディスク・ドライブ識別子について

Oracle Big Data Applianceサーバーには、ホスト・バス・アダプタ(HBA)によって制御されるディスク・エンクロージャ・ケージが含まれます。エンクロージャには、スロット番号0から11で識別される12のディスク・ドライブがあります。ドライブは、表12-1に示すような固有の機能専用にすることができます。

Oracle Big Data Applianceでは、ディスクのスロット番号を識別するために、`/dev/disk/by_hba_slot`で定義されるシンボリック・リンクを使用します。リンクの形式は、snpmであり、nはスロット番号、mはパーティション番号です。たとえば、`/dev/disk/by_hba_slot/s0p1`は初期状態で`/dev/sda1`に対応します。

ディスクがホット・スワップされる場合、オペレーティング・システムでは、カーネル・デバイス名を再利用できません。かわりに、新しいデバイス名が割り当てられます。たとえば、`/dev/sda`をホット・スワップすると、`/dev/disk/by-hba-slot/s0`に対応するディスクは、`/dev/sda`のかわりに`/dev/sdn`にリンクされます。したがって、`/dev/disk/by-hba-slot/`のリンクは、デバイスの追加または削除時に自動的に更新されます。

コマンド出力では、デバイス名がシンボリック・リンク名ではなくカーネル・デバイス名でリストされます。つまり、`/dev/disk/by-hba-slot/s0`は、コマンド出力では`/dev/sda`として識別される場合があります。

### 12.2.1 標準ディスク・ドライブ・マッピング

表12-1に、RAID論理ドライブとオペレーティング・システム識別子との間の通常の初期マッピングを示します。ただし、システムに存在するマッピング(ここにリストしたものとは異なる可能性があります)を使用する必要があります。表には、Oracle Big Data Applianceサーバーの各ドライブの専用機能も示します。障害ドライブのあるサーバーは、CDHクラスタ(HDFS)またはOracle NoSQL Databaseクラスタの一部です。

表12-1 ディスク・ドライブ識別子

物理スロットに対するシンボリック・リンク | 一般的な初期カーネル・デバイス名 | 固有の機能
--- | --- | ---
/dev/disk/by-hba-slot/s0 | /dev/sda | オペレーティング・システム
/dev/disk/by-hba-slot/s1 | /dev/sdb | オペレーティング・システム
/dev/disk/by-hba-slot/s2 | /dev/sdc | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s3 | /dev/sdd | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s4 | /dev/sde | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s5 | /dev/sdf | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s6 | /dev/sdg | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s7 | /dev/sdh | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s8 | /dev/sdi | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s9 | /dev/sdj | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s10 | /dev/sdk | HDFSまたはOracle NoSQL Database
/dev/disk/by-hba-slot/s11 | /dev/sdl | HDFSまたはOracle NoSQL Database

### 12.2.2 標準マウント・ポイント

表12-2に、HDFSパーティションとマウント・ポイントとの間のマッピングを示します。

表12-2 マウント・ポイント

物理スロットおよびパーティションに対するシンボリック・リンク | HDFSパーティション | マウント・ポイント
--- | --- | ---
/dev/disk/by-hba-slot/s0p4 | /dev/sda4 | /u01
/dev/disk/by-hba-slot/s1p4 | /dev/sdb4 | /u02
/dev/disk/by-hba-slot/s2p1 | /dev/sdc1 | /u03
/dev/disk/by-hba-slot/s3p1 | /dev/sdd1 | /u04
/dev/disk/by-hba-slot/s4p1 | /dev/sde1 | /u05
/dev/disk/by-hba-slot/s5p1 | /dev/sdf1 | /u06
/dev/disk/by-hba-slot/s6p1 | /dev/sdg1 | /u07
/dev/disk/by-hba-slot/s7p1 | /dev/sdh1 | /u08
/dev/disk/by-hba-slot/s8p1 | /dev/sdi1 | /u09
/dev/disk/by-hba-slot/s9p1 | /dev/sdj1 | /u10
/dev/disk/by-hba-slot/s10p1 | /dev/sdk1 | /u11
/dev/disk/by-hba-slot/s11p1 | /dev/sdl1 | /u12

### 12.2.3 ディスク・ドライブの物理スロット番号の取得

次の`MegaCli64`コマンドを使用して、仮想ドライブ番号と物理スロット番号のマッピングを確認します。「ディスク・ドライブの交換」を参照してください。

    # MegaCli64 LdPdInfo a0 | more

## 12.3 障害ディスクを交換するための前提条件

予測障害状態にあるHDFSディスクまたはオペレーティング・システム・ディスクを交換するには、最初にHDFSパーティションをディスマウントする必要があります。オペレーティング・システム・ディスクを交換する前には、スワッピングを無効にする必要もあります。

注意:

HDFSパーティションのみをディスマウントしてください。オペレーティング・システム・ディスクの場合、オペレーティング・システム・パーティションをディスマウントしないでください。HDFSには、オペレーティング・システム・ディスクのパーティション4 (sda4またはsdb4)のみを使用します。

HDFSパーティションをディスマウントするには、次の手順を実行します。

1. 障害ドライブのあるサーバーにログインします。

2. 障害ドライブがオペレーティング・システムをサポートしている場合、スワッピングを無効にします。

       # bdaswapoff

   アクティブなスワッピングが存在するディスクを削除すると、カーネルがクラッシュします。

3. マウントされているHDFSパーティションをリストします。

       # mount -l

       /dev/md2 on / type ext4 (rw,noatime)
       proc on /proc type proc (rw)
       sysfs on /sys type sysfs (rw)
       devpts on /dev/pts type devpts (rw,gid=5,mode=620)
       /dev/md0 on /boot type ext4 (rw)
       tmpfs on /dev/shm type tmpfs (rw)
       /dev/sda4 on /u01 type ext4 (rw,nodev,noatime) [/u01]
       /dev/sdb4 on /u02 type ext4 (rw,nodev,noatime) [/u02]
       /dev/sdc1 on /u03 type ext4 (rw,nodev,noatime) [/u03]
       /dev/sdd1 on /u04 type ext4 (rw,nodev,noatime) [/u04]
            .
            .
            .

4. 障害ディスクでマウントされているパーティションのリストを確認します。ディスクのパーティションがリストされていない場合、「ディスク・ドライブの交換」に進みます。そうではない場合、次の手順に進みます。

   注意:

   オペレーティング・システム・ディスクの場合、パーティション4 (sda4またはsdb4)を見つけます。オペレーティング・システム・パーティションはディスマウントしないでください。

5. 障害ディスクのHDFSマウント・ポイントをディスマウントします。

       # umount mountpoint

   たとえば、`umount /u11`によって、パーティション`/dev/sdk1`のマウント・ポイントが削除されます。

   `umount`コマンドに成功した場合、「ディスク・ドライブの交換」に進みます。`umount`コマンドがデバイス・ビジー・メッセージで失敗した場合、パーティションはまだ使用中です。次の手順に進みます。

6. Cloudera Managerのブラウザ・ウィンドウを開きます。次に例を示します。

   `http://bda1node03.example.com:7180`

7. Cloudera Managerで次の手順を実行します。

   注意:

   次の手順に従ってCloudera Managerでマウント・ポイントを削除する場合、他のすべての構成手順が終了した後に、Cloudera Managerでこれらのマウント・ポイントをリストアする必要があります。

   1. `admin`としてログインします。

   2. 「Services」ページで、「hdfs」をクリックします。

   3. 「Instances」サブタブをクリックします。

   4. 「Host」列で、障害ディスクのあるサーバーを特定します。次に、「Name」列のサービス(datanodeなど)をクリックしてそのページを開きます。

   5. 「Configuration」サブタブをクリックします。

   6. 「Directory」フィールドからマウント・ポイントを削除します。

   7. 「Save Changes」をクリックします。

   8. 「Actions」リストから、「Restart this DataNode」を選択します。

8. Cloudera Managerで、`NodeManager Local Directories`からマウント・ポイントを削除します。

   1. 「Services」ページで、「Yarn」をクリックします。

   2. 「Status Summary」で、「NodeManager」をクリックします。

   3. リストから、障害ディスクのあるホスト上のNodeManagerをクリックして選択します。

   4. 「Configuration」サブタブをクリックします。

   5. NodeManagerからマウント・ポイントを削除します。

   6. 「Save Changes」をクリックします。

   7. NodeManagerを再起動します。

9. 同じHDFSマウント・ポイント(HBase Region Serverなど)にデータを格納する他のロールを追加した場合は、これらのロールに対するマウント・ポイントも同様に削除してリストアします。

10. 障害ドライブのあるサーバーのセッションに戻ります。

11. `umount`コマンドを再発行します。

        # umount mountpoint

    `umount`がまだ失敗する場合、`lsof`を実行して、HDFSマウント・ポイントの下で開かれているファイルとそれらを開いたプロセスをリストします。これはunmountを妨げているプロセスを特定するのに役立ちます。次に例を示します。

        # lsof | grep /u11

12. ディスクをオフラインにします。

        # MegaCli64 PDoffline "physdrv[enclosure:slot]" a0

    たとえば、`"physdrv[20:10]"`はディスクs11を示します。これは、エンクロージャ20のスロット10にあります。

13. コントローラ構成表からディスクを削除します。

        MegaCli64 CfgLDDel Lslot a0

    たとえば、L10はスロット10を示します。

14. 「ディスク・ドライブの交換」の手順を完了します。

### 12.3.1 bdacli

Oracle Big Data Applianceコマンドライン・インタフェース(`bdacli`)は、ラック、クラスタ、サーバー、インフィニバンド・ネットワークおよびソフトウェア・パッチに関する情報を返すために様々な構成ファイルを問い合せます。

`bdacli`ユーティリティは、パッチおよびオプション・サービスの追加と削除も実行します。重要なノード間における重要なサービスの移行や、クラスタに対するサーバーの追加および削除も実行できます。

コマンドラインにパラメータが含まれていないか、または値が未定義の場合、`bdacli`ユーティリティには使用方法の情報が表示されます。

構文

    bdacli action [parameters]

アクション

help

  bdacliの一般的な使用方法の情報、アクションのリスト、および`getinfo`アクションでサポートされているパラメータのリストを表示します。

{add | remove} patch patch_number

  Oracle Big Data Applianceで、patch_numberと一致するソフトウェア・パッチを追加または削除します。`add`または`remove`を使用するには、`root`としてログインする必要があります。

admin_cluster parameter node_name

  障害のあるサーバーに応じて、クラスタのノードを管理できます。表13-1はパラメータの説明です。

  表12-3 bdacliのadmin_clusterのパラメータ

  パラメータ | 説明
  --- | ---
  `decommission` | 指定したノードをクラスタから削除し、Cloudera Managerでサーバーをデコミッションします。また、Mammothファイルを更新します。 デコミッションできるのは、障害のある、重要性の低いノードです。ノード上のクリティカル・サービスを最初に移動する必要があることに注意してください。このパラメータは、メンテナンスのためにクラスタからノードを一時的に除外するためのもので、クラスタからノードを削除する手段ではありません。
  `recommission` | デコミッションされたノードのリストからノードを削除し、Cloudera Managerでサーバーをリコミッションします。このコマンドを使用するのは、障害のあるノードをデコミッションして修理した後です。
  `migrate` | 重要なノードから重要性の低いノードにサービスを移動し、Cloudera Managerで障害のあるサーバーをデコミッションします。障害のある重要なノードの名前を指定すると、ユーティリティによって重要性の低いノードが移行用に選択されます。移行が完了すると、新しいノードは元の重要なノードと同じすべての機能を持ちます。 移行できるのは重要なノードのみです。また、これを行うのは、重要なノードに障害が発生した場合のみにします。
  `reprovision` | サーバーを重要性の低いノードとしてクラスタに戻し、Cloudera Managerでサーバーをリコミッションします。このコマンドを使用するのは、重要なノードのサービスを移行し、障害のあるサーバーを修理した後です。

{enable | disable} service

  Oracle Big Data Applianceのオプションのソフトウェア・コンポーネントを有効化または無効化します。`enable`または`disable`を使用するには、`root`としてログインする必要があります。

  表13-2では、コンポーネント・パラメータについて説明します。

  表12-4 bdacliのenableまたはdisableのサービス・パラメータ

  パラメータ | 説明
  --- | ---
  `asr` | 自動サービス・リクエスト
  `auditvault` | Oracle Audit Vault and Database Firewallプラグイン
  `bdc` | Oracle Big Data Connectors
  `bdd` | Oracle Big Data Discovery
  `big_data_sql` | Oracle Big Data SQL
  `em` | Oracle Enterprise Manager Cloud Controlエージェント
  `disk_encryption` | 既存のeCryptfs暗号化を無効にします。`disable`のみ。このパラメータに対する`enable`アクションはありません。hdfs_transparent_encryptionパラメータを使用して保存データを暗号化するオプションがあります。
  `hdfs_transparent_encryption` | クラスタ上のHDFS透過的暗号化。 BDAにKey Trustee Serverの設定を行うか尋ねられますので、「Yes」または「No」を選択します。「No」を選択した場合、アクティブおよびパッシブKey Trustee Serverのアドレスに加えて、Key Trustee組織および認可コードの入力を求められます。「Yes」を選択した場合、Key Trustee Serverはあらかじめ定められた構成でOracle Big Data Applianceに設定されます。 Kerberosが必要です。重要な前提条件と手順の詳細は、My Oracle Supportのドキュメント2111343.1を参照してください。 初期構成の後、KMS/KTSサーバーの起動および停止はCloudera Manager経由でのみ行えます。 Mammothはエッジ・ノードに直接アクセスできないため、これらのノードに対するKMSサービスの設定または検出を行うことができません。ユーザーは、エッジ・ノード上でKMSサービスを設定できます。これらは、Key Trustee Serverへのアクセスが必要なサービスとして同じクラスタに存在している必要があります。Clouderaによるこのアーキテクチャの説明を参照してください。
  `ad_kerberos` | Active Directory Kerberos。「Encrypt Hadoop Services」および「Encrypt HDFS Data Transport」機能を有効にするかどうかの選択を求めるプロンプトも表示します。 `disable`オプションは、これらのサービスとad_kerberosを無効にします。 重要な準備ステップがあります。MOS (My Oracle Support)のドキュメント2013585.1および2029378.1を参照してください。
  `kerberos` | MIT Kerberos。「Encrypt Hadoop Services」および「Encrypt HDFS Data Transport」機能を有効にするかどうかの選択を求めるプロンプトも表示します。disableオプションは、これらのサービスとMIT Kerberosを無効にします。 このパラメータは、Active Directory Kerberosを制御しません。この表の`ad_kerberos`を参照してください。
  `https_cm_hue_oozie` | Cloudera Manager、HueおよびOozieのHTTPS。disableオプションはありません。Kerberosが必要です。
  `hdfs_encrypted_data_transport` | DataNodeとクライアント間、およびDataNode間のデータ転送の暗号化。Kerberosが必要です。
  `hadoop_network_encryption` | HDFSおよびYARNのHTTPS暗号化およびKerberos認証。YARNに対して暗号化されたWebシャッフルも有効にします。Sparkのシャッフル、MapReduceの中間ファイル、mapおよびreduceの操作、ならびにImpala SQLから非HFDSディスク・ストレージへのデータ・スピルも暗号化されます。 Kerberosが必要です。
  `sentry` | Apache Sentry認証

  注意:

  HDFS透過的暗号化が無効になっている場合、クラスタのHDFS透過的暗号化ゾーンに格納されたデータは暗号化されたままになるため、アクセスできません。データへのアクセスを復元するには、同じキー・プロバイダを使用してHDFS透過的暗号化を再度有効にします。

{start | stop | restart | status} service

  クラスタまたは特定のノードのサービスを開始、停止、再開します。またはサービスの現在のステータスを返します。

  表13-3では、サービス・パラメータについて説明します。

  表12-5 BDACLIのstart、stop、restartのパラメータ

  パラメータ | 説明
  --- | ---
  `big_data_sql_cluster` | クラスタのすべてのノードのOracle Big Data SQL
  `big_data_sql_server` `node_name` | クラスタの指定したノードのOracle Big Data SQL。 このパラメータとともに`bdacli`を使用するのは、現在の`config.json`ファイルが格納されている、クラスタの第1ノードからに限定されます。

reset scope_parameter network_parameter

  指定された範囲内のネットワークを再構成します。ネットワークの構成では、IPアドレス、サブネット、ドメインおよびDNSを設定します。クライアント・ネットワークやプライベート・ネットワークなどの仮想アダプタの場合は、VNICが削除され、新しいIPアドレスで再作成されます。

  `root`権限が必要です。

  例:

      bdacli reset server admin_network
      bdacli reset cluster client_network
      bdacli reset cluster private_network
      bdacli reset server all_networks

  表12-6 BDACLIのresetの範囲パラメータ

  範囲パラメータ | 説明
  --- | ---
  `server` | このアクションは、コマンドが実行されたノードに対して実行されます。
  `cluster` | このアクションは、クラスタ内のすべてのノードに対して実行されます。
  `rack` | このアクションは、ラック内のすべてのノードに対して実行されます。

  表12-7 BDACLIのresetのネットワーク・パラメータ

  ネットワーク・パラメータ | 説明
  --- | ---
  `admin_network` | 管理ネットワーク・インタフェース`eth0`を、<`rack-name>-network.json`で指定したとおりに再構成します。
  `client_network` | クライアント`eth8`、`eth9`、`bondeth0`およびすべての追加クライアント・ネットワークを、<`cluster-name>-network.json`で指定したとおりに再構成します。
  `private_network` | クライアント`ib0`、`ib1`、`bondib0`およびすべての追加プライベート・ネットワークを、`<cluster-name>-network.json`で指定したとおりに再構成します。
  `all_networks` | すべてのネットワーク(管理、クライアントおよびプライベート)を、対応するネットワーク・ファイルで指定したとおりに再構成します。

getinfo [parameter]

  `getinfo`パラメータのリストを返します。コマンドにパラメータ名を含めた場合、`getinfo`はそのシステム・コンポーネントの情報を返します。

  - インフィニバンド・パラメータ: `bdacli`コマンドはインフィニバンド・ファブリックに問い合せます。「インフィニバンド・パラメータ」を参照してください。

  - ラック・パラメータ: 物理的なOracle Big Data Applianceラックを示します。`bdacli`コマンドは、コマンドが実行されたラックについて、現在の`network.json`構成ファイルに問い合せます。「ラック・パラメータ」を参照してください。

  - クラスタ・パラメータ: 論理的なOracle Big Data Applianceクラスタを示します。`bdacli`コマンドは、コマンドが実行されたHadoopクラスタについて、現在の`config.json`ファイルに問い合せます。「クラスタ・パラメータ」を参照してください。

  - サーバー・パラメータ: サーバーを示します。`bdacli`コマンドは、`bdacli`コマンドが実行されたサーバーのオペレーティング・システムに問い合せます。「サーバー・パラメータ」を参照してください。

  - 個別パッチ・パラメータ: 個別パッチに関する情報を提供します。「個別パッチ・パラメータ」を参照してください。

  "s"で終わるパラメータ名はリストを返します。ブール型パラメータは`true`または`false`の文字列を返します。

インフィニバンド・パラメータ

表13-6では、`bdacli getinfo`のインフィニバンド・パラメータについて説明します。

表12-8 インフィニバンド・パラメータ

パラメータ | 戻り値
--- | ---
`ib_bda_servers` | インフィニバンド・ファブリック上のすべてのOracle Big Data Applianceサーバーのリスト。リストには、非修飾クライアント・ホスト名が含まれ、アルファベット順にソートされます。リストには、ケーブルで接続されている複数のラック内のサーバーを含めることができます。
`ib_switches` | インフィニバンド・ファブリック上のスイッチをリストします。スイッチ名、Globally Unique Identifier (GUID)およびタイプ(ゲートウェイ・スイッチの場合は`GTW`、スパイン・スイッチの場合は`36P`)を含みます。リストには、非修飾管理名が含まれ、スイッチ名のアルファベット順にソートされます。「例」を参照してください。

ラック・パラメータ

表13-7では、`bdacli getinfo`のラック・パラメータについて説明します。

表12-9 ラック・パラメータ

パラメータ | 戻り値
--- | ---
`rack_admin_domain_name` | ラックの管理ネットワーク・ドメイン名(`example.com`など)。すべてのクラスタ・ノードが同一の管理ドメイン名を持つため、戻り値もクラスタ内のすべてのノードに対する管理ネットワーク・ドメインになります。
`rack_domain_name` | ラックのクライアント・ネットワーク・ドメイン名(`example.com`など)。すべてのクラスタ・ノードが同一のクライアント・ドメイン名を持つため、戻り値もクラスタ内のすべてのノードに対するクライアント・ネットワーク・ドメインになります。
`rack_ib_switch_ips` | ラック内の3つのインフィニバンド・スイッチのIPアドレス。順序は、スパイン・スイッチ、第1リーフ・スイッチ(上)、第2リーフ・スイッチ(下)。
`rack_ib_switch_names` | ラック内の3つのインフィニバンド・スイッチの非修飾名。順序は、スパイン・スイッチ、第1リーフ・スイッチ(上)、第2リーフ・スイッチ(下)。例: bda1sw-ib1, bda1sw-ib2, and bda1sw-ib3。
`rack_ilom_ips` | ラック内のすべてのOracle ILOMのIPアドレスについて、下位のサーバーから順に並べたリスト
`rack_ilom_names` | ラック内のすべてのOracle ILOMのホスト名(bda1node01-ilom、bda1node02-ilomなど)について、下位のサーバーから順に並べたリスト
`rack_ip_switch_ip` | Ciscoイーサネット・スイッチのIPアドレス
`rack_ip_switch_name` | Ciscoイーサネット・スイッチのホスト名(bda1sw-ipなど)
`rack_name` | このラックの名前(bda1など)
`rack_pdu_ips` | ラック内のPDUのIPアドレスについて、PDU-Aから順に並べたリスト
`rack_pdu_names` | ラック内のPDUの非修飾名について、PDU-Aから順に並べたリスト(bda1-pdua、bda1-pdubなど)
`rack_serial_number` | ラックのシリアル番号
`rack_server_admin_ips` | ラック内のすべてのサーバーの管理ネットワーク上のIPアドレスについて、下位のサーバーから順に並べたリスト
`rack_server_admin_names` | ラック内のすべてのサーバーの管理ネットワーク上のホスト名(bda1node01-adm、bda1node02-admなど)について、下位のサーバーから順に並べたリスト
`rack_server_ips` | ラック内のすべてのサーバーのクライアント・ネットワーク上のIPアドレスについて、下位のサーバーから順に並べたリスト
`rack_server_names` | ラック内のすべてのサーバーのクライアント・ネットワーク上のホスト名(bda1node01、bda1node02など)について、下位のサーバーから順に並べたリスト
`rack_server_priv_ips` | ラック内のILOMデバイスへのIPアドレスのリスト
`rack_server_priv_names` | ラック内のILOMデバイスの非修飾名(bda1node01-priv、bda1node02-privなど)

クラスタ・パラメータ

次の表では、クラスタ・パラメータについて説明します。

- 表13-8

- 表13-9

- 表13-10

- 表13-11

表13-8では、`bdacli getinfo`の一般的なクラスタ・パラメータについて説明します。

表12-10 一般的なクラスタ・パラメータ

パラメータ | 戻り値
--- | ---
`cluster_asr_installed` | このクラスタに自動サービス・リクエストが構成されている場合は`true`。それ以外の場合は`false`
`cluster_big_data_sql_enabled` | このクラスタでOracle Big Data SQLが有効になっている場合は`true`。それ以外の場合は`false`。
`cluster_cdh_version` | このクラスタにインストールされているCloudera's Distribution including Apache Hadoopのバージョン(`4.5.0-ol6`など)。
`cluster_cm_server` | サーバー名およびポート番号を含むCloudera Managerのアドレス(`bda1node03.example.com:7180`など)。
`cluster_cm_version` | このクラスタで実行されているCloudera Managerのバージョン(`4.8.0-ol6`など)。
`cluster_em_enabled` | このクラスタにOracle Enterprise Mangerが構成されている場合は`true`。それ以外の場合は`false`
`cluster_name` | クラスタの名前(`cluster-c`など)。
`cluster_nosqldb_type` | このクラスタにインストールされているOracle NoSQL Databaseのエディション (`community edition`または`enterprise edition`)。Oracle NoSQL Databaseがインストールされていない場合は`none`。
`cluster_nosqldb_version` | このクラスタにインストールされているOracle NoSQL Databaseのバージョン。
`cluster_primary_host` | Puppetマスターをホストしているサーバーの非修飾ホスト名。Mammothユーティリティはこのホストからデプロイされたため、クラスタの再構成は、そのサーバーにログインしている間に実行する必要があります。
`cluster_type` | クラスタのタイプ(`hadoop`または`nosqldb`)。
`cluster_version` | Mammothユーティリティによってこのクラスタにインストールされているソフトウェア・バージョン(3.1.0など)。

表13-9では、`bdacli getinfo`のOracle Big Data Connectors関連のクラスタ・パラメータについて説明します。

表12-11 Oracle Big Data Connectorsステータス・パラメータ

パラメータ | 戻り値
--- | ---
`cluster_bdc_installed` | Oracle Big Data Connectorsがインストールされている場合は`true`。それ以外の場合は`false`
`cluster_odi_enabled` | Oracle Data Integratorエージェントが有効な場合は`true`。それ以外の場合は`false`。
`cluster_odi_version` | このクラスタにインストールされているOracle Data Integratorエージェントのバージョン。
`cluster_oraah_version` | このクラスタにインストールされているOracle R Advanced Analytics for Hadoopのバージョン
`cluster_oraloader_version` | このクラスタにインストールされているOracle Loader for Hadoopのバージョン
`cluster_osch_version` | このクラスタにインストールされているOracle SQL Connector for HDFSのバージョン
`cluster_oxh_version` | このクラスタにインストールされているOracle XQuery for Hadoopのバージョン

表13-10では、`bdacli getinfo`のクラスタ・ネットワーク・パラメータについて説明します。

表12-12 クラスタ・ネットワーク・パラメータ

パラメータ | 戻り値
--- | ---
`cluster_hosts_entries` | `/etc/hosts`エントリのリストで、これをOracle Big Data Applianceクラスタと同じインフィニバンド・ファブリック上の任意のデバイスにある`/etc/hosts`ファイルに追加することで、Hadoopトラフィックがインフィニバンド・ネットワークを使用するようにできます。これらのエントリは、別のファブリックのデバイスに追加しないでください。 各エントリは1行で記述し、インフィニバンドIPアドレス、完全なクライアント・ホスト名、短いクライアント・ホスト名の3つの部分を含めます。
`cluster_ilom_ips` | サーバーのOracle ILOMのIPアドレスについて、クラスタ内の第1ノードから順に並べたリスト
`cluster_ilom_names` | サーバーのOracle ILOMの管理ネットワーク上の非修飾ホスト名について、クラスタ内の第1サーバーから順に並べたリスト
`cluster_node_ips` | このクラスタ内のすべてのノードのクライアント・ネットワーク上のIPアドレス
`cluster_node_names` | クラスタ内のすべてのノードのクライアント・ネットワーク上のホスト名(`bda1node01`など)

表13-11では、`bdacli getinfo`のクラスタ・セキュリティ・パラメータについて説明します。

表12-13 クラスタ・セキュリティ・パラメータ

パラメータ | 戻り値
--- | ---
`cluster_av_admin` | Oracle Audit Vault and Database Firewallの管理ユーザーの名前。このクラスタにAudit Vaultが構成されていない場合はエラーを返します。
`cluster_av_enabled` | Oracle Audit Vault and Database Firewall監査が有効な場合は`true`。それ以外の場合は`false`
`cluster_av_port` | Audit Vault Serverがリスニングするポートの番号。このクラスタにOracle Audit Vault and Database Firewallが構成されていない場合はエラーを返します。
`cluster_av_server` | Audit Vault ServerのIPアドレス。このクラスタにOracle Audit Vault and Database Firewallが構成されていない場合はエラーを返します。
`cluster_av_service` | Audit Vault Serverのデータベース・サービス名。このクラスタにOracle Audit Vault and Database Firewallが構成されていない場合はエラーを返します。
`cluster_hdfs_encryption_enabled` | このクラスタでHadoopデータのネットワーク暗号化が有効になっている場合は`true`。それ以外の場合は`false`
`cluster_hdfs_transparent_encryption_enabled` | このクラスタでHadoop保存データのHDFS透過的暗号化が有効になっている場合は`true`。それ以外の場合は`false`
`cluster_kerberos_enabled` | Kerberosセキュリティが有効な場合は`true`。それ以外の場合は`false`。
`cluster_kerberos_kdc_hosts` | Oracle Big Data Applianceの外部にあるキー配布センター(KDC)ホストのリスト。Kerberosが有効になっていない場合はエラーを返します。
`cluster_kerberos_kdc_on_bda` | Oracle Big Data ApplianceにKerberos KDCがある場合は`true`。それ以外の場合は`false`。Kerberosが有効になっていない場合はエラーを返します。
`cluster_kerberos_realm` | クラスタのKerberosレルム。Kerberosが有効になっていない場合はエラーを返します。
`cluster_sentry_enabled` | このクラスタにSentryが構成されている場合は`true`。それ以外の場合は`false`。

サーバー・パラメータ

表13-12では、`bdacli getinfo`のサーバー・パラメータについて説明します。

表12-14 サーバー・パラメータ

パラメータ | 戻り値
--- | ---
`server_mammoth_installed` | MammothユーティリティがこのサーバーにOracle Big Data Applianceソフトウェアをデプロイした場合は`true`。それ以外の場合は`false`。
`server_name` | クライアント・ネットワーク上のこのサーバーの名前(bda1node01など)。
`server_os_version` | このサーバー上のOracle Linuxのバージョン(6.4など)。

個別パッチ・パラメータ

表13-13では、`bdacli getinfo`の個別パッチ・パラメータについて説明します。

表12-15 個別パッチ・パラメータ

パラメータ | 戻り値
--- | ---
`available_patches` | インストールに使用できる有効なパッチのリスト。有効なパッチについては、`/opt/oracle/bda/patches`または`/opt/oracle/BDAMammoth/patches`の下にディレクトリがあり、`inventory`という名前のファイルが含まれています。
`installed_patches` | すでにインストールされているパッチのリスト。インストールされているパッチについては、`/opt/oracle/bda/patches`と`/opt/oracle/BDAMammoth/patches`の両方にディレクトリがあります。

関連項目

オプション・サービスの詳細は、「オプション・ソフトウェアの構成の変更」を参照してください。

例

次のコマンドは、クラスタのオプション・ソフトウェアに関する情報を提供します。

    # bdacli getinfo cluster_bdc_installed
    true
    # bdacli getinfo cluster_odi_version
    11.1.1.7.0

    # bdacli getinfo cluster_hdfs_encryption_enabled
    true

次のコマンドは、現在のインフィニバンド・ファブリック上のすべてのスイッチをリストします。この例では、標準のハードウェア構成(それぞれに1つのスパイン・スイッチと2つのゲートウェイ・スイッチ)を備えた3つのOracle Big Data Applianceラックがファブリック上にあります。

    $ bdacli getinfo ib_switches
    bda1sw-iba0 00:21:28:6c:c8:af:a0:a0 36P
    bda1sw-ibb0 00:21:28:46:9e:3b:a0:a0 36P
    bda1sw-ibs0 00:21:28:6c:c8:ae:a0:a0 36P
    bda2sw-ib1 00:21:28:46:98:d3:a0:a0 36P
    bda2sw-ib2 00:21:28:de:ae:4a:c0:a0 GTW
    bda2sw-ib3 00:21:28:c3:70:9a:c0:a0 GTW
    bda3sw-ib1 00:21:28:46:90:ee:a0:a0 36P
    bda3sw-ib2 00:21:28:df:34:8a:c0:a0 GTW
    bda3sw-ib3 00:21:28:df:0f:0a:c0:a0 GTW
    bda4sw-ib1 00:21:28:e8:af:23:a0:a0 36P
    bda4sw-ib2 00:10:e0:0c:48:a0:c0:a0 GTW
    bda4sw-ib3 00:21:28:f4:82:ce:c0:a0 GTW

この例では、patch 1234をインストールします。

    $ bdacli add patch 1234

## 12.4 サーバーが再起動しない場合の対処方法

サーバーは、ディスク交換手順の最中に、ユーザーが`reboot`コマンドを発行したため、またはMegaCli64コマンドでエラーが発生したために再起動することがあります。ほとんどの場合、サーバーは正常に再起動し、作業を継続できます。ただし、それ以外の場合、エラーが発生するためにSSHを使用して再接続できなくなります。この場合、Oracle ILOMを使用して再起動を完了する必要があります。

Oracle ILOMを使用してサーバーを再起動するには、次の手順を実行します。

1. ブラウザで、Oracle ILOMを使用してサーバーに対する接続を開きます。次に例を示します。

   `http://bda1node12-c.example.com`

   注意:

   ブラウザには、JDKプラグインがインストールされている必要があります。ログイン・ページにJavaのコーヒー・カップが表示されない場合、作業を続行する前にプラグインをインストールする必要があります。

2. Oracle ILOM資格証明を使用してログインします。

3. 「Remote Control」タブを選択します。

4. 「Launch Remote Console」ボタンをクリックします。

5. [Ctrl]を押しながら[D]を押し、再起動を続行します。

6. 再起動に失敗した場合、プロンプトでサーバーの`root`パスワードを入力し、問題の修正を試みます。

7. サーバーが正常に再起動したら、「Redirection」メニューを開いて「Quit」を選択し、コンソール・ウィンドウを閉じます。

関連項目:

Oracle Integrated Lights Out Manager (ILOM) 3.0のドキュメント

`http://docs.oracle.com/cd/E19860-01/`

## 12.5 ディスク・ドライブの交換

障害が発生または障害状態にあるディスク・ドライブを交換するには、次の手順を実行します。

1. 障害ディスクを交換する前に、「障害ディスクを交換するための前提条件」を参照してください。

2. 障害ディスク・ドライブを交換します。

   「Oracle Big Data Applianceサーバーの部品」を参照してください。

3. 障害ディスクを交換するためにサーバーの電源を切断した場合、電源を投入します。

4. KVMまたはラップトップとのSSL接続を使用して、`root`としてサーバーに接続します。

5. ファイルに物理ドライブの情報を保存します。

       # MegaCli64 pdlist a0 > pdinfo.tmp

   注意: このコマンドによって、出力がファイルにリダイレクトされるため、テキスト・エディタを使用して複数の検索を実行できます。必要に応じて、`more`または`grep`コマンドを通じて出力をパイプ処理できます。

   ユーティリティによって、スロットごとに次の情報が返されます。次の例は、Firmware Stateが`Unconfigured(good), Spun Up`であることを示しています。

       Enclosure Device ID: 20
       Slot Number: 8
       Drive's postion: DiskGroup: 8, Span: 0, Arm: 0
       Enclosure position: 0
       Device Id: 11
       WWN: 5000C5003487075C
       Sequence Number: 2
       Media Error Count: 0
       Other Error Count: 0
       Predictive Failure Count: 0
       Last Predictive Failure Event Seq Number: 0
       PD Type: SAS
       Raw Size: 1.819 TB [0xe8e088b0 Sectors]
       Non Coerced Size: 1.818 TB [0xe8d088b0 Sectors]
       Coerced Size: 1.817 TB [0xe8b6d000 Sectors]
       Firmware state: Unconfigured(good), Spun Up
       Is Commissioned Spare : NO
       Device Firmware Level: 061A
       Shield Counter: 0
       Successful diagnostics completion on :  N/A
       SAS Address(0): 0x5000c5003487075d
       SAS Address(1): 0x0
       Connected Port Number: 0(path0)
       Inquiry Data: SEAGATE ST32000SSSUN2.0T061A1126L6M3WX
       FDE Enable: Disable
       Secured: Unsecured
       Locked: Unlocked
       Needs EKM Attention: No
       Foreign State: None
       Device Speed: 6.0Gb/s
       Link Speed: 6.0Gb/s
       Media Type: Hard Disk Device
       .
       .
       .

6. 手順5で作成したファイルをテキスト・エディタで開き、次の項目を検索します。

   - Foreign StateがForeignであるディスク

   - Firmware StateがUnconfiguredであるディスク

7. Foreign StateがForeignのディスクでは、そのステータスを消去します。

       # MegaCli64 CfgForeign clear a0

   外部ディスクは、コントローラが以前認識していたディスクです(再挿入されたディスクなど)。

8. Firmware StateがUnconfigured (Bad)のディスクでは、次の手順を実行します。

   1. エンクロージャ・デバイスのID番号とスロット番号を書き留めます。

   2. 次の書式でコマンドを入力します。

          # MegaCli64 pdmakegood physdrv[enclosure:slot] a0

      たとえば、[20:10]では、スロット10のエンクロージャ20によって識別されるディスクが修復されます。

   3. もう一度Foreign Stateの現在のステータスを確認します。

          # MegaCli64 pdlist a0 | grep foreign

   4. Foreign StateがまだForeignの場合は、`clear`コマンドを繰り返します。

          # MegaCli64 CfgForeign clear a0

9. Firmware StateがUnconfigured (Good)のディスクでは、次のコマンドを使用します。複数のディスクが未構成の場合、最小のスロット番号から最大のスロット番号へと向かう順序でそれらを構成します。

       # MegaCli64 CfgLdAdd r0[enclosure:slot] a0

       Adapter 0: Created VD 1

       Adapter 0: Configured the Adapter!!

       Exit Code: 0x00

   たとえば、[20:5]では、スロット5のエンクロージャ20によって識別されるディスクが修復されます。

10. 手順9の`CfgLdAdd`コマンドがキャッシュされたデータにより失敗した場合は、キャッシュを消去します。

        # MegaCli64 discardpreservedcache l1 a0

11. ディスクがオペレーティング・システムによって認識されることを確認します。

        # lsscsi

    ディスクは、その元のデバイス名(`/dev/sdc`など)で表示されるか、新しいデバイス名(`/dev/sdn`など)で表示されます。オペレーティング・システムでディスクが認識されない場合、そのディスクは`lsscsi`コマンドによって生成されるリストに含まれません。

    `lssci`出力が正しい順序で表示されない場合もありますが、構成は続行できます。同じ物理ディスクから論理ディスクへのマッピングが必要な場合には、カーネルに対して同じディスクからデバイスへのマッピングは不要です。ディスク構成は、`/dev/disks/by-hba-slot`のデバイス名に基づいて行われます。

    次の出力例は、新しいデバイス名の2つのディスクを示しています(スロット5の`/dev/sdn`およびスロット10の`/dev/sdo` )。

        [0:0:20:0]   enclosu ORACLE  CONCORD14        0960  -
        [0:2:0:0]    disk    LSI      MR9261-8i        2.12  /dev/sda
        [0:2:1:0]    disk    LSI      MR9261-8i        2.12  /dev/sdb
        [0:2:2:0]    disk    LSI      MR9261-8i        2.12  /dev/sdc
        [0:2:3:0]    disk    LSI      MR9261-8i        2.12  /dev/sdd
        [0:2:4:0]    disk    LSI      MR9261-8i        2.12  /dev/sde
        [0:2:5:0]    disk    LSI      MR9261-8i        2.12  /dev/sdn
        [0:2:6:0]    disk    LSI      MR9261-8i        2.12  /dev/sdg
        [0:2:7:0]    disk    LSI      MR9261-8i        2.12  /dev/sdh
        [0:2:8:0]    disk    LSI      MR9261-8i        2.12  /dev/sdi
        [0:2:9:0]    disk    LSI      MR9261-8i        2.12  /dev/sdj
        [0:2:10:0]   disk    LSI      MR9261-8i        2.12  /dev/sdo
        [0:2:11:0]   disk    LSI      MR9261-8i        2.12  /dev/sdl
        [7:0:0:0]    disk    ORACLE   UNIGEN-UFD       PMAP  /dev/sdm
        [

12. サーバーのハードウェア・プロファイルを確認し、エラーがあれば修正します。

        # bdacheckhw

13. サーバーのソフトウェア・プロファイルを確認し、エラーがあれば修正します。

        # bdachecksw

    「Wrong mounted partitions」エラーが表示され、デバイスがリストにない場合は、エラーを無視して続行できます。ただし、「Duplicate mount points」エラーが表示されるか、またはスロット番号が切り替わった場合は、「マウントされているパーティションのエラーの修正」を参照してください。

14. ドライブを適切に構成できるように、その機能を識別します。「ディスク・ドライブの機能の識別」を参照してください。

## 12.6 マウントされているパーティションのエラーの修正

`bdachecksw`ユーティリティで見つかる問題は通常、マウントされているパーティションに関係しています。

古いマウント・ポイントが`mount`コマンドの出力として表示される場合があるため、たとえば/u03など、同じマウント・ポイントが2回表示されることもあります。

重複しているマウント・ポイントを修正するには、次の手順を実行します。

1. `umount`コマンドを2回使用して、両方のマウント・ポイントをディスマウントします。この例では、重複している2つの/u03をディスマウントしています。

       # umount /u03
       # umount /u03

2. マウント・ポイントを再マウントします。この例では、/u03を再マウントしています。

       # mount /u03

ディスクが誤ったスロット(つまり、仮想ドライブ番号)にある場合には、2つのドライブを切り替えることができます。

スロットを切り替えるには、次の手順を実行します。

1. 両方のドライブのマッピングを削除します。この例では、スロット4および10からドライブを削除しています。

       # MegaCli64 cfgLdDel L4 a0
       # MegaCli64 cfgLdDel L10 a0

2. 表示しようとする順序でドライブを追加します。最初のコマンドで、使用可能な最初のスロット番号が取得されます。

       # MegaCli64 cfgLdAdd [20:4] a0
       # MegaCli64 cfgLdAdd [20:5] a0

3. スロット番号が正しい場合であってもマウント・エラーが続く場合には、サーバーを再起動してください。

## 12.7 ディスク・ドライブの機能の識別

障害ディスクのあるサーバーはHDFSまたはOracle NoSQL Databaseをサポートするように構成され、ほとんどのディスクはその目的のみに使用されます。ただし、2つのディスクはオペレーティング・システム専用です。新しいディスクを構成する前に、障害ディスクがどのように構成されたかを確認します。

Oracle Big Data Applianceは、最初の2つのディスク上にオペレーティング・システムが構成されます。

障害ディスクでオペレーティング・システムがサポートされていたことを確認するには、次の手順を実行します。

1. 交換ディスクが`/dev/sda`または`/dev/sdb` (オペレーティング・システム・ディスク)に対応しているかどうかを確認します。

       # lsscsi

   「ディスク・ドライブの交換」の手順11での出力を参照してください。

2. `/dev/sda`および`/dev/sdb`がオペレーティング・システムのミラー化パーティション・ディスクであることを確認します。

       # mdadm -Q –-detail /dev/md2
       /dev/md2:
               Version : 0.90
         Creation Time : Mon Jul 22 22:56:19 2013
            Raid Level : raid1
            .
            .
            .
           Number   Major   Minor   RaidDevice State
              0       8        2        0      active sync   /dev/sda2
              1       8       18        1      active sync   /dev/sdb2

3. 前の手順で障害ディスクがオペレーティング・システム・ディスクであることがわかった場合、「オペレーティング・システム・ディスクの構成」に進みます。

## 12.8 オペレーティング・システム・ディスクの構成

最初の2つのディスクによって、Linuxオペレーティング・システムがサポートされます。これらのディスクには、ミラー化されたオペレーティング・システムのコピー、スワップ・パーティション、ミラー化されたブート・パーティションおよびHDFSデータ・パーティションが格納されます。

オペレーティング・システム・ディスクを構成するには、稼働を続けているディスクからパーティション表をコピーし、HDFSパーティション(ext4ファイル・システム)を作成して、オペレーティング・システムのソフトウェアRAIDパーティションとブート・パーティションを追加する必要があります。

スロット0またはスロット1のディスクを交換した後、次の手順を実行します。

- オペレーティング・システム・ディスクのパーティション化

- RAIDアレイの修理

- オペレーティング・システム・ディスクのHDFSパーティションのフォーマット

- スワップ・パーティションのリストア

- GRUBマスター・ブート・レコードおよびHBAブート順序のリストア

### 12.8.1 オペレーティング・システム・ディスクのパーティション化

パーティション化の手順は、Oracle Linuxバージョン5と6では若干異なります。各システムに対応する適切な手順を実行してください。

- Oracle Linux 6のパーティション化

- Oracle Linux 5のパーティション化

注意:

次のコマンドの`/dev/disk/by-hba-slot/s` `n`は、適切なシンボリック・リンク(`/dev/disk/by-hba-slot/s0`または`/dev/disk/by-hba-slot/s1`)に置き換えてください。

#### 12.8.1.1 Oracle Linux 6のパーティション化

Oracle Linux 6の論理ドライブをパーティション化するには、次の手順を実行します。

1. 「ディスク・ドライブの交換」の手順を完了します。
2. 新しいディスクにパーティション表が存在しないことを確認します。

       # parted /dev/disk/by-hba-slot/sn -s print

   通常は、欠落しているパーティション表に関するメッセージが表示されます。

3. `parted`コマンドでパーティション表が表示された場合、それを消去します。

       # dd if=/dev/zero of=/dev/disk/by-hba-slot/sn bs=1M count=100

   ヒント:

   間違った場合、このコマンドを使用してオペレーティング・システム・ディスクの構成を再開できます。

4. パーティション表を作成します。

       # parted /dev/disk/by-hba-slot/sn -s mklabel gpt print

5. 稼働を続けているディスクのCylinder Head Sector (CHS)パーティション情報をリストします。つまり、`/dev/disk/by-hba-slot/s0`をパーティション化する場合、次のコマンドの`/dev/disk/by-hba-slot/s` `m`として`/dev/disk/by-hba-slot/s1`を入力します。

       # parted /dev/disk/by-hba-slot/sm -s unit chs print

       Model: LSI MR9261-8i (scsi)
       Disk /dev/sda: 243031,30,6
       Sector size (logical/physical): 512B/512B
       BIOS cylinder,head,sector geometry: 243031,255,63.  Each cylinder is 8225kB.
       Partition Table: gpt

       Number  Start        End          File system    Name    Flags
        1      0,0,34       25,127,7     ext4           primary boot
        2      25,127,8     21697,116,20                primary raid
        3      21697,116,21 23227,61,35  linux-swap(v1) primary
        4      23227,61,36  243031,29,36 ext4           primary

6. 稼働を続けているディスクのパーティションを複製して、新しいドライブにパーティション1から3を作成します。次の書式で3つのコマンドを発行します。

       # parted /dev/disk/by-hba-slot/sn -s mkpart primary file_system start end

   次の例に示されているアドレスのかわりに、手順5で取得した開始アドレスと終了アドレスを使用してください。

       # parted /dev/disk/by-hba-slot/sn -s mkpart primary ext4 0,0,34 25,127,7
       # parted /dev/disk/by-hba-slot/sn -s mkpart primary ext4 25,127,8 21697,116,20
       # parted /dev/disk/by-hba-slot/sn -s mkpart primary linux-swap 21697,116,21 23227,61,35

7. 手順5で取得した開始アドレスと100%の終了アドレスを使用して、プライマリ・パーティション4を作成します。

       # parted /dev/disk/by-hba-slot/sn -s mkpart primary ext4 23227,61,36 100%

   パーティション4にはHDFSデータが格納され、この構文によってパーティションが可能なかぎり大きくなります。

8. RAIDフラグを設定します。

       # parted -s /dev/disk/by-hba-slot/sn set 1 raid
       # parted -s /dev/disk/by-hba-slot/sn set 2 raid

9. ブート・フラグを設定します。

       # parted -s /dev/disk/by-hba-slot/sn set 1 boot

10. ブート・フラグが設定されていることを確認します。

        # parted /dev/disk/by-hba-slot/sn -s unit chs print

    出力例を次に示します。

        Model: LSI MR9261-8i (scsi)
        Disk /dev/sda: 243031,30,6
        Sector size (logical/physical): 512B/512B
        BIOS cylinder,head,sector geometry: 243031,255,63. Each cylinder is 8225kB.
        Partition Table: gpt
        Number Start         End           File system    Name    Flags
        1      0,32,32       24,89,0       ext4           primary boot
        2      24,89,1       60812,135,58                 primary raid
        3      60812,135,59  65618,90,7    linux-swap(v1) primary
        4      65618,90,8    243030,252,37 ext4           primary

11. 「RAIDアレイの修理」の手順を完了します。

#### 12.8.1.2 Oracle Linux 5のパーティション化

Oracle Linux 5の論理ドライブをパーティション化するには、次の手順を実行します。

1. 「ディスク・ドライブの交換」の手順を完了します。
2. 新しいディスクにパーティション表が存在しないことを確認します。

       # parted /dev/disk/by-hba-slot/sn -s print

   通常は、欠落しているパーティション表に関するメッセージが表示されます。

3. `parted`コマンドでパーティション表が表示された場合、それを消去します。

       # dd if=/dev/zero of=/dev/disk/by-hba-slot/sn bs=1M count=100

   ヒント:

   間違った場合、このコマンドを使用してオペレーティング・システム・ディスクの構成を再開できます。

4. パーティション表を作成します。

       # parted /dev/disk/by-hba-slot/sn -s mklabel gpt print

5. 稼働を続けているディスクのCylinder Head Sector (CHS)パーティション情報をリストします。つまり、`/dev/disk/by-hba-slot/s0`をパーティション化する場合、次のコマンドの`/dev/disk/by-hba-slot/s` `m`として`/dev/disk/by-hba-slot/s1`を入力します。

       # parted /dev/disk/by-hba-slot/sm -s unit chs print

       Model: LSI MR9261-8i (scsi)
       Disk /dev/sda: 243031,30,6
       Sector size (logical/physical): 512B/512B
       BIOS cylinder,head,sector geometry: 243031,255,63.  Each cylinder is 8225kB.
       Partition Table: gpt

       Number  Start         End           File system  Name     Flags
        1      0,0,34        25,127,7      ext3                  raid
        2      25,127,8      21697,116,20  ext3                  raid
        3      21697,116,21  23227,61,35   linux-swap
        4      23227,61,36   243031,29,36  ext3         primary

6. 稼働を続けているディスクのパーティションを複製して、新しいドライブにパーティション1から3を作成します。次の書式で3つのコマンドを発行します。

       # parted /dev/disk/by-hba-slot/sn -s mkpart file_system start end

   次の例に示されているアドレスのかわりに、手順5で取得した開始アドレスと終了アドレスを使用してください。

       # parted /dev/disk/by-hba-slot/sn -s mkpart ext3 0,0,34 25,127,7
       # parted /dev/disk/by-hba-slot/sn -s mkpart ext3 25,127,8 21697,116,20
       # parted /dev/disk/by-hba-slot/sn -s mkpart linux-swap 21697,116,21 23227,61,35

7. 手順5で取得した開始アドレスと100%の終了アドレスを使用して、プライマリ・パーティション4を作成します。

       # parted /dev/disk/by-hba-slot/sn -s mkpart primary ext3 23227,61,36 100%

   パーティション4にはHDFSデータが格納され、この構文によってパーティションが可能なかぎり大きくなります。

8. RAIDフラグを設定します。

       # parted -s /dev/disk/by-hba-slot/sn set 1 raid
       # parted -s /dev/disk/by-hba-slot/sn set 2 raid

9. 対話モードで`parted`を使用して名前を消去します。

       # parted /dev/disk/by-hba-slot/sn

       GNU Parted 1.8.1
       Using /dev/sdn
       Welcome to GNU Parted! Type 'help' to view a list of commands.
       (parted) name 1 " "
       (parted) name 2 " "
       (parted) name 3 " "
       (parted) quit

10. 「RAIDアレイの修理」の手順を完了します。

### 12.8.2 RAIDアレイの修理

ディスクをパーティション化した後、2つの論理RAIDアレイを修理できます。

- `/dev/md0`には、`/dev/disk/by-hba-slot/s0p1`および`/dev/disk/by-hba-slot/s1p1`が含まれます。`/boot`としてマウントされます。

- `/dev/md2`には、`/dev/disk/by-hba-slot/s0p2`および`/dev/disk/by-hba-slot/s1p2`が含まれます。`/` (root)としてマウントされます。

注意:

システムが停止する操作になるため、`/dev/md`デバイスはディスマウントしないでください。

RAIDアレイを修理するには、次の手順を実行します。

1. RAIDアレイからパーティションを削除します。

       # mdadm /dev/md0 -r detached
       # mdadm /dev/md2 -r detached

2. RAIDアレイが縮退していることを確認します。

       # mdadm -Q –-detail /dev/md0
       # mdadm -Q –-detail /dev/md2

3. 各アレイの縮退ファイルが1に設定されていることを確認します。

       # cat /sys/block/md0/md/degraded
       1
       # cat /sys/block/md2/md/degraded
       1

4. RAIDアレイにパーティションをリストアします。

       # mdadm –-add /dev/md0 /dev/disk/by-hba-slot/snp1
       # mdadm –-add /dev/md2 /dev/disk/by-hba-slot/snp2

5. `/dev/md2`がリカバリ状態になり、アイドル状態でなくなるように、再同期が開始されていることを確認します。

       # cat /sys/block/md2/md/sync_action
       repair

6. 再同期の進行を確認するには、`mdstat`ファイルを監視します。カウンタによって、完了した割合が示されます。

       # cat /proc/mdstat

       Personalities : [raid1]
       md0 : active raid1 sdb1[1] sda1[0]
             204736 blocks [2/2] [UU]

       md2 : active raid1 sdb2[2] sda2[0]
             174079936 blocks [2/1] [U_]
             [============>........]  recovery = 61.6% (107273216/174079936) finish=18.4min speed=60200K/sec

   次の出力は、同期が完了したことを示しています。

       Personalities : [raid1]
       md0 : active raid1 sdb1[1] sda1[0]
             204736 blocks [2/2] [UU]

       md2 : active raid1 sdb2[1] sda2[0]
             174079936 blocks [2/2] [UU]

       unused devices: <none>

7. /etc/mdadm.confのコンテンツを表示します。

       # cat /etc/mdadm.conf

       # mdadm.conf written out by anaconda
       DEVICE partitions
       MAILADDR root
       ARRAY /dev/md0 level=raid1 num-devices=2 UUID=df1bd885:c1f0f9c2:25d6...
       ARRAY /dev/md2 level=raid1 num-devices=2 UUID=6c949a1a:1d45b778:a6da...

8. 次のコマンドの出力をステップ7の/etc/mdadm.confの内容と比較します。

       # mdadm --examine --brief --scan --config=partitions

9. ファイル内のUUIDが`mdadm`コマンドの出力内のUUIDと異なる場合は、次の手順を実行します。

   1. テキスト・エディタで/etc/mdadm.confを開きます。

   2. ARRAYからファイルの末尾までを選択し、選択した行を削除します。

   3. ファイルの行を削除した部分に、コマンドの出力をコピーします。

   4. 変更したファイルを保存して終了します。

10. 「オペレーティング・システム・ディスクのHDFSパーティションのフォーマット」の手順を完了します。

### 12.8.3 オペレーティング・システム・ディスクのHDFSパーティションのフォーマット

オペレーティング・システム・ディスクのパーティション4 (sda4)は、HDFSに使用されます。パーティションをフォーマットして適切なラベルを設定すると、ディスク領域が必要な場合にパーティションを使用するようにHDFSによってジョブの負荷がリバランスされます。

HDFSパーティションをフォーマットするには、次の手順を実行します。

1. ext4ファイル・システムとしてHDFSパーティションをフォーマットします。

       # mkfs -t ext4 /dev/disk/by-hba-slot/snp4

   注意:

   デバイスがマウントされているためにこのコマンドが失敗する場合、ここでドライブをディスマウントし、手順3を省略してください。ディスマウントの手順については、「障害ディスクを交換するための前提条件」を参照してください。

2. パーティション・ラベル(`s0p4`に対する`/u01`など)が存在しないことを確認します。

       # ls -l /dev/disk/by-label

3. 適切なHDFSパーティション(`/dev/sda`の場合は`/u01`、`/dev/sdb`の場合は`/u02`)をディスマウントします。

       # umount /u0n

4. パーティション・ラベルを再設定します。

       # tune2fs -c -1 -i 0 -m 0.2 -L /u0n /dev/disk/by-hba-slot/snp4

5. HDFSパーティションをマウントします。

       # mount /u0n

6. 「スワップ・パーティションのリストア」の手順を完了します。

### 12.8.4 スワップ・パーティションのリストア

HDFSパーティションをフォーマットした後、スワップ・パーティションをリストアできます。

スワップ・パーティションをリストアするには、次の手順を実行します。

1. スワップ・ラベルを設定します。

       # mkswap -L SWAP-sdn3 /dev/disk/by-hba-slot/snp3
       Setting up swapspace version 1, size = 12582907 kB
       LABEL=SWAP-sdn3, no uuid

2. スワップ・パーティションがリストアされたことを確認します。

       # bdaswapon; bdaswapoff
       Filename                          Type            Size    Used    Priority
       /dev/sda3                         partition       12287992        0       1
       /dev/sdb3                         partition       12287992        0       1

3. 交換したディスクがオペレーティング・システムによって認識されることを確認します。

       $ ls -l /dev/disk/by-label
       total 0
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 BDAUSB -> ../../sdn1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 BDAUSBBOOT -> ../../sdm1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 SWAP-sda3 -> ../../sda3
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 SWAP-sdb3 -> ../../sdb3
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u01 -> ../../sda4
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u02 -> ../../sdb4
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u03 -> ../../sdc1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u04 -> ../../sdd1
            .
            .
            .

4. 出力に交換したディスクがリストされない場合:

   - Linux 5で、`udevtrigger`を実行します。

   - Linux 6で、`udevadm trigger`を実行します。

   その後、手順3を繰り返します。`lsscsi`コマンドも、ディスクの正しい順序をレポートする必要があります。

5. 「GRUBマスター・ブート・レコードおよびHBAブート順序のリストア」の手順を完了します。

### 12.8.5 GRUBマスター・ブート・レコードおよびHBAブート順序のリストア

スワップ・パーティションをリストアした後、Grand Unified Bootloader (GRUB)のマスター・ブート・レコードをリストアできます。

`device.map`ファイルによって、オペレーティング・システム・デバイスにBIOSドライブがマップされます。次に、デバイス・マップ・ファイルの例を示します。

    # this device map was generated by anaconda
    (hd0)     /dev/sda
    (hd1)     /dev/sdb

ただし、GRUBデバイス・マップはシンボリック・リンクをサポートしていないため、デバイス・マップ内のマッピングは`/dev/disk/by-hba-slot`によって使用されているものと一致しない場合があります。この手順では、必要に応じてデバイス・マップを修正する方法について説明します。

GRUBのブート・レコードをリストアするには、次の手順を実行します。

1. ドライブがslot1で使用しているカーネル・デバイスを確認します。

       # ls -ld /dev/disk/by-hba-slot/s1
       lrwxrwxrwx 1 root root 9 Apr 22 12:54 /dev/disk/by-hba-slot/s1 -> ../../sdb

2. ステップ1に示すとおり、出力に`/dev/sdb`が表示されている場合は、次のステップ(GRUBのオープン)に進みます。

   別のデバイス(`/dev/sdn`など)が表示されている場合は、まず`hd1`が正しいデバイスを指すように設定する必要があります。

   1. `device.map`ファイルのコピーを作成します。

          # cd /boot/grub
          # cp device.map mydevice.map
          # ls -l *device*
          -rw-r--r-- 1 root root 85 Apr 22 14:50 device.map
          -rw-r--r-- 1 root root 85 Apr 24 09:24 mydevice.map

   2. `mydevice.map`を編集して、`hd1`が新しいデバイスを指すようにします。この例では、ステップ1で`s1`が`/deb/sdn`を指していました。

          # more /boot/grub/mydevice.map
          # this device map was generated by bda install
          (hd0)     /dev/sda
          (hd1)     /dev/sdn

   3. 残りのステップでは、編集したデバイス・マップ(`mydevice.map`)を使用します。

3. ここに示すように`device.map`を使用するか、編集した`mydevice.map`を使用して、GRUBをオープンします。

       # grub --device-map=/boot/grub/device.map

           GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

        [ Minimal BASH-like line editing is supported.  For the first word, TAB
          lists possible command completions.  Anywhere else TAB lists the possible
          completions of a device/filename.
       ]

4. `/dev/sda`の場合はhd0、`/dev/sdb`の場合はhd1を入力して、ルート・デバイスを設定します。

       grub> root (hdn,0)

       root (hdn,0)
        Filesystem type is ext2fs, partition type 0x83

5. `/dev/sda`の場合はhd0、`/dev/sdb`の場合はhd1を入力して、GRUBをインストールします。

       grub> setup (hdn)

       setup (hdn)
        Checking if "/boot/grub/stage1" exists... no
        Checking if "/grub/stage1" exists... yes
        Checking if "/grub/stage2" exists... yes
        Checking if "/grub/e2fs_stage1_5" exists... yes
        Running "embed /grub/e2fs_stage1_5 (hdn)"... failed (this is not fatal)
        Running "embed /grub/e2fs_stage1_5 (hdn,0)"... failed (this is not fatal)
        Running "install /grub/stage1 (hdn) /grub/stage2 p /grub/grub.conf "... succeeded
       Done.

6. GRUBコマンドライン・インタフェースを終了します。

       grub> quit

7. HBAのブート・ドライブが正しく設定されていることを確認します。

       # MegaCli64 /c0 show bootdrive

   BootDrive VD:0が設定されている場合、コマンド出力は次のようになります。

       Controller = 0
       Status = Success
       Description = None
       Controller Properties :
       =====================
       ----------------
       Ctrl_Prop Value
       ----------------
       BootDrive VD:0
       ----------------

   BootDrive VD:0が設定されていない場合、コマンド出力に`「No Boot Drive」`と表示されます。

       Controller = 0
       Status = Success
       Description = None
       Controller Properties :
       =====================
       ----------------
       Ctrl_Prop Value
       ----------------
       BootDrive No Boot Drive
       ----------------

8. ブート・ドライブが設定されていないことが`MegaCli64 /c0 show bootdrive`によって報告された場合は、次のように設定します。

       # MegaCli64 /c0/v0 set bootdrive=on
       Controller = 0
       Status = Success
       Description = None
       Detailed Status :
       ===============
       -----------------------------------------
       VD  Property   Value Status   ErrCd ErrMsg
       -----------------------------------------
       0   Boot Drive On    Success  0     -
       ------------------------------------------

9. ブート・ドライブが設定されたことを確認します。

       # MegaCli64 /c0 show bootdrive
       Controller = 0
       Status = Success
       Description = None
       Controller Properties :
       =====================
       ----------------
       Ctrl_Prop Value
       ----------------
       BootDrive VD:0
       ----------------

10. 自動選択ブート・ドライブ機能が有効であることを確認します。

        # MegaCli64 adpBIOS EnblAutoSelectBootLd a0
        Auto select Boot is already Enabled on Adapter 0.

11. 構成を確認します。「ディスク構成の確認」を参照してください。

## 12.9 HDFSディスクまたはOracle NoSQL Databaseディスクの構成

オペレーティング・システムで使用されていないすべてのディスクで、次の手順を実行します。「ディスク・ドライブの機能の識別」を参照してください。

ディスクを構成するには、それをパーティション化してフォーマットする必要があります。

注意:

次のコマンドのsnp1は、s4p1などの適切なシンボリック名に置き換えてください。

HDFSまたはOracle NoSQL Databaseで使用するためにディスクをフォーマットするには、次の手順を実行します。

1. 「ディスク・ドライブの交換」の手順をまだ完了していない場合は完了します。

2. ドライブをパーティション化します。

       # parted /dev/disk/by-hba-slot/sn -s mklabel gpt mkpart primary ext4 0% 100%

3. ext4ファイル・システムのパーティションをフォーマットします。

       # mkfs -t ext4 /dev/disk/by-hba-slot/snp1

4. 存在しないデバイスに適切なパーティション・ラベルを再設定します。表12-2を参照してください。

       # tune2fs -c -1 -i 0 -m 0.2 -L /unn /dev/disk/by-hba-slot/snp1

   たとえば、次のコマンドでは、`/u03`に対して`/dev/disk/by-hba-slot/s2p1`というラベルを再設定します。

       # tune2fs -c -1 -i 0 -m 0.2 -L /u03 /dev/disk/by-hba-slot/s2p1
       Setting maximal mount count to -1
       Setting interval between checks to 0 seconds
       Setting reserved blocks percentage to 0.2% (976073 blocks)

5. 交換したディスクがオペレーティング・システムによって認識されることを確認します。

       $ ls -l /dev/disk/by-label
       total 0
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 BDAUSB -> ../../sdn1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 BDAUSBBOOT -> ../../sdm1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 SWAP-sda3 -> ../../sda3
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 SWAP-sdb3 -> ../../sdb3
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u01 -> ../../sda4
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u02 -> ../../sdb4
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u03 -> ../../sdc1
       lrwxrwxrwx 1 root root 10 Aug  3 01:22 u04 -> ../../sdd1
            .
            .
            .

6. 出力に交換したディスクがリストされない場合:

   - Linux 5で、`udevtrigger`を実行します。

   - Linux 6で、`udevadm trigger`を実行します。

   その後、手順5を繰り返します。`lsscsi`コマンドも、ディスクの正しい順序をレポートする必要があります。

7. 適切なマウント・ポイントを入力してHDFSパーティションをマウントします。

       # mount /unn

   たとえば、`mount /u03`とします。

8. 複数のドライブを構成する場合、前述の手順を繰り返します。

9. Cloudera ManagerでHDFSドライブのマウント・ポイントを削除していた場合、リストにリストアします。

   1. Cloudera Managerのブラウザ・ウィンドウを開きます。次に例を示します。

      `http://bda1node03.example.com:7180`

   2. Cloudera Managerを開き、`admin`としてログインします。

   3. 「Services」ページで、「hdfs」をクリックします。

   4. 「Instances」サブタブをクリックします。

   5. 「Host」列で、交換ディスクのあるサーバーを特定します。次に、「Name」列のサービス(datanodeなど)をクリックしてそのページを開きます。

   6. 「Configuration」サブタブをクリックします。

   7. 「Directory」フィールドにマウント・ポイントがない場合、リストに追加します。

   8. 「Save Changes」をクリックします。

   9. 「Actions」リストから、「Restart」を選択します。

10. 以前に「NodeManager Local Directories」からマウント・ポイントを削除した場合、Cloudera Managerを使用してそれもリストにリストアします。

    1. 「Services」ページで、「Yarn」をクリックします。

    2. 「Status Summary」で、「NodeManager」をクリックします。

    3. リストから、障害ディスクのあるホスト上のNodeManagerをクリックして選択します。

    4. 「Configuration」サブタブをクリックします。

    5. 「NodeManager Local Directories」フィールドにマウント・ポイントがない場合、リストに追加します。

    6. 「Save Changes」をクリックします。

    7. 「Actions」リストから、「Restart」を選択します。

11. 構成を確認します。「ディスク構成の確認」を参照してください。

## 12.10 ディスク構成の確認

Oracle Big Data Applianceソフトウェアをサーバーに再インストールする前に、新しいディスク・ドライブの構成が適切であることを確認する必要があります。

ディスク構成を確認するには、次の手順を実行します。

1. ソフトウェア構成を確認します。

       # bdachecksw

2. エラーが存在する場合、必要に応じて構成手順を再実行して問題を修正します。

3. `/root`ディレクトリで`BDA_REBOOT_SUCCEEDED`というファイルを確認します。

4. `BDA_REBOOT_FAILED`という名前のファイルが見つかった場合には、そのファイルを読んで新しい問題を特定し、修正します。

5. 次のスクリプトを使用して、`BDA_REBOOT_SUCCEEDED`ファイルを生成します。

       # /opt/oracle/bda/lib/bdastartup.sh

6. `BDA_REBOOT_SUCCEEDED`が存在することを確認します。まだ`BDA_REBOOT_FAILED`ファイルが見つかる場合には、前の手順を繰り返します。