パート II ZFS、ブート、Solaris ゾーン、および RAID-1 ボリュームに関連するインストールについて

このパートでは、Solaris OS のインストールとアップグレードに関連するいくつかの技術の概要を説明します。ガイドラインおよび要件についても解説します。

• ZFS ルート (/) ファイルシステムのインストール

• x86 または SPARC ベースのシステムでのブート

• Solaris ゾーン区分技術

• Solaris ボリュームマネージャーの構成要素 (RAID-1 など)

第 6 章 ZFS ルートファイルシステムのインストール (計画)

この章では、ZFS ルートプールをインストールする場合のシステム要件と制限事項について説明します。ZFS ルートプールをインストールするインストールプログラムの概要についても説明します。

• 「ZFS ルートプールのインストールの要件」

• 「ZFS ルートプールをインストールする Solaris インストールプログラム」

システム上に複数のブート環境がある場合のブートについては、第 7 章SPARC および x86 ベースのブート (概要と計画)を参照してください。

Solaris 10 10/09 リリースの新機能

Solaris 10 10/09 リリース以降では、JumpStart プロファイルを設定して、ZFS ルートプールのフラッシュアーカイブを特定できます。

フラッシュアーカイブは、UFS ルートファイルシステムまたは ZFS ルートファイルシステムを実行しているシステムで作成できます。ZFS ルートプールのフラッシュアーカイブには、スワップボリュームとダンプボリュームおよび任意の除外されたデータセットを除く、プール階層全体が含まれます。スワップボリュームとダンプボリュームは、フラッシュアーカイブのインストール時に作成されます。

フラッシュアーカイブによるインストール方法は次のとおりです。

• ZFS ルートファイルシステムによるシステムのインストールとブートに使用できるフラッシュアーカイブを生成します。

• ZFS フラッシュアーカイブを使用して、システムの JumpStart インストールを実行します。

  ---

  注 –

  ZFS フラッシュアーカイブを作成すると、個別のブート環境ではなく、ルートプール全体がバックアップされます。flarcreate コマンドと flar コマンドの - D オプションを使用すると、プール内の個別のデータセットを除外できます。

  ---

詳細と制限事項については、『Oracle Solaris ZFS 管理ガイド』の「ZFS ルートファイルシステムのインストール (Oracle Solaris フラッシュアーカイブインストール)」を参照してください。

ZFS ルートプールのインストールの要件

ZFS インストールのディスク容量要件

通常、UFS ルートファイルシステムのシステムでは、スワップとダンプが同じスライス上にあります。そのため、UFS はダンプデバイスとスワップ空間を共有します。ZFS ルートプールでは、スワップとダンプは別々の zvols となるので、同じ物理空間が共有されることはありません。システムが ZFS ルートファイルシステムを使ってインストールまたはアップグレードされている場合、スワップ領域とダンプデバイスのサイズは、物理メモリーの容量に依存します。ブート可能な ZFS ルートファイルシステムに使用されるプール領域の最小ディスク容量は、物理メモリー容量、使用可能ディスク領域、作成するブート環境の数によって異なります。メモリーは約 1G バイト、ディスク容量は 2G バイト以上を推奨します。容量は次のように消費されます。

• スワップ領域とダンプデバイス - スワップのデフォルトサイズは物理メモリーサイズの 1/2 ですが、512M バイトから 2G バイトまでの範囲を外れることはありません。ダンプデバイスは、メモリーサイズと dumpadm.conf ファイルの内容に基づいて計算されます。このファイルでは、クラッシュダンプに何を含めるかを定義します。スワップボリュームとデバイスボリュームのサイズは、インストール前またはインストール後に調整することができます。詳細については、『Oracle Solaris ZFS 管理ガイド』の「ZFS のプロパティーの紹介」を参照してください。

• ブート環境 - 新規のスワップとダンプデバイスの要件、調整されたスワップとダンプデバイスのサイズのいずれかに加えて、UFS ブート環境から移行した ZFS ブート環境に約 6G バイト必要です。別の ZFS ブート環境からの各クローン ZFS ブート環境には、追加のディスク容量は必要ありません。ただし、パッチを適用したためにブート環境のサイズが増加する可能性はあります。同じルートプール内のすべての ZFS ブート環境で、同じスワップとダンプデバイスが使用されます。

ZFS ルートプールをインストールする Solaris インストールプログラム

ZFS ルートプールの初期インストールを実行するインストールプログラムは、次のとおりです。

• Solaris インストールプログラムテキストインストーラ

• インストールプロファイルを使用するカスタム JumpStart

Solaris Live Upgrade で UFS ファイルシステムを ZFS ルートプールに移行することができます。Solaris Live Upgrade で、アップグレード可能な ZFS ブート環境を作成することもできます。

第 7 章 SPARC および x86 ベースのブート (概要と計画)

Solaris 10 10/08 以降のリリースでは、Solaris ブートアーキテクチャーが変更され、ZFS ファイルシステムなどさまざまな種類のファイルシステムからのブートを含む、多数の新機能が提供されています。この章では、これらの変更について説明し、ブートに関する詳細な情報のリファレンスを提供します。また、x86 システムの GRUB ベースのブートの概要を説明します。

この章の内容は次のとおりです。

• 「Solaris のブート (概要)」

• 「x86: GRUB ベースのブート (概要)」

• 「x86: GRUB ベースのブート (計画)」

Solaris のブート (概要)

