KEK report 2002-4
Last update 2002/10/15
About this HTML

共通データ解析システムの設計と導入

KEK Data Analysis System
Its Concept and Design



八代 茂夫, 佐々木節, 石川正, 川端節彌, 馬渡博司, 柿原春美, 広瀬均

東孝司, 山本明広
日本アイ・ビー・エム株式会社

宮下勉
ケイエスアルパ株式会社

  1. はじめに
  2. システム設計の方針
    2.1.基本方針
    2.2.システムの概要
    2.3.分散処理システム環境
    2.4.ワークグループを基本にした運用
    2.5.高信頼性の確保
    2.6.セキュリティ対策
  3. システムの設計
    3.1.ファイルの保存領域
    3.2.計算サーバ
    3.3.ログインサーバ
    3.4. I/O サーバ
    3.5.DCE サーバ
    3.6.プリンタ
    3.7.X端末
  4. 運用の方針
    4.1.ワークグループ管理者
    4.2.ユーザ管理の方法
    4.3. ワークグループ管理者の権限
    4.4. 利用に関する申請事項
    4.5.サポート体制
    4.6. システムの情報提供
    4.7. 運用委員会等
  5. システム導入の作業
    5.1.タスクフォース
    5.2.仕様策定作業
    5.3.システム導入作業
    5.4.システムの移行
  6. あとがき

    参考文献
    FOOTNOTE

    付録 1 HPSS Quota System設計書
    付録 2 データ移行について

1.はじめに

共通データ解析システム(KEKCC)は, KEKで行なっている素粒子実験, 原子核実験で収集したデータの解析を主目的としたシステムである.  現在のシステムは2001年1月に機能と処理能力を増強して運用が開始された[1].

今回のKEKCCは, 分散処理システムとしては2期目である. 1996年 1月から2000年12月まで運用を行なった第1期のシステムは, 計算科学センターにとって初めて経験する本格的な分散処理システムであり, 手探りの状態で導入したものであった. サーバ・クライアントシステムとして十分に機能分散されていなかったために運用が安定せず, 運用を開始してからしばしばシステム構成の変更を加えざるをえなかった. しかし, 資源不足により機能ごとに独立したサーバを立ち上げるという根本的な対策ができないままに, どうにか使いこなしてきた状態だった. 今回は, 第1期システムの経験をふまえて, 分散処理システムにふさわしく設計されたシステムを構築した. 運用を開始してから安定して稼動している.

本稿では, 今回のシステム設計にあたっての考え方を中心に説明する. 実際の使い方や具体的なデータは Web 上で手引書1が公開されているので, 参照していただきたい.


2.システム設計の方針

2.1. 基本方針

システムを設計するにあたって, まず以下の基本方針を定めた.


2.2.システムの概要

KEKCCは大容量データの蓄積, およびそれらのデータの高速な解析処理を主眼として設計した. サーバクライアント型の分散処理システムとして, ユーザのホームディレクトリを提供するホームディレクトリサーバ, 実験データ等の大容量のデータを格納するデータサーバ, データ解析処理を行なう計算サーバ, プログラム開発作業を行なうログインサーバ, データサーバと磁気テープとの間でデータのコピーするためのI/Oサーバ, およびユーザ認証を行なう DCE サーバにより全体のシステムを構築した (表 1, 図 1).




ハードウエアはIBMの RS/6000 SPと磁気テープライブラリ装置を中心として構成されている (表 2, 図 1). RS/6000 SPは, システム内の計算機ノード間を, 双方向データ転送速度 300MB/s のSP クロスバースイッチで接続されており, 高速な通信ができるように設計されている. 磁気テープライブラリ装置には20台の磁気テープ装置が備えられている. IBM3590E磁気テープ装置は非圧縮時のデータ転送速度が 14MB/s であり, 磁気テープの容量は非圧縮で 40GB/巻である. 約3000巻の磁気テープが格納可能なので, 合計約 120TB の容量になる. 磁気ディスク装置は, SSA(Serial Storage Architecture)インターフェイスが採用されており, CPU との接続パスが二重化され, 信頼性が高いものとなっている. このSSA ディスクを RAID5 構成で運用している.


図 1 KEKCC の概略図






2.3.分散処理システム環境

KEKCC の環境を構築している主要なソフトウエアを表 3に示す.

RS/6000 SP内の計算機ノードを一体のシステムとして運用するために, DCE (Distributed Computing Environment)2 を, 第1期のシステム[3] に引き続き採用した.



DCEによりユーザ管理が一本化されており, 全てのログインサーバ, 全ての計算サーバ, 全てのI/Oサーバ, HPSS (High Performance Storage System) 3 に同一のユーザ名とパスワードでアクセスできる. ユーザファイルはDCE/DFS(Distributed File Service, 以下DFSと略す) により単一のファイルツリー構造をもって共用され, どのホストからも同一のファイルパスでアクセスできる. ファイルにアクセスする時には, その度に認可処理が行なわれるので, 不当なアクセスを防ぎ安全性が高い.

階層型ファイルシステム(HSM)である HPSS により, 120TBの大容量のストレージをあたかも全体が磁気ディスク上にあるように使用できる. HPSS上のファイル全体が単一のツリー構造として示され, どのHPSSクライアントからも同一のファイルパスでアクセスできる.

LSF(Load Sharing Facility)4 により, ログインサーバ上で開発されたプログラムを, プログラム実行の専用のマシンである計算サーバにジョブとして投入し, 実行することができる.

2.4.ワークグループを基本にした運用

KEKCCは, 複数の研究プロジェクトが1つのシステムを共用している. プロジェクトにより, 計算機の利用の仕方に違いがあるため, 12GeV PS実験(長基線ニュートリノ振動実験を含む), JLC R&D, ATLAS実験, 中性子・中間子実験, 加速器研究, およびその他の研究グループのためのセントラルという, 合計6つのワークグループを運用の単位として設けた. ワークグループ内には実際の共同研究を行なう単位となるグループが複数存在する. KEKCCでは, この研究グループをサブグループと位置付けている. サブグループは UNIX のグループという概念に対応させて, 標準的に備わっているグループ管理機能を用いて制御している.




2.5.高信頼性の確保

24時間連続運転を安定して運用できるよう, 障害が発生しても可能な限り部分的な機能の低下や縮小でとどまり, システム全体が停止しないように設計した. システムの重要な部分については原則として二重化を行なった. OSの磁気ディスクの二重化や RAIDディスクの採用などハードウエアの信頼性の向上,  DCE サーバ機能のレプリカ作成やプログラムライブラリ領域のレプリカ作成などソフトウエアのバックアップパスの作成を行なった. 運用を継続しながら障害の対策を行なえる. これによりシステムの回復のために停止する場合でも短時間の作業で済ますことができる. 夜間や休日に障害が起こっても, 翌日まで対策を延ばすことが可能である. 緊急に対策しなければシステムが機能しない事態が減り, 結果的にメンテナンスコストを削減できた.

システムの運用に重大な支障をきたす障害についての常時遠隔監視体制と緊急対策の体制を整備しており, 早期検知と対策を可能としている.


2.6.セキュリティ対策

不正アクセスが増加している中で, 多数のユーザが利用するシステムを安定的に運用するために, セキュリティ対策[4] を従来以上に強化した. セキュリティ対策は利便性と相反することが多いので, 両者のバランスを検討しながら設定している.

サーバ機能により, KEK外からのアクセスが必要なもの, KEK内からのアクセスが必要なもの, ユーザのアクセスが不要なものと整理してネットワークの設定[5]を行なった. ログインサーバへのリモートアクセスおよびリモートファイル転送は, 原則として SSH [6] のみとした. TCP wrappers によりサイトあるいはホストをアクセス制限している.


