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

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

• x86 ベースのシステムでの GRUB ベースのブート

• Solaris ゾーン区分技術

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

第 6 章 x86: Solaris インストールのための GRUB ベースのブート

この章では、Solaris インストールに関連する、x86 ベースのシステムでの GRUB ベースのブートについて説明します。この章の内容は次のとおりです。

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

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

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

オープンソースのブートローダー GRUB が、Solaris OS のデフォルトのブートローダーとして採用されています。

GRUB ベースのブートは、SPARC ベースのシステムでは使用できません。

ブートローダーは、システムの電源を入れたあと最初に実行されるソフトウェアプログラムです。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 を使用すると、さまざまなオペレーティングシステムのブートおよびインストールがより簡単にできます。たとえば、1 つのシステムで次のオペレーティングシステムを別々にブートできます。

• Solaris OS

• Microsoft Windows

  ---

  注 –

  GRUB は Microsoft Windows のパーティションを検出しますが、OS がブート可能かどうかは確認しません。

  ---

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

x86: GRUB ベースのブートの動作

GRUB がシステムの制御を取得すると、コンソールにメニューが表示されます。GRUB メニューでは次の操作を実行できます。

• エントリを選択してシステムをブートします

• 組み込まれている GRUB 編集メニューを使用してブートエントリを変更します

• コマンド行から手動で OS カーネルをロードします

デフォルトで登録されている OS ブートでは、設定可能なタイムアウトを利用できます。いずれかのキーを押すと、デフォルトの OS エントリのブートが中止されます。

GRUB メニューの例については、「GRUB メインメニューについて」を参照してください。

x86: GRUB デバイス命名規則

GRUB が使用するデバイス命名規則は、以前の Solaris OS バージョンの場合と若干異なっています。GRUB デバイス命名規則を理解すると、使用しているシステムで GRUB を構成するときに、ドライブとパーティションの情報を正しく指定できます。

次の表に、GRUB デバイス命名規則を示します。

GRUB デバイス名はすべて括弧で囲む必要があります。パーティション番号は、1 からではなく 0 (ゼロ) から数えます。

fdisk パーティションの詳細については、『Solaris のシステム管理 (デバイスとファイルシステム)』の「fdisk パーティションの作成上のガイドライン」を参照してください。

x86: 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 でネットワークを手動で構成し、ファイルサーバーからマルチブートプログラムとブートアーカイブをダウンロードできます。

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

GRUB メインメニューについて

x86 ベースのシステムをブートすると、GRUB メニューが表示されます。このメニューには、選択可能なブートエントリの一覧が表示されます。「ブートエントリ」は、使用しているシステムにインストールされている OS インスタンスです。GRUB メニューは、構成ファイルの menu.lst ファイルに基づいています。menu.lst ファイルは、Solaris インストールプログラムによって作成され、インストール後に変更できます。menu.lst ファイルには、GRUB メニューに表示される OS インスタンスの一覧が記述されています。

• Solaris OS をインストールまたはアップグレードすると、GRUB メニューが自動的に更新されます。これにより、Solaris OS が新しいブートエントリとして表示されます。

• Solaris OS 以外の OS をインストールする場合は、menu.lst 構成ファイルに変更を加えて新しい OS インスタンスを含める必要があります。新しい OS インスタンスを追加すると、システムを次にブートしたときに、新しいブートエントリが GRUB メニューに表示されます。

例 6–1 GRUB メインメニュー

次の例では、GRUB メインメニューに Solaris オペレーティングシステムと Microsoft Windows オペレーティングシステムが表示されています。また、Solaris Live Upgrade ブート環境も second_disk という名前で一覧に表示されています。各メニューの項目については、続く説明を参照してください。

GNU GRUB version 0.95 (616K lower / 4127168K upper memory)
+-------------------------------------------------------------------+
|Solaris                                                            |
|Solaris failsafe                                                   |
|second_disk                                                        |
|second_disk failsafe                                               |
|Windows                                                            |
+-------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted. Press
enter to boot the selected OS, 'e' to edit the commands before
booting, or 'c' for a command-line.

Solaris

Solaris OS を指定します。

Solaris failsafe

Solaris OS が損傷した場合に、回復のために使用できるブートアーカイブを指定します。

second_disk

Solaris Live Upgrade ブート環境を指定します。second_disk ブート環境は、Solaris OS のコピーとして作成されました。luactivate コマンドによってアップグレードおよびアーカイブされています。ブート環境は、ブート時に使用できます。

Windows

Microsoft Windows OS を指定します。GRUB はこれらのパーティションを検出しますが、OS がブート可能かどうかは確認しません。

GRUB menu.lst ファイルについて

