Red Hat Enterprise Linuxをインストールしたら、クラスタハードウェアコンポーネントをセットアップし、 メンバーが接続されているすべてのデバイスを認識していることを確認します。 ハードウェアの設定手順は、構成の種類によって異なります。 クラスタ構成の詳細については、項1.1を参照してください。
クラスタハードウェアをセットアップするには、以下の手順に従ってください。
メンバーをシャットダウンし、電源を外します。
必要な場合は、ボンドした Ethernet チャンネルをセットアップします。詳細については、項1.4.1を参照してください。
電源スイッチを使用する場合は、スイッチをセットアップして、各メンバーを電源スイッチに接続します。 詳細については、項1.4.2を参照してください。
更には、各電源スイッチ(電源スイッチを使用していない場合は、各メンバーの電源コード) を個別のUPSシステムに接続することをお勧めします。 オプションのUPS システムの使用方法については、 項1.4.3を 参照してください。
ベンダーの説明書に従って、共有ディスクストレージをセットアップし、 メンバーを外部ストレージケースに接続します。 この手順の操作詳細については、項1.4.4を参照してください。
更に、ストレージケースを冗長UPSシステムに接続することをお勧めします。 オプションのUPSシステムの使用方法の詳細については、項1.4.3を参照してください。
ハードウェアの電源を入れ、各クラスタメンバーを起動します。 起動時にBIOSユーティリティに入り、メンバー設定を以下のように変更します。
BIOSユーティリティを終了し、各メンバーの起動を続行します。を起動メッセージを 読んで、PROD;カーネルが設定されていて、すべての共有ディスクを認識できることを確認 します。コンソール起動メッセージを表示するには、dmesgコマンドを使用します。 dmesgコマンドの使用方法の詳細については、項1.3.3を参照してください。
pingコマンドを使用して各ネットワークインターフェースを介してパケットを送信し、 メンバーが各ポイントーツーポイントEthernet接続を介して通信できることを確認します。
共有ディスクストレージ上に共有クラスタパーティションを設定します。 この手順の詳細については、項1.4.4.3 を参照してください。
no-single-point-of-failure クラスターシステム内のEthernet channel bonding は 2つの Ethernet デバイスを1つの仮想デバイスに合成することにより、fault tolerant ネットワークを許可することになります。その結果、channel がボンドした インターフェイスは、Ethernet が不具合を示す時に他のデバイスが確実にアクティブに なるようにします。 このタイプの channel bonding はactive-backup ポリシーと呼ばれ、両方のボンドしたデバイスを許可したり、各Ethernet デバイスを別々のハブ、又はスイッチに接続できるように許可できます。これにより ネットワークのハブ/スイッチ内の1箇所の停止ポイントを回避することになります。
Channel bonding には各クラスターメンバーが2つの Ethernet デバイスの インストールを持つ必要があります。ロードされた時点で、bonding モジュールは 1番目のスレーブ化したネットワークデバイスの MAC アドレスを使用し、 1番目のデバイスがリンクの検出に失敗した場合、そのMAC アドレスを他のネットワーク デバイスに割り当てます。
channel bonding 用に2つのネットワークデバイスを設定するには、以下を実行 します:
/etc/modules.confの中に bonding デバイスを作成します。 例えば:
alias bond0 bonding options bonding miimon=100 mode=1 |
これが、bond0のインターフェイス名の、bonding デバイスとbonding ドライバーへのオプションをロードして、スレーブネットワーク インターフェイス用のアクティブなバックアップマスターデバイスとして 設定します。
eth0 と eth1用に/etc/sysconfig/network-scripts/ifcfg-ethX設定ファイルを編集して、ファイルが同一の内容を示すように します。例えば:
DEVICE=ethX USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none |
これがethX (Xを Ethernetデバイスの割り当て番号に入れ換える) をマスターデバイスのbond0の配下に置きます。
bondingデバイス用(例、/etc/sysconfig/network-scripts/ifcfg-bond0) にネットワークスクリプトを作成します。これは、次の例のように表示 されます:
DEVICE=bond0 USERCTL=no ONBOOT=yes BROADCAST=192.168.1.255 NETWORK=192.168.1.0 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 IPADDR=192.168.1.10 |
変更を有効にするには再起動をします。別の方法として、手動で bonding デバイスを ロードしてネットワークの再起動をします。例えば:
/sbin/insmod /lib/modules/`uname -r`/kernel/drivers/net/bonding/bonding.o \ miimon=100 mode=1 |
/sbin/service network restart |
電源スイッチにより、一方のメンバーは、フェイルオーバー処理の一部としてもう一方のクラスタシステムのサービスを再起動する前にそのシステムの電源のオンとオフを切り換えることができるようになります。リモートからメンバーを無効にできることにより、あらゆる障害状況でデータ整合性を保証することができます。実稼働環境のクラスタ構成では電源スイッチまたはwatchdog タイマーを使用することをお勧めします。 電源スイッチが存在しない構成は、開発(テスト)環境でのみ使用してください。 各種電源スイッチの説明については、項1.1.3を参照してください。このセクションで「電源スイッチ」という語句は、Watchdogタイマーを含むすべての電源スイッチを表しています。
物理的な電源スイッチを使用するクラスタ構成では、 各メンバーの電源ケーブルはシリアルまたはネットワーク接続(スイッチの種類による) を通じて電源スイッチに接続されています。フェイルオーバーが発生した場合、 一方のメンバーはこの接続を使用して、もう一方のメンバーのサービスを再起動する前に、そのメンバーの電源のオンとオフを切り換えることができます。
電源スイッチは、応答しない(ハングしている)メンバーのサービスがフェイルオーバーした後で、 そのメンバーが応答するようになったときにデータが破損するのを防ぎ、 もう一方のメンバーからI/Oを受信しているディスクにI/Oを発行します。 また、メンバーでquorum処理デーモンがダウンすると、 そのメンバーは共有クラスタパーティションをモニターできなくなります。 クラスタで電源スイッチまたはwatchdog タイマーを使用していない場合、 このエラーによってサービスが複数のメンバー上で実行されるようになり、 データが破損、おそらくシステムがクラッシュする可能性があります。
クラスタでは、電源スイッチを使用することを強くお勧めします。電源スイッチを使用しない方向で検討している場合は、その危険性を十分に理解した上で判断してください。
メンバーは、スワップ中または作業負荷が高いときに数秒間ハングした状態になります。 このため、十分な時間(通常は12秒)が経過してからもう一方のシステムがダウンしたと確信します (一般的には15秒)。
メンバーが、ハングしているメンバーがダウンしていると判断し、 クラスタで電源スイッチを使用している場合、 そのメンバーはサービスを再起動する前にハングしているシステムの電源のオンとオフを切り換えます。 システムのハングが発生するほとんどの状況下では、 watchdog タイマーを使用するよう設定されているクラスタはセルフリブートします。これにより、ハングしたシステムは、クリーンな状態で再起動され、 I/Oや破損したサービスデータを発行しなくなります。
watchdog の始動、ハートビートパケットの送信障害、 あるいは(メンバーに物理的な電源スイッチが装備されていない場合) quorum ステータスの損失などのいずれかが起因して、ハングしたメンバーは自身をリブートします。
ハングしたメンバーは、 電源スイッチに接続されている場合は他のメンバーによってリブートされることもあります。 ハングしたメンバーがまったく応答せず、電源スイッチを使用していない場合は、 手動でリブートする必要があります。
電源スイッチを使用する場合は、ベンダーの指示に従ってセットアップする必要があります。しかしクラスター内の電源スイッチを使用するのに電源クラスタ固有のタスクを 実施しなければならないこともあります。電源スイッチ(Watchdogタイマーを含む)の 詳細については、項B.1を参照してください。電源スイッチ 固有の規則事項と機能特性を必ず理解してください。本書で説明しているクラスタ固有の情報は、ベンダーの情報よりも優先されることに留意して下さい。
電源スイッチのケーブルを接続する際には、各ケーブルが正しいコネクタ/コンセントに接続されていることを必ず確認してください。ケーブル接続が正しいかどうかをソフトウェアで確認することはできないため、確認作業は非常に重要です。ケーブルが正しく接続されていないと、間違ったメンバーの電源のオンとオフが切り換えられることや、一方のメンバーがもう一方のクラスタメンバーの電源のオンとオフを正常に切り換えたと間違って確信することがあります。
電源スイッチをセットアップしたら、以下のタスクを実行して電源スイッチをメンバーに接続します。
各メンバーの電源ケーブルを電源スイッチに接続します。
各メンバーを電源スイッチに接続します。 シリアル接続で使用するケーブルは、 電源スイッチの種類によって異なります。 シリアル接続の電源スイッチでは ナルモデムケーブルを使用し、ネットワーク接続の電源スイッチではイーサネット パッチケーブルを使用する必要があります。
各電源スイッチの電源ケーブルをコンセントに差し込みます。 各電源スイッチは、個別のUPSシステムに接続することをお勧めします。 詳細については、項1.4.3を参照してください。
クラスタソフトウェアをインストールした後は、クラスタを起動する前に、 電源スイッチをテストして、各メンバーが、もう一方のメンバーの電源のオン/オフを切り換えることができることを確認します。 詳細については、項2.11.2を参照してください。
UPS(無停電電源装置)システムは、アベイラビリティ(可用性)の高い電源を提供します。 複数のUPS(サーバに1台)が組み込まれた冗長ソリューションを採用することをお勧めします。 最高のフォールトトレランス性を実現できるように、 サーバあたり2台のUPSシステムとAPCのAutomatic Transfer Switchesを組み込んで、 サーバの電源とシャットダウンを管理することもできます。 どちらのソリューションを採用するかは、アベイラビリティ(可用性)の要件によって決まります。
クラスタの単独の電源として、単独UPSインフラストラクチャを使用することは お勧めできません。 クラスタ専用のUPSソリューションの方が、管理およびアベイラビリティ(可用性)において高い柔軟性を発揮します。
完成したUPSシステムはm長期間に渡り適切な電圧と電流が供給可能でなければなりません。 すべての電力要件に合う単一UPSはありませんが、 特定の構成に合うようソリューションを調整することはできます。
クラスタディスクストレージサブシステムに、個別電源コードの電源が2系統ある場合は、 UPSシステムを2つセットアップし、 電源スイッチ1つ(電源スイッチを使用していない場合はメンバーの電源コード) とストレージサブシステムの電源コード1本を各UPSシステムに接続します。 冗長UPSシステムの構成を図1-3に示します。
もう一つの冗長電源構成として、両方の電源スイッチ(またはメンバーの電源コード)と ディスクストレージサブシステムを同じUPSシステムに接続する方法があります。 これが最もコスト効果の良い構成で、電源障害に対してある程度の保護機能を提供します。 ただし、停電した場合、単独UPSシステムが障害発生箇所となる可能性があります。 また、単独UPSシステムが、接続されているすべてのデバイスに 十分な電源を十分な時間供給できない可能性もあります。 単独UPSシステム構成は図1-4に示してあります。
ベンダーが提供している多くのUPSシステムに、 シリアルポート接続経由でUPSシステムの動作ステータスをモニターするRed Hat Enterprise Linux アプリケーションが含まれています。 バッテリ電圧が低くなると、モニタリングソフトウェアはクリーンシステムシャットダウンを実行します。 これは、SysVのランレベルスクリプト(たとえば、/etc/rc.d/init.d/clumanager) によって制御されるため、クラスタソフトウェアは正常に停止します。
インストール方法の詳細については、ベンダーが提供しているUPSのマニュアルを参照してください。
クラスタでは、共有ディスクストレージは、 サービスデータとクラスタの状態情報を格納する2つのパーティション(プライマリーとシャドー) を保持するのに使用されます。 このストレージは、すべてのメンバーが使用できる必要があるため、 いずれかのメンバーのアベイラビリティ(可用性)に依存するディスク上にあってはいけません。 製品とインストールの詳細については、ベンダーの説明書を参照してください。
クラスタに共有ディスクストレージを設定する場合は、以下のことを検討する必要があります。
外部RAID
RAID 1(ミラーリング)を使用して、 サービスデータと共有クラスタパーティションのアベイラビリティ(可用性)を高めることを強くお勧めします。 オプションで、パリティRAIDを採用してアベイラビリティ(可用性)を高めることもできます。 共有パーティション用にRAID 0(ストライピング)を単独で使用しないでください。 ストレージのアベイラビリティ(可用性)が低下します。
マルチイニシエータSCSI構成
適切なバスターミネーションを得ることが困難であるため、マルチイニシエータSCSI構成はサポートされていません。
各共有ストレージデバイスのRed Hat Enterprise Linuxデバイス名は、各メンバーで同じでなければなりません。 たとえば、一方のメンバー上の/dev/sdcという名前のデバイスは、 もう一方のクラスタメンバー上でも/dev/sdc という名前になっている必要があります。 通常、すべてのメンバーに同じハードウェアを使用することで、 これらのデバイスには同じ名前が付けられるようになります。
ディスクパーティションは、1つのクラスタサービスだけが使用できます。
クラスタソフトウェアはサービスファイルシステムのマウントとアンマウントを制御する必要があるため、 クラスタサービスで使用しているファイルシステムをメンバーのローカルの /etc/fstabファイルに含めないでください。
共有ファイルシステムの最適なパフォーマンスのために、 mke2fsコマンドに-bオプションを付けて 4 KB ブロックサイズを必ず指定してください。 これより小さいブロックサイズだと、fsckに時間がかかります。 項1.4.4.6を参照してください。
パラレルSCSIをクラスタ環境で使用する場合に従う必要がある パラレルSCSI要件の詳細を以下に示します。
SCSIバスは両端でターミネートする必要があります。また、長さとホットプラグに関する制約に従う必要があります。
SCSIバス上のデバイス(ディスク、ホストバスアダプタ、RAIDコントローラ)には、固有なSCSI ID番号を付ける必要があります。
詳細については、項B.2を参照してください。
アベイラビリティ(可用性)の高い電源を確保できるように、ストレージケースを冗長UPSシステムに接続することを強くお勧めします。詳細については、項1.4.3を参照してください。
共有ストレージの構成の詳細については、項1.4.4.1と項1.4.4.2を参照してください。
共有ディスクストレージハードウェアをセットアップしたら、ディスクをパーティション構成し、 パーティション上にファイルシステムまたはrawデバイスを作成します。 プライマリとシャドーの共有クラスタパーティション用に2つのrawデバイスを作成する必要があります。 詳細については、項1.4.4.3、項1.4.4.4、項1.4.4.5、項1.4.4.6を参照してください。
シングルイニシエータSCSIバスには1つのメンバーだけが接続されていて、 ホストの分離とマルチイニシエータバスよりも優れたパフォーマンスを提供します。 シングルイニシエータバスにより、各メンバーは、他のメンバーの作業負荷、 初期化、または修理による中断などの影響を受けなくなります。
複数のホストポートがあり、ストレージケースのホストポートからすべての共有論理ユニットに同時にアクセス可能なシングルまたはデュアルコントローラRAIDアレイを使用している場合は、 各クラスタメンバーをRAIDアレイに接続するようにシングルイニシエータSCSIバスをセットアップできます。 論理ユニットが一方のコントローラからもう一方のコントローラにフェイルオーバーできる場合、 処理はオペレーティングシステムに透過的でなければなりません。 一部のRAIDコントローラでは、特定のコントローラまたはポートへのディスクセットが制限されています。 この場合、シングルイニシエータバスをセットアップすることはできません。
シングルイニシエータバスは、項B.2 に 記載されている要件に適合していなければなりません。
シングルイニシエータSCSIバス構成をセットアップするには、以下のことを実行する必要があります。
各ホストバスアダプタのオンボードターミネーションをイネーブルにします。
各RAIDコントローラのターミネーションをイネーブルにします。
適切なSCSIケーブルを使用して、各ホストバスアダプタとストレージケースを接続します。
ホストバスアダプタのターミネーションの設定は、通常、 メンバーの起動時にアダプタのBIOSユーティリティで行ないます。 RAIDコントローラのターミネーションの設定方法については、ベンダーのマニュアルを参照してください。 図1-5 は、 2つのシングルイニシエータSCSIバスを使用した構成を示しています。
図1-6は、 2つのシングルイニシエータSCSIバスに接続された シングルコントローラRAIDアレイのターミネーションを示しています。
図1-7は、 2つのシングルイニシエータSCSIバスに接続された デュアルコントローラRAIDアレイのターミネーションを示しています。
ファイバーチャネルは、シングルイニシエータ構成またはマルチイニシエータ構成で使用できます。
シングルイニシエータファイバーチャネル相互接続には1つのメンバーだけが接続されています。 これにより、ホストの分離とマルチイニシエータバスよりも優れたパフォーマンスを提供します。 シングルイニシエータ相互接続により、各メンバーは、他のメンバーの作業負荷、 初期化、または修理による中断などの影響を受けなくなります。
複数のホストポートがあり、 ストレージケースのホストポートからすべての共有論理ユニットに 同時にアクセス可能なRAIDアレイを使用している場合は、 シングルイニシエータファイバーチャネル相互接続をセットアップして各メンバーをRAIDアレイに接続します。 論理ユニットが一方のコントローラからもう一方のコントローラにフェイルオーバーできる場合、 処理はオペレーティングシステムに透過的でなければなりません。
図1-8は、2つのホストポートのあるシングルコントローラRAIDアレイと、ファイバーチャネルハブまたはスイッチを使用せずに、ホストバスアダプタをRAIDコントローラに直接接続した状態を示しています。このタイプの シングルイニシエータファイバチャンネル接続を使用する場合、RAIDコントローラは 各クラスターメンバー用に個別のホストポートを必要とします。
外部RAIDアレイは各クラスターメンバー毎に個別の SCSI チャンネルを持つ必要が あります。2つ以上のメンバーを持つクラスターでは、図1-8に示してあるように、シングルイニシエータ SCSI バスを使って各メンバーをRAIDアレイ上の別々の SCSI チャンネルに接続します。
RAID アレイ上の同じホストポートへマルチクラスターを接続するには、FC ハブ又は スイッチを使用します。この場合、各HBAは、ハブまたはスイッチに接続され、 ハブまたはスイッチは RAID コントローラのホストポートに接続されます。
ファイバーチャンネルのハブ又はスイッチは、各コントローラ上に2つのホストポートを 持つデュアルコントローラRAID アレイでも必要となります。この構成は図1-9に表示されています。追加のクラスターメンバーは表に 示してあるように、ファイバーチャンネルのハブ又はスイッチに接続することが出来ます。 RAID アレイの幾つかには、組み込み型のハブが含まれており、各ホストポートは既に それぞれの内部 RAID コントローラに接続されています。この場合、追加の外部ハブ 又は、スイッチが必要でなくなります。
プライマリ共有パーティションとシャドー共有パーティション用に、 共有ディスクストレージ上に2つのrawデバイスを作成する必要があります。 各共有パーティションは、10 MB以上でなければなりません。 共有パーティション内のデータ量は一定です。 つまり増加したり減少することはありません。
共有パーティションは、以下のようなクラスタの状態情報を格納するために使用されます。
クラスタロックの状態
サービスの状態
構成情報
定期的に各メンバーはそのサービスの状態を共有ストレージに書き込みます。 また、共有パーティションにはクラスタ構成ファイルのバージョンが格納されています。 これにより、各メンバーに表示されるクラスタ構成が同じになります。
プライマリ共有パーティションが破損した場合、 クラスタメンバーはその情報をシャドー(バックアップ)共有パーティションから読み込み、 同時にプライマリパーティションを修復します。 データ整合性は、チェックサムを通じて維持され、パーティション間に不整合がある場合は、 自動的に訂正されます。
メンバーが起動時に両方の共有パーティションに書き込みを行えない場合、 そのメンバーはクラスタに組み込まれません。 また、アクティブなメンバーが両方の共有パーティションに書き込めなくなると、 メンバーは再起動して自分自身をクラスタから除外します (また、正常なメンバーによってリモートから電源のオンとオフが切り換えられます)。
共有パーティションの要件を以下に示します。
どちらの共有パーティションも容量は10 MB以上でなければならない
共有パーティションはrawデバイスでなければならない。ファイルシステムを含むことはできない。
共有パーティションは、クラスタの状態情報と構成情報用にだけ使用できる。
共有パーティションを構成する際の推奨ガイドラインを以下に示します。
共有ストレージ用にRAIDサブシステムを設定し、 RAID 1(ミラーリング)を使用して共有パーティションを含む論理ユニットのアベイラビリテ(可用性) を高めることを強くお勧めします。 オプションで、パリティRAIDを採用してハイアベイラビリティを実現することもできます。 共有パーティション用にRAID 0(ストライピング)を単独で使用しないでください。
クラスタが実行するためには両方の共有パーティションが使用可能になっている必要があるため、 両方とも同じRAIDセット上、またはRAIDを使用していない場合は同じディスク上、に配置してください。
共有パーティションは、 頻繁にアクセスされるサービスデータが含まれているディスクには配置しないでください。 できれば、ほとんどアクセスされないサービスデータが含まれているディスク上に作成してください。
共有パーティションのセットアップの詳細については、項1.4.4.4および項1.4.4.5を参照してください。
メンバーが起動するたびに、rawキャラクタデバイスをブロックデバイスにバインドするように rawdevicesファイルを編集する方法については、 項2.5 を参照してください。
共有ディスクストレージハードウェアをセットアップしたら、クラスタで使用できるようにディスクにパーティションを設定します。 そして、パーティションにファイルシステムまたはrawデバイスを作成します。 たとえば、項1.4.4.3 で説明しているガイドラインに従って共有パーティション用に 2つのrawデバイスを作成する必要があります。
partedコマンドを使用してディスクパーティションテーブルを変更し、 ディスクをパーティションに区分します。parted の使用中は、 pを使用してパーティションテーブルを表示したり、 mkpartコマンドを使用して新しいパーティションを作成できます。 partedを使用してディスクにパーティションを作成する方法を以下の例で示します。
シェルでpartedコマンドを実行して使用できる共有ディスクデバイスを指定します。 (parted)プロンプトで、 pを入力して現在のパーティションテーブルを表示します。 出力は次のようになります。
Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags |
必要なパーティションのサイズを決定します。 partedでmkpartコマンドを使い、 このサイズのパーティションを作成します。 通常、パーティション作成時にファイルシステムタイプが必要とされますが、 mkpartではファイルシステムを作成しません。 partedではディスクの範囲を使用してパーティションのサイズを決定します。 サイズとは特定の範囲の始点から終点までのあいだの領域のことです。 空のディスクにそれぞれ 20 MB のパーティションを2つ作成する方法を以下の例に示します。
(parted) mkpart primary ext3 0 20 (parted) mkpart primary ext3 20 40 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary |
1つのディスクに4つ以上のパーティジョンが必要な場合、 拡張パーティションを作成する必要があります。 拡張パーティションが必要な場合も、mkpartで作成することができます。 この場合、ファイルシステムタイプを指定する必要はありません。
![]() | 注記 |
---|---|
拡張パーティションは1つだけでも構いません、 その拡張パーティションは4つのプライマリパーティションのうちの1つでなければなりません 。 |
(parted) mkpart extended 40 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended |
拡張パーティションは、その中に論理パーティションを作成することができます。 拡張パーティションを2つの論理パーティションに分割した例を示します。
(parted) mkpart logical ext3 40 1000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical (parted) mkpart logical ext3 1000 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
partedのrm コマンドを使ってパーティションを削除することができます。 例えば、
(parted) rm 1 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
必要なパーティションをすべて作成したら、 quitコマンドを使ってpartedを終了します。 両方のメンバーの電源がオンになっていて共有ストレージに接続されている間にパーティションの追加、 削除、変更が行なわれた場合、他のメンバーをリブートしてこれらの変更を認識させます。 ディスクのパーティション設定が終了したら、クラスターで使用するためにそのパーティション をフォーマットします。 例えば、共有パーティション用のファイルシステム またはrawデバイスを作成します。 詳細については、項1.4.4.5 及び 項1.4.4.6を参照してください。
インストール時のハードディスクパーティション設定のための基本情報に ついては、Red Hat Enterprise Linux インストールガイドを参照してください。
共有ストレージディスクにパーティションを設定したら、パーティション上にrawデバイスを作成します。 ファイルシステムは、パフォーマンスを向上させるために最近使用したデータをメモリ内にキャッシュするブロックデバイス(たとえば、/dev/sda1)です。 rawデバイスはキャッシュ用ににシステム メモリを利用しません。 詳細については、項1.4.4.6を参照してください。
Red Hat Enterprise Linuxは、特定のブロックデバイスに対してハードコードされていない rawキャラクタデバイスをサポートしています。 その代わりに、Red Hat Enterprise Linuxは、キャラクタメジャー番号(現在162)を使用して、 バインドされていない一連のrawデバイスを/dev/rawディレクトリに実装します。 ブロックデバイスが実行時にロードされた場合でも、 すべてのブロックデバイスは、キャラクタrawデバイスフロントエンドを持つことができます。
rawデバイスを作成するには、/etc/sysconfig/rawdevicesファイルを編集して、 rawキャラクタデバイスを適切なブロックデバイスにバインドします。 これにより、rawデバイスを開いたり、読み取ったり、書き込むことができます。
共有パーティションと一部のデータベースアプリケーションは、rawデバイスを必要とします。 これは、これらのアプリケーションがパフォーマンスを向上させるために独自のバッファキャッシング を実行するためです。状態データがシステムメモリ内にキャッシュされると、 それぞれのメンバーには異なる状態データが表示されるようになるため、 共有パーティションにファイルシステムを含めることはできません。
raw キャラクタデバイスは、メンバーが起動するたびに、 ブロックデバイスに バインドされる必要があります。 必ずバインドされるようにするには、 /etc/sysconfig/rawdevicesファイルを編集して、 共有パーティションの バインドを指定します。 クラスタサービス内でrawデバイスを使用している場合は、 このファイルを使用して起動時にデバイスをバインドします。 詳細については、項2.5 を参照してください。
/etc/sysconfig/rawdevicesを編集したら、 再起動するか以下のコマンドを実行することで変更を適用できます。
service rawdevices restart |
raw -aqコマンドを使用してすべてのrawデバイスを照会します。 出力は以下のようになります。
/dev/raw/raw1 bound to major 8, minor 17 /dev/raw/raw2 bound to major 8, minor 18 |
rawデバイスの場合、rawデバイスとブロックデバイス間にキャッシュコヒーレンシはありません。 また、要求は、メモリ内およびディスク上の両方で512バイトに割り当てられている必要があります。 たとえば、標準のddコマンドは、rawデバイスでは使用できません。 これは、コマンドが書き込みシステムコールに渡すメモリバッファが 512バイト境界に割り当てられていないためです。
rawの使用方法の詳細については、raw(8)の man ページを参照してください。
![]() | 注記 |
---|---|
すべてのクラスタメンバーでrawデバイスは同じ名前を使用する必要があります (例、/dev/raw/raw1と/dev/raw/raw2)。 |