3.システムの設計

3.1. ファイルの保存領域

3.1.1.二種類の保存領域

データの保存場所は, ホームディレクトリサーバの領域とデータサーバの領域がある. 前者は磁気ディスクの領域であり, 後者は階層型ファイルシステムで管理された磁気テープライブラリ装置と磁気ディスクにより構成される領域である. これらは, 以下のように設計され, パラメータのオプティマイズがされている.

ホームディレクトリサーバは, クライアント側のDFSキャシュを利用して, 比較的に小さなファイルを繰り返しアクセスする場合にキャッシュ効果により早いレスポンスが得られるようにパラメータを設定している. 従って, その中に大きなファイルを置いてシーケンシャルにアクセスをすると, 他の小さなファイルがキャシュから追い出されて, キャシュ効果が失われる.

サイズの大きなファイルは, 例えそれが一時的であっても, データサーバに置くことを前提にシステムのパラメータを設定している. 仮に, データサーバ上に小さなファイルを多数置いたりすると, 階層型ファイルシステムの性質上, レスポンスの低下を招きやすい.

以上に述べたデータの性質によるサーバの使い分けが自動的に行なわれるように設定されている訳でない. 利用者には各々のサーバの特性を理解して効率の良いシステムの利用ができるよう指導している.


3.1.2.ホームディレクトリサーバ

ユーザのプログラムや, 数KBから数10MBといった比較的に小さいファイルの保存領域である. ログインサーバおよび計算サーバから, DFS による分散ファイルシステムとしてアクセスされる.

ホームディレクトリサーバの領域は, ユーザ毎の作業領域である本来の意味でのホームディレクトリ領域, グループファイル領域, ワークグループライブラリ領域と, 3つの用途に割り当てられている.

また, ホームディレクトリサーバの領域は, ワークグループ毎に集中させて領域を割り当てている. これはシステムの保守などの場合に, ワークグループ単位での作業ができることを想定している.




4.1.2.1. ファイルシステム

ファイルシステムは, LFS(Local File System) を使用している. LFSはDFS のファイルシステムであり, 個々のファイルおよびディレクトリにACL(Access Control List) を設定できるので, UNIX のアクセス制御よりきめ細かな制御ができる [7].

DCE の ACLでは, ディレクトリの場合には, 読み取り(r), 書き込み(w), 実行(x), 制御(c), 挿入(i), 削除(d)の6種類の, ファイルの場合には, 読み取り(r), 書き込み(w), 実行(x), 制御(c) の4種類のアクセス許可ができる. また, 任意のユーザあるいは任意のグループに対してアクセス許可が設定できる.

以下にACL 設定の表示例を示す. ディレクトリ /dfs/l/ce/egs4 について, ユーザ user1 および user2 に, グループ ce_adm と admi に全権限を与えている.

更に, ディレクトリ内にファイル, あるいはサブディレクトリを作成した時に, それらに標準的に設定される ACL を設定できる. 例として /hpss/ce における設定の表示を示す. 上から順に, 当該ディレクトリの ACL, 作成するファイルの ACL, 作成するディレクトリの ACL である.

KEKCC では, それぞれのディレクトリの ACL の設定により, 第ワークグループ管理者の権限節で説明しているワークグループ管理者(権限については第ワークグループ管理者の権限節を参照) によるワークグループ内のストレージの管理と制御を可能にした. ただし, ユーザがACL の設定を不適切に変更するとワークグループ管理者の管理外となるので注意が必要である. ユーザには利用の手引きで注意を促している.


4.1.2.2.ホームディレクトリ領域

個々のユーザのデータ保存領域である. ユーザが確保できる領域の大きさは, LFS の QUOTA で管理される. システムが使用量を監視しており, 定められた量まで領域を確保できる.

ユーザのホームディレクトリはACLにより, サブグループメンバーだけに読み込みが許可されるように初期設定した. ホームディレクトリ直下にprivate と public と言う名称の2つのディレクトリが作成されており, private の下に作られたファイルは本人のみがアクセス可能, public の下に作られたファイルは誰でも読み込み可能となるように設定している. 他ユーザ一般に見せたいファイルは public の下に作成する.


4.1.2.3.グループファイル領域

KEKCC は研究グループを共同作業の基本にした運用がされているので, データの保存領域の配分を, 研究グループを基本にして行なっている. グループファイル領域は主に以下の用途の領域として設けた.

この領域は, QUOTAによるユーザ毎の領域管理を行なわず, 割り当てられた領域全体を研究グループのメンバーが自由に使えるようにした.

研究グループ単位に領域を配分するということで, 運用が簡単になり, 領域の配分は研究グループの要求の妥当性と研究プロジェクト(ワークグループ)内での優先度を考慮した調整で済む. 研究グループ内でのユーザ間の調整は, 必要性が生じたグループ内でだけ行なえば良い. 仮に全てをユーザ領域として配分する場合には, ワークグループ全体の中で個々のユーザの要求について妥当性を検討し, 優先度を考慮して調整を行なう必要がある.


4.1.2.4.ワークグループライブラリ領域

ワークグループで共通に利用するフリーソフト, 市販のソフト, 開発したツールなどのソフトウエアを入れる領域である. 特にホームディレクトリ領域やグループファイル領域と区別する必然性がある訳でないが, 個々のユーザの領域やサブグループの領域に入れるよりも管理しやすいという, 今までの経験から設けた.


4.1.2.5.ホームディレクトリサーバへのアクセス

ホームディレクトリサーバへは, ログインサーバおよび計算サーバからDFS経由でアクセスできる.

KEKCCの内部からだけでなく, 研究者の手元にあるワークステーションあるいはパソコンからもファイルシステムとしてアクセス可能である. KEKCC をデータサーバとして利用し, CPU は自分の計算機を使うといった環境を構築できる. 研究者のマシンにDFS クライアントを導入すればDFS経由でアクセスできる. これは計算科学センターと打ち合わせをした上で設定する必要がある. DFS クライアントを導入せずに, もっと簡単にファイルシステムとしてアクセスできるようにするためにゲートウエイ機能を導入した. LSI Logic Storage Systems 社のTAS5 というソフトウエアにより, Windows や Linux からはSMBプロトコルで, またMacintosh からは AppleTalk over TCP/IP によってアクセスできる.


4.1.2.6.バックアップ

ホームディレクトリサーバ上のファイルは, TSM(Tivoli Storage Manager)により定期的にバックアップされる. TSMでは DFS の ACL を含めてファイル単位のバックアップが可能である.

DFS 自身にもバックアップ機能があるが, この機能はバックアップ中にはファイルセット単位でロックがかかり, 数分間はアクセスできなくなる場合がある. 各ユーザのホームディレクトリは1つのファイルセットとしているので, バックアップ処理中となったユーザはファイルの読み書きができないために計算機利用に支障をきたすことが予想された. 技術面および運用面での比較検討をした結果, ファイルセット単位でのロックを行なわないTSMによる方法を選択した.

各ワークグループのログインサーバのうちの1台のホストで, 毎週金曜日の17時にフルバックアップの処理を開始する. 処理が終了するまでの時間は, ファイルの数と総容量によるが, 2002/4/13 時点で, PS グループの約 55GB で約 18 時間が最大である.