Solaris 10 10/08 以降のリリースでは、Solaris SPARC ブートストラップ処理の設計が見直され、Solaris x86 ブートアーキテクチャーとの共通部分が増えて SPARCシステム上での ITU (install time update) が可能になりました。改善された Solaris ブートアーキテクチャーにより、直接ブート、RAM ディスクベースのブート、および RAM ディスクミニルートが SPARC プラットフォーム上で可能になります。これらを可能にする技術によって、次の機能がサポートされます。

• システムを ZFS ファイルシステムなどの追加されたファイルシステムからブートする。

• ソフトウェアインストール用の単一のミニルートを DVD、NFS、または HTTP からブートする。

その他の改善点としては、ブート時間の大幅な短縮、柔軟性の向上、保守の必要性の低下などが挙げられます。

このアーキテクチャーの再設計の一環として、これまで Solaris x86 プラットフォームでしか使用できなかった Solaris ブートアーカイブと bootadm コマンドが、Solaris SPARC ブートアーキテクチャーの一部として完全に組み込まれました。

Solaris SPARC ブートの実装は変更されましたが、SPARC システムをブートするための管理手順に変更はありません。Solaris のインストールに ZFS ファイルシステムからのインストールが追加されましたが、それ以外に新しいブートアーキテクチャーによる変更はありません。

ZFS ブート環境のブート (概要)

複数の OS がインストールされている、または ZFS ルートプールに複数のルートブート環境を持つシステムの場合、これらのブート環境から SPARC プラットフォーム用と x86 プラットフォーム用の両方のブートが可能です。ブート可能なブート環境には、Solaris Live Upgrade で作成されたブート環境も含まれます。

• Solaris 10 10/08 以降のリリースでは、SPARC システムで ZFS プール内の ZFS ルートファイルシステムをブートできるようになりました。ZFS ルートプールの場合は、boot コマンドに -L オプションを指定して、利用できるブート環境の一覧を表示できます。そこからブート環境を選択し、OBP boot コマンドに -Z オプションを指定して実行すれば、そのブート環境をブートできます。-Z オプションは、ZFS ルートプールの新規ブート環境のブートにも使用される luactivate コマンドの代替です。luactivate コマンドは、主にブート環境の切り替えに使用します。UFS ファイルシステムでは、主な管理インタフェースとして引き続き、OpenBoot PROM OBP を使用します。指定するブートオプションは、OBP のコマンドを使用して選択します。

• Solaris 10 1/06 以降のリリースでは、x86 システムの GRUB ブートメニューに、さまざまなブート環境からブートできるインタフェースが備えられました。Solaris 10 10/08 以降のリリースでは、ブートに利用できる ZFS ブート環境の一覧がこのメニューに表示されます。デフォルトのブート環境が ZFS ファイルシステムで GRUB メニューが表示されている場合、そのままデフォルトのブート環境をブートすることも、他のブート環境を選択してブートすることもできます。GRUB メニューは、ZFS ルートプールの新規ブート環境のブートにも使用する luactivate コマンドの代替です。luactivate コマンドは、主にブート環境の切り替えに使用します。

SPARC および x86 ベースのシステムの両方で、ZFS ルートプールごとに 1 つのデータセットがデフォルトのルートファイルシステムとして指定されます。SPARC の場合は boot コマンドを入力、x86 の場合は GRUB メニューのデフォルトを選択すると、このデフォルトのルートファイルシステムがブートされます。

x86: GRUB ベースのブート (概要)

オープンソースのブートローダー GRUB が、Solaris OS のデフォルトのブートローダーです。

ブートローダーは、システムの電源を入れたあと最初に実行されるソフトウェアプログラムです。x86 ベースのシステムの電源を入れると、BIOS (Basic Input/Output System) により、CPU、メモリー、およびプラットフォームハードウェアが初期化されます。初期化フェーズが完了すると、BIOS が構成済みブートデバイスからブートローダーをロードし、システムの制御をブートローダーに移します。

GRUB は、簡単なメニューインタフェースを備えたオープンソースのブートローダーで、メニューには構成ファイルに定義されたブートオプションが表示されます。また、GRUB はコマンド行インタフェースも備えており、メニューインタフェースからアクセスしてさまざまなブートコマンドを実行できます。Solaris OS では、GRUB 実装はマルチブート仕様に準拠しています。詳細な仕様については、http://www.gnu.org/software/grub/grub.html を参照してください。

Solaris カーネルはマルチブート仕様に完全に準拠しているため、GRUB を使用して Solaris x86 ベースのシステムをブートできます。GRUB を使用すると、さまざまなオペレーティングシステムのブートおよびインストールがより簡単にできます。

GRUB の主な利点は、ファイルシステムおよびカーネル実行可能ファイルの形式に対して直観的であるため、ディスク上のカーネルの物理的位置を記録せずにオペレーティングシステムをロードできることです。GRUB ベースのブートでは、カーネルのファイル名、ドライブ、およびカーネルがあるパーティションを指定することでカーネルがロードされます。GRUB ベースのブートは Solaris Device Configuration Assistant (デバイス構成用補助) を置き換え、GRUB メニューによってブート処理を簡略化します。

x86: GRUB ベースのブート (計画)

この節では、GRUB ベースのブートの基本と、GRUB メニューについて説明します。