GRUB menu.lst ファイルには、GRUB メインメニューの内容の一覧が記述されています。GRUB メインメニューには、Solaris Live Upgrade ブート環境を含め、システムにインストールされているすべての OS インスタンスのブートエントリが一覧表示されます。Solaris のソフトウェアアップグレード処理では、このファイルに対して行なった変更内容がすべて保持されます。

menu.lst ファイルに対する修正は、Solaris Live Upgrade エントリと一緒に、すべて GRUB メインメニューに表示されます。ファイルに対する変更点はすべて、システムを次にリブートしたときに有効になります。このファイルは、次の目的で変更できます。

• Solaris 以外のオペレーティングシステム用の GRUB メニューエントリを追加するため

• GRUB メニューでのデフォルトの OS の指定など、ブート動作をカスタマイズするため

GRUB menu.lst ファイルを使用して Solaris Live Upgrade エントリを変更しないでください。変更により、Solaris Live Upgrade の実行に失敗する可能性があります。

menu.lst ファイルを使用してカーネルデバッガによるブートなどのブート動作をカスタマイズできますが、カスタマイズする場合は eeprom コマンドを使用する方法をお勧めします。menu.lst ファイルを使用してカスタマイズすると、ソフトウェアのアップグレード時に Solaris OS エントリが変更される可能性があります。これにより、ファイルに加えた変更内容が失われます。

eeprom コマンドの使用法については、『Solaris のシステム管理 (基本編)』の「eeprom コマンドを使用して Solaris ブートパラメータを設定する方法」を参照してください。

例 6–2 menu.lst ファイル

次に menu.lst ファイルの例を示します。

default 0
timeout 10
title Solaris
  root (hd0,0,a)
  kernel /platform/i86pc/multiboot -B console=ttya
  module /platform/i86pc/boot_archive
title Solaris failsafe
  root (hd0,0,a)
  kernel /boot/multiboot -B console=ttya -s
  module /boot/x86.miniroot.safe
#----- second_disk - ADDED BY LIVE UPGRADE - DO NOT EDIT  -----
title second_disk
  root (hd0,1,a)
  kernel /platform/i86pc/multiboot
  module /platform/i86pc/boot_archive
title second_disk failsafe
  root (hd0,1,a)
  kernel /boot/multiboot kernel/unix -s
  module /boot/x86.miniroot-safe
#----- second_disk -------------- END LIVE UPGRADE ------------
title Windows
  root (hd0,0)
  chainloader -1

default

タイムアウトした場合にブートする項目を指定します。デフォルトの設定を変更する場合は、番号を変更して一覧の別の項目を指定できます。最初のタイトルを 0 として数えます。たとえば、デフォルトを 2 に変更すると、second_disk ブート環境が自動的にブートします。

timeout

デフォルトのエントリをブートするまで、ユーザーの入力を待つ時間を秒単位で指定します。タイムアウトを指定しない場合は、エントリを選択する必要があります。

title OS name

オペレーティングシステムの名前を指定します。

• これが Solaris Live Upgrade ブート環境の場合、OS name は新しいブート環境の作成時にその環境に指定した名前です。前の例では、Solaris Live Upgrade ブート環境の名前は second_disk です。

• これがフェイルセーフブートアーカイブの場合、このブートアーカイブは主 OS が損傷したときの回復処理に使用されます。前の例では、Solaris フェイルセーフと second_disk フェイルセーフが Solaris および second_disk オペレーティングシステムの回復用ブートアーカイブです。

root (hd0,0,a)

ファイルのロード先となるディスク、パーティション、およびスライスを指定します。GRUB は、ファイルシステムの種類を自動的に検出します。

kernel /platform/i86pc/multiboot

マルチブートプログラムを指定します。kernel コマンドのあとに、必ずマルチブートプログラムを指定する必要があります。マルチブートのあとの文字列は、解釈されずに Solaris OS に渡されます

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

GRUB メニューを変更するための menu.lst ファイルの検出

GRUB メニューの menu.lst ファイルを検出するには、常に bootadm コマンドを使用する必要があります。アクティブな GRUB メニューを見つけるには、list-menu サブコマンドを使用します。menu.lst ファイルには、システムにインストールされているすべてのオペレーティングシステムが一覧表示されています。このファイルの内容は、GRUB メニューに表示されるオペレーティングシステムの一覧を記述したものです。このファイルに変更を加える場合は、『Solaris 10 8/07 インストールガイド (Solaris Live Upgrade とアップグレードの計画)』の「GRUB メニューの menu.lst ファイルの検出 (作業)」を参照してください。

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

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

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

• 「Solaris ゾーン (概要)」

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

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

Solaris ゾーン (概要)

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

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

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

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

