Linux かHP-UX、あなたはどっち？...Linux かHP-UX、あなたはどっち？～潜むリスクを完全比較、適材適所の OS 選択～適材適所、適宜適量

Linux か HP-UX、

あなたはどっち？

～潜むリスクを完全比較、適材適所の OS 選択～

適材適所、適宜適量 ──そうしたクラウド時代にもっとも重要とされる選択眼に

は、用途の場面に合わせた潜在するリスクを正しく把握することです。システムは

どういう時に止まるのか、その止まらない仕組はあるのか、Linux と HP-UX を完全

比較！買うならどっちか、あなたのお声を聞かせてください。

《連載期間：2010 年 9 月～2011 年 2 月》

1

Linux か HP-UX、あなたはどっち？～潜むリスクを完全比較、適材適所の OS 選択～

―目次―

第 1 回エラーが起きても止まらない可用性を徹底検証

“Linux と x86 サーバーでミッションクリティカル・システムを構築” ―― そんな成功事例を目にする機会が増えつつある。し

かし、いくら隣の芝が青いからと言って、闇雲に飛びついて良いとは限らない。重要なのは、自社が要求するレベルの可用性を

満たしているか否か、正しく見極めることだ。「Linux を選んで失敗した」という表に出てこない失敗事例も少なからずあると

いうことも忘れてはならない。次のシステムに最適なプラットフォームは、Linux なのか、それとも HP-UX なのか。今回は

「可用性」をテーマに比較検証してみる。

第 2 回 OS のライフサイクルが及ぼすサポート問題とは？

ミッションクリティカル・システムを構築する際、OS やサーバーの可用性、信頼性、拡張性など比較・検討することは、非常

に重要なことである。しかし、ビジネスの中核を担うシステムを構築する場合、機能・性能だけでなく、考慮すべき重要な事項

がある。それは、OS やサーバーをベンダーがどこまでサポートするかという点である。長期間の利用を想定して業務アプリケ

ーションを構築しようとしても、OS やサーバーのサポート期間が短ければ、とても安心して採用することはできない。今回

は、システムのライフサイクルという側面から HP-UX/Integrity サーバーの優位性を探ってみたい。

第 3 回障害発生時における迅速な切り分けを比較

事業の根幹に関わる重要なミッションクリティカル・システムには、決してシステムを止めることにない可用性が求められる。

高可用性を実現するためにシステムを冗長化・多重化することも重要だが、どんなに堅牢なシステムを構築したとしても、障害

発生のリスクをゼロにすることは不可能だ。しかし、たとえ障害発生のリスクをゼロにできなくても、障害発生の根本原因を即

座に発見・特定できれば、障害発生によるダウンタイムの短縮に大きく寄与することになり、再発というリスクも防止できる。

今回は、障害発生時において迅速な切り分けを実現する HP-UX/Integrity サーバーの優位性を解説する。

第 4 回キャパシティとスケーラビリティについて問う

重要な基幹業務アプリケーションが動作する OS には、アプリケーションが安定稼働するためのさまざまな機能・性能が求めら

れる。アプリケーション視点からは、OS の機能を比較することは意味のないことと捉えられるかもしれない。しかし、実際に

は機能の違いが性能・信頼性の差につながることもある。今、多くの OS、プラットフォームがミッションクリティカル・シス

テムでの利用に耐え得る機能強化が進められているが、キャパシティやスケーラビリティに関しては、実績のある HP-

UX/Integrity サーバーに一日の長がある。今回は、そうした機能の違いを見てみよう。

第 5 回プラットフォームの安定性とメンテナンス性

ミッションクリティカル・システムでは、何を優先してプラットフォームを選べば良いのだろうか。処理能力の高さ、機能の豊

富さ、拡張性の高さなど、業務アプリケーションの内容や用途によって優先すべき選択ポイントは異なってくるが、実際にシス

テムを運用管理する情報システム部門の担当者にとっては、プラットフォームの安定性とメンテナンス性に優れていることが何

よりも重要なポイントになってくる。第 5 回目の今回は、OS の安定性とメンテナンス性の観点から、Linux/x86 サーバーと

HP-UX/Integrity サーバーの違いを見てみよう。

最終回 Linux⁄x86 サーバーはコスト高という衝撃の調査結果

半年に渡り、ミッションクリティカルシステムにおける Linux⁄x86 サーバーと HP-UX⁄Integrity サーバーをさまざまな角度か

ら比較・検証してきた本連載も、今回をもって最終回を迎える。信頼性、堅牢性、安定性、さらにはサポート体制などにより、

HP-UX⁄Integrity サーバーの優位性を見てきたが、実際に導入するには「コスト」という壁がある。オープンソースの Linux、

コモディティ化された x86 サーバーの導入コストの安さは、語るべくもない。ところが、米国調査会社が発表したレポートに

よると、トータルコストを比較した場合、むしろ“Linux⁄x86 サーバーはコスト高”だという。今回は、その衝撃的なレポートを

読み解いてみたい。

2


第 1 回

エラーが起きても止まらない可用性を徹底検証

2010 年 9 月大神企画富樫純一

“Linux と x86 サーバーでミッションクリティカル・システムを構築” ―― そんな成功事例を目にする機会が増えつつある。しか

し、いくら隣の芝が青いからと言って、闇雲に飛びついて良いとは限らない。重要なのは、自社が要求するレベルの可用性を満

たしているか否か、正しく見極めることだ。「Linux を選んで失敗した」という表に出てこない失敗事例も少なからずあるとい

うことも忘れてはならない。次のシステムに最適なプラットフォームは、Linux なのか、それとも HP-UX なのか。今回は「可

用性」をテーマに比較検証してみる。

ミッションクリティカル・システムに相応しい可用性とは？

目が向けられていることも事実であり、やむなくコストを優先させるというケースも少なからずある。そうした場面でよく見ら

れるのが、オープンソースでイニシャルコストを抑えられる Linux を、高性能化が著しく製品価格も手頃な x86 サーバー上で稼

働させ、それをシステムのプラットフォームとして採用するというものだ。こうしてコスト優先で構築したシステムが、障害なく

稼働していれば万々歳である。しかし、そのシステムが順調に稼働するのは、運が良いからだろうということを、導入した企業

の情報システム部門は薄々と感じているはずなのだ。

そもそも x86 サーバーが安価に提供できるのは、ハードウェア障害の発生をある程度許容しているからである。ハードウェア障

害が発生しやすいから、システム単位あるいはコンポーネント単位で二重化またはそれ以上に冗長化し、来るべき障害発生に備え

るわけだ。冗長化すれば、確率計算上は可用性が高まるだろう。だが、その発想で高めた可用性は、本当に信頼がおけるのだろ

うか。事業継続を必須とするミッションクリティカル・システムに相応しいだろうか。イニシャルコストの削減は実現した。け

れども可用性に課題を残してしたり、可用性に不安が残ったりしたのでは、そのシステム導入が成功したとは言えないだろう。

最適なプラットフォームを選択するのに最も重要なのは、システム全体に潜むリスクを正しく把握することである。なお、最適

なプラットフォームというのは、プロセッサなどサーバーを構成するハードウェア、その上で稼働する OS を単体比較しても意味

はない。あくまでも、システム全体として比較することが望ましい。本稿では、以下の項目について、Linux/x86 サーバーのシ

ステム、および HP-UX/ Integrity サーバー（以下、Integrity サーバー）のシステムの比較を交えながら解説する。

富樫先生が伝える今回のポイント

OS のことならお任せ！

富樫先生

エラーが起きても止まらない可用性を把握する！！

1.可用性に対する設計思想の違いを把握しよう！

2.搭載された高可用性技術の違いを把握しよう！

3.HA クラスター製品の違いを把握しよう！

3


可用性に対する設計思想の違い：許容する Linux と未然に防ぐ HP-UX

「可用性が高い」ということは、すなわち「システムが停止しない」という意味である。言い換えれば、システムの可用性はシス

テムダウンを発生させる要因を取り除く、または対策することによって高められることになる。

では、システムダウンの発生要因にはどのようなものがあるだろうか。まず、挙げられるのが「人」に属する要因だ。行うべき

テストが不十分だったために障害が発生してしまったとか、バックアップなどの作業中に操作ミスをしたことにより引き起こされ

たシステムダウンは、テスト手法の見直しやオペレーションを自動化するツールの導入など、プロセスを改善して属人的な作業を

削減しなければ、なくすことはできない。これは、OS やサーバーの違いによって差が出るものではない。

プロセスを改善したとしても、そのプロセスに起因するシステムダウンも考えられる。たとえば、業務を決められた手順で行っ

ていたのに想定外の処理が割り込んだ、あるいは運用管理ツールの不具合が発生したといったことが原因でシステムダウンが発生

したのなら、そのプロセスを見直さなければならない。これも、OS やサーバーで差異のあるわけではない。

しかし、テクノロジーが原因で発生するシステムダウンについては、OS やサーバーの違いが如実に表れる。たとえば、ハードウ

ェア障害の発生による計画外停止を回避するためには、システムまたはコンポーネントを冗長化することで対応することが可能だ

が、メモリやハードディスクなどの主要コンポーネントに障害抑制機能が搭載されているかどうかは大きな違いになる。万一、

システムダウンが発生した際にも、それだけ短時間で復旧できるかは、OS やサーバー、HA クラスターの機能により違いがあ

る。また、システムダウンを引き起こした原因が究明できる障害解析機能の有無も、次のシステムダウンを発生さないという意

味で重要だ。このテクノロジーの部分を比較すると、Linux が稼働する x86 サーバーと HP-UX が稼働する Integrity サーバー

では、設計思想に大きな違いがある。x86 サーバーというのは、本稿の冒頭で述べたように、ハードウェア障害が発生すること

をある程度許容した設計になっている。コモディティ化されたパーツ・コンポーネントを使用してコスト効果を狙っている代償

でもある。そのため、システムやコンポーネントの多重化など、障害発生時の対策を事前に施すことは必須である。それに対し、

Integrity サーバーは単体でハードウェア障害によるシステムダウンを極小化する設計になっている。もちろん、システムやコン

ポーネントを多重化すれば、さらに可用性が向上するが、HA クラスターは最後の手段とも言えるほどだ。

図 1：Integrity Superdome 2 ブロック図

4


障害発生時の対策も、x86 サーバーと Integrity サーバーでは大きく違う。 x86 サーバーの場合、障害が発生しても詳細な解析

を行うことが困難であり、原因として考えられるパーツ・コンポーネントをいろいろと交換してみるという試行錯誤が必要にな

る。一方の Integrity サーバーには「同じ障害を繰り返さない」という設計思想が根底にあるために、障害が発生した際にはそれ

をきちんと記録し、解析の実行と迅速な復旧を可能にしている。

図 2：Superdome 2 OA を中心とする各種管理コンポーネント

ライフサイクルが設計思想も変える