運用として, バックアップをファイルの修復に使用するのは, システム障害によりファイルが壊れた場合としている. 個々のユーザが消去したファイルの修復作業は, システム管理者の負担が大きいので対応していない. 個々のユーザのファイル修復を必須とするならば, システム設計の段階でバックアップファイルセットの設定と運用を行なうことで可能であった. しかし KEKCC では, 磁気ディスクの容量を最大限にユーザのファイル領域として利用することを優先させたので, 容量的なオーバヘッドがあるこの機能を運用しなかった.


3.1.3.データサーバ

1つのファイルが数10MBから数10GBの実験データファイルや tarでまとめたデータなどの保存領域である. 総容量120TBの磁気テープライブラリ装置による保存領域と, 10TB の磁気ディスクによる作業領域を備えている.

磁気テープライブラリ装置は, 20台の 3590E磁気テープ装置を備えており, 磁気テープ約3000巻が格納可能である. 磁気テープの容量は, 非圧縮で40GBであり, これを圧縮モードで記録するよう設定してある. 磁気テープの圧縮時の容量は, 3590E磁気テープでは3倍とされている. 実際にはデータのパターンに大きく依存する. KEKCC の実際のデータを PS実験のサブグループ単位に測定した結果では, 圧縮率が低いグループで 115%, 高いグループで190% であった. 実験データは作成時に既にバイナリで圧縮されているので, 磁気テープ装置による圧縮率が低くなっている.


4.1.3.1.HPSSの概要

データ領域を管理するのは, HPSS [8] [9] というソフトウエアである. HPSSはTB(=1012バイト)からPB(=1015バイト) 規模のデータ管理をめざして, アメリカ・エネルギー省管轄下の研究所6とIBM社との共同で開発され, 維持されている. アメリカでは, SLAC, FERMIlab, BNL など約20機関で稼働しており, その他の地域では理化学研究所(1999年稼動開始), 東京大学宇宙線研究所(2002年1月稼動開始), CERN(スイス), IN2P3(フランス), CEA-DAM(フランス)で使用されている.

HPSS は階層型ストレージ管理システム(HSM, Hierarchical Storage Management)である. HSMとは記憶装置(ストレージ)のコストパーフォマンスを向上させるするために, 高速なアクセスのための磁気ディスクと, 経済性のよい磁気テープとを組み合わせて利用できるようにしたソフトウエアである. ユーザには媒体を意識しない統一的なインターフェイスが提供される. 一般的に高速なアクセスを必要とする上位の階層に磁気ディスクを, 経済性を重視しアクセス速度は二次的とする下位の階層に磁気テープライブラリ装置を使用することが多い. KEKCC でも同様な構造でシステムを構築している.

HPSS は, メタデータを管理する Core サーバと, データの移動を行なうディスクムーバおよびテープムーバを中心にして構成されている. ムーバプロセスが計算機ノードに接続された磁気ディスク装置や磁気テープ装置を管理して, データの転送を行なう. ディスクムーバおよびテープムーバは同一のノードあるいは異なるノードに配置することができる. KEKCCでは47台のSSAディスクを12台のノードに, 20台の3590E磁気テープ装置を5台のノードに接続している. テープムーバとディスクムーバを異なるノードに置き, その間のファイル転送は双方向転送速度が 300MB/sec のSPクロスバースイッチを経由して行なわれる.


4.1.3.2. 処理概要

クライアントから読み出しが要求されたファイルが上位の階層である磁気ディスク上にあれば, そのままデータが転送される. 要求されたファイルが下位の階層である磁気テープに存在する場合には, 磁気ディスクへの複写処理が発生する. この処理をステージングという. この場合にクライアントへのデータの転送が開始されるのは, HPSSサーバ側の設定による. ステージングが完了してから(Stage on Open), またはステージングしながら(Stage on Open Async)のいずれかの設定ができる. KEKCC でのデータのアクセスパターンは多くの場合が先頭からの順次読み出しなので, 後者の Stage on Open Async に設定した. 先頭のバイトがディスク上に到達した瞬間から読み出しが開始される. 従って, ステージング処理の終了を待つ必要がなく, 磁気テープライブラリ装置のローデイング処理および磁気テープ装置の頭出し処理を含めて1分程度の待ち時間で済む. 待ち時間を全くなしに, プログラムで直ちに読み出したい場合には, 使う予定のファイルを, あらかじめ, のような, ファイルの先頭を読み出す操作をしておけば, この時点でステージング処理が実行され, このコマンド終了後はいつでも読み出しが可能である.


新たに作成あるいは更新されたファイルは, 磁気ディスクに作成される. 作成されたファイルは一定時間経過7すると磁気テープに複写される. この処理をマイグレーションという.ファイルはマイグレートされてもすぐには磁気ディスクから削除されずに, 磁気テープ上と磁気ディスク上の双方に保存されている. このような状態のファイルの読み込みが発生した場合には, 磁気ディスクから行なわれるので, 高速な処理ができる.

ファイルの作成, あるいはステージング処理により, 磁気ディスクの残量がhigh water markに達したときには磁気ディスク上の古いマイグレートされているファイルが削除される. 削除処理は古いファイルから順番に行われ, low water markに達したときに終了する. この時点で削除されるファイルは既にマイグレートされているので, 発生する処理は磁気ディスクの削除だけである. その結果, 作成処理中あるいはステージング処理中のファイルが, マイグレーション処理の終了を待つということが避けられる.

以上のように, 磁気ディスクの使用率が high water mark に達していなくとも, 全てのファイルが作成後一定時間経過するとマイグレートされるのが HPSS の特徴である. どのような状態であっても高速な処理が可能となるように設計されている. 常にHPSSクライアントからのデータのアクセスは, 磁気テープとの I/O ではなく, 磁気ディスクとの I/Oだけである.

HPSSでは磁気ディスクを置かずに, 直接に磁気テープにデータを置く設定もできる. この場合には同時に磁気テープを使用するプロセス数の分の磁気テープ装置台数が必要となる. KEKCC では, 磁気テープ装置の有効利用のために, この方式を採用していない.


4.1.3.3. データ領域の管理

データ領域の管理方法については、代表的なサブグループのデータの種類、サイズ、 扱い方を調査検討し、以下の条件を前提に HPSS の設計を行なった.

以上の条件を実現させるために、HPSSが持っているclass of service (COS) という概念および file familyという概念を組み合わせて利用した.

COS はマイグレーション先, マイグレーションに関するパラメータ, マイグレート済みファイルの削除に関するパラメータの定義である. 全てのファイルにはCOSの番号(ID)がつく. 当初考えられた設定方法は, ファイルの大きさや使用頻度に従って複数のCOSを用意し, ユーザが自分のファイルの性質に合わせてCOS を選択するというものであった. システムの効率的利用、あるいは性能を引き出すという観点からの案であった. しかし, KEKCC での利用のように異なるグループに属するユーザがそれぞれに使用する場合には,特定のCOSに選択が集中して資源の競合が起こる可能性が考えられた. 競合の調整が容易であることという要素を優先させて, これが現実的に容易な範囲であるワークグループに1つのCOSを割り当てることにした.

File familyという磁気テープ上のファイルをグループ化する仕組みを用いて, これをサブグループのディレクトリツリーと対応付け, 各々のサブグループのファイルが特定の磁気テープにマイグレートされるように設定した. 原則として1つのサブグループに1つの File familyを割り当てた. 規模の大きいサブグループには例外的に, 複数の File familyを割り当てた. 逆にそれぞれのサブグループの使用するデータ量が少ないNMLワークグループでは, 全体をまとめて1つのfile family とした. 

QUOTAチェックのプログラムを作成して, File familyごとに磁気テープの使用量を計算するようにして 3番目の条件を実現させた. 容量の制限を越えている場合には, サブグループの管理者に警告のメイルが送られる. そのままデータの書き出しが続けられると, 書き込みを不可にする. 詳細な仕様は付録1を参照のこと.

