Power Systems AIX: FAQ集 - LVM -

1.  LVMのホット・スペアのセットアップ方法

1-1.           対象ボリューム・グループ内の既存のディスクに基づいて、必要なホット・スペア・ディスクの数と大きさを決定します。

1-2.           extendvgコマンドを使って、ホット・スペア・ディスクを保護対象のボリューム・グループに追加します。

1-3.           ボリューム・グループに最適なホット・スペアのポリシーを決定します。y、Y、n、r の 4 通りのポリシー(オプション)があります。

1-4.           chpvコマンドあるいはSMITで、選択したディスクをホット・スペア・ディスクとして指定します。
SMITのPhysical Volumes >> Change Charactistics of a Physical Volume のところで、Set hotspare characteristicsを y にします。
chpvコマンドの場合は、たとえば chpv -h y hdisk3 のように指定します。

1-5.           chvgコマンドあるいはSMITで、要件に応じた同期ポリシーを設定します。
SMITのVolume Groups >> Set Characteristics of a Volume Group >> Change a Volume Group のところで、Set hotspare characteristicsを y/Y/n/r にします。
chvgコマンドの場合は、たとえば chvg -h y VGNAME のように指定します。

＜注＞1-4の作業だけでは、ディスクをホット・スペア・ディスクとしてマークするにすぎず、VG のホット・スペアリング特性は使用可能に設定されません。したがって、ホット・スペアリング機能を使用する場合は、１-4 の作業によるディスクのマーク付けと 1-5 の作業によるホット・スペアリング特性の設定が必要です。

2. ホット・スペアのポリシー(y，Y，n，r)

オプションの意味は以下のとおりになります。
y ･･･ 障害の発生したディスクの区画をホット・スペア・ディスクに対して 1 対 1 の関係で自動移行します。
Y ･･･ ホット・スペア・ディスクがVG内に複数存在した場合、障害の発生したディスクの区画をそれら全体への自動移行をします（1対多）。
なお、Y は、1つのディスクが一杯になったら、次のディスクを使うという形になります(均等に使うのではなく)。
n ･･･ 障害の発生したディスクの区画をホット・スペア・ディスクへの自動移行を禁止します。(デフォルトの動きです。)
r ･･･ VGのホット・スペア・ディスクプールからホット・スペア・ディスクを削除します。

詳しくはオンラインマニュアル「コマンドリファレンス第一巻」chvg コマンドの項を参照してください。
http://publibn.boulder.ibm.com/doc_link/Ja_JP/a_doc_lib/cmds/aixcmds1/chvg.htm

3. ディスク障害時、ディスクのSTATEの変化

任意ディスク障害時、障害を起こしたディスクのSTATEは missing になります：　障害発生 => 自動マイグレーション => 障害を起こしたディスクのSTATEはmissing に。
VG の AUTO SYNC 属性が no の場合でも、自動的に同期が行われますので、syncvgで同期する必要がありません。
自動移行が始まると、ホット・スペア・ ディスクの STATE が active/hotspare から active にかわります。　

4. 障害後のディスク交換

4-1.           reducevg を実行して障害ディスクをVGから削除

4-2.           rmdev -dl にてディスクを削除

4-3.           ディスク交換

4-4.           cfgmgr にて新規ディスクを構成

4-5.           extendvg にてVGにディスクを追加

4-6.           chpv コマンドにて追加したディスクをホット・スペア・ディスクにマーク

 Hot questions:

 Q. サイズの異なるディスクをホット・スペア・ディスクに指定できますか？
A. はい、できます。ただ、ホット・スペア・ディスクの容量は、すでにボリューム・グループにある最も小さいディスクより大きいものでなければなりません。
ミラーリングされたディスクのうち、最も大きいものを十分にカバーできる容量を備えるようにした方が良いでしょう。

Q. ホット・スペアリングが起こったときは自動的にマイグレーションが発生しますか？
A. ホット・スペアのポリシーをy，Yに設定すれば、自動的にマイグレーションが発生します。

Q. どのような VG でも、LVMのホット・スペア機能を使用できますか？
A. rootvg に対し、LVMのホット・スペア機能は使用すべきではありません。rootvg でホット・スペア機能を使用することは技術的には可能ですが、ページングが多く発生している状態でマイグレーションと同期が行われる可能性があり、予期せぬ結果を招きかねません。また、bosboot コマンドの実行やブート・リストの再設定なども自動的に行われません。このほか、コンカレント・モードの VG では、LVMのホット・スペア機能はサポートされません。

Q.  1つのディスクを、複数の VG のホット・スペア・ディスクとすることはできますか？
A. いいえ。

Q.  1 つの VG に複数のディスクをホット・スペア・ディスクとして構成し、hdisk0 のスペアは hdisk2、hdisk1のスペアは hdisk3 といった指定は可能ですか？
 A. できません。