Solaris OS のインストール時に、デフォルトで 2 つの GRUB メニューエントリがシステムにインストールされます。最初のエントリは Solaris OS エントリです。2 番目のエントリはフェイルセーフブートアーカイブで、システムの回復に使用されます。Solaris GRUB メニューエントリは、Solaris ソフトウェアのインストールおよびアップグレード処理の一環として自動的にインストールおよびアップグレードされます。これらのエントリは OS によって直接管理されるため、手動で編集しないでください。

Solaris OS の標準インストール中に、システム BIOS の設定を変更せずに GRUB が Solaris fdisk パーティションにインストールされます。この OS が BIOS ブートディスクにない場合は、次のいずれかの操作を行う必要があります。

• BIOS の設定を変更します。

• ブートマネージャーを使用して Solaris パーティションでブートストラップするようにします。詳細については、使用しているブートマネージャーの使用方法を参照してください。

ブートディスクに Solaris OS をインストールする方法をお勧めします。マシンに複数のオペレーティングシステムがインストールされている場合は、エントリを menu.lst ファイルに追加できます。これらのエントリは、システムを次にブートしたときに GRUB メニューに表示されます。

複数のオペレーティングシステムの詳細については、『Solaris のシステム管理 (基本編)』の「GRUB で複数のオペレーティングシステムをサポートする方法」を参照してください。

x86: ネットワークからの GRUB ベースのインストールの実行

GRUB ベースのネットワークブートを実行するには、PXE クライアント用に構成された DHCP サーバーと、tftp サービスを提供するインストールサーバーが必要です。DHCP サーバーには、DHCP クラスである PXEClient と GRUBClient に応答する機能が必要です。DHCP 応答には、次の情報が含まれている必要があります。

• ファイルサーバーの IP アドレス

• ブートファイルの名前 (pxegrub)

rpc.bootparamd は、通常、ネットワークブートを実行する場合にサーバー側で必要とされるファイルですが、GRUB ベースのネットワークブートでは不要です。

PXE も DHCP サーバーも使用できない場合は、CD-ROM またはローカルディスクから GRUB をロードできます。次に GRUB でネットワークを手動で構成し、ファイルサーバーからマルチブートプログラムとブートアーカイブをダウンロードできます。

詳細は、『Oracle Solaris 10 9/10 インストールガイド (ネットワークインストール)』の「PXE を使用したネットワーク経由のブートとインストールの概要」を参照してください。

第 8 章 システムに Solaris ゾーンがインストールされている場合のアップグレード (計画)

この章では、非大域ゾーンが構成されている場合の、Solaris ゾーン区分技術と Solaris OS のアップグレードとの関係の概要を説明します。

この章の内容は次のとおりです。

• 「Solaris ゾーン (概要)」

• 「非大域ゾーンを含むアップグレード」

• 「非大域ゾーンのディスク容量要件」

Solaris ゾーン (概要)

Solaris ゾーン区分技術は、オペレーティングシステムサービスを仮想化し、安全で隔離されたアプリケーション実行環境を提供します。非大域ゾーンは、Solaris OS の 1 つのインスタンス内で作成される、仮想化されたオペレーティングシステム環境です。非大域ゾーンを作成すると、アプリケーション実行環境が生成されます。このアプリケーション実行環境内のプロセスは、システムのほかの部分から隔離されます。このように隔離されているので、ある非大域ゾーンで実行中のプロセスが、ほか の非大域ゾーンで実行中のプロセスから監視または操作されることがありません。スーパーユーザー資格で実行されているプロセスであっても、ほかのゾーンの活動を監視したり操作したりすることはできません。また、非大域ゾーンにより、アプリケーションを配備するマシンの物理的属性からアプリケーションを分離する抽象層も提供されます。このような属性の例として、物理デバイスパスがあります。

各 Solaris システムには大域ゾーンが 1 つ含まれています。大域ゾーンは 2 つの機能を持っています。大域ゾーンは、システムのデフォルトのゾーンであり、システム全体の管理に使用されるゾーンでもあります。大域管理者が非大域ゾーンを作成した場合を除き、すべてのプロセスが大域ゾーンで実行されます。非大域ゾーンの構成、インストール、管理、およびアンインストールは、大域ゾーンからのみ行うことができます。システムハードウェアから起動できるのは、大域ゾーンだけです。物理デバイス、ルーティング、動的再構成 (DR) といったシステムインフラストラクチャーの管理は、大域ゾーンでのみ行うことができます。大域ゾーンで実行されるプロセスは、適切な権限が付与されていれば、非大域ゾーンに関連付けられているオブジェクトにもアクセスできます。

非大域ゾーンを含むアップグレード

Solaris OS をインストールしたあと、非大域ゾーンをインストールして構成することができます。非大域ゾーンがインストールされている場合に、Solaris OS をアップグレードできます。ブランドを設定した非大域ゾーンがインストールされている場合、それらはアップグレードプロセスでは無視されます。非大域ゾーンがインストールされているシステムに対応できるインストールプログラムの要約を次に示します。

Solaris 10 10/09 リリース以降では、ゾーンパラレルパッチングによって、標準のSolaris 10 パッチユーティリティーが拡張されています。この機能は、非大域ゾーンにも並行してパッチを適用することで、ゾーンパッチングのパフォーマンスを向上します。

これまでと同様に、大域ゾーンには非大域ゾーンよりも先にパッチが適用されます。

Solaris 10 10/09 リリースより前のリリースでは、この機能は次のパッチユーティリティーへのパッチとして提供されています。

• SPARC: パッチ 119254-66 以降のリビジョン