さらに、競争が激しい x86 サーバーの場合、ハードウェアのライフサイクルが非常に短く、他社に先駆けて製品投入を果たすに

はテストに時間をかけてはいられないという側面がある。 Integrity サーバーはハードウェアのライフサイクルが長く、製品をあ

らゆる面からテストする期間を長く確保している。こうした設計思想の差が、可用性の高さと迅速な復旧に大きく効いてくるの

である。

搭載された高可用性技術の違い：今後の Linux と実績の HP-UX

ここで、Linux/x86 サーバーにはなく、HP-UX/Integrity サーバーにはある機能について解説しよう。

HP-UX/Integrity サーバーには、OS とハードウェアが連携することでメインフレームクラスに匹敵する可用性を実現する「マ

シン・チェック・アーキテクチャ（MCA）」に基づく技術が実装されている。インテル® Xeon® プロセッサー7500 番台から

x86 サーバーにも採用されているが、この MCA は OS と連携して初めてその真価を発揮するものである。 MCA とは、ハードウ

ェアで修正することが不可能なエラーをファームウェアや OS（HP-UX）に通知して、それらのソフトウェアを介してリカバリー

を実行するというアーキテクチャである。ファームウェアや OS がリカバリーに関与するために、複雑なエラーが発生しても訂

正、または回復処理を実行できるという特徴がある。

5


図 3：マシン・チェック・アーキテクチャ（MCA）のフローチャート

キャッシュエラーを切り離す

その実装例の一つが「Dynamic Processor Resilience（DPR）」である。これは、プロセッサーのコアでキャッシュエラーが

頻発した際に、致命的な障害が発生してシステムダウンする前に該当するコアを切り離して利用しないようにする機能だ。

Linux/x86 サーバーの場合、コアでキャッシュエラーが発生したときにエラーを訂正するハードウェアの機能は働くものの、エ

ラーが頻発しても切り離すという動作は行われないので、致命的なエラーが発生するとシステムがダウンすることになる。この

間、Linux は何もしない。

それが、DPR を搭載した HP-UX/Integrity サーバーでは、コアでキャッシュエラーが発生したときのエラー訂正機能が働いたこ

とを HP-UX がカウントし、エラーが頻発してしきい値を超えた時点で HP-UX がコアに不具合があると判断、そのコアを切り離

して利用しないようにする。これにより、システムダウンを未然に防止するわけだ。

図 4：Dynamic Processor Resilience（DPR）

6


レジスターや TLB のエラーを切り離す

もう一つの実装例として「Automated Processor Recovery（APR）」という機能がある。これは、レジスターや TLB

（Translation Lookaside Buffer）でエラーは発生しても継続運用を実現するというものだ。

Linux/x86 サーバーの場合、レジスターや TLB でパリティエラーが発生すると、その場でシステムダウンしてしまう。これは、

レジスターや TLB が ECC で保護されていないためだ。当然、Linux には通知されることはない。

その点、HP-UX/Integrity サーバーの場合、インテル® Itanium® プロセッサーにレジスターや TLB でパリティエラーが発生

すると OS に通知するという機能が搭載されている。この機能によりエラー内容が HP-UX に通知され、破損したレジスターの内

容がユーザーモードのデータだったときには、HP-UX が関連するプロセスのみを強制終了させてシステムを継続運用するという

措置をとる。こうした手段でシステムダウンを回避しているわけだ。

HA クラスター製品の違い：チューニング次第の Linux と迅速な HP-UX

可用性を向上させる手段として、HA クラスター構成をとることが一般的である。これは、Linux/x86 サーバーでも HP-

UX/Integrity サーバーでも同じだが、Linux/x86 サーバーに多種多様な選択肢があるのに対し、HP-UX/Integrity サーバーに

は OS カーネルと強固に連携して優れた機能・性能を発揮する HA クラスター製品が用意されている。それが「Serviceguard」

である。

Serviceguard には、さまざまな優れた特徴がある。まず挙げられるのが、非常に高速なフェイルオーバーを実現するということ

だ。ノードに障害が発生した場合、クラスターを再構成してリカバリーを完了させるまで、通常は数十秒から数分単位の処理時

間がかかる。しかし、HP-UX＋Serviceguard の場合、クラスター再構成に約 4 秒、リカバリー完了まで約 10 秒しかかからな

い。これだけ高速な復旧時間なら、一般的な Web ベースの業務システムではネットワークのレイテンシが多少長引いた程度にし

か感じないだろう。

図 5：Serviceguard のフェイルオーバー時間比較

こうした高速処理を実現できるのは、HP-UX の OS カーネルと強固に連携しているからである。 Serviceguard の主要プロセス

は、他のユーザープロセスよりも高い優先順位で動作し、HA クラスターとして確実に機能する仕組みになっている。 HP-UX カ

ーネルのハングアップを検出することも可能だ。障害ノードはシステムリセットで強制的に排除し、I/O も強制停止するなど、

不確実な動作を徹底的に排除する機能も備えている。もちろん、イベント監視や管理ツールなど、他の HA 関連製品と連動する

ように設計されており、個別のデータベース製品に対応するオプションも用意されている。

7


Serviceguard と Oracle RAC の連携

Oracle Real Application Clusters（RAC）の環境では、Oracle Clusterware に Serviceguard の拡張機能「Serviceguard

Extension for RAC」を追加することで、フェイルオーバーの高速化を簡単に実現できる。また、Serviceguard の機能によ

り、Oracle RAC 以外のアプリケーションの監視やフェイルオーバーも問題なく実行できる。

可用性の違い：作り込みが必要な Linux と完成された HP-UX

第 1 回の今回は、可用性をテーマに Linux/x86 サーバーと HP-UX/Integrity サーバーを比較してきた。企業で稼働するさまざ

まなシステムには、事業継続のために決して止められないミッションクリティカルなものもあるだろうし、障害が発生して 5～

10 分程度のシステムダウンならば大勢に影響がないものもあるだろう。そうしたシステムの特性に合わせ、適材適所でプラット

フォームを選択することが重要だが、可用性にこだわったシステムを構築しなければならない場合、HP-UX/Integrity サーバー

に一日の長があることは明らかだ。そこには、イニシャルコストの差だけでは決して測ることのできない価値がある。

次回は、ダウンタイムを最小化するための「障害発生時における迅速な切り分け」をテーマに、Linux/x86 サーバーと HP-

UX/Integrity サーバーを比較してみたい。

第 2 回

OS のライフサイクルが及ぼすサポート問題とは？


ミッションクリティカル・システムを構築する際、OS やサーバーの可用性、信頼性、拡張性など比較・検討することは、非常に

重要なことである。しかし、ビジネスの中核を担うシステムを構築する場合、機能・性能だけでなく、考慮すべき重要な事項が

ある。それは、OS やサーバーをベンダーがどこまでサポートするかという点である。長期間の利用を想定して業務アプリケー

ションを構築しようとしても、OS やサーバーのサポート期間が短ければ、とても安心して採用することはできない。今回は、シ

ステムのライフサイクルという側面から HP-UX/Integrity サーバーの優位性を探ってみたい。

長期間使い続けるシステムに適したサポートとは？

オフィスの機器を見渡してみると、電話機、コピー機、ファクシミリ、空調設備など、どれも通常は 10～15 年、言い換えれば

寿命が来て壊れるまで使い続けることが多い。ところが、PC、サーバー、プリンターなどの IT 機器だけは、おおよそ 5 年前後

で役目を終えてしまう。もちろん、技術革新による性能向上、処理するデータ量の増大化により、IT 機器があっという間に陳腐

化するのは分かる。だが、すべてのシステムが 5 年で役立たずになってしまうわけではない。アプリケーションの仕様を変更す

ることなく、同じシステムを長期間使い続けるケースもよくあることだ。しかし、同じシステムを使い続けるには、OS のサポー

トライフサイクルという壁がある。

OS のサポートライフサイクルという壁

8


OS のサポートライフサイクルは、OS を提供するベンダーが独自に設定するものだ。この期限を超えた場合、OS の利用は自己責

任、つまり何らかの不具合やセキュリティ上の脆弱性が発見されたとしても、それらに対する手当てはない。そこで、企業は選

択を迫られる。新しいバージョンの OS に乗り換えるか、古いバージョンの OS のまま使い続けるかという選択である。

図 1:安定した環境で長時間利用するためには？

新しいバージョンの OS に変更する場合、以前のバージョン向けに作成したアプリケーションが正常に動作するかどうかの確認作

業が必須になる。正常に動作しない場合は、アプリケーションを含めて業務システム自体を作り直さなければならない。当然の

ことながら、開発・構築の手間とコストがかかってくる。今までのアプリケーションで十分なのに、コストをかけてまでわざわ

ざ作り直す必要性は感じない ―― そう判断した企業は、従来のシステムを使い続ける。これがいわゆる“塩漬け”である。ハード

ウェアが老朽化したら、システムをそのまま仮想環境へと移行する。しかし、OS のサポートは受けられないので、セキュリティ

上の脅威・危険に晒されることになってしまう。長期間使い続けるシステムを構築する場合、それだけ OS のサポート期間を考

慮すべきなのである。



富樫先生

主要 OS のサポートライフサイクルの違い：10 年フルサポートの HP-UX

システムを使い続けるために長期サポートライフサイクルの重要性

を知る！

1.主要 OS のサポートライフサイクルの違いを把握しよう！

2.システム移行時におけるリスクとコストの違いを把握しよう！

3.レガシー救済の方法とサポート範囲の違いを把握しよう！

9


では、長期間使い続けるシステムでは、どんな OS を選択すればよいのだろうか。答えは簡単。サポートライフサイクルが長い

OS を選べばよいのだ。以下、主要サーバーOS のサポートライフサイクルを比較してみよう。

Windows の場合、インシデントサポート（有償・無償）が受けられ、セキュリティパッチや修正プログラムが無償で提供される

フルサポート（マイクロソフトはメインストリームと呼ぶ）期間は、製品の初期版（RTM）が出荷された時点から 5 年間であ

る。フルサポートを終えると、最低 5 年間の延長サポートのフェーズになる。ここでは、セキュリティパッチは無償で提供され

るものの、セキュリティ関連以外の修正プログラムをリクエストする場合、「延長修正プログラムサポート契約」を購入する必要

がある。なお、マイクロソフトは、Windows のサポートライフサイクルの延長サポートを含めて最低 10 年間、必要に応じて延

長するとしている。

Linux の代表的なディストリビューションである Red Hat Enterprise Linux の場合、新しいハードウェアへの対応やソフトウ

ェア機能拡張にも対応するフルサポートの期間が 4 年間、ハードウェアへの対応が一部のみに絞られるデプロイメントサポート

が 1 年間、マイナーリリースが提供されないメンテナンスサポートが 2 年間の合計 7 年間のサポートになる。このサポートライ

