| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 10 8/11 インストールガイド (Solaris Live Upgrade とアップグレードの計画) Oracle Solaris 10 8/11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 10 8/11 インストールガイド (Solaris Live Upgrade とアップグレードの計画) Oracle Solaris 10 8/11 Information Library (日本語) |
パート I Solaris Live Upgrade によるアップグレード
RAID-1 ボリュームファイルシステムを持つブート環境の作成
Solaris Live Upgrade でボリュームを管理する方法
Solaris ボリュームマネージャーのタスクと Solaris Live Upgrade の対応
4. Solaris Live Upgrade によるブート環境の作成 (作業)
5. Solaris Live Upgrade によるアップグレード (作業)
6. 障害回復: 元のブート環境へのフォールバック (作業)
7. Solaris Live Upgrade ブート環境の管理 (作業)
8. 非大域ゾーンがインストールされているシステムにおける Oracle Solaris OS のアップグレード
10. Solaris Live Upgrade (コマンドリファレンス)
パート II Solaris Live Upgrade を使った ZFS ルートプールのアップグレードと ZFS ルートプールへの移行
11. Solaris Live Upgrade と ZFS (概要)
12. ZFS の Solaris Live Upgrade (計画)
次に、現在のブート環境のコピーを作成してそのコピーをアップグレードし、アクティブなブート環境になるように切り替える作業の概要を示します。元のブート環境に切り替えるフォールバックの手順についても説明します。図 2-1 に、この Solaris Live Upgrade 処理の全体を示します。
図 2-1 Solaris Live Upgrade の実行手順
次の節で、Solaris Live Upgrade の実行手順について説明します。
物理スライスまたは論理ボリューム上での新しいブート環境の作成
ブート環境を作成すると、クリティカルファイルシステムをアクティブなブート環境から新しいブート環境にコピーできます。必要であれば、ディスクを編成し直して、ファイルシステムをカスタマイズし、クリティカルファイルシステムを新しいブート環境にコピーします。
Solaris Live Upgrade では、次の 2 種類のファイルシステムを区別します。 クリティカルファイルシステムと共有可能ファイルシステムです。次の表に、これらのファイルシステムのタイプを示します。
|
Solaris Live Upgrade では、ファイルシステム上に RAID-1 ボリューム (ミラー) を持つブート環境を作成できます。概要については、「RAID-1 ボリュームファイルシステムを持つブート環境の作成」を参照してください。
新しいブート環境を作成するには、まず、クリティカルファイルシステムをコピーできる未使用のスライスが存在することを確認します。スライスが使用できないかあるいは最小限の要件を満たしていない場合は、新しいスライスをフォーマットする必要があります。
スライスを定義した後、ファイルシステムをディレクトリにコピーする前に、新しいブート環境上のファイルシステムを再構成できます。ファイルシステムを分割およびマージすることによってvfstab を簡単に編集でき、ファイルシステムを再構成することができます。ファイルシステムは、同じマウントポイントを指定して親ディレクトリにマージすることも、異なるマウントポイントを指定して親ディレクトリから分割することも可能です。
非アクティブブート環境でファイルシステムを構成した後、自動コピーを開始します。クリティカルファイルシステムは、指定された宛先ディレクトリにコピーされます。共有可能なファイルシステムは (それらの一部をコピーするように指定しない限り)、コピーされずに共有されます。ファイルシステムをアクティブなブート環境から非アクティブなブート環境にコピーする時、ファイルは新しいディレクトリにコピーされるので、アクティブなブート環境は変更されません。
|
UFS ファイルシステムでは、次の図で示すように新規ブート環境がさまざまな方法で作成されます。
ZFS ファイルシステムの場合については、第 11 章Solaris Live Upgrade と ZFS (概要)を参照してください。
図 2-2 に、クリティカルファイルシステムのルート(/) をディスク上の別のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境は、既存のスライス上にルート (/) ファイルシステムを持っています。新しいブート環境は、新しいスライス上にルート (/) ファイルシステムとまったく同じ複製を持ちます。/swap ボリュームと /export/home ファイルシステムは、アクティブなブート環境と非アクティブなブート環境で共有されます。
図 2-2 非アクティブなブート環境の作成 - ルート (/) ファイルシステムのコピー
図 2-3 に、クリティカルファイルシステムを分割し、ディスク上の複数のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境は、既存のスライス上にルート (/) ファイルシステムを持っています。このスライスでは、ルート (/) ファイルシステム内に、/usr、/var、および /opt ディレクトリがあります。新しいブート環境では、ルート (/) ファイルシステムは分割され、/usr と /opt は別のスライスに配置されています。/swap ボリュームと /export/home ファイルシステムは、両方のブート環境で共有されます。
図 2-3 非アクティブなブート環境の作成 - ファイルシステムの分割
図 2-4 に、クリティカルファイルシステムをマージし、ディスク上の複数のスライスにコピーして、新しいブート環境を作成する方法を示します。アクティブなブート環境には、ルート (/) ファイルシステム、/usr、/var、/opt があり、各ファイルシステムは別々のスライス上に配置されています。新しいブート環境では、/usr と /opt はルート (/) ファイルシステムと同一のスライス上にマージされます。/swap ボリュームと /export/home ファイルシステムは、両方のブート環境で共有されます。
図 2-4 非アクティブなブート環境の作成 - ファイルシステムのマージ
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 ファイルシステムが作成されます。
|
Solaris Live Upgrade では、Solaris ボリュームマネージャーのタスクの一部が管理されます。表 2-1 に、Solaris Live Upgrade で管理できる Solaris ボリュームマネージャーのコンポーネントを示します。
表 2-1 ボリュームクラス
|
次の例では、新しいブート環境の 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-5 ブート環境の作成とミラーの作成
図 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 に接続します。
図 2-6 ブート環境の作成と既存のサブミラーの使用
ブート環境の作成が完了したら、そのブート環境をアップグレードできます。アップグレード作業の過程で、ブート環境の任意のファイルシステムに RAID-1 ボリューム (ミラー) を持たせることができます。あるいは、ブート環境に非大域ゾーンをインストールしておくこともできます。アップグレードを行なっても、アクティブなブート環境内のファイルには影響ありません。準備ができたところでこの新しいブート環境をアクティブにし、このブート環境を現行のブート環境とします。
|
図 2-7 に、非アクティブなブート環境のアップグレードの例を示します。
図 2-7 非アクティブなブート環境のアップグレード
アップグレードする代わりに、Solaris フラッシュアーカイブをブート環境にインストールすることもできます。Solaris フラッシュインストール機能を使用すると、Oracle Solaris OS の単一の参照用インストールを 1 台のシステム上に作成できます。このシステムはマスターシステムと呼ばれます。続いて、クローンシステムと呼ばれる多数のシステム上にこのインストールを複製できます。この場合、非アクティブなブート環境はクローンシステムです。Solaris フラッシュアーカイブをシステムにインストールするとき、初期インストールの場合と同じように、アーカイブは既存のブート環境にあるすべてのファイルを置き換えます。
Solaris フラッシュアーカイブのインストール手順については、「ブート環境への Solaris フラッシュアーカイブのインストール」を参照してください。
次の図に、非アクティブなブート環境における Solaris フラッシュアーカイブのインストールを示します。図 2-8 は、1 台のハードディスクを持つシステムを示しています。図 2-9 は、2 台のハードディスクを持つシステムを示しています。
図 2-8 Solaris フラッシュアーカイブのインストール - ハードディスク 1 台
図 2-9 Solaris フラッシュアーカイブのインストール - ハードディスク 2 台
Oracle Solaris 10 9/10 リリース以降、アップグレード処理は自動登録の影響を受けます。
システムをインストールまたはアップグレードすると、システムの構成データは、既存のサービスタグ技術によってリブート時に自動的にオラクル製品登録システムに伝達されます。システムに関するこのサービスタグデータは、オラクルの顧客向けサポートとサービスの向上などに役立てられます。この同じ構成データを使用して、システム独自の目録を作成および管理することができま す。
自動登録の概要については、『Oracle Solaris 10 8/11 インストールガイド (インストールとアップグレードの計画)』の「Oracle Solaris 10 9/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
autoreg=disable
# regadm status
Solaris Auto-Registration is currently disabled新しいブート環境に切り替えてアクティブにする準備ができたら、新しいブート環境をすばやくアクティブにしてリブートします。新たに作成したブート環境を初めて起動するとき、ブート環境間でファイルの同期がとられます。ここでいう「同期」とは、いくつかのシステムファイルやディレクトリを、直前にアクティブだったブート環境から、ブート中のブート環境へコピーすることです。システムをリブートすると、非アクティブなブート環境にインストールした構成がアクティブになります。この時点で、元のブート環境は非アクティブブート環境となります。
|
図 2-10 に、リブート後に非アクティブなブート環境からアクティブなブート環境に切り替わる様子を示します。
図 2-10 非アクティブなブート環境のアクティブ化
問題が発生する場合は、アクティブ化とリブートを行なって元のブート環境にすぐにフォールバックできます。元のブート環境をバックアップして復元するよりも、フォールバックの方がはるかに時間がかかりません。ブートに失敗した新しいブート環境は保存されるので、障害を解析できます。フォールバックを実行できるのは、luactivate を使用して新しいブート環境をアクティブにしたブート環境だけです。
以前のブート環境に戻すには、次の手順に従います。
|
フォールバックの手順については、第 6 章障害回復: 元のブート環境へのフォールバック (作業)を参照してください。
図 2-11 に、リブートして戻したときにブート環境が切り替わる様子を示します。
図 2-11 元のブート環境へのフォールバック
ブート環境のステータス確認、名前変更、削除など、さまざまな保守作業も行うことができます。保守作業の手順については、第 7 章Solaris Live Upgrade ブート環境の管理 (作業)を参照してください。
|