Q. 実際、どのような障害時にホット・スペア機能が働きますか？
 A. ODM の errnotify クラスに、LVM_SA_PVMISS と LVM_SA_STALEPP のエラーに対する通知メソッドとして、/usr/sbin/hotspare が定義されます。
 LVM_SA_PVMISS は、PV を missing にマークしたときに出力されます。LVM_SA_STALEPP は、PP が Stale にマークされた時に出力されます。ただし、後者の場合は、VG が Autosync=on か検査して ON の場合、sync するようになっているのみで移行は発生しません。また、/usr/sbin/hotspare スクリプト中で、PV の STATE が REMOVED であった場合は、移行せずに終了するようになっています。したがって、移行は、LVM_SA_PVMISS エラーが検出された時で、かつ、PV の STATE が REMOVED でないときに開始されます。

Q. ホット・スペア機能はミラーリングの代わりとなるものですか？
 A. いいえ。ホット・スペア機能はミラーリング環境で使用するものです。ミラーリングでは、単一のディスク障害に対応することはできますが、ディスク障害後、これを交換し、再ミラーするまでは冗長性を欠いた状態となります。ホット・スペア・ディスクを使用することで、単一ディスク障害後にはホット・スペアリング(データのマイグレーション)を行い、冗長性を持たせた状態 (ミラーリングされた状態) に自動的に復帰させることが可能です。なお、データ移行および同期が起こるときには、I/O 負荷が高くなることに考慮が必要です。

 参照文献

AIXオペレーティングシステムの概念と上級システム管理p309　株式会社アスキー　古寺雅弘編著

 以上です。

AIXのmirrorvg機能

 rootvgと非rootvgにおけるミラーリングの設定手順と注意点について、まとめました。

1. rootvgのミラーリング

 以下は、hdisk0 のみから構成されている rootvg に hdisk1 を追加してミラーリングする場合を例にした手順です。

1-1.           ボリューム・グループに新しいディスクを追加します。

 #extendvg rootvg hdisk1

1-2.           すべてのrootvg用論理ボリュームにミラーを追加します。2つの方法があります。mirrorvgコマンドを使用する方法と、mklvcopyコマンドを使用する方法です。一般的にはmirrorvgコマンドを使用します。mirrorvgコマンドに-sオプションをつける場合、作成した新しいコピーを同期化しません。逆に、mklvcopyコマンドにオプションをつけない場合、作成した新しいコピーを同期化しません。

 #mirrorvg -s rootvg
または
#mklvcopy hd1 2 hdisk1
#mklvcopy hd2 2 hdisk1
#mklvcopy hd3 2 hdisk1
#mklvcopy hd4 2 hdisk1
#mklvcopy hd5 2 hdisk1
#mklvcopy hd6 2 hdisk1
#mklvcopy hd8 2 hdisk1
#mklvcopy hd9var 2 hdisk1
#mklvcopy hd10opt 2 hdisk1
 ．．．（rootvg内のミラーリング対象のLVについて、それぞれmklvcopyコマンドを実行します）

1-3.           次に作成した新しいコピーを同期化します。

1-2で、mirrorvg コマンドに -s オプションを指定しなかった場合、新しいコピーの同期化は自動で実行されますので、この手順は不要です。

#syncvg -v rootvg

1-4.           hdisk0、hdisk1 いずれのディスクからもブートできるようにするために、bosbootを実行する必要があります。

#bosboot -ad hdisk0
#bosboot -ad hdisk1

1-5.           ブート・リストを更新します。1つのディスクに障害が発生した場合には、異なるディスクからブートできるようにします。

#bootlist -m normal hdisk0 hdisk1

1-6.           システムをリブートします。

#shutdown -Fr

1-7.           起動後、ブート・リストの先頭に記述されたディスクからブートした事を確認します。

#bootinfo -b

＜注＞1-2は、一般的にはmirrorvgコマンドを使用します。すでにミラーリングされたrootvgにLVを追加するとき、その追加されたLVをミラーリングするためにはmklvcopyが便利です。また、mklvcopyを独立して使用することにより、特定のLVのコピー数を指定することができます。例えば、hd1だけ2つのコピー、hd1以外のLVに1つのコピーを追加したい場合、mklvcopyを使用することにより作成できます。

2. rootvg以外のvgのミラーリング

1-1～1-3を実行します。

3. ディスク間での PP のマッピングを意識したミラーリング

2つの方法があります。1つはmirrorvg -mを使って、vgをミラーリングする方法です。
例えば、hdisk1<->hdisk0 でマッピングさせるため、

 #extendvg datavg hdisk1
 #mirrorvg -m datavg hdisk1

のように指定します。

もう1つは、マップファイルにより明示的に使用する PP を指定してミラーリングする方法です。