フサイクル期間中は、技術的な問い合わせやエラッタ（重要なアップデート、バグフィックスを集めたもの）は提供される。

「Red Hat Enterprise Linux 3」に関しては、サブスクリプション契約の更新することにより最大 3 年延長が受けられ、最大

10 年間サポートされるようになった。

HP-UX の最低 10 年サポート

x86 サーバー上で稼働する上記 2 つの OS に対し、HP-UX は最低 10 年間というサポートライフサイクルポリシーのもとで提供

されている。 Windows や Red Hat Enterprise Linux のようにフルサポートと段階的にサポート範囲を縮小する延長サポート

などの区別はなく、最低 10 年間は一貫して同じサポートが提供されているのだ。

HP-UX の最低 10 年サポートは、2005 年に世界に先駆けて日本国内で始まったものだ。たとえば、2000 年 12 月に出荷開始

された「HP-UX11i」は、2010 年 12 月までフルサポートされており、セキュリティパッチや修正プログラムが提供され続けて

いる。 10 年間というのはあくまでも最低ラインであり、2007 年 4 月に出荷した「HP-UX11i v3」のサポート期間を 2020 年

12 月まで延長することを発表している。詳細はこちら

最低 10 年間、一貫してフルサポートが提供されることで、HP-UX 上で構築されたシステムは、長期間に渡って安定して運用で

きることになる。 HPE は、OS のサポート終了時期も明らかにしているので、システムを導入するときに OS がいつサポート終

了になるのかを把握でき、次期システムへの更新を早期に計画できるというメリットも得られるのだ。

システム移行時におけるリスクとコストの違い：長期的にコストを抑える HP-UX

サポートライフサイクルの期間によって得られるメリットは何だろう。それは、次期システムに移行する際に、とくに効いてく

る。

たとえば、2010 年に Linux/x86 サーバーと HP-UX/Integrity サーバーでシステムを構築したとしよう。 OS とサーバーハー

ドウェア、市販のアプリケーションやミドルウェアなども含めたトータルコストは、間違いなく Linux/x86 サーバーのほうが安

上がりになるだろう。 5 年後の 2015 年、ハードウェアの老朽化に伴って、2010 年に構築したシステムを次世代のプラットフ

ォームに移行することになった。 Linux は、新しいハードウェアに対応するフルサポートの期間が終了しているので、新しいバ

ージョンに入れ替えなければならない。それに伴い、市販のアプリケーションやミドルウェアなども更新する必要がある。とこ

ろが、HP-UX は 5 年後もフルサポート期間中である。したがって、ハードウェアのみ移行すれば、OS もミドルウェアもそのま

ま利用することができる。つまり、システムの次期更新も含めた長期的な視点で見れば、HP-UX を選択したほうがトータルコス

トを抑えられる可能性が高いのである。

http://h50146.www5.hpe.com/products/software/oe/hpux/topics/support/

10


図 2：システム移行を含む長期的な総コスト

レガシー救済の方法とサポート範囲の違い：バイナリ互換を維持する HP-UX

サポートライフサイクル期間を終了したバージョンの OS で稼働する、レガシーシステムの救済方法も、Linux/x86 サーバーと

HP-UX/Integrity サーバーでは大きく異なっている。

今、情報システムの現場では、サーバー仮想化の話題が花盛りだ。サーバー統合によるコスト削減効果、新しい仮想マシンをす

ぐに用意できる俊敏性、物理環境と仮想環境の分離による可用性の向上など、サーバー仮想化には多くのメリットがあるが、実際

にサーバー仮想化を導入する動機として多いのが、実はレガシーシステムの救済なのである。

確かにサーバー仮想化は、ハードウェアが老朽化してしまったが新しいシステムを構築し直す必要性も予算もないという場合に最

適なソリューションである。ただし、リスクも大きいことを認識しておくべきだろう。まず、サポートライフサイクル期間が終

了した OS では、どんなトラブルが発生するか分からない。万一、新たな脆弱性が発見されて、それを狙ったマルウェアが出現

すれば、修正パッチが提供されないレガシーシステムはお手上げである。仮想マシンに“塩漬け”にしたはずのサーバーが踏み台に

なって DoS 攻撃の加担をしたり、仮想マシン間でマルウェアが広まったりする危険性も十分に考えられる。

問題は、OS だけにとどまるものではない。ハイパーバイザを含む仮想化ソフトウェアは、物理環境から仮想環境への移行を支援

するツールを用意しているものの、それが正常稼働するかどうかを保証するわけではない。サーバー仮想化のシステム構築を受

注した SI ベンダーは「ウチが面倒を見ます」と言うかもしれないが、基本的には自己責任で使い続けることになる。これが、

x86 サーバーの仮想化におけるレガシー救済の現状である。

ところが、HP-UX では事情がまったく異なる。そもそも HP-UX は、HP が自社開発した RISC プロセッサ「PA-RISC」上で稼働

する UNIX OS だった。しかし、HP はインテルと提携して PA-RISC に代わる新しいプロセッサの開発に臨み、その結果

Itanium という新しいプロセッサが誕生した。これにより、HP-UX の稼働環境は、PA-RISC から Itanium へと移行した。この

ように、プロセッサアーキテクチャが大きく変わるという経験があるにもかかわらず、HP-UX 上で稼働するアプリケーション

は、バイナリ互換でそのまま実行することが可能になっている。これが、HP-UX に搭載されている「ARIES（ダイナミックバイ

ナリトランスレータ）」という機能だ。

ARIES は、PA-RISC 用アプリケーションが Integrity サーバー上で稼働するように、ソフトウェア的にエミュレーションする機

能。このおかげで、レガシーシステム上で稼働するアプリケーションをそのまま移行できる。ただし、移行するにあたっては、

11


アプリケーションのインベントリ収集、および変換作業を行い、アプリケーションコンポーネントを手動で分析・複製してから

ARIES を使って実行しなければならなかった。それを一気に解決するのが、HP-UX の最新機能「HP 9000 Container」であ

る。これは、HP 9000 で実行されていた HP-UX の環境をそのままコンテナに移行し、ARIES を使って実行するもの。手動で

行う分析や各種設定作業を繰り返し行う必要がなく、シンプルかつ容易に変換できる。

図 3：HP-UX の最新機能「HP 9000 Container」

この HP 9000 Container と HP-UX の仮想化機能「Integrity VM」を組み合わせると、複数台の HP 9000 環境を Integrity

サーバー上へ仮想化統合することも可能になる。この仮想環境は、すべて HP-UX に含まれる機能であり、HP-UX がフルサポー

トする。自己責任が基本の x86 サーバー上の仮想環境とは大きく異なるのだ。

図 4：Integrity VM と HP 9000 Container によるサーバー統合

サポートライフサイクルの違い：長期利用を想定したポリシーを貫く HP-UX

12


今回の記事で明らかになったのは、HP-UX が長期間使い続けるシステムにとって最適なサポートライフサイクルを提供している

こと、上位互換性の確保により投資保護を実現すること、そしてレガシーシステムの移行を十分に考慮していることだ。こうした

要素も、とりわけミッションクリティカル・システムには求められるものだ。

第 3 回

障害発生時における迅速な切り分けを比較


事業の根幹に関わる重要なミッションクリティカル・システムには、決してシステムを止めることにない可用性が求められる。高

可用性を実現するためにシステムを冗長化・多重化することも重要だが、どんなに堅牢なシステムを構築したとしても、障害発生

のリスクをゼロにすることは不可能だ。しかし、たとえ障害発生のリスクをゼロにできなくても、障害発生の根本原因を即座に発

見・特定できれば、障害発生によるダウンタイムの短縮に大きく寄与することになり、再発というリスクも防止できる。今回は、

障害発生時において迅速な切り分けを実現する HP-UX/Integrity サーバーの優位性を解説する。

根本原因が分からなければ、障害を繰り返すことに

日進月歩、急速に普及を続ける IT テクノロジーのおかげで、今のコンピューターシステムは障害発生の頻度がずいぶん小さくな

っている。しかし、メカニカルなパーツを組み合わせて作られている以上、障害発生をゼロにすることは残念ながら不可能と言わ

ざるを得ない。さらに、障害発生はすべてがハードウェアに起因するものとは限らない。ソフトウェアの不具合により、障害が引

き起こされることもある。

重要なのは、障害が発生したときにその原因を出来るだけ早く発見・特定することだ。これにより、ダウンタイムからの復旧時間

は大幅に短縮され、可用性も高まる。システムの停止を回避するために HA クラスター構成で二重化しているからといって、障害

原因を即座に特定しなくても大丈夫、と高を括ってはいけない。障害が発生して稼働系システムがダウンし、待機系システムが代

替処理を行っている間、冗長性は大きく損なわれているからだ。この事態から一刻も早く脱するには、障害からの復旧を迅速に進

めるとともに、原因の特定と切り分けが行えることが望ましい。

障害から復旧しさえすればよい、と原因究明に無頓着になってもいけない。システムがダウンして根本原因が分からないままにし

ておくと、同じ障害を繰り返すことも考えられるからだ。たとえば、CPU やメモリに障害が発生してシステムがダウンしたこと

が分かったとしても、その原因が CPU やメモリなどを構成するハードウェアの故障にあるのか、それとも CPU やメモリに致命

的なエラーを発生させるソフトウェアの不具合にあるのかによって、対処の仕方は当然のことながら変わってくる。対処方法を誤

れば、同じ障害が繰り返されるばかりか、無駄なコストをかけることにもなりかねない。

そこで、ミッションクリティカル・システムに求められるのが、障害発生時にその原因を即座に発見・特定し、障害の内容を切り

分けて的確な対応を行えるように支援する機能である。


13



富樫先生

障害の根本原因究明を実現する機能の違い：HP-UX/Integrity サーバーのハード

ウェアダンプ

HP-UX のハードウェアプラットフォームである Integrity サーバーには、インテルが最新テクノロジーを結集して開発した 64

ビット CPU、インテル® Itanium® プロセッサー（以下、Itanium プロセッサー）が搭載されている。この Itanium プロセッ

サーには、障害発生時の根本原因を即座に発見・特定するために有用なハードウェアダンプ機能が搭載されている。

Itanium プロセッサーは “遺言”を残す

システムの稼働中、Integrity サーバーに搭載された Itanium プロセッサーは、発生したエラーがハードウェアで訂正されたの

か、ファームウェアで訂正されたのか、OS で訂正されたのか、その内容をチップセットを通じて NVRAM（Non Volatile RAM

＝不揮発性メモリ）に記録している。また、HP-UX では、NVRAM に書き込まれたエラーメッセージを定期的に参照し、訂正さ

れたエラーカウントをチェックしている。

ところが、訂正できない深刻なエラーが発生し、障害発生の根本原因を取り除いたのちにシステムを再起動しなければならないケ

ースが発生することも考えられる。その際、Itanium プロセッサーは働きを停めることになるわけだが、黙って働きが停まるわ