4.1.3.4. セキュリティ

HPSSの認証にはKerberos V5 が採用されている. これはDCEのKerberos V5との相互運用が可能であるので, KEKCC では DCEサーバをHPSSの認証サーバとして運用している. またHPSSのファイルのアクセス制御はACLにより行なわれている.


4.1.3.5. 磁気テープのrepack

ファイルを消去したりアップデートした場合に, 磁気テープ上では以前に書いたデータはそのまま残され, 新しいデータが磁気テープの最後尾に書かれ, ファイルのポインタが変更される. この結果, 磁気テープ上では, 有効なファイルと無効になったファイルがモザイク状に存在する「虫食い状態」が生ずる. このような虫食い状態を解消するために, HPSSには, 磁気テープのrepackという機能がある. この機能によりファイルを磁気ディスク経由で磁気テープから磁気テープに複写して, 有効なファイルだけを集めた磁気テープを作成することができる.

Repackにかかる時間は, 虫食い率とファイル大きさによるが, 虫食い率50%の場合, 磁気テープ一本あたり2時間以内と見積もられている. これは無視できる時間でないので頻繁に行なうわけにはいかない. 一方, 虫食いを放置すると, 3000巻という限られた磁気テープの有効利用ができなくなるので, 次のような方針でrepackを実施している.


4.1.3.6.データサーバへのアクセス経路

HPSSでサポートされているクライアントアクセスのインターフェイスと, それぞれについてサポートされているクライアントのOS は表6の通りである8. ファイルシステムとしてのアクセスはDFS と NFS である. KEKCC では, Client-API, Parallel ftp, ftp, および DFS9 を運用している(図3).

DFSはファイルシステムとしてアクセスできるので, 既存のプログラムからのアクセスがそのままで可能であり, またファイルの状態やパスを調べたりするのが容易である. しかしデータ解析のためのアクセスをDFS経由で行なうと, 性能がDFS によって制限される. ログインサーバでHPSS上のデータの読み書き行なった場合には, 大きなサイズのファイルがDFSキャッシュに入ることで, 小さいサイズの多数のファイルがキャッシュから追い出される. 追い出される多数のファイルは, ホームディレクトリサーバのファイルであり, キャッシュ効果が大きいファイルである. 結果的にDFS性能が悪化し, レスポンス低下を招く. 従って, DFS経由ではファイルの状態の確認(ls, cd, head など)やアクセス権限の変更 ("dcecp -c acl ....") に限って使用して, ファイルの内容の読み書きは行なわないことを推奨している.

データ解析にはClient-API を主として使用することを検討した. 性能を十分に引き出すには, データ転送のバッファサイズのチューニングが重要である. ユーザがClient-API を容易に使用できるように, インターフェイスを簡単にしたClient-APIのラッパープログラム [10] を用意した. Linux もサポートし, 研究グループが所有しているマシンにも容易にインストールして利用できるようにした. Client-API でもKerberos認証10をサポートしている. LinuxにKerberosも併せてインストールして, KEKCC の認証サーバから認証を得るように設定すれば, LANにパスワードを流さないようにできる. このラッパープログラムを利用して, PS実験グループの青木正治氏(現大阪大学)や山p~光裕氏は CERNLIBのデータの入出力をHPSS との間で直接にできるようにした11.




Parallel ftp と ftp は, KEKCC の内部では I/O サーバとHPSSとの間でのデータ転送に使用する. また, ユーザのワークステーションとの間のデータ転送の主要な経路になる. Ftp は多くのマシンにクライアントが導入されているので直ちに使えるが, 認証時にパスワードを平文でLAN上に流すので, セキュリティ上問題がある. やむを得ない場合を除いては Kerberos 対応の Parallel ftpを使用するべきである. Parallel ftp もラッパープログラムのパッケージの中に含まれており, 展開するとbin/krb5_gss_pftp_client が作成される. 以下に実行例を示す. イタリック体の部分はそれぞれ自分のユーザ名およびパスワードである.

HPSS でもホームディレクトリサーバと同様に, 研究者のワークステーションあるいはパソコンからファイルシステムとしてアクセスできるようにした. 研究者のマシンにDFS クライアントを導入すればDFS経由でアクセスできる. TAS によるゲートウエイ機能を経由して, Windows や Linux からはSMBプロトコルで, またMacintosh からは AppleTalk over TCP/IP によってアクセスできる.





3.1.4. ファイルのアクセス制御

それぞれのディレクトリに設定したアクセス制御の値を表 7 に示す. ディレクトリに作成したファイルおよびサブディレクトリには, 同一の値が設定されるようにした.

ユーザホームディレクトリの設定については, 「ホームディレクトリ領域」で説明した通りである. グループファイルは, サブグループのメンバーがアクセスできるようにしている. ワークグループライブラリ領域は, 導入したソフトウエアを他のワークグループも利用できるように設定してある. 書き込みを行なうユーザは, ワークグループの管理者が別途登録する.

これらの設定は標準値であり, ワークグループの運用方針によっては異なる設定をしている場合がある.



3.1.5.データサーバアクセスのベンチマーク

Client-APIのラッパープログラムのベンチマークテストを2000年6月に実施した. 17ノードのRS/6000-SP(POWER3, 375MHz, 4CPU)を用いて, 10ノードのクライアントと6ノードのディスクムーバおよび1ノードのCoreサーバによって (図4) によって構成した. それぞれのディスクムーバにはRAID5構成の SSAディスクを接続した. ソフトウエア環境は, AIX4.3.3, DCE 2.2, Encina 4.2, そしてHPSS R4.1.1である.

ベンチマークテストでは, 入出力の性能およびクライアントにおけるCPU利用率を計測した. 1つのクライアントノードあたり1つのreadと1つのwriteプロセスを実行し, サーバに対して合計20プロセスを同時に実行した. それぞれのプロセスの扱うファイルサイズは4GBとし, データ・リクエストのレコード長を64KBとした. このベンチマークは, 実利用環境のプロセスあたりの入出力性能とスループットおよびクライアントノードのCPUの消費をシミュレートすることを目的としており, ベンチマークテストとしては厳しいものである.