• x86: パッチ 119255-66 以降のリビジョン

詳細については、次のドキュメントを参照してください。

• 『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「Solaris 10 10/09: パッチ適用時間を短縮するためのゾーンの並列パッチ」

• 『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「Solaris 10 10/09: 非大域ゾーンに並列でパッチを適用する方法」

非大域ゾーンを含んだシステムをアップグレードする場合の制限事項のリストを次の表に示します。

ゾーンを含むアップグレードを実行する前のシステムのバックアップ

アップグレードを実行する前に、Solaris システムの大域ゾーンと非大域ゾーンをバックアップしてください。ゾーンがインストールされているシステムのバックアップを作成する方法については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の第 27 章「Solaris のゾーン管理 (概要)」を参照してください。

非大域ゾーンのディスク容量要件

大域ゾーンをインストールするときには、作成するすべてのゾーンに十分なディスク容量を必ず確保してください。非大域ゾーンごとに、ディスク容量要件は異なる場合があります。

1 つのゾーンで消費できるディスク容量に制限はありません。容量制限は大域ゾーンの管理者が行います。小規模な単一プロセッサシステムでも、同時に稼働する多数のゾーンをサポートできます。非大域ゾーンを作成するときの容量要件は、大域ゾーンにインストールされたパッケージの種類によって異なります。パッケージの数およびディスク容量要件が要因となります。

計画の要件と推奨事項の詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の第 18 章「非大域ゾーンの計画と構成 (手順)」を参照してください。

第 9 章 インストール時の RAID-1 ボリューム (ミラー) の作成 (概要)

この章では、ルート (/) ファイルシステムの RAID-1 ボリューム (ミラー) を作成する利点について説明します。ファイルシステムのミラー作成に必要な Solaris ボリュームマネージャーコンポーネントについても説明します。この章の内容は次のとおりです。

• 「RAID-1 ボリュームを使用する理由」

• 「RAID-1 ボリュームの機能」

• 「Solaris ボリュームマネージャーコンポーネントの概要」

• 「RAID-1 ボリュームのディスク配置の例」

Solaris Live Upgrade や JumpStart に固有の追加情報については、次の資料を参照してください。

• Solaris Live Upgrade の場合: 『Oracle Solaris 10 9/10 インストールガイド (Solaris Live Upgrade とアップグレードの計画)』の「RAID-1 ボリューム (ミラー) ファイルシステムを作成するための一般的な指針」

• JumpStart:

  • 『Oracle Solaris 10 9/10 インストールガイド (カスタム JumpStart/上級編)』の「filesys プロファイルキーワード (RAID-1 ボリュームの作成)」

  • 『Oracle Solaris 10 9/10 インストールガイド (カスタム JumpStart/上級編)』の「metadb プロファイルキーワード (状態データベースの複製の作成)」

RAID-1 ボリュームを使用する理由

インストール時、またはアップグレード時に、RAID-1 ボリュームを作成して、複数の物理ディスクにシステムデータを複製できます。複数のディスクにデータを複製することにより、ディスクの破壊やディスク障害の際にデータを保護することができます。

Solaris カスタム JumpStart および Solaris Live Upgrade では、ファイルシステムをミラー化する RAID-1 ボリュームの作成に、Solaris ボリュームマネージャーを使用します。Solaris ボリュームマネージャーでは、ボリュームを使って確実にディスクやデータを管理できます。Solaris ボリュームマネージャーでは、連結、ストライプ、その他の複雑な構成が可能です。カスタム JumpStart および Solaris Live Upgrade インストールでは、これらの作業の一部が実行できます。たとえば、ルート (/) ファイルシステムの RAID-1 ボリュームを作成できます。RAID-1 ボリュームは、インストール時、またはアップグレード時に作成できるので、インストール後に作成する必要はありません。

• ガイドラインについては、「カスタム JumpStart と Solaris Live Upgrade のガイドライン」を参照してください。

• Solaris ボリュームマネージャーソフトウェアとそのコンポーネントの詳細については、『Solaris ボリュームマネージャの管理』を参照してください。

RAID-1 ボリュームの機能

Solaris ボリュームマネージャーは、物理ディスクおよびその関連データの管理に仮想ディスクを使用します。Solaris ボリュームマネージャーでは、仮想ディスクを「ボリューム」と呼びます。「ボリューム」とは、システム上で単一の論理デバイスとみなされる物理スライスの集まりの名前です。ボリュームは、一般的な UNIX 用語である「擬似 (仮想) デバイス」と、実質的に同義です。

アプリケーションやファイルシステム (UFS など) から見ると、ボリュームは物理ディスクと同じように機能します。Solaris ボリュームマネージャーは、ボリュームに対する入出力要求を、そのボリュームを構成するメンバーディスクに対する入出力要求に変換します。Solaris ボリュームマネージャーのボリュームは、スライス (ディスクパーティション) またはほかの Solaris ボリュームマネージャーボリュームから作成されます。

ボリュームを使用して、パフォーマンスとデータ可用性を向上させることができます。場合によっては、ボリュームの使用により入出力パフォーマンスも向上します。ボリュームの機能は、スライスと同じです。ボリュームはスライスとよく似ていますが、エンドユーザー、アプリケーション、およびファイルシステムに対して透過的です。物理デバイスと同様に、Solaris ボリュームマネージャーを使用して、ブロックデバイス名または raw デバイス名からボリュームにアクセスできます。ボリューム名は、使用しているのがブロックデバイスなのか raw デバイスなのかによって異なります。カスタム JumpStart インストールおよび Solaris Live Upgrade では、ミラー化されたファイルシステムの作成用としてブロックデバイスがサポートされます。ボリューム名の詳細については 「カスタム JumpStart と Solaris Live Upgrade を行うときの RAID ボリューム名の要件とガイドライン」を参照してください。

