63

Size: px

Start display at page:

Download "63"

さやなにいだ
5 years ago
Views:

1 テクニカルコンピテンシー部基盤技術室シニア IT スペシャリスト高橋一博 Kazuhiro Takahashi オープン系サーバ仮想化技術を利用した社内向け共通プラットフォーム開発検証環境を2008 年度に構築し部内および事業部向けのファイルサーバ Webサーバ開発および検証用サーバの運用環境として仮想マシンを提供してきた本稿では社内向けという狭い範囲に限定されるが機能や構成の異なる物理マシンの仮想環境への移行運用を通して得られた経験をもとに移行計画および仮想マシンの構成についての留意点と採用した方針を報告する 63

2 1. はじめに弊社内には部単位で運用しているファイルサーバや Webサーバおよび開発検証用サーバなど多数のサーバが存在しておりそのほとんどがx86 系サーバである 2008 年度にサーバ仮想化技術とブレードサーバの採用によって共通プラットフォームを構築し仮想化に適した既存サーバの移行および新規開発用サーバの提供を進めてきたその結果当初の目的であった物理サーバが占有する執務スペースの圧迫サーバ台数に比例する管理の複雑化それによって生じる個々人の管理負荷の増加マシンの老朽化などの問題を解決してきたただし既存サーバから共通プラットフォームへの移行および共通プラットフォームの利用環境についてはユーザから多種多様な要望が寄せられ仮想化ゆえの今までにはなかった課題も浮かび上がったそれらに対応するため一定方針のもとに集約を図った結果現時点で仮想サーバ数は70 台を超え共通プラットフォームの増強をなお継続しているサーバ仮想化技術はさらに拡大深化しているが社内向けサーバの仮想化という状況下で採用した方針について共通プラットフォームの改善につなげる意味も含めてその概要を報告する 2. 共通プラットフォーム 2.1. 共通プラットフォーム概要サーバ物理統合のため標準ラックにブレードシャーシブレードサーバファイバチャネル ( 以後 FC と略す )RAID 管理サーババックアップサーバおよびテープライブラリを搭載したブレードサーバにはFC Host Bus Adapter( 以後 HBAと略す ) を装着し FC RAIDによって記憶装置の集中と仮想化を実現した実際に採用したブレードは2CPU(8コア ) 16GBメモリシステムディスク NIC(Ethernet 1000Base-T x 2) およびFC HBA( オプションカード ) で構成されているブレードを使用した共通プラットフォームは2 式あり 1 号機は主に当部内で利用中の現行ファイルサーバやWebサーバの移行用とし RAIDにはIBM-DS4700 (FC 300GB x 16) を採用した 2 号機は主に事業部向けの開発および検証用サーバの運用環境であり RAIDにはIBM-DS4700(FC 300GB x 16およびSATA 500GB x 16) を採用したサービス用 LAN 管理用 LAN ブレードサーバブレード内蔵の FC スイッチモジュール (FC) (FC) バックアップサーバ & SATA RAID-6 (SCSI) 管理サーバ FC RAID-5 & SATA RAID-6 テープライブラリ図 1 共通プラットフォーム 64

3 またサーバ仮想化環境には VMware Infrastructure 3 ( 以後 VI3と略す ) を採用した本報告もその利用実績をもとにしていることに注意して欲しいこれら課題に対して共通プラットフォームで採用した方針および施策を以降に記す 2.2. 共通プラットフォームに対する要求事項共通プラットフォームの利用前後にユーザから寄せられた主な要望を表 1に示すユーザには既存システムの管理者開発検証用サーバの管理者およびそれらの利用者が含まれるなお移行した個々の既存サーバには関連性がなく多種多様な運用管理がなされていた状況が表 1の要求に反映していると考えられる 3. 課題への取り組みセキュリティを重視したため共通プラットフォームへの物理的なアクセスは制限されるがサーバ仮想化技術を用いた場合仮想サーバに対しては従来どおりのユーザインタフェースが確保されるよって2 章に挙げた要求事項のうち解決すべき課題は下記のとおりとなる 3.1. 既存サーバの移行移行ガイドライン部内の既存ファイルサーバやWebサーバのシステム管理者およびユーザからユーザに対するサービス停止時間が短くなるよう要望を受けそれに対応した移行ガイドラインを設けた留意事項ガイドラインを設けた2008 年はLinuxシステムをサーバ仮想化プラットフォームへ自動的に移行するツール ( 以後 P2Vツールと略す ) が少なく機能的な選択肢も限られていたそのためLinuxの場合は特定のツールが移行に失敗した時点でゲストOSのインストールを出発点とする再構築を行ったよって本稿ではWindowsの移行について記す図 2に移行の全体的手順を示す既存サーバの共通プラットフォーム移行に伴うサービス停止期間の短縮性能保証システム管理 ( 特にバックアップ ) (1) 移行支援ツールの比較移行先の共通プラットフォームは VI3 環境であり移行ツールにも VMware 社製品を使用した提供される製品に表 1 課題課題サービス停止時間ユーザインタフェース性能保証リソース増強システム管理その他内容既存システムの共通プラットフォームへの移行に際しユーザに対するサービス停止時間を短くする従来と同様のアクセス方法とユーザインタフェースを提供する既存システムの仮想化では現行システムと同等以上の性能を新規システムについても要求仕様を満たす仮想マシンを提供するサービス提供を継続する上でリソース不足が懸念される場合はリソースの追加が可能なこと現行システムと同じくパッチの適用等を独自に行えるシステムおよびデータのバックアップのために新たにエージェントの追加は行なわない DNS やアクティブディレクトリサービスを継続して受けられること 65

