Skip to content

翻訳記事：

  • RED HAT Magazineは、米国発の記事を翻訳したものです。

RED HAT SPEAKS

Red Hat Networkの展開：システム管理者の生産性向上

執筆者: David Kirlin

原文(英語)

問題



我々は典型的なIT問題に見舞われました。より多くのことを、より少ないリソースで行う方法を見つける必要に迫られたのです。我々は従来4人のシステム管理者で35台のサーバを運用していました。サーバは安定しており、アプリケーションは申し分なく動作していました。ところが、ITの世界でよくあるように、やがて事情が変わりました。プロジェクトの数が増加したため、サーバの台数を増やし、新しいサービス要求に対応することが必要になりました。しかし、リソースは以前より減っていました。システム管理者はわれわれ2人だけになっていたのです。ITマネージャ兼システム管理者として、私は2人だけで管理できるような新しいテクノロジプラットフォームを見つける担当者でした。我々の以前のテクノロジソリューションは完璧ではありませんでしたが、優れたものでした。それでも、さらに優れたものが必要だったのです。我々はシステム管理者を追加する余裕がなくなっていました。そのため、管理業務の自動化を拡大できるようなソリューションを見つける必要がありました。また、そのソリューションは、スケーラビリティと安定性を備え、我々のソフトウェア（大部分がSun ONE）のサポート対象プラットフォームである必要がありました。これらすべての問題の前提として、あらゆるIT問題の最終課題、ダウンタイムが最小限に保たれる必要がありました。
(プロジェクトの数が増加したため、サーバの台数を増やし、新しいサービス要求に対応することが必要になりました。しかし、それを前より少ないリソースで行わなければなりませんでした。)

私は西イリノイ大学に付属するApplication of Information Technologies（CAIT）センターに勤務していました。CAITは、教育機関、企業、公共機関、および非営利組織向けに、オンライン学習システムとアプリケーションの開発、展開、およびサポートを行っています。これらの学習システムは、全世界のユーザをサポートしています。それには、週7日24時間、我々のシステムを稼働状態に保つことが必要であり、アップタイムをできるかぎりファイブナイン（99.999%）に近づける必要があります。ユーザは業務の維持と情報セキュリティの確保を我々に依存しています。

ソリューションを見つけるため、我々はまず、管理業務のどの側面に最も時間がかかっているかを検討しました。当時の我々のテクノロジは、異なるサーバが混在した構成でした。我々の当初の計画では、Sun Solaris UNIX 8および9とDebian Linuxからなる異機種環境を使用することになっておりました。コアアプリケーションサーバは、すべてSolarisでした。それらは、Sun ONE Web Server、Sun ONE Directory Server、またはMySQLのいずれかを実行していました。これらのサーバを補完し、コストを節約するため、Debian Linuxサーバを設置していました。これらのサーバは、主に電子メール、ヘルプデスクチケットソフトウェア、リストサーブ、ストレージシステムといった支援アプリケーションを実行していました。我々の方法論を検討していくと、パッケージ管理とセキュリティ修正に最も多くの時間を費やしていることがわかりました。また、SolarisサーバはDebian Linuxサーバに比べて複雑な場合が多いため、その設定やトラブルシューティングにも、ある程度の時間がかかっていました。

サーバを最新状態に保つための作業に何時間もかかっていました。毎週、Solarisサーバから出されるセキュリティやパッチの電子メールを読み、該当するものがないかどうかを確認するために時間を費やしていました。何か見つかった場合は、その重大性、およびパッチの適用やアップグレードの緊急性の程度を判断しました。システムがダウンすると、必要な場合はただちにサーバにパッチを適用し、リブートしました。しかし、その方法論は中央集中型ではなかったため、問題のある個々のサーバのところへ行き、1台ずつアップグレードやパッチの適用を行う必要がありました。我々は時間を節約するため、中央にあるNFSマウント上のパッチをマウントすることにより、それを個々のサーバにコピーしなくてもいいようにしました。Debianサーバのパッチ管理は、より簡単でした。Debianサーバでも毎週セキュリティやパッチの情報を読むために何時間も費やし、パッチを適用するには個々のサーバにログインする必要がありましたが、アップグレードやパッチの適用では、事前にダウンロードを行う必要はありませんでした。apt-get dist-upgradeを実行するだけで、必要なアップグレードと修正がすべて自動的にダウンロードされ、インストールされました。これにより、Solarisサーバに比べて時間がかなり節約されました。しかし、それでも1つ1つのサーバのところへ行く時間が無駄になっていました。中央集中型のパッケージ管理システムがなかったのです。我々は、cfengineの使用などの代替ソリューションを調査しました。cfengineは、一度に複数のシステムにコマンドを実行または適用できるオープンソースソフトウェアです。したがって、理論的には、必要に応じてパッチを一度にすべてのシステムに適用できます。しかし、セットアップに時間がかかり、サーバに追加してインストールする必要があるサードパーティ製ソフトウェアです。すべての問題を満たすと同時に、オペレーティングシステムに対してアドオンではなくその一部として統合されるパッケージ管理を使用するような、より包括的なソリューションが必要でした。

ソリューション