RAID-0 ボリューム (単一スライスの連結) を保持する RAID-1 ボリュームを作成する場合、Solaris ボリュームマネージャーは RAID-0 サブミラー上のデータを複製し、サブミラーを 1 つのボリュームとして処理します。

図 9–1 に、ルート (/) ファイルシステムを 2 つの物理ディスクに複製するミラーを示します。

図 9–1 2 つのディスクにルート (/) ファイルシステムの RAID-1 ボリュームを作成

図 9–1 のシステムの構成は、次のとおりです。

• d30 という名前のミラーは、d31 および d32 という名前のサブミラーで構成されています。ミラー d30 は、ルート (/) ファイルシステム内のデータを 2 つのサブミラーに複製しています。

• hdisk0 上のルートファイルシステム (/) は、d31 という名前の単一スライスの連結に含まれています。

• ルート (/) ファイルシステムは、hdisk1 という名前のハードディスクにコピーされます。このコピーは、 d32 という名前の単一スライスの連結です。

Solaris ボリュームマネージャーコンポーネントの概要

カスタム JumpStart インストールおよび Solaris Live Upgrade では、データの複製に必要な次のコンポーネントを作成できます。

• 状態データベースと状態データベースの複製 (metadbs)

• 単一スライスの連結 (サブミラー) を保持する RAID-1 ボリューム (ミラー)

この節では、これらのコンポーネント 1 つ 1 つについて簡単に説明します。これらのコンポーネントの詳細は、『Solaris ボリュームマネージャの管理』を参照してください。

状態データベースと状態データベースの複製

「状態データベース」は、物理ディスクに情報を格納するデータベースです。状態データベースは、構成に対して加えられた変更を記録および管理します。Solaris ボリュームマネージャーは、構成や状態に変化があると、状態データベースを自動的に更新します。新しいボリュームの作成は、構成の変更の一例です。サブミラーの障害は、状態の変化の一例です。

状態データベースは、実際には、複製された複数のデータベースコピーの集まりです。各コピーは、「状態データベースの複製」と呼ばれ、データベース内のデータが常に有効であることを保証します。状態データベースのコピーを複数持つことにより、単一点障害からデータを保護することができます。状態データベースは、既知の状態データベースの複製の格納場所と状態をすべて記録しています。

状態データベースとその状態データベースの複製が作成されるまで、Solaris ボリュームマネージャーは動作できません。Solaris ボリュームマネージャー構成には、正常に動作する状態データベースが必要です。

状態データベースの複製は、状態データベースのデータが常に有効であることを保証します。状態データベースが更新されると、個々の状態データベースの複製も更新されます。ただし、システムクラッシュによってすべての更新が失われるのを防ぐために、更新は一度に 1 つずつ行われます。

システムから 1 つの状態データベースの複製が失われると、Solaris ボリュームマネージャーは、どの状態データベースの複製に有効なデータが格納されているかを判断する必要があります。この情報を得るために、Solaris ボリュームマネージャーは「多数決アルゴリズム」を使用します。このアルゴリズムでは、過半数 (半数 + 1) の複製が使用可能であり、一致していれば、それらの複製を有効であるとみなします。この多数決アルゴリズムがあるため、ディスク構成を設定するときに、3 つ以上の状態データベースの複製を作成する必要があります。3 つの状態データベースの複製のうち少なくとも 2 つが使用可能であれば、合意に達することができます。

個々の状態データベースの複製には、デフォルトで 4M バイト (8192 ディスクセクタ) のディスク領域が使用されます。複製は、次のデバイスに格納できます。

• 専用のローカルディスクスライス

• Solaris Live Upgrade のみ:

  • ボリュームの一部となるローカルスライス

  • UFS ロギングデバイスの一部となるローカルスライス

複製は、ルート (/)、 swap、/usr スライス、およびファイルシステムやデータがすでに格納されているスライスには格納できません。ただし、複製を格納したあとで、同じスライスにボリュームやファイルシステムを置くことができます。

複数の状態データベースのコピーを 1 つのスライス上に置くこともできます。しかし、複数の状態データベースの複製を 1 つのスライスに置くと、システムが単一点障害に対してより脆弱になる可能性があります。

RAID-1 ボリューム (ミラー)

RAID-1 ボリューム (ミラー) は、同じデータのコピーを複数の RAID-0 ボリューム (単一スライスの連結) に保持しているボリュームです。RAID-1 ボリュームの構成後、このボリュームを物理スライスと同様に使用できます。既存のファイルシステムを含め、どのようなファイルシステムでも複製できます。RAID-1 ボリュームは、データベースなど、任意のアプリケーションでも使用できます。

RAID-1 ボリュームを使用したファイルシステムのミラー化には、次の利点と欠点があります。

• RAID-1 ボリュームでは、両方の RAID-0 ボリュームから同時にデータを読み取ることができるので (どちらのボリュームもすべての要求に応じることができる)、パフォーマンスが向上します。1 つの物理ディスクに障害が発生しても、パフォーマンスの低下やデータの損失なしにミラーを引き続き使用できます。

