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

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

≫ HP-UX 11i
Knowledge-on-Demand

≫コラム

≫連載
≫特集、特別企画

ドキュメント/ツール

HPラボ

≫Webキャスト

関連情報

≫HP-UX
- ≫各種ソフトウェア

≫日本HPサイトマップ

ミッションクリティカル・システムでは、何を優先してプラットフォームを選べば良いのだろうか。処理能力の高さ、機能の豊富さ、拡張性の高さなど、業務アプリケーションの内容や用途によって優先すべき選択ポイントは異なってくるが、実際にシステムを運用管理する情報システム部門の担当者にとっては、プラットフォームの安定性とメンテナンス性に優れていることが何よりも重要なポイントになってくる。第5回目の今回は、OSの安定性とメンテナンス性の観点から、Linux/x86サーバーとHP-UX/Integrityサーバーの違いを見てみよう。

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

≫	高い安定性を裏付けるHP-UX/Integrityサーバーの真の実力とは？
≫	パッチ適用時のサービス停止時間を最小化するHP-UX/Integrityサーバー
	≫ Twitterでつぶやく

2011年1月
大神企画富樫純一

ページ： 1 2 | 次へ ≫

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

ミッションクリティカル・システムのプラットフォームは、「安定性」に優れていることがとりわけ重要だ。しかし、「安定性」というのは、実に抽象的な言い回しでもある。サービスをいかに停止させずに稼働し続けるかという可用性の高さを“安定している”ということもあるし、ソフトウェアのエラーも含めて障害の発生頻度が少ないことを“安定している”ということもある。さらには、すでに実績のある、いわゆる“枯れた”技術を使うことが“安定している”につながるという考え方もある。

このように「安定性」という言葉の意味に正解はないが、運用管理を担当する情報システム部門に負荷がかからない、手間いらずのプラットフォームであることが「安定性」が高いミッションクリティカル・システムとは言えるだろう。

では、運用管理担当者の負担がかからないプラットフォームとは何か。まず思い浮かぶのは、本連載第1回の記事でも述べたように、障害発生を未然に防ぐ、事前に対策する高可用性を実現する機能を持ち合わせているかどうかということがある。ただし、それだけではない。システムダウンが発生するのは、障害発生時ばかりではないからだ。

システムダウンが最も多く発生するのは、OSを含むソフトウェアの不具合を修正したり、セキュリティパッチを適用したりするアップデートを実施する際の計画停止である。だから、アップデートにかかる時間の長いか短いか、アップデートモジュールがテスト済みかどうか、アップデートをベンダーが保証・サポートしているかどうかといったこと ―― すなわち「メンテナンス性」の高さは、「安定性」を語る上で極めて重要になるのである。

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

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


	安定稼働を実現する「メンテナンス性」の重要性を知る 1. サービス停止時間を最小化する技術を理解しよう！ 2. サーバーとOSの設計思想の違いを再確認しよう！ 3. 第2世代Integrityサーバーの最新機能を理解しよう！

OSのことならお任せ！
富樫先生

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

ミッションクリティカル・システムでは、業務継続性の観点からダウンタイムを出来る限り短くすることが求められる。これは、障害発生時はもちろんのこと、OSを含むソフトウェアの修正モジュールやセキュリティパッチを適用するときの計画停止も同じだ。

Linux/x86サーバーを利用した一般的なシステム運用の場合、パッチ適用時はサービスを停止して事前バックアップを実施し、その後パッチを適用する作業を行って、事後バックアップを行うという手順を踏む。これら一連のパッチ適用にかかる平均的なサービス停止時間は、HPの調べによると約3時間程度にもなるという。

実は、HP-UX/Integrityサーバーでも同じ手順を踏めば、Linux/x86サーバーと同じだけのサービス停止時間が必要になる。そのサービス停止時間を最小化するために、HP-UXには「Dynamic Root Disk（DRD）」が用意されている。

DRDは、現用OS環境の稼働中にOSのイメージを複製・バックアップする。そして、複製されたOS環境にパッチを適用する。パッチ適用が完了したら、パッチ適用済みのOS環境に切り替えるために再起動する。OSの再起動中はどうしてもサービスが停止するが、その時間は数分から最大でも約10分程度だ。再起動時には複製OS環境が起動されることになる。

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

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

Linux/x86サーバーの場合、パッチ適用前に戻すには、事前に取得したバックアップからリストアするか、ロールバック機能を利用するか、どちらかの方法をとることになる。しかし、HP-UX/Integrityサーバーでは、これらの方式に加えて、DRDを利用することができる。バックアップをリストアする時間も、ロールバック機能でパッチ適用前に戻す時間も必要がない。

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

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

x86サーバーで稼働するLinuxやWindowsなどのOSでは、緊急性の高いセキュリティパッチなどが不定期に配布される。これらを適用するには、稼働中のシステムに影響があるかどうかテストを実施する必要があるが、その責任所在は基本的にパッチを適用しなければならないユーザー側に委ねられている。

しかし、HP-UX/Integrityサーバーの場合は、メーカーのHP自身がテストを行い、認定されたものだけがパッチとして提供される。つまり、お墨付きが得られたものだけなので、安心して適用することが可能だ。しかも、パッチは「標準HP-UXパッチバンドル」という形で定期的にまとめて提供される。システムに不要な修正モジュールなどは必ずしも適用する必要がないので、「パッチ管理」という意味では運用管理担当者の負担は軽減されることになる。

ページ： 1 | 2

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

≫このページのトップへ戻る

	Twitterでつぶやく「LinuxかHP-UX、あなたはどっち？」～適材適所のOS選択、ミッションクリティカル・システムに最適なプラットフォームは？～