使える!サーバ運用の実践テクニック

第2回 150台が13台に? -旧型から新型マシンへのリプレース!

この記事を読むのに必要な時間:およそ 3 分

構成の決定まで[Webサーバ編]

現行のシステム構成が以下となっていることを前提とします。

  • Red Hat Linux3.x(32ビット)
  • Apache 1.3 100プロセス
  • Tomcat 5.0 200スレッド/1コンテナ

上記の設定のマシンが100台あった場合,プロセス的には10,000の同時処理を実現できていることになり,これが現行のSLAに近いものと仮定します。

おおよそWebサーバの場合,ハードウェア側の性能を使い切ることは難しく,上記のようにアプリケーションセッションを1台あたりどの程度持たせ,処理を行わせるかというところから,HTTP/APサーバの定義を設定することとします。

ハードウェアの性能を使い切っていないのであれば,このままプロセスやスレッドなどを上げてしまえばいいかもしれませんが,どこかを境にミドルウェアが不安定になったり,ネットワークなどに負担をかけてしまったり別の場所で歪みが出てくる場合があります。このあたりは,ユーザ側の業務要件や事業の特性や設定項目,チューニングなどから値を決定していく必要があります。

ハードウェアの性能向上を考慮に入れ,新システムとして以下の構成を検討しました。

  • VMware ESXi 4.x(1台あたり2ゲスト構成)
  • CentOS 5.4(64ビット)
  • Apache 2.2 1,000プロセス
  • Tomcat 6.0 200スレッド/5コンテナ

上記の設定のマシンで10,000プロセスを実現するには,論理的には10台程度あれば可能となります。

今回は,さらにWebサーバにVMwareを採用し,1台のマシンに2ゲストを稼動させると,理論上の半分の5台で10,000プロセス稼動を実現できます。そのため,まずは最新スペックのマシンで,1ゲスト,2ゲストと,Apache 2.2で1,000プロセスずつ稼働することから検証を行います。

●Webサーバにオープンソースが貢献

上記の通り,Webサーバに関しては今回のプロジェクトで大幅に構成を変更しています。それぞれの要素について,もう少し詳しく見ていきましょう。

●OS

Red Hat LinuxからCentOSへの移行に関しては,大手メーカやベンダなど,採用実績や保守メニューなどがない場合があり,動作を保証しなければならない業務アプリケーション開発担当の顔色を見ながら検討する必要があります。ただし,Red Hat Linuxの場合は,オープンソースかどうかではなく,販売形態(サーバ本体に紐付くバンドル版によるイニシャル費用の軽減)や年額保守費用という考え方があり,ユーザ企業側としては立派にランニングコストがかかるもの(=商用プロダクト)と認識します。

この場合,ユーザ側としては今までお金で保守を購入していたことになりますので,今日まで開発元へ問い合わせを行わなければ解決できなかった問題,障害があるか,また,その他プロダクト等でRed Hat Linux以外では保証されないものがどの程度あるのかを徹底的に調査し,その結果,Webサーバに関してはCentOSへ移行できると結論付けました。

●Apache/Tomcat

Apache/Tomcatに関しては一般化されているという認識があり,イニシャルや保守費用などに関してもよほどのことが無い限りは発生しないと思います。これらはアップグレードを実施して機能や性能の向上を実現する対応とします。

●仮想化-VMwareの商用版と無償版

昨今,着々と脚光を浴びている仮想化技術ですが,ここでは事業系企業が初めて仮想化技術を採用するためのアプローチ,検討事項,採用に向けてのシステム構成を記載したいと思います。

VMwareに関しても商用版を選択した場合,Red Hat Linux等を利用するのと同じく,イニシャル,ランニング費用が必要となります。しかし,VMwareに関しては,機能に対して費用が発生するイメージとなりますので,業務要件や,監視・運用等を考慮して採用する必要があるか否かを検討することなります。各機能や,価格帯についてはVMwareのサイト等を参照していただくとして,今回の案件では大まかに以下の3点について検討しました。

[検討1]ディスク装置に関してRAID 1を利用した運用からRAID 0に変更し,リソースの確保と運用の変更を行う。
→ディスク障害が発生した場合,サーバ自体を本番サービスから切り離し,パーツを交換し,最小限の設定後,外部ディスクからイメージファイルを戻し,アプリケーションの差分を埋めて改めて本番サービスへ組み込む運用を実現した。これにより,今まで行っていたテープでのシステムバックアップやディスクのリビルドなどの運用を廃止する事ができた。
[検討2]業務アプリケーションに関しては,単一のサービスを大量のサーバで提供していたが,サーバ自体が性能向上による台数集約が実現されるため,VMotionなど商用にしかない機能を利用せずに,サーバ自体を+n台構成としてスケールで対応できるようにした。
→これにより,監視,運用の設計をしっかりする事で,無償版のVMware ESXiを採用することができた。⁠+n台については,最小構成5台+n台とし,イニシャル時に準備する事とした)
[検討3]サーバ側のディスク(スライス)設計として,ハイパーバイザが構築されるエリアをRAID 1とし,更に仮想OSごとにRAID 0のスライスを割り当てる事で,OS単体に障害が発生しても,他のOSやハードそのものが影響を受けない設計とした。

→その場合,XenよりもVMware製品の方が,システムに対する理解が薄い事業会社の経営陣向けに説明がしやすかった。

実際にゲストとして稼働させる数に関しては,本番にてサービスを提供するという観点より,当初2つのOSを稼働させ,システムの状況を見ながら再度検討する事としました。

画像

著者プロフィール

高岡将(たかおかすすむ)

大手金融,独立系SIerにて気がつけば計18年以上のキャリアを重ねる。バランス感覚に長け,インフラ/アプリ,プレイヤ/マネージャなど関係なくこなし,「いそうだけどいないタイプ」と評価される。

仕事以外では,自転車,ジョギング,サックス等を趣味にし,密かに「エンジニアと健康」についてダイエット成功論の連載を企む。

コメント

コメントの記入