けではない。Itanium プロセッサーは、「こういうわけでシステムが停止した」という“遺言”を残すのだ。これが、Itanium プ

ロセッサーに備えられたハードウェアダンプ機能である。

Itanium プロセッサーは、ダンプファイルを NVRAM に保存する。そのダンプファイルには、訂正できなかったエラーが発生し

た際の全レジスタの内容が記録されており、これを解析することで障害原因をすぐに特定することが可能になっている。これによ

り、たとえばメモリの DRAM チップに不良があると分かれば該当するメモリモジュールと交換し、CPU のコアに不具合があると

分かれば CPU モジュールを交換する。また、ソフトウェアに起因する障害と分かれば、障害回避のための修正パッチを開発す

る。このようにして、障害の原因を特定し、同じ障害が再び発生しないように対処することが可能になるわけだ。

障害発生時における根本原因を即座に究明できる機能を知る!

1. 障害の根本原因究明を実現する機能に違いがあることを理解しよう！

2. システムがサポートするイベントトレーサビリティの違いを理解しよ

う！

14


図 1：NVRAM に訂正されたエラーを記録

これに対し、Linux/x86 サーバーの場合、インテル® Xeon®プロセッサーにはハードウェアダンプ機能がない。したがって、

ハードウェアに起因する障害の場合、何らかのエラーによってシステムダウンしたという情報しか得られない。原因が特定できな

いので、どのコンポーネント、どのモジュールを交換すればよいのか調査するのに時間がかかることになる。

図 2：障害時の切り分けの比較

※インテル、Intel Inside、Intel Inside のロゴ、Pentium 、Intel Xeon、および Pentium III Xeon は、米国その他の国々に

おけるインテル株式会社もしくはその子会社の商標または登録商標です。

15


具体的な事例に見る復旧までの時間の差：ハードウェアダンプ機能の有効性を示す

HP-UX

ハードウェアダンプ機能の有効性を理解するために、ここで具体的な障害事例を想定して解説してみよう。 HA クラスター構成により冗長化された HP-UX/Integrity サーバーがある。稼働系システムに何らかの障害が発生してシステムがダ

ウンし、業務サービスは待機系システムにフェイルオーバーした。このとき、HP-UX のシステム運用管理担当者は、リモートから障害の原因を調査し、稼働系システムの NVRAM に残されたハー

ドウェアダンプファイルを参照する。そして、ログにより以下のような記載を確認した。

図 3：HP-UX での対応例

これにより、CPU への電源供給が絶たれたことが、障害の原因と特定できた。該当するコンポーネントを交換してシステムを再

起動し、業務を復帰させることが可能になった。ハードウェアダンプが記録されていたために、障害発生時の切り分けが容易にな

り、原因を明確にできたとともに、短時間のうちに正常なシステムへと復旧することが可能だった。

一方、Linux/x86 サーバーではどうだろうか。同様に、HA クラスター構成により冗長化された Linux/x86 サーバーがあり、稼

働系システムに障害が発生してシステムがダウンして業務サービスが待機系システムにフェイルオーバーしたとしよう。

Linux のシステム運用管理担当者は、リモートから障害の原因調査を開始し、システムログを確認してみる。しかし、「予期せぬ

エラー」によりシステムダウンが発生したという限定的な情報しか得られないケースもある。

そこでシステム運用管理担当者は、データセンターに設置されている該当のサーバーの場所まで足を運び、原因究明にあたる。目

視をして確認しても異常が発見できないため、限られたシステムログしかない場合では原因がハードウェアにあるのか、ソフトウ

ェアにあるのか切り分けられない。そこで、システムボードの交換、CPU モジュールの交換、メモリモジュールの交換、I/O バ

ックプレーンの交換などを見込みで試してみる。一つずつ交換しながら原因究明にあたると時間がかかるので、原因になりそうな

コンポーネント・モジュールをまとめて交換し、明確な原因を特定できないまま応急処置的に復旧させた。

16


これにより、とりあえず障害発生前の状況に戻すことは可能だろう。しかし、根本原因が特定されていなければ、再び同じ障害・

エラーに見舞われるリスクを完全に払拭することはできない。故障していないコンポーネント・モジュールを交換することによ

り、本来は必要のないコストをかけることにもなりかねない。業務システムを利用するユーザー部門も「本当にハードウェアの問

題だったのだろうか。ソフトウェアには原因がないのだろうか。また同じエラーが発生して業務を止めることにならないだろう

か」といった不安や懸念を抱えたままになる。そして、同じ障害・エラーが繰り返されれば、システム運用管理担当部門への信頼

が失墜することになる。

この事例から、ハードウェアが独自に取得するログによって障害発生時の切り分けが可能な HP-UX/Integrity サーバーに優位性

があることは明らかだ。冗長化構成にし、決して停めたくないミッションクリティカル・システムならばなおさらのこと、HP-

UX/Integrity サーバーを選択すべきだろう。

システムがサポートするイベントトレーサビリティにおける HP-UX と Linux の比

較

ここまでは、HP-UX/Integrity サーバーに搭載されたハードウェアダンプ収集機能により、ハードウェアイベントに関するトレ

ーサビリティに優れていることを紹介した。次に HP-UX、と Linux の、イベントトレーサビリティを実現するさまざまなモニ

タリングツール、およびログファイルについて比較してみよう。

まず HP-UX では、修正可能なメモリエラーや物理ディスク障害など、ハードウェアに関連するイベントのトレーサビリティを実

現するツールとして「EMS（Event Monitoring Service）」や「System Fault Management（SFM）」を用意している。こ

れらは障害監視の為のフレームワークで、ハードウエアで発生する障害だけでなく OS やミドルウエアで発生する障害も検知し

syslog 等をつかって通知することが可能だ。また、システム運用管理ツールの「SMH（System Management

Homepage）」、CPU やメモリの利用率といった性能に関するイベントには、パフォーマンスの監視、診断をリアルタイムで

行う「GlancePlus」が用意されており、ps や top、vmstat、iostat などのコマンド/ツールだけでは入手困難なパフォーマンス

情報を入手できる。

図 4：イベント・ディスクリプション：多くのイベントの種類が設定されている

これに対し、Linux/x86 サーバーも、ハードウェアダンプ機能を除けば、さまざまなツールによってイベントのトレーサビリテ

ィが可能になっている。［ｒsyslog］や「syslog-ng」のような先進的な機能を実装している他、「procfs」等を使えばパフォ

17


ーマンス情報のみならずカーネル内の情報を簡単に入手することも可能だ。また、「GlancePlus」の Linux 版も用意しており、

様々な情報収集が可能となっている。

HP-UX/Integrity サーバーと Linux/x86 サーバーの違いは、ツールを開発したベンダーが直接サポートしているか否かという

ところにある。HP-UX 用の各種ツールは、開発者である HP 自身が HP-UX の標準またはオプション機能として提供しているも

のであり、すべてがサポート対象範囲になる。しかし、オープンソースの Linux の場合、SI ベンダーかディストリビューターと

サポート契約を結び、ツールのサポートもその範囲に含める必要がある。また、ツールの開発が終息を迎えたら、自己責任で最新

バージョンにアップデートしなければならない。その点、HP-UX は OS のサポート範囲内で、すべてのアップデートに対応す

る。ツールを使う安心感は、設計・開発元による一貫したベンダーサポートという意味では当然のことながら HP-UX のほうが優

位になる。

ちなみに、HP の場合、Linux 向けの管理ツールを簡単に導入・更新できるようにするためのソフトウェアパッケージ「PSP

（ProLiant Support Pack）」が無償で提供されている。

根本原因の究明こそが再発防止を含めた障害対応

障害発生が避けられないものであれば、少なくとも同じ障害の再発を防止するために、根本原因の究明は欠かせない。しかし、発

生原因のヒントがなければ、究明するまでに膨大な時間がかかるものだ。

今回紹介したように、ハードウェアダンプ機能を搭載した HP-UX/Integrity サーバーならば、原因の発見・特定にかかる時間を

最小化することができる。障害を起こさない、障害が発生しても業務が停止しないように冗長化するといったシステム上の対策も

重要だが、障害発生原因を切り分けられることも可用性を高めるためには非常に重要なのだ。

第 4 回

キャパシティとスケーラビリティについて問う


重要な基幹業務アプリケーションが動作する OS には、アプリケーションが安定稼働するためのさまざまな機能・性能が求められ

る。アプリケーション視点からは、OS の機能を比較することは意味のないことと捉えられるかもしれない。しかし、実際には

機能の違いが性能・信頼性の差につながることもある。今、多くの OS、プラットフォームがミッションクリティカル・システム

での利用に耐え得る機能強化が進められているが、キャパシティやスケーラビリティに関しては、実績のある HP-UX/Integrity

サーバーに一日の長がある。今回は、そうした機能の違いを見てみよう。

システムの信頼性に差が出る詳細な機能の違い

基幹業務アプリケーションが稼働するミッションクリティカル・システムでは、高い可用性を維持するためにピーク時の負荷を想

定したシステム設計が行われることが多い。ハードウェア性能が急速な進化を遂げつつある現在、そうしたシステム設計の手法

は、リソースを有効活用できず、無駄があると批判を受けることも多々ある。しかし、万一の事態を考えると、たとえオーバース

ペックであっても余裕を持ってシステムを構築することを選択する企業は、まだまだ多いのが実情だ。

18


同様に、OS にどれだけのキャパシティがあるかは、アプリケーションを設計する上で重要だ。たとえば、ビジネスインテリジェ

ンスを実現する各種解析業務などは、システムや OS がどれだけのメモリ容量をサポートしているかによってパフォーマンスが大

きく違ってくる。サポートされているプロセッサー数やボリュームサイズ、I/O スロット数なども同様だ。

ただし、理論上対応できるという数値が必ずしも優位にはならないということは知っておかなければならない。本当に重要なの

は、OS やシステムがどれだけのキャパシティまでベンダーが責任をもってテストし、サポートしているかということなのだ。

一方、システムのリソースを有効利用するための手段として、仮想化技術が注目されている。仮想化を採用する目的は、どんなサ

ーバープラットフォームやハイパーバイザーを用いても変りない。しかし、同一の物理システム上で稼働する仮想サーバーに障害

が発生した際、その影響範囲がどこまで及ぶかは、仮想化技術によって微妙な差がある。ミッションクリティカル・システムを仮

想環境で稼働させようという場合、こうした機能差を重視することも大切になる。



富樫先生

キャパシティの違い：スケーラビリティに優れた HP-UX/Integrity サーバー

ハードウェアの進化とともに、システムに求められる性能もどんどん高まっている。それに伴い、OS やシステムがサポートする

キャパシティもどんどん拡張され、現在は当面の間、十分に対応可能だろうと想定されるだけの容量がサポートされるようになっ

