(57)【要約】  ＵＮＩＸ（登録商標）システムにパッチを適用するために、並びにパッチの問題の場合にシステムへの変更がロール・バックされるのを許容するために必要とされるダウンタイムを減少するためのコンピュータ・ユティリティ。
2008511910.tif 000002
【特許請求の範囲】
【請求項１】
システム保守の間にコンピュータ・システムのダウンタイムを減少する方法であって、
システム保守が二次ブート・ディスク上で行われている間に一次ブート・ディスク上で動作環境を実行するステップと、ここに、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、
バックアップ・ブート環境として一次ブート・ディスクを維持しつつ、二次ブート・ディスクを再ブートするステップと、
を含む方法。
【請求項２】
システム保守の間にコンピュータ・システムのダウンタイムを減少する方法であって、
一次ブート・ディスクから二次ブート・ディスクに動作環境をコピーするステップと、
システム保守が一次ブート・ディスク上で行われている間に二次ブート・ディスク上で動作環境を実行するステップと、ここに、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、
バックアップ・ブート環境として二次ブート・ディスクを維持しつつ、一次ブート・ディスクを再ブートするステップと、
を含む方法。
【請求項３】
二次ブート・ディスクにミラー化される一次ブート・ディスクを含むコンピュータ・システムのダウンタイムを、システム保守の間に減少する方法であって、
一次ブート・ディスク及び二次ブート・ディスク間のミラーを破断するステップと、
システム保守が二次ブート・ディスク上で行われている間に一次ブート・ディスク上で動作環境を実行するステップと、ここに、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、
バックアップ・ブート環境として一次ブート・ディスクを維持しつつ、二次ブート・ディスクを再ブートするステップと、
を含む方法。
【請求項４】
ミラーを再創設するステップをさらに含む請求項３に記載の方法。
【請求項５】
コンピュータ・システムにおけるシステムグレードを容易にするためにブート・ディスク・ユティリティ方法であって、コンピュータ・システムは、ルート・ディスク・グループと、カプセル化されかつオリジナル・ブート環境及びブート・ブロックを含む一次ブート・ディスクと、カプセル化された二次ブート・ディスクとを備え、一次ブート・ディスクは、二次ブート・ディスクにミラー化されて、ディスク・メディア・レコードを有し、ブート・ディスク・ユティリティ方法は、
二次ブート・ディスク上でブート可能なブート環境を作成するステップと、
二次ブート・ディスクのブート環境をマウントするステップと、
二次ブート・ディスクのブート環境上でシステム保守を行うステップと、ここに、システム保守はシステムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、
二次ブート・ディスクのブート環境をアンマウントするステップと、
二次ブート・ディスク上でブート環境をブートするステップと、
一次ブート・ディスクのオリジナル・ブート環境を削除するステップと、
ルート・ディスク・グループの部分として一次ブート・ディスクを指定するステップと、
一次ブート・ディスクを再命名するステップと、
二次ブート・ディスクを一次ブート・ディスクにミラー化するステップと、
を含む方法。
【請求項６】
一次ブート・ディスクと、
二次ブート・ディスクと、
を備えたコンピュータ・システムであって、二次ブート・ディスク上でシステム保守が行われている間に一次ブート・ディスク上でオペレーティング・システムが実行され、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、バックアップ・ブート環境として一次ブート・ディスクが維持されている間に、システムが二次ブート・ディスクに再ブートされるコンピュータ・システム。
【請求項７】
一次ブート・ディスクと、
二次ブート・ディスクと、
を備えたコンピュータ・システムであって、一次ブート・ディスクから二次ブート・ディスクへ動作環境がコピーされ、一次ブート・ディスク上でシステム保守が行われている間に二次ブート・ディスク上で動作環境が実行され、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、バックアップ・ブート環境として二次ブート・ディスクが維持されている間にシステムが一次ブート・ディスクに再ブートされるコンピュータ・システム。
【請求項８】
一次ブート・ディスクと、
二次ブート・ディスクと、
を備えたコンピュータ・システムであって、一次ブート・ディスクは二次ブート・ディスクにミラー化され、一次ブート・ディスク及び二次ブート・ディスク間でミラーが破断され、二次ブート・ディスク上でシステム保守が行われている間に一次ブート・ディスク上で動作環境が実行され、バックアップ・ブート環境として一次ブート・ディスクが維持されている間に、システムが二次ブート・ディスクに再ブートされ、ここに、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含むコンピュータ・システム。
【請求項９】
二次ブート・ディスクは、システムが二次ブート・ディスクに再ブートされた後に、一次ブート・ディスクにミラー化される請求項８に記載のコンピュータ・システム。
【請求項１０】
ルート・ディスク・グループと、
オリジナル・ブート環境、ディスク・メディア・レコード、及びブート・ブロックを備えるカプセル化された一次ブート・ディスクと、
カプセル化された二次ブート・ディスクと、
を備えたコンピュータ・システムであって、ブート可能なブート環境が、二次ブート・ディスク上に作成され、二次ブート・ディスクのブート環境がマウントされ、システム保守が二次ブート・ディスクのブート環境上で行われ、ここに、システム保守は、システムに適用されるべき１つまたは複数のパッチを識別することと、アプリケーションのためのパッチを待ち行列に入れることと、パッチを適用することとを含み、二次ブート・ディスクのブート環境がアンマウントされ、二次ブート・ディスク上のブート環境が再ブートされ、オリジナル・ブート環境が一次ブート・ディスクから削除され、一次ブート・ディスクがルート・ディスク・グループの部分として指定され、一次ブート・ディスクが再命名され、そして、二次ブート・ディスクが一次ブート・ディスクにミラー化されるコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本件出願は、２００４年８月３０日に提出された米国仮特許出願第６０／６０５，５７７号の恩恵を主張するものであり、その全体はここに参照により組み込まれるものとする。
【０００２】
技術分野
本発明は、ブート・ディスク管理のユティリティに関するものである。
【背景技術】
【０００３】
多くの重要なＵＮＩＸ（登録商標）システムは、最も高い利用可能性の要件を有している。これらのシステムは、既知の問題に起因する内在的なサービスの停止期間を最小にするために、オペレーティング・システムに対する現在のレベルに絶え間なくパッチされるという要件を有している。パッチは、しばしば毎日リリースされている。不運にも、これらの２つの要件は両立しない。パッチングは、ダウンタイム、しばしば過度のダウンタイムをもたらす。現在のパッチングの技術状態は、また、パッチ除去プロセスにおける弱さを有しており、再度、それを許容することができないシステム上に一層のダウンタイムをもたらす。
【０００４】
パッチを適用するために必要とされるダウンタイムを除去することは理想的であるが、しかし、根元的なＵＮＩＸ（登録商標）に基づくオペレーティング・システムの性質に起因して除去することができないものであり、また、多くのパッチがリブートのためのダウンタイムを必要とするという事実に起因しても除去することができないものである。この最も侵入的な動作のために必要とされるブート時間を単純化するようダウンタイムを最小とする必要性がある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、従来技術に存在するこの必要性を取り扱うものである。
【課題を解決するための手段】
【０００６】
本発明は、システム保守の間にコンピュータ・システムのダウンタイムを減少するための方法及びシステムに向けられている。動作環境は、一次ブート・ディスク上で実行され、他方、システム保守は、二次ブート・ディスク上で行われる。このシステム保守は、システムに適用されるべきパッチを識別し、適用されるべき該パッチを待ち行列に入れ、そして、パッチを適用することを含む。リブートは、二次ブート・ディスクに対して行われ、他方、一次ブート・ディスクは、バックアップ・ブート環境として維持される。任意選択的には、一次ブート・ディスクは、最初に、二次ブート・ディスクにミラー化され得るか、または、動作環境が、最初に、二次ブート・ディスクから一次ブート・ディスクにコピーされ得る。
【発明を実施するための最良の形態】
【０００７】
さて、本発明の好適な実施形態を詳細に参照し、その例が添付図面に示されている。ここに含まれている本発明の図面と説明は、本発明に特に関連している素子を示しかつ説明するものであるが、明瞭さのために他の素子は除去されているということを理解すべきである。当業者は、他の素子が本発明を履行するために望ましい及び／または必要とされ得るということを認識するであろう。しかしながら、このような素子は技術分野において良く知られており、それらが本発明の良好な理解を容易にしないので、このような素子の説明はここでは提供されていない。
【０００８】
ここに説明される本発明は、ユーザが、保守動作に起因するダウンタイムを減少するのを許容する。ただ１つのブート・ディスクだけが最初にインストールされたパッチを有しているので、変更は二次ブート・ディスクにロール・バックされ（rolled back）得る。本発明は、また、システムが、アプリケーションのために待ち行列化されている該システムに適用可能なパッチだけで調査されるのを許容する。パッチは、次に、活きている（ライブの）オペレーティング・システムのブート・ディスクではなく、むしろ、ブート環境（“ＢＥ”）に適用される。本発明は、さらに、システムが余分のローカル・ディスクを有しているのと同じ位多くのＢＥを、ユーザが創成しかつ保持するのを許容する。
【０００９】
ここに説明される本発明は、ＵＮＩＸ（登録商標）システムにパッチを適用するために必要とされるダウンタイムを除去することに関する。ここに説明される実施形態は、特に、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ  Ｓｏｌａｒｉｓ／Ｖｅｒｉｔａｓ環境に適用されるが、本発明は、ここに説明されるコマンドに関する適切な変形を用いてＵＮＩＸ（登録商標）システムのすべての変形例に等しく適用され得る。このような変形は、当業者に既知であるであろう。
【００１０】
ここに説明される本発明の例示的な実施形態は、以下の必要条件（前提条件）を満足するシステムとの関連で動作する：
１．  ＵＮＩＸ（登録商標）のＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ  Ｓｏｌａｒｉｓ２．６，７，８、または９バージョン。
２．  Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ３．１、３．１．１、３．２、または３．５。
３．  システムのブート・ディスクは、Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ制御下になければならない。（すなわち、ブート・ディスクは、カプセル化されていなければならない。
４．  現存するブート・ディスクの複製を創成するために用いられる未使用の直接付属ディスク。
５．  ユティリティを用いるシステムが、パッチ収納場所へのアクセスを有さなければならず、そして、ＮＦＳ、ＨＴＴＰ、等を介してどのパッチがシステムに適用され得るかを決定するために必要とされる何等かのメタデータへのアクセスを有さなければならない。
６．  システムは、Ｐｅｒｌ５．６．１またはその後のものへのアクセスを有さなければならない。
これが、本発明のユティリティがシステム上で用いられている最初であるならば、最初のＢＥを創成するための手順は引き続くＢＥを創成するための手順よりもわずかに異なっている。この説明は、該プロセスの概略を述べており、そして、新しいＢＥの適切な作用が確認されると、オリジナル・ブート・ディスクがいつ及びいかにしてリサイクルされるべきであるかを論じている。ＢＥディスクに対する概念及び要件は以下で一層詳細に説明される。
【００１１】
図１ａは、本発明の実施形態に対する共通の最初のブート・ディスク構成を示す。一次ブート・ディスク１００は、ルートディスク（rootdisk）として知られ、それに反して、二次ブート・ディスク１０１は、ｄｉｓｋ０１として知られる。ＯｐｅｎＢｏｏｔ  ＰＲＯＭは、ディスク１００または１０１のいずれかにユーザがブートするのを許容するための、及び最初の一方のものへのブーティングが失敗した場合に他方のディスクにブートするためのエイリアス（aliases：別名）を有するシステムに依存して構成され得る。多くのシステムは以下の定義を有する：
【数１】
2008511910.tif 000003
【００１２】
この例に対しては、ブート・ディスク１０１及び１０２は、ユティリティで用いられ得る利用可能な２つのディスクだけであるということが仮定される。従って、ディスクの一方は自由に（空いた状態に）されなければならない。この場合において、ｄｉｓｋ０１が自由に（空いた状態に）され、このことは以下のステップを伴う：
●  ブート・ディスク１０１上にあるＶｘＶＭプレックス（plexes）（ミラー）を削除し、従って、ブート・ディスク１００とブート・ディスク１０１の間の関連を破断する。
●  ｄｉｓｋ０１に対するＶｘＶＭディスク媒体記録を削除し、従って、他の使用に対してそれを自由にする（空いた状態にする）。
●  ｄｉｓｋ０１に対するＯＢＰエイリアス（alias）を削除し、それをブート装置リストから除去する。ｖｘｅｅｐｒｏｍ  ｄｅｖｕｎａｌｉａｓ  ．．．ＡＮＤ  ｅｅｐｒｏｍ  ｂｏｏｔ−ｄｅｖｉｃｅ＝”．．．“を用いる。
【００１３】
これらのステップを達成する手順は以下の通りである：
●  ブート・ディスク・ミラーとして用いられるディスクの名称を得るためのｖｘｐｒｉｎｔ、並びにブート・ディスクからミラー化される各ボリュームのためのミラー・プレックスを用いる。以下の例においては、以下に注意：
１．  ｒｏｏｔｄｉｓｋは一次ブート・ディスクであり、装置ｃ０ｔ０ｄ０ｓ２上にある。ｄｉｓｋ０１（システムがすべてこの名称を用いているわけではない）はミラー・ブート・ディスクであり、装置ｃ０ｔ１ｄ０ｓ２上にある。
２．  ｖｘｐｒｉｎｔコマンドに−ｈｔオプションを用いることは各Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅの階層的プリントアウトを生成する：各Ｖｏｌｕｍｅ（ｖでスタートするライン）は、１つまたは複数のＰｌｅｘｅｓ（ｐｌで始まるライン）から構成され、その各々は、ボリュームの全内容のコピーを含む。各Ｐｌｅｘは１つまたは複数のＳｕｂｄｉｓｋｓ（ｓｄで始まるライン）で構成される。
３．  ｒｏｏｔｄｇディスク・グループにおけるボリュームの各々は、第２のプレックス（plex）すなわちミラーを有し、そのＳｕｂｄｉｓｋはｄｉｓｋ０１上に配置される。これらのプレックスの各々は、再帰的に除去されなければならず、従って、それらのＳｕｂｄｉｓｋが常駐（もしくは駐在）するディスクは、除去され得る。
【数２】
2008511910.tif 000004
【００１４】
●  各ボリュームのミラー・プレックスを除去する。この場合において、除去するためのプレックスは上に強調される：ｒｏｏｔｖｏｌ−０２、ｓｗａｐｖｏｌ−０２、ｖａｒ−０２、及び０−０２。以下のコマンドも各プレックスに含まれるサブディスクを除去する。
【数３】
2008511910.tif 000005
【００１５】
●  ｒｏｏｔｄｇディスク・グループからミラー・ディスク１０１（ｄｉｓｋ０１）を除去する。これは、ＢＥとしての使用のためにこのディスクを自由に（空いた状態に）する。
【数４】
2008511910.tif 000006
【００１６】
●  ディスクｖｘｄｉｓｋ０１のためのエイリアス（alias）を除去する。
【数５】
2008511910.tif 000007
【００１７】
●  もしそれがそこにあるならば、ＯｐｅｎＢｏｏｔ  ＰＲＯＭのブート装置リストからｖｘ−ｄｉｓｋ０１のエイリアスを除去する。
【数６】
2008511910.tif 000008
【００１８】
図１ｂは、これらの動作を取ることの結果を示す。この点において、ＢＥは、ｂｅ−ｃｒｅａｔｅコマンドを用いて未使用ディスク１０１（このディスクのための装置名はｃ０ｔ１ｄ０ｓ２である）上に創成され得る。この例において、ＢＥは名称ｖｍｕｐｇｒａｄｅを与えられる：
【数７】
2008511910.tif 000009
【００１９】
ユティリティがこのホスト上で実行されている最初のときがこれであるということを検出するようシステムが構成され得、そして、“ｏｒｉｇ”と名前が付けられたオリジナル・ブート・ディスク１００のための特別のＢＥ構成記録をシステムが創成し得る。このことは、単純にプレースホルダであり、オリジナル・ブート・ディスクに対して他のどんな変更も必要とされない。システムは、また、ＯＢＰセッティングへの変更を行い得て、それらをオリジナル・ディスクの新しいＢＥ名と一致させ得る。このステップも、手動で行われ得る。
【００２０】
ｂｅ＿ｃｒｅａｔｅプログラムは、ユーザにステータスを与える出力を生成し得、そして、／ｖａｒ／ｌｏｇ／ＢＥ．ｌｏｇの中に一層詳細な情報をログし得る。結果のＢＥは、また、創成手順の部分としてブート可能であり得る。
【００２１】
これらの動作の結果は図１ｃに示されている。新しいＢＥのためのＯＢＰエイリアスは、
【数８】
2008511910.tif 000010
である。
【００２２】
この点において、新しいＢＥがマウントされ得（ａｔ／．ｌｂｂｅ．ｖｍｕｐｇｒａｄｅ／）、システムが新しいＢＥにブートされたときに見られるであろう変更がそれに対して行われ得る。ＢＥは、以下のコマンドでマウントされ得る：
【数９】
2008511910.tif 000011
【００２３】
この点において、新しいＢＥ上に保守が行われ得、これにより、ディスク１０１が非アクティブであり、他方、ブート・ディスク１００が現在アクティブであるので安全である。種々のユティリティ・スクリプトによって変更が取り扱われ得、これらのスクリプトは、リリースからリリースへ変化するそれら自体のドキュメンテーションを有する。所望の変更が行われてしまうと、ＢＥはそれにブートすることを試みる前に、アンマウントされなければならない：
【数１０】
2008511910.tif 000012
【００２４】
システムは、今や、ユーザの都合の良いときに新しいＢＥにブートされ得る：
【数１１】
2008511910.tif 000013
【００２５】
システムに依存して、矢継ぎ早に２度リブートすることが必要とされ得る。このことは、また、変更手順において文書化され得、アップグレードのスクリプト出力の部分として現出し得る。これは、新しいＶｘＶＭプロダクトのインストールが、不能化されたＶｏｌｕｍｅ  Ｍａｎａｇｅｒで生ずるために最初のリブートを必要とするからであり、その理由は、全体的にＶｘＶＭ装置が、新しいＶｏｌｕｍｅ  Ｍａｎａｇｅｒで来る新しいロード可能なカーネル・モジュール（Kernel modules）によって創成されなければならないからである。このブートのすぐ直後に、Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒは再可能化され得、そして、再度リブートされ得る。システムが戻った（comes back up）とき、Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒは、再度アクティブとなる。このことは、上述の“リブート”コマンドが以下となるように拡張する：
【数１２】
2008511910.tif 000014
＜システムがリブートしてルートとしてログインするのを待機する＞
【数１３】
2008511910.tif 000015
＜システムは可能化されたＶｏｌｕｍｅ  Ｍａｎａｇｅｒでリブートするであろう＞
これらの動作を取ることの結果は、図１ｄに示されている。
【００２６】
さて、システムは新しいＢＥ上で実行しており、そして、オリジナルのＢＥは非アクティブである。しかしながら、これを維持するために、ＯｐｅｎＢｏｏｔ  ＰＲＯＭセッティングに対して手動の変更が必要とされる。この点において、ＯＢＰのエイリアスが双方のディスクに対して存在するが、ディスクの一方だけが、ＯＢＰセッティングに対する手動の変更が行われるまでオリジナル・ディスクから自動的にブートされているであろう。好適な実施形態においては、このセットアップは意図的であり、その理由は、新しいＢＥが任意の与えられたシステム上で適切に動作し得ないという機会が常にあるからであり、そして、それが適切にブートするということが確実にされ得るまで、新しいＢＥまで明白にブートすることを必要とすることが好ましい。この点において、ＯＢＰブートセッティングは以下のように見えるはずである：
【数１４】
2008511910.tif 000016
【００２７】
ｖｘ−ｒｏｏｔｍｉｒｒｏｒが一層容易に破壊されたので、それは除去され得る。また、デフォルトにより新しいＢＥにブートすることを望んでいるユーザは、以下のようなコマンドを有するＯＢＰブート装置セッティングの前部にそのエイリアス（ｖｘ−ｖｍｕｐｇｒａｄｅ）を追加することを必要とするであろう：
【数１５】
2008511910.tif 000017
【００２８】
この点において、標準の再ブート、ｉｎｉｔ  ６、または他のシステム再スタート・コマンドが発生したとき、システムは新しいＢＥディスクにブートすることを試み；これが失敗したならば、オリジナル・ブート・ディスクが用いられるであろう。
【００２９】
好適な実施形態においては、新しいＢＥのミラーとして使用されるべきオリジナル・ブート・ディスクをリサイクリングする前に、少なくとも数日間この方法でシステムを実行することが代表的である。これを行うための理由は以下の通りである：
【００３０】
●  新しいＢＥは、幾つかの理由で、システムにとって適切でないかも知れず、例えば、新しいＢＥにおいてパッチされ（patched）ていたシステムにおける古いバグに依存している古いアプリケーション、通常でないハードウェア構成が新しいＢＥ、等上の変換と共に良く動作しないかも知れない。これらの問題は、それら自体を直ちにすなわち数日間も無く提起し得る。もし、オリジナルＢＥがすぐに破壊されるならば、変化及び試みを再度ロール・バックする機会が失われる。
【００３１】
●  ディスクの故障が新しいＢＥ上に生じたとしても、ＯＢＰに対して行われる変化は、それがオリジナル・ディスクに対してブート・バックされることを確実にし、保守が他のディスク上で行われている間に、少なくともアップして実行するであろう。この種の問題にさらされている状態は、オリジナル・ブート・ディスクが維持されている時間の量に制限されるであろう。
【００３２】
新しいＢＥの安定性が確認されると、オリジナル・ブート・ディスク１００は、それが新しいＢＥに対するミラーとして用いられ得るようにリサイクルされ得る。このことは、オリジナル・ブート・ディスク１００の周りに特別に創成されていた“ｏｒｉｇ”ＢＥを削除することを必要とする。オリジナル・ブート・ディスクへの参照のすべては、ＯＢＰから削除されなければならない。このことを１つのコマンドで行うことが可能であるけれども、この例に対しては、以下のステップが用いられるであろう：
【数１６】
2008511910.tif 000018
＜ＯＢＰのエイリアスｖｘ−ｒｏｏｔｄｉｓｋ  ｉｎ／ｔｍｐ／ｒｅｃｙｃｌｅｄ−ｄｅｖｉｃｅによって指し示された装置のコピーをセーブする＞
【数１７】
2008511910.tif 000019
【００３３】
これらのコマンドを実行することの結果が図１ｅに示されている。システムは、今や、ＯＢＰのエイリアスｖｘ−ｖｍｕｐｇｒａｄｅでディスク１０１までブートすることだけができる。
【００３４】
オリジナル・ブート・ディスク１００は、今や、リサイクリングのために準備している。この例においては、標準のＶｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ技術が、他の動作を実行するために用いられ、それは、図１ｆに示されている：
【００３５】
●  ｒｏｏｔｄｇ  ｄｉｓｋ  ｇｒｏｕｐの部分としてリサイクルされているディスクをセットアップし、そして、それにｄｉｓｋ０１の名前を付ける。
【００３６】
●  ｄｉｓｋ０１にｖｍｕｐｇｒａｄｅを命名されたディスク１０１上にボリュームの各々をミラー化する。
【００３７】
●  早期に／ｔｍｐ／ｒｅｃｙｃｌｅｄ−ｄｅｖｉｃｅの中に保存されたｄｉｓｋ０１上にブート・ブロックのためのＯＢＰエイリアスを創成する：
【数１８】
2008511910.tif 000020
【００３８】
●  ディスクのいずれかからのブーティングを許容するためにＯＢＰブート装置セッティングをセットアップする：
【数１９】
2008511910.tif 000021
【００３９】
これらのコマンドの最終結果、すなわち、手動または自動のいずれかでブートするために全ＯＢＰ支援を有する完全ミラー化された冗長ブート・ディスクが、図１ｇに示されている。
【００４０】
今や、システム上の引き続くＢＥ創成が考慮されるであろう。最後の例の終りにおいて、ブート・ディスク・ミラーの状態は、図１ｈに表示されている。新しいＢＥは、例示的な生成パッチを適用するために創成され、これは、ここではｐａｔｃｈ０９０３と称する。これらはシステムにおいて利用可能な２つだけのディスクであるということも仮定されている。従って、これらのディスクの一方は、新しいＢＥとしての使用のために自由に（空き状態に）されなければならない。この場合においては、ｄｉｓｋ０１が自由に（空き状態に）され、以下のステップを必要とする：
【００４１】
●  ｄｉｓｋ０１上に常駐するＶｘＸＭ  プレックス（ミラー）削除し、従って、ｒｏｏｔｄｉｓｋとｄｉｓｋ０１との間の関連性を破壊する。
【００４２】
●  ｄｉｓｋ０１に対するＶｘＶＭディスク・メディア記録を削除し、従って、それを他の使用のために自由にする。
【００４３】
●  ｄｉｓｋ０１のためのＯＢＰエイリアスを削除し、それをブート装置リストから除去する。
【数２０】
2008511910.tif 000022
を使用する。
【００４４】
これらのステップを達成する手順は以下の通りである：
●  ブート・ディスク・ミラーとして用いられるディスクの名称、並びにブート・ディスクからミラー化される各ボリュームのためのミラー・プレックスを得るために、ｖｘｐｒｉｎｔを用いる。以下の例においては、以下を注意されたし：
【００４５】
１．  ｖｍｕｐｇｒａｄｅは一次ブート・ディスクであり、最後の例が完了した後、装置ｃ０ｔ１ｄ０ｓ２上にある。ｄｉｓｋ０１は、ミラー・ブート・ディスクであり、装置ｃ０ｔ０ｄ０ｓ２上にある。
【００４６】
２．  ｖｘｐｒｉｎｔコマンドへの−ｈｔオプションを用いることは、各Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅの階層的プリントアウトを生成する：各Ｖｏｌｕｍｅ（ｖで始まるライン）、は１つまたは複数のＰｌｅｘｅｓ（ｐ１で始まるライン）から構成され、その各々は、ボリュームの全内容のコピーを含んでいる。各Ｐｌｅｘは１つまたは複数のＳｕｂｄｉｓｋ（ｓｄで始まるライン）で構成される。
【００４７】
３．  ｒｏｏｔｄｇディスク・グループにおけるボリュームの各々は、第２のプレックスまたはミラーを有し、そのサブディスクは、ｄｉｓｋ０１ディスク上に位置している。これらのプレックスの各々は、再帰的に除去されなければならず、それ故、サブディスクが常駐（駐在）しているディスクは除去され得る。
【００４８】
【数２１】
2008511910.tif 000023
【００４９】
●  各ボリュームのミラー・プレックスを除去する。この場合において除去すべきプレックスは、上で強調される：ｒｏｏｔｖｏｌ−０２、ｓｗａｐｖｏｌ−０２、及び０−０２。以下のコマンドは、各プレックスに含まれるサブディスクをも除去する。
【数２２】
2008511910.tif 000024
【００５０】
●  ｒｏｏｔｄｇディスク・グループからミラー・ディスク（ｄｉｓｋ０１）を除去する。このことは、ＢＥとして用いるために、このディスクを自由にする。
【数２３】
2008511910.tif 000025
【００５１】
●  ディスクｖｘｄｉｓｋ０１のためのエイリアスを除去する。
【数２４】
2008511910.tif 000026
【００５２】
●  それがあるならば、ＯｐｅｎＢｏｏｔ  ＰＲＯＭブート装置リストからｖｘｄｉｓｉｋ０１のエイリアスを除去する。
【数２５】
2008511910.tif 000027
【００５３】
図１ｉは、これらの動作を取ることの結果を示す。この点において、ブート可能なＢＥは、ｂｅ＿ｃｒｅａｔｅコマンドを用いて未使用のディスク１００（このディスクに対する装置名はｃ０ｔ０ｄ０ｓ２である）上に創成され得る。前述したように、新しいＢＥは、ｐａｔｃｈ０９０３と名づけられる：
【数２６】
2008511910.tif 000028
【００５４】
この動作の結果は、図１ｊに示されている。新しいＢＥは、ｖｘ−ｐａｔｃｈ０９０３のＯＢＰエイリアスを有することに注意されたし。
【００５５】
この点において、新しいＢＥがマウントされ得（／．ｌｂｂｅ．ｐａｔｃｈ０９０３／において）、そして、それに対して変更が為され、このことは、システムがそれにブートされるときに見られるであろう。ＢＥは以下のコマンドでマウントされ得る：
【数２７】
2008511910.tif 000029
【００５６】
このＢＥに対する変更が行われ得、それが、／ｄｉｒｅｃｔｏｒｙであったかのように、／．ｌｂｂｅ．ｐａｔｃｈ０９０３／を処理する。所望の変更が行われてしまうと、ＢＥは、それにブートすることを試みる前に、アンマウントされなければならない：
【数２８】
2008511910.tif 000030
新しいＢＥは、ユーザの選択の任意の時点においてブートされ得る：
【数２９】
2008511910.tif 000031
これらの動作を取ることの結果は図１ｋに示されている。
【００５７】
さて、システムは新しいＢＥ上で実行しており、そして、古いＢＥは非アクティブである。しかしながら、これを維持するために、手動の変更が、ＯｐｅｎＢｏｏｔ  ＰＲＯＭセッティングに必要とされる。この点において、ＯＢＰエイリアスは、双方のディスクに対して存在するが、手動の変更がＯＢＰセッティングに為されない限り、ディスクの一方だけが、―オリジナル・ディスク―から自動的に絶えずブートされる。新しいＢＥが任意の与えられたシステム上で適切に動作し得ないという機会が常にあるので、このセットアップは意図的であり、そして、それが適正にブートするということをユーザが確信するまで、新しいＢＥに明白にブートすることを必要とすることが好ましい。この点において、ＯＢＰブート装置セッティングは、これのように見えるはずである：
【数３０】
2008511910.tif 000032
【００５８】
もし、新しいＢＥがデフォルトによってブートされるべきであるならば、そのエイリアス（ｖｘ−ｐａｔｃｈ０９０３）が、ＯＢＰブート装置セッティングの前部に加えられなければならない：
【数３１】
2008511910.tif 000033
【００５９】
さて、標準のリブート、ｉｎｉｔ  ６、もしくは他のシステム再開始コマンドが発生したとき、システムはｖｘ−ｐａｔｃｈ０９０３ディスクにブートすることを試み；ｖｘ−ｖｍｕｐｇｒａｄｅブート・ディスクが使用されるであろう。
【００６０】
システムは、新しいＢＥのミラーとして用いられるべきオリジナル・ブート・ディスクをリサイクルする前に、少なくとも数日間この方法で実行するのを許容され得る。これを行う理由は以下の通りである：
【００６１】
●  新しいＢＥは、幾つかの理由で、例えば新しいＢＥにおいてパッチされていたシステムにおける古いバグに依存する古いアプリケーションのために、システムにとって適切でないかも知れず、通常でないハードウェア構成が、新しいＢＥ等に関する変更で良く動作しないかも知れない。これらの問題は、それら自体を直ちにすなわち数日間で無く提起し得る。もし、オリジナルＢＥがすぐに破壊されるならば、変化及び試みを再度ロール・バックする機会が失われる。
【００６２】
●  新しいＢＥのミラーを直ちに有することは必要とされない。もし、問題が新しいＢＥに提起されたならば（ディスク故障以外に）、それは、新しいＢＥを有する問題によって引き起こされ得、そして、ユーザはオリジナルＢＥが頼る（フォール・バック・オン）ことを望み得る。
【００６３】
●  ディスクの故障が新しいＢＥ上に生じたとしても、ＯＢＰに対して行われる変化は、システムがオリジナル・ディスクに対してブート・バックされ得ることを確実にし、このことは、保守が他のディスク上で行われている間に、少なくともアップして実行しているであろう。この種の問題にさらされている状態は、オリジナル・ブート・ディスクが維持されている時間の量に制限されるであろう。
【００６４】
新しいＢＥが時間に渡って安定していることを決定されてしまうと、ユーザは、ｖｍｕｐｇｒａｄｅブート・ディスクをリサイクルすることを望み得、それにより、それは新しいＢＥに対するミラーとして用いられ得る。これを行うことは、“ｖｍｕｐｇｒａｄｅ”ＢＥがアップグレードされるということを必要とする。オリジナル・ブート・ディスクに対する参照の全ては、また、ＯＢＰから除去されなければならないが、該装置の名称は、ファイルにセーブされるべきであり（この例においては、／ｔｍｐ／ｒｅｃｙｃｌｅｄ−ｄｅｖｉｃｅ）、その理由は、それのための新しいエイリアスがその後まもなく創成されるからである。単一のコマンドでこのパラグラフの手順を達成することが可能であるけれども、この例においては、以下のステップが取られる：
【数３２】
2008511910.tif 000034
＜／ｔｍｐ／ｒｅｃｙｃｌｅｄ−ｄｅｖｉｃｅにおけるＯＢＰエイリアスｖｘ−ｖｍｕｐｇｒａｄｅによって指摘される装置のコピーをセーブする＞
【数３３】
2008511910.tif 000035
【００６５】
これは、図１ｌ及び１ｍに示されている。システムは、今や、ＯＢＰエイリアスｖｘ−ｐａｔｃｈ０９０３を有するディスクにブートすることだけができる。
【００６６】
前者のｖｍｕｐｇｒａｄｅブート・ディスクは、今や、サイクリングのために準備できている。この例においては、標準のＶｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ技術がこれらの動作を行うために用いられる：
【００６７】
●  ｒｏｏｔｄｇ  ｄｉｓｋ  ｇｒｏｕｐの部分としてリサイクルされているディスクをセットアップし、そして、それにｄｉｓｋ０１の名前を付ける。
【００６８】
●  ｄｉｓｋ０１にｐａｔｃｈ０９０３を命名されたディスク上にボリュームの各々をミラー化する。
【００６９】
●  早期に／ｔｍｐ／ｒｅｃｙｃｌｅｄ−ｄｅｖｉｃｅの中に保存された新しいｄｉｓｋ０１上にブート・ブロックのためのＯＢＰエイリアスを創成する：
【数３４】
2008511910.tif 000036
【００７０】
●  ディスクのいずれかからのブーティングを許容するためにＯＢＰブート装置セッティングをセットアップする：
【数３５】
2008511910.tif 000037
これらのコマンドの最終結果、すなわち、手動または自動のいずれかでブートするために全ＯＢＰ支援を有する完全ミラー化された冗長ブート・ディスクが、図１ｎに示されている。
【００７１】
オリジナル・ブート・ディスクのミラーを維持しつつ、新しいＢＥの創成を支援するために、システムが、利用可能な３つのブート・ディスクのうちの最小のものを有することが有利である。本発明は、任意の数のＢＥディスクの使用を支援するが、新しいＢＥが創成され得る前に、任意のブート・ディスク・ミラーが破壊されることを必要とする。ＢＥが創成されると、ミラーは回復される。
【００７２】
新しいＢＥを創成することは、以下のことを必要とする：
【００７３】
１．  新しいＢＥとして用いられるべき局部的に添付されたディスク。
【００７４】
２．  新しいＢＥとして用いられるディスクは、ＢＥを創成するに先立って、Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒの下にあってはならない。
【００７５】
３．  現存するブート・ディスクは、ＢＥの創成中にミラー化されてはならない。任意の現存するミラーは、ＢＥの創成に先立って破壊されなければならない。創成が完了した後、ミラーは再創成され得る。
【００７６】
４．  新しいＢＥのための独特の名称。該名称はホストごとのベースで独特であることが必要とされるだけである。該名称は、説明的であるべきであり、その理由は、多くのＢＥが、自由な（空いた状態の）局部的に付属されたディスクの数によってのみ制限される単一の機械上で創成され得るからである。
【００７７】
用語、局部添付されたディスク、とは、Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ上にない任意のタイプのディスクを意味する。これは、任意の内部のドライブ（Ｓｕｎ  Ｖ８８０のようなシステム内のＦＣ−ＡＬドライブを含む）、外部ドライブ・ベイ（bays）におけるドライブ（Ｓｕｎ  Ｄ１３０のような）、または、ＳＣＳＩケーブルと直接接続される外部ドライブ・アレイにおけるドライブが、ＢＥディスクとして用いられ得るということを意味する。Ｓｕｎ  Ｎｅｔｒａｓのような一層小さい多くのシステムが２つだけの内部ドライブを有し、これらのドライブが、普通、互いのミラーであるということに留意されたし。これらの場合において、本発明は未だ用いられ得るが、ミラーは破壊されて新しいＢＥとして用いられなければならない。新しいＢＥが良好に動作するために有効化されると、オリジナルＢＥは除去され得、そして、新しいミラーとして用いられ得る。システムがただ１つのディスクを有する場合には、本発明はそれに関して用いられることができない。
【００７８】
本発明のもう１つの実施形態においては、ディスク装置ｃ０ｔ１ｄ０ｓ２（このＳｕｎ  Ｅ４２０上の内部の３６ＧＢディスク）が新しいＢＥとして用いられるべきである。最初に、このディスクは、ｖｘｄｉｓｋリスト・コマンドを用いることにより、かつ“ＤＩＳＫ”及び“ＧＲＯＵＰ”コラムがそれらの中にダッシュ（−）を有するということを留意することによって、現在、Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ制御下に無いということが確認される：
【数３６】
2008511910.tif 000038
次に、新しいＢＥのための名称が選択されなければならず、この例では、ｐａｔｃｈ１２０２である。
【００７９】
最後に、本発明のこの実施形態においては、／ａｎｄ／ｌｏｃａｌ／０  ｆｉｌｅｓｙｓｔｅｍボリューム、並びにスワップ・ボリューム（swap volume）をサイジングする（sizing）ためのガイドラインを自動的に提供するために、テンプレートが用いられる。テンプレートにおける値は、新しいＢＥが創成されているドライブのサイズに基づいている。この時点において、／ｕｓｒ  ａｎｄ／ｖａｒ  ｆｉｌｅｓｙｓｔｅｍｓ（及び、現在のブート・ディスク上にだけ配置されている任意の他のｆｉｌｅｓｙｓｔｅｍｓ）が、／ｆｉｌｅｓｙｓｔｅｍに崩壊されるが、／ｌｏｃａｌ／０は別に保たれる。
【００８０】
正常な環境下では、ファイルシステム（ｆｉｌｅｓｙｓｔｅｍ）を崩壊することは、完全に受け入れ可能であり、その理由は、Ｓｏｌａｒｉｓ２．５がリリースされて以来、これがＳｕｎ及びＶｅｒｉｔａｓからの推奨された構成であるからである。追加された保護として、本発明の好適な実施形態においては，ＵＦＳロギングが、Ｓｏｌａｒｉｓ７及びそれ以後のものに対する、新しく創成されたＢＥ上のＵＦＳファイルシステムの全てに対して、自動的にターン・オンされる。ＵＦＳロギングは、実際、ファイルシステムの性能を改善することができ、システムが未来にクラッシュすべきである場合には、これらのファイルシステムのｆｓｃｋに対する必要性を阻止する。
【００８１】
これらの情報でもって、新しいＢＥを実際に創成するためのコマンドが今や発行され得る：
【数３７】
2008511910.tif 000039
【００８２】
ｆｉｒｓｔ  ｔｉｍｅ  ｂｅ＿ｃｒｅａｔｅがシステム上で実行され、現在のブート・ディスクは、ｏｒｉｇのデフォルトＢＥ名が与えられる。しかしながら、説明された実施形態においては、このＢＥに対しては、ＯｐｅｎＢｏｏｔ  ＰＲＯＭエイリアスは創成されない。
【００８３】
デフォルトによって新しく創成されたＢＥがブート可能である。創成プロセスは、また、新しいＢＥへのブートを助けるために、ＯｐｅｎＢｏｏｔ  ＰＲＯＭエイリアスをも創成する。創成されたエイリアスは、ｖｘ−｛ＢＥｎａｍｅ｝の形態のものである。従って、もし、新しいＢＥ名がｐａｔｃｈ１２０２であるならば、それのためのＯｐｅｎＢｏｏｔ  ＰＲＯＭエイリアスは、ｖｘ−ｐａｔｃｈ１２０２であるであろう。
【００８４】
ＢＥだけを創成することは、それをブート可能とし、エイリアスを創成する。それはデフォルト・ブート・ディスクを変更しない。このことは、オリジナル・デフォルト・ブート装置の損失を避けるために、及びこれが必要とされる場合にはオリジナルＢＥにブート・バックすることを容易にするために、行われる。デフォルト・ブート装置をちょうど活性化されたＢＥに変更するために、以下のもののようなコマンドが、Ｓｏｌａｒｉｓ  ＯＳの内側で実行され得る：
【数３８】
2008511910.tif 000040
代替的には、以下のコマンドがＯｐｅｎＢｏｏｔ  ＰＲＯＭプロンプトにおいて実行され得る：
【数３９】
2008511910.tif 000041
【００８５】
創成されると、ＢＥは所定のマウント点においてマウントされ得、それにより、その内容は、手動で変更され得る。このマウント点は、／．ｌｂｂｅ．｛ＢＥｎａｍｅ｝の形態のものである。従って、もし、ＢＥ名がｐａｔｃｈ１２０２であるならば、それは、／．ｌｂｂｅ．ｐａｔｃｈ１２０２の下でマウントされるであろう。そのＢＥディスク上の／ｅｔｃ／ｖｆｓｔａｂにリストされかつＢＥディスク上に物理的に配置されたｆｉｌｅｓｙｓｔｅｍｓのすべてがマウントされ、ちょうどｒｏｏｔ（／）ｆｉｌｅｓｙｓｔｅｍではないということに留意されたし。非アクティブＢＥをマウントする幾つかの理由は：
【００８６】
１．  構成ファイルを編集するためである。
２．  パッケージをＡｄｄ／Ｒｅｍｏｖｅするためである。
３．  パッチをＲｅｍｏｖｅするためである（ｂｅ  ｕｐｇｒａｄｅパッチング・アプリケーション・コマンドがその仕事を行うためにＢＥを自動的にマウント／アンマウントし、それにより、ユーザは、パッチ・アプリケーションを行うためにＢＥを手動でマウントする必要がない）。
例：ｐａｔｃｈ１２０２と名付けられたＢＥをマウントする：
【数４０】
2008511910.tif 000042
ＢＥは、今や、／．ｌｂｂｅ．ｐａｔｃｈ１２０２のもとでマウントされる。
【００８７】
−Ｒ＜ａｌｔｅｒｎａｔｅ  ｒｏｏｔｓオプションの使用を支援するパッケージは、マウントされたＢＥ上にインストールされ得る。幾つかのパッケージは、−Ｒ＜ａｌｔｅｒｎａｔｅ  ｒｏｏｔ＞オプションの使用を支援しないことに留意されたし。
例：ｐａｔｃｈ１２０２と名付けられたＢＥ上にパッケージＬＢａｂｃをインストールする−このＢＥは、この動作が行われ得る前にマウントされなければならないことに留意されたし：
【数４１】
2008511910.tif 000043
【００８８】
−Ｒ＜ａｌｔｅｒｎａｔｅ  ｒｏｏｔｓオプションの使用を支援するパッケージは、マウントされたＢＥから除去され得る。幾つかのパッケージは、−Ｒ＜ａｌｔｅｒｎａｔｅ  ｒｏｏｔｓオプションの使用を支援しないということに留意されたし。
例：ｐａｔｃｈ１２０２と名付けられたＢＥからパッケージＬＢａｂｃを除去する−このＢＥは、この動作が行われ得る前にマウントされなければならないことに留意されたし：
【数４２】
2008511910.tif 000044
【００８９】
もしＢＥがマウントされ、管理上の作業がそれの上に実行されるならば、それは、それを再度ブート可能にするために引き続きアンマウントされなければならない。
例：ｐａｔｃｈ１２０２と名付けられたＢＥをアンマウントする。
【数４３】
2008511910.tif 000045
ＢＥは、今や、アンマウントされ、そして、／ｌｂｂｅ．ｐａｔｃｈ１２０２ディレクトリが除去される。ＢＥをマウントするプロセスは、ＢＥが再度アンマウントされるまで、ＢＥをブート不可能にする。
【００９０】
実際に、それらを適用する前にＢＥに適用され得るパッチのリストを得ることは、時折好ましい。
例：ｐａｔｃｈ１２０２と名付けられたＢＥのためのパッチ・レポートを得る。
【数４４】
2008511910.tif 000046
ｂｅ＿ｐａｔｃｈコマンドは、ＢＥのためのパッチ・レポートを生成する前に、名付けられたＢＥを自動的にマウントすることに留意されたし。それは、また、完了する前にＢＥを自動的にアンマウントする。
【００９１】
あるパッチが、ＰａｔｃｈＭａｎａｇｅｒフレームワークを介してＢＥに適用するために利用可能である。ｂｅ＿ｐａｔｃｈツールがＢＥを調べ、それを、ＢＥ上にロードされたＯＳバージョンのために、かつＢＥのロードされたパッケージの特性のために、最近認証されたパッチのリストと比較する。このＢＥに対してカスタマイズされたパッチ・リストが構成され、そしてＢＥに適用され得る。−−ｒｅｐｏｒｔオプションを有するＢＥのためのパッチ・レポートを得ることも可能である。
例：ｐａｔｃｈ１２０２と名付けられたＢＥのための最近のパッチを適用して、同様にパッチ・レポートを得る。
【数４５】
2008511910.tif 000047
ｂｅ＿ｐａｔｃｈコマンドは、ＢＥにパッチを適用する前に、名付けられたＢＥを自動的にマウントすることに留意されたし。それは、また、完了する前にＢＥを自動的にアンマウントする。
【００９２】
もし、ＢＥがもはや目的を果たさないならば、または、創成されるべき新しいＢＥのためのルームを作るために破壊されることが必要ならば、それは破壊され得る。
例：ｐａｔｃｈ１２０２と名付けられたＢＥを削除する。
【数４６】
2008511910.tif 000048
【００９３】
システムにおけるすべてのＢＥの状況が、ｂｅ＿ｓｔａｔｕｓコマンドを実行することにより決定され得る：
【数４７】
2008511910.tif 000049
【００９４】
図２ａ〜図２ｆは本発明の方法の好適な実施形態を示すフローチャートである。
【００９５】
図２ａを参照すると、システム保守が二次ブート上で行われる間、動作環境は一次ブート・ディスク上で実行される（ステップ２００）。一次ブート・ディスクがバックアップ・ＢＥとして維持される間、システムは二次ブート・ディスクに再ブートされる（ステップ２０２）。
【００９６】
図２ｂを参照すると、一次ブート・ディスクから二次ブート・ディスクに動作環境がコピーされる（ステップ２１０）。一次ブート・ディスク上でシステム保守が行われる間、二次ブート・ディスク上で動作環境が実行される（ステップ２１２）。バックアップＢＥとして二次ブート・ディスクを維持しつつ一次ブート・ディスクが再ブートされる（ステップ２１４）。
【００９７】
図２ｃを参照すると、一次ブート・ディスク及び二次ブート・ディスク間のミラーが破断される（ステップ２２０）。次に、二次ブート・ディスク上でシステム保守が行われる間、一次ブート・ディスク上で動作環境が実行される（ステップ２２２）。バックアップＢＥとして一次ブート・ディスクが維持されつつ、システムは、二次ブート・ディスクに再ブートされる（ステップ２２４）。
【００９８】
図２ｄを参照すると、ステップ２３０、２３２、及び２３４は、それぞれステップ２２０、２２２、及び２２４に対応し、追加のステップ２３６は、一次ブート・ディスク及び二次ブート・ディスク間のミラーを再創設する。
【００９９】
図２ｅを参照すると、二次ブート・ディスク上でブート可能なＢＥが創成される（ステップ２４０）。二次ブート・ディスクのＢＥがマウントされる（ステップ２４２）。二次ブート・ディスクのブート環境上にシステム保守が行われる（ステップ２４４）。二次ブート・ディスクのＢＥがアンマウントされる（ステップ２４６）。二次ブート・ディスク上にＢＥがブートされる（ステップ２４８）。一次ブート・ディスクのオリジナルＢＥが削除される（ステップ２５０）。ルート・ディスク・グループの部分として一次ブート・ディスクが指定される（ステップ２５２）。一次ブート・ディスクは再命名され（ステップ２５４）、二次ブート・ディスクは一次ブート・ディスクにミラー化される（ステップ２５６）。
【０１００】
図２ｆを参照すると、本発明の実施形態のためのシステム保守に関連するステップが示されている。これらのステップは、システムに適用されるべき１つまたは複数のパッチを識別し（ステップ２６０）、システムへの適用のためにパッチを待ち行列に入れ（ステップ２６２）、そして、パッチをシステムに適用する（ステップ２６４）。システム保守が図２ａ〜図２ｅに示された方法と関連して行われるごとに、図２ｆのステップが含まれ得る。
【０１０１】
以下は、本発明に用いられるコマンドのリストである：
ｂｅ＿Ｃｒｅａｔｅ：現存するディスク上に新しいＢＥを創成するために用いられる。結果のＢＥはブート可能である。
必要（前提）条件：
システムは、既に、Ｖｅｒｉｔａｓ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ制御の下になければならない。
ブート・ディスクは、既に、カプセル化されるかまたは初期設定されなければならない。
現存するブート・ディスクの任意の現存ミラーは、除去されなければならない。
【０１０２】
オプション：
−−ＢＥ＝ＢＥｎａｍｅ
創成されている新しいＢＥにユーザの選択の説明的（ＢＥｎａｍｅ）名前を与える。
もし、これが、ＢＥが問題の機械上に創成されている最初のときであるならば、ＢＥレコードは現存のブート・ディスクのためにも創成され、それは、所定のＢＥ名が与えられる（または、それに１つを与えるためにユーザを鼓舞する）ということに留意されたし。この方法で、ユーザは、名称で新しい及びオリジナルのＢＥの双方を参照することができる。
【０１０３】
−−ｄｅｖｉｃｅ＝ｄｅｖｉｃｅ
その上に新しいＢＥを創成するためのディスク装置の名称を与える。この装置は、以下の形態の任意のものであって良い：／ｄｅｖ／［ｒ］ｄｓｋ／ｃ０ｔ０ｄ０ｓ２，ｃ０ｔ０ｄ０，ｃ０ｔ０ｄ０ｓ２。
−−ｎｏ＿ｃｈｅｃｋｓｕｍ
デフォルトにより、ｂｅ  ｃｒｅａｔｅは、現在のＢＥから新しいＢＥにコピーされたすべてのファイル上でＭＤ５  ｃｈｅｃｋｓｕｍを行う。このことは、コピー中に何等コ不正行為が生じなかったということを確実にする。もし、ＢＥの創成が試験使用のためだけに意図されているならば、次に、このオプションは、新しいＢＥを創成するためにかかる時間を減少し得る。
【０１０４】
ｂｅ＿ｓｔａｔｕｓ：このホスト上に存在するすべてのＢＥの状況をリストする。これはすべてのＢＥ名のリストを得るための唯一の方法である。
【０１０５】
オプション：
無し
ｂｅ＿ｍｏｕｎｔ：／ｌｂｂｅ．ＢＥｎａｍｅ／における特定のＢＥをマウントする。ユーザがＢＥを手動でマウントするのを許容し、それ故、パッケージまたはパッチａｄｄｓ／ｒｅｍｏｖｅｓは、ｐｋｇａｄｄ／ｐｋｇｒｍ／ｐａｔｃｈａｄｄ／ｐａｔｃｈｒｍコマンドへの−Ｒ／．ｌｂｂｅ．ＢＥｎａｍｅオプションでもって手動で行われ得る。
注意：それにブートすることを試みる前に、（ｂｅ＿ｕｍｏｕｎｔを用いて）ＢＥをアンマウントするのを確実にし、そうでなければ、ｂｏｏｔ  ａｔｔｅｍｐｔは失敗するであろう。
【０１０６】
オプション：
−−ＢＥ＝ＢＥｎａｍｅ
ユーザがマウントすることを望むＢＥの名称を与える。
ｂｅ＿ｍｏｕｎｔ：特定のＢＥをアンマウントする。終了と同時にマウント点を削除する。
【０１０７】
オプション：
−−ＢＥ＝ＢＥｎａｍｅ
ユーザがアンマウントすることを望むＢＥの名称を与える。
ｂｅ＿ｄｅｌｅｔｅ：特定のＢＥを削除し、それを他のユーザのために含むディスクを自由に（空き状態に）する。
【０１０８】
オプション：
−−ＢＥ＝ＢＥｎａｍｅ：
ユーザが削除することを望むＢＥの名称を与える。
ｂｅ＿ｐａｔｃｈ：現在、このユティリティは特定のＢＥの現在のパッチ・レベルを調査するために用いられ、そして、以下のパッチの詳細レポートを提供する：
１．  このＢＥ上に現在ある。
２．  このホストにとって全く新しい（パッチのどんなバージョンもかつて適用されていなかった）。
３．  現在適用されているパッチへの更新。
ユティリティは、また、最近のパッチ・レベルまでＢＥをもたらすために、任意の必要なパッチを任意に選択的に適用する。
【０１０９】
オプション：
−−ＢＥ＝ＢＥｎａｍｅ：
ユーザがパッチを適用することを望むＢＥの名称を与える。
−−ｒｅｐｏｒｔ
詳細なパッチ・レポートを与える。
−−ａｐｐｌｙ
依存性の順番で、このＢＥへの最近のｐａｔｃｈ  ｕｐｄａｔｅｓをユティリティに適用させる。
−−ｌｉｓｔ  Ｉ  −−ｌｉｓｔｐｒｏｄ
Ｕｎｉｘ（登録商標）  Ｅｎｇｉｎｅｅｒｉｎｇによって認証されていたＰｒｏｄｕｃｔｉｏｎ  Ｐａｔｃｈ  Ｄａｔａｂａｓｅｓをリストする。
−−ｌｉｓｔｄｅｖ
Ｄｅｖｅｌｏｐｍｅｎｔ  Ｐａｔｃｈ  Ｄａｔａｂａｓｅｓをリストする。
−−ｐａｔｃｈｄｂ＿ｒｅｖ＜ｔａｇ＞
中央のＰａｔｃｈ  ＤＢ  ＣＶＳ  ｒｅｐｏｓｉｔｏｒｙをチェック・アウトするために特定のＰａｔｃｈ  Ｄａｔａｂａｓｅを選択する。タグのリストは、−−ｌｉｓｔ及び−−ｌｉｓｔｄｅｖオプションで見られ得る。
−−ｃｈｅｃｋｓｕｍ＿ｅｔｃ
新しいＢＥ上のすべての構成ファイルｕｎｄｅｒ／ｅｔｃを記載するパッチングの後のレポートを生成し、それは、以下であった：
●  適用されていたパッチによって追加されていた。
●  適用されていたパッチによって削除された。
●  適用されていたパッチによって変更された。
−ｊｕｍｐｓｔａｒｔ
非対話的にｂｅ＿ｐａｔｃｈを実行するとき、このオプションは、パース（構文解析）されているパッチ・エントリのカウントダウンを、Ｐａｔｃｈ  Ｐｒｏ  Ｄａｔａｂａｓｅパーサが表示することを阻止する。このことは、ｂｅ＿ｐａｔｃｈの非対話的な実行の出力を清浄に保つ。
【０１１０】
以下は、本発明と共に使用されるユティリティのリストである：
【数４８】
2008511910.tif 000050
このユティリティは、３つの目的を果たす：
１．  Ｅｍｕｌｅｘ  ＦｉｂｒｅＣｈａｎｎｅｌ  ＨＢＡドライバを最近のバージョンにアップグレードする。
２．  （最近の）ＨＢＡドライバの構成が正しいことを確認し、もし正しくなければそれを修正する。
３．  そのファームウェアがアップグレードされているという理由で、各ＨＢＡを通るすべての経路をＰｏｗｅｒＰａｔｈが完全に回復（リストア）できるということを確実にしつつ、一度に１つのカードずつ、ライブ・システム上のＥｍｕｌｅｘ  ＦｉｂｒｅＣｈａｎｎｅｌ  ＨＢＡファームウェアをアップグレードする。そのときだけ、ユティリティは次のＨＢＡカードに進むであろう。
このユティリティは、このユティリティが動作することを要求されているライブ・ブート・ディスクまたはＢＥ上の適所に、ＶｘＶＭ、ＶｘＦＳ、及びＰｏｗｅｒＰａｔｈの最近認証されたバージョンが既に存在する場合にのみ動作する。
オプション：
−−ＢＥ＿ＢＥｎａｍｅ
【０１１１】
もし与えられたならば、特定されたＢＥのドライバは、それがアップグレードを必要とするか否かを見るためにチェックされる。もしアップグレードを必要とするならば、行われ、オリジナル・ドライバの構成（普通、ちょうどＷＷＰＮ目標数）が、新しいドライバ構成ファイルにコピーされる。新しいドライバ構成ファイルは、また、（それらがバージョンからバージョンに変化するので）そのドライバ・バージョンのためのＥＭＣ  ＳＡＮファブリック・リコメンデーションに一致するよう編集される。もし、ドライバが既に適切なバージョンにあるならば、その構成は、そのドライバ・バージョンのためのＥＭＣ  ＳＡＮファブリック・リコメンデーションに対して比較され、そして、何等かの必要な修正が行われる。
【０１１２】
もし何等のオプションも与えられないならば、ユティリティは、それがライブ・ブート・ディスク上で動作しているということを仮定し、そしてドライバ・アップグレードを試みない。しかし、もし、最近のドライバ・バージョンがロードされるならば、それは有効化され、必要ならばその構成を修正する。ユティリティは、次に、最近のファームウェアが各カード上にロードされたということを確認し、必要の場合にはそれをアップグレードする。このことは、実時間で行われなければならず、各カードのリセットを生ずる。ユティリティは、そのカードを通して見られるすべてのＬＵＮが、次のカードのファームウェア・アップグレードに進む前に、再度、ＨＢＡドライバ及びＰｏｗｅｒＰａｔｈ（使用中ならば）の双方に可視であるということを確認する。
【数４９】
2008511910.tif 000051
【０１１３】
このユティリティは、このリリースにおけるシェル・スクリプト（ｓｈｅｌｌ  ｓｃｒｉｐｔ）であり、その上で動作するためのＢＥ名を必要とする。それはライブ・ブート・ディスク上で動作しないであろう。もし必要ならば、それは、最近のＶｘＶＭ、ＶｘＦＳ、ＶＥＡ、及びＰｏｗｅｒＰａｔｈプロダクトにアップグレードするであろう。もしこれらのプロダクトが既にインストールされていないならば、それは、それらをインストールしないであろう。それらは、このユティリティが呼び出されるときには既にインストールされなければならない。
【図面の簡単な説明】
【０１１４】
【図１ａ】本発明の実施形態のための共通の初期のルート・ディスク構成を示す図である。
【図１ｂ】ミラーが破断されてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｃ】ブート環境が非アクティブ・ディスク上で作成されてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｄ】システムが新しいブート環境に再ブートされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｅ】オリジナル・ブート・ディスクへの参照が削除されてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｆ】本発明の実施形態おけるブート・ディスクのリサイクリングを示す図である。
【図１ｇ】ブート・ディスクがリサイクリングされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｈ】ブート・ディスクがリサイクリングされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｉ】新しいブート環境としての使用のためにブート・ディスクが自由に（空き状態に）されてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｊ】新しいブート環境が未使用ディスク上に作成される場合の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｋ】システムが変更されたブート環境に再ブートされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｌ】システムが変更されたブート環境に再ブートされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｍ】システムが変更されたブート環境に再ブートされてしまった後の本発明の実施形態のためのブート・ディスク構成を示す図である。
【図１ｎ】完全にミラー化された冗長なブート・ディスクを有する本発明の実施形態のためのブート・ディスク構成を示す図である。
【図２ａ】本発明の実施形態において行われる動作のフローチャートである。
【図２ｂ】本発明の実施形態において行われる動作のフローチャートである。
【図２ｃ】本発明の実施形態において行われる動作のフローチャートである。
【図２ｄ】本発明の実施形態において行われる動作のフローチャートである。
【図２ｅ】本発明の実施形態において行われる動作のフローチャートである。
【図２ｆ】本発明の実施形態においてシステム保守と関連して行われる動作のフローチャートである。
【符号の説明】
【０１１５】
１００      一次ブート・ディスク
１０１      二次ブート・ディスク
【図１ａ】
2008511910.tif 000052
【図１ｂ】
2008511910.tif 000053
【図１ｃ】
2008511910.tif 000054
【図１ｄ】
2008511910.tif 000055
【図１ｅ】
2008511910.tif 000056
【図１ｆ】
2008511910.tif 000057
【図１ｇ】
2008511910.tif 000058
【図１ｈ】
2008511910.tif 000059
【図１ｉ】
2008511910.tif 000060
【図１ｊ】
2008511910.tif 000061
【図１ｋ】
2008511910.tif 000062
【図１ｌ】
2008511910.tif 000063
【図１ｍ】
2008511910.tif 000064
【図１ｎ】
2008511910.tif 000065
【図２ａ】
2008511910.tif 000066
【図２ｂ】
2008511910.tif 000067
【図２ｃ】
2008511910.tif 000068
【図２ｄ】
2008511910.tif 000069
【図２ｅ】
2008511910.tif 000070
【図２ｆ】
2008511910.tif 000071