次に、現在のブート環境のコピーを作成してそのコピーをアップグレードし、アクティブなブート環境になるように切り替える作業の概要を示します。元のブート環境に切り替えるフォールバックの手順についても説明します。図 2–1 に、この Solaris Live Upgrade 処理の全体を示します。
次の節で、Solaris Live Upgrade の実行手順について説明します。
ブート環境を作成すると、クリティカルファイルシステムをアクティブなブート環境から新しいブート環境にコピーできます。必要であれば、ディスクを編成し直して、ファイルシステムをカスタマイズし、クリティカルファイルシステムを新しいブート環境にコピーします。
Solaris Live Upgrade では、次の 2 種類のファイルシステムを区別します。 クリティカルファイルシステムと共有可能ファイルシステムです。次の表に、これらのファイルシステムのタイプを示します。
ファイルシステムのタイプ |
説明 |
例と詳細 |
---|---|---|
クリティカルファイルシステム |
クリティカルファイルシステムは、Solaris OS に必須のファイルシステムです。これらのファイルシステムは、アクティブなブート環境と非アクティブなブート環境の vfstab において別々のマウントポイントを持ちます。これらのファイルシステムは、必ずソースブート環境から非アクティブブート環境にコピーされます。クリティカルファイルシステムのことを「共有不能」と呼ぶこともあります。 |
root (/)、/usr、/var、/opt などがクリティカルファイルシステムの例です。 |
共有可能ファイルシステム |
共有可能なファイルシステムとは、/export のように、アクティブなブート環境と非アクティブなブート環境の両方の vfstab において同じマウントポイントを持つユーザー定義ファイルのことです。したがって、アクティブなブート環境内の共有ファイルを更新すると、非アクティブなブート環境のデータも更新されます。新しいブート環境を作成するとき、共有可能なファイルシステムはデフォルトで共有されます。しかし、コピー先のスライスを指定した場合、そのファイルシステムは (共有されずに) コピーされます。 |
たとえば、/export が共有可能ファイルシステムの例です。 共有可能なファイルシステムについての詳細は、「共有可能なファイルシステムのスライスを選択するための指針」を参照してください。 |
スワップ |
|
|
Solaris Live Upgrade では、ファイルシステム上に RAID-1 ボリューム (ミラー) を持つブート環境を作成できます。概要については、「RAID-1 ボリュームファイルシステムを持つブート環境の作成」を参照してください。
新しいブート環境を作成するには、まず、クリティカルファイルシステムをコピーできる未使用のスライスが存在することを確認します。スライスが使用できないかあるいは最小限の要件を満たしていない場合は、新しいスライスをフォーマットする必要があります。
スライスを定義した後、ファイルシステムをディレクトリにコピーする前に、新しいブート環境上のファイルシステムを再構成できます。ファイルシステムを分割およびマージすることによってvfstab を簡単に編集でき、ファイルシステムを再構成することができます。ファイルシステムは、同じマウントポイントを指定して親ディレクトリにマージすることも、異なるマウントポイントを指定して親ディレクトリから分割することも可能です。
非アクティブブート環境でファイルシステムを構成した後、自動コピーを開始します。クリティカルファイルシステムは、指定された宛先ディレクトリにコピーされます。共有可能なファイルシステムは (それらの一部をコピーするように指定しない限り)、コピーされずに共有されます。ファイルシステムをアクティブなブート環境から非アクティブなブート環境にコピーする時、ファイルは新しいディレクトリにコピーされるので、アクティブなブート環境は変更されません。
ファイルシステムの分割やマージの手順 | |
RAID-1 ボリュームファイルシステムを持つブート環境の作成の概要 |
UFS ファイルシステムでは、次の図で示すように新規ブート環境がさまざまな方法で作成されます。
ZFS ファイルシステムの場合については、第 11 章Solaris Live Upgrade と ZFS (概要)を参照してください。
図 2–2 に、クリティカルファイルシステムのルート(/) をディスク上の別のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境は、既存のスライス上にルート (/) ファイルシステムを持っています。新しいブート環境は、新しいスライス上にルート (/) ファイルシステムとまったく同じ複製を持ちます。/swap ボリュームと /export/home ファイルシステムは、アクティブなブート環境と非アクティブなブート環境で共有されます。
図 2–3 に、クリティカルファイルシステムを分割し、ディスク上の複数のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境は、既存のスライス上にルート (/) ファイルシステムを持っています。このスライスでは、ルート (/) ファイルシステム内に、/usr、/var、および /opt ディレクトリがあります。新しいブート環境では、ルート (/) ファイルシステムは分割され、/usr と /opt は別のスライスに配置されています。/swap ボリュームと /export/home ファイルシステムは、両方のブート環境で共有されます。
図 2–4 に、クリティカルファイルシステムをマージし、ディスク上の複数のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境には、ルート (/) ファイルシステム、/usr、/var、/opt があり、各ファイルシステムは別々のスライス上に配置されています。新しいブート環境では、/usr と /opt はルート (/) ファイルシステムと同一のスライス上にマージされます。/swap ボリュームと /export/home ファイルシステムは、両方のブート環境で共有されます。
Solaris Live Upgrade は、Solaris ボリュームマネージャーテクノロジを使って、RAID-1 ボリュームにカプセル化されたファイルシステムを持つブート環境を作成できます。Solaris ボリュームマネージャーでは、ボリュームを使って確実にディスクやデータを管理できます。Solaris ボリュームマネージャーでは、連結、ストライプ、その他の複雑な構成が可能です。Solaris Live Upgrade では、これらの作業の一部を実行できます。たとえば、ルート (/) ファイルシステムの RAID-1 ボリュームを作成できます。
ボリュームを使用すると、複数のディスクにまたがるディスクスライスをグループ化して、OS で単一のディスクとして扱われるようにできます。Solaris Live Upgrade で作成できるのは、RAID-1 ボリューム (ミラー) 内に単一スライスの連結を持つルート (/) ファイルシステムのブート環境だけです。これは、ブート用のスライスを 1 つだけ選択するようにブート PROM が制限されているためです。
ブート環境を作成するとき、Solaris Live Upgrade を使って次の作業を行うことができます。
単一スライスの連結 (サブミラー) を RAID-1 ボリューム (ミラー) から切り離します。必要な場合は、内容を保持して新しいブート環境の内容にすることができます。内容はコピーされないため、新しいブート環境を短時間で作成できます。ミラーから切り離されたサブミラーは、元のミラーの一部ではなくなります。サブミラーに対する読み取りや書き込みがミラーを介して実行されることはなくなります。
ミラーを含んだブート環境を作成します。
新しく作成したミラーに単一スライスの連結を 3 つまで接続します。
lucreate コマンドの -m オプションを使って、新しいブート環境に対してミラーの作成、サブミラーの切り離し、およびサブミラーの接続を行うことができます。
現在のシステム上に VxVM ボリュームが構成されている場合は、lucreate コマンドを使用して新しいブート環境を作成できます。新しいブート環境にデータをコピーすると、Veritas ファイルシステム構成が失われ、新しいブート環境に UFS ファイルシステムが作成されます。
詳細な手順 | |
インストール時の RAID-1 ボリューム作成の概要 |
『Oracle Solaris 10 9/10 インストールガイド (インストールとアップグレードの計画)』の第 9 章「インストール時の RAID-1 ボリューム (ミラー) の作成 (概要)」 |
Solaris Live Upgrade では使用できない Solaris ボリュームマネージャーの複雑な構成に関する詳細 |
Solaris Live Upgrade では、Solaris ボリュームマネージャーのタスクの一部が管理されます。表 2–1 に、Solaris Live Upgrade で管理できる Solaris ボリュームマネージャーのコンポーネントを示します。
表 2–1 ボリュームクラス
用語 |
説明 |
---|---|
RAID-0 ボリューム。複数のスライスが連結された方式では、利用可能な最初のスライスがいっぱいになるまでそのスライスにデータが書き込まれます。そのスライスがいっぱいになると次のスライスに連続してデータが書き込まれます。ミラーに含まれている場合を除き、連結にはデータの冗長性はありません。 |
|
RAID-1 ボリューム。「RAID-1 ボリューム」を参照してください。 |
|
同じデータのコピーを複数保持しているボリューム。RAID-1 ボリュームはミラーと呼ばれることもあります。RAID-1 ボリュームは、サブミラーと呼ばれる 1 つまたは複数の RAID-0 ボリュームから構成されます。 |
|
ストライプ方式または連結方式のボリューム。これらはサブミラーとも呼ばれます。ストライプや連結は、ミラーを構築する基本構成ブロックです。 |
|
状態データベースでは、Solaris ボリュームマネージャー構成の状態に関する情報がディスクに保存されます。状態データベースは、複製された複数のデータベースコピーの集まりです。各コピーは「状態データベースの複製」と呼ばれます。状態データベースは、既知の状態データベースの複製の格納場所と状態をすべて記録しています。 |
|
状態データベースの複製 |
状態データベースのコピー。複製により、データベース内のデータの有効性が保証されます。 |
「RAID-0 ボリューム」を参照してください。 |
|
システムで単一の論理デバイスとして扱われる、物理スライスやボリュームの集まり。アプリケーションやファイルシステムから見ると、ボリュームは物理ディスクと同じように機能します。一部のコマンド行ユーティリティーでは、ボリュームはメタデバイスと呼ばれます。 |
次の例では、新しいブート環境の RAID-1 ボリュームを作成するためのコマンド構文を示します。
図 2–5 は、2 つの物理ディスク上に作成された RAID-1 ボリューム (ミラー) を持つ新しいブート環境を示しています。この新しいブート環境とミラーは、次のコマンドで作成されたものです。
# lucreate -n second_disk -m /:/dev/md/dsk/d30:mirror,ufs \ -m /:/dev/dsk/c0t1d0s0,/dev/md/dsk/d31:attach -m /:/dev/dsk/c0t2d0s0,/dev/md/dsk/d32:attach \ -m -:/dev/dsk/c0t1d0s1:swap -m -:/dev/dsk/c0t2d0s1:swap |
このコマンドは、次のような処理を実行します。
新しいブート環境 second_disk を作成する。
ミラー d30 を作成し、UFS ファイルシステムを構成する。
各物理ディスクのスライス 0 に単一デバイスの連結を作成する。これらの連結に d31 および d32 という名前を付ける。
これら 2 つの連結をミラー d30 に追加する。
ルート (/) ファイルシステムをミラーにコピーする。
各物理ディスクのスライス 1 に、スワップ用のファイルシステムを構成する。
図 2–6 は、RAID-1 ボリューム (ミラー) を持つ新しいブート環境を示しています。この新しいブート環境とミラーは、次のコマンドで作成されたものです。
# lucreate -n second_disk -m /:/dev/md/dsk/d20:ufs,mirror \ -m /:/dev/dsk/c0t1d0s0:detach,attach,preserve |
このコマンドは、次のような処理を実行します。
新しいブート環境 second_disk を作成する。
ミラー d10 を解除し、連結 d12 を切り離す。
連結 d12 の内容を保持する。ファイルシステムのコピーは行われない。
新しいミラー d20 を作成する。これで、d10 および d20 という 2 つの 1 面ミラーが作成される。
連結 d12 をミラー d20 に接続する。
ブート環境の作成が完了したら、そのブート環境をアップグレードできます。アップグレード作業の過程で、ブート環境の任意のファイルシステムに RAID-1 ボリューム (ミラー) を持たせることができます。あるいは、ブート環境に非大域ゾーンをインストールしておくこともできます。アップグレードを行なっても、アクティブなブート環境内のファイルには影響ありません。準備ができたところでこの新しいブート環境をアクティブにし、このブート環境を現行のブート環境とします。
Oracle Solaris 10 9/10 リリース以降、アップグレード処理は自動登録の影響を受けます。「Live Upgrade に対する自動登録の影響」を参照してください。
UFS ファイルシステムでのブート環境のアップグレード手順 | |
UFS ファイルシステムでの、RAID-1 ボリュームファイルシステムを持つブート環境のアップグレードの例 | |
UFS ファイルシステムの非大域ゾーンがある場合のアップグレード手順 | |
ZFS ファイルシステムのアップグレード、または ZFS ファイルシステムへの移行 |
図 2–7 に、非アクティブなブート環境のアップグレードの例を示します。
アップグレードする代わりに、Solaris フラッシュアーカイブをブート環境にインストールすることもできます。Solaris フラッシュインストール機能を使用すると、Solaris OS の単一の参照用インストールを 1 台のシステム上に作成できます。このシステムはマスターシステムと呼ばれます。続いて、クローンシステムと呼ばれる多数のシステム上にこのインストールを複製できます。この場合、非アクティブなブート環境はクローンシステムです。Solaris フラッシュアーカイブをシステムにインストールするとき、初期インストールの場合と同じように、アーカイブは既存のブート環境にあるすべてのファイルを置き換えます。
Solaris フラッシュアーカイブのインストール手順については、「ブート環境への Solaris フラッシュアーカイブのインストール」を参照してください。
次の図に、非アクティブなブート環境における Solaris フラッシュアーカイブのインストールを示します。図 2–8 は、1 台のハードディスクを持つシステムを示しています。図 2–9 は、2 台のハードディスクを持つシステムを示しています。
Oracle Solaris 10 9/10 リリース以降、アップグレード処理は自動登録の影響を受けます。
システムをインストールまたはアップグレードすると、システムの構成データは、既存のサービスタグ技術によってリブート時に自動的にオラクル製品登録システムに伝達されます。システムに関するこのサービスタグデータは、オラクルの顧客向けサポートとサービスの向上などに役立てられます。この同じ構成データを使用して、システム独自の目録を作成および管理することができま す。
自動登録の概要については、『Oracle Solaris 10 9/10 インストールガイド (インストールとアップグレードの計画)』の「Oracle Solaris 9 10/10 リリースにおけるインストールの新機能」を参照してください。
システムを明示的に、以前のリリースから Oracle Solaris 10 9/10 リリースまたはそれ以降のリリースにアップグレードしようとしている場合を除き、自動登録によって Live Upgrade の処理は変更されません。
Live Upgrade の以下の処理は、自動登録によっていずれも変更されません。
Solaris Flash アーカイブのインストール
パッチやパッケージの追加または削除
プロファイルのテスト
パッケージの整合性の確認
システムを以前のリリースから Oracle Solaris 10 9/10 リリースまたはそれ以降のリリースにアップグレードする場合のみ、自動登録の構成ファイルを作成する必要があります。そしてシステムをアップグレードするときには、luupgrade -u コマンドで -k オプションを使用して、この構成ファイルを指定する必要があります。そのための手順は次のとおりです。
以前のリリースから Oracle Solaris 10 9/10 リリースまたはそれ以降のリリースにアップグレードする場合のみ、この手順を使用して、必要とされる自動登録の情報をアップグレード中に提供します。
テキストエディタを使用して、サポート資格を記述した構成ファイルを作成します。必要に応じて、プロキシ情報も含めます。
このファイルは、キーワードと値のペアから成るリストの形式です。ファイルには、この形式で以下のキーワードと値を含めます。
http_proxy=Proxy-Server-Host-Name http_proxy_port=Proxy-Server-Port-Number http_proxy_user=HTTP-Proxy-User-Name http_proxy_pw=HTTP-Proxy-Password oracle_user=My-Oracle-Support-User-Name oracle_pw=My-Oracle-Support-Password |
以下の形式のルールに従ってください。
パスワードは暗号化テキストではなく、平文テキストにする必要があります。
キーワードの順序は重要ではありません。
値を指定しない場合は、キーワードを完全に省略できます。または、キーワードを保持して値を空白のままにすることもできます。
サポート資格を省略すると、登録は匿名になります。
入力したい値にはスペースを含める必要があることを除いては、構成ファイルの空白は問題になりません。http_proxy_user と http_proxy_pw の値のみ、値の中にスペースを含むことができます。
oracle_pw の値にスペースを含めてはいけません。
例を参照すること
http_proxy= webcache.central.example.COM http_proxy_port=8080 http_proxy_user=webuser http_proxy_pw=secret1 oracle_user=joe.smith@example.com oracle_pw=csdfl2442IJS |
ファイルを保存します。
そのアップグレードに必要な luupgrade コマンドのその他の標準オプションをすべて含めて、luupgrade -u -k /path/filename コマンドを実行します。
前の手順で説明した構成ファイルの内容を修正するか、ファイルを作成します。自動登録を無効にするには、この構成ファイルに次の行だけを含める必要があります。
autoreg=disable |
ファイルを保存します。
そのアップグレードに必要な luupgrade コマンドのその他の標準オプションをすべて含めて、luupgrade -u -k /path/filename コマンドを実行します。
省略可能: 次のようにすると、Live Upgrade が完了し、システムが再ブートするときに、自動登録機能が無効になっていることを確認できます。
# regadm status Solaris Auto-Registration is currently disabled |
新しいブート環境に切り替えてアクティブにする準備ができたら、新しいブート環境をすばやくアクティブにしてリブートします。新たに作成したブート環境を初めて起動するとき、ブート環境間でファイルの同期がとられます。ここでいう「同期」とは、いくつかのシステムファイルやディレクトリを、直前にアクティブだったブート環境から、ブート中のブート環境へコピーすることです。システムをリブートすると、非アクティブなブート環境にインストールした構成がアクティブになります。この時点で、元のブート環境は非アクティブブート環境となります。
ブート環境をアクティブにする手順 | |
アクティブなブート環境と非アクティブなブート環境の同期についての情報 |
図 2–10 に、リブート後に非アクティブなブート環境からアクティブなブート環境に切り替わる様子を示します。
問題が発生する場合は、アクティブ化とリブートを行なって元のブート環境にすぐにフォールバックできます。元のブート環境をバックアップして復元するよりも、フォールバックの方がはるかに時間がかかりません。ブートに失敗した新しいブート環境は保存されるので、障害を解析できます。フォールバックを実行できるのは、luactivate を使用して新しいブート環境をアクティブにしたブート環境だけです。
以前のブート環境に戻すには、次の手順に従います。
問題 |
動作 |
---|---|
新しいブート環境は正常にブートしたが、結果に満足できない。 |
luactivate コマンドに以前のブート環境の名前を指定して実行し、リブートします。 x86 のみ – Solaris 10 1/06 以降のリリースでは、GRUB メニューにある元のブート環境を選択して戻すことができます。元のブート環境と新しいブート環境は、GRUB ソフトウェアに基づいている必要があります。GRUB メニューからブートすると、古いブート環境と新しいブート環境の間でファイルは同期されません。ファイルの同期の詳細については、「ブート環境間での強制的な同期」を参照してください。 |
新しいブート環境がブートしない。 |
戻すブート環境をシングルユーザーモードでブートし、luactivate コマンドを実行し、リブートします。 |
シングルユーザーモードでブートできない。 |
次のいずれかの操作を実行します。
|
フォールバックの手順については、第 6 章障害回復: 元のブート環境へのフォールバック (作業)を参照してください。
図 2–11 に、リブートして戻したときにブート環境が切り替わる様子を示します。
ブート環境のステータス確認、名前変更、削除など、さまざまな保守作業も行うことができます。保守作業の手順については、第 7 章Solaris Live Upgrade ブート環境の管理 (作業)を参照してください。