レベル: 中級 Vallard Benincosa, Certified Technical Sales Specialist,
IBM
Egan Ford, Linux Cluster Executive IT Specialist,
IBM
2008年 10月 22日 クラスターの意味は人それぞれに違います。この記事のコンテキストで言うと、クラスターに最適な定義はスケールアウトです。通常、スケールアウト構成のクラスターには Web ファーム、レンダー・ファーム、ハイパフォーマンス・コンピューティング (HPC) システムなど、同じタイプのコンポーネントがいくつもあります。管理者たちは、スケールアウト・クラスターで変更を行うとなると、それがどんなに小さな変更であれ何十万回と変更を繰り返さなければならないと言うでしょう。その一方、極めて怠惰な管理者たちはスケールアウトの管理技術をマスターしているため、ノードがいくつあろうと作業量は変わりません。この記事の著者たちが、そんな極めつけの怠け者である Linux® 管理者の頭の中を覗き込み、彼らが作業を減らす秘訣を解き明かします。
1998年、世界の最速コンピューターのトップ 500 に初めて登場してからというもの、Linux クラスターは目立たない科学実験という位置付けから、スーパーコンピューティング技術における今日の支配的勢力という地位にまでのぼりつめました。事実、トップ 500 に掲載された Linux クラスターの数は 1998年には 1 つのシステム (1 つのクラスター、1 つの Linux OS システム) だけでしたが、2008年にはリストの 5 分の 4 (400 のクラスター、458 の Linux OS システム) を占めています。
Linux クラスターを管理するには、単一のシステムや小規模なネットワーク・システムの IT 管理者が普段使うことのないような独特のスキルが必要です。具体的には、ネットワーキング、オペレーティング・システム、そしてアーキテクチャーに存在するほとんどすべてのサブシステムについての深い知識が必要となります。
それだけではありません。管理に対する態度も変えなければなりません。なかでも特に必要なのは、怠け癖です。管理者は、Scrooge McDuck が田舎町にいる彼の甥に言ったことを実践しなければなりません。それは、「がむしゃらに働くのではなく、要領良く働く」ということです。
この記事では、極めて怠惰な Linux クラスター管理者たちが要領良く働くために使っている選り抜きの秘訣を説明します。秘訣と言っても、とてもそう呼べるほどのものではないのですが、どういうわけか人々はこれらの考え方を理解しないか、あるいはその効果を過小評価しています。そんな誤解を解くため、それぞれの秘訣をその重要性と併せて説明します。
The secrets are
- ここで紹介する秘訣は以下のとおりです。
- わざわざ一からやり直さないこと
- オープンソースを利用すること
- 何もかも自動化すること
- スケーリングに対応するように設計すること (最初から怠けることを計画する)
- ハードウェアを管理しやすいように設計すること
- 優れたクラスター管理ソフトウェアを使用すること (時間のかかる細かい作業をしない)
- オープンソースの監視ソリューションを利用すること
- キューイング・システムを使ってユーザーを制御すること
- 払った額に見合うものを確実に手に入れること (ベンチマークを実行する)
- クラスター通信を管理すること
- さらに怠けるための方法を探すこと
1. わざわざ一からやり直さないこと
怠惰な Linux クラスター管理者は一から何かを作り出すことはしません。彼らが重点を置くのは、他人の作業を土台にすることです。無料でサポートされるソリューションが既にあるのなら、わざわざアプリケーションを作成して時間を無駄にすることはありません。
独創的なアイデア、あるいは他に例のない問題というのは、世界では極めてまれなことです。これは、特に Linux クラスターの世界には当てはまり、2004年から今に至るまで、取り組まれたことのない構想や解決されていない問題はほとんど見当たらないはずです。だからと言って、自分が取るに足らない存在であるとか、独創性に欠けた人間だと思うことはありません。逆に、解決できない問題などというものは存在しないと自信を持つべきです (もちろん、政治的または社会的にではなく、技術の点から言った場合の話ですが)。ほとんどの問題とそのソリューションはすでに認識され、診断され、解決されているという事実を受け入れてください。
時間の無駄を少なくするために、有能な管理者は以下の作業に時間をかけます。
- 既存のソリューションを調査して独自のニーズに適応させる作業。アイザック・ニュートンはフランスのシャルトルの学者ベルナールの言葉を引用し、自分の業績は「巨人の肩の上に立ったものだ」と言及しました。ニュートンがまずユークリッドの原論を理解し、それを基に理論を発展させていなかったとしたら、世界がいかに大きな損失を被っていたかを想像してみてください。
- すでに行われたことをもう一度はじめからやり直すのではなく、オープンソース・プロジェクトを提供、あるいはカスタマイズするための作業。管理者は自らがソリューションを作成したとすると、他には誰もその内容を理解しないことから、自分が新しい仕事に移るとそのソリューションがまもなく使えないものになってしまうことを十分認識しています。
私たちは皆さんの独創力を抑えつけようとしているのではなく、むしろその逆です。他人がすでに成し遂げた業績をさらに改善することによって、自分たちの環境を他の組織よりも遙かに優れた効率的な環境にすることができます。
2. オープンソースを利用すること
私たちが今まで一緒に仕事をした Linux クラスター管理者のなかでもとりわけ成功している管理者たちは、現在活動中のオープンソース・プロジェクトについて広範な知識を持っています。彼らはメーリング・リストに頻繁に貢献しており、インターネットで現在のプロジェクトを検索すると、そのプロジェクトに関連する名前として彼らの名前が見つかるはずです。彼らは常に、http://sourceforge.net や http://freshmeat.net に投稿して、興味をそそる新しいプロジェクトを探しています。
オープンソースのツールには、ツールを支持する人間以上にツールを生き延びさせる特質が備わっています。よく使われているツールでは、この特質が一層、顕著になります。Ganglia、Nagios、TORQUE などのツールは登場してから長いこと経ちますが、それでもまだ現役で使用されているのにはもっとも理由があります。これらの優れたツールでは、ソフトウェアのコストとライセンス方式の管理を省けるからです。
極めて怠惰なクラスター管理者は、オープンソースにかなり熱心で、個人的な趣味にも使用しているというもう 1 つの側面を持っています。彼らは例えば、自宅の Web サーバーや、自分専用の Linux ノートブックで実行するアプリケーションなどにもオープンソースを使用しています。Pidgin から Firefox に至るまで、極めて怠惰な Linux 管理者たちは職場で管理しているクラスターとは別の生活の一面で Linux を実行しています。
3. 何もかも自動化すること
Linux 管理者の道具箱でかなりの部分を占めるのは、コマンドライン上で使うスクリプトや、その他簡単に作成したツールです。スクリプトは (何も作り直さない限り) 2 つの有益な結果をもたらします。
- 第一に、何よりも明らかなのは、入力する手間を省き、繰り返し使えるパターンを提供することです。
- 第二に、スクリプトはそれ自体が文書となるので、後で参照することができます。
熟練した管理者のマシン上には、今までに作成したスクリプトを納めたディレクトリーがあるのが、ごく一般的です。これらのスクリプトで、ノードのファームウェア・バージョンのチェックから InfiniBand クラスターでの GUID のマッピングに至るまでのあらゆることに対処します。
スクリプトを作成するのにまさにぴったりの例は、オペレーティング・システム・イメージを生成するスクリプトです。これは、イメージがステートレスであろうと、ステートフルであろうと関係なく当てはまります。管理者が「ゴールデン・イメージ」をシステム上の各計算ノードに伝搬しなければならない場合、その管理者はその内容を知っていなければなりません。そこで、イメージを作成するスクリプトを用意すれば、利用可能なドキュメントのなかでも最高のドキュメントになります。なぜなら、スクリプトは何が行われるかを正確に説明し、しかも繰り返し使えるからです。スクリプトを使用しないでイメージを作成すると、イメージが膨れ上がり、スペースを使い果たしてシステムの処理速度を落とす結果になります。
2000年から温めてきたゴールデン・イメージをいまだに手放さない組織が、あまりにも多すぎます。その最大の理由は、どうやって作成し直すのかがわからないからです。第二の理由は、おそらくこれが最も妥当な理由だと思いますが、アプリケーションはそのイメージでテストされて「認定された」からです。この認定という言葉は、クラウド・コンピューティングという言葉の定義に引けを取らないほど意味が漠然としています (ちなみに、クラウド・コンピューティングという言葉は特許を取った言葉でも、商標付きの言葉でもありません)。
なぜ自動化するべきかと言えば、その要点は、自動化では実際に行う作業に対してよりも、作業を省くことに頭を使うからです。怠惰な Linux クラスター管理者は、頭をいっぱいにしてしまうような作業は受け付けません。例えば、クラスター内のすべてのマシンに SSH 通信でコマンドを実行するとしたら、それは十分に怠けているとは言えません。ノードに対するすべてのコマンドは、パラレル・コマンドやプロシージャーを使って一挙に実行するべきです。ハードウェア・ベンダーに BIOS 更新やサブシステムのフラッシングを自動化する Linux ツールがないのであれば、その点を入手価格の計算に入れてください。
前回の記事「怠惰な Linux: 管理者に必須の 10 の秘訣」の秘訣 8 と 10 に、私たちがよく使ういくつかのコマンドラインのスクリプト技術を説明しています。方法は他にもたくさんあり、そのうちの一部はより効率的ですが、前回の秘訣は、スクリプトで何ができるかの概要を説明しているに過ぎません。
4. スケーリングに対応するように設計し、最初から怠けることを計画すること
秘訣 3 (なにもかも自動化する) は素晴らしい目標ですが、完全な怠惰に至る過程のなかの 1 歩でしかありません。極めて怠惰な管理者にとって、完全な怠惰を実現する唯一の手段は、自律スケールアウト管理です。これを追及する最初のステップとなるのは、スケーリングしない操作に影響されることのないシステムです。
大掛かりなスケールアウト・クラスターは、ボトルネックに悩まされます。それは、ほとんどのスケールアウト管理者は、ネットワークを起動したり、大規模なマシンのセットをインストールしたりするのに TFTP を使用するという点です。経験を積んだスケールアウト指向の管理者の誰もが言うように、TFTP は信頼性に乏しく、スケーリングできません。適切なリモート・ハードウェア制御がなければ、大規模な TFTP の障害によって怠惰な管理者が実際に椅子から立ち上がり (あるいはベッドから起き上がり)、(自宅ではなく) データ・センターまで徒歩で (あるいはヒッチハイクで) 赴き、マシンのそれぞれをすべてリセットするはめになります (時間のかかるつまらない仕事です)。適切なリモート・ハードウェア制御があったとしても、怠惰な管理者はそれまでプレイしていた WoW (オンライン・ゲーム World of Warcraft の略称) をわざわざ中断して、小さな塊ごとにノードをリセットするコマンドを定期的に実行し (これもまた、時間のかかるつまらない仕事です)、システムを立ち上げる必要に迫られます。
しかし、ちょっとした事前の計画管理によって、以下のようなボトルネックは避けることができます。
ボトルネック 1: プロビジョニング・サービス
クラスターのプロビジョニングに最もよく使われるサービスは、DHCP、TFTP、HTTP、NFS、そして DNS です。このそれぞれにはスケーリングに関しての限界がありますが、なかでも TFTP は最悪です。それでも幸いなことに、これらのサービスはスケーリングを支援するためにすべて簡単に複製することができます。
秘訣: DHCP と TFTP を別の NIC に分けると、スケーラビリティーが劇的に向上します。例えば、TFTP のスケーリングを測定した結果、他のプロビジョニング・サービスと NIC を共有する場合には 40:1 でしたが、サービスやステートレス・ブートを共有しない場合には 80:1 となりました。
ボトルネック 2: ネットワーク
ネットワークは、設計のなかで最も見過ごされがちな部分です。ここで言っているネットワークとは、管理に使用する GigE (ギガビット・イーサネット) ネットワークのことで、アプリケーション・トラフィック専用のハイパフォーマンス・ネットワークのことではありません。多くの場合、データと管理に必要な共有ネットワークは 1 つだけですが、これがスケーリングの問題を作り出します。
階層型ネットワークを設計するときには、あまりにも大量のノードがファブリックに接続されることのないように注意してください。例えばノードとサービス・ノードの比率として 80:1 を要求されている場合には、ファブリック全体でこの比率を維持するか、またはそれを超えるぐらいになるようにしてください。
ボトルネック 3: 自分の能力以上のことをしようとしないこと
私たちがスケールアウト・クラスターを設計するときには、クラスターのクラスターという手法を取っています。これは、それぞれのサブクラスターすなわちスケーラブル・ユニット (SU) を 1 つのビルディング・ブロックとし、その SU のなかで、すべてのクラスター操作 (例えばインストール、ネットワーク・ブート、BIOS フラッシング、監視など) に応じてスケーリングするという手法です。各 SU には (SU のサイズに応じて) 1 つ以上のサービス・ノードがあり、それによって SU 内のすべてのノードを制御、監視、プロビジョニングするために必要なサービスを提供します。スケーラブルな管理をさらに支援するため、SU ごとに固有のブロードキャスト・ドメインがあります (SU 間の通信、および SU と世界との通信がルーティングされます。ボトルネックをチェックしてください)。
中央管理ノードとサービス・ノードには、専用の物理ネットワークまたは仮想ネットワークがあるため、サービス・ノードからの情報の集約とサービス・ノードに送られるデータとが、他のクラスター・トラフィックと競合することはありません。私たちはこのネットワーク、管理ノード、そしてサービス・ノードを階層型管理クラウド (HMC: Hierarchal Management Cloud) と呼んでいます。そのセットアップと操作はもっぱら、管理者の領域です。
クラスターのクラスター手法では、怠惰な管理者が予算を超えてスケーリング可能なシステムを設計し、その同じ管理者が大量の操作が失敗することを恐れずに中央での制御をすることができます。
5. ハードウェアを管理しやすいように設計すること
私たちが驚かされるのは、クラスターを設計するときに「完全自動」に関して考慮しない管理者の多さです。有能な管理者は完全自動クラスターを操作しています。つまり、管理者が毎日操作する物理マシンの実物を目にする必要が出てくるまで、クラスターは人気のない暗い部屋に何週間も何か月も放置されます。さらに管理者が地球の反対側からマシンを管理しているとしたら、マシンを目にすることは一度もないでしょう。当然のことながら、とびきりの怠け者はデータ・センターがどこにあるのかさえ知りません。彼らにとっては、データ・センターとは単なるホスト名あるいは IP アドレスの集合なのです。
データ・センターは、機器や装置の出す音がうるさく、時には寒く (また、危険かもしれません)、怠惰な管理者にとっては何としても避けなければならない場所です。さらに、何台ものマシンが置かれた部屋には、まだ見つかっていない健康上有害な物質がないとも限りません。電力費、冷却費、人件費が上がるにつれ、データ・センターを管理費の低い場所に移す傾向が進んでいます。その点を考慮すると、当面は、完全リモート制御を可能にすることが Linux クラスターを管理する上での必須事項だと考えなければなりません。
ハードウェア・ベンダーのほとんどは、システムをリモートから管理するための標準を求める顧客の要望に従ってきました。現在、ほとんどの Linux クラスターで管理標準となっているのは IPMI (Intelligent Platform Management Interface) 2.0 です。IPMI は、リモートからマシンの電源オン/オフを行い、リモート・コンソールの表示画面で BIOS からのマシンのブートを確認する方法を提供します。私たちはある顧客の現場で、快適なオフィスにいながらにして、60 マイル離れたところにあるマシンのトラブルシュートをすることができました (この顧客も怠惰な Linux 管理者の一人で、彼のオフィスにある照明と言えば、壁に掛けられたネオン・サインだけです。独身者の住まいと化したオフィスには、栄養ドリンクと甘みのついたスナックでいっぱいの 2 台の冷蔵庫も備わっていました。言うまでもなく、私たちはこのオフィスから離れたくはなかったわけです)。
強力な IPMI によって、すべてのクラスターでセットアップすべきマシンを実際に見ることもなく、BIOS 設定を変更し、ノードをリブートし、ノードが起動する様子を観察して画面のダンプで確認することができました。このように、怠惰な管理者には少なくとも以下の 2 つが常に必要です。
- リモートからのマシンの電源投入
- 発生する可能性のある、起動に関する問題を確認できるリモート・コンソール、またはそれよりも優れたマシン表示機能
IPMI を使用する場合、おそらく管理ノードであることを抜かせば、見事な IPMI 実行用インターフェースしか提供しない他のボックスを Linux クラスターの領域に追加する必要はほとんどありません。代わりに推奨するのは、ほとんどの Linux ディストリビューションにすでにパッケージ化されている ipmitool のような標準オープンソース・ツールです。とびきり怠惰な Linux クラスター管理者になれるかどうかは、このコマンドラインにかかっています。
ただし、リモート・コンソールに関する IPMI の信頼性については議論の余地があります。実際にアウト･オブ・バンドのターミナル・サーバーが有益な場合があることは認めざるを得ません。Cyclades ACS48 などのターミナル・サーバーは投資するだけの価値があり、IPMI では実現しきれないアウト･オブ・バンドによるアクセスと信頼性を提供します。
その上、IPMI 1.5 は正直なところ、最も信頼性の高い IOHO と言えるものではありませんでした (これは業界全体で問題になっていたことです)。IPMI 2.0 はそれよりも遙かに改善されているため、多くのベンダーは IPMI 2.0 を手の込んだ Web ページで囲み、アウト･オブ・バンドであるかのように見せています。ターミナル・サーバーを組み込むか、またはターミナル・サーバーを組み込まずに IPMI をマシン上でネイティブに使うかどうかについては議論があります。ほとんどの顧客の思考の流れは次のようになります。怠惰な Linux 管理者の誰もが、全ノードの 95 パーセントが順調に機能していても、残りの 5 パーセントのトラブルシューシュングにかなりの時間がかかることを知っているはずだ。だとしたら、インフラストラクチャーの代わりに、ノードを予備として 5 パーセント多めに購入したほうが賢いのではないだろうか。これはつまり、インフラストラクチャーよりも計算能力に多くの予算をつぎ込むことになるはずだ。
これに対する反論は、1 台のターミナル・サーバーによって、ノードのトラブルシューティングをするために飛行機で国の端から端まで旅する必要を省けるのであれば、費用をかける価値はあるという意見です。この点についての判断は怠惰な Linux 管理者に任せることにします。結局のところ、飛行機に乗らなければならいのは Linux 管理者自身です。私たちとしては、どちらも説得力のある意見だと思います。
6. 優れたクラスター管理ソフトを利用して、時間のかかる細かい作業を省くこと
クラスター・ツールは 1999年に Linux クラスターがインストールされ始めた頃に比べ、大幅に進歩しています。その当時、使用できるクラスター管理ツールは数少なく、そのためほとんどの管理者は自分で一連のツールを作成し、クラスターのデプロイメントと監視、管理に使っていました。
極めて怠惰な管理者は、オープンソースのツールを使用しているか、1999年に自分たちが開発したツールをコミュニティーで使用できるようにしているかのいずれかです。オープンソースのツールで不足を補えないほど独特の環境を使っている人はほとんどいません。大抵、自作のツールを擁護する管理者は一匹狼で、その管理者が組織を離れると管理者が作成したツールも使われなくなってしまいます。その一方、カスタマイズしたオープンソースのツールが有効に機能しているところがたくさんあることも、私たちは認識しています。
自作のツールに満足できない場合、あるいはそれよりも優れたツールを探している場合には、いくつかのオープンソース・ツールを調べてみてください。クラスターの管理に有力なツールには OSCAR (System Imager)、ROCKS、Perceus、そして個人的な好みとしては xCAT 2 がありますが、いずれもオープンソースのツールです。
現在最もよく使われているオープンソースのクラスター・デプロイメント/制御ソリューションは、おそらく ROCKS でしょう。ROCKS を作成し、管理している UCSD は、クラスターをユーザー・フレンドリーにする上で素晴らしい成果を上げています。唯一不満を挙げるとしたら、このツールには主に OS レベルでの柔軟性が欠けていることです。ROCKS は Red Hat ディストリビューションをベースとしています。これは、多くの人々にとって問題ありませんが、SUSE を使用している場合や、RH (Red Hat) 6.2 ディストリビューションをベースに作成したイメージを使いたいという場合にはその限りではありません。さらに ROCKS は、多くの IT 組織が使用しているクローン作成ソリューションではありません。
Perceus も同じようなソリューションですが、ステートレス・インストールという点で ROCKS とは異なります。この記事での説明のためにステートレス・コンピューティングを定義すると、これは、オペレーティング・システムをディスク上に保持する代わりにメモリー内で実行するということになります。ディスクは必要ありませんが、ローカル・スクラッチやスワップにディスクを使用することはできます。
利害関係を抜きにして (完全な情報開示をすると、私たちはコードを提供して積極的に xCAT を開発しています)、私たちが xCAT で気に入っているところは、柔軟性とスケーラビリティーに優れていて、他のどのツールよりも処理能力が高いという点です (しかも、非常にハンサムで賢いコントリビューターたちの後ろ盾もあります)。この世で最も高速なスーパーコンピューター、LANL RoadRunner システム (これは Cell/B.E.™/Opteron™ のハイブリッドで、初の 1 ペタフロップス・システムであり、初の 1 ペタフロップスの Linux クラスターでもあります) は、xCAT によって管理されています。
xCAT では、ほぼすべてのエンタープライズ Linux ディストリビューションにイメージング、kickstart、autoyast、iscsi、およびステートレスを使用できます。しかも、リモートでの電源操作からコンソールのセットアップに至る IPMI コマンドを抽象化するコマンドライン・ツールが備わっており、抽象化したコマンドを同じ 1 つのフレームワークで使用します。xCAT は 1999年10月から積極的に開発が進められ、2007年に IBM によってオープンソースとなりました。
ここまで xCAT の優れた点を紹介しましたが、公平を期して xCAT の欠点についても触れておきます。
- セットアップが難しいかもしれません。これほどまでに柔軟性が高い xCAT には、構成可能なパラメーターが数多くあります。私たちはセットアップを容易にするためのウィキを設けており、さらにメーリング・リストや IRC チャネルを介した充実したサポートがあります。
- 時代遅れとなった xCAT 1.3 を完全に作成し直した xCAT 2 には、解決しなければならない機能の問題があります。
- 多くのオープンソース・ツールと同様、ドキュメントには改善の余地があります。
クラスター管理ソリューションは他にもたくさんあり、Emacs を使用するか、vi を使用するかについても議論するのは簡単です。しかし、私たちの結論としては、ツールのアイデアや他に優れたツールを探しているのであれば、xCAT を試してみることをお勧めします。
7. オープンソースの監視ソリューションを利用すること
昨年の SC'07 で、私たちは米国トップレベルの研究所のいくつかと、Linux クラスターを監視する上での難題について話し合いました。その結果、2008年の初めには、この問題についての討議に何回か呼ばれることになりました。監視が難しい理由には、以下の点が挙げられます。
- クラスターが大規模になるにつれ、収集されるデータが多くなることから、監視情報を受信するマシンでのパフォーマンスに影響が出てきます。例えば 2,000 台のマシンがあり、そのそれぞれが 1 つのインフラストラクチャー・ノードにメトリックスを送信するとしたら、そのノードは圧倒され、応答しているかどうか確認できないぐらいの状態になってしまうはずです。
- 計算ノード上のエージェントでデータを収集すると、メモリーと CPU サイクルをユーザーのジョブから奪い取ってしまうことになります。多くの会社ではノードにエージェントを持ちたがりません。エージェントがあると、アプリケーションのパフォーマンスを劣化させることになるためです。バランスを取るにはトレードオフが必要になります。つまり、データを取得するために CPU サイクルを費やす価値があるかどうかを考えなくてはなりません。
- ユーザーのジョブをマシンのパフォーマンスに結び付け、有効で視覚的にも優れたジョブのプロファイルを作成するスケーラブルなツールというものを、私たちは見たことがありません。
- すべてを意図したとおりに実行してくれるツールはありません。これがおそらく、この問題で最も特筆すべき点でしょう。使用するツールは不完全で、誰もが望む機能が少なくも 1 つは欠けています。ほとんどの管理者は 1 つか 2 つの管理製品を組み合わせて使用していますが、他のすべてのソリューションに勝ると約束しているクラスター監視製品には、私たちは疑いの目を向けます。クラスターはそれぞれに異なり、1 つですべてのクラスターに対応できる製品はないからです。これを解決するには、監視をカスタマイズするしか方法はなさそうです。
このような複雑性があることから、私たちが知っている極めて怠惰な管理者たちは、この問題を以下のように解決しています。
これは大規模なクラスタリングを行っている組織 (最先端の研究を行っている大学や政府の研究所を含め) で最もよく使われているソリューションですが、Nagios でアラートを出し、Ganglia で監視を行います。大幅にカスタマイズできるこの 2 つのツールを併用することで、管理者はクラスターで発生している多数の事態を詳細に把握することができます。Ganglia に至っては、極めてスケーラビリティーに優れていることが実証されています。
一方、他の視点もあります。USC の Garrick Staples が TORQUE のプラグインとして作成した pbstop では、各ジョブの実行内容と実行場所を視覚的に確認することができます。彼は、監視に必要なのはこれだけで、他には何も使用していないと言っています。
スケールアウト・クラスター・コミュニティーで最もよく使用されているオープンソースの監視ツールには以下のものがあります。
- Nagios.
- Ganglia.
- Cacti.
- Zenoss.
- CluMon.
確実に言えることは、これらのツールの多くは、その実装で RRDtool を大いに利用しているということです。CluMon はさらに内部で、同じく人気の高い PCP (Performance Co-Pilot) も使用しています。xCAT の今後のリリースでは、Ganglia および PCP がサポートされる予定です。
要は、怠惰な Linux クラスター管理者は以下のことを理解しているということです。
- 監視には、単独ですべてをカバーできるソリューションはありません。監視の意味は人それぞれに異なります。マシンのアラートにだけ興味があるという人もいれば、パフォーマンスのメトリックスやジョブのプロファイル作成を目的としている人もいます。あるいは、特定のサービスまたはアプリケーションが実行中であることを確認できさえすればよいという人もいます。
- カスタマイズはサイトによって異なるだけでなく、同じサイト内であってもそれぞれのクラスターによって異なります。
- 監視対象、監視の目的、そして監視に必要なリソースとの間でトレードオフを慎重に比較検討する必要があります。
8. キューイング・スケジューラーを使ってユーザーを制御/管理すること
怠惰な管理者は、すべての問題の根本原因はユーザーであることを知っています。そのため、ユーザーがルートとしての権限やアクセス権を持たないようにすることが極めて重要です。さらに徹底した方法として、ユーザーを自分のマシンから締め出すためにあらゆる手段を講じるのも一考です。
この機能を提供するのが、キューイング・システムです。キューイング・システムは、ユーザーがジョブをサブミットすると、どのノードでそのジョブを実行するかを決定します。ユーザーはジョブを実行していない限り、マシンから締め出されます。
現在よく使用されているキューイング・システムには、LSF や PBS Pro などの有料の製品もあります。これらの製品は、多数の法人顧客だけでなく、政府の研究所や大学でも使われています。一方、大多数のシステムには、TORQUE や SLURM などの簡素なオープンソース・ソリューションで十分間に合います。
私たちは、ユーザーがジョブの実行中以外はクラスターに近づけないようにするため、TORQUE を Maui スケジューラーと連動させるという方法を取っています。Linux でのこの方法を説明すると、まず /etc/security/access.conf ファイルで、root だけがログインできて他は誰もログインできないように設定します。例えば、それぞれのノードで以下のコマンドを実行するとします。
echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf
|
すると、このマシンにログインできるのは root だけとなります。次に、ユーザーがログインできるようにするための TORQUE プロローグ・スクリプトを作成して、以下のように実行します。
perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf
|
(ヒント: $USER 変数は、このプロローグ・スクリプトが実行されるときに TORQUE によってスクリプトに渡される 2 番目の変数です)。プロローグ・スクリプトを実行するのは root ユーザーなので、このユーザーにはクラスターへのログインが許可されます。ジョブが完了すると、ユーザーを /etc/security/access.conf から削除するエピローグ・スクリプトが実行されるため、そのユーザーはノード perl -pi -e "s/ $USER\b//g" /etc/security/access.conf にログインできなくなります。このようにして、ユーザーが互いを上書きできないようにしています。
私たちはこれまで、マシンとはまるで無関係のクラスターの「パフォーマンス」問題を見てきました。実際の問題は、複数のユーザーが同じ 1 つのマシンで実行し、それぞれのユーザーが実行するジョブに CPU の 100 パーセントが必要になることです。
ユーザーの管理が必須であることは、秘訣でも何でもありません。しかし、単純なトラブルシューティングでは、ユーザー自身が問題を作り出しているという点が見過ごされがちです。私たちが強く推奨するのは、リソース・スケジューラーなどの管理された環境に入るのでない限り、ユーザーをシステムに近づけないようにすることです。さらに、クラスター・ネットワーク自体 (ギガビット管理またはユーザー・ネットワーク) を他の企業またはキャンパス WAN から切り離して、特定のユーザー・ノードだけからアクセスできるようにすることを是非お勧めします。
9. ベンチマークで、発生する前にパフォーマンス上の問題を突き止めること
貧弱なパフォーマンスと誤った結果を理由に、たいまつを手に村を焼き払うと脅している暴徒を相手にするのは、できる限り遠慮したいはずです。そこで念頭に置いておかなければならないのは、ハードウェア診断がクラスターの価値を判断する唯一のテストですが、ハードウェア診断が描き出す全体像は完全ではない可能性があることです。
ハードウェア診断は通常、ベンダーが定義したしきい値で合否を判定します。しかし、使用する側のしきい値は、ベンダー定義のしきい値よりも高い場合もあれば低い場合もあります。ハードウェア診断テストに失敗した場合は、もちろん問題があるということになりますが、失敗しないからといって、問題がないとは限りません。
今まで経験してきたなかで、システムがベンダーの診断に合格しながらも、パフォーマンスに見過ごせない影響を与えた問題としては以下のものがあります。
- ダブルビットのメモリー・エラー
- シングルビットのメモリー・エラー
- SRAM パリティー・エラー
- PCI バス・エラー
- 数値エラー
- キャッシュ・エラー
- ディスク・エラー
- パフォーマンスの矛盾
たいていの場合、これらの問題はハードウェアとは一切関係なく、ソフトウェアに関係します。アプリケーション、ライブラリー、コンパイラー、ファームウェア、そしてオペレーティング・システムのあらゆる部分が、ハードウェア診断では検出されない問題の原因となる可能性があります。多くの場合、ハードウェア診断はアプリケーションと同じランタイム環境では実行されず、アプリケーションと同じ意味でサブシステムに重点を置くこともありません。そうなると、ソフトウェアが原因となっている問題は見過ごされてしまいます。
当然のことながら、クラスターが実際に有効に機能することを検証するためには、実際に使用する動作環境を使って、何らかの関連するワークロードを実行する必要があります。その方法として使えるのが、業界が認めたベンチマークをいくつか実行することです。ベンチマークの目的は最良の結果を得ることではなく、同じく最良の結果でありながらも、一貫性のある再現可能で正確な結果を得ることです。
それでは、どうやって最良の結果であるかどうかを判断すればよいのでしょうか。それにはまず、クラスターを以下の主要なサブシステムに分類します。
ハードウェア・ベンダーは、メモリー、CPU (FLOPS)、ディスク、そしてネットワークのパフォーマンスが正常であることを示すベンチマーク・データを持っているはずです。
一貫性のある結果であるかどうかを判断するには
それは統計で判断します。各ベンチマークをノードごと (マルチノード・テストの場合はノードのセットごと) に 1 回以上実行し、それぞれのノード (またはノードのセット) の代表的な結果を 1 つのグループにまとめ、それを単一の母集団として分析します。その分析結果として興味深いのは、結果の分布の形です。この記事のすべてのベンチマークを実験して明らかな結果として示されたのは、すべて正規分布の形になるということです。正規分布とは、統計では頻繁に現れる標準的な釣鐘曲線のことで、一様に分布する互いに独立した (おそらく識別できないぐらい) 小さな変動要素 (つまりランダム・イベント) が合計されたものです。
このようにベンチマークの結果には、一様に分布する互いに独立した (おそらく識別できないぐらい) 小さな変動要素が含まれており、そのなかにはパフォーマンスに影響を及ぼす可能性があるものも多数あります。例えば、以下の要素です。
- 競合する小さなプロセス
- コンテキスト・スイッチ
- ハードウェア割り込み
- ソフトウェア割り込み
- メモリー管理
- プロセス/スレッド・スケジューリング
- 宇宙線
これらの変動要素は避けることができないものであり、正規分布を形成する要因の一部となっています。
ベンチマークの結果に、一様に分布していない識別可能な変動要素が含まれる場合もあります。これらの変動要素もパフォーマンスに影響を与える可能性があります。
- 競合する大きなプロセス
- メモリー構成
- BIOS のバージョンおよび設定
- プロセッサー速度
- オペレーティング・システム
- カーネルのタイプ (NUMA、SMP、UNI など) およびバージョン
- 不良メモリー (過剰な ECC など)
- チップセット・リビジョン
- ハイパースレッディングまたは SMT
- 不規則に競合するプロセス (一部のノードでは実行し、他では実行しない
httpd など)
- 共有ライブラリーのバージョン
これらの変動要素は回避可能です。このような回避可能な一貫性のなさは、多様な分布あるいは非正規分布という結果に至り、アプリケーションのパフォーマンスに大きな影響を及ぼす可能性があります。
結果の一貫性、再現性、正確性を実現する最良の方法は、できる限り変動要素を少なくして始めることです。まずは、STREAM のような単一ノードのベンチマークから始めてください。すべてのマシンで同じような STREAM の結果が得られたら、メモリーはその他のベンチマークの異常性の要因から排除することができます。その後は、プロセッサーとディスクのベンチマーク、2 つのノードの (並列) ベンチマーク、さらにマルチノードの (並列) ベンチマークへと進めていきます。それぞれの複雑なベンチマークを行った後、複雑な次のベンチマークを続ける前に、結果の一貫性、再現性、正確性をチェックします。
以下に、私たちが推奨する手順を要約します (ベンチマークがレポートするコンポーネントのパフォーマンスを太字で示します) 。
- 単一ノードの (シリアル) ベンチマーク の場合:
- STREAM (メモリー Mbps)
- NPB Serial (ユニプロセッサー FLOPS およびメモリー)
- NPB OpenMP (マルチプロセッサー FLOPS およびメモリー)
- HPL MPI 共有メモリー (マルチプロセッサー FLOPS およびメモリー)
- IOzone (ディスク Mbps、メモリー、およびプロセッサー)
- パラレル・ベンチマーク (MPI システム専用) の場合:
- Ping-Pong (相互接続 マイクロ秒および Mbps)
- NAS Parallel (マルチノード FLOPS、メモリー、および相互接続)
- HPL MPI 分散メモリー (マルチノード FLOPS、メモリー、および相互接続)
作業量が多いような感じがしますが
その通りですが、後で楽をしようと思ったら、これも必要なことです。幸いなことに作業を容易にするツールとドキュメントは揃っているので、ほんの数日分の事前計画で、その後の何週間分ものフラストレーションをなくすことができます。これらのツールとグラフについては今後の記事で説明する予定です。今後、xCAT RPM の一部としても公開されることになっているので、そうなると生産性が大幅に向上するはずです。
10. クラスター管理者間の通信を管理すること
 |
