13 サーバー・ディスクの交換

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

注意:

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

物理ディスクの修理では、Oracle Big Data Applianceを停止する必要はありません。ただし、個々のサーバーは一時的にクラスタの外部に取り出すことがあり、停止時間が必要です。

関連項目:

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

13.1 サーバー構成の確認

各Oracle Big Data Applianceサーバーの12のディスク・ドライブは、LSI MegaRAID SAS 92610-8iディスク・コントローラによって制御されます。パフォーマンス低下の可能性や機能停止を避けるため、RAIDデバイスのステータスを確認することをお薦めします。RAIDデバイスを検証することによるサーバーに対する影響は、ごくわずかです。修正作業はサーバーの操作に影響する可能性があり、その範囲は、検出された特定の問題に応じて単純な再構成から機能停止にまで及びます。

13.1.1 ディスク・コントローラ構成の確認

ディスク・コントローラ構成を確認するには、次のコマンドを入力します。

# MegaCli64 -AdpAllInfo -a0 | grep "Device Present" -A 8

次に、コマンドからの出力例を示します。通常は、12の仮想ドライブがあり、縮退ドライブやオフライン・ドライブはなく、14の物理デバイスがあります。14のデバイスは、コントローラと12のディスク・ドライブです。

                Device Present
                ================
Virtual Drives    : 12 
  Degraded        : 0 
  Offline         : 0 
Physical Devices  : 14 
  Disks           : 12 
  Critical Disks  : 0 
  Failed Disks    : 0 

出力が異なる場合、調査して問題を修正してください。

13.1.2 仮想ドライブ構成の確認

仮想ドライブ構成を確認するには、次のコマンドを入力します。

# MegaCli64 -LDInfo -lAll -a0

次に、仮想ドライブ0に関する出力例を示します。StateがOptimalであることを確認してください。

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-0, Secondary-0, RAID Level Qualifier-0
Size                : 1.817 TB
Parity Size         : 0
State               : Optimal
Strip Size          : 64 KB
Number Of Drives    : 1
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Cached, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Cached, No Write Cache if Bad BBU
Access Policy       : Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None

13.1.3 物理ドライブ構成の確認

次のコマンドを使用して、物理ドライブ構成を検証します。

# MegaCli64 -PDList -a0 | grep Firmware

次に、コマンドからの出力例を示します。通常、12のドライブに、Online, Spun Upが表示されます。出力が異なる場合、調査して問題を修正してください。

Firmware state: Online, Spun Up
Device Firmware Level: 061A
Firmware state: Online, Spun Up
Device Firmware Level: 061A
Firmware state: Online, Spun Up
Device Firmware Level: 061A
     .
     .
     .

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

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

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

関連項目:

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

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

次の場所にある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

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

Oracle Big Data Applianceサーバーには、ホスト・バス・アダプタ(HBA)によって制御されるディスク・エンクロージャ・ケージが含まれます。エンクロージャには、スロット番号0から11で識別される12のディスク・ドライブがあります。ドライブは、表13-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として識別される場合があります。

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

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

表13-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

13.3.2 標準マウント・ポイント

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

表13-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

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

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

# MegaCli64 LdPdInfo a0 | more 

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

予測障害状態にある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. 「ディスク・ドライブの交換」のステップを完了します。

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

サーバーは、ディスク交換手順の最中に、ユーザーが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/

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

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

  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. ステップ9CfgLdAddコマンドがキャッシュされたデータにより失敗した場合は、キャッシュを消去します。

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

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

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

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

障害ディスクのあるサーバーは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. 前のステップで障害ディスクがオペレーティング・システム・ディスクであることがわかった場合、「オペレーティング・システム・ディスクの構成」に進みます。

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

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

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

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

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

13.9.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/smとして/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アレイの修理」のステップを完了します。

13.9.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パーティションのフォーマット」のステップを完了します。

13.9.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. 「スワップ・パーティションのリストア」のステップを完了します。

13.9.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 6で、udevadm triggerを実行します。

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

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

13.9.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が新しいデバイスを指すようにします。この例では、ステップ1s1/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. 構成を確認します。「ディスク構成の確認」を参照してください。

13.10 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. 存在しないデバイスに適切なパーティション・ラベルを再設定します。表13-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 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. 構成を確認します。「ディスク構成の確認」を参照してください。

13.11 ディスク構成の確認

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ファイルが見つかる場合には、前のステップを繰り返します。