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

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

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

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

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

  • Red Hat Linux 3.x(32ビット)
  • Oracle 9i

現行のデータベース構成はレスポンス性能の担保を行うため,アップデート系とセレクト系を分けています。今回の対象はセレクト系のみとし,以下の構成を検討しました。

  • Red Hat Linux5.4(64ビット)
  • Oracle 11g(64ビット)

結果的に,DBサーバ側に関してはOracleからフリーソフトへの転用を見送りました。理由としては,今までOracleの機能に依存した運用を行っている(たとえばMaterialized View)ことにより,他プロダクトへの移行に時間的余裕が無い点などがあげられました。

また,XenやVMwareなどを利用した仮想化を検討しましたが,いずれも利用実績はありそうなものの,プロダクトベンダ(オラクル社)より正式なサポートが得えられそうになかった点がネックとなりました。逆にOracleVMなどの選択肢に関しては,一般的な事例が手の届く場所になく,業務アプリケーション開発部門や,保守ベンダーなどとも話し合い,今回は断念しました。その代わり,OSは64ビット版を採用し,OSそのものの機能向上と,データベース側のキャッシュエリアの拡大などで,ハードウェア以外の性能向上を期待する事とします。

さて,上記を元に,DBサーバ50台を何台へ集約できるか見積もりを実施します。

まず,実際にはシステム係数などで重み付け算出する必要がありますが,マシン性能差は5倍と定義付けました。マシン自体が処理可能なプロセス数は150と定義付け,Oracleを9iから11gへアップグレードすることによる性能向上の期待値を2倍と見込みました。以上より,単純に処理可能なプロセス数は150×2=300プロセスとしました。

これはシステムが提供している事業によりますが,アクセスピーク時の必要プロセスを1500と予測し,

1500プロセス÷300=5台

となります(あくまでも机上の計算です)⁠

150台が13台になる?

サーバ集約に向けた削減プランでは,以下の台数に削減できそうだという計画としました。⁠ハード待機用のマシンに関しては,本番稼働機器台数が少なく,保証しているプロセス数等が大きいほど,ダウン時等のインパクトが大きいため,きちんとしたポリシー定義等が必要なのですが,今回は省略します。)

Webサーバ:100台→5台+ハード待機用機器1台+VM待機用(n台)として1台
DBサーバ:50台→5台+ハード待機用機器1台
監視保守,運用委託台数(合計)⁠150台→13台

上記に加え,スケールアップ用の待機マシン,開発機等を加味する必要がありますが,台数は単純に10分の1以下になるため,運用委託費用等に関しても,かなりの削減が望めます。また,劇的に台数が削減される場合,データセンターのラックや電源など,ファシリティ関連でも費用が軽減されます。さらに,地味ですが,テープバックアップ廃止に伴い,運用,メディア類とバックアップソフトウェア等も廃止にする予定です。

これら全てを取りまとめ,システム投資と回収計画を作成し,計画予算とプロジェクトスタートの承認を仰ぎます。

さて,次回は検証を行った結果,VMware ESXiやOracle 11gについてどのような設定を実施していったか記載できればと思います。

著者プロフィール

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

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

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

コメント

コメントの記入