4 リソース ( サービスを含む ) の調査はコールドクローニング用のBoot-CDとホットクローニング用のVMware Converterがありその比較を表 2に仮想マシンの仕様決定示すそれらに移行元および移行先に関する必要な情報を与えれば以後はネットワーク経由で自動的にシステムの新規作成希望 No (P2V) Windows Boot-CD の編集コールドクローニング成功 No ホットクローニング No (Linux) コールドクローニング成功 No 仮想マシンの作成 + OS のインストール移行が行われる (2) 全体の流れ今回の移行要件にサービス停止時間の短縮が挙げられているコールドクローニングおよびホットクローニングとも正常に作業が終了すれば移行に必要な時間に変わりはなくディスク容量にもよるが数時間以上必要なケースが多い一方移行作業が失敗したことが判明するのはコールドクローニングはブート直後であるのに対してホットクローニングの場合は作業進捗率が95% 以上となってからがほとんどであるよって標準手順では成功 No ユーザによる構築失敗がすぐに判明するコールドクローニングを行い次いでホットクローニングに取り組むこととした終了図 2 移行の流れ提供元移行対象 OS 表 2 移行支援ツールの比較コールドクローニング VMware, Inc. Microsoft Windows ホットクローニング特徴起動方法システムの shutdown が必要コールドクローニング専用 Boot-CD を用いた boot(windows PE) 後にアプリケーションとして自動的に起動システムの稼働中に静止点が設けられるだけで shutdown の必要はない物理サーバ上の OS(Windows) のアプリケーションとして起動させる制約事項専用 Boot-CD に物理サーバに対応したデバイスドライバが含まれていない場合ネットワークが使えないつまり移行データを送出できない等の不具合が発生する VMware 提供の petool を使用することによって Boot-CD にドライバの事前追加が可能 OS 上のサービス例えばセキュリティ監視ツールや P2P 監視ツールにより移行が阻害されることがある移行失敗判明の時期 boot 直後移行終了の最終段階移行所要時間移行対象のファイルシステム ( データ ) の大きさに比例 66

5 (3) 運用サービスの調査移行元サーバのリソース調査対象項目にOS 上で稼働しているサービスを含めるホットクローニング開始時に停止または削除するサービスを事前に決定しシステム管理者の同意を得ておくなおホットクローニング開始時にサービスを削除した場合は移行後のゲストOSに再インストールする (4)Boot-CDの編集移行元サーバのリソース調査対象項目に物理サーバが使用しているデバイスも含めた特殊なデバイスの場合デバイスドライバが入手できた場合はあらかじめ Boot-CD に組み込んでおくなお Boot-CDに含まれるデバイスドライバは公式には公開されていないので特殊なデバイスの判断は経験によるところが大きい VMware 社およびMicrosoft 社はWindows PE 用のデバイスドライバを提供していない必要なデバイスドライバはハードウェアベンダーから入手するまた Boot-CD への組み込みには Boot-CDダウンロード時に同時に入手したpeTool.exeを使用する (5) コールドクローニング Boot-CDによりWindows PEが立ち上がった時点で必要なデバイスドライバが不足していれば移行ステップは停止するのでコールドクローニング作業を中止しホットクローニングに切り替える (6) ホットクローニングホットクローニング開始前に移行を阻害すると思われるサービスを停止する移行の失敗が判明するのは終盤であるが画面に表示される作業進捗率が進まなくなった時点で失敗とみなし作業を停止するただし移行先には仮想マシンが作成されているので念のために電源を上げて確認を行う稀にではあるが100% 完了していなくとも仮想マシンとして稼働する場合もあるので移行元サーバ管理者の確認を受けて移行完了とするかの判断を下す移行失敗の場合は仮想マシンのゲストOSのインストールを含めた再構築に着手する 3.2. 性能保証既存システムに対しては移行前と同等の性能を保証しているそのための仮想マシン配置時の留意点を述べるキャパシティプランニング ESXサーバ上への仮想マシン配置決定には下記のとおりいくつかの観点がある仮想マシンの管理者管理組織仮想マシンが提供しているサービス内容 OSおよびソフトウェアの種類 ( 仮想環境での有効ライセンス数 ) 物理リソース (ESXサーバ) の有効利用共通プラットフォームでは物理リソースの有効利用に重点を置いた理由は物理リソースを有効に使いたいということもあるが物理リソースが不足した場合仮想マシンのパフォーマンスが極端に低下するためそれを防ぐという意味が大きいサーバ仮想化メリットの一つにワークロードの異なる仮想マシンを同一のESXサーバ上に適切に配置することによって物理リソースを有効に利用できることが挙げられるその結果個々の仮想マシンが要求するリソースの合計値が物理リソースを上回ることが可能となりサーバの集約効果が期待できるそのため既存システムに対しては物理リソースおよびシステム処理繁忙時を含むリソース調査シートを用いた聞き取り調査を行ったこの結果をもとに仮想マシンを配置したが目安としてはVirtualCenter Management ServerがモニターするESXサーバのCPUおよびメモリの使用率 80% を注意レベルとしたまたSNMP アラーム通知を利用した監視により注意レベルの長時間発生を防いでいるただし今回移行対象となったサーバ群は基幹システムのようにワークロードのピーク発生が確実に予測可能なものではなく突然のリソース消費発生を考慮する必要があったまた ESXサーバ上で稼働するそれぞれの仮想マシンが CPU メモリディスク NIC 等を独自のリソースとして認識かつ使用するためのオーバヘッドも発生しており ESXサーバの負荷は両者を合計したものになるオーバヘッド項目のうちメモリの管理ディスク 67

