MOSES 技術文書 − 序論

p. 1
MOSES 技術文書
−
序論
US WEST NewVector Group, Inc.
ジョン・C・ブラック
Copyright (C) US WEST NewVector Group, Inc. 1993. All rights reserved.
Reprinted with the permission of UniForum Association, the International Association
for Open Computing.
注意：
文中で使用されている資料やデータの表現は、MOSES の成果に貢献した個人や団体の意向
を、必ずしも反映するものではない。従って、その確実性、あるいは有益性に対し、貢献
者、出版社(者)は一切の責任を負わないものとする。
ビジョン
モーゼ (Moses) は、抑圧から、そして奴隷という身分から人々を救い出し、
『乳と蜜の流
れる地』へと導いた。情報システムのユーザは、まるで古代エジプトの奴隷たちのようだ。
彼らは、決まったシステム・ベンダーに囚われ、その製品と技術という限られた範囲の中
で生きるように強制されてきた。商用分野におけるオープンシステム・ソリューションの
出現は、このような『奴隷制度』の中に希望をもたらした。偉大なる自由が目前にあるの
だ。しかし、Plug-n-play による情報処理相互運用という『約束の地』へ到達するために、
企業は、危険な挑戦を何度も繰り返さなくてはならない。選択肢は多くあるが、この新し
いアプローチの導入には問題が多い。限られた環境の中でオープンシステム・ソリューシ
ョンを導入する際の大きな障害のひとつに、運用管理がある。
大規模オープンシステム環境基準化 (The Massive Open Systems Environment
Standard - MOSES) プロジェクトは、大規模オープンシステムの現場担当者によって行わ
れた共同の活動である。高度な有効性、信頼性の保証が必要とされるシステム運用上の生
産環境を定義するために発足した。また、大規模な UNIX オープンシステムの開発環境を
整備する際に必要とされる、一貫した基準についても述べる。
このプロジェクトの提供する主な情報には、新しい運用モデルにおける基準、方針、手順、
ツールの詳細定義・推奨などが含まれる。
包括的なシステム管理用ツールセットの提供という点では、オープンシステムは、その対
照にあるメインフレームのシステムほど完成されていない。そのツールセットは、データ
センターという環境で、大規模な業務システムの効果的な管理を可能にする為のものであ
る。MOSES は、この点を補うため、オープンシステムの供給者がプラットホームに依存し
ない製品を開発するよう、彼らに影響を与えることを望んでいる。目標は、産業界に提供
する一定の必要条件一式を作成することである。さらに、異質のコンピューティング環境
（オープン、メインフレーム・システムの両者とも）の運用に関する経験を分かちあう機
会を提供したり、可能である場合には、共通の業務や手順の確立もする。
読者層
この文書は、本来、大規模なデータセンター、特に UNIX 環境でのデータセンターを運用
する MIS のプロフェッショナルに向けたものであり、MOSES グループがコーディネート
した貢献者チームによって作成された。貢献者たちは、自らの現場の改善、あるいは UNIX
データセンターを完成するために行われた最上の実践におけるダイアログの作成などのよ
うな努力の成果のひとつとして、これらのレポートを作成した。
資料は、UNIX オペレータによって書かれた UNIX 運用のためのものではあるが、他のオ
ペレーティング・システムやデータベースにも幅広く適用される。
UNIX サクセス・ストーリー
MOSES のメンバー団体は全て、UNIX とリレーショナル・データベース技術への確約を積
極的に拡大している。なぜなら、UNIX は有用で、かつビジネスセンスを生み出すからであ
る。
データベース技術を伴う UNIX システムは、会社が信頼できるものとして十分に安定して
いる。US WEST NewVector Group, Inc.では、19 の大規模 UNIX システムが 1991 年に
97.5%、1992 年には 99.92%の使用可能時間を達成している。1993 年 1 月現在、16 の大規
模な UNIX コンピュータが、同年、99.999%を実現している。
1990 年代、急速に変化するビジネス環境の中で、UNIX の柔軟性は MOSES が適用される
現場に戦略的な利点をもたらしている。パッケージ化されたソリューションの幅広い有効
性により、UNIX の現場では、ソリューションを構築する代わりに、ソリューションを買う
ことが可能になったのだ。
MOSES プロジェクト憲章
大規模な UNIX 生産環境において、首尾一貫した運用上のパフォーマンスを促進する、基
準、方針、手順、ソフトウェアツールの詳細を定義する。
MOSES は良いものをより良く
MOSES グループは UNIX データセンターの質の向上に焦点を当てている。MOSES は、
以下の際に必要とされるサイクルタイムを減少させるよう努めている。新しいシステムの
考案、UNIX データセンター運用の上質化、UNIX データセンター共通のレベルの向上、そ
して、より多いコスト効果の取得である。
MOSES プロジェクト前身の歩み
1991 年 9 月
インターナショナル・オラクル・ユーザ・ウィーク (International Oracle Users Week)。
大規模なデータセンターを運用するためのソフトウェア、ハードウェアを所有しているに
も関わらず、その運用業務が会社の発展を制限している事実を、数社が理解し始めた。
p. 2
1991 年 11 月
Sequent Consulting が、転機となる研究、すなわち US WEST NewVector Group のデー
タセンターにおける運用上のチャレンジについて記述した。
1992 年 1 月
UniForum オラクル・ベリー・ラージ・データベース (UniForum Oracle Very Large
Database – VLDB) グループが、Sequent 社と NewVector の研究に関して論議を行った。
彼らのチャレンジが、グループの結成を決定した UNIX ベースのメンバーに支持されてい
たのは明らかであった。
MOSES の歩み
1992 年 4 月 21 日
デンバーでの会議に、大手６団体の UNIX の現場から、それぞれ代表者が出席し、MOSES
が発足。
− US WEST NewVector Group, Inc.
− Burlington Coat Factory Warehouse Corp.
− Millipore Corporation
− British Telecom 社
− Oracle 社 MIS
− Sequent 社 MIS
メンバーである団体はブレインストームを行い、潜在的なトピックをリストアップした。
それらは、このセクションの最後に記しておく。
以下のトピックが研究材料として選択された。
− アラーム／イベント管理
− ジョブ／タスク・スケジューリング
− アーカイブ
− 変更の管理
− バックアップとリカバリー
− システムコンフィグレーション
1992 年 6 月
MOSES の団体がシアトルで会合を開き、それぞれの作成したレポートのドラフトをレビュ
ー。
1992 年 9 月
インターナショナル・オラクル・ユーザ・グループ (IOUG) の会議にてワーキング・セッ
ションを行う。メンバーは IOUG の中に UNIX データセンターSub-SIG を構成することに
同意。
1993 年 1 月
Millipore 社の MOSES プロセスに関するワーキング・セッションの成功。
1993 年 3 月 20 日
MOSES、最初の推奨一式を採用。UNIX データセンターSub-SIG が公式に承認され、活動
を開始。
1993 年 5 月 17 日
MOSES、UNIX データセンターSub-SIG を通じて電子出版をする。MOSES の研究に関す
るコピーを紹介するレターが、400 以上の団体に送信され、印刷物のオーダー要項が添付さ
れた。
1993 年 8 月 15 日
MOSES の研究に関する印刷物が送付された。
チャレンジ − The US WEST NewVector Group の経験
大規模な UNIX 環境があちらこちらにある。それを運用する人々は、生産システムを稼動
させるために、日々、チャレンジをし続けなくてはならない。MOSES プロジェクトは、大
規模な UNIX 環境を運用する上での最良の方針、手順、ツールを文書にまとめて提供して
いる。この研究により、新しい UNIX の現場では、既に確立した UNIX データセンターの
クローンを作ることが可能になる。標準化されたシステム環境は、お互いを研究し学ぶこ
とができる。ゼロから始める必要はないのだ。
我々、US WEST NewVector Group は、自らの UNIX 環境に数百万ドルを投資した。正直
に言うと、我々の UNIX 環境をもっと良く働かせることが可能なのだ。それには、ツール
やユーティリティが必要である。さらに、改善を加えられるよう、さまざまな問題点や信
頼できる方法を著した、方針や手順の文書も不可欠だ。我々は、コンサルタントを雇い、
現場の調査を依頼した。必要なものは何かを明らかにするために。
かつてメインフレームの環境にあったような生産環境のサポートが、UNIX でも必要である。
古典的な MVS メインフレームに携わるスタッフを雇うと、彼らは我々のシステム環境がど
のように稼動しているか、およそ 85%を理解する。たった 15％の学習曲線である。ほとん
どの MVS システム環境は、共通のツールとユーティリティを使用し、類似した方針と手順
を持つ。対照的に UNIX に携わるスタッフの学習曲線は 200%である。まず始めに明白にし
なくてはならないのは、なぜ以前働いていたシステム環境と同じ方法を、次にも取り入れ
ないのかということである。次に、今の方法を継続させない理由だ。賢い人間を雇うと議
論が減るように、携わる人間が替わる度にシステム環境は変化する。やがて、軌道から大
きくはずれてしまうのだ。システム環境を軌道に戻すため、我々は大プロジェクトに乗り
出さなくてはならない。表に出て、コンサルタントが確認した問題を解決するのだ。しか
し、問題は業界全般に広がっている。大規模な UNIX システムユーザ、例えば、British
Telecom 社、 Sequent 社の MIS、US WEST New Vector Group, Inc.、 Millipore 社、そ
して Burlington Coat Factory Warehouse 社もそれぞれにみな、UNIX 環境における同じ
問題を抱えている。我々は、問題解決に向けての研究を共同で行うことを決意した。これ
こそが MOSES 発足の理由である。
これらの組織は、互いに学べるように、同じ方法を採用する方向へと移行しつつある。他
のシステム環境にも役立つよう、我々は、MOSES の早期発行に専心している。ソリューシ
ョンは、可能な限りハードウェアとデータベース、それぞれ独立したものした。
p. 3
エコノミック・モデル
MVS、MS、VM などメインフレームの環境と UNIX 環境、両者を同規模と想定してコス
トを比較すると以下の通りである。
環境
人件費
ハードウェア・ソフトウェア
メインフレーム環境
30%
70%
UNIX
70%
30%
メインフレーム環境では、予算の 70％がハードウェアやソフトウェアに投入される。それ
により、1 から 10 まで整ったソリューションが手に入る。残りの 30％は、そのソリューシ
ョンに携わるスタッフの人件費となる。UNIX 環境では、この割合が逆になる。30％をハ
ードウェアやソフトウェアに費やすことにより、ソリューションを構築するためのツール
が手に入るのだ。
このことから分かるように、UNIX データセンターの運営コストは、メインフレーム環境の
データセンターのそれに比べて約 2 倍である。エコノミック・モデルは、(X = 2*Y)だ。
MOSES はこの方程式をなんとか、(X =.3*Y)にしようと試みている。
X = 2Y から X = .3Y へ移行するためにまず最初にしなくてはならないのは、UNIX データ
センターの稼動方法を標準化することである。全ての UNIX データセンターが別々に稼動
している限り、問題は大きくなる一方で解決はさらに難しくなる。それぞれが、ほぼ同じ
ように稼動すれば、問題の解決は容易になるのである。UNIX データセンターと、UNIX
ではない他のデータセンターとの間で、相互運用が可能なのかどうかを懸念する企業もあ
る。この問題に関しても、両者が運用の基準を持っていれば、解決はより容易である。
学習曲線による採用の遅延
UNIX への移行を検討している顧客は、しばしば我々のショップを訪れる。多くの場合、彼
らは、最初のシステムを大規模でミッション・クリティカルなシステムにしようと考えて
いる。我々は通常、もっと小さなシステム（データサイズは５GB、ユーザ数は 100、ミッ
ション・クリティカルではないもの）から始めるようにアドバイスをしている。学ぶべき
ことは多い。経験のないユーザが、ミッション・クリティカルな信頼できるアプリケーシ
ョン・サービスを稼動するまでに、18 ヵ月はかかるのだ。
ほとんどの MIS マネージャーは、稼動するまでに 6 ヵ月以上かかるような新しいシステム
は考慮に入れない。6 ヵ月という期間は、システム要件が変わらず、早急な調整も必要とし
ない有用なシステムを提供するには長すぎる。今日、ビジネスは急速に変化しているのだ。
学習曲線が６ヵ月を超える限り、多くの MIS マネージャーは UNIX を試みるのを嫌がる。
ベンダーにとっては、大規模なシステムを新しい顧客に売るまでの長いセールス・サイク
ルを意味する。
UNIX データセンターの標準化は、学習曲線の短縮に向かって長い道のりを歩む。学習曲線
が短いほど、オープンシステム採用の速度は速くなる。さらに、採用が速いほど、産業は
より健全なものになるのである。
14 の方法
UNIX の最良かつ最悪の点として、何を行うにも 14 の方法があることが挙げられる。
たとえば、プログラムを書いてもらいたい時、MIS のスタッフに「青」をリクエストする
としよう。MVS と UNIX の両方を知るプログラマーであれば、
「青なら、最初は@#$。次
は&%$だ」と考える。MVS では@#$を作るのに、ひとつの方法しかない。もし二つあると
しても、ひとつは明らかに標準の方法である。このように MVS のプログラマーは、@#$を
作る。それが UNIX になると@#$を作るのに 14 の方法がある。多くの場合、UNIX のプロ
グラマーは@#$を作る方法を決断することになる。グループに分かれ、戦争に遭い、そして、
なんとかその時限りの方法に落ち着くようなものだ。その間に MVS のシステムの現場は
&%$まで終わらせてしまう。より質の高い UNIX システムの現場では、@#$あるいは&%$を
作るのに優先的に用いられる手法がある。こういったユーザは、通常、UNIX を豊かな開発
環境として構築している。しかしながら、この優先される手法というのは、必ずしもシス
テム環境間で通用するものではない。UNIX のコミュニティは、別の方法を採る理由がない
限りは、使うべき最良の方法を統一する必要がある。
MOSES における手順
MOSES グループは小さな、コンセンサスを持ったグループだ。メンバーは互いの現場を知
っている。我々は、同じハードウェア、同じデータベース、そして同程度のビジネス上で
の問題を持つ友人と研究をすることにより、UNIX データセンターの問題を簡素化した。も
っと多様な別のグループとの研究もできたのだが、一連の問題を制限すれば、早く先にす
すめるのだ。
MOSES のメンバーは、自分の現場での問題は解決している。我々は、経費を節約するべく、
さらに共通の運用モデルに向けて前進しているのだ。MOSES は、他のグループが早期に追
従できるよう、その行動を公表している。
MOSES における手順を以下に記しておく。
１．
興味を持つ公の団体が、インターナショナル・オラクル・UNIX・スペシャル・イ
ンタレスト・グループ (IOUSIG)の UNIX データセンター (UDC) Sub-SIG に参
加する。
２．
UDC Sub-SIG が MOSES にアイデアとコメントを提供する。
３．
適当なコマーシャルなシステム環境を担当する、最も活動的な SIG のメンバーが
MOSES への参加を依頼される。（類似した問題に関する責務には、MOSES のメ
ンバーシップが必要である。）
４．
SIG から「無数の問題点」のリストが収集され、MOSES がインプットする。
５．
MOSES が集合し、問題点のリストに優先順位をつける。MOSES が現時点で
取り組んでいない問題に関しては、SIG へ差し戻す。
６．
ミーティングで MOSES メンバーが、ツールやユーティリティ、方針、手順の
必要性についてブレインストームを行う。
７．
アイデアが分類され、重複するものは削除される。さらにアイデアは明白に
される（ミーティングにて）
。
８．
MOSES のメンバー団体は、自身のショップにおける各アイデアの重要性を
評価する（ミーティングにて）
。
９．
「発行議長」は、分類され、優先順位をつけられたアイデアを確認した上で、
それらをまとめる。報告書の探求に責任を持ち、OSF, UI, OSI を考察する。
１０．要求条件が、修正された UNIX インターナショナル形式に記入される。
その形式は MOSES が承認したものである。
p. 4
１１． E メールでメンバーにドラフトが配布される。コメントが要求される。
１２．発行議長が、訂正したドラフトを、再度、配布する。１１と１２は数回に渡って、
繰り返されることがある。
１３．
MOSES のミーティングにて、要求条件が承認される。あるいは、再考のために
差し戻される。
１４．
承認されたレポートは、電子出版される。または、印刷される。
１５．
出版されたレポートに対するコメントが SIG によって収集され、レポートに
反映される。
１６．
MOSES が再検討した上で追加を発行することもある。
１７．
MOSES がベンダーにソリューションを懇請する。
１８．
MOSES のメンバーがベンダーのソリューションを評価する。
１９．
MOSES のメンバーが、ショップに導入するソリューションを選択する。
２０．
MOSES のメンバーの団体が、ショップの一部、あるいは全部に
ソリューションを導入する。
２１．
それらの団体は、ソリューションを適切に試みた後、学んだことを文書にする。
２２．
ショップの効率化に貢献できるソリューションは、
MOSES によって是認される。
MOSES ショップのうち、ひとつあるいは複数がそのソリューションを試み、納
得したことを意味する。
２３．
ショップの効率化に貢献できないソリューションは放棄され、
別のソリューションが試行される。
２４．
MOSES の団体は、継続してソリューションを発展させるため、是認された
ソリューションについてベンダーと研究をする。
MOSES における手順／トピックのライフサイクル
「MOSES における手順／トピックのライフサイクル」のチャートは、このレポートの追加
版として、e-mail 経由で入手できる。また、Perfecting the UNIX Data Center という資料
の Requirements and Policies Volume 1 にも含まれている。さらに、電話での注文も受
け付けている。電話番号は,(800) 252-0300、U.S.A。パートナンバーは、A10925-1。
MOSES の次なるステップ
MOSES グループは、レポートを作成することに専念してきた。
・ツールとユーティリティの一般的な必要条件
・ツールとユーティリティの共有操作性
・セキュリティ
・運用上の測定基準
・災害からの復旧
・テープとメディアの管理
・レポートの閲覧／共有／配布
MOSES が潜在的に関心を持つトピックのリスト
方針と手順
・変更の管理
・テープの管理
・生産プラットホームの管理
・ネットワークのパフォーマンス
・システムのパフォーマンス
・イベント管理とアラーム
・セキュリティ
・バックアップとリカバリー
・機能拡張（新しいコードの追加）
・ロードの管理
・必要な容量の計算・計画
・プログラミングのガイドライン
・プログラミングの方法論
・災害からの復旧
・サービスレベルの一致（応答時間と有効性）
・ネーミングの慣例
・プリンタの管理とレポートの配布
・ユーザ管理
・問題のエスカレーション
ツールとユーティリティ
・バックアップとリカバリー
・テープとメディアの管理
・オンラインでのパラメータ再構成（UNIX とオラクル）
・セキュリティ管理
・データベース・アーカイビング
・変更のコントロール
・コンフィギュレーションの管理
・業務のスケジューリング
・ベンチマークの標準化と測定基準
・データベースのパージ／大規模な削除
・周辺装置の管理
p. 5
・データベースの再構築
・アラーム
・レポートの閲覧／共有／配布
・システム・パフォーマンスの監視
・ユーザ管理
・遠隔システム運用
・システム・アカウント
MOSES への参加
インターナショナル・オラクル・UNIX・スペシャル・インタレスト・グループ (IOUSIG)
は、UNIX 上で稼動するオラクル製品に関する情報を入手したり共有するための、オラクル
ユーザの組織である。システム管理者が互いに助け合ったり、オラクルへの要求を提出す
るフォーラムだ。技術的、マーケティング的情報、そしてベンダーの情報を伝えるため、E
メールの設備を提供している。また、四半期毎にニュースレターを発行したり、UNIX 版オ
ラクル製品ユーザのための会議の後援もしている。
Sub-SIG は、IOUSIG メンバーの媒体であり、特定の、また探し出すのが困難である情報
にアクセスしたり、その情報を共有することに、特に強い関心を持っている。
さらに、UNIX データセンター (UDC) Sub-SIG は、MOSES グループの公のフォーラムと
して奉仕している。
MOSES グループは、UNIX のおもなデータセンター、６つから構成されている。Oracle
社 MIS、US WEST NewVector Group Inc.、Millipore Corporation、Burlington Coat
Factory Warehouse Corp.、British Telecom 社、Sequent 社 MIS である。将来は、UDC
Sub-SIG

Download Report