た。マルチプロセッサーとして扱えるプロセッサー数、論理的に扱えるメモリ容量やディスクのボリューム容量、接続可能な I/O

ポート数などがそれに相当する。

ミッションクリティカル・システムを非常に高い信頼性と性能で稼働させることを目的に開発されている HP-UX/Integrity サー

バーでは、いずれのキャパシティも非常に大容量だ。たとえば、マルチプロセッサーは最大 256 ウェイ（コア数）まで対応。メ

モリ容量は最大 2 テラバイト、ボリュームサイズは最大 256 テラバイト、ファイルサイズは最大 16 テラバイトまでサポートさ

れている。また、I/O のキャパシティでは、最大 192 スロットまで拡張可能だ。

これらの数字は、理論的なものではない。HP が実際にテストを実施し、稼働することを保証したものだ。ここがポイントであ

る。

OS の拡張性 HP-UX 11i V3 on Integrity RedHat Enterprise Linux 5 on x86

最大サポート論理プロセッサー数 256 96

OS/システムと同時にサポートされる機能の違いを見極める

1. OS がサポートするキャパシティに違いがあることを理解しよう！

2. 仮想化技術の違いで障害発生時の影響範囲に差が出ることを理解し

よう！

3. ワンストップでサポートする HA クラスターの優位性を理解しよ

う！

19


最大サポートメモリー容量 2TB 512GB

最大ボリューム容量 256TB 16TB

最大ファイルサイズ 16TB 2TB*

(Ext3 ファイルシステム)

I/O キャパシティ 192 I/O スロット 28 I/O スロット

*XFS ファイルシステムの制限を超える場合は、特別なサポート契約が必要です

表 1： HP-UX 11i v3 と RedHat Enterprise Linux 5 とのスケーラビリティ比較

それに対し、Linux/x86 サーバー（現時点でエンタープライズシステムに最も採用例が多い RedHat Enterprise Linux 5 の場

合）は、マルチプロセッサーが最大 96 ウェイ、メモリ容量が最大 512 ギガバイト、ボリュームサイズが最大 16 テラバイト、

ファイルサイズが最大 2 テラバイト（Ext3 ファイルシステム）にとどまっている。I/O に至っては、最大 28 スロットに制限さ

れる。いずれも、公式にサポートされている数字だ。

これらは正直なところ、現時点では比較検討の必要性がないほどの数字ではある。しかし、システムの将来性を考えたとき、どこ

までのキャパシティをベンダーが保証しているかによる安心感は、ずいぶん違ってくる。Linux/x86 サーバーも、今後は新しい

バージョンに更新されるたびに拡張性が高まると予想されるが、それに対応するためにはアプリケーションを作り直さなければな

らないこともあるだろう。信頼できるアプリケーションを長く使えるという意味からも、現時点でキャパシティに余裕があるほう

が良いことは間違いない。

障害発生時の影響範囲に差が出る仮想化技術の違い：HP-UX/Integrity サーバー

の堅牢なシステム基盤

現在、多くの企業システムでハードウェアリソースの有効活用を目的に、仮想化技術の導入が進んでいる。開発系、インフラ系シ

ステムでは仮想環境に統合することが当たり前のようになりつつあり、基幹業務アプリケーションを仮想環境に移行する例も急増

している。

しかし、ビジネスの根幹となるミッションクリティカル・システムを仮想環境へ移行することについては、まだまだ躊躇する企業

が多い。当然、仮想環境の信頼性・可用性を危惧してのことだ。すでに数多くの導入事例があるにも関わらず、それでも一歩踏み

出せないのである。

その理由は、同一のハードウェア上に構築された仮想環境で稼働する仮想サーバー同士の影響範囲にある。仮想サーバー個々の独

立性は高いものの、ハードウェアリソースを共有しているため、他の仮想サーバーに深刻な影響を与える障害が発生しないとは限

らない。

そうした課題を解決するには、ハードウェアと一体化して開発された仮想化技術を導入するしかない。そのニーズにピッタリと当

てはまるのが、HP-UX/Integrity サーバーのパーティショニング・ソリューションである。

20


図 1：パーティショニング・ソリューション比較

物理パーティショニング技術「nPartitions」（nPar）

たとえば、ミッドレンジおよびハイエンドの HP-UX/Integrity サーバーでは、物理パーティショニング技術「nPartitions」

（nPar）が提供されている。これは、サーバーを構成するブレードやセルボード単位で物理パーティションを構成できるという

もので、ハードウェアレベルの分割・分離により、高い可用性を確保できるというものだ。OS に障害が発生しても、他のパーテ

ィションにまったく影響を与えず、再構成やリブートがダイナミック（動的）に行える。

こうした物理パーティションは、Linux/x86 サーバーには存在し得ない。したがって、他のパーティションに影響することなく

再構成やリブートすることは可能であっても、障害発生時でも性能・稼働に影響がないとは言えない。

論理パーティショニング技術「Virtual Partition」（vPar）

もちろん、物理パーティションは、ブレードやセルボード単位でしか構成できないので、リソースの有効活用という点では不足す

ることもある。そこで、HP-UX/Integrity サーバーのパーティショニング・ソリューションには、論理パーティショニング技術

「Virtual Partition」（vPar）も用意されている。こちらは単一のサーバーまたは前述の物理パーティションの nPar 上で利用す

ることが可能で、nPar とほぼ同等の使い勝手を実現しながらプロセッサーのコア単位でパーティションを分割できる。もちろ

ん、OS のカーネルやアプリケーションは、それぞれの vPar で完全に独立している。

仮想マシン「Integrity Virtual Machines」（Integrity VM）

Linux/x86 サーバーで一般的なハイパーバイザー製品と同じように、仮想マシン上に個別のゲスト OS 環境を構築することも可

能だ。これが「Integrity Virtual Machines」（Integrity VM）である。ゲスト OS には HP-UX だけでなく、Linux や

Windows、さらには OpenVMS も導入できる。

21


物理パーティション論理パーティション仮想マシン

Integrity

Superdome2 nPartition Virtual Partition

Integrity

Virtual Machine

Integrity rx2800

i2

Integrity BL8x0c

i2

なしなし Integrity

Virtual Machine

x86 サーバーなしなし

Red Hat Enterprise

Virtualization(KVM)

Citrix Xen Server

実装ファームウェアファームウェアハイパーバイザー

パフォーマンスの

オーバヘッドなしなしあり

障害の分離度

極めて高い

（単一コンポーネントの障害

により複数の物理パーティシ

ョンが同時に使用不可（全停

止）になることはない）

低い

（プロセッサーやメモリーの

障害時には、該当物理パーテ

ィション内の全ての論理パー

ティションが使用不可）

低い

（プロセッサーやメモリー、IO カード

の障害時には、それらのリソースを使用

する全ての仮想マシンが使用不可）

リソース割り当て 8 コア単位 1 コア単位 %、MHz 等

リソースの共有不可不可可能

表 2：パーティショニング機能比較

コア単位でリソースを自在に操る「インスタントキャパシティ」（iCAP）

こうした仮想環境におけるリソースの最適化、ダイナミックな拡張や再構成などの利用を支援する HP-UX/Integrity サーバー特

有の「インスタントキャパシティ」（iCAP）も用意されている。これは、プロセッサーそのものと、プロセッサーの利用権を分

離させる技術で、仮想化環境上で様々な活用ができる。

たとえば、あらかじめ利用権のないプロセッサーを企業システムに納入しておき、必要に応じてコア単位で利用権を後払いで購

入、即座に利用可能になる。これにより、システム設計の負担を軽減し、オーバースペックになりがちな仮想環境のハードウェア

プラットフォームを無駄なく、無理なく最適に利用できるようになる。一時的な需要発生時に利用できる「TiCAP」もある。プロ

セッサー単位でかかるソフトウェア・ライセンスが必要になるまで発生せず、無駄なコスト削減に繋がる。

また、仮想化環境での利用権の共有もできるのが、iCAP の魅力の一つである。たとえば、クラスター構成のアクティブ側の利用

権を、障害発生時にスタンバイ側へ移動することができる。つまりスタンバイ側は、稼働するまでコストが発生しないということ

なのだ。

22


図 2：インスタントキャパシティ

ユーティリティコンピューティングを実現するこうした柔軟な料金体系で利用できる仮想環境は、残念ながら Linux/x86 サーバ

ーでは構築できない。とりわけ、オンプレミスで企業システム内にプライベートクラウド環境を構築するためのシステム基盤とし

て、HP-UX/Integrity サーバーの仮想環境は非常に優位と言えるだろう。

クラスターの違い：カーネルと密接に連携した HA クラスタリングを実現する HP-

UX/Integrity サーバー

HP-UX/Integrity サーバーと Linux/x86 サーバーの機能比較でもう一つ欠かせないのが、高可用性を担保する HA

クラスター機能である。ミッションクリティカル・システムでは、可用性を高めるために二重化、三重化の冗長構成にした HA クラスタリン

グが当たり前のように行われている。HA クラスタリングの仕組みは、ソフトウェアベンダーが提供する市販製品を

導入することが一般的だ。Linux でも、たとえば RedHat Enterprise Linux には「Red Hat Cluster Suite」がディスト

リビューションに含まれる。しかし、機能・性能、使い勝手の面から市販製品が選択されるケースも少なくない。一方、HP-UX にも「Serviceguard」という HA クラスター機能が用意されている。その最大の優位性は、HP-UX カ

ーネルと強固な連携を実現している点である。特筆すべき点は、障害ノードをシステムリセットで強制排除できると

いう点だ。HA クラスタリングで最も留意しなければならないのは、障害が発生した稼働系ノードが中途半端に動い

たまま、待機系ノードに制御が移ってしまうということだ。これにより、データが正しく更新されなかったり、デー

タに違いが発生してしまうと、ビジネスに大きな問題が生じるおそれがある。それを防止するために、Serviceguard

は HP-UX カーネルと連携し、システムを完全にリセットしてしまうのも、HP-UX の機能として稼働する

Serviceguard の強みである。また、Serviceguard には構築、運用管理の負担を軽減する豊富な機能も用意されている。たとえば、Oracle

Database や IBM DB2、SAP 製品に対応した、HP によるテスト済みのスクリプトが「Enterprise Cluster Master

Toolkit（ECMT）」として用意されており、それをテンプレートとして適用するだけで HA クラスタリング環境を構

築できる。運用管理に関しては、待機系ノードの Serviceguard をアップグレードして切り替え、稼働系ノードをアップグレー

23


ドするローリングアップグレードに対応、メンテナンス時の計画停止時間の低減に寄与する。もちろん、ほとんどの

パラメーターは、クラスタリング稼働中にオンラインで設定を変更できる。当然のことながら、仮想環境にも対応し

ており、nPar や vPar、Integrity VM の VM ノード間でクラスターを構築することも可能だ。実際に、Serviceguard の稼働実績は非常に多く、国内でも金融、通信、流通業界のミッションクリティカル・システ