a．LVマップの確認

 #lslv -m LV名　または、　#lspv -p hdiskX でLVのマップ、空き領域を確認

b．マップファイルの作成

 #vi /mapfile
 PVName: PPnum1[-PPnum2]

c．マップファイルを使用してミラーリング

 #mklvcopy -m /mapfile LV名　コピー数　PVName

d．ミラーの同期

 #syncvg -v XXvg

e．ミラーリング後、LVマップの再確認

hdisk1-hdisk5 にまたがるLV (lv01)を hdisk6-hdisk10 にミラーリングする場合

a． #lslv -m lv01

  lv01:N/A
LP    PP1  PV1          PP2  PV2               PP3  PV3
0001  0001 hdisk1
0002  0002 hdisk1
0003  0003 hdisk1
0004  0001 hdisk2
0005  0002 hdisk2
0006  0001 hdisk3
0007  0002 hdisk3
0008  0003 hdisk3
0009  0001 hdisk4
0010  0002 hdisk4
0011  0001 hdisk5
0012  0002 hdisk5

 b．#vi /mapfile

 hdisk6:1-3
 hdisk7:1-2
 hdisk8:1-3
 hdisk9:1-2
 hdisk10:1-2 

c．#mklvcopy　-m　/mapfile　lv01 2 hdisk6 hdisk7 hdisk8 hdisk9 hdisk10

d．#syncvg -v datavg

e．#lslv -m lv01
lv01:N/A 
LP    PP1  PV1         PP2  PV2               PP3  PV3
0001  0001 hdisk1    0001 hdisk6
0002  0002 hdisk1    0002 hdisk6
0003  0003 hdisk1    0003 hdisk6
0004  0001 hdisk2    0001 hdisk7
0005  0002 hdisk2    0002 hdisk7
0006  0001 hdisk3    0001 hdisk8
0007  0002 hdisk3    0002 hdisk8
0008  0003 hdisk3    0003 hdisk8
0009  0001 hdisk4    0001 hdisk9
0010  0002 hdisk4    0002 hdisk9
0011  0001 hdisk5    0001 hdisk10
0012  0002 hdisk5    0002 hdisk10

Hot questions:

Q. マッピングを意識せずに、LV 追加、ミラーリングをしてしまったため、ディスク間での PP のマッピングがずれてしまいました。直し方を教えてください。
 A. ミラーリングを再作成する必要があります。すなわち、一度、ミラーリングを解除してから、mirrorvg -m もしくは mklvcopy -m <mapfile> で再ミラーしてください。

Q．ミラーリングされたディスクを交換する場合は、どうしますか？
A．一旦ミラーリングを解除してから、ディスク交換を行います。ディスク交換後、もう一度ミラーリングを実行します。ディスク交換の詳細はディスク交換編をご参照ください。

 Q．extendvgを実行すると、「0516-792 extendvg: ボリューム・グループを拡張できませんでした。」のエラーが発生します。
 A．物理区画サイズを確認してください。

　　　https://www.ibm.com/docs/ja/aix/7.3?topic=s-syncvg-command

以上です。

ディスク交換

ディスクに障害が発生し、そのディスクを修復できないことが明らかな場合は、ディスクを交換しなければなりません。ミラーリングされたrootvgと、ミラーリングされていないrootvgの二つの状況に分けて、ディスク障害時の交換手順について、まとめました。

