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

第4回 仮想化はサーバ管理者を救うのか?─VMware ESXiで行う運用

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

3.スタンバイ機の利用

運用局面において,ハードウェア障害やリージョン不足などによるスローダウン,その他一般障害に関しては,スタンバイ機をアクティブにすることにより対応することとしました。普段から電源は投入され,バック側(運用管理LANなど)は本番機器同様とすることにより,業務アプリケーションのプログラムリソースなどは常に最新となるように構成し,障害時に対象機器を本番ネットワークから切り離し,スタンバイ機を本番ネットワークに参加させる運用を確立しました。このプランは,通常商いが右肩上がりの際のシステム増強などに関しても柔軟かつ即時に対応することもでき,比較的経営側を(楽に?)説得することが可能なプランでもあります。

余談ですが,スタンバイ機を調達するコストがかけられるのであれば,そのまま本番に参加させればよいのでは? という疑問もあるかと思いますが,スタンバイ機という位置づけをHA構成のスタンバイ側と同じ解釈をすることにより,ライセンス費用の免除であったり,監視などを外部へ委託している際のホストカウントから免除いただくことがメリットとなる場合があります。確かにせっかく購入した最新スペックのハードウェアを利用しないことに抵抗があるかも知れませんが,このあたりは各企業のリスク管理のあり方にも関わってくるのかと思いますので,十分に検討いただければと思います。

4.バックアップ運用の変更

これまでの運用では,システムバックアップ用にそれぞれテープドライブを用意したり,場合によってはバックアップサーバなどを準備して対応していました。これらに関しては,サーバやテープドライブ,メディアなどを準備しなければならず,その管理など含め専用の運用やルールを設けていました。また,バックアップ用のソフトウェアなどがある場合も同様に運用や保守料などが必要な場合もあります。

今回VMware ESXiを複数台本番運用で採用することでテープ関連の運用は全てディスクに移行するべく,⁠ローカル,スタンドアロンでの利用イメージ」を念頭に置くこととしました。そのため,少々面倒な構成ではありますが,全てのホストはiSCSIなどで外部ディスクと接続し,システムバックアップ領域は全て外部筐体に格納することとしました(筐体は単体だが,ホストごとにマウントさせるイメージ)⁠

これによりテープ関連の運用から切り離すことが可能となりました。

図1 構成イメージ

図1 構成イメージ

これによりテープ関連の運用から切り離すことが可能となりました。

たとえば図1の構成で本番運用が行われていた場合,さらに,スタンバイ機「マシン3」「SystemE」⁠SystemF」を準備しておくことで,仮にSystemCに無応答などの障害が発生し復旧に時間がかかる見込みの場合,マシン1自体がダウンしてしまった場合,あるいは別途サーバ増強が必要となった場合に,マシン3の両システムを本番稼動させることにより対応することができます。

また,マシン1自体がダウンしてしまった場合や,RAID0などで構成されているシステムではディスクに障害が発生した際に問題箇所のパーツを交換するなど対応をした際に,システム的な設定(フォーマットやスライスの定義)を行い,後はハイパーバイザからiSCSIを認識させてシステム的なリストアを実施することができます。容量(対応時間)などにもよりますが,ddコマンド一発でリストアできる運用も可能です。

iSCSI側の機能にもよりますが,筐体に即効性などを持たせなくてもよい場合,RAID1やRAID5構成とし,ボリューム・スナップショットなどと併せてバックアップ運用に関する要件をまかなうことを可能とします。また,シン・プロビジョニング機能なども搭載されていていれば,比較的容量を気にすることなく運用を続けることが可能になります。これにより,システム(場合によってはデータ部分)に関しては,テープにコピーするための装置,プロダクト,運用などから開放され,その集約効果も期待できます。

図1 運用イメージ

図1 運用イメージ

5.運用局面

VMware ESXiを利用した運用局面に関する注意事項としては,前記のようにスケールに対応したサーバのポリシーと,通常の運用のほかに,リソースの利用状況について一層注視しておく必要があります。とはいっても,一般的なインフラ(サーバなど)の稼働状況レポートを決められた期間ごとに推移を見定め,増強の可否を検討する程度で良いと思いますが,サービスを提供するアプリケーション部門に関しては,新技術を採用することにより若干抵抗がある可能性もありますので,インフラ,サーバ基盤担当として「論理部分」「物理部分」に分け,仮想化による悪影響が出ていないことが確認できれば良いと思います。

[論理部分]

無応答などの死活確認,セッション数やコネクションプールなどの推移,パフォーマンスなどを注視し,特段問題ないことが証明されていれば,後は時間が過ぎれば慣れていくものかと思います。

[物理部分]
CPU/メモリ使用量
これらはハイパーバイザ側からある程度明示的な定義ができるため,それらについて問題が無いこと確認する。
ディスクパフォーマンス
OSのバージョンをあげたらswapアクセスが増えたなどといった些細なことでも仮想にしたから?と疑われてしまわないよう,普段のヘルス,動向をきちんと把握し,不測の事態でも切り分けができるようチェックする。
ネットワーク状況
場合によっては,複数ホストにて共有する可能性がありますので,帯域など問題ないかなどが確認します。 おおよその場合は,外部(インターネット側)の専用回線が1Gbpsかと思われますので,内部セグメントに関してもクリティカルな部分で無い限り同様に近い形で問題ないかと思われます。

図3 運用イメージ

図3 運用イメージ

著者プロフィール

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

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

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