6 の管理においては予想外の負荷が発生する以降に具体例を示すがその特徴を捉えることによってパフォーマンス低下の原因を特定し共通プラットフォーム内での対応につなげているメモリの管理仮想マシンのオペレーティングシステムがコンテキストスイッチを行うこの現象は各仮想マシンのワークロードを重ね合わせただけでは推測が困難でありサーバ仮想化環境で顕在化するので注意が必要である ESXサーバには通常の物理サーバにおける物理マシン ~ OS ~ アプリケーションによる負荷に加えてサーバ仮想化特有のオーバヘッドがある VirtualCenter Management ServerがモニターするESXサーバの各パフォーマンス値が注意レベルに達した場合にはゲストOS 上のアプリケーション負荷が高くなったのかを確認するだけでなく以降に記す仮想化特有の要因も検討に加え性能の回復に努めた CPUをオーバコミットしている場合物理サーバのリソースはシェア値による重み付けによって仮想マシンに配分される NICは直接の重み付けはされないが仮想スイッチのポート単位でトラフィックシェーピングが適用され表面上はパフォーマンスの低下となって処理されるこれらのリソースは時分割によってシェアされるがメモリは時分割できないことに注意が必要であるメモリのアドレス変換はゲストOS 上の仮想アドレス ~ 仮想マシン上の実アドレス ~ 物理マシン上の実アドレスの二段階となっているが ESXサーバは [ シャドウページテーブル ] と呼ばれるゲストOS 上の仮想アドレス ~ 物理マシン上の実アドレスを一段階で行うマッピングテーブルを作成しプロセッサ上のTLB( 仮想アドレスから物理アドレスへの高速変換を目的としたCPU 内キャッシュ ) がキャッシュすることによってアドレスのマッピングオーバヘッドを回避しているしかし下記の場合はシャドウページテーブル再作成のためにCPUサイクルを費やすため物理マシン上でOSを直接稼働させる場合に比較して大きなパフォーマンスの低下を引き起こす仮想マシンのオペレーティングシステムがゲスト OS 上の仮想アドレス ~ 仮想マシン上の実アドレスのマッピングを変更するディスクの管理仮想マシンにおけるディスクI/O 割り込み処理などをエミュレーションし仮想マシンと物理マシンを橋渡しするバイナリトランスレーションの中心となるVMXプロセスについては下記のとおりである 1 VMXは仮想マシン毎にVMkernelのアプリケーションとして起動する 2 VMXは仮想マシンのCPUとは別のCPUが割り当てられる 3 仮想マシンのI/O 処理はVMM 経由でVMXが行う ( バイナリトランスレーション ) ただしこのときに VMX 用のCPUが仮想マシンのCPUと同時に割り当てられる必要はないよって仮想マシンがI/O 処理を終了するためには仮想マシン用のCPUの他に1CPU 必要になるこのディスクI/Oが実際にゲストOSで処理されるまでの経路を下記に記すゲストOSのドライバ VMM 提供のSCSIコントローラ仮想 SCSIレイヤスイッチ VMFS( 通常の物理サーバではここで作業完了だが VI3ではパススルーしている ) VMXプロセス ( 各仮想マシンにインフラを提供 ) VMkernelのキューに登録仮想マシン群がFCディスクを共有している場合 I/Oの 68