• RAID-1 ボリュームを使用する場合、より多くのディスク容量が必要になります。少なくとも、データの容量の 2 倍のディスク容量が必要です。

• Solaris ボリュームマネージャーソフトウェアは、すべての RAID-0 ボリュームに書き込む必要があるので、データを複製すると、書き込み要求がディスクに書き込まれるまでの時間も長くなる可能性があります。

RAID-0 ボリューム (連結)

RAID-0 ボリュームは、単一スライスの連結です。連結とは、複数のコンポーネント間でデータが順番に隣接して配置され、1 つの論理記憶ユニットを構成するボリュームのことです。カスタム JumpStart インストールおよび Solaris Live Upgrade では、ストライプの作成や、その他の複雑な Solaris ボリュームマネージャーボリュームは作成できません。

インストール時、またはアップグレード時に、RAID-1 ボリューム (ミラー) を作成し、これらのミラーに RAID-0 ボリュームを追加できます。「ミラー化された」RAID-0 ボリュームを「サブミラー」と呼びます。ミラーは 1 個以上の RAID-0 ボリュームで構成されます。インストール後、Solaris ボリュームマネージャーを使用して RAID-1 ミラーボリュームを管理することにより、個々の RAID-0 サブミラーボリューム上のデータを管理できます。

カスタム JumpStart インストールでは、最大 2 つのサブミラーで構成されるミラーを作成できます。Solaris Live Upgrade では、最大 3 つのサブミラーで構成されるミラーを作成できます。実際には 2 面ミラーで十分です。3 つ目のサブミラーを構成すると、オンラインでバックアップをとることができます。この場合、バックアップのために 1 つのサブミラーがオフラインになっていても、データの冗長性は失われません。

RAID-1 ボリュームのディスク配置の例

次の図は、ルートファイルシステム (/) を 2 つの物理ディスク上に複製する RAID-1 ボリュームです。状態データベースの複製 (metadb) は、両方のディスクに配置されています。

図 9–2 RAID-1 ボリュームのディスク配置

図 9–2 のシステムの構成は、次のとおりです。

• d30 という名前のミラーは、d31 および d32 という名前のサブミラーで構成されています。ミラー d30 は、ルート (/) ファイルシステム内のデータを 2 つのサブミラーに複製しています。

• hdisk0 上のルートファイルシステム (/) は、d31 という名前の単一スライスの連結に含まれています。

• ルート (/) ファイルシステムは、hdisk1 という名前のハードディスクにコピーされます。このコピーは、 d32 という名前の単一スライスの連結です。

• 状態データベースの複製は、 hdisk0 と hdisk1 の両方のスライスで作成されます。

第 10 章 インストール時の RAID-1 ボリューム (ミラー) の作成 (計画)

この章では、カスタム JumpStart または Solaris Live Upgrade インストールを使って RAID-1 ボリュームを作成するために必要な条件とガイドラインについて説明します。

この章の内容は次のとおりです。

• 「システム要件」

• 「状態データベースの複製のガイドラインと要件」

• 「RAID-1 ボリュームと RAID-0 ボリュームの要件とガイドライン」

• 「シングルユーザーモードでのブート時に表示されるミラー保守管理に関する通知」

Solaris Live Upgrade や JumpStart に固有の追加情報については、次の資料を参照してください。

• Solaris Live Upgrade の場合: 『Oracle Solaris 10 9/10 インストールガイド (Solaris Live Upgrade とアップグレードの計画)』の「RAID-1 ボリューム (ミラー) ファイルシステムを作成するための一般的な指針」

• JumpStart:

  • 『Oracle Solaris 10 9/10 インストールガイド (カスタム JumpStart/上級編)』の「filesys プロファイルキーワード (RAID-1 ボリュームの作成)」

  • 『Oracle Solaris 10 9/10 インストールガイド (カスタム JumpStart/上級編)』の「metadb プロファイルキーワード (状態データベースの複製の作成)」

システム要件

RAID-1 ボリュームを作成して、特定のスライスにデータを複製するには、インストール時に、使用するディスクがシステムに直接接続されていて使用可能である必要があります。

状態データベースの複製のガイドラインと要件

シングルポイント障害を避けるため、状態データベースの複製は、複数のスライス、ドライブ、およびコントローラに分散させる必要があります。これは、単一のコンポーネントに障害が発生した場合でも、大半の複製を利用可能な状態に保つ必要があるからです。たとえばデバイス障害時などに、複製が失われた場合、Solaris ボリュームマネージャーの実行やシステムの再起動が正常に行われなくなることがあります。Solaris ボリュームマネージャーが動作するためには、少なくとも半数の複製が使用可能でなければならず、システムをマルチユーザーモードで再起動するためには過半数 (半数+1) の複製が使用可能でなければなりません。

状態データベースの複製の作成および管理方法の詳細は、『Solaris ボリュームマネージャの管理』を参照してください。

状態データベースの複製用のスライスの選択

状態データベースの複製用のスライスを選択する前に、次のガイドラインと推奨事項を参考にしてください。

状態データベースの複製の数の選択

状態データベースの複製の数を選択する前に、次のガイドラインを参考にしてください。

• 状態データベースの複製の数は、Solaris ボリュームマネージャーの 1 つのディスクセットに対して、最低 3 つから最高 50 までを推奨します。次のガイドラインを推奨します。

  • ドライブが 1 つだけのシステムでは、3 つの複製すべてを 1 つのスライスに置きます。

  • ドライブの数が 2 つから 4 つのシステムでは、 各ドライブに 2 つずつ複製を置きます。

  • ドライブの数が 5 つ以上のシステムでは、 各ドライブに 1 つずつ複製を置きます。