我々の問題に必要なソリューションは、結局、身近なところにありました。ITの問題を引き起こした変化が起きる数カ月前に、我々はシステム管理者の会合で、さまざまなタイプのUNIXとLinuxについて長所と短所を議論していました。この議論のなかで、システム管理者の1人が、一部のサービスをRed Hat Enterprise Linuxに切り替えることを主張しました。彼は、Red Hat Enterprise LinuxとRed Hat Network（RHN）のさまざまな利点を指摘しました。当時、私はRed Hatに対しては賛成でも反対でもありませんでした。Red Hatには長所と短所がありましたが、RHNとあわせて使用したことはなかったのです。Red Hatについては、主にFedoraに関与した経験がありました。我々は数台の新しいサーバを発注し、Red Hat Enterprise Linuxをインストールすることで合意しました。それから一部のサービスを移行し、それ以上の展開を行うかどうかを評価することになりました。インストールしたあと、私は初めてRHNにログインし、感銘を受けました。我々の2台のサーバがステータス報告とともに一覧表示されていました。それらは、青色のチェック記号によって最新状態であることが明示されていました。一番感心したのは、システムパッケージを一覧し、インストールされているものとされていないものを確認できることでした。そして、サーバが必要とするパッケージやアップデートを送信できました。これらのイベントの実行は、必要に応じてスケジューリングすることもできました。システム管理者が2人になったときには、RHNを最初に評価してからかなり時間が経っていました。
(問題のソリューションを探す必要に迫られたとき、我々はRed Hat Enterprise Linuxサーバに戻りました。)

問題へのソリューションを探さなければならなくなったとき、我々はRed Hat Enterprise Linuxサーバに戻りました。Red Hat NetworkとRed Hat Enterprise Linuxを組み合わせて使用することで、パッケージやアップデートを管理し、ワンクリックで一度に複数のサーバへ展開することができました。さらに、それらのアップグレードやパッチをダウンタイムまたは好都合な時間帯にスケジューリングできました。また、関係のあるアップデートやパッチが利用可能になると、RHNから電子メールが届きました。サーバをすべて移行すれば、サーバ管理において莫大な時間が節約されます。可能なセキュリティ修正の調査は続けますが、セキュリティ修正とパッチが利用可能であることが通知されるのは、きわめて有益です。また、Debianと同様、Red Hatは設定と管理が非常に容易であることが大きな利点でした。Red Hatのグラフィカルツールによって、いくつかの管理業務がさらに容易になりました。とりわけ、Red Hat Enterprise Linuxは、我々が使用しているSolarisソフトウェアのサポート対象プラットフォームです。私は最初の展開のために20ライセンスを発注しました。これが我々のソリューションでした。

ライセンス購入を確認する最初の電子メールを受け取ったときは、非常に興奮しました。旧式のMySQLサーバのリプレースが最初の仕事でした。新しいサーバが100%稼働するまで従来のサーバをシャットダウンしなくて済むように、アップグレード用にはすべて新品のサーバを発注しました。インストールは円滑に進み、インストール後のアップデートもまったく問題がありませんでした。次のステップはMySQLのインストールと設定でしたが、これは主任技術者の1人が処理しました。ここでも、MySQLのセットアップとクエリーへの応答について問題はありませんでした。翌年1年を通じて、段階的にサーバを新しいテクノロジソリューションに移行していきました。

結果



現在、RHNとRed Hat Enterprise Linuxは、我々の管理戦略の主要部分になっています。朝RHNから電子メールを受け取ることで、サーバのステータスがわかります。それによって、どのサーバにセキュリティパッチまたはアップグレードが必要か、およびサーバがRHNに連絡しているかどうかが示されます。その情報を検討したあと、我々の1人がRHNにログインし、リストを再検討します。さらに、すべてのサーバを含むサーバグループを利用して、すべての問題をワンクリックで修正します。問題に応じて、アップグレードの実行を業務時間外にスケジューリングする場合もあります。また、我々の1人が出張時や自宅にいるときもRHNを利用します。それによって、我々は遠隔地からでもパッチを点検し、その状態を把握できます。
RHNとRed Hat Enterprise Linuxによって時間が節約されたため、以前は4人で管理していた同じ数のサーバを、2人だけで十分効果的に管理、運用できるようになりました。

20ライセンスをほぼすべて展開しても、問題はほとんど発生していません。サーバは円滑に動作し、アプリケーションは問題なく実行されています。ソフトウェア変更とハードウェア変更の両方を、以前よりすばやく実行しています。RHNとRed Hat Enterprise Linuxによって時間が節約されたため、以前は4人で管理していた同じ数のサーバを、2人だけで十分効果的に管理、運用できるようになりました。

20ライセンスをほぼすべて展開しても、問題はほとんど発生していません。サーバは円滑に動作し、アプリケーションは問題なく実行されています。ソフトウェア変更とハードウェア変更の両方を、以前よりすばやく実行しています。RHNとRed Hat Enterprise Linuxによって時間が節約されたため、以前は4人で管理していた同じ数のサーバを、2人だけで十分効果的に管理、運用できるようになりました。

執筆者について

David Kirlinは、Center for the Application of Information TechnologiesのITマネージャです。彼はLinuxで11年を超える経験を持ち、インテリジェントソリューションの支持者です。余暇には、執筆やさまざまな活動に参加しています。