7 競合によってパフォーマンスの低下が生じるが割り込み処理のための大量のバイナリトランスレーションは CPUにおいて予想外の大きな負荷を発生させる 3.3. 仮想マシンおよびデータのバックアップ移行対象の既存サーバは統合管理対象となっていないため個々のサーバ管理者によって独自の方法で管理されておりバックアップも各々の状況に従って行われていた今回はほとんどの既存サーバ管理者つまり仮想マシンのサーバ管理者が対応可能なシステム運用環境の提供を目標として下記のバックアップ方式とした仮想マシンのシステムバックアップサーバ管理者が既存サーバの移行完了を確認した時点で下記のバックアップを行ったリストア操作に複数のステップが必要なVMware Consolidated Backup( 以後 VCBと略す ) は原則として使用しない仮想マシンを停止できない状態が長く続くと判定したときだけ VCBによる暫定バックアップを行う VI3 管理者がVI3の機能を使用して該当仮想マシンのテンプレートを作成書き込み先はバックアップサーバのRAID-6 構成のディスク VI3 管理者がバックアップ用ソフトウェアを使用して同テンプレートをテープにバックアップテンプレートは一世代のみ保管新規作成依頼時には旧テンプレートを削除 ( ディスク容量の確保が目的 ) テンプレートの作成は同時には二台以上行わないクローン作成やテンプレート作成は共有ディスクに対する I/Oレートが高く常時発生しているゲストOS 群のディスクI/O 処理量によってはレスポンスタイムアウトを起こし作業が失敗につながるためであるまたテンプレートおよびテープの管理はVI3 管理者が行いサーバ管理者からの要求に従ってリストアし操作ミスによるシステムの回復などに対応しているデータのバックアップデータのバックアップも仮想マシンのシステムバックアップに近い考え方である個々のサーバ管理者に対してネットワーク上にデータバックアップ用のディスク領域を提供バックアップ先に対するアクセス権はサーバ管理者に対してのみ付与書き込み先はバックアップサーバのRAID-6 構成のディスクサーバ管理者がバックアップデータを指定された場所にコピーバックアップデータの選定およびスケジュールはサーバ管理者が決定し VI3 管理者は関与しない VI3 管理者はバックアップ用ソフトウェアを使用してバックアップ用ディスクからテープにバックアップテープは二世代まで作成それ以前のリストアは不可能 4. おわりにサーバ仮想化技術を利用した共通プラットフォームを 2008 年度に構築した今回は既存サーバの移行および新規開発環境の提供時に管理者およびユーザの要求を実現するために採った方針方式を報告したサーバ仮想化環境管理の一助となれば幸いであるなお Intelから出荷されたXeon 5500 番台は拡張ページテーブル (EPT) 機能が実装されここに述べたシャドウページテーブルとは異なったメモリ管理も行っているため今回記した内容が全てに適用できないことに注意していただきたいまたサーバ仮想化ソフトウェアとしては従来のVI3や Xenだけでなく Intel VTやAMD-Vを前提とした Microsoft Hyper-V Red Hatが採用を打ち出したLinux カーネル仮想化基盤のKernel-based Virtual Machine (KVM) なども続々と登場している今後はそれぞれの短長所を把握し仮想マシンを適切な環境で稼働させることが重要になると思われる 69

8 参考文献 1) VMware 徹底入門翔泳社 2008/11 2) リソース管理ガイド VMware, Inc. 3) 基本システム管理 VMware, Inc. 4) サーバ仮想化技術を利用した社内サーバの集約事例エクサレビュー 2008/ Linuxは Linus Torvaldsの米国およびその他の国における商標または登録商標です VMware, VMotionは VMware, Inc. の米国およびその他の国における商標または登録商標です IBMは IBM Corporationの米国およびその他の国における登録商標です Red Hatは, 米国 Red Hat, Inc. の米国およびその他の国における商標または登録商標です Microsoft Hyper-Vは米国 Microsoft Corporationの米国およびその他の国における商標または登録商標です Advanced Micro Devices AMD-Vは米国 Advanced Micro Devicesの米国およびその他の国における登録商標ですその他の会社名製品名およびサービスはそれぞれ各社の商標または登録商標です

FUJITSU Software Systemwalker Centric Manager Lite Edition V13.5 機能紹介資料

FUJITSU Software Systemwalker Centric Manager Lite Edition V13.5 機能ご紹介 2014 年 3 月富士通株式会社目次特長機能システム構成プラットフォーム各エディションの機能比較表 < ご参考 > Systemwalker Centric Manager Lite Edition は被管理サーバの数が数台 ~30 サーバ以内の規模で