MediaWiki のセットアップ
MediaWiki をセットアップするには、まず、このウィキをホストするサーバーを指定します。他のサーバーを使えない場合には通常、管理サーバーを使用します。
ssh mgmt
http サーバー、mysql サーバー、php5 がインストールされていることを確認します。Red Hat 5.1 やその派生バージョンを使用している場合は、以下を入力してください。
yum install http mysql php5 mysql-serverr
次に、mysql を構成します。
service mysqld start
mysql_install_db
mysqladmin -u root password 'mypasswd'
ここで、MediaWiki をインストールします。
cd /tmp/
wget http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.0.tar.gz
tar zxvf mediawiki-1.13.0.tar.gz
mv mediawiki-1.13.0 /var/www/html/wiki
chmod a+x /var/www/html/wiki/config
ここまでの作業が完了したら、Web ブラウザーで http://localhost/wiki までナビゲートしてください。後はメニューに従うだけで残りのインストール作業を完了できます。
作業が完了すると、以下のコマンドを実行するように指示されます。
cd /var/www/html/wiki
mv config/LocalSettings.php .
|
|
システムについての情報を集めたら、その情報は使いやすい場所に保存して、残りのクラスター・スタッフが容易にアクセスできるようにしなければなりません。ここで、2000年を振り返ってみましょう。Word 形式や Excel 形式は卓越した文書でもなく、情報を効率的に保存する方法でもありませんでした。私たちがこれまで見たなかで、情報を保存するのに最も生産的なプラクティスは、内部ウィキをセットアップすることです。なぜなら怠惰な管理者は同じ質問に何度も繰り返し答えることに飽き飽きしてくるからです。ウィキがあれば、質問の答えを出すために、調べたりコマンドを実行したりする代わりに、一言、「ウィキを調べてください。」と言うだけで彼の仕事は終わります。
- すべてのサイトは、クラスターに関するすべての情報が含まれるウィキを維持するべきです。通常、このようなウィキには以下のものが必要になります。
- クラスターで管理アクションが行われた日時を含めたシステムの変更ログ。
- クラスターのインベントリー (ファームウェア、バージョン、モデル、シリアル番号、クラスター内のノード数、プロセッサー・タイプ、メモリー)
- ベンダーでのオープン・サポート・チケットへのリンクと、更新を取得するためのリンク
- 管理ソフトウェアを使用した共通タスクについての文書
- OS イメージの作成方法に関する情報
要するに、ウィキに十分な情報があれば、誰かがクラスターに関して質問しても、管理者は「ウィキを調べてください。」と言うだけで済みます。同様に、誰かにウィキにはない質問の答えを教えた場合には、その知識が他の人にも役立つようにウィキに書き込むように指示してください。これがさらにチャーン個人に役立つというのも、未開の IT 世界での現実です。
ウィキが他のドキュメントの形態よりも優れている理由とは何でしょう。
- ウィキは中央の一か所で編集することができ、アクセス制御をそれが必要な人々に与えることができます。文書が共有リポジトリーに置かれていても、その文書を表示するにはまず、その共有リポジトリーまでナビゲートして文書をハード・ディスクに保存してからでないと、文書を開けないことはよくありますが、これでは非効率です。リンク 1 つでアクセスできるほうがすぐに表示でき、イライラさせられることがありません。
- Word 文書やスプレッドシートに情報を書き込むのは静的であり、編集や再度保存をしたり、リビジョンを送信したりするにも簡単とは言い難いものです。言うまでもなく、同じ文書が何度も繰り返し処理されているために、人々が自分の持っている文書が最新のバージョンであるかどうかわからなくなってしまうという事態はよくあります。このような事態は特に、複数の人が編集している場合に顕著です。実際、内容が更新される文書はウィキでのほうが長く存続します。
ウィキのセットアップは至って簡単です。私たちが使っている MediaWiki は無料で簡単に入手できるだけでなく、インストールして構成するにも簡単です (囲み記事を参照)。
ウィキの構文は HTML に比べ遙かに簡単で、その使い方を調べるにも、Web に役立つリンクが多数見つかります。また、perl や bash を使っている場合には、コード構文を強調表示する優れた拡張機能も手に入れることができます。
私たちのウィキの提案に対して難色を見せる組織はほとんどありません。皆さんもウィキをインストールして、さらに怠惰になれるよう願っています。
11. さらに怠け者になる方法を探すこと
クラスター・ビジネスでは、これまでいつもそうしてきたからという理由で、同じように物ごとを行っている人をよく見かけます。これでは Linux クラスターを構成する組織からは優秀な人材が失われ、クラスターから最低限の成果しか得られなくなってしまうでしょう。重要なのは変化です。そして新しい構想は次々と生まれています。
当然のことながら、新しく生まれる構想すべてを調査できる人がいるとは思いませんが、より新しい傾向を十分に理解しているかどうかが、優れた管理者と二流の管理者との境目となります。そうは言っても、この素早く移り変わる世界では誰一人として、あらゆることについて何らかの知識を持てるわけはなく、特定のことについてすべてを把握している人もほとんどいません。それでも、優れたクラスター管理者であれば、何かについて十分な知識を持ち、さらに他のことについてもテストし、そして聞いたことのないことについては質問するものです。
怠惰な Linux 管理者は、誰かが自分が聞いたことのない話題について話し始めると、その場で質問を投げてきます。彼は後で自分のオフィスに行って、お気に入りの検索エンジンで情報を探すには、あまりにも怠惰だからです。最も恐ろしい Linux クラスター管理者は、決して質問を口にしないような管理者です。怠惰な Linux クラスター管理者は、自分の無知を明かすのを恐れません。怠惰な管理者は、自分が知らなければ、同じ部屋にいる他の誰かも知らないはずだと自信を持っています。
現在、Linux クラスターの管理では素晴らしいことがいくつか起こっています。なかでも最も興味深いと思うことを以下に紹介します。
- ステートレス・コンピューティングへの移行が大幅に進んでいます。これにより、イメージが管理しやすくなるとともに、ノードの同期状態を維持しやすくなります。
- データ・センターの観点からクラスターを考慮するようになってきています。これはつまり、単なる取得に係る費用だけではなく、電力および冷却に係る費用も併せ、3 年以上の長期にわたっての支払い額を考慮しているということです。
- 空冷ではなく、液体冷却の効率性。液体冷却は、空冷よりも 90 パーセントも効率的であることをご存知でしたか？
- 適応管理。この場合、キューイング・システムがオンデマンドでノードをプロビジョニングすることができます。これは真のクラウド・コンピューティングであり、私たちはこれを Moab と xCAT で実証しています。これは、完全なる怠惰への最終ステップです。
まとめ
この記事がその目的を果たしたとしたら、読者の皆さんは今頃、作業を減らすと同時に既存の Linux クラスター環境をより賢く管理する方法を思い付いて、次の環境を計画していることでしょう。この記事で説明した概念とプラクティスは必ず、より良いクラスターの利用法、クラスター関連の技術向上、そしクラスター管理スタッフの削減と作業効率の改善に役立つはずです。
人が減り、問題が軽減されるということは、会議の回数が少なくなり、作業量が減り、そして WoW をプレイする時間や、ヤギの世話をする時間、睡眠時間、あるいは怠惰な趣味が何であろうとそのための時間が増えるということを意味します。
参考文献 学ぶために
製品や技術を入手するために
- この記事で取り上げたリソースは、以下から入手してください。
- Rocks は、エンド・ユーザーが簡単にコンピューター・クラスター、グリッド・エンドポイント、ビジュアライゼーション・タイル表示ウォールを作成できるオープンソースの Linux クラスター・ディストリビューションです。このグループの目標は 1 つ、クラスターを簡単にすることです。
- OSCAR (Open Source Cluster Application Resources) では、ユーザーが *NIX 環境でどれだけの経験を積んでいるかに関わらず Beowulf タイプの HPCクラスターをインストールできます。
- Perceus は、Warewulf の開発者たちによって作成された次世代のエンタープライズ/クラスター・プロビジョニング・ツールキットです。
- xCAT (eXtreme Cluster Administration Toolkit) は、スケーラブルな分散コンピューティング管理およびプロビジョニング・ツールで、ハードウェア制御、ディスカバリー、そして OS ディスクフル/ディスクフリー・デプロイメントを行うための統一インターフェースを提供します。
- Nagios は、クライアント、ユーザー、マネージャーよりも先にネットワーク問題を通知するように設計されたホストおよびサービス・モニターです。これは Linux 用に設計されたモニターですが、ほとんどの *NIX バリエーションでも有効に機能します。
- Ganglia は、HPC クラスターおよびグリッド向けのスケーラブルな分散監視システムで、クラスターのフェデレーションを対象とした階層設計をベースとしています。
- pbstop は、perl-PBS (Portable Batch System) 内部に分散される ncurses 監視および管理ツールです。このツールは、世界指折りの大規模なクラスターの管理者が使用しています。
- TORQUE は、バッチ・ジョブおよび分散コンピューター・ノードを制御するオープンソースのリソース・マネージャーで、*PBS プロジェクトをベースとしたコミュニティー・エフォートです。
- Cacti は、RRDToo のデータ・ストレージおよびグラフ化機能を利用するように設計された完全なネットワーク・グラフ化ソリューションです。このツールには、そのまますぐに使える高速ポーリング・プログラム、拡張グラフ・テンプレート、複数のデータ取得メソッド、そしてユーザー管理機能が組み込まれています。
- Zenoss は商用のオープンソース IT 管理ソリューションを提供します。
- CluMon は、National Center for Supercomputing Applications がその Linux スーパー・クラスターを追跡するために開発したクラスター監視システムです。このシステムは、ほぼあらゆるセットの Linux マシンで機能するように調整できます。
- RRDtool は、時系列データを対象としたオープンソースのハイパフォーマンス・データ・ロギングおよびグラフ化システムです。
- Performance Co-Pilot は、システム・レベルのパフォーマンス監視、およびパフォーマンス管理をサポートするためのフレーム、サービスを提供します。SGI では 2000年にオープンソース・バージョンを提供しています。
- 「極めてスケーラブルなリソース・マネージャー」である SLURM (米国のテレビ・アニメーション・シリーズ、Futurama で人気の飲料と同じ名前) は、あらゆるサイズの Linux クラスター用に設計されたオープンソースのリソース・マネージャーです。3 つの主要な機能は、リソースへの排他的あるいは非排他的アクセスを割り当てること、割り当てられた一連のノードでの作業を開始、実行、監視すること、そして保留中の作業のキューを管理してリソースの競合を解決することです。
- Moab Workload Manager は、クラスターを対象としたユーティリティー・ベースのコンピューティングを可能にするポリシー・ベースのジョブ・スケジューラー兼イベント・エンジンです。
- Linux SEK を注文してください。この 2 枚組 DVD セットには、Linux 対応の DB2、Lotus®、Rational®、Tivoli®、そして WebSphere® の最新 IBM 試用版ソフトウェアが収録されています。
- developerWorks から直接ダウンロードできる IBM 試用版ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。
議論するために
著者について | | | Vallard Benincosa は怠惰な Linux 認定 IT プロフェッショナルであり、IBM Linux Clusters チームに所属しています。彼はオレゴン州ポートランドに妻と 2 人の子供と暮らしています。 |
| | | Egan Ford は、IBM 初の大規模 HPC クラスター (University of New Mexico の Los Lobos) の主任アーキテクトとして、1999年から Web および HPC Linux クラスターの構築を始めました。それ以来、AIST、LANL Roadrunner、US National Science Foundation Teragrid (teragrid.org) などの IBM きっての大規模システムの設計および実装を先導しています。 Egan は IBM 初のクラスター管理ソリューション (xCAT) の作成者であり、Linux HPC に関する 2 つの IBM RedBook の共著者でもあります。 |
記事の評価
| 
