クラスタ・ライフサイクル管理:リサイクルと再生

Deepak Khosla

先のクラスタ・ライフサイクル管理のコラムでは、あなたのHPCクラスタをアップグレードまたは更新する必然性への準備を助けるキャパシティ・プラニングとレポートに関する様々なオプションを検討した。今回のコラムでは、このクラスタ・ライフサイクル管理シリーズのまとめとして、システムをアップグレード、もしくはおそらくリプレースすることについて、実際にどのように取り掛かるかを議論する。

このコラムシリーズにおいて、システムを効率良く運用し続けるために必要なステップに多くの焦点を当ててきており、そうすることでエンドユーザは生産的な経験を持つ事となり、そして組織はHPC技術への投資に対するプラスのROIを得るようになるのだ。しかし、クラスタが最大の効率で動作したとしても、それは数ヶ月かもしれないし、4年かもしれないが、システムをアップグレードする必要を考え始めるその日は来るのだ。

キャパシティ・プランニングとレポートのコラムでは、どのようにクラスタが利用され、どの程度の性能を出しているかについてHPCの管理者への情報を更新する堅実なレポートシステムの必要性を強調した。大きいにせよ小さいにせよ、システムのリフレッシュは急な決定ではないので、これは重要なのだ。新しいリソースの予算化や調達には長い時間が掛り、これなどのようにシステムが使われてきたのかを検証しなければならない。利用と性能の履歴は、アップグレードや変更に関して良い決断をするのに重要なのだ。

変更が必要なことを示す現象は、様々な形式や重大度で来るだろう。最も一般的には、ビジネスが拡大し、利用者はもっと速度やスループット、もしくはジョブを完了するための追加のストレージ要求するだろう。または、おそらくソフトウェア・アプリケーションが進化し、追加の演算能力や、もしくは効率良く実行するための異なるソフトウェア・スタックが必要となる。数年後には、ハードウェアが単に古くなり、必要となるスループットを維持できなくなったり、または運用や保守がかなり高価になるかもしれない。関連する症状としては、さらに頻繁なハードウェア障害や、より多くの原因不明の断続的なジョブ障害などがある。

障害チケットおよび変更管理システムとのコンビネーションで、システムおよびジョブの使用状況や性能レポートのシステムを持つ事は、どのオプションが一番良いかについて、データ駆動型分析的決定を行うのに必要なデータを提供する。いつものように、1個のパスしかないのはめったにない!

システムのアップグレードやリフレッシュは様々な度合いで来る。ちょうど車を買う決定に似ており、クラスタのリフレッシュは全く同じだ。(古い車を買い替えるのか、もしくはどこかをアップグレードまたは修理するのか、それとも新しい車を買って古いのも持っておくのか)　しかし、決定については、各選択肢と関連するコストを軽視すべきではない。一般的に言って、選択肢は、既存システムのアップグレードか、既存のクラスタに追加の演算もしくはストレージを追加して拡張するか、もしくは全システムをリプレースするかだ。顧客もしくはアップグレードのスコアにおける私の経験では、ローリング・アップグレードが最も一般的で、システムのある部分をアップグレードしている間に、顧客はある特定の生産量を継続できるのだ。

どのパスを辿るかは、私が運用の最初から維持するように推奨した履歴レポート情報を参照する必要があるだろう。どのハードウェアをアップグレードもしくはリプレースするか知る事は、どのようにシステムが使われてきたかの測定基準によって規定されるだろう。これらの基準は、最初の場所でHPCの技術を展開する元々の決断があったように、最大のROIを提供するあなたの決断を助けるのだ。

検証しなくてはならない重要な情報または判断基準は次を含んでいる:

• システムの平均スループットは?
• 利用方法のプロフィールは?
• 何のアプリケーションがどのアーキテクチャで効率的に動くか?
• どのノードが最も使われているか?使われていないのは?
• どんな問題をユーザが報告しているか?
• 保守、管理、電力、およびソフトウェアライセンスに関連するコストはどうか?

ジョブはこれらのデータポイントを使用して費用対効果分析を行うべきであり、そうすることで、どのオプションが組織に最大のリターンを与えるか決定することができるのだ。そして最も重要なのは、強化されたシステムは、エンドユーザに以前よりもずっと高い効率性と信頼性を提供すべきなのだ。最初のクラスタを購入する前に行ったように、現在と予測される利用状況のプロフィールに基づいたアップグレードのニーズを評価しなくてはならない。

何をリプレースするか、もしくは購入するかの決断をしたら、オリジナルのシステムを購入した時のようにRFP(Request For Proposal)を開始しなくてはならない。もし可能なら、同じチームを集め(システム管理者、データセンターオペレータ、エンドユーザ、ITスタッフ、および経営幹部)、再び分析と購入プロセスに投入しよう。最初のシステムのアーキテクチャや性能に満足していないならば、2回目の中でクラスタを改善する変更を規定する機会をもつこととなる。新システムのRFPに関して重要な考慮事項は、既存システムが考慮しているものと新システムの互換性を保証することだ。これは管理システム、スケジューラ、ソフトウェアとワークフロー、およびポリシーと手順が含まれている。

オリジナルのHPC導入におけるプラスの経験を持っており、たとえ同じベンダーからまた買いたいと思っていたとしても、少なくとも2、3の他のRFPを出す事を推奨する。現在の速い技術変化の時代の中で、他のベンダーが必要とするものを良い価格で提供していることを発見して驚くかもしれないのだ。価格でなく価値であることに注意!　既存システムの知識をもった良いベンダーは、どのオプションが良い選択かどうかの価値ある洞察を提供してくることができるのだ。

オリジナルのRFPが新システムのインストールをする際には、アップグレードはインストールされ、展開されて、経験豊かな専門家によって評価されなければならない。アップグレード、特にメジャーアップグレードは、既存システムへの最小限の中断で達成されなくてはならないので、ユニークなスキルを必要とする。古いシステムが完全にリプレースされたら、物流が問題となるので、RFPの中で処理されなければならない。全ての実装行動は、アップグレードのコストに「ソフト」ドルを追加し、費用対効果の中で考慮されなければならない。

最後に、古いハードウェアまたはリプレースするシステム全体はどうするのか?年数と状態にもよるが、地方大学への寄付や他の組織への販売を検討することもできる。

アップグレードまたはリプレースが完了し運用開始したら、HPCシステムの再生は今のところ完了だ。キーの測定基準での改善を見たら、リフレッシュは成功したとわかるだろう。スループットが向上し、ジョブ実行から完了および運用全体のコストが下がってくる。そして、最も重要なのは、エンドユーザからの満足度は上がり、不平は少なくなるのだ。

このプロセスは簡単ではないので、終了したらお祝いしよう、それは動いている車のタイヤを交換したようなものだ!　しかし、これがHPCの正解を楽しんでいる理由ではないだろうか?　これは心臓の弱い人のためではない。お疲れさま!　さあ泡立てて、洗い流して、それを繰り返そう。ハッピークラスタリング。

これでクラスタ・ライフサイクル管理シリーズの最後となる。このコラムを掲載してくれたHPCwireに感謝し、シリーズ化にも感謝する。何か質問があれば、直接コンタクトして欲しい。dkhosla@x-iss.com

Deepak Khoslaは、X-ISS社（http://www.x-iss.com/）の社長兼最高経営責任者（CEO）だ。