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
-
ディスクの修理の手順は、Oracle Big Data Applianceサーバーの部品を参照してください
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 ディスク・ドライブ識別子について
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.2.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.2.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.2.3 ディスク・ドライブの物理スロット番号の取得
次のMegaCli64
コマンドを使用して、仮想ドライブ番号と物理スロット番号のマッピングを確認します。「ディスク・ドライブの交換」を参照してください。
# MegaCli64 LdPdInfo a0 | more
13.3 ディスク交換プロセスの概要
- 障害ディスク・ドライブを交換します。
- Bdaconfigurediskユーティリティを実行して、新しいディスク・ドライブを構成します。
Bdaconfigurediskユーティリティは、残りの処理を自動化します。その操作は次のとおりです。
- 新しいディスクの基本構成ステップを実行します。
- 障害ディスクの固有の機能がオペレーティング・システム・ディスク、HDFSディスクまたはOracle NoSQL Databaseディスクのいずれであるかを識別します。
- ディスクをその固有の機能用に構成します。
- 構成が正しいことを確認します。
- ディスクをプロビジョニングします(Oracle Big Data Applianceソフトウェアをインストールします)。
関連項目:
次の場所にあるOracle X8-2Lサービス・マニュアルのストレージ・ドライブの修理に関する項
https://docs.oracle.com/cd/E93361_01/html/E93393/gqtcs.html#scrolltoc
次の場所にある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.4 サーバーが再起動しない場合の対処方法
サーバーは、ディスク交換手順の最中に、ユーザーがreboot
コマンドを発行したため、またはMegaCli64コマンドでエラーが発生したために再起動することがあります。ほとんどの場合、サーバーは正常に再起動し、作業を継続できます。ただし、それ以外の場合、エラーが発生するためにSSHを使用して再接続できなくなります。この場合、Oracle ILOMを使用して再起動を完了する必要があります。
Oracle ILOMを使用してサーバーを再起動するには、次の手順を実行します。
-
ブラウザで、Oracle ILOMを使用してサーバーに対する接続を開きます。次に例を示します。
http://bda1node12-c.example.com
ノート:
ブラウザには、JDKプラグインがインストールされている必要があります。ログイン・ページにJavaのコーヒー・カップが表示されない場合、作業を続行する前にプラグインをインストールする必要があります。
-
Oracle ILOM資格証明を使用してログインします。
-
「Remote Control」タブを選択します。
-
「Launch Remote Console」ボタンをクリックします。
-
[Ctrl]を押しながら[D]を押し、再起動を続行します。
-
再起動に失敗した場合、プロンプトでサーバーの
root
パスワードを入力し、問題の修正を試みます。 -
サーバーが正常に再起動したら、「Redirection」メニューを開いて「Quit」を選択し、コンソール・ウィンドウを閉じます。
13.5 障害ディスクを交換するための前提条件
予測障害状態にあるHDFSディスクまたはオペレーティング・システム・ディスクを交換するには、最初にHDFSパーティションをディスマウントする必要があります。オペレーティング・システム・ディスクを交換する前には、スワッピングを無効にする必要もあります。
ノート:
HDFSパーティションのみをディスマウントしてください。オペレーティング・システム・ディスクの場合、オペレーティング・システム・パーティションをディスマウントしないでください。HDFSには、オペレーティング・システム・ディスクのパーティション4 (sda4またはsdb4)のみを使用します。
HDFSパーティションをディスマウントするには、次の手順を実行します。
-
障害ドライブのあるサーバーにログインします。
-
障害ドライブがオペレーティング・システムをサポートしている場合、スワッピングを無効にします。
# bdaswapoff
アクティブなスワッピングが存在するディスクを削除すると、カーネルがクラッシュします。
-
マウントされている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 (sda4またはsdb4)を見つけます。オペレーティング・システム・パーティションはディスマウントしないでください。
-
障害ディスクのHDFSマウント・ポイントをディスマウントします。
# umount mountpoint
たとえば、
umount /u11
によって、パーティション/dev/sdk1
のマウント・ポイントが削除されます。umount
コマンドに成功した場合、「ディスク・ドライブの交換」に進みます。umount
コマンドがデバイス・ビジー・メッセージで失敗した場合、パーティションはまだ使用中です。次のステップに進みます。 -
Cloudera Managerのブラウザ・ウィンドウを開きます。次に例を示します。
http://bda1node03.example.com:7180
-
Cloudera Managerで次のステップを実行します。
ノート:
次のステップに従ってCloudera Managerでマウント・ポイントを削除する場合、他のすべての構成手順が終了した後に、Cloudera Managerでこれらのマウント・ポイントをリストアする必要があります。
-
admin
としてログインします。 -
「Services」ページで、「hdfs」をクリックします。
-
「Instances」サブタブをクリックします。
-
「Host」列で、障害ディスクのあるサーバーを特定します。次に、「Name」列のサービス(datanodeなど)をクリックしてそのページを開きます。
-
「Configuration」サブタブをクリックします。
-
「Directory」フィールドからマウント・ポイントを削除します。
-
「Save Changes」をクリックします。
-
「Actions」リストから、「Restart this DataNode」を選択します。
-
-
Cloudera Managerで、
NodeManager Local Directories
からマウント・ポイントを削除します。-
「Services」ページで、「Yarn」をクリックします。
-
「Status Summary」で、「NodeManager」をクリックします。
-
リストから、障害ディスクのあるホスト上のNodeManagerをクリックして選択します。
-
「Configuration」サブタブをクリックします。
-
NodeManagerからマウント・ポイントを削除します。
-
「Save Changes」をクリックします。
-
NodeManagerを再起動します。
-
-
同じHDFSマウント・ポイント(HBase Region Serverなど)にデータを格納する他のロールを追加した場合は、これらのロールに対するマウント・ポイントも同様に削除してリストアします。
-
障害ドライブのあるサーバーのセッションに戻ります。
-
umount
コマンドを再発行します。# umount mountpoint
umount
がまだ失敗する場合、lsof
を実行して、HDFSマウント・ポイントの下で開かれているファイルとそれらを開いたプロセスをリストします。これはunmountを妨げているプロセスを特定するのに役立ちます。次に例を示します。# lsof | grep /u11
-
ディスクをオフラインにします。
# MegaCli64 PDoffline "physdrv[enclosure:slot]" a0
たとえば、
"physdrv[20:10]"
はディスクs11を示します。これは、エンクロージャ20のスロット10にあります。 -
コントローラ構成表からディスクを削除します。
MegaCli64 CfgLDDel Lslot a0
たとえば、L10はスロット10を示します。
-
「ディスク・ドライブの交換」のステップを完了します。
13.6 ディスク・ドライブの交換
障害が発生または障害状態にあるディスク・ドライブを交換するには、次の手順を実行します。
-
障害ディスクを交換する前に、「障害ディスクを交換するための前提条件」を参照してください。
-
障害ディスク・ドライブを交換します。
「Oracle Big Data Applianceサーバーの部品」を参照してください。
-
障害ディスクを交換するためにサーバーの電源を切断した場合、電源を投入します。
-
KVMまたはラップトップとのSSL接続を使用して、
root
としてサーバーに接続します。 -
ファイルに物理ドライブの情報を保存します。
# 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 . . .
-
ステップ5で作成したファイルをテキスト・エディタで開き、次の項目を検索します。
-
Foreign StateがForeignのディスクでは、そのステータスを消去します。
# MegaCli64 CfgForeign clear a0
外部ディスクは、コントローラが以前認識していたディスクです(再挿入されたディスクなど)。
-
Firmware StateがUnconfigured (Bad)のディスクでは、次のステップを実行します。
-
エンクロージャ・デバイスのID番号とスロット番号を書き留めます。
-
次の書式でコマンドを入力します。
# MegaCli64 pdmakegood physdrv[enclosure:slot] a0
たとえば、[20:10]では、スロット10のエンクロージャ20によって識別されるディスクが修復されます。
-
もう一度Foreign Stateの現在のステータスを確認します。
# MegaCli64 pdlist a0 | grep foreign
-
Foreign StateがまだForeignの場合は、
clear
コマンドを繰り返します。# MegaCli64 CfgForeign clear a0
-
-
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によって識別されるディスクが修復されます。
-
ステップ9の
CfgLdAdd
コマンドがキャッシュされたデータにより失敗した場合は、キャッシュを消去します。# MegaCli64 discardpreservedcache l1 a0
-
ディスクがオペレーティング・システムによって認識されることを確認します。
# 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 [
-
サーバーのハードウェア・プロファイルを確認し、エラーがあれば修正します。
# bdacheckhw
-
サーバーのソフトウェア・プロファイルを確認し、エラーがあれば修正します。
# bdachecksw
「Wrong mounted partitions」エラーが表示され、デバイスがリストにない場合は、エラーを無視して続行できます。ただし、「Duplicate mount points」エラーが表示されるか、またはスロット番号が切り替わった場合は、「マウントされているパーティションのエラーの修正」を参照してください。
-
ドライブを適切に構成できるように、その機能を識別します。「ディスク・ドライブの機能の識別」を参照してください。
13.7 マウントされているパーティションのエラーの修正
bdachecksw
ユーティリティで見つかる問題は通常、マウントされているパーティションに関係しています。
古いマウント・ポイントがmount
コマンドの出力として表示される場合があるため、たとえば/u03など、同じマウント・ポイントが2回表示されることもあります。
重複しているマウント・ポイントを修正するには、次の手順を実行します。
-
umount
コマンドを2回使用して、両方のマウント・ポイントをディスマウントします。この例では、重複している2つの/u03をディスマウントしています。# umount /u03 # umount /u03
-
マウント・ポイントを再マウントします。この例では、/u03を再マウントしています。
# mount /u03
ディスクが誤ったスロット(つまり、仮想ドライブ番号)にある場合には、2つのドライブを切り替えることができます。
スロットを切り替えるには、次の手順を実行します。
-
両方のドライブのマッピングを削除します。この例では、スロット4および10からドライブを削除しています。
# MegaCli64 cfgLdDel L4 a0 # MegaCli64 cfgLdDel L10 a0
-
表示しようとする順序でドライブを追加します。最初のコマンドで、使用可能な最初のスロット番号が取得されます。
# MegaCli64 cfgLdAdd [20:4] a0 # MegaCli64 cfgLdAdd [20:5] a0
-
スロット番号が正しい場合であってもマウント・エラーが続く場合には、サーバーを再起動してください。
13.8 ディスク・ドライブの構成
bdaconfiguredisk
ユーティリティを使用して、Oracle Big Data Applianceサーバー上のディスク・ドライブを構成または再構成します。
bdaconfiguredisk
ユーティリティは、完全に自動化された処理でディスクを構成します。このユーティリティは、HadoopシステムとNoSQLシステムのオペレーティング・システムおよびデータ・ディスクで動作するようになりました。
関連項目:
- bdaconfiguredisk
-
手動でディスク構成する手順はこのガイドの付録として提供されていますが、手動の手順ではなく、すべてのステップが実行される
bdaconfiguredisk
を使用することをお薦めします。