ZFS ブート環境で GDS を使用してシステムディスクをミラーリングするには、以下の 2 つの方式があります。
GDS ミラー方式
GDS の1つのミラーボリュームで、ZFS のストレージプールを構成する方式です。
GDS ミラー方式には、以下の特長があります。
GDS のミラーリング機能によるシステムディスクの冗長化
GDS の I/O タイムアウト機能によるシステムの可用性の向上
従来の UFS ブート環境と同じ方法でシステムディスクの交換が可能
ZFS ミラー方式
GDS の 2 つのシングルボリューム (多重度 1 のミラーボリューム) で、ZFS のストレージプールを構成する方式です。
ZFS ミラー方式には、以下の特長があります。
ZFS のミラーリング機能によるシステムディスクの冗長化
GDS の I/O タイムアウト機能によるシステムの可用性の向上
図A.1 ZFS ブート環境におけるシステムディスクのミラーリング
GDS : Global Disk Services
ZFS ブート環境で GDS を使用してシステムディスクをミラーリングする場合、以下に注意してください。
ディスクの個数
システムディスク 1 個と、ミラー先のディスク 1 個の、合計 2 個のディスクによるミラーリングをサポートしています。
OS インストール時に、インストール先とするシステムディスクは 1 個だけ指定してください。
システムディスクのディスクラベル形式
SPARC M12、SPARC M10 (XCP2230 以降) またはSPARC Tシリーズ (System Firmware 8.4 以降) で、Solaris 11.1 以降を使用する場合、EFI ラベル付きディスクに OS をインストールできますが、GDS を使用する場合は VTOC ラベル付きディスクに OS をインストールしてください。
VTOC ラベル付きディスクに OS をインストールするには、format -e コマンドでインストール先のディスクに VTOC (SMI) ラベルを付与してから OS をインストールしてください。詳細は、SPARC M12/M10 のプロダクトノート、または、Oracle Solaris のマニュアルを参照してください。
システムディスクのパーティション構成
システムディスクには、GDS の占有スライス用に 20 MB の空き領域が必要です。
このため、OS インストール時には、ZFS ルートプールの構成を以下のように設定してください。
OS のインストール先として、システムディスク全体 (cXtXdXまたはcXtXdXs2) ではなく、スライス (cXtXdXsY) を指定する。
※Y は 0 以上、7 以下で 2 以外の整数。通常は Y は0 。
ZFS ルートプールの最大サイズは、(ディスクサイズ-21) [MB] 以下にする。
システムディスクミラーリングの設定と解除
ZFS ブート環境では、GDS 運用管理ビューによるシステムディスクミラーリングの設定と解除はできません。
コマンドによるシステムディスクミラーリングの設定と解除は、以下を参照してください。
GDS ミラー方式の場合:「7.1 ZFS ブート環境のシステムディスクミラーリング (GDS ミラー方式)」
ZFS ミラー方式の場合:「7.2 ZFS ブート環境のシステムディスクミラーリング (ZFS ミラー方式)」
システムディスクのバックアップ・リストア
ZFS ブート環境のルートクラスでは、スライス切離し方式によるスナップショットおよび GDS Snapshot を使用したシステムディスクのバックアップ・リストアはできません。
ZFS ブート環境のシステムディスクのバックアップ・リストアは、ZFS のスナップショット機能 (zfs snapshot 、zfs rollback 、zfs send 、zfs receive コマンドなど) で実施してください。詳細は、「6.2 ZFS ブート環境のシステムディスクのバックアップとリストア」を参照してください。
ブート環境の作成
ZFSルートプールをGDSのボリュームで構成している場合、ブート環境の作成可否は以下のとおりです。
ブート環境の作成方法 | Solaris 11 以前 | Solaris 11.1 以降 |
---|---|---|
beadm(1M) コマンドによる Boot Environment (BE) の作成 | × | ○ |
Solaris Live Upgrade によるブート環境の作成 | × | × |
○:作成可能、×:作成不可
GDS ミラー方式のシステムディスクの操作
GDS ミラー方式でシステムディスクのミラーリングを設定した後、ZFS は GDS のボリュームを ZFS ルートプールの構成要素となる仮想デバイスとして認識します。ZFS は、GDS のディスク構成やスライス構成を意識しません。
このため、GDS の物理ディスク交換操作、グループの構成変更などで、ZFS ルートプール内にある GDS のディスク構成を変更しても、ZFS への影響はありません。
したがって、システムディスクのミラーリングを設定した後は、従来の UFS ブート環境と同様の方法で、システムディスクの運用や操作ができます。
ZFS ミラー方式のシステムディスクの交換
ディスクの交換は、交換するディスク上の GDS のボリュームを ZFS ルートプールから切り離し、ディスクをルートクラスから削除した後、実施してください。
ディスク交換後、交換したディスクをルートクラスに登録してボリュームを作成し、作成したボリュームを ZFS ルートプールに接続してください。
[ZFS ミラー方式のシステムディスクの交換手順]
1) 交換対象のディスクのデバイス名を確認します。
sdxinfo コマンド実行結果中の DEVNAM 欄より、交換対象のディスクのデバイス名を確認します。
交換対象のディスクのデバイス名を把握されている場合は、本手順の実施は不要です。
例: rootDisk0002 のディスクを交換する場合
表示例では、rootDisk0002 のデバイス名は、c0t5000C5001D4809FFd0 です。
# sdxinfo -D
OBJ NAME TYPE CLASS GROUP DEVNAM DEVBLKS DEVCONNECT STATUS
------ ------------ ------ --------- --------- --------------------- --------- ---------------- -------
disk rootDisk0001 mirror RootClass rootGroup c0t5000CCA0150FEA10d0 585912500 * ENABLE
disk rootDisk0002 mirror RootClass rootGroup c0t5000C5001D4809FFd0 585912500 * ENABLE
disk dataDisk0001 mirror RootClass dataGroup c0t5000CCA00AC1C874d0 585912500 * ENABLE
disk dataDisk0002 mirror RootClass dataGroup c0t5000CCA0150F96F0d0 585912500 * ENABLE
2) ディスク上のボリュームを ZFS ルートプールから切り離します。
例:
# zpool detach rpool /dev/sfdsk/RootClass/dsk/Volume2
3) ディスクをルートクラスから削除します。
例:
# sdxvolume -F -c RootClass -v Volume2 # sdxvolume -R -c RootClass -v Volume2 # sdxgroup -R -c RootClass -g rootGroup # sdxdisk -R -c RootClass -d rootDisk0002
4) 交換前のディスクが接続されているハードウェア固有の識別子を調べます。
ハードウェア固有の識別子は、交換前のディスクのデバイス名が表示された情報の Ap_Id で確認します。
以下の例では、物理ディスク c0t5000C5001D4809FFd0 のハードウェア固有の識別子は c5::w5000c5001d4809fd です。
# cfgadm -av
Ap_Id Receptacle Occupant Condition Information
When Type Busy Phys_Id
~
c5::w5000c5001d4809fd,0 connected configured unknown \
Client Device: /dev/dsk/c0t5000C5001D4809FFd0s0(sd7)
unavailable disk-path n \
/devices/pci@400/pci@2/pci@0/pci@e/scsi@0/iport@4:scsi::w5000c5001d4809fd,0
~
5) ディスクを交換します。
6) OSの format(1M) コマンドなどを使用して、交換したディスクをシステムディスクと同じ構成にします。
7) 交換後のディスクのデバイス名を調べます。
手順 4) で調べたハードウェア固有の識別子の情報について、Occupant に "unconfigured" と表示されていることと、Phys_Id に表示されている "iport@X:scsi" の形式の情報を確認します。
交換後のディスクのデバイスは、Phys_Id に上記で確認した"iport@X:scsi"が表示され、かつ、Occupant に "configured" と表示されているデバイスです。
以下の例では、交換後のディスクのデバイス名は c0t5000C5001D4806BFd0 です。
# cfgadm -av
Ap_Id Receptacle Occupant Condition Information
When Type Busy Phys_Id
~
c5::w5000c5001d4809fd,0 connected unconfigured unknown (sd7)
unavailable disk-path n \
/devices/pci@400/pci@2/pci@0/pci@e/scsi@0/iport@4:scsi::w5000c5001d4809fd,0
c5:: w5000c5001d4806bd,0 connected configured unknown \
Client Device: /dev/dsk/c0t5000C5001D4806BFd0s0(sd8)
unavailable disk-path n \
/devices/pci@400/pci@2/pci@0/pci@e/scsi@0/iport@4:scsi::w5000c5001d4806bd,0
~
8) 交換後のディスクのリソースを PRIMECLUSTER(クラスタリソース管理機構)に登録します。
クラスタシステムでない場合、手順 9) 以降を実施してください。
8-1) PRIMECLUSTER が管理するクラスタのノード ID を確認します。
以下の例では、ノード ID は 0 になります。
# /etc/opt/FJSVcluster/bin/clgetnode
RID 3
KEY TRC89
RNAME TRC89
NODEID 0
8-2) 交換前のデバイスにおける PRIMECLUSTER のリソース ID を確認します。
clgetrid コマンドの -k オプションでは手順 1) で確認したデバイス名、-s オプションでは手順 8-1) で確認したノード ID を指定します。
以下の例では、リソース ID は 25 になります。
# /etc/opt/FJSVcluster/sys/clgetrid -c DISK -k c0t5000C5001D4809FFd0 -s 0
25
8-3) 交換前のディスクのリソースを削除します。
以下の例では、リソース ID が 25 のリソースを削除します。
# /etc/opt/FJSVcluster/bin/cldeldevice -r 25
8-4) 交換前のディスクのリソースが削除されていることを確認します。
削除したリソースが表示されていないことを確認します。
# /etc/opt/FJSVcluster/sys/clgetrid -c DISK -k c0t5000C5001D4809FFd0 -s 0
8-5) 交換後のディスクを PRIMECLUSTER に登録します。
# /etc/opt/FJSVcluster/sys/clautoconfig -r
8-6) 交換後のディスクのデバイス名が登録されていることを確認します。
交換後のディスクのデバイス名 (c0t5000C5001D4806BFd0) が表示されていることから、交換後のディスクがPRIMECLUSTER に登録されたことが確認できます。
# /etc/opt/FJSVcluster/bin/clgettree
Cluster 1 cluster
Domain 2 cluster
Shared 7 SHD_cluster
SHD_DISK 3417 SHD_Disk3417 UNKNOWN
DISK 3418 c3t46554A4954535520333030303030383530303043d0 UNKNOWN TRC89
DISK 3477 c3t46554A4954535520333030303030383530303043d0 UNKNOWN ryuta
SHD_DISK 3419 SHD_Disk3419 UNKNOWN
DISK 3420 c3t46554A4954535520333030303030383530303042d0 UNKNOWN TRC89
DISK 3478 c3t46554A4954535520333030303030383530303042d0 UNKNOWN ryuta
Node 3 TRC89 ON
Ethernet 105 igb3 UNKNOWN
SDX_DC 3519 RootClassI UNKNOWN
DISK 71 c0t5000CCA0150FEA10d0 UNKNOWN
DISK 72 c0t5000CCA00AC1C874d0 UNKNOWN
DISK 73 c0t5000CCA0150F96F0d0 UNKNOWN
DISK 3418 c3t46554A4954535520333030303030383530303043d0 UNKNOWN
DISK 3420 c3t46554A4954535520333030303030383530303042d0 UNKNOWN
DISK 3518 c0t5000C5001D4806BFd0 UNKNOWN
Node 5 ryuta ON
Ethernet 106 igb3 UNKNOWN
DISK 101 c0t5000C5001D480F6Fd0 UNKNOWN
DISK 3477 c3t46554A4954535520333030303030383530303043d0 UNKNOWN
DISK 3478 c3t46554A4954535520333030303030383530303042d0 UNKNOWN
9) GDS のディスク情報を再読込みします。
# sdxinfo -x Refresh
10) 交換したディスクをルートクラスに登録しボリュームを作成します。
例:
# sdxdisk -M -c RootClass -a type=root -d c0t5000C5001D4806BFd0=rootDisk0002:keep # sdxdisk -C -c RootClass -g rootGroup -d rootDisk0002 -v 0=Volume2:on
11) 交換したディスク上のボリュームを ZFS ルートプールに接続します。
例:
# zpool attach rpool /dev/sfdsk/RootClass/dsk/Volume1 \
/dev/sfdsk/RootClass/dsk/Volume2
zpool attach コマンド実行後、ZFS の再同期処理が実行されます。このとき、コンソールに OS のメッセージ (SUNW-MSG-ID: ZFS-8000-QJ) が出力されることがありますが、システムには影響ありません。
ZFS の再同期処理実行中、zpool status コマンドの出力の state に "DEGRADED" と表示されることがありますが、再同期処理完了後、state に "ONLINE" と表示されれば問題ありません。
12) ZFS による再同期化処理が完了後、交換したディスク上のボリュームにブートブロックをインストールします。
以下の環境の場合、この手順は実行しないでください。
Solaris 10 を使用し、カーネルパッチ 144500-19以降を適用している場合
Solaris 11 11/11以降の場合
例:
# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk \
/dev/sfdsk/RootClass/rdsk/Volume2
注意
交換したディスクは、OBP の boot-device プロパティに自動的には設定されません。システムを再起動すると交換したディスクが boot-device プロパティに設定されるため、手順 7 の後、なるべく早めにシステムを再起動してください。