• Solaris 対話式インストールプログラムでは、非大域ゾーンがインストールされている場合にシステムのアップグレードまたはパッチの適用が可能です。インストールされている非大域ゾーンの数に応じて、アップグレードやパッチに要する時間が大幅に長くなることがあります。このプログラムを使用したインストールの詳細は、『Solaris 10 8/07 インストールガイド (基本編)』の第 2 章「Solaris インストールプログラムによるインストール (作業)」を参照してください。

• 自動化された JumpStart インストールでは、アップグレードまたはパッチに適用する任意のキーワードを使ってアップグレードまたはパッチを行うことができます。インストールされている非大域ゾーンの数に応じて、アップグレードやパッチに要する時間が大幅に長くなることがあります。このプログラムを使用したインストールの詳細は、『Solaris 10 8/07 インストールガイド (カスタム JumpStart/ 上級編)』を参照してください。

• Solaris Live Upgrade では、非大域ゾーンが含まれているシステムのアップグレードまたはパッチの適用が可能です。システムに非大域ゾーンが含まれている場合は、アップグレードプログラムまたはパッチを追加するプログラムとして、Solaris Live Upgrade を推奨します。ほかのアップグレードプログラムでは、膨大なアップグレード時間が必要となる場合があります。これは、アップグレードの実行に要する時間が、インストールされている非大域ゾーンの数に比例して増加するからです。Solaris Live Upgrade を使ってシステムにパッチを適用する場合は、システムをシングルユーザーモードにする必要がないため、システムの稼働時間を最大限に活用できます。非大域ゾーンがインストールされているシステムに対応するための変更は次のとおりです。

  • 新しいパッケージ SUNWlucfg をほかの Solaris Live Upgrade パッケージ SUNWlur および SUNWluu とともにインストールする必要があります。

  • 現在稼働しているブート環境から新しいブート環境を作成する方法は同じままですが、例外が 1 つあります。非大域ゾーン内の共有ファイルシステムの宛先スライスを指定できます。この例外は、次の状況のもとで発生します。

    • 現在のブート環境で zonecfg add fs コマンドが使用され、非大域ゾーンに対して個別のファイルシステムが作成された場合

    • この個別のファイルシステムが、/zone/root/export などの共有ファイルシステム上にある場合

    この個別のファイルシステムが新しいブート環境で共有されないようにするため、非大域ゾーンの個別ファイルシステムの宛先スライスを指定できるように lucreate コマンドが変更されました。-m オプションの引数には、新しい省略可能フィールド zonename が追加されました。この新しいフィールドは、非大域ゾーンの個別のファイルシステムを新しいブート環境の個々のスライス上に配置します。個別のファイルシステムを含む非大域ゾーンの設定方法の詳細は、zonecfg(1M) のマニュアルページを参照してください。

    ---

    注 –

    デフォルトでは、クリティカルファイルシステム (ルート(/)、/usr、/opt ファイルシステム) 以外のすべてのファイルシステムが、現在のブート環境と新しいブート環境との間で共有されます。このため、アクティブブート環境内の共有ファイルを更新すると、非アクティブブート環境のデータも更新されます。/export ファイルシステムは、共有ファイルシステムの一例です。-m オプションと zonename オプションを使用すると、非大域ゾーンの共有ファイルシステムが個々のスライスにコピーされ、データは共有されません。このオプションを使用すると、zonecfg add fs コマンドを使って作成した非大域ゾーンのファイルシステムがブート環境間で共有されなくなります。

    ---

  • ブート環境の比較機能が向上しました。lucompare コマンドは、非大域ゾーンの内容が含まれているブート環境の比較を行うようになりました。

  • lumount コマンドは、非大域ゾーンが、非アクティブブート環境に存在する、それらに対応する個別のファイルシステムにアクセスできるようにします。大域ゾーン管理者が lumount コマンドを使って非アクティブブート環境をマウントすると、同様にブート環境が非大域ゾーン用にマウントされます。

  • lufslist コマンドによるファイルシステムの表示機能が向上し、大域ゾーンと非大域ゾーンの両方のファイルシステムの一覧が表示されるようになりました。

非大域ゾーンがインストールされているときに Solaris Live Upgrade を使用する手順については、『Solaris 10 8/07 インストールガイド (Solaris Live Upgrade とアップグレードの計画)』の第 9 章「非大域ゾーンがインストールされているシステムにおける Solaris OS のアップグレード」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• JumpStart:

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

  • 『Solaris 10 8/07 インストールガイド (カスタム 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 つのボリュームとして処理します。

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

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

図 8–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) は、両方のディスクに配置されています。

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

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

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

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

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

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

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

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

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

• 「システム要件」

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

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

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

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

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

• JumpStart:

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

  • 『Solaris 10 8/07 インストールガイド (カスタム 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 はミラーの作成に失敗します。

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

例 9–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

例 9–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 を使用します。

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

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

filesys                 mirror c0t0d0s1  / 

例 9–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 ボリュームマネージャの管理』を参照してください。