• 状態データベースの複製を追加することで、ミラーのパフォーマンスを向上させることができます。一般に、システムにミラーを 1 つ追加するごとに複製は 2 つ追加する必要があります。

• 小容量のランダム入出力 (データベースなど) に RAID-1 ボリュームを使用する場合は、複製の数を考慮する必要があります。RAID-1 ボリュームごとに、その RAID-1 ボリュームに接続されていない複数のスライス (および、可能であれば複数のディスクとコントローラ) 上に 2 つ以上の複製を余分に作成します。これは、最適な性能を得るために必要な作業です。

コントローラ間で状態データベースの複製を分散

複数のコントローラがある場合、できるだけすべてのコントローラに均等になるように複製を分散させます。これによって、コントローラ障害に対する冗長性が確保できるだけでなく、負荷の分散も可能になります。同じコントローラ上に複数のディスクが存在する場合は、各コントローラで 2 個以上のディスクに複製を配置します。

RAID-1 ボリュームと RAID-0 ボリュームの要件とガイドライン

RAID-1 ボリューム (ミラー) と RAID-0 ボリューム (単一スライスの連結) を使用する際は、次のガイドラインに従ってください。

カスタム JumpStart と Solaris Live Upgrade のガイドライン

カスタム JumpStart インストールと Solaris Live Upgrade は、Solaris ボリュームマネージャーで使用可能な機能の一部をサポートします。これらのインストールプログラムでミラー化されたファイルシステムを作成するときは、次のガイドラインに従ってください。

カスタム JumpStart と Solaris Live Upgrade を行うときの RAID ボリューム名の要件とガイドライン

ボリュームに名前を割り当てるときには、次の規則に従ってください。

• スライス番号とディスク番号がボリューム番号に対応するような命名方法を使用します。

• ボリューム名は d で始まり、その後に 1 つの数字が続きます (たとえば、d0)。

• Solaris ボリュームマネージャーでは、0 から 127 までの 128 個のデフォルトボリューム名を使用できます。次にボリューム名の例を示します。

  • デバイス /dev/md/dsk/d0 - ブロックボリューム d0

  • デバイス /dev/md/dsk/d1 - ブロックボリューム d1

• 特定のボリュームタイプごとに範囲を指定します。たとえば、RAID-1 ボリュームには 0 から 20、RAID-0 ボリュームには 21 から 40 を割り当てます。

Solaris Live Upgrade を行うときの RAID ボリュームの命名規則

RAID-1 ボリューム (ミラー) または RAID-0 ボリューム (サブミラー) を作成するのに Solaris Live Upgrade を使用する場合は、ソフトウェアでボリューム名を検出して割り当てるか、またはユーザーがボリューム名を割り当てることができます。ソフトウェアで名前を検出すると、ソフトウェアは使用可能な最初のミラー名またはサブミラー名を割り当てます。ユーザーがミラー名を割り当てる場合は、インストール時にサブミラーに 1 および 2 で終わる名前を使用できるように、0 で終わる名前を割り当てます。ユーザーがサブミラー名を割り当てる場合は、1 または 2 で終わる名前を割り当てます。誤った番号を割り当てると、ミラーが作成されない可能性があります。たとえば、ミラー名に 1 または 2 で終わる番号 (d1 または d2) を持つ名前を指定すると、ミラー名がサブミラーの名前と重複した場合、Solaris Live Upgrade はミラーの作成に失敗します。

以前のリリースでは、省略されたボリューム名を入力できました。Solaris 10 10/08 以降のリリースでは、完全ボリューム名だけを入力できます。たとえば、/dev/md/dsk/d10 などの完全ボリューム名だけをミラーの指定に使用できます。

例 10–1 Solaris Live Upgrade: ソフトウェアによるミラーとサブミラーの検出および命名の有効化

次の例では、Solaris Live Upgrade がボリューム名を割り当てています。RAID-1 ボリュームの d0 と d1 だけが使用中のボリュームです。ミラー d10 に対し、デバイス c0t0d0s0 用のサブミラー名として d2 を、デバイス c1t0d0s0 用のサブミラー名として d3 を、Solaris Live Upgrade が割り当てます。

lucreate -n newbe -m /:/dev/md/dsk/d10:mirror,ufs  \
-m /:/dev/dsk/c0t0d0s0:attach -m /:/dev/dsk/c1t0d0s0:attach

例 10–2 Solaris Live Upgrade: ミラーおよびサブミラー名の割り当て

次の例では、コマンドでボリューム名を割り当てています。ミラー d10 に対し、デバイス c0t0d0s0 用のサブミラー名が d11、デバイス c1t0d0s0 用のサブミラー名が d12 です。

lucreate -n newbe -m /:/dev/md/dsk/d10:mirror,ufs \
-m /:/dev/dsk/c0t0d0s0,/dev/md/dsk/d11:attach \
-m /:/dev/dsk/c1t0d0s0,/dev/md/dsk/d12:attach

Solaris ボリュームマネージャーの命名規則については、『Solaris ボリュームマネージャの管理』を参照してください。

カスタム JumpStart を行うときの RAID ボリュームの命名規則