1. ミラーリングされたディスク(rootvg）

以下の作業手順は、rootvg が scsi0 に接続する hdisk0 と hdisk1 でミラーリングされており、hdisk0 が故障した場合の例です。*1
hdisk0 と hdisk1 はホットスワップ対応ディスクであり、rootvg の Quorum は hdisk0 故障前から オフにされていたことを前提としています。

1-1.           ダンプデバイスの確認

hdisk0 にダンプデバイスが存在するかどうかは、下記の方法で確認してください。
a.  ダンプデバイスの名前を確認します。
# sysdumpdev -l
b.  rootvg に sysdump タイプの LV があるか確認します。
# lsvg -l rootvg
c.  bで確認したダンプデバイスが hdisk0 に存在するか確認します。
# lspv -l hdisk0

1-2.           ダンプデバイスの変更／削除 *2

1-1で hdisk0 にダンプデバイスが存在し、ダンプデバイスとして指定している場合、そのダンプデバイスを sysdumpnull に切り替えます。
hdisk0 上のダンプデバイスを一次ダンプデバイスに設定していた場合
# sysdumpdev -Pp /dev/sysdumpnull
hdisk0 上のダンプデバイスを二次ダンプデバイスに設定していた場合
# sysdumpdev -Ps /dev/sysdumpnull
次に、hdisk0 に存在するすべての sysdump タイプの LV を削除してください。
必要に応じて、ディスク交換後、ダンプデバイスを再構築するための情報を取得しておいてください。
# rmlv ダンプデバイスLV名

1-3.           どちらのhdiskで起動したか、ブートディスクの確認　

# bootinfo -b

1-4.           ミラーリングの解除

# unmirrorvg rootvg hdisk0
unmirrorvg 実施後、ブート・レコードを削除するため、chpv -c hdisk0を実行してくださいというメッセージが表示されます。ここで chpv -c hdisk0を実行し、hdisk0に残されているブート・レコードを削除してください。
# chpv -c hdisk0　（場合によって、hdisk0 にアクセスできなくてエラーが表示される可能性があります。）

1-5.           ブート・イメージの初期化およびブートレコードの再作成            

# bosboot -ad /dev/hdisk1

1-6.           bootlist の変更            

# bootlist -m normal hdisk1

1-7.           rootvg からの障害ディスクの除去

# reducevg rootvg hdisk0

1-8.           /dev/ipldevice の再作成

ipldeviceを確認して、障害ディスク側にリンクがある場合はipldeviceを削除します。i-node番号が同じ場合はそのディスクにipldeviceがあります。
(ipldeviceと障害ディスクのinode番号が異なる場合、ipldeviceのrmによる削除ならびにlnによる再作成は必要ありません)
# ls -i /dev/rhdisk0 /dev/ipldevice
# rm /dev/ipldevice
ipldeviceを再作成します。(hdiskの前の"r"を忘れないようにしてください)
# ln /dev/rhdisk1 /dev/ipldevice

1-9.           ディスク交換 (diagのHot Plug Managerを用いた実施例 )

# diag
→Task Selection
→Hot Plug Task
→SCSI and SCSI RAID Hot Plug Manager
→Replace/Remove a Device Attached to an SCSI Hot Swap Enclosure Device
→hdisk0 を選択し、LED が点灯していることを確認
→ディスク交換して、 Enter キーを押し F10 で diag を終了
(HW構成やバージョン等によってdiagのメニューに違いがありますのでご注意ください)

1-10.       交換したディスクが使用可能な状態になっていることを確認

# lsdev -Cc disk

1-11.       交換したディスクをrootvgへ追加

# extendvg rootvg hdisk0

1-12.       ミラーリングの実施　(LVマッピングを作成し、同期なし or ありの mirrorvg コマンド実施例） 

同期なしmirrorvg の場合
# mirrorvg -s -m  rootvg hdisk0 
次に同期を行います。
# syncvg -v rootvg        (foreground同期) 
同期あり mirrorvg の場合
# mirrorvg -m rootvg hdisk0    (foreground同期)

1-13.       Quorum の確認

# lsvg rootvg で、Quorumがオフの状態となっていることを確認してください。
Quorum=1の場合、Quorumがオフの状態です。

1-14.       ブート・イメージの初期化およびブートレコードの再作成

# bosboot -a

1-15.       bootlist の変更

hdisk0、hdisk1にブート論理ボリューム(hd5)が存在することを確認した上でbootlistを変更します
# lslv -m hd5
# bootlist -m normal hdisk0 hdisk1

1-16.       全てのLV が syncd であり、かつ、sysdump タイプの LV を除くすべての LV のPP 数が LP 数の2倍であることを確認

# lsvg -l rootvg

1-17.       ダンプデバイスの再作成および設定 （1-2 でダンプデバイスを変更/削除した場合のみ） *2

ダンプデバイスを再作成してください。
# mklv -t sysdump ダンプデバイスLV名 rootvg PP数 hdisk0
ダンプデバイスを再設定してください。
作成したダンプデバイスを一次ダンプデバイスに設定する場合
# sysdumpdev -Pp /dev/ダンプデバイスLV名
作成したダンプデバイスを二次ダンプデバイスに設定する場合
# sysdumpdev -Ps /dev/ダンプデバイスLV名

1-18.       ipldeviceの確認

ipldeviceのi-node番号が両エントリーとも同じであることを確認します。
# ls -i /dev/rhdisk1 /dev/ipldevice

  *1 障害hdisk、および障害hdiskが接続されているscsiデバイスは、次の方法で特定できます。

例） 障害ディスクの判別：    

errpt に出力されている hdisk、lsvg -p rootvg コマンドで"missing"になっている hdisk

障害ディスクが接続されている scsi デバイスの特定：    

lsdev コマンドを利用して、hdisk のロケーションコードと同一の同じものを特定

*2 /dev/sysdumpnull を一次ダンプデバイスに設定すると、二次ダンプデバイスにダンプデバイスが指定されていても、再起動する、再度一次ダンプデバイスにダンプデバイスを設定する、またはダンプデバイス設定を変更するまで、二次ダンプデバイスは機能しない可能性があります。（つまり、ダンプが取得できません）
もし、ディスク交換作業中の確実なダンプ取得を考慮する場合、一次ダンプデバイスには、二次ダンプデバイスで使用しているダンプデバイスなどを設定する方法などが考えられます。この場合、二次ダンプデバイスは一時的に /dev/sysdumpnull を設定してから実施してください。

2. ミラーリングされていない rootvg 内のディスクが故障した場合、mksysb からのリストアが必要です。

2-1.           不良ディスクを交換

2-2.           保守モードでブート

2-3.           mksysbテープから復元

2-4.           mksysbの作成時に、rootvgにマウントされていないファイル・システムがあった場合は、それらのファイル・システムは別個の手順で作成し、リストアする必要があります。使用するmksysbテープがユーザー・ボリューム・グループの定義を含んでいない場合には、mksysbをリストアしてから、ユーザー・ボリューム・グループをインポートする必要があります。

# importvg -y datavg hdisk1

 Hot questions:

Q. HDD交換後、extendvgができないのですが、どうすれば修復できますか？
A. VGDAの情報を使ってODMを再構成してみてください。

#synclvodm -Pv rootvg

なお、rootvg以外のディスクの交換の際は、以下参考文献の「replacepv コマンドを使用した障害のある PV の交換」を参照してください。

 参照文献 

ミラーリングされたボリューム・グループ内の障害のある物理ボリュームの交換
https://www.ibm.com/docs/ja/aix/7.2?topic=clvm-replacing-failed-physical-volume-in-mirrored-volume-group

Steps of replacing an AIX® disk with another new disk in VG
https://www.ibm.com/support/pages/node/6333595

以上です。

VGの種類と制約

ボリューム・グループ（VG）の制約の比較と、AIX5.3から導入されているScalable VGの特徴とVGの機能追加による注意点について、まとめました。

1. AIX V5.3は、下記の3種類のボリューム・グループをサポートしています。

• ノーマル・ボリューム・グループ(Normal VG)：SMITまたはmkvgを使ってデフォルトで作成されるボリューム・グループです。
• ビッグ・ボリューム・グループ(Big VG)：AIX V4.3.2以降導入されました。SMITまたはmkvg -Bを使って作成します。
• スケーラブル・ボリューム・グループ(Scalable VG)：AIX V5.3以降導入されました。SMITまたはmkvg -Sを使って作成します。

それぞれのVGの制約を下の表にまとめました。

  *  64 ビット・カーネル上の 装置テーブルは、アクティブ・メジャー番号が最大で 1024 となるため、アクティブ・ボリューム・グループの数は、最大で 1024となります。

 ＜注＞Normal VGとBig VGについては、mkvg(chvg) -t コマンドを使って、1PVの最大PP数をこの表の値より大きくすることができます。ただし、1PVの最大PP数を増加させると、そのVG内の最大PV数が減少します。以下の表は、それぞれのVGについて、-t フラッグを変更した場合の1VGあたりの最大PV数と1PVあたりの最大PP数との関係を示します。

 2. AIX V5.3から導入されているScalable VGの特徴

2-1.           Normal VG、Big VG では、ディスクあたりの最大 PP 数の制限がありました。Scalable VG では、PP 数は、ディスクごとの制限ではなく、VG 全体での制限です。

2-2.           2-2. 従来の VG (Normal VG、Big VG) の PP サイズは、2のべき乗、かつ最小1MB、最大1024MB（1GB）の範囲で指定できました。Scalable VG のPPサイズも、2のべき乗である必要がありますが、最小は1MB、最大は131072MB(128GB)までに拡張されました。この新しい拡張は、最大256PBディスクに対する設計上のサポートを提供します。

2-3.           Scalable VGにおける1VGの最大LV数は4095まで拡張されました。

2-4.           注意点：Scalable VGの構成が大きくなるほど、パフォーマンスは落ちます。

·          MAX LVsまたはMAX PPｓ/VGが制限値に近づくと多くのメタデータの読み書きが発生するので、メタデータの操作のパフォーマンスが若干落ちます。多くのPVsで構成されているVGはそれぞれのPVがメタデータのコピーを保持するため、メタデータの操作のパフォーマンスが大きく落ちます。LVMのメタデーターの操作は、VG、LV、FSの追加/表示/変更/削除など、LVM関連コマンドを発行するとき発生します。

·          Scalable VG の最大 LV 数や最大 PP 数をデフォルト値より大きくすると、比例的に VGDA のサイズが増加します。一度増加させた最大 LV 数や最大 PP 数は減少させることはできないため、必要な分だけ増加させるべきです。VGDA 領域が増加するにしたがい、すべての VGDA 更新操作( LV作成、LV 変更、PV 追加、など) は、実行により時間がかかります。

 3. 従来のVG（Normal VG と Big VG）とScalable VGの互換性

chvgコマンドを使ってNormal VGとBig VGをScalable VGに変換することができます。

#chvg -G testvg

-G オプションを使用するとき、下記の条件を考慮してください。

a．Stale physical partitionsがないこと。

b．一旦Scalable VGに変換されたVGは、AIX5.2以前のバージョンにインポートさせることができなくなります。

c．VGはVaryoffモードでなければなりません。

 VGがVaryon状態のままでchvg -Gコマンドを実行すると下記のエラーが出力されます。

 # chvg -G testvg
 0516-1707 chvg: The volume group must be varied off during conversion to scalable volume group format.
 0516-732 chvg: Unable to change volume group testvg.

 d．Scalable VGのVGDA構造とVGSA構造が従来のVGと結構違い、必要なサイズも大きくなります。従来のVGをScalable VGに変更するとき、VGSAの展開にフリー・パーティションが必要です。
VGDAの展開の時、ディスクのエッジ(edge)部分にあるパーティションがVGDAに取られます。この部分にデータがあった場合は、そのデータは自動的にほかのパーティションに移動されます。このため、マッピング情報が自動的に変更されることがあります。

4. VGの機能追加による注意点

 前項のVGの種類の変更に加え、VGに新機能が追加されたり仕様変更があった場合に、それを有効にすることによりVGDAが拡張される場合等はそれ以前のバージョンのAIXにはインポートできなくなりますので注意が必要です。
以下にその例を記載します。

4-1.           Quorum設定の変更

AIX 5.2 TL10 、AIX 5.3 TL7、AIX 6.1 以降では、以下の仕様変更が行われました
１）Normal VGのVGDAの拡張
Normal VGのVGDAを拡張して、QuorumとAuto_ONの属性が入るように変更されました。
この変更により、Importvgの後に、設定変更が不要になりました。  

２）Quorumの反映の変更
従来Quorumの設定を変更した後、一度varyoffvgを行い、その後varyonvgを行う必要がありましたが、varyoffvg/varyonvgの設定は不要となりました。

4-2.           ミラー・プール

PVにミラー・プールを設定することにより、ミラーリングされたLVを作成する際にどのPVに作成するかの割り当てを簡素化することが可能になります。
ミラー・プールはAIX 6.1から追加された機能で、これを有効にするとそれ以前バージョンのAIXでは使用できなくなります。

4-3.           クリティカルVG

AIX 6.1 TL9 および AIX 7.1 TL3 以降で chvg コマンドにクリティカル・ボリューム・グループ（VG）を使用可能にするオプションが追加されました。クリティカルVGに設定することで、ディスク障害とボリューム・グループ障害からの保護が可能となります。
ただし、一度クリティカルVG を使用可能にすると、そのVGは AIX 6.1 TL9 未満および AIX 7.1 TL3 未満の環境にインポートできなくなります。移行検証などで事前にインポートするといった作業を行う際は注意してください。
詳細につきましては、参照文献のリンク先をご確認ください。

 Hot questions：

Q．AIX 5L V5.3で利用可能な１ディスクの最大サイズ、1システムがサポートするディスクの最大容量、ディスクの最大数を教えてください。
 A．64ビット・カーネルのシステムがサポートする1ディスクの最大サイズは２TB弱で、32ビット・カーネルのシステムがサポートする１ディスクの最大サイズは１TB弱です。
 設計上では、システムに接続できるディスクの合計ディスクの最大容量は510PB弱 ですが、VGの制限やODMの制限、Fibreの制限などにより、実際にアクセスできるディスクの最大数は約10000個ですので、実際にシステムに接続できるディスクの合計ディスクの最大容量は20PB弱（32ビット・カーネルは10PB弱）です。

Q.  Scalable VGをNormal VGやBig VGに変換することはできますか。
A.  いいえ、できません。再作成が必要となります。

参照文献

Changing the Volume Group Factor value and Factor calculation 
https://www.ibm.com/support/pages/node/6372976

AIX Volume Group limitations and types (Small, Big, Scalable and how to convert between them) 
https://www.ibm.com/support/pages/node/6372968

chvg コマンド
https://www.ibm.com/docs/ja/aix/7.2?topic=c-chvg-command

クォーラム (定足数)
https://www.ibm.com/docs/ja/aix/7.1?topic=concepts-quorum

ミラー・プール
https://www.ibm.com/docs/ja/aix/7.2?topic=concepts-mirror-pools

AIX 6.1 TL9, AIX 7.1 TL3におけるクリティカルVG機能追加のお知らせ
https://www.ibm.com/support/pages/node/3419781

クリティカル・ボリューム・グループの作成
https://www.ibm.com/docs/ja/powerha-aix/7.2?topic=groups-creating-critical-volume

以上です。

JFSとJFS2の比較

ファイル・システムの比較と、AIX5.3からサポートされる主な新機能－JFS2のファイル・システムの縮小、JFS2のQuotasについて、まとめました。

 1. JFSとJFS2の比較

 2. AIX V5.3からサポートされる新機能：JFS2のファイル・システムの縮小

2-1.           ファイル・システムの縮小がファイル・システムのマウント中に実行できるようになります。chfsコマンドまたはSMITから実施できます。

chfsの実行例：
# chfs -a size=-2324048 /jfs2
ファイル・システム・サイズが2031616 に変更されました

2-2.           新しいサイズは、すべての既存データと縮小のためのワークスペースが必要ですので、chfsコマンドまたはSMITからファイル・システムを縮小する前に、dfコマンドで現在のシステム上使用可能なスペースを確認しておいてください。

chfsの実行例：
# df /jfs2
Filesystem    512-blocks        Free  %Used  Iused %Iused  Mounted on
 /dev/jfs2     4325376       2324048     47%        4      1%  /jfs2
# chfs -a size=-2324048 /jfs2
 ファイル・システム・サイズが2031616 に変更されました
# df /jfs2
Filesystem    512-blocks        Free   %Used Iused %Iused  Mounted on
 /dev/jfs2      2031616         30648      99%       4      1%  /jfs2

＜注＞AIXでは、厳密にどれだけのサイズまで縮小できるかを表示するコマンドはありません。dfコマンドを使用しても、フラグメンテーションが予測できなかったりする問題がありますので、システムの最小サイズを予測することができません。また、縮小は PP サイズで行われます。上の例では、 2324048 ブロックを縮小しましたが、実際には 2293760 ブロック分縮小されています。chfs -aに実際に縮小できる限度以上の数字を指定すると、エラーが戻ってきます。
＜注＞dfコマンドに指定するブロックサイズ と chfs -a コマンドに指定するブロック・サイズ を統一してください。デフォルトでは、２つのコマンドとも512バイトブロック単位ですが、変更することができます。例えば、dfコマンドに-k、-m、-gオプションをつけることにより、KB、MB、GB単位で表示することができます。また、chfs -a コマンドでも、M-suffix やG-suffix を利用できます。

2-3.           縮小後のファイル・システムは最小限１PPサイズでなければなりません。chfs -aの設定値が１PPサイズより小さい場合、コマンドが無効になります。また、設定値がPP単位ではない場合、PPサイズまで大きめに丸めます。

2-4.           インラインログも、ファイル・システムの縮小・拡張に従い、動的に縮小・拡張することができます。ただし、インラインログのサイズはファイル・システム・サイズの0.4%～10%の範囲である必要があります。

 3.AIX V5.3からサポートされる新機能：JFS2のQuotas

3-1.           ファイル・システム単位でユーザー、グループに、使用量とファイル数のソフト制限とハード制限をつけることができます。ソフト制限を超える場合、ユーザーのところに警告メッセージ（warning message）が出されますが、指定した猶予期間の間はファイル・システムが続けて利用できます。しかし、一定の期間が経ってから、制限オーバーの問題が解消されない場合には、それ以上のファイルの作成もしくは容量の利用はできなくなります。

3-2.           JFSと異なる新しいクォータ・ファイルフォーマットを利用します。新クオータ・ファイルフォーマットは「UNIX System Manager's Manual (4.3 Berkeley Software Distribution)：Disk Quotas in a UNIX Environment」をベースに、任意のユーザー、グループに設定可能です。

3-3.           容易な管理のためにlimits classの概念が導入されました。各ユーザーは、その所属するlimits classに設定されたクォータにより、それぞれファイル・システムの利用が制限されます。クォータはlimits class単位で変更することができます。

3-4.           クォータはj2edlimit コマンド またはSMITで管理します。

4. JFSとJFS2の利用環境

JFSでもJFS2でも、32bitカーネル環境と64bitカーネル環境両方で使えます。ただし、32bitカーネル環境ではJFSを、64bitカーネル環境ではJFS2をお勧めします。
JFS2 は本来64bitカーネルを基に設計されており、最適な64bitカーネル環境でその効果を発揮するので、64bitカーネル環境ではJFS2を使用することを推奨しております。

5. JFSからJFS2への移行

JFSファイル・システムをJFS2に変換したい場合の対応方法です。

a．JFSのバックアップを取得してから、ファイル・システムを削除します。次に、JFS2を構成し、バックアップしたファイルをリストアします。

b．ディスクスペースに余裕がある場合、JFSのバックアップを取らず、JFS2を構成した後、JFSのファイルをJFS2ファイル・システムに直接にコピーします。

※既存のJFSファイル・システムを直接JFS2に変換することはできません。

 参照文献

「AIX5L Differences Guide Version 5.1 Edition」(3.4.2 Compatibility)にて、JFSからJFS2への移行に関する記述がありますのでご参照下さい。
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245765.pdf

インフォメーション・センターのFAQ->ファイル・システム
http://publib16.boulder.ibm.com/pseries/Ja_JP/infocenter/base/faq.htm#kernel

AIXオペレーティングシステムの概念と上級システム管理　株式会社アスキー　古寺雅弘編著

以上です。

FSの管理制約

 ファイル・システムの管理制約、たとえば、ファイル・システムに作成できるファイルの最大数、JFS2でインライン・ログを使用する場合のサイズ、NBPI、AG(Allocation Group) の概念と相互関係について、まとめました。

1. ファイル・システムに作成できるファイルの最大数

ファイル個数上限は1 ファイル・システムのinode個数上限に制約されます。
inode個数の上限を超えてファイルを作成することはできませんので、この上限にも制約されます。inode個数は、JFSの場合にはファイル・システム・サイズ等に依存し、ファイル・システム作成時に一定個数が割り当てられます。JFS2の場合にはinodeは動的に割り当てられます。

2. JFS2でインライン・ログを使用する場合のサイズ

AIX5.1以降では、インライン・ログのサイズを自由に変更することができます。ただし、最小はLVサイズの0.4%で、最大はLVサイズの10%です。デフォルト値はLVサイズの0.4%でした。
AIX5.2からは、インライン・ログのサイズはAIX5.1と同じように、0.4%～10%の間で変更することができますが、インライン・ログのサイズのデフォルトサイズは下の表のようになります。

      * 上記数値は IBM Information Center home FAQs に依ります。
   http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/faq.htm#jfs2

3. NBPI、AG(Allocation Group) の概念と相互関係

NBPIは、1つのiノード当たりのバイト数です。NBPIにより、JFSではファイル作成時に1つのiノード当たりのバイト数を指定することで、ファイル・システム当たりのiノードの数（作成可能なファイル数）を設定することができます。例えば、NBPI値を1024にすると、iノードは、ファイル・システムのディスク・スペースの1024バイトごとに作成されます。すなわち、一定のファイル・システム・サイズにおいて、NBPI値を小さくすると、作成されるiノードの数は多くなります。逆に、NBPI値を大きくすると、iノードの数は少なくなります。デフォルトでは、NBPI＝4096バイトです。
AG（アロケーショングループ）は、ファイル・システムへのアクセス効率を向上させるために、AIX V4.2以降で追加となった機能です。ファイル・システム作成時にアロケーショングループ・サイズを指定することにより、指定されたサイズごと（8、16、32、64Mバイト）にファイル・システムが論理的にグループ化されます。グループ化されたAGには、データブロックとiノードがそれぞれ構成されます（従来はiノードが論理ディスクの先頭に近い位置に一括して割り振られていました）。
設定可能なNBPI値とAGサイズとの間には、以下の表に示した依存関係があります。

 4. NBPI 値を小さくする時の考慮点とAG値を設定する時の考慮点

NBPI をデフォルトの 4096 バイトより小さくする必要があるのは、フラグメントを使用している場合です。
NBPI値を小さくした場合は、iノードの数が増えることにより、iノード割り当て用に確保される領域の割合が多く必要となるため、データブロックとして使用できる領域が少なくなることに注意してください。NBPI値は事前に想定されるファイルの数とそのサイズの見積に応じて決定する必要があります。
NBPIを小さくするとファイル・システムの最大サイズも小さくなる可能性があります。JFSの実際の最大サイズは、ファイル・システムの作成時に決定され、（フラグメント・サイズ x 2^28）と（NBPI x 2^24）とのうち、いずれか小さい方になります。そのため、NBPIを小さくすると、作成可能なファイル・システムの最大サイズも小さくなることがあります。
ファイル・システム作成時にAGサイズを指定することができます。原則的にファイルのデータブロックとiノード、またファイルの属するディレクトリーは同一のアロケーショングループに存在するため、AGサイズを小さくすると、ファイルの作成・更新時に物理的なディスクヘッドのシーク時間が減少することによりパフォーマンスが向上します。

5. ファイル・システム作成後、NBPI や AG サイズは変更できますか？

JFSではNBPIを動的に変更できないため、変更する場合はファイル・システムを再作成する必要があります。
AGもNBPIと同様に、動的に変更することができません。

参照文献

AIXオペレーティングシステムの概念と上級システム管理　株式会社アスキー　古寺雅弘編著

以上です。

その他、LVM関連についての情報を以下に記載します。

論理ボリューム・マネージャー（LVM）
https://www.ibm.com/support/pages/node/1137316

AIX Logical Volume Manager from A to Z: Introduction and Concepts
https://www.redbooks.ibm.com/abstracts/sg245432.html?Open