5回測定 (表8) を行ない, 以下の結果が得られた.

  • 1クライアント・プロセスあたりの平均read性能 :31.6MB/s
  • 1クライアント・プロセスあたりの平均write性能 :14.8MB/s
  • クライアントにおける平均CPU利用率 :16%
  • HPSSのスループットは, 6ノードのディスクムーバ構成において464MB/sに達し, 1ノードのディスクムーバあたりでは77MB/sを実現した. 高い転送性能ながら, クライアントノードのCPU利用率は平均で16%と低く抑えられている。このような入出力を行いながらも計算に十分CPU資源を配分できるという特徴は、実験データ解析に最適なシステムを構築するという導入目標を満足するものであった。また導入された実機においても2001年1月に同じベンチマークを行い、このような性能結果を追証した。





    3.2.計算サーバ

    計算サーバは, ユーザプログラムを実行するための専用のサーバであり, ログインサーバからバッチジョブを投入して利用する. ジョブスケジュールのためのソフトウエアとして Platform Computing社12 の LSF(Load Sharing Facility) [11] を導入している.

    このソフトウエアにより, ジョブは適切なホストで実行されるようスケジューリングされる. ユーザにとってはホストを意識する必要がなくなると共に, 特定のホストに負荷が集中して過負荷状態になることが避けられ,システムを効率よく運用できる.

    3.2.1.ジョブキューの設定

    ジョブキューの設定はワークグループ毎にできるようにすることを第1条件にしてシステムを設計した. LSFでは管理運用の単位をクラスターというが, KEKCC のワークグループ毎に, 1つのクラスターを割り当てた. クラスターには, 各々のワークグループのログインサーバおよび計算サーバが含まれ, これらの資源内でジョブキューを作成できる.

    ジョブキューは, 標準的にCPU時間を基本とした express, short, middle, large, huge の5種類を設定している. 1ホストで実行できる最大ジョブ数や, 1ユーザが実行できる最大ジョブ数, 使用可能なメモリサイズ, NICE値, スケジューリング方式の設定はワークグループ毎に異なる. 以下に例として Central ワークグループの設定を示す.


    ジョブの取り出しは, 優先度の高いキューの中の, 優先度の高いジョブから行なわれる. キュー間の優先度は, 設定ファイルで定められる. 上記の例では Prio の値がキューの優先度である. ジョブ間の優先度の扱いは, PSワークグループでは同一サブグループが, その他のワークグループでは同一ユーザが, 同時に多数のジョブを投入しても連続して実行されずに, 異なるサブグループあるいはユーザが割り込めるような方式 (PREEMPTION機能) を採用してパラメータを設定した.

    3.2.2.DCEへの対応

    DCE環境では, 資源にアクセスするためには有効な認証チケットを保持している必要がある. LSFをDCE環境下で使用するために, 認証の問題を検討する必要があった.

    認証チケットはログイン後10時間が有効であるように設定されており, それを過ぎるとファイルのアクセスができなくなる. LSFのバッチジョブも例外でない. チケットの自動延長機能を組み込み, 10時間以上のバッチジョブを実行可能にした.

    3.2.3.実行結果の出力先

    バッチジョブの実行時に, 標準出力および標準エラーが出力される. 実行中にこれらの出力は, ユーザのホームディレクトリ領域である $HOME/.lsfbatch/ に一時ファイルとして作成されるように設定した. システムに共通領域を置くことも検討したが, その場合には容量を管理するメカニズムが必要になるので, ユーザ個人の責任で領域を管理する方針とした. ジョブの実行途中にこの一時ファイルを参照すると, 最新のデータが全て出力されているとは限らないが, ある程度のジョブの進行状況をつかめる. ジョブ終了時には, LSFにより一時ファイルの内容がユーザにメールとして送られ, 一時ファイルは削除される.

    LSFが出力するファイルの容量をシステムとして制限することを検討したが, 標準的な機能を使う範囲では実現できなかった. プログラムミスなどにより多量の出力が生じた場合にはシステムの領域 /tmp に出力され, この領域が圧迫されることになる. 既に QUOTAの上限近くまでホームディレクトリ領域を使用している場合には, QUOTA の制限にかかり, ジョブが異常終了してエラー情報がメールで送られる.


    3.3.ログインサーバ

    ログインサーバは, KEKCC を利用するための入り口となる. ユーザはパソコンなどの端末からログインサーバにリモートログインして, プログラム開発等を行なう. プログラムやデータの保存領域である, ホームディレクトリ領域およびデータ領域が DFS マウントされており, ファイルシステムとしてアクセスできる. ログインサーバからHPSS に Client-API や DFS でアクセスして, 開発したプログラムのテストを行なう.

    テストが終了したプログラムは, LSFを使って計算サーバにジョブとして投入して実行する. ログインサーバでの長時間のプログラム実行は, システムレベルでは制限できないが, システムを効率的に動作させるためには控えることが望ましい.

    3.3.1.ログインホストの負荷分散

    ログインのためのホストは, 各ワークグループに複数のホストが割り当てられている.

    ログインは代表ホスト名で行なう. ログインすると, そのワークグループに割り当てられているホストに順次ラウンドロビンで接続される. 個別のホスト名を意識する必要がなく, またホスト毎の負荷分散がされる. 逆に, 同じ代表ホスト名でログインしても同一ホストに接続されるとは限らないので, ホストを意識する必要がある場合には個別ホスト名を使用する. この場合には負荷分散を乱す場合もあるので一般的には使用しない.

    どのワークグループにも複数のホストを割り当てているので, あるホストが障害により停止しても, 運用を継続できる. ユーザは代表ホスト名でログインするので, どのホストが障害を起こしているのかを意識する必要がない. ログインしていたユーザだけが影響を受ける.

    接続を許可する相手のドメインやホストは, ワークグループ毎に定めてアクセス制限を行なっている. 研究グループ毎に共同研究を行なう相手が異なるので, 必要な相手先だけに接続を許している.

    3.3.2. ユーザ認証

    ログイン時にはDCEの認証が行われ, 認証チケットが発行される. ログインしたセッションでは, このチケットを使って, ホームディレクトリへのアクセス, HPSSへのアクセス, バッチジョブの実行を行なう.

    チケットには, セキュリティのために有効期限があり, その期限が過ぎるとシステムのほとんどの機能が使用できなくなる. このチケットの初期有効期限は10時間としている. 認証チケットは必要に応じて kinitコマンドを使って, 最大4週間を限度として更新できる.

    DCE の認証を使用しているので, ユーザ認証に関係するコマンドは一般的なUNIX環境の場合と異なる. 表 9 に KEKCC での対応を示す.




    3.3.3. アプリケーションソフトウエア

    プログラム開発作業を行なうためにアプリケーションソフトウエアの導入は欠かせない. この種のソフトウエアは非常に多く存在しており, 数多く導入するほど可能性と利便性が広がる. その一方では, 商用ソフトを導入するためには経費と運用のために, またフリーソフトウエアの導入には運用のためにマンパワーが増大する. 限られた経費と人員で運用するために, KEKCC の主目的とする作業に欠かせないソフトウエアを整備するという観点で選択して導入している. 主なソフトウエアを表 10 に示す.

    フリーソフトは機能面やユーザインターフェイス面でよくできたものが多く存在し, KEKCCでもいくつかをインストールしている. しかし性格上, 計算科学センターや計算機メーカーが内容を保証できるものでなく, 使い方を含めてユーザ自身の責任で使用するものである.


    3.3.4. シェル環境

    ユーザの作業環境となるシェルは, Korn shell (ksh), C shell (csh), tcsh, および bash (Bourne again shell) をKEKCC での標準とした.  Kshは AT&T の David Korn らによって開発されたシェルであり, RS/6000 の OS である AIXで標準とされている. Cshは多くのUNIX でサポートされておりAIX でもサポートされている. Tcshはcshのユーザインターフェイスを改善したシェルであり, フリーソフトウエアであるので広く使われている. BashはGNU13ライゼンスのソフトウエアであり Linux で標準のシェルとされている.

    以上のシェルのうち, csh/tcshおよび bashについて, KEKCC の運用に即した標準のシェル環境設定のスクリプトを用意した. これは, 以下のことが可能であるように設計されている.

  • KEKCCの標準的な環境を, ユーザに提供する. また個々のユーザのファイルを変更せずに, ワークグループあるいはKEKCCの標準設定の変更や追加を加えることができる.

  • ファイルを適切に修正することで, 既存に設定を保存しつつ, ユーザ自身の設定, ワークグループ単位での設定, KEKCC全体での設定を追加することが用意にできる.

  • 実際のシェル環境の設定を, csh /tcshのファイルである .login および .cshrc を例にとって説明する.

    Bash については, 環境の設定のファイル .bash_profile および . bashrc を csh/tcshの場合と同様な構造で用意した.



    3.4. I/O サーバ

    データサーバやホームディレクトリサーバのファイルを, ユーザの磁気テープとの間で複写するために計算機棟のオープン利用室にI/O サーバを設けてある.

    ログインはI/O サーバのコンソールあるいはオープン利用室のX端末から行なう. 便宜のために KEKの内部のホストからもログインできるようになっている. I/O サーバは全てのワークグループの利用者が利用でき, ログインサーバと同一のユーザ環境になっている. それぞれのI/O サーバホストにはHPSS との間で効率的な転送を行なうために, 作業用のストレージとしてのローカルディスクが接続されている.

    3.4.1. 磁気テープ装置

    4台のI/O サーバホストに, DAT装置(4mmテープ装置とも呼ばれる), DLT装置, 8mmテープ装置, Sony AIT装置, およびSony DTF装置が接続されている. それぞれの装置がサポートする形式を表11 に示す.


    異なる磁気テープ媒体の間での複写, たとえばDATからDLTといった変換が容易にできるよう, それぞれのI/O サーバホストには異なる磁気テープ装置が接続されている.


    3.4.2. 装置の予約機能

    UNIX には磁気テープ装置の使用をスケジュールする機能はない. 不特定のユーザが磁気テープ装置を使用する場合には, 誤って他人の磁気テープをアクセスする事故が起こる可能性がある. 今回の KEKCC では, 計算科学センターの真鍋篤氏が作成して KEKB計算機システム14で使用されている, 磁気テープ装置の利用を管理する reserve機能を導入した.

    磁気テープ装置を利用するユーザは先ず磁気テープ装置を予約し, 利用が終了したら磁気テープ装置を解放する. 他のユーザが予約している磁気テープ装置は, その使用が終了して解放されるまで予約できない. Reserve機能には利用中の装置を, 別のユーザが予約できるようにするためのパラメータが2つある. 処理が開始されてから一定時間経過後には予約ができる. また処理が終了してから一定時間経過後には予約ができる. 前者は特定の利用者が装置を占有することを避けるためであり, 後者は処理終了後すみやかに次の利用者が使用できるようにするためのパラメータである.

    KEKCC では, 必要とする利用者が利用できるようにするという方針で, 処理中の磁気テープ装置には予約できない, 処理終了後20分経過後に予約ができるというようにパラメータを定めた. 処理終了後20分という長めの時間を設定したのは, HPSS との間のデータ転送時には準備のための時間が必要ということからである.


    3.4.3. 作業用のストレージ

    I/Oサーバに接続されているテープ装置から HPSSへデータ転送を行う際の作業領域として, I/Oサーバの各ホストに作業用の磁気ディスクが接続されている.

    HPSSにデータを送る場合には, 必要ならば磁気テープのデータを一旦作業用の磁気ディスク ("/work" 領域) に複写する. 多数の小さいファイルの場合には tar でまとめた後に, HPSSにftpで送る. また, PS実験グループの青木正治助教授が開発した, HPSS対応の dd である gudd を使えば, パイプを利用して直接に磁気テープあるいは作業用の磁気ディスクとHPSSとの間でデータの転送を行なうことができる. 以下に実行例を示す.

    作業用の磁気ディスクの領域はシステム側でストレージ管理をしていないので, 転送が終了したらユーザ自身が削除する.



    3.5.DCE サーバ

    KEKCCの分散処理環境は, DCEおよびDFS により構築している. DCEサーバは, その中の中枢部分であり, セキュリティサービス, ディレクトリサービス, DFSデータベース(FLDB)などの機能を提供している. サーバホストに障害が生じても, システム停止にならないよう, 1台のマスターサーバおよび2台のレプリカサーバの合計3台のホストで構成されている.

    このサーバにユーザが直接にアクセスすることはない. ログインサーバへのログイン時のユーザ認証, ファイルアクセス時の権限チェックなどに関与している.


    3.6.プリンタ

    プリンタは各建物に1台あるいは各階に1台を原則として, 主要な建物の端末室に配置した. 資源の有効利用という観点から, 全てのプリンタを KEKCC 固有のものとして用意するのではなく, 原子核物理計算機システム(NPCS)15 のプリンターと合わせて配置を検討した. プリンタのキューは, LPD サーバを設けて集中管理している.

    これらのプリンタに, ユーザのワークステーションやパソコンから出力したり, またKEKCCから研究グループの保有するプリンタに出力したいという要求には, LPD プロトコルに対応しているものについて, 以下の条件を満たした場合には可能としている.

  • KEKCC及びNPCSのプリンタにユーザのパソコンから出力する場合は, LPD サーバを経由してプリンタに出力する.

  • 研究グループのプリンターにKEKCC及びNPCSから出力する場合は, 申請してプリンタをLPD サーバおよびKEKCCのホストに登録する. 登録にあたっての条件は, 個人利用でなくグループで共用していること, 管理者がはっきりしていて日常的にメンテナンスされていることである. メンテナンス状況が悪く, トラブルが頻発するプリンターは登録を取り消すことになっている.


  • 3.7.X端末

    KEKCC では, 共同利用者のために端末を用意している. この端末は計算科学センターのユーザ用の端末室, 研究所あるいは研究施設の端末室に設置され, 多数の共同利用者が利用する. 数10台の端末の運用を容易に行なうためには, 簡単に初期設定の状態に戻せること, 停電などがあっても故障しないことが必要である.

    3.7.1.端末の検討

    数年前までは, 運用管理が容易なことでX端末が広く使われていたが, 現在はパソコン(PC)が非常に安くなったことや, PCに Linux を搭載することが簡単にできるようになったために, X端末が使われなくなった.

    今回, PCにXサーバを搭載して使用することや, PCにLinux を搭載することも検討した. しかしPC を端末にする場合には, 以下のような解決すべき問題がある.

  • システムを保護するには, ブートができないようパスワード保護ができる機種を導入する必要があった.

  • 変更できないようにした場合には, リブートや停止操作が必要になった場合には, 担当者がその場に出かける必要が生じる. あるいは遠隔操作の環境を構築することも考えられる.

  • OS や設定を変更できないようにするには, ユーザ管理ができるOSである必要がある. その場合には, ユーザ管理の運用が余分に生じる.

  • PC を端末にするには, 検討すべき課題が多いので, 従来通りX端末を導入することにした.

    3.7.2.NCD製のX端末

    NCD製の旧式のX端末が IBMから提供された. NCDのX端末は良く設計されていて使いやすかったが, 生産をやめてしまって新しい機種はない.

    旧式のX端末でありメモリが少ないので, 大容量のメモリが必要とする使い方はできないが, 一般的な使用法の場合には未だ十分に使えるので, 利用することにした. このX端末は以下の特徴がある.

  • 環境設定を集中管理できる.

  • 個々のユーザの操作に関する設定は, ユーザが自由に変更でき, ネットワーク設定など重要的な設定はユーザが変更できないように設定できる.

  • ユーザが自由に変更した設定は, 再立ち上げで初期状態に戻せる.

  • X端末から遠隔ホストへの接続形態は, telnet あるいは xdm を選べる. 接続先を自由に指定できる.

  • 3.7.3.MiNT-ACC の運用

    株式会社高岳製作所は MiNT-ACC16 というX端末を製作している. これは調査した中で唯一のX端末だった. このX端末は環境設定を端末の ROM にローカルに持っている. 設定にはパスワード保護をすることができる. KEKCC の端末として運用する以上, ネットワーク設定などをユーザが変更できないようにパスワード保護が必要である. しかし, パスワード保護をかけると, 同時にユーザの操作に関する項目を含めて一切の設定の変更にパスワードの入力が必要になる. そのために, 運用方法の検討が必要だった.

    NCD製のX端末で可能である, 任意のホストにXDMでログインすることや, local の telnet ウィンドウからログインするといったことを, ログイン時にユーザが選択することができない. 端末の環境設定時にダイレクトタイプあるいはブロードキャストタイプと呼ぶ2種類の方式について検討した.

    ダイレクトタイプの場合には, 固定的にある特定ホストに xdmでログインする. ブロードキャストタイプの場合には, X端末を接続する同じネットワークセグメントに存在するXDMサーバ, つまりFI, FJ, AT, GE といったネットワーク内の xdm サーバがリストされ, ユーザはその一覧の中からログイン先を選択するといった利用法になる.

    KEKCCの一部として導入した端末なので, 前者のダイレクトタイプを標準設定とし, 接続先をログインサーバとした. ワークグループによっては研究グループの事情によってブロードキャストタイプに設定されている.


    4. 運用の方針

    4.1.ワークグループ管理者

    ワークグループの代表者として, ワークグループ管理者を設けた. システムの運用に関しての計算科学センター側との連絡および調整, およびワークグループに割り当てられた資源のサブグループへの再配分が主任務である.

    サブグループ内のユーザの管理と資源の管理を行なう代表者として, サブグループ管理者を設けた.


    4.2. ユーザ管理の方法

    KEKCC の利用は研究グループを基本としている. 研究グループが登録を申請する場合には, 最も近いと思われるワークグループの管理者と相談する. その研究グループがワークグループのメンバーとして妥当がどうかの判断はワークグループ管理者が行なう.

    研究グループの利用が認められてサブグループとして登録された後には, そのグループ内の個々のユーザの管理はサブグループ管理者が行なう.

    ユーザのホームディレクトリの上限値についての方針は, ワークグループ管理者が定める. 個々のユーザの申請の可否はサブグループの管理者が行なう. システムへの登録作業は計算科学センター側で行なう.

    複数の研究グループに属して研究活動しているユーザの場合には, 複数のサブグループに属したり, 複数のワークグループに属した方が, ファイルのアクセス管理や資源の管理が自然に行なえるので, これをサポートすることにした. しかし運用面から検討した結果, いくつかの問題がでてきた. これを解決するために以下のように運用方針を定めた.

  • ホームディレクトリは最初に登録したワークグループの領域におく.

  • 最初に登録したサブグループを, primary group とする. これは原則として変更しない.

  • ログインは primary group で行なわれる. DCEの仕様として, セッションのgroup を変更できない. 従ってセッションは常に primary group である.

  • ユーザが作成したファイルの所有グループは primary group になる. 必要に応じてユーザ自身が chgrp で所有グループを変更する.

  • LSF によるジョブの投入は primary group で行なわれる. ログインサーバのワークグループに対応した計算サーバにサブミットされる. 従って, 複数のワークグループに所属する場合には, サブミットを行なうログインサーバを使い分ける.


  • 4.3. ワークグループ管理者の権限

    ワークグループ管理者は自ワークグループに割り当てられたホームディレクトリ領域, グループファイル領域, ワークグループライブラリ領域, HPSS領域について,管理運用を行なえるようにした. 以下にその内容を掲げる.

    1. ホームディレクトリ領域
    2. グループファイル領域
    3. HPSS領域
    4. ワークグループライブラリ領域
    5. LSF関係

    4.4. 利用に関する申請事項

    計算機利用にあたって通常発生する申請事項を表13 に示す. 頻度の高い申請事項については, 申請書を用意した. 申請書は計算科学センターの事務室および Web 上に置いてある. 頻度の低い事項については申請書を用意しておらず, 申請は電子メイルで行なう.




    4.5.サポート体制

    4.5.1.コンサルト

    システムの異常動作や使用方法の問い合わせのなどの一般ユーザからのコンサルトは電子メイルで受け付けている. 受付窓口は, 計算科学センター (以下センターと略す) の他のサービスと同様に consult @kek.jpに一本化されている. ここで内容により振り分けられて KEKCC 関係の場合には, センター内部のメイリングリスト(以下MLと略す)であるkekcc-QA に転送される. このMLは, センターの担当者とIBMのシステムエンジニア (以下SEと略す) がメンバーになっている. メイルは全て保管されており, 関係者およびワークグループの管理者はWeb経由で参照できる.

    運用に関するワークグループの管理者との連絡のために, 一般ユーザを対象としたコンサルトとは別にkekcc-support@ccoper.kek.jp というMLを設けた. このMLは, センターの担当者, 運用管理室, SE, およびワークグループ管理者がメンバーになっている. 運用に関するシステム管理者側からの連絡や問い合わせ, ワークグループ管理者からのパラメータの変更依頼などに使われる. メンバーのみ投稿可能であり, メイルは保管されてメンバーがWeb経由で参照できる.


    5.5.2.システムの監視体制

    システムが異常状態で停止した場合に速やかに対処できるよう, 以下のシステム監視を全ホストで1時間に1回行っている.

  • pingによるホスト稼動状況監視
  • ハードウェアのパーマネントエラーが発生しているか
  • OSの稼動に影響するファイルシステムの使用量が80%を超えているか
  • ユーザサービスに不可欠なプロセスが落ちているか
  • RAIDディスク(ユーザホームディレクトリ領域, HPSSステージング用の磁気ディスク領域)がdegrade(RAID5構成の磁気ディスクのうち1台が動作不能となっている状態)しているか
  • ミラーリングしている磁気ディスク(システム領域)の1台が動作不能となっているか
  • HPSSログにSeverityがCRITICALあるいはMAJORのエラーが出ているか
  • 4.5.3.障害時の対応体制

    停電や電圧の変動の影響を減らすために, 無停電電源装置(Unstopped Power Supply, 以下UPSと略す)を導入している. このUPSからの停電信号を受け取り, 自動的にシステムを停止するための遮断ソリューションシステムが組み込まれている. UPSから停電信号を受け取った遮断ソリューションは, この信号が3分以上継続した場合には自動的にシステムのシャットダウンを行なう. 但し, UPS電源容量の制約から, この場合のシャットダウンはOSのシャットダウンのみで, その上で稼動しているHPSS, LSF, DCE/DFS の正常停止は行なわれない.

    「システムの監視体制」で述べたpingによるホスト稼動状況監視は, 遠隔監視システムで行われており, 必要であればいつでもSEに連絡を取れる体制をとっている. 異常が発生した場合には, 通常業務時間帯には直ちに復旧作業に取りかかる. それ以外の時間帯のときには, 二重化されていないホストでは1時間以内に復旧作業に取りかかる. 二重化されているホストでは機能縮小状態で運転を行ない, 通常業務時間帯に復旧作業を行なう.



    4.6. システムの情報提供

    システムに関する情報は Web により公開している. システムの運転スケジュール, 利用の手引き, Webマニュアル, 運用統計, KEKCC 関連の打ち合わせのメモ, システムの設計仕様書, 作業報告書などがある.

    情報のレベルにより, 一般に公開, 関係する大学研究機関からのみアクセス可能, KEK内のホストからのみアクセス可能としている. 一部の情報はパスワード付きで限定公開となっている. システムの運転スケジュール17は, 特に安定して情報を提供できるよう機構の Web システムから発信している.


    4.7. 運用委員会等

    運用状況の報告および運用に関する問題点の検討は, 年に1回程度開催される運用委員会, 2ヶ月に1回に開催される計算機ネットワーク業務委員会, 毎月開催される KI (KEK-IBM) 連絡会で行なうことにした.



    5.システム導入の作業

    5.1.タスクフォース

    システムのリプレースに向けて, 計算科学センター内に新システムの骨格のデザインを検討するためのタスクフォースが, 1998年11月20日に川端, 真鍋篤氏, 柴田章博氏, 佐々木, 八代をメンバーとして設けられた. これが, 新システム検討の始まりになった. このミーティングは表15 に示すように, ほぼ毎週開かれシステムデザインの骨格が検討された. その後, タスクフォースでの検討結果を基にして, 仕様策定委員会に先立ち市場の動向調査を行なった.


    5.2.仕様策定作業

    仕様策定に関係する作業は, ユーザの重要の調査, 資料提供招請 (市場調査), 仕様書案の作成, ベンチマークプログラムの作成, 仕様書の作成等の作業からなる. この一連の作業の間, 市場調査などの結果をみながら, ユーザの必要とするものを満たすシステムを実現させうる構築可能な計算機システムを検討してゆく. 技術の進歩が激しく, 検討している最中にも製品が代わってゆくことと, 導入したのち5年間の使用に耐えるシステムとしなければならないことが, 検討を困難にした.

    導入のための仕様策定委員会は, 1999年6月17日から2000年4月4日にかけて, 合計9回開かれ, 各研究グループの計算機の需要調査, 市場調査, 仕様書原案の作成, および仕様書の作成を行なった. 2000年8月3日に技術審査委員会を開き, 仕様書に対する各社からの提案の審査を行なった. 委員会の日程は表16 を, 委員の一覧は表17 を参照のこと.

    今回は, 計算機による文書処理を合理化するために, 資料提供招請書案, 仕様書案, 仕様書を電子ファイルで業者に配布し, また, 提案書を電子ファイルで提供するよう依頼した. これは業者からも歓迎され, 全ての会社から電子ファイルの提供があった.






    5.3.システム導入作業

    5.3.1.作業の分担

    導入するシステムが決まった2000年8月11日の直後から, 計算科学センターの担当者と日本アイ・ビー・エム株式会社(以下IBMと略す) の担当者との間で, システム構築のための打ち合わせを開始した. 運用開始までの5ヶ月という短期間で導入を完了させるために, 表18 に示すように, システム基幹(基本設計, サーバの配置の設計, データサーバの設計, ファイルシステムの設計, その他), 設備関係(機器の配置, 電源の準備, 空調の準備), ネットワーク, バッチ処理(LSF), メイルシステム, Webシステム, I/O機器(I/Oサーバ, X端末, プリンタ), システムの移行(データの移行, アカウントの移行), 利用の手引き作成, と分担してワークグループを作り, システムの検討および導入作業を行なった. この分担表の中には, データ解析システム以外の, PostKEK メイルシステム, [12] 18, 機構用 Web システム (ccwww.kek.jp), 研究情報 Web システム (research.kek.jp) の分担も含まれている.



    導入作業は, 短期間で効率よく進めるために, 電子メイルでの打ち合わせとWebによる情報の交換を基本にして行なった. 関係者全員による打ち合わせは月に1度行ったが, これは全体の進行状況の確認にとどめた. 実質的な打ち合わせは, 各分担グループ毎に電子メイルを利用して行ない, 必要に応じてミーティングをもった. 電子メイルの内容および打ち合わせに使用する資料はWebに掲載し関係者全員が参照できるようにした. 分担以外のグループでの検討内容を知ることができ, 必要に応じて議論に参加できた. ミーティングを基本にした過去の導入作業に比べて時間と労力を軽減して作業を進めることができた.


    5.3.2. HPSS導入の準備

    特に HPSS については, KEKCC の中で重要な位置を占めるものであり, 全く新規に導入するソフトウエアなので, 開発元でありサポートを担当している Houston の IBM's Global Government Industry(以下Houstonと略す)19 のメンバーと綿密な打ち合わせを行なった. 2000年9月には佐々木, 八代がHoustonを訪問して, 実験データの解析におけるデータストレージの使い方および新システムの運用方針を説明した. Houston側からは, KEK の使用方法に適したシステムの設定の提案がなされ, HPSSの骨格が決まった.

    その後, インデアナポリス大学の Advanced Information Technology Laboratory20 を訪問して, HPSS を DFS インターフェイスで運用することの経験と留意点について調査してきた. 彼らの指摘により, 当初予定したDFS インターフェイスを archived mode とする設定では, KEK の希望する動作を得られないことが判明し, mirrored mode に変更することになった. この変更を運用開始後に行なうことになれば, 単純な設定の変更で済まずに, 全データの入れ直しになっていた.

    続いて SLACを訪問して, HPSSの運用状況を調査してきた. SLACでは, 記憶装置として磁気ディスクを使用せずに, 磁気テープだけで運用していた. 磁気テープ装置のトラブルが年に1p~2回あり, 装置を使用中のユーザプログラムが停止する問題が述べられた.

    2000年11月にはHoustonのメンバーが来所した際には, KEKCCのユーザ代表とのミーティングを開き, KEKCCでの使い方について議論を深めた.


    5.4. システムの移行

    旧システムから新システムへのデータの移行作業は, センター側で行うか, あるいは従来の方針にしたがってユーザ自身が行うということにするかを検討した. データの移行はある限られた一定の期間内に大量のデータを限られたデーターパスを使って, しかも一方のシステムは運用を継続しながら行なうことになる. データ量と日程を検討した結果, 各々のユーザが自分のデータを移行するのでは混乱が生ずることが予想されたので, 原則的にセンター側で行なうことにした. だたし, センターで行なう作業には保証できる範囲に限界があるので, 非常に重要なデータについては各自が移行することを求めた.

    移行対象となるデータの種類は, 磁気ディスク領域にあるデータ, 階層型ファイル・システム(HSM)上のデータ, 磁気テープ上のデータ, メイル・スプールにあるデータの4種類であった. 磁気ディスク領域にあるデータは, データ移行のパスを確保すること以外は問題がなかった. HSM上のデータは磁気テープにマイグレートされているデータを一旦磁気ディスクに持ってくる必要があるので, 綿密なスケジュールを立てて移行作業を実施した. この間はユーザがデータをアクセスするときには調整を行ない競合をさけるようにした. HSMのファイル形式である VBFSでなく, 直接に磁気テープ上に書かれたデータは, 新システムに接続したテープドライブから直接に読み込んで移行させた. メイル・スプールはサイズは小さく, また個々のユーザの所有という性格が強いことから, 個々のユーザが移行作業をすることにした.

    データ移行の概略図を図5 に, 移行作業に要した期間を 表19 に示す. データ移行の詳細は付録2 を参照のこと.







    6. あとがき

    導入は本文で紹介した方を含めて多くの方の参加と協力によって進められました. 計算科学センターのセンター長渡瀬芳行氏, 鵜飼熊太郎氏およびその他の方々, 日本アイ・ビー・エム株式会社の大塚薫氏, 増田佐保氏, 石原正三氏, 伊藤義彦氏およびその他の方々, 日立情報システムズ株式会社の方々, IBM HoustonのHarry Hulenおよびその他の方々に感謝します.  仕様策定委員会および技術審査職員の方々に感謝します.  HPSSの設定に関して貴重な情報を提供してくださったインデアナポリス大学のGustav Meglicki, Anurag Shankerおよびその他の方々, SLACの方々に感謝します.

    磁気テープ装置の予約機能を提供してくださった真鍋篤氏に感謝します. HPSS のユーザとして運用方針の設定にあたって貴重な意見を寄せていただき, またCERNLIB とHPSS の連携について検討してくださった青木正治氏(現大阪大学)および山p~光裕氏に感謝します.


    参考文献


    FOOTNOTE