ムで豊富な採用事例がある。HPE も日本市場を最重視しており、ACSL（HA 製品ラボ）設計責任者、Bob Sauers 氏

も「Serviceguard はリリースから 15 年が経過したが、日本のユーザーからのフィードバックが品質の向上に役立っ

ており、新バージョンには日本のユーザーから要求された多くの新機能が実装されている」と話している。

仮想化技術や HA クラスターはまさに選定の決め手となるような詳細な機能差

OS の機能比較というと、“重箱の隅のつつき合い”というのが常である。実際、現在のミッションクリティカル・システムで採用さ

れている OS に、決定的な機能差があるとは言えない。しかし、よくよく掘り下げていくと、選定の決め手となるような詳細な機

能差も見えてくる。今回紹介したキャパシティやスケーラビリティ、とりわけ仮想化技術や HA クラスターなどの分野は、まさに

そうした機能差の部分だと言えるだろう。

第 5 回

プラットフォームの安定性とメンテナンス性


ミッションクリティカル・システムでは、何を優先してプラットフォームを選べば良いのだろうか。処理能力の高さ、機能の豊

富さ、拡張性の高さなど、業務アプリケーションの内容や用途によって優先すべき選択ポイントは異なってくるが、実際にシステ

ムを運用管理する情報システム部門の担当者にとっては、プラットフォームの安定性とメンテナンス性に優れていることが何より

も重要なポイントになってくる。第 5 回目の今回は、OS の安定性とメンテナンス性の観点から、Linux/x86 サーバーと HP-

UX/Integrity サーバーの違いを見てみよう。

高い安定性を裏付ける HP-UX/Integrity サーバーの真の実力とは？

ミッションクリティカル・システムのプラットフォームは、「安定性」に優れていることがとりわけ重要だ。しかし、「安定性」

というのは、実に抽象的な言い回しでもある。サービスをいかに停止させずに稼働し続けるかという可用性の高さを“安定してい

る”ということもあるし、ソフトウェアのエラーも含めて障害の発生頻度が少ないことを“安定している”ということもある。さらに

は、すでに実績のある、いわゆる“枯れた”技術を使うことが“安定している”につながるという考え方もある。

このように「安定性」という言葉の意味に正解はないが、運用管理を担当する情報システム部門に負荷がかからない、手間いらず

のプラットフォームであることが「安定性」が高いミッションクリティカル・システムとは言えるだろう。

では、運用管理担当者の負担がかからないプラットフォームとは何か。まず思い浮かぶのは、本連載第 1 回の記事でも述べたよ

うに、障害発生を未然に防ぐ、事前に対策する高可用性を実現する機能を持ち合わせているかどうかということがある。ただし、

それだけではない。システムダウンが発生するのは、障害発生時ばかりではないからだ。

24


システムダウンが最も多く発生するのは、OS を含むソフトウェアの不具合を修正したり、セキュリティパッチを適用したりする

アップデートを実施する際の計画停止である。だから、アップデートにかかる時間の長いか短いか、アップデートモジュールがテ

スト済みかどうか、アップデートをベンダーが保証・サポートしているかどうかといったこと ―― すなわち「メンテナンス性」

の高さは、「安定性」を語る上で極めて重要になるのである。

今回は、そうしたメンテナンス性の高さを実現する HP-UX/Integrity サーバーの特長を紹介する。



富樫先生

パッチ適用時のサービス停止時間を最小化する HP-UX/Integrity サーバー

ミッションクリティカル・システムでは、業務継続性の観点からダウンタイムを出来る限り短くすることが求められる。これは、

障害発生時はもちろんのこと、OS を含むソフトウェアの修正モジュールやセキュリティパッチを適用するときの計画停止も同じ

だ。

Linux/x86 サーバーを利用した一般的なシステム運用の場合、パッチ適用時はサービスを停止して事前バックアップを実施し、

その後パッチを適用する作業を行って、事後バックアップを行うという手順を踏む。これら一連のパッチ適用にかかる平均的なサ

ービス停止時間は、HPE の調べによると約 3 時間程度にもなるという。

実は、HP-UX/Integrity サーバーでも同じ手順を踏めば、Linux/x86 サーバーと同じだけのサービス停止時間が必要になる。そ

のサービス停止時間を最小化するために、HP-UX には「Dynamic Root Disk（DRD）」が用意されている。

DRD は、現用 OS 環境の稼働中に OS のイメージを複製・バックアップする。そして、複製された OS 環境にパッチを適用す

る。パッチ適用が完了したら、パッチ適用済みの OS 環境に切り替えるために再起動する。OS の再起動中はどうしてもサービス

が停止するが、その時間は数分から最大でも約 10 分程度だ。再起動時には複製 OS 環境が起動されることになる。

安定稼働を実現する「メンテナンス性」の重要性を知る

1. サービス停止時間を最小化する技術を理解しよう！

2. サーバーと OS の設計思想の違いを再確認しよう！

3. 第 2 世代 Integrity サーバーの最新機能を理解しよう！

25


図 1： DRD 利用によるサービス停止時間の最小化

パッチを適用する際には、もう一つ留意しなければならないことがある。それは、パッチ適用後の OS 環境に不具合があった場合

の対処だ。

Linux/x86 サーバーの場合、パッチ適用前に戻すには、事前に取得したバックアップからリストアするか、ロールバック機能を

利用するか、どちらかの方法をとることになる。しかし、HP-UX/Integrity サーバーでは、これらの方式に加えて、DRD を利

用することができる。バックアップをリストアする時間も、ロールバック機能でパッチ適用前に戻す時間も必要がない。

図 2：修正プログラムを適用前に戻す手段の比較

パッチ適用に関して、HP-UX/Integrity サーバーにはもう一つ優位なことがある。それは、パッチの適用頻度が低いということだ。

x86 サーバーで稼働する Linux や Windows などの OS では、緊急性の高いセキュリティパッチなどが不定期に配布される。これらを

26


適用するには、稼働中のシステムに影響があるかどうかテストを実施する必要があるが、その責任所在は基本的にパッチを適用し

なければならないユーザー側に委ねられている。

しかし、HP-UX/Integrity サーバーの場合は、メーカーの HPE 自身がテストを行い、認定されたものだけがパッチとして提供され

る。つまり、お墨付きが得られたものだけなので、安心して適用することが可能だ。しかも、パッチは「標準 HP-UX パッチバンド

ル」という形で定期的にまとめて提供される。システムに不要な修正モジュールなどは必ずしも適用する必要がないので、「パッ

チ管理」という意味では運用管理担当者の負担は軽減されることになる。

安定性に差が出る HP-UX/Integrity サーバーの設計思想

HP-UX/Integrity サーバーがミッションクリティカル・システムに相応しい安定性を実現しているのは、OS とハード

ウェアを一体化して開発することで、システムダウンを極小化しようという設計思想の違いにある。本連載では、

HP-UX/Integrity サーバーの設計思想について、第 1 回目の可用性、第 2 回目のライフサイクルをテーマにした記事で

も取り上げたが、ここで再確認してみたい。安定性の指針として、前項ではパッチ適用時のサービス停止時間を最小化するメンテナンス性の高さを紹介した。

DRD のようなソフトウェアツールが用意されているのは、システムのダウンタイムを最小化して、運用管理担当者

が通常の業務時間内にソフトウェアのメンテナンスが行えるようにするという HP-UX/Integrity サーバーの設計思想

に基づいたもの。Linux/x86 サーバーでは、パッチ適用のオペレーションを簡素化したり、スケジューリングによっ

てダウンタイムの影響を軽減したりする機能・ツールは提供されているものの、ダウンタイムの時間を出来る限り短

くしようという発想がないのだ。これは、可用性に関する考え方も同様である。HP-UX/Integrity サーバーは、ハードウェア障害に起因するシステム停

止を最小化する設計になっている。障害予兆のあるプロセッサコアを切り離して利用しない「Dynamic Processor

Resilience（DPR）」、L2/L3 キャッシュ上の ECC でリカバリできないエラーが発生しても、キャッシュラインのみ

無効にする「インテル® キャッシュ・セーフ・テクノロジー（ICST）」、レジスタや TLB でパリティエラーが発生

した際に該当するユーザープロセスを終了してシステムを継続運用する「Automated Processor Recovery

（APR）」、DIMM 上の DRAM が 2 つフェイルしてもシステムに影響を与えない「Double Device Data Correction

（DDDC）」などは、サービス停止時間を最小化するという設計思想を基にして組み込まれた機能なのである。さらに、システムのライフサイクルが長いのも、HP-UX/Integrity サーバーの大きな特長だ。現行バージョンの「HP-

UX 11i v3」が登場したのは 2007 年 4 月のこと。一つ前のメジャーバージョン「HP-UX 11i v2」は 2004 年のリリー

スで、継続的にメジャーバージョンアップが行われていることになる。これだけライフサイクルが長いのは、HPE に

よると、製品に対するテストを十分に繰り返していることが理由だという。最低 10 年間のサポートを提供するというのも、システム全体の安定性向上に一役買っている。長期間に渡る運用計

画を事前に把握できるだけでなく、ハードウェアのみを最新機種に更改して、同じサービスを提供し続けることが可

能になる。これにより、マイグレーションのインパクトを出来る限り抑えられるとともに、長期的な観点に立ってみ

ると、Linux/x86 サーバーよりも総コストを圧縮できる可能性もある。なお、コスト比較に関しては、米国の第三者

（調査会社）による興味深いレポートが発表されている。その内容については、次の記事で詳しく紹介するので、

“乞うご期待”である。ちなみに HP-UX ではオペレーティングシステムのバージョン間、ハードウェアプラットフォーム間、仮想マシンお

27


よびチップアーキテクチャ間における各種のレベルにおいて互換性が保証されており、開発したアプリケーションは

Integrity サーバーでは基本的にバイナリ互換で動作する（互換性に関するホワイトペーパーはこちら）。たとえば、

Integrity サーバーが初めて登場して以来、現在までに 7 世代のインテル® Itanium® プロセッサーがリリースされてい

るが、アプリケーションのバイナリ上位互換性は一貫して提供されている。

HP-UX バージョンリリース ID リリース日販売完了

(Discontinuance)

サポート終了

(End of Support)

HP-UX 11.00

(HP9000 only) 11.0 Nov 1997 Mar 2004 Dec 2006

HP-UX 11i v1

(HP9000 only) B.11.11 Dec 2000 Dec 2009 Dec 2013

HP-UX 11i v2

(Integrity & HP9000) B.11.23

Oct 2003

(Oct 2004 for HP9000) Dec 2010 Dec 2013

HP-UX 11i v3

(Integrity & HP9000) B.11.31

Apr 2007

(Feb 2007 for WW) Dec 2014 Dec 2020

・販売完了は、最短でもそれが示す時点までは販売完了の予定は無いことを示します。

