| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 10 から Oracle Solaris 11 への移行 Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 10 から Oracle Solaris 11 への移行 Oracle Solaris 11 Information Library (日本語) |
1. Oracle Solaris 10 から Oracle Solaris 11 への移行 (概要)
2. Oracle Solaris 11 インストール方法への移行
Oracle Solaris 11 ファイルシステムの変更点
ZFS ファイルシステムへの UFS データの移行 (ufsdump および ufsrestore)
10. 仮想環境での Oracle Solaris リリースの管理
次の ZFS ファイルシステムの機能は、Oracle Solaris 10 リリースでは利用できませんが、Oracle Solaris 11 では利用できます。
ZFS ファイルシステムの暗号化 - ZFS ファイルシステムを作成時に暗号化できます。詳細は、第 9 章セキュリティーの管理を参照してください。
ZFS ファイルシステムの複製解除 - システム環境が ZFS データの複製解除をサポートできるかどうかを判断するための重要な情報については、「ZFS データの複製解除の要件」を参照してください。
ZFS ファイルシステムの共有 - NFS および SMB ファイルシステムの共有への変更が含まれています。詳細は、「ZFS ファイルシステムの共有の変更点」を参照してください。
ZFS のマニュアルページの変更 – zfs.1m のマニュアルページは、主要な ZFS ファイルシステムの機能が zfs.1m ページに残るように改訂されていますが、委任管理、暗号化、および共有の構文と例については次のページに記載されています。
システムのインストール後、ZFS ストレージプールおよび ZFS ファイルシステムの情報を確認します。
zpool status コマンドを使用して、ZFS ストレージプールの情報を表示します。例:
# zpool status
pool: rpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c2t0d0s0 ONLINE 0 0 0
errors: No known data errors
zfs list コマンドを使用して、ZFS ファイルシステムの情報を表示します。例:
# zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT NAME USED AVAIL REFER MOUNTPOINT rpool 5.39G 67.5G 74.5K /rpool rpool/ROOT 3.35G 67.5G 31K legacy rpool/ROOT/solaris 3.35G 67.5G 3.06G / rpool/ROOT/solaris/var 283M 67.5G 214M /var rpool/dump 1.01G 67.5G 1000M - rpool/export 97.5K 67.5G 32K /rpool/export rpool/export/home 65.5K 67.5G 32K /rpool/export/home rpool/export/home/admin 33.5K 67.5G 33.5K /rpool/export/home/admin rpool/swap 1.03G 67.5G 1.00G -
ルートプールコンポーネントの詳細は、「インストール後の最初の ZFS BE の確認」を参照してください。
利用可能なプールおよびファイルシステムの領域を判別する場合、zpool list および zfs list コマンドは、以前の df および du コマンドより優れています。旧バージョンのコマンドでは、プールおよびファイルシステムの領域を簡単に識別できず、下位のファイルシステムまたはスナップショットによって消費される領域の詳細を表示できません。
たとえば、次のルートプール (rpool) は、5.46GB が割り当て済みで、68.5GB は空き領域です。
# zpool list rpool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 74G 5.46G 68.5G 7% 1.00x ONLINE -
個別のファイルシステムの USED 列を確認することにより、プール領域の数値とファイルシステム領域の数値を比較すれば、プールの領域の詳細を確認できます。例:
# zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 5.41G 67.4G 74.5K /rpool rpool/ROOT 3.37G 67.4G 31K legacy rpool/ROOT/solaris 3.37G 67.4G 3.07G / rpool/ROOT/solaris/var 302M 67.4G 214M /var rpool/dump 1.01G 67.5G 1000M - rpool/export 97.5K 67.4G 32K /rpool/export rpool/export/home 65.5K 67.4G 32K /rpool/export/home rpool/export/home/admin 33.5K 67.4G 33.5K /rpool/export/home/admin rpool/swap 1.03G 67.5G 1.00G -
zpool list コマンドによって報告される SIZE 値は、通常、プール内の物理ディスク領域の大きさですが、プールの冗長性レベルに応じて異なります。次の例を参照してください。zfs list コマンドは、使用可能な領域のうち、ファイルシステムで利用できる領域を示します。これは、ディスク領域から ZFS プール冗長性メタデータオーバーヘッド (ある場合) を差し引いたものです。
非冗長性ストレージプール – 136GB のディスク 1 つで作成されています。zpool list コマンドは SIZE および初期 FREE 値を 136GB として報告します。zfs list コマンドによって報告される初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134GB です。例:
# zpool create tank c0t6d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
ミラー化されたストレージプール – 136GB のディスク 2 つで作成されています。zpool list コマンドは SIZE および初期 FREE 値を 136GB として報告します。この報告は、デフレートされた領域値と呼ばれます。zfs list コマンドによって報告される初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134GB です。例:
# zpool create tank mirror c0t6d0 c0t7d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
RAID-Z ストレージプール – 136GB のディスク 3 つで作成されています。zpool list コマンドは SIZE および初期 FREE 値を 408GB として報告します。この報告は、インフレートされたディスク領域値と呼ばれます。パリティー情報などの冗長性オーバーヘッドが含まれています。zfs list コマンドによって報告される初期 AVAIL 領域は、プール冗長性オーバーヘッドのため 133GB です。次の例は RAIDZ-2 プールを作成しています。
# zpool create tank raidz2 c0t6d0 c0t7d0 c0t8d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 408G 286K 408G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 73.2K 133G 20.9K /tank
ZFS ファイルシステムを利用可能にする方法は、Oracle Solaris 10 リリースと次の点で似ています。
ZFS ファイルシステムは、作成時に自動的にマウントされ、システムのブート時に自動的に再マウントされます。
ZFS ファイルシステムに旧バージョンのマウントを作成する場合を除き、ZFS ファイルシステムをマウントするために /etc/vfstab ファイルを変更する必要はありません。旧バージョンのマウントを使用するよりも、ZFS ファイルシステムを自動マウントすることを推奨します。
ファイルシステムを共有するために、/etc/dfs/dfstab ファイルを変更する必要はありません。ZFS ファイルシステムの共有の詳細は、「ZFS ファイルシステムの共有の変更点」を参照してください。
UFS ルートと同様に、スワップデバイスは /etc/vfstab ファイルにエントリを持つ必要があります。
NFS 共有を使用することで、Oracle Solaris 10 および Oracle Solaris 11 システムの間でファイルシステムを共有できます。
NFS または SMB 共有を使用することで、Oracle Solaris 11 システム間でファイルシステムを共有できます。
ZFS ストレージプールは、Oracle Solaris 10 システムからエクスポートして、Oracle Solaris 11 システムにインポートできます。
Oracle Solaris 10 では、sharenfs または sharesmb プロパティーを設定して ZFS ファイルシステム共有を作成して公開したり、旧バージョンの share コマンドを使用したりできました。
この Solaris リリースでは、次のように ZFS ファイルシステムの共有を作成してからその共有を公開します。
zfs set share コマンドを使用することで、ZFS ファイルシステムの NFS または SMB 共有を作成します。例:
# zfs create rpool/fs1 # zfs set share=name=fs1,path=/rpool/fs1,prot=nfs rpool/fs1 name=fs1,path=/rpool/fs1,prot=nfs
sharenfs または sharesmb プロパティーを on に設定することで、NFS または SMB 共有を公開します。 例:
# zfs set sharenfs=on rpool/fs1 # cat /etc/dfs/sharetab /rpool/fs1 fs1 nfs sec=sys,rw
新しい共有の主要な相違点は次のとおりです。
ZFS ファイルシステムを共有するための sharemgr インタフェースが zfs set share コマンドに置き換わります。
sharemgr インタフェースは使用できなくなりました。旧バージョンの share コマンドおよび sharenfs プロパティーは引き続き使用できます。次の例を参照してください。
/etc/dfs/dfstab ファイルは引き続き存在しますが、変更は無視されます。SMF が ZFS または UFS の共有情報を管理するので、システムのリブート時にファイルシステムが自動的に共有されます。ZFS のマウントおよび共有情報が管理される方法と似ています。
share -a コマンドを使用して共有されるファイルシステムの共有は永続的です。
子孫のファイルシステムは、共有プロパティーを継承しません。オンに設定された sharenfs プロパティーを継承して子孫のファイルシステムが作成された場合は、新しい子孫のファイルシステムに共有が作成されます。
旧バージョンの共有の構文は引き続きサポートされます。/etc/dfs/dfstab ファイルを変更する必要はありません。旧バージョンの共有は SMF サービスによって管理されます。
share コマンドを使用してファイルシステムを共有します。
たとえば、ZFS ファイルシステムを共有するには、次のように行います。
# share -F nfs /tank/zfsfs # cat /etc/dfs/sharetab /tank/zfsfs - nfs rw
上の構文は UFS ファイルシステムの共有と同じです。
# share -F nfs /ufsfs # cat /etc/dfs/sharetab /ufsfs - nfs rw /tank/zfsfs - nfs rw
以前のリリースと同様に、sharenfs プロパティーを有効にしたファイルシステムを作成できます。Oracle Solaris 11 の動作では、ファイルシステムにデフォルトの共有が作成されます。
# zfs create -o sharenfs=on rpool/data # cat /etc/dfs/sharetab /rpool/data rpool_data nfs sec=sys,rw
上記のファイルシステムの共有は、すぐに公開されます。
このセクションで、共有の移行の問題を確認してください。
システムのアップグレード - このリリースでのプロパティーの変更により、古い BE でブートすると、ZFS 共有が不正になります。ZFS 以外の共有は影響を受けません。古い BE でブートすることを計画している場合は、ZFS データセットに共有構成を復元できるように、pkg update 操作の前に、既存の共有構成のコピーを保存します。
古い BE で、sharemgr show -vp コマンドを使用して、すべての共有およびそれらの構成を一覧表示します。
zfs get sharenfs filesystem コマンドおよび zfs sharesmb filesystem コマンドを使用して、共有プロパティーの値を取得します。
古い BE でブートする場合は、sharenfs および sharesmb プロパティーを元の値にリセットします。
旧バージョンの共有解除動作 - unshare -a コマンドまたは unshareall コマンドを使用すると、共有が解除されますが、SMF 共有リポジトリは更新されません。既存の共有を再度共有しようとすると、共有リポジトリで競合がチェックされ、エラーが表示されます。
Oracle Solaris 11 では、複製解除 (dedup) プロパティーを使用して、ZFS ファイルシステムから冗長なデータを削除できます。ファイルシステムで dedup プロパティーが有効になっている場合、重複データブロックが同期的に削除されます。この結果、一意のデータだけが格納され、共通のコンポーネントがファイル間で共有されます。例:
# zfs set dedup=on tank/home
次の手順を実行してシステムがデータの複製解除をサポートできるかどうかを判断するまでは、本稼働システムに常駐するファイルシステムで dedup プロパティーを有効にしないでください。
複製解除による領域の節約がデータに有益であるかどうかを判断します。データを複製解除できない場合、dedup を有効にしても無駄です。次のコマンドを実行すると、非常に大量のメモリーが使用されます。
# zdb -S tank
Simulated DDT histogram:
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 2.27M 239G 188G 194G 2.27M 239G 188G 194G
2 327K 34.3G 27.8G 28.1G 698K 73.3G 59.2G 59.9G
4 30.1K 2.91G 2.10G 2.11G 152K 14.9G 10.6G 10.6G
8 7.73K 691M 529M 529M 74.5K 6.25G 4.79G 4.80G
16 673 43.7M 25.8M 25.9M 13.1K 822M 492M 494M
32 197 12.3M 7.02M 7.03M 7.66K 480M 269M 270M
64 47 1.27M 626K 626K 3.86K 103M 51.2M 51.2M
128 22 908K 250K 251K 3.71K 150M 40.3M 40.3M
256 7 302K 48K 53.7K 2.27K 88.6M 17.3M 19.5M
512 4 131K 7.50K 7.75K 2.74K 102M 5.62M 5.79M
2K 1 2K 2K 2K 3.23K 6.47M 6.47M 6.47M
8K 1 128K 5K 5K 13.9K 1.74G 69.5M 69.5M
Total 2.63M 277G 218G 225G 3.22M 337G 263G 270G
dedup = 1.20, compress = 1.28, copies = 1.03, dedup * compress / copies = 1.50
推定される dedup 比率が 2 より大きい場合は、dedup によって領域が節約される可能性があります。
この例では、dedup 比率 (dedup = 1.20) は 2 より小さいため、dedup の有効化は推奨されません。
システムに dedup をサポートするための十分なメモリーがあることを確認してください。
コア内の各 dedup テーブルエントリは、およそ 320 バイトです。
割り当てられているブロック数に 320 を掛けます。例:
in-core DDT size = 2.63M x 320 = 841.60M
dedup のパフォーマンスは、複製解除テーブルがメモリーに入る場合に最適になります。dedup テーブルをディスクに書き込む必要がある場合は、パフォーマンスが低下します。十分なメモリーリソースがない状態でファイルシステムに対する複製解除を有効にすると、ファイルシステム関連の操作時にシステム性能が低下する可能性があります。たとえば、十分なメモリーリソースがない状態で、dedup が有効になっている大容量のファイルシステムを削除すると、システム性能に影響が出る可能性があります。
|