RAID-1 ボリューム (ミラー) または RAID-0 ボリューム (サブミラー) を作成するのにカスタム JumpStart インストール方式を使用する場合は、ソフトウェアでミラーリングするボリューム名を検出して割り当てるか、またはプロファイルでボリューム名を割り当てることができます。

• ソフトウェアによる名前の検出を有効にすると、ソフトウェアにより使用可能な最初のボリューム番号が割り当てられます。

• プロファイルでボリューム名を割り当てる場合は、インストール時にサブミラーに 1 および 2 で終わる名前を使用できるように、0 で終わるミラー名を割り当てます。

  ---

  注 –

  誤った番号を割り当てると、ミラーが作成されない可能性があります。たとえば、ミラー名に 1 または 2 で終わる番号 (d1 または d2) を持つ名前を指定すると、ミラー名がサブミラーの名前と重複した場合、JumpStart プログラムはミラーの作成に失敗します。

  ---

物理ディスクスライスや Solaris ボリュームマネージャーのボリュームの名前は、省略形にすることができます。省略名は、デバイスを一意に識別できる最短の名前です。次に例を示します。

• Solaris ボリュームマネージャーのボリュームは dnum という形式で表されます。たとえば、/dev/md/dsk/d10 は d10 となります。

• 1 つのコントローラと複数のディスクを持つシステムでは t0d0s0 を使用できますが、複数のコントローラがある場合は c0t0d0s0 を使用します。

例 10–3 ソフトウェアによるミラー名とサブミラー名の検出の有効化

次のプロファイル例では、ミラーには使用可能な最初のボリューム番号が割り当てられています。次に使用可能な 0 で終わるミラーが d10 の場合、名前 d11 および d12 はサブミラーに割り当てられます。

filesys                 mirror c0t0d0s1  / 

例 10–4 ミラー名とサブミラー名の割り当て

次のプロファイル例では、プロファイル内でミラー番号 d30 が割り当てられています。サブミラー名は、ミラー番号および最初に使用可能なサブミラーに基づき、ソフトウェアによって割り当てられます。サブミラー名は d31 と d32 です。

filesys                 mirror:d30 c0t1d0s0 c0t0d0s0  /

Solaris ボリュームマネージャーの命名規則については、『Solaris ボリュームマネージャの管理』を参照してください。

ディスクとコントローラの選択のガイドライン

ファイルシステムのミラー化に使用するディスクやコントローラを選択するときは、次のガイドラインに従ってください。

• コンポーネントをそれぞれ異なるコントローラに置くと、同時に実行できる読み取りや書き込みの数が増えます。

• サブミラーのスライスは、異なるディスクとコントローラに配置します。同じミラーの 2 つ以上のサブミラーのスライスを同じディスクに置くと、データの保護機能が大幅に低下します。

• サブミラーは、別個のコントローラに配置します。これは、コントローラやそのケーブルでは、ディスクよりも障害が発生する確率が高いためです。これにより、ミラーのパフォーマンスも向上します。

• 1 つのミラーでは、同じタイプのディスクとコントローラを使用します。特に、古いタイプの SCSI 記憶装置では、ディスクやコントローラのパフォーマンスがモデルやブランドによって大幅に異なることがあります。パフォーマンスレベルが異なるデバイスが同じミラーに混在していると、パフォーマンスが大幅に低下することがあります。

スライスの選択のガイドライン

ファイルシステムのミラー化に使用するスライスを選択するときは、次のガイドラインに従ってください。

• ルート (/)、swap、/usr を含むどのファイルシステムでもミラーを使用できます。また、データベースをはじめとするどのアプリケーションでもミラーを使用できます。

• サブミラースライスが同じサイズになっていることを確認してください。サイズが異なるサブミラーを使用すると、ディスク領域が無駄になります。

• ミラー化されたファイルシステムで、最初に接続したサブミラーがシリンダ 0 から始まらない場合、追加接続するすべてのサブミラーも、シリンダ 0 から始まらないようにしてください。最初のサブミラーがシリンダ 0 から始まらないミラーに、シリンダ 0 から始まるサブミラーを接続しようとすると、次のエラーメッセージが表示されます。

  can't attach labeled submirror to an unlabeled mirror

  1 つのミラーに接続するサブミラーは、全部シリンダ 0 から始まるか、どれもシリンダ 0 から始まらないかのどちらかにする必要があります。

  開始シリンダは、すべてのサブミラーで同じにする必要はありませんが、すべてのサブミラーにシリンダ 0 が含まれるか、すべてのサブミラーにシリンダ 0 が含まれないかのどちらかでなければなりません。

シングルユーザーモードでのブート時に表示されるミラー保守管理に関する通知

ルート (/)、/usr、およびswap のミラーを持つシステムをシングルユーザーモードでブートした場合、これらのミラーの保守管理が必要であることが、システムから通知されます。metastat コマンドでこれらのミラーを確認すると、「Needing Maintenance」という状態情報が表示されます。システム上のすべてのミラーでこの現象が起きる場合もあります。

これは危険な状況に見えますが、心配はいりません。metasync -r コマンドは通常、ブート時にミラーの再同期のために実行されますが、 システムがシングルユーザーモードでブートされた場合には実行を中断されます。システムをリブートすると、metasync -r コマンドが実行され、すべてのミラーの再同期が取られます。

この中断が問題になる場合は、手動で metasync -r コマンドを実行してください。

metasync の詳細については、metasync(1M) のマニュアルページと、『Solaris ボリュームマネージャの管理』を参照してください。