・サポート完了についても、最短でも “End of Support” で示す時点までは継続することを示します。

・各 OS バージョンのサポートは、稼動するサーバー本体のサポート終了を超えては継続いたしません。

表 1：HP-UX リリース・ライフサイクル

クラウド時代の新しいプラットフォームへ進化した新世代 Integrity サーバー

ミッションクリティカル・システムのプラットフォームとして、HP-UX と Linux のどちらが相応しいかというテーマで始まった

本連載では、これまで HP-UX のハードウェアプラットフォームである「Integrity サーバー」については詳しく触れてこなかっ

た。しかし、安定性を語る上では、Integrity サーバーの話題を避けて通ることはできない。ここで、現行の Integrity サーバーのラ

インアップや位置付けを紹介しよう。

最新の Integrity サーバーを、HPE では「第 2 世代」と呼んでいる。これまで Itanium プロセッサーが大きく変化しても、新世代の

製品として明確にしたことはなかった。それだけ大幅なアーキテクチャの見直しが、2010 年に行われたのだ。

第 2 世代 Integrity サーバーには、3 つの製品ラインアップがある。ミッションクリティカルクラウド基盤を支えるハイエンドサー

バー「Integrity Superdome 2」、管理性に優れたミッションクリティカルブレードサーバー「Integrity BL シリーズ」、そして中

小規模システムでも利用可能な高密度・省スペースのラックマウントサーバー「Integrity rx2800 i2」だ。

中でも、HP-UX/Integrity サーバーのフラッグシップというべき存在なのが、Superdome 2 である。前世代の Superdome は、メイ

ンフレームを凌駕する機能・性能を誇る基幹サーバーとして 1995 年に開発を着手、2000 年に製品化されたものだった。当初は

「HP 9000 サーバー」のラインアップとして登場したが、Integrity サーバーという新しいサーバーラインアップが登場してからも

アーキテクチャが変更されることはなかったが、2010 年 4 月、実に 10 年ぶりにアーキテクチャが刷新された。

http://h50146.www5.hpe.com/products/software/oe/hpux/developer/document/migration.html

28


Superdome 2 は、従来の Superdome 同様にセルボードによるモジュール型の設計になっている。ただし、Superdome 2 では従来

のセルボードというよりも、サーバーブレードそのものである。新たに開発された HP クロスバーファブリックによって、プロセ

ッサーと I/O を独立させるとともに、4 コアの Itanium 9300 番台を 2 基内蔵するブレードをエンクロージャあたり 8 枚搭載し、4

台のエンクロージャを結合して 64 プロセッサー/256 コアという強力なスペックのサーバーにスケールアップできる拡張性を持っ

ている。

図 3： Superdome と Superdome 2 のアーキテクチャの違い

MTBF（平均故障間隔）1000 年以上を設計目標とし、バックプレーンの改良、徹底したモジュール型設計による実装方法の改善

などが行われ、可用性の大幅な向上を実現。それでいて、本体を 19 インチラックと同サイズに合わせて従来比 3 分の 1 の設置

面積になり、消費電力も最大 65 パーセント削減されている。

ミッドレンジクラスのミッションクリティカル・システムに最適な Integrity BL シリーズは、HP の第 3 世代ブレードサーバー

「BladeSystem C-Class」のテクノロジーを継承している。x86 ブレードサーバー「ProLiant BL シリーズ」と共通のエンクロ

ージャが採用されているので、投資保護や管理性の面でも優位性がある。とはいえ、その機能・性能は x86 サーバーとは一線を

画している。2 枚/4 枚のブレードを SMP 構成にできるスケールアップによる拡張性を備えるほか、前項で紹介したさまざまな高

可用性機能を内蔵するなど、ミッションクリティカル・システムでの実用に耐える設計になっている。

適材適所が最も賢い選択肢

今回は、ミッションクリティカル・システムに求められる「安定性」の面から HP-UX/Integrity サーバーの機能を見てきた。し

かし、この分野に関しては、設計思想の違いから Linux/x86 サーバーに搭載されていない機能が多く、比較することも困難だっ

た。

だからといって、Linux/x86 サーバーの存在を否定するつもりは毛頭ない。オープンソースである Linux カーネルと、コモディ

ティ化が進んだ x86 サーバーを組み合わせると、コストパフォーマンスに優れたシステムになるのが誰もが認めるところだ。

Web サーバーなどのフロントシステムには、Linux/x86 サーバー以外の選択肢はないと言えるくらいだ。

だが、高信頼性・高可用性で安定稼働が求められるミッションクリティカルなバックシステムには、HP-UX/Integrity サーバー

のほうが有利なのは明白である。つまり、適材適所で Linux/x86 サーバーと HP-UX/Integrity サーバーを使い分けることが、

最も賢い選択肢と言えるだろう。

次回はいよいよ、Linux/x86 サーバーの最大のメリットと言われる「コスト」を比較してみたい。

29


最終回

“Linux ⁄ x86 サーバーはコスト高”という衝撃の調査結果


半年に渡り、ミッションクリティカルシステムにおける Linux⁄x86 サーバーと HP-UX⁄Integrity サーバーをさまざまな角度から

比較・検証してきた本連載も、今回をもって最終回を迎える。信頼性、堅牢性、安定性、さらにはサポート体制などにより、HP-

UX⁄Integrity サーバーの優位性を見てきたが、実際に導入するには「コスト」という壁がある。オープンソースの Linux、コモ

ディティ化された x86 サーバーの導入コストの安さは、語るべくもない。ところが、米国調査会社が発表したレポートによる

と、トータルコストを比較した場合、むしろ“Linux⁄x86 サーバーはコスト高”だという。今回は、その衝撃的なレポートを読み解

いてみたい。

HP-UX⁄Integrity サーバーがお得？3 年間の TCO 削減効果に差が

“エンタープライズ Linux”という言葉がメディアに取り上げられはじめて、今年で丸 10 年が経過した。この間、Linux はバージ

ョンアップを重ねるごとに着実に進化を遂げ、企業システムを支える重要なプラットフォームの一角を占めるまでに成長した。

Linux の主要な稼働基盤となる x86 サーバーも 64 ビット化・マルチコア化が進むとともに、仮想化を実現するハイパーバイザ

ーをハードウェアベースでサポートしたり、RAS（Reliability - Availability - Serviceability）機能が実装されたりといったよ

うに、企業のエンタープライズシステムに十分対応できるほどの実力を身に着けている。

ミッションクリティカルシステムにおける採用例も増え、現在は金融業界の勘定系基幹システム、あるいは社会インフラを支える

制御システムといった分野においても、Linux⁄x86 サーバーが導入されるケースが出始めている。メディアが Linux⁄x86 サーバ

ーを礼賛するのも無理はない。

高い可用性、信頼性、拡張性、性能が要求される分野でも十分に使用に耐え得る Linux⁄x86 サーバーの最大の特徴・メリット

は、コストパフォーマンスが極めて優位である点というのが常識だ。事実、オープンソースソフトウェアの Linux は、基本的に

OS を無償で使うことができる。x86 サーバーも、コモディティ化されたパーツが採用されたことで低価格化が猛烈に進んだ。

OS もハードウェアも、導入費用は極めて低廉。これは、否定しようがない事実である。

ところが 2010 年 8 月、米国の調査会社・Alinean 社から驚くべき結果のレポートが発表された。安価なはずの Linux⁄x86 サー

バーではなく、HP-UX⁄Integrity サーバーを選択したほうが TCO の削減と ROI の向上に貢献するというのだ。Alinean 社によ

ると、3 年間の TCO を比較してみると、Linux⁄x86 サーバーよりも HP-UX⁄Integrity サーバーのほうが約 20％も有利であり、

結論として「HP を選択すると、IT 運用と管理面の生産性の向上、変更費用の削減、可用性の向上により費用が削減される。適応

力を向上させることによって、さらなるビジネス効果が得られる」という分析している。2010 年 8 月かつ US の価格とはいえ、

TCO の削減という指標としては日本においても十分参考になるだろう。

今回は、この第三者機関が発表したレポートの内容について、サマリーを紹介する。

30




富樫先生

ハードウェアを除くコストパフォーマンスに優れた HP-UX⁄Integrity サーバー

Alinean 社のレポートには、冒頭に調査概要が事細かく語られている。Linux⁄x86 サーバーと HP-UX⁄Integrity サーバーのコス

ト効果は、単純な IT コスト（ハードウェア購入費用、ソフトウェアライセンス費用、保守契約費用）によって比較が行われてい

るのではなく、企業にとってどれだけの経済効果があるのか、TCO (Total Cost of Ownership＝総保有コスト）で計算されたこ

とが力説されている。

Alinean 社の TCO 分析手法は、米国の 30 業種以上・2 万社以上の IT 関連支出と TCO ベンチマークを調査して基本となるデー

タと評価基準をまとめ、これをベースに開発された標準モデルを使用するというものだ。いわゆる“手間”となる人件費も、米国の

特定地域における賃金負担率を米ドルに換算して計算されている。ハードウェアやソフトウェアの費用は、Alinean 社が HP と競

合他社の Web サイトに公開されている表示価格を収集したものだという。

TCO の比較に用いられた項目は多岐にわたる。サーバーやストレージ、ネットワーク機器などのハードウェア、OS やミドルウェ

ア、アプリケーションなどのソフトウェアはもちろん、IT の運用管理業務にかかる人件費、IT の調達や資産管理、トレーニング

などにかかる人件費、データセンターの設置面積や消費電力、空調にかかる費用などに加え、可用性や事業利益に関しても金額換

算が行われている。

実際の比較で用いられたのは、72 コアの「SUN Fire 15K Ultra SPARC III」が 2 台、24 コアの「SUN Fire 6800 Ultra

SPARC III」が 14 台で本稼働、テスト、開発の環境で使用しているシステムを、Linux⁄x86 サーバーおよび HP-UX⁄Integrity サ

ーバーにマイグレーションするというケースシナリオ。移行先となるハードウェアは、以下のとおりだ。

まず、Linux⁄x86 サーバーは、4 コアの 1U ラックマウントサーバー10 台、16 コアの 4U ラックマウントサーバー4 台。1U サ

ーバーには Xeon 3.06GHz、4U サーバーには Xeon 2.26GHz が搭載されており、コア総数は 104、OS は「Red Hat

Enterprise Linux 5」が稼働する。いずれも HP 以外の他社製品だ。一方の HP-UX⁄Integrity サーバーは、16 コアの

「Integrity BL870c i2」が 2 台、8 コアの「Integrity BL860c i2」が 5 台、16 コアの「Integrity Superdome 2」が 2 台。

プロセッサーはいずれも Itanium 9340 1.6GHz でコア総数は 104、OS は「HP-UX 11i v3」が稼働する。

ハードウェア費用

ハードウェア費用を単純に比較すると、x86 サーバーが 197,535 ドル、Integrity サーバーが 490,412 ドルと、HP-

UX⁄Integrity サーバーが 2 倍以上も高額だ。HP-UX⁄Integrity サーバーの場合、支払猶予となる iCAP の費用（3 年間分）があ

るものの、それでも 292,877 ドルも差がある。

単純なコスト比較だけでは見えてこない TCO 削減効果を知る

1. 導入後の運用費用も考慮し、ライフサイクル全体でコストを考えよ

う！

2. HP-UX の管理機能が IT の生産性向上に役立つことを認識しよう！

3. コスト削減だけにとどまらないビジネス効果があることも理解しよ

う！

31


図 1：ハードウェア費用の比較

ソフトウェア費用

ところが、ソフトウェアの費用は、HP-UX⁄Integrity サーバーのほうが圧倒的に有利だという。これは、HP-UX 11i が備えるコ

ンソリデーション、パーティショニング、ワークロード管理機能により、必要となるプロセッサライセンスが少なくて済むためと

いうのが、Alinean 社の見方である。ケースシナリオでは、Oracle Database Enterprise Edition にかかるライセンス総費用が

705,000 ドルも違っている。 OS にかかる費用は、Linux が無償（ゼロ）、HP-UX が 279,240 ドルと HP-UX が圧倒的に高額

だが、HP-UX にはシステム管理、ディザスタリカバリ、仮想化ソフトウェアがすべて含まれており、追加ライセンスは不要。こ

れらをすべて計算すると、HP-UX⁄Integrity サーバーが 3 年間で 556,515 ドル、約 30％も低コストになるそうだ。

図 2：ソフトウェア費用の比較

同様の傾向は、サポートとメンテナンスにかかる費用にも表れている。とりわけ、ソフトウェアサポート費用に大きな差が生じて

いるが、ケースシナリオのワークロードを処理するには、Linux⁄x86 サーバーは HP-UX⁄Integrity サーバーよりも多くのプロセ

ッサコアとライセンスが必要になるというのが理由だ。また、Linux はオープンソースであるものの、年間のサポートとメンテナ

ンス費用は、HP-UX 11i よりもコスト高なのだという。

32


安定性に差が出る HP-UX⁄Integrity サーバーの設計思想

レポートでは、ハードウェアやソフトウェア、サポートなど、実際のコストが金額として見える部分だけでなく、企業のコスト負

担をトータルに比較している。とりわけ、IT の運用管理業務、IT の調達や資産管理、トレーニングなどにかかる人件費などから

IT に関する労務費に関しては、詳しい分析に基づく比較が行われた。

ソフトウェア費用

その結果、Linux⁄x86 サーバーは、HP-UX⁄Integrity サーバーに比べて多くのサーバーが必要になるため、必要な人員と人件費が

高くなる。また、HP-UX が装備する各種管理ツールセットが、一人の管理者が担当できるサーバー台数増加に役立っていると分

析する。

Alinean 社では、複数のプラットフォーム、ストレージ、仮想化、OS を単一コンソールから管理できる「Systems Insight

Manager（SIM）」、包括的で操作性に優れた仮想化管理ソフトウェア「Insight Dynamics - VSE」、ビジネスニーズに合わせ

たリソースの自動調整機能により、システムの運用、構成を制御する「Process Resource Manager（PRM）」「HP-UX

Workload Manager（WLM）」などのツールを挙げ、これらの機能を使用して、アプリケーション、ワークロード、使用率、

キャパシティプランニング、性能、可用性を一元管理することで、管理作業が簡素化され、コストも削減されるとしている。

これらにより、HP-UX⁄Integrity サーバーには、IT の生産性の向上における優位性が明らかに存在し、優れたコンソリデーショ

ンと管理すべきサーバーの数が少ないことにより、Linux⁄x86 サーバーに比べて、IT 管理で 26％、IT 運用で 14％の生産性向上

につながるという。

図 3: IT 管理/IT 運用費用の比較

電力、空調、設置費用

データセンターなどの施設に関する比較では、Linux⁄x86 サーバーが優勢だ。ケースシナリオの場合、9 台の HP-UX⁄Integrity サー

バーと同等の性能を得るには、14 台の Linux⁄x86 サーバーが必要になるものの、HP-UX⁄Integrity サーバーの消費電力量、占有空間

のほうが 34％も多くなる。この構成で予測されるワークロードを処理した場合、3 年間の電力、空調、設置費用を計算すると、

HP-UX⁄Integrity サーバーは Linux⁄x86 サーバーよりも年間 6,169 ドルも多く必要になる。

33


図 4：電力、空調、設置費用の比較

マイグレーション費用

マイグレーション作業については、HP が提供するサポートサービスによって初期の労務費が削減されるほか、アプリケーション

移植ツールによりアプリケーションの移植やリコンパイルの作業負荷を大幅に軽減できるという。一方で、Linux⁄x86 サーバーで

は、より多くの資産に対してセットアップおよび構成を行う必要があり、より多くの変更費用がかかるという。Alinean 社では、

初期労務費、サービス、テスト費用で HP-UX⁄Integrity サーバーならば 60,007 ドル節約できるとしている。

図 5： : 移行作業費用の比較

エンドユーザーの生産性、およびビジネスへの影響についても言及されている。可用性と想定される計画外のダウンタイム時間を

計算すると、HP-UX⁄Integrityサーバーを導入することではエンドユーザーの生産性への影響は 38,163 ドル、ビジネスへの影響は

18,852 ドルも軽減できる。セキュリティパッチ、ソフトウェアモジュールのアップデートなどに伴う計画停止についても、HP-

UX⁄Integrity サーバーが 81,414 ドルであるのに対し、Linux⁄x86 サーバーは 223,395 ドルにも及ぶ。

34


図 6：生産性/ビジネスへの影響の比較

クラウド時代の新しいプラットフォームへ進化した新世代 Integrity サーバー

Alinean 社によれば、HP-UX⁄Integrity サーバーには以下のようなメリットがあり、それらが非常に効果的に働いているという。

まず、アプリケーションとデータベース費用の削減効果だ。Oracle Database に関しては、HP-UX⁄Integrity サーバーで必要なプロ

セッサー数は、Linux⁄x86 サーバーに比べて少なくなる。このため、プロセッサーベースのライセンス費用を大幅に削減できる。

また、ハードウェア⁄ソフトウェアのサポートとメンテナンスの差も、大きなメリットになっている。サポートとメンテナンスの

総費用は 14％以上も削減され、HP-UX⁄Integrity サーバーのハードウェアに関するコスト高が相殺されるという。マイグレーショ

ンや IT の業務、運用管理にかかるコストの削減は、前項で紹介したとおりだ。

ビジネスアジリティ/ソリューション導入期間

これらに加え、ビジネスアジリティ（俊敏性）とソリューション導入期間（迅速性・即応性）などにより、企業のビジネス戦略に

関する費用は、HP-UX⁄Integrity サーバーが 32％も優位だという。短期間のうちにリプレースすることを前提とした Linux⁄x86 サー

バーに比べ、HP-UX⁄Integrityサーバーは将来の変化に対しても投資が保護されることも、メリットの一つとして挙げている。

図 7：ビジネスアジリティ/ソリューション導入期間の金額換算比較

35


IT 業界において、Linux は UNIX よりも安価というのが一般的な常識だ。これは、サーバーハードウェア、OS、それぞれのメン

テナンス費用については正解だ。しかし、企業にどれだけのコストメリットをもたらすのか、詳細な分析結果に基づくコスト比較

が重要だ。

3 年間の TCO は 21％削減

Alinean 社は、3 年間の費用について分析すると、今回のケースシナリオでは HP-UX⁄Integrity サーバーが Linux⁄x86 サーバー

よりも TCO を 21％削減できるという結論が導き出されたとしてレポートを締めている。もちろん、第三者機関のレポートでは

あるものの、さまざまな見方、意見はあるだろうし、米国と日本では事情も違う。あくまでも本記事がレポートの信用性を担保し

ているわけではないことだけは、最後にお断りしておきたい。

図 8： 3 年間の TCO 比較

※当レポートは Alinean 社が 2010 年 8 月に纏めたものであり、現在の状況とは一部異なっている可能性があります。

36


HP-UX

www.hpe.com/jp/hpux

© Copyright 2018 Hewlett Packard Enterprise Development LP.

本書の内容は、将来予告なく変更されることがあります。日本ヒューレット・パッカード製品およびサービスに対

する保証については、当該製品およびサービスの保証規定書に記載されています。本書のいかなる内容も、新たな

保証を追加するものではありません。日本ヒューレット・パッカードは、本書中の技術的あるいは校正上の誤り、

脱字に対して、責任を負いかねますのでご了承ください。

連載を振り返って

半年に渡って連載を続けてきた本特集記事も、今回で終了となる。ミッションクリティカルシステム分野においても台頭著しい

Linux⁄x86 サーバーだが、実際に導入して運用する場合は、システム構築においても運用管理においても、かなりの高度なスキル

が要求されることは間違いない。もちろん、ベンダーにお任せすることも可能だが、日々の保守・運用にかかるコスト、頻繁に訪

れるハードウェアの更改時期のたびに発生するコストを考えると、決して安い買い物でないことは分かるはずだ。これでは、無料

で使えるオープンソース OS とコモディティ化が進んだ低価格なハードウェアを導入する「旨味」を享受することはできない。

世の中では、ベンダーにロックインしてしまう UNIX システムは、これからの時代にそぐわないという意見が大勢を占めてい

る。それを裏付けるようにシェアの漸減が続いているのは事実だ。しかし、ミッションクリティカルシステムは信頼性が第一であ

る。信頼性の高さに依然として差がある現時点において、最新の Linux⁄x86 サーバーへ移行するという選択肢が必ずしも最適解

でないことは明らかである。

こうしている間に、時代はすでにハードウェアや OS などのシステムインフラを意識しない、仮想化やクラウドコンピューティン

グへと進みつつある。ミッションクリティカルシステムにおいても、企業にとってノンコアなシステムはクラウドに移行するとい

う例も増えている。Linux⁄x86 サーバーか、それとも HP-UX⁄Integrity サーバーかというプラットフォームを選択する議論は当

分続くかもしれない。だが、Linux⁄x86 サーバーが HP-UX⁄Integrity サーバーを信頼性、コストの両面において凌駕する実力を

身に着けるよりも早く、クラウドかオンプレミスかを選ぶ時代になるだろうというのが、筆者個人の率直な見方である。

http://www.hpe.com/jp/hpux

Documents

Linux かHP-UX、 あなたはどっち？...Linux かHP-UX、 あなたはどっち？ ～潜むリスクを完全比較、適材適所の OS 選択 ～ 適材適所、適宜適量

Linux かHP-UX、あなたはどっち？...Linux かHP-UX、あなたはどっち？～潜むリスクを完全比較、適材適所の OS 選択～適材適所、適宜適量