Microsoft Oracle SAP 向け長距離 VMotion VCE Vblock 1 EMC Symmetrix VMAX EMC CLARiX EMC VPLEX Metro により実現 アーキテクチャに関する概要 概要 このホワイト ペーパーでは EMC VPLEX Metro によって提供される仮想化ストレージに VMware vsphere Oracle E-Business Suite Release 12 SAP Microsoft SharePoint 2007 および SQL Server 2008 の OLTP( オンライン トランザクション処理 ) を組み込んだ 仮想化されたアプリケーション環境の設計 / 導入 / 検証について説明しています 2010 年 5 月
Copyright 2010 EMC Corporation. 不許複製 このドキュメントに記載されている情報は ドキュメントの出版日現時点の情報です この情報は予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については Japan.emc.com で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 :H6983-J 2
目次 エグゼクティブ サマリー... 6 ビジネス ケース... 6 製品の概要... 6 主な結果... 8 概要... 9 このホワイト ペーパーの概要... 9 目的... 9 適用範囲... 10 対象読者... 10 用語... 10 構成... 12 概要... 12 物理環境... 12 ハードウェア リソース... 13 ソフトウェア リソース... 13 この分散化された仮想化データセンターのテスト環境の共通の要素... 14 共通の要素の概要... 14 コンテンツ... 14 VMware vsphere... 15 VMware vsphereに関する概要... 15 VMware vsphere 構成... 15 EMC Symmetrix VMAX... 18 EMC Symmetrix VMAXの概要... 18 EMC Symmetrix... 18 VMAX 構成... 18 EMC CLARiX CX4-480... 19 EMC CLARiX CX4-480 に関する概要... 19 EMC CLARiX CX4-480 の構成... 19 VCE Vblock 1... 21 VCE Vblock 1 の概要... 21 VCE Vblock 1 の構成... 21 VPLEX Metro... 22 VPLEX Metroの概要... 22 VPLEX Metro 向けのSANの設計... 23 ストレージ向けのVPLEX Metroの機能... 23 ストレージのベスト プラクティス : パーティションの配置... 23 分散ミラーリング : DR1 デバイス... 23 VPLEX Metroのバックエンド ゾーニング... 24 VPLEX Metro のフロントエンド ゾーニング... 24 3
VPLEX Metro の WAN 接続性... 24 LUN カプセル化を使用した VPLEX Metro への移行 : ホスト アクセスの停止が発生... 24 VMware Storage VMotion を使用した VPLEX Metro への移行 : ホスト アクセスの停止は発生しない... 25 VPLEX Metro DR1 への移行 : ホスト アクセスの停止が発生する... 25 サイト A からサイト B への VPLEX Metro LUN の移行 : ホスト アクセスの停止は発生しない... 26 VPLEX Metro の管理... 27 VPLEX Metro の管理に関する概要... 27 VPLEX Metro の管理手順... 27 Microsoft Office SharePoint Server 2007... 29 Microsoft SharePoint Server 2007 の概要... 29 Microsoft SharePoint Server 2007 の構成... 29 Microsoft SharePoint Server 2007 の構成に関する概要... 29 Microsoft SharePoint Server 2007 の設計に関する考慮事項... 29 Microsoft SharePoint Server 2007 ファームの仮想マシンの構成... 30 仮想マシンの構成とリソースの割り当て... 31 テスト アプローチ :SharePoint ファームのユーザー ロード プロファイル... 32 仮想化された SharePoint Server 2007 環境の検証... 33 テストの概要... 33 VPLEX へのカプセル化を実行しない場合の検証... 33 ローカル サイトとリモート サイト間で実行している VMotion による検証... 34 サイト間 VMotion の検証... 35 Microsoft SQL Server 2008... 36 Microsoft SQL Server 2008 の概要... 36 Microsoft SQL Server 2008 の構成... 36 設計に関する考慮事項... 36 SQL Server テスト アプリケーション... 36 OLTP ワークロード... 36 SQL Server のテストの主なコンポーネント... 36 SQL データベース パーティション設定... 37 証券会社および顧客ファイル グループのパーティション設定... 37 証券会社および顧客ファイル グループ... 37 仮想化された SQL Server 2008 環境の検証... 39 テストの概要... 39 カプセル化前の検証... 39 カプセル化後の検証... 39 サイト間 VMotion の検証... 40 SAP... 41 SAP の概要... 41 SAP の構成... 41 SAP ERP 6.0... 41 4
SAP BW 7.0... 41 ビジネス シナリオ... 41 設計に関する考慮事項... 42 仮想化されたSAP 環境の検証... 44 テストの目的... 44 テスト シナリオ... 44 テスト手順... 44 テストの結果... 45 Oracle... 46 Oracleの概要... 46 Oracleの構成... 46 Oracle E-Business Suite 環境の構成... 46 設計に関する考慮事項... 47 Oracle E-Business Suiteデータベース サーバ... 48 Oracle E-Business Suiteアプリケーション サーバ 1 と 2... 49 Oracle E-Business Suiteインフラストラクチャ サーバ... 49 仮想化されたOracle 環境の検証... 50 チューニング テストとベースライン テスト... 50 ベースライン テスト... 51 vstorageへのrdm (Raw Device Mapping) のカプセル化... 51 Vmotion 移行テスト... 52 FCに関する 100 kmの距離のシミュレーション... 53 バッチ プロセス テスト... 54 結論... 55 要約... 55 結論... 55 次の手順... 55 関連資料... 56 ホワイト ペーパー... 56 製品ドキュメント... 56 その他のドキュメント... 56 5
エグゼクティブ サマリー ビジネス ケース 企業は サーバおよびアプリケーションを仮想化することによるビジネス / 技術面での大きなメリットを次第に認識するようになっているため 同じモデルをストレージ システムにも適用する方法を模索しています サーバの仮想化により ハードウェア リソースをリソース グループに集約して アプリケーションのワークロードに対して動的に割り当てることが可能になります この結果 柔軟性 / 流動性に優れたインフラストラクチャが実現します またストレージも シンプルな統合ポイントを超えて仮想ストレージへと進化させる必要があります これにより ストレージ リソースを集約および仮想化して 動的なストレージ インフラストラクチャを提供できるようになり 動的な仮想サーバ インフラストラクチャを補完することが可能になります EMC は 仮想ストレージ ソリューションを提供します このソリューションは 完全に自動化されたストレージ階層化機能をベースに構築されており 基盤となるストレージ インフラストラクチャの移動 / 柔軟性に関するニーズに対応します この対応は フェデレーションを通じて行われます つまり ストレージ リソースの共通プールが提供されます フェデレーションにより IT は 動的に割り当て可能なリソース プールを介して 迅速かつ効率的にビジネスをサポートできるようになります この柔軟性により より的確なサービスのサポートを実現できるようアプリケーションおよびデータを移動することが可能になるため IT によってビジネスにもたらされる価値が引き上げられます さらに サーバ アプリケーションおよびストレージの共通プールにより サービスとしての IT という新たなコンピューティング モデルが実現します 予想される自然災害など 発生する可能性のある災害による脅威をプロアクティブに回避するため IT 部門は 離れた距離でのストレージ仮想化によって生じる課題を克服する必要があります これまで データセンター間のアレイ レプリケーションとサイトのフェイルオーバー プロセスに依存することなく これを実現することは不可能でした 製品の概要 EMC VPLEX Metro により 離れた 2 つのサイトにあるさまざまなストレージ アレイを アプリケーション ホストが 1 つの共有アレイとして認識できるようになります これにより データセンター内または最大 100 km 離れた距離にあるデータセンター間で 物理か仮想かにかかわらず アプリケーション サーバおよびアプリケーション データの容易な移動および計画的な再配置を実行できるようになります 企業は VPLEX Metro を活用して 同期可能な距離にある複数のホスト間でストレージ リソースを共有およびプール化することにより 効果的な情報の分散を確実に実行できるようになります VPLEX Metro により 同期可能な距離にある仮想環境を管理する新しい方法が企業に提供され 次に示す項目を実行できます 物理データセンター間でのリソースの透過的な共有およびロード バランシング リモート ユーザーの即座のリアルタイム データ アクセスの確保 保護を強化することで 予期しないアプリケーションの停止を軽減 物理データセンター内およびデータセンター間でのリソースの透過的な共有およびロード バランシング VPLEX Metro を使用することで IT 部門は データセンター内およびデータセンター間で仮想マシン アプリケーション データを移動および再配置できるようになります VPLEX Metro は VMware VMotion および Storage VMotion と連携して機能することで 次の項目を実現します : 管理者は 標準的な管理ツールを使用して 実行中のアプリケーションを 2 つのサイト間に容易に分散させることができ ロード バランシング オペレーションを簡単に実行できる 6
実行中のアプリケーションおよびデータを 2 つのサイト間で透過的に移動させることで 予定されているダウンタイム イベント時にサービスの停止が発生しないようにする ストレージを容易に追加または撤去できるため 1 つのアレイ上におけるデータの実際の位置の重要性が低くなる 仮想ストレージにより 新しいストレージ システムを IT 環境に迅速かつシンプルに導入できるようになる 容易にオンサイトでホストしたり ホストティング プロバイダに移行したりすることができる シームレスなマルチサイト ストレージ レイヤーを構築することにより プライベート クラウドの展開を促進する リモート ユーザーの即座のリアルタイム データ アクセスの確保 VPLEX Metro を使用することにより データは分散され アクセスはサイト間で共有されるようになります この結果 IT 環境で次の項目が実現します 2 つのサイトに複数のホストを配置することにより データの読み取り / 書き込みアクセスを同時に実現 ローカル ストレージを配置することなく リモートの物理データセンターのデータにリアルタイムでアクセス可能 最大 100 km 離れている 物理的に分散した環境でストレージを共有する 保護を強化することで 予期しないアプリケーションの停止を軽減 IT は VPLEX Metro を使用することで サイト間の高可用性およびワークロードのリカバリ性を高めると同時に 予想される自然災害など 発生する可能性のある災害による脅威をプロアクティブに回避することができます VPLEX Metro では n+1 クラスタ アーキテクチャの採用により 各 VPLEX クラスタ内のコンポーネントで障害が発生した場合でも 各サイトまたはクラスタでデータに継続的にアクセスできるようにするほか 異なる種類のアレイ間での異機種混在ストレージ ミラーリング機能と VCE( 仮想コンピューティング環境 ) 連合 Vblock 1 を提供します サポート対象となるアレイに関する詳細については EMC サポート マトリックスを参照してください VPLEX Metro と 地理的に分散した VMware クラスタ間の VMware VMotion を組み合わせて使用することにより IT は あるサイトから別のサイトにワークロードを無停止でプロアクティブに移動できるようになるため 災害が発生する前に それによってもたらされる脅威に対処することが可能になります 7
主な結果 VPLEX Metro によって実現されるこのソリューションは これまでは容易に実現できなかった方法で IT に関する主な課題を解決します これまでお客様は 地理的に分散したデータセンター間でのデータおよびアプリケーションの移動に関する課題に 手作業で取り組んでいました お客様は 物理的なバックアップを実行するか データ レプリケーション サービスを使用して アプリケーション データを代替サイトに移動していました このとき アプリケーションを停止させる必要があったほか テストと検証が完了するまで アプリケーションを再開することはできませんでした VPLEX Metro により こうした移行に関する課題を迅速かつ容易に解決することができます DR1 ( 分散 RAID 1 デバイス ) が確立されると すべてのデータのコピーが完了する前であっても リモート サイトで即座にアプリケーションを開始できます VPLEX Metro により 既存のアプリケーション / インフラストラクチャとの透過的な統合が可能となり サービスを停止させることなくリモート データセンター間でデータを移行できる機能が提供されるため 仮想ストレージ環境をより効果的に管理できるようになります このソリューションで VPLEX Metro を活用することにより 企業は次の項目を実現できます VMware VMotion や Storage VMotion などの標準的なインフラストラクチャ ツールを使用することにより ダウンタイムや停止を発生させることなく サイト間のアプリケーションの移動をリアルタイムで容易に実行できる 災害の回避およびデータ移動のための アプリケーションに対して透過的な無停止のソリューションが提供される この結果 テープ バックアップやデータ レプリケーションなどの従来のソリューションで発生していたオペレーションに関するインパクトが 数日または数週間から数分または数時間に短縮される 標準的なインフラストラクチャ ツールを使用することにより 地理的に分散したデータセンター間のリソースの透過的な共有およびロード バランシングを実行する 8
概要 このホワイト ペーパーの概要 このホワイト ペーパーでは この環境で使用されるテクノロジーとコンポーネントについて簡潔に説明することから開始します その後 この分散化された仮想化データセンターのテスト環境をサポートする共通の要素について説明します さらに このソリューションで使用される Microsoft SharePoint SQL SAP Oracle アプリケーションの構成について概説します 最後に テストの手法および検証された結果についてまとめます このホワイト ペーパーは次のセクションで構成されます トピック ページ 構成 12 この分散化された仮想化データセンターのテスト環境の共通の要素 14 VMware vsphere 15 EMC Symmetrix VMAX 18 EMC CLARiX CX4-480 19 VCE Vblock 1 21 VPLEX Metro 22 VPLEX Metroの管理 27 Microsoft Office SharePoint Server 2007 29 Microsoft SQL Server 2008 36 SAP 41 Oracle 46 結論 55 関連資料 56 目的 このホワイト ペーパーの目的は 読者に対し VPLEX Metro テクノロジーについて包括的に理解してもらうほか VMware VMotion や Storage VMotion などのツールとともに VPLEX Metro テクノロジーを使用して 最大 100 km 離れた場所にあるデータセンター間で ダウンタイムまたは停止を発生させることなく 効果的なリソースの分散および共有を実行する方法を把握してもらうことにあります 9
適用範囲 このホワイト ペーパーの範囲は 次の項目をドキュメント化することにあります EMC VPLEX Metro によって提供される仮想化ストレージを利用した 複数のアプリケーションの環境構成 直接アクセス可能な SAN 接続ストレージから EMC VPLEX Metro によって提供される仮想化ストレージ環境への移行 地理的に分散した VPLEX Metro 仮想化ストレージ環境内のアプリケーション機能 対象読者 このホワイト ペーパーの対象読者は次のとおりです ローカルおよび分散フェデレーション プラットフォームとして VPLEX Metro を使用して 複数アプリケーションの仮想化データセンターの実装に取り組んでいるフィールド担当者 EMC のマルチアプリケーション仮想化データセンターの評価 取得 管理 運用 設計に関与するお客様の関係者 (IT プランナー ストレージ アーキテクト 管理者を含む ) 提案のガイダンスと作成を担当する EMC のスタッフとパートナー 用語 本書で使用される用語の定義を次の表にまとめています 用語 CNA COM DR FCoE HA Metro-Plex OATS OLTP SAP ABAP SAP BI SAP CI SAP ERP UCS 定義 統合ネットワーク アダプタ 通信 : クラスタ間およびクラスタ内の通信リンクを特定する 災害復旧 Fibre Channel over Ethernet 高可用性 MAN( メトロポリタン エリア ネットワーク : たとえば 同じビル サイト または最大 100 km 離れた場所にあるキャンパス ) 内で接続される複数のクラスタ Oracle Application Testing Suite サーバ オンライン トランザクション処理 SAP Advanced Business Application Programming SAP Business Intelligence SAP Central Instance SAP Enterprise Resource Planning Cisco ユニファイド コンピューティング システム 10
用語 VCE VM VPLEX Metro VMDK 定義 仮想コンピューティング環境連合 Cisco EMC VMware で構成され 非常に高いレベルの共同コラボレーション サービス パートナーシップを実現することで プライベート クラウドへのインフラストラクチャ仮想化の移行に関する リスクを回避 する 仮想マシン 物理マシンのようにプログラムを実行するマシンのソフトウェア実装 クラスタ内または同期可能な距離にある 2 つのクラスタ間の分散フェデレーションを実行 仮想マシン ディスク フォーマット VMDK ファイルは 仮想マシンのハード ディスク ドライブのコンテンツを格納する このファイルには 物理ハード ディスクと同じ方法でアクセスできる 11
構成 概要 次のセクションでは 環境で使用されるテクノロジーとコンポーネントを特定し それぞれについて簡潔に説明します 物理環境 次の図は 環境の物理アーキテクチャの全体像を示しています 12
ハードウェア リソース 次の表は ソリューションの検証に使用されるハードウェアを示します 装置個数構成 Intel x86 ベース サーバ 5 クワッド CPU 96 GB RAM デュアル 10 GB CNA( 統合ネットワーク アダプタ ) VCE Vblock 1 1 Cisco UCS( ユニファイド コンピューティン グ システム ) Cisco Nexus 6120 スイッチ EMC CLARiX CX4 EMC Symmetrix VMAX 1 FC( ファイバ チャネル ) 接続性 450 GB/15k FC ドライブ EMC CLARiX CX4-480 1 FC 接続性 450 GB/15k FC ドライブ EMC VPLEX Metro 2 VPLEX Metro ストレージ クラスタ デュアル エンジン 4 ダイレクタによる中規模構成 WAN エミュレータ 1 1 GbE 100 km の距離 ファイバ チャネル SAN 長距離エミュレータ 1 1/2/4 GB FC 100 km の距離 ソフトウェア リソース 次の表は ソリューションの検証に使用されるソフトウェアを示します ソフトウェア バージョン VMware vsphere 4.0 U1 Enterprise+ ビルド 208167 VMware vcenter 4.0 U1 ビルド 186498 EMC PowerPath /VE 5.4.1 ビルド 33 Red Hat Enterprise Linux 5.3 DB2 Linux UNIX Windows 向け 9.1 Microsoft Windows 2008 R2(Enterprise Edition) Microsoft SQL Server 2008 Microsoft Office SharePoint Server 2007(SP1+ 累積アップデート ) Microsoft Visual Studio Test Suite 2008 KnowledgeLake Document Loader 1.1 Microsoft TPCE BenchCraft kit MSTPCE1.9.0-1018 SAP Enterprise Resource Planning 6.0 SAP Business Warehouse 7.0 Oracle E-Business Suite 12.1.1 Oracle RDBMS 11GR1 11.1.0.7.0 13
この分散化された仮想化データセンターのテスト環境の共通の要素 共通の要素の概要 このホワイト ペーパーで説明する仮想化データセンター環境は 共有インフラストラクチャを念頭に置いて設計および導入されました サーバからローカル / 分散フェデレーション ネットワーク統合に至るまで インフラストラクチャに関して最大の ROI を実現するため 環境のすべてのレイヤーを共有すると同時に 機能およびパフォーマンスに関するアプリケーションの要件も満たしています VMware vsphere をベースとするサーバ仮想化を使用することで Intel x86 ベースのサーバは アプリケーション間で共有され 冗長性およびフェイルオーバー機能を実現するためにクラスタ化されます 物理データセンター間で共有データ ストアを提供するために VPLEX Metro が利用されており この結果 物理サイト間のアプリケーション仮想マシンについて VMotion による移行が実現しています 物理サイト A のストレージは SAP 環境向けの Symmetrix VMAX SE( 単一エンジン ) と Microsoft および Oracle 環境向けの CLARiX CX4-480 で構成されています 物理サイト B のデータセンター インフラストラクチャおよびストレージには Vblock 1 が使用されています コンテンツ このセクションでは 次の表に示された この分散化された仮想化データセンター環境の共通の要素について説明しています トピック ページ VMware vsphere 15 EMC Symmetrix VMAX 18 EMC CLARiX CX4-480 19 VCE Vblock 1 21 VPLEX Metro 22 VPLEX Metroの管理 27 14
VMware vsphere VMware vsphere に関する概要 VMware vsphere は IT インフラストラクチャのデータセンター仮想化に使用できる 業界で最も信頼性の高いプラットフォームです VMware vsphere により 堅牢かつ可用性に優れた環境で x86 サーバ ハードウェアを最も効率的に そして拡張性に優れた方法で活用できるようになります VMware ESX は次の項目を実現します サーバ プロセッサ メモリ ストレージ ネットワーク リソースを複数の仮想マシンに抽出することで VMware VSphere 4 スイートの基盤を構築する 物理サーバを複数の仮想マシンに分割する 各仮想マシンは プロセッサ メモリ ネットワーク機能 ストレージ BIOS を搭載した完全なシステムとして機能する 複数の仮想マシン間で 1 つのサーバ リソースを共有し リソースのさらなる共有のために ESX サーバをクラスタ化する VMware vsphere 構成 このソリューションでは VMware vsphere は次のとおり構成されました サイト A:Microsoft と Oracle アプリケーション環境 サイト A:SAP アプリケーション環境 サイト B:Microsoft Oracle SAP アプリケーション環境 サイト A:Microsoft と Oracle アプリケーション環境 Microsoft と Oracle 向けのサイト A の仮想インフラストラクチャは VMware vsphere 4 Update 1 を実行している次のエンタープライズ クラス サーバ ( 合計 2 台 ) で構成されます : コンポーネント メモリ 説明 128 GB RAM CPU 6 コア 2.659 GHz X7460Intel Xeon プロセッサ 4 SAN およびネットワーク接続 ファイバ チャネルおよび Ethernet 接続性向け 10 GB Emulex LightPulse LP21000 CNA 2 Broadcom 5708 GbE アダプタ 2 高可用性ネットワーク VMware サービス コンソール向け 1 Gb/ 秒物理接続 2 仮想マシン アプリケーション接続および VMotion 向け VLAN の物理 10 Gb/ 秒接続 2 VMDK 仮想マシンの起動 LUN およびアプリケーション データ LUN に仮想マシン ディスクが使用される 15
サイト A:SAP アプリケーション環境 SAP 向けのサイト A の仮想インフラストラクチャは VMware vsphere 4 Update 1 を実行している次のエンタープライズ クラス サーバ ( 合計 2 台 ) で構成されます : コンポーネント メモリ 説明 96 GB RAM CPU クワッド コア 2.792 GHz X5560 Intel Xeon プロセッサ 2 SAN およびネットワーク接続 高可用性ネットワーク VMDK ファイバ チャネルおよび Ethernet 接続性向け 10 GB Emulex LightPulse LP21000 PCI FCoE CNA 2 Broadcom 5708 GbE アダプタ 2 VMware サービス コンソール向け 1 Gb/ 秒物理接続 2 仮想マシン アプリケーション接続および VMotion 向け VLAN の物理 10 Gb/ 秒接続 2 仮想マシンの起動 LUN およびアプリケーション データ LUN に仮想マシン ディスクが使用される サイト B:Microsoft Oracle SAP アプリケーション環境すべてのアプリケーション向けのサイト B の仮想インフラストラクチャは VMware vsphere 4 Update 1 を実行している Vblock 1 の一部として 次のエンタープライズ クラス Cisco UCS ブレード サーバで構成されます : コンポーネント メモリ 説明 48 GB RAM CPU クワッド コア 2.526 GHz E5540 Intel Xeon プロセッサ 2 SAN およびネットワーク接続 高可用性ネットワーク VMDK ファイバ チャネルおよび Ethernet 接続性向け Cisco UCS CNA M71KR-E-Emulex FCoE CNA 2 仮想マシン アプリケーション接続 VMotion VMware Service Console 向け物理 10 Gb/ 秒接続 2 仮想マシンの起動 LUN およびアプリケーション データ LUN に仮想マシン ディスクが使用される 次の画像は サイト A とサイト B のクラスタを示しています 16
17
EMC Symmetrix VMAX EMC Symmetrix VMAX の概要 EMC Symmetrix VMAX シリーズは 可用性の高い次世代仮想データセンター向けの多様な新機能を備えています 高レベルのデータ保護およびレプリケーションにより EMC Symmetrix VMAX システムは エンタープライズ SAN( ストレージ エリア ネットワーク ) テクノロジーの最前線に位置します さらに Symmetrix VMAX アレイは 必要に応じたパフォーマンスの提供を損なうことなく サービス レベルを透過的に最適化するための速度 容量 効率性を実現しています こうした機能は VMware 仮想データセンターなどの大容量の仮想化サーバ インフラストラクチャにおいて最大のメリットとなります Symmetrix VMAX システムは 次世代のデータセンターにインフラストラクチャ サービスを提供するよう構築された EMC のハイエンド ストレージ アレイです Symmetrix VMAX は 信頼性 可用性 拡張性を実現するよう構成されており 特殊なエンジンを使用します 各エンジンには 2 つの冗長ダイレクタ モジュールが装備されており すべての重要データの並列アクセスおよび複製コピーを実行します Symmetrix VMAX の Enginuity オペレーティング システムは 次に示す先進的な機能を提供します ストレージ管理の合理化を実現する自動プロビジョニング グループ 操作性と容量利用率の向上を実現する Virtual Provisioning ストレージ階層間を無停止で移動する仮想 LUN テクノロジー EMC Symmetrix VMAX 構成 このソリューションで導入される SAP アプリケーション環境は サイト A のプライマリ ストレージとして Symmetrix VMAX アレイを使用しています 次の表に示したように起動 LUN およびデータ LUN がプロビジョニングされます 注仮想マシンによる LUN の割り当ての詳細については このホワイト ペーパーの SAP セクションの説明を参照してください 容量 LUN の数 RAID タイプ 500 GB 2 RAID 5(7+1) 250 GB 6 RAID 5(7+1) 85 GB 8 RAID 5(7+1) 65 GB 2 RAID 5(7+1) 32 GB 4 RAID 1/0 すべてのドライブは 400 GB 15k FC ドライブです LUN は 冗長性とスループット確保のため 2 つの FA( フロントエンド アダプタ ) を介して Symmetrix VMAX から提供されています VPLEX Metro にカプセル化された後 同じ種類 / サイズのデバイスが DR1 として提供されます 18
EMC CLARiX CX4-480 EMC CLARiX CX4-480 に関する概要 EMC CLARiX CX4 シリーズは 第 4 世代の CLARiX CX ストレージ プラットフォームにより 業界をリードする革新性をミッドレンジ ストレージの分野に提供します 柔軟性と拡張性の高いハードウェア設計と先進的なソフトウェア機能を独自に組み合わせることにより Intel Xeon プロセッサを備えた EMC CLARiX CX4 シリーズ システムは 今日の中堅企業や大企業の拡大する多様なニーズを満たすことができます フラッシュ ドライブ UltraFlex などの革新的なテクノロジーにより 次の項目を実現できます コストと消費電力の削減 可用性と仮想化の最適化 EMC CLARiX CX4 モデル 480 は最大で 256 台の可用性の高いデュアル接続ホストをサポートしており ディスク ドライブを 480 台まで増設でき 最大で 939 TB の大容量に対応します 以前の世代の CLARiX と比較して 2 倍のパフォーマンスと拡張性を提供する CLARiX CX4 は 部門アプリケーションからデータセンター クラスのビジネス クリティカルなシステムまで 幅広いニーズを満たす業界トップのミッドレンジ ストレージ ソリューションです EMC CLARiX CX4-480 の構成 このソリューションで導入される Oracle および Microsoft アプリケーション環境は サイト A のプライマリ ストレージとして CX4-480 アレイを使用しています 次の表に示したように起動 LUN およびデータ LUN がプロビジョニングされます 注仮想マシンによる LUN 割り当ての詳細については このホワイト ペーパーの Oracle Microsoft Office SharePoint Server 2007 Microsoft SQL Server 2008 セクションの情報を参照してください SQL/SharePoint 容量 LUN の数 RAID タイプ 200 GB 2 RAID 5(4+1) 150 GB 2 RAID 5(4+1) 125 GB 4 RAID 5(4+1) 100 GB 16 RAID 5(4+1) 75 GB 24 RAID 5(4+1) 50 GB 3 RAID 5(4+1) 20 GB 12 RAID 1/0 15 GB 4 RAID 5(4+1) 19
Oracle 容量 LUN の数 RAID タイプ 500 GB 1 RAID 5(4+1) 150 GB 2 RAID 1/0 80 GB 4 RAID 5(4+1) 50 GB 1 RAID 5(4+1) すべてのドライブは 400 GB 15k FC ドライブです LUN は 冗長性とスループット確保の目的でマルチパスをサポートするため 4 つの SP( ストレージ プロセッサ ) を介して CLARiX CX4-480 から提供されています VPLEX Metro にカプセル化された後 同じ種類 / サイズのデバイスが DR1 デバイスとして提供されます 20
VCE Vblock 1 VCE Vblock 1 の概要 Vblock は 明確なパフォーマンス 容量 可用性に関するプロファイルを有する 事前設計されたテストおよび検証済みの IT インフラストラクチャ ユニットです Vblock は IT インフラストラクチャの取得 導入 運用を合理化するという考えから生まれたテクノロジーです Vblock は 特定のパフォーマンスおよび可用性に関する制約を克服するよう厳格に定義されている一方で 効率性 制御 選択の組み合わせに関するメリットが存在します Vblock 1 では 各 Cisco UCS シャーシに B-200 シリーズのブレードが搭載されており 48 GB の RAM を搭載したブレードが 6 台 96 GB RAM を搭載したブレードが 2 台が格納されます これにより 優れたコスト パフォーマンスが提供されるほか Vblock 定義内のインメモリ データベースなど メモリを大量に消費するアプリケーションがサポートされます Vblock 1 内では 起動サービスおよびストレージはすべて SAN (Vblock 1 の場合は CX4-480 ストレージ アレイ ) から提供されるため B-200 シリーズ ブレードにハード ディスク ドライブは存在しません VCE Vblock 1 の構成 Vblock 1 は サイト B でコンピューティング / ストレージ リソースとして使用されました これにより この使用例で導入されたアプリケーションに関する ワークロードのバランシング機能および災害を回避するためのフェイルオーバー機能が提供されました Vblock 1 の標準的な最小構成を使用することで このコンピュータのリソースは Cisco UCS B シリーズ ブレード サーバと CLARiX CX4-480 のストレージ リソースによって提供されています Vblock の詳細については Vblock Infrastructure Packages Reference Architecture を参照してください 注 VPLEX Metro を介して Vblock ストレージを提供することにより Vblock の特定の管理機能が使用できなくなる場合があります お使いの Vblock 環境に与える可能性のある影響については EMC 担当営業までお問い合わせください 次の図に示すとおり Vblock 1 の 16 あるブレードのうち 4 つが この環境のテストに使用されました 2 ノード構成の ESX クラスタがサイト B に 2 つ作成されています 1 つは Microsoft および Oracle アプリケーションをホストするため もう 1 つは SAP アプリケーションをホストするためです Vblock によって提供されたストレージは プライマリ サイト環境を複製できるだけのサイズを有しています デバイスは VPLEX Metro で作成された DR1 デバイスの一部として構成され プライマリ サイトの LUN とペアを構築しています 21
VPLEX Metro VPLEX Metro の概要 VPLEX Metro は 従来のストレージ アレイによって提供される物理ストレージを データセンター間の障壁を越えて仮想化 アクセス 管理できるようにする SAN ( ストレージ エリア ネットワーク ) ベースのブロック ローカル / 分散フェデレーション ソリューションです AccessAnywhere と名付けられたこの新しいアクセス形態により 物理データセンターの限界およびストレージ アレイに関する多くの制約が取り払われます AccessAnywhere ストレージにより データセンター間でデータの移動 / アクセス / ミラーリングを透過的に実行できるようになり まるで物理面での制約が存在しないかのように データセンター間でストレージおよびアプリケーションを効果的に機能させることができるようになります 従来の SAN ベース ストレージのアクセス次の図は 従来の SAN ベース ストレージのアクセスを示しています ストレージ仮想化レイヤーを介したストレージ アクセス 次の図は ストレージ仮想化レイヤーを介したストレージ アクセスを示しています 22
VPLEX Metro 向けの SAN の設計 SAN 環境において VPLEX Metro は ターゲットとイニシエータの両方の役割を担っています ホストの観点からは VPLEX Metro はターゲットであり バックエンド ストレージ アレイの観点からは VPLEX Metro はイニシエータです VPLEX Metro を介してすべての LUN がホストに提供されるよう環境が構成されている場合 SAN ゾーニングを実行できます このように ホストは VPLEX Metro フロントエンド ポートと同じ SAN に ストレージ アレイは VPLEX Metro バックエンド ポートと同じ SAN に存在します ホストがストレージ アレイに直接アクセスする必要のある環境の場合 および移行などで VPLEX Metro LUN にアクセスする必要がある環境の場合 ホストが両方のソースから LUN を認識できるよう ホスト VPLEX Metro のフロントエンドとバックエンド ストレージ アレイをすべて 同じ SAN に配置する必要があります ストレージ向けの VPLEX Metro の機能 VPLEX Metro は データを保持した状態で既存のストレージ デバイスのカプセル化およびカプセル化解除を実行する機能を提供します EMC VPLEX Metro により 同期距離内にある 2 つの VPLEX Metro クラスタ間でのデータのアクセスと移動が可能になります 独自のスケール アップおよびスケール アウト アーキテクチャを採用した VPLEX Metro の高度なデータ キャッシングと分散キャッシュ一貫性により ワークロードのリカバリ性 ストレージ ドメインの自動共有 ロード バランシング フェイルオーバーが提供されます これにより 予測可能なサービス レベルを維持しながらローカルとリモートの両方のデータ アクセスが確保できます 注 4 KB の倍数でないストレージ ボリュームを 要求したり カプセル化したりすることはできません ストレージのベスト プラクティス : パーティションの配置 直接アクセスするストレージ ボリュームに適用されるストレージのベスト プラクティスは 仮想ボリュームにも適用されます 準拠すべきベスト プラクティスとして x86 ベースの OS プラットフォームのパーティション配置が挙げられます パーティションを誤って配置すると ストレージ アレイ内のリソースを大幅に消費したり 追加の作業が必要になったりすることがあり パフォーマンスの低下につながります パーティションの配置を誤ると アレイへの I/O オペレーションが トラックまたはシリンダーの境界を越えることになり I/O オペレーションを満たすために複数の読み取り / 書き込み要求が必要になります 32 KB の制限内にパーティションを配置することにより こうした事態を回避できます 分散ミラーリング : DR1 デバイス EMC VPLEX Metro-Plex の分散ミラーリング機能により ミラーリングされた仮想ボリュームを作成する機能が提供されます ボリュームのミラー行程は Metro-Plex の各サイトに存在する物理ストレージによってサポートされます ホストにとって DR1 デバイスは 両方のクラスタによって提供される同じボリューム ID を有する 1 つの論理ボリュームです デバイスへの I/O は VPLEX Metro クラスタによって同時に発行できます VPLEX Metro クラスタは高度なデータ キャッシングと分散キャッシュ一貫性を使用して ワークロードのリカバリ性 ストレージ ドメインの自動共有 ロード バランシング フェイルオーバーを提供し 予測可能なサービス レベルを維持しながらローカルとリモートの両方のデータ アクセスを実現します 23
VPLEX Metro のバックエンド ゾーニング 各ストレージ アレイにおいて 各 VPLEX Metro バックエンド ダイレクタとの間に Symmetrix VMAX の場合には複数の FA( フロントエンド アダプタ ) CLARiX CX4-480 Vblock の場合には複数の SP 接続を設定することにより スループットと冗長性を確保するようバックエンド ゾーニングが構成されました 構成される VPLEX Metro ポートの数は 使用される LUN の数 ホストからアレイに転送されるデータ量によって決定されます それに応じて各環境のサイズを決定する必要があります VPLEX Metro によって要求された LUN だけが認識されるよう デバイスがマスキングされます バックエンド ゾーニングは Cisco MDS 9500 スイッチに構成されます 各 VPLEX Metro バックエンド ゾーンにつき 2 つの CLARiX SP ポートが存在します VPLEX コマンド ライン インタフェース (VPlexcli) を使って VPLEX Metro バックエンド ポートおよび COM ポートを検証できます バックエンド ゾーニングが完了したら ストレージ アレイを再検出する必要があります VPLEXcli または Management Console を使用してストレージ ボリュームをチェックできます VPLEX Metro のフロントエンド ゾーニング 各 ESX ホストに 2 つの FC アダプタ (CNA を介して ) を構成し 各アダプタを複数の VPLEX Metro フロントエンド ダイレクタ ポートにゾーニングすることで スループットと冗長性を確保するようフロントエンド ゾーニングが構成されました 構成される VPLEX Metro ポートの数は 使用される LUN の数 ホストからアレイに転送されるデータ量によって決定されます それに応じて各環境のサイズを決定する必要があります アプリケーション クラスタの各サーバは 同じ LUN にすべてアクセスできるよう 同じように構成されています フロントエンド ポートは VPLEX Metro メタボリュームが作成された後にのみ有効にすることができます このメタボリュームには 重要なシステム構成データが含まれます メタボリュームに関する詳細については EMC VPLEX Installation and Setup Guide を参照してください VPLEX Metro の WAN 接続性 WAN 構成は 冗長性とスループットを確保するよう設計されました 各ダイレクタの WAN ポートは それぞれシュミレートされた場所にある MDS( 複数階層ダイレクタ スイッチ ) に接続されています 2 つのポートを装備した ISL( スイッチ間リンク ) が FC スイッチに構成され こうした接続は 100 km のレイテンシーを確保するよう WAN エミュレータを介して実現しています LUN カプセル化を使用した VPLEX Metro への移行 : ホスト アクセスの停止が発生 直接アクセスされるストレージ アレイから VPLEX Metro アレイに LUN を移行する際に使用できる方法の 1 つとしてカプセル化が挙げられます カプセル化プロセスでは VPLEX Metro が 元のアレイから認識できる LUN のオーナーシップを取得します カプセル化されると ホストはその LUN を元のアレイから直接認識することはできなくなります VPLEX Metro から LUN を認識できるよう ゾーニングを介してホストを構成する必要があります カプセル化を実行するには 仮想マシンを ESX のイベントリから削除して ESX ホストが 新しい LUN および仮想マシンを認識できるよう再スキャンを実行する必要があります この移行にあたっては停止が必要となります ストレージ使用率の観点からは この方法を実行する場合 必要となる差分の容量が最小限で済みます これは 元の LUN がカプセル化されることにより 余分な容量を必要とする移行 LUN が必要なくなるためです 24
VMware Storage VMotion を使用した VPLEX Metro への移行 : ホスト アクセスの停止は発生しない VMware Storage VMotion を使用して 直接アクセスされるストレージ アレイから VPLEX Metro を介して提供される LUN に 無停止で移行することができます これは 元の LUN と新しい VPLEX Metro LUN の両方を同時にホストに対して提供した後 元の LUN から VPLEX Metro LUN に VMware Storage VMotion を実行することで実現されます 元の LUN に戻す必要はないという前提に立った場合 元の LUN をストレージ アレイが再要求して 他の目的にディスク容量を使用することができます ストレージ使用率の観点からは この方法を実行する場合 移行中に追加のストレージ容量が必要となります これは 既存の LUN から VMotion を実行する前に新しい LUN を VPLEX Metro に作成する必要があるためです ただし この後 元の LUN を破棄して その容量をアレイ上の未使用プールに戻して追加することができます VPLEX Metro DR1 への移行 : ホスト アクセスの停止が発生する ダウンタイムが懸念事項ではない場合 VPLEX Metro DR1 デバイスへのデータ移行を 余分な移行 LUN なしで実行できます 移行手順は次のとおりです ステップ アクション 1 仮想マシンの電源をオフにし その仮想マシンを vcenter インベントリから削除します 2 VPLEX Metro ではない元の LUN をカプセル化します 3 LUN をストレージ グループから削除します 4 この LUN を VPLEX ストレージ グループまたはストレージ マスキングに追加します 5 ストレージ アレイを再スキャンします 6 アプリケーション一貫性オプションによりストレージ ボリュームを要求します 7 エクステントおよびローカル デバイスを作成します 8 DR1 デバイスを作成します 9 新たにカプセル化された LUN を DR1 デバイスに追加し DR1 デバイス上に仮想ボリュームを作成します 10 仮想ボリュームをホスト ビューに割り当てます 11 新しい DR1 デバイスを認識するため ESX ホストを再スキャンします 12 仮想マシンをインベントリに追加し 仮想マシンの電源をオンにします ストレージ使用率の観点からは この方法を実行する場合 必要となる差分の容量が最小限で済みます これは 元の LUN がカプセル化されることにより 移行時に余分な容量を必要とする移行 LUN が必要なくなるためです ただし DR1 仮想ボリュームのリモート デバイス向けの追加の容量が必要となります 25
サイト A からサイト B への VPLEX Metro LUN の移行 : ホスト アクセスの停止は発生しない 一部の状況では Metro-Plex の 1 つのサイトにある VPLEX Metro LUN(DR1 以外 ) から Metro-Plex の他のサイトの VPLEX Metro LUN(DR1 以外 ) への移行が必要になる場合があります これは Metro-PLEX に展開されている移行 DR1 デバイスを使用することで実現されます 手順は次のとおりです ステップ アクション 1 元の VPLEX Metro LUN と VPLEX Metro 移行 DR1 デバイスを 両方のサイトのホストに提供します 2 VMware Storage VMotion を使用して サイト A の VPLEX Metro LUN から移行 DR1 デバイスに移行します 3 VMware VMotion を使用して サイト B のホストに仮想マシンを移行します 4 VMware Storage VMotion を使用して 移行 DR1 デバイスからサイト B の VPLEX Metro ローカル LUN に移行します ストレージ使用率の観点からは この方法を実行する場合 移行中に追加のストレージ容量が必要となります これは 既存の LUN から VMware Storage VMotion を実行する前に新しい LUN を VPLEX Metro に作成する必要があるためです ただし この後 元の LUN を破棄して その容量をアレイ上の未使用プールに戻して追加することができます 26
VPLEX Metro の管理 VPLEX Metro の管理に関する概要 既存のストレージ アレイを仮想化されたストレージ環境で使えるようにするには 次の 2 つのオプションが存在します すでにホストによって使用されている既存のストレージ アレイからストレージ ボリュームをカプセル化する または 新しい VPLEX Metro LUN を作成して 既存のデータをこの LUN に移行する 移行に要する時間の観点から見れば Storage VMotion を介して新しい VPLEX Metro LUN に移行する場合に比べ カプセル化の方が極めて高速に処理を行うことができます ( この環境では約 4~5 倍高速 ) Storage VMotion を使用するメリットは アプリケーション サーバでダウンタイムが発生しない点です 一方 カプセル化オプションを使用した場合 ホストが仮想マシンの再スキャンを実行して入替を実行する必要があるため ダウンタイムが発生します VPLEX Metro は VPLEXcli を使用して既存データをカプセル化するオプションを提供します アプリケーションの整合性が設定された場合 ( appc フラグを使用 ) 要求されたボリュームは データが保護され データが失われることはありません VPLEX Metro の管理手順 VPLEXcli にも同じ機能が存在しますが このソリューションでは VPLEX Metro の管理は主に Management Console を通じて実行されました 安全な Web ベースの GUI に認証すると ユーザーに対して 完了順に示された 画面上の構成オプションのセットが提供されます ワークフローの各手順に関する詳細については EMC VPLEX Management Console オンライン ヘルプを参照してください 次の表は アレイの検出からホストによってストレージが認識されるまでの実行すべき手順の概要を示しています ステップアクション 1 利用可能なストレージを検出する VPLEX Metro は バックエンド ポートに接続されたストレージ アレイを自動的に検出します クラスタ内の各ダイレクタに接続されたすべてのアレイが [Storage Arrays] ビューに一覧表示されます 2 ストレージ ボリュームを要求するストレージ ボリュームをクラスタで使用できるようになる前にボリュームを要求する必要があります ( 要求されないストレージ ボリュームから作成されるメタデータ ボリュームは除く ) ストレージ ボリュームが要求された後でのみ エクステント デバイス 仮想ボリュームの作成にこのボリュームを使用できるようになります 3 エクステントを作成する選択されたストレージ ボリューム用のエクステントを作成し 容量を指定します 4 エクステントからデバイスを作成するシンプル デバイスが 1 つのエクステントから作成され 1 つのクラスタのみでストレージを使用します 27
ステップ アクション 5 仮想ボリュームを作成する 前の手順で作成したデバイスを使用して仮想ボリュームを作成します 6 イニシエータを登録するイニシエータ ( ストレージにアクセスするホスト ) が直接またはファイバ チャネル ファブリックを介して接続されている場合 VPLEX Metro は 自動的にイニシエータを検出し [Initiators View] に表示します 検出されると イニシエータがストレージ ビューに追加され ストレージにアクセスする前に イニシエータを VPLEX Metro に登録する必要があります イニシエータを登録することにより ポートの WWN にわかりやすい名前 ( 通常はサーバの DNS 名 ) がつけられ 容易にホストを特定できるようになります 7 ストレージ ビューを作成するストレージからホストを認識できるようにするには まずストレージ ビューを作成してから VPLEX Metro フロントエンド ポートと仮想ボリュームをビューに追加します 仮想ボリュームが 関連するポートおよびイニシエータとともにストレージ ビューに表示されるまで 仮想ボリュームはホストによって認識されません [Create Storage View] ウィザードを使用して ストレージ ビューを作成し イニシエータ ポート 仮想ボリュームをビューに追加できます すべてのコンポーネントがビューに追加されると ビューが自動的にアクティブになります ストレージ ビューがアクティブになると ホストはストレージを認識して 仮想ボリュームへの I/O を開始できます ストレージ ビューを作成した後 GUIを介しては仮想ボリュームの追加または削除だけを実行することができます ポートおよびイニシエータを追加または削除するには CLIを使用してください 詳細については EMC VPLEX CLI Guide を参照してください VPLEX Metro のコマンドに関する包括的な情報については EMC VPLEX CLI Guide を参照してください 28
Microsoft Office SharePoint Server 2007 Microsoft SharePoint Server 2007 の概要 このセクションでは 以下のトピックについて説明します Microsoft SharePoint Server 2007 の構成 仮想化された SharePoint Server 2007 環境の検証 Microsoft SharePoint Server 2007 の構成 Microsoft SharePoint Server 2007 の構成に関する概要 SharePoint 環境を 仮想化された環境に移行するお客様が増えており 複雑なバックエンド ストレージをサポートした状態で複数のサイトにサーバ ファームが構築される場合があります この結果 次の 2 つの課題が生じます ファームの運用を中断させることなく どのようにして既存の SharePoint Server を異なるデータセンター間で移動させることができるのか どのようにしてストレージの保守コストを削減できるのか 仮想化された SharePoint Server 2007 を VPLEX Metro がサポートされている vsphere 4.0 上に構築することにより こうした課題が解決されます 複数のサイトに存在するさまざまなストレージ アレイが SharePoint 2007 ファームに対し 1 つの共有アレイをプロビジョニングすることができます Microsoft SharePoint Server 2007 の設計に関する考慮事項 この SharePoint 2007 環境の設計における 構成に関する主なハイライトとして 以下のものが含まれます SharePoint ファームは 1 つのサイトで 5 台の ESX サーバのうち 2 台を共有しており SQL および Oracle 環境を仮想化している バランス調整されたロードを介してクエリのパフォーマンスを向上させるために WFE(Web フロントエンド ) もクエリ サーバとして構成されている ( エンタープライズ レベルの SharePoint ファームに対して推奨 ) コンテキスト依存のネットワーク スイッチを使用することにより ユーザー リクエストのロードが 利用可能なすべての WFE 間で調整される 次のセクションでは 仮想化されたデータセンター向けの SharePoint Server 2007 アプリケーション アーキテクチャについて定義しています マルチサーバ SharePoint Server 2007 ファームは 次に示す 3 階層の Web アプリケーション アーキテクチャを使用します Web サーバ階層 : ユーザー リクエストを調整し Web コンテンツを提供します 29
アプリケーション階層 : 次を含む特定のリクエストに関するサービスを提供します Excel ドキュメント変換 一元管理 コンテント インデクシング データベース階層 : ドキュメントのコンテンツ SharePoint ファームの構成 検索データベースを管理します Microsoft SharePoint Server 2007 ファームの仮想マシンの構成 次の表は SharePoint Server 2007 ファームの仮想マシンの構成について説明しています 構成 3 つの WFE 仮想マシン 説明 このリソースは 仮想化された SharePoint ファームにおいて最も優れた検索のパフォーマンスと冗長性を提供します WFE とクエリは CPU を大量に消費するため WFE 仮想マシンには 4 つの仮想 CPU と 4 GB のメモリが割り当てられています クエリ ( 検索 ) ボリュームは 100 GB 仮想ディスクとして構成されています インデックス サーバ アプリケーションおよび Excel サーバ SQL Server インデックス サーバは 専用の WFE の役割とともに ポータル向けの唯一のインデクサとして構成されています つまり インデクス仮想マシンがコンテンツのクロールを実行している間 クロールするのにそれ自体を WFE として使用できます これにより ネットワーク トラフィックが最小限に抑えられるほか ユーザーがアドレス可能な WFE がインデクス ロードによる影響を受けている場合でも SharePoint ファームのパフォーマンスが損なわれないようにすることができます インデックス サーバには 4 つの仮想 CPU と 6 GB のメモリが割り当てられています インデックス プロセスはインデックス コンテンツをマージする必要があります したがって 2 倍のディスク容量が必要となります この結果 150 GB 仮想検索ディスクが割り当てられています アプリケーションおよび Excel サーバの役割は多くのリソースを必要としないため これらには 2 つの仮想 CPU と 2 GB のメモリが割り当てられています SharePoint ファームの SQL に関する CPU 使用率およびメモリに関する要件が高いため SQL Server 仮想マシンに対して 4 つの仮想 CPU と 16 GB のメモリが割り当てられています SQL 仮想マシンに多くのメモリが割り当てられるようになったため SQL Server は SharePoint ユーザー データのキャッシュをより効果的に行えるようになっています これにより ストレージに関する物理 IOPS が低下し パフォーマンスが向上します 30
仮想マシンの構成とリソースの割り当て 次の表は SharePoint Server ファームの仮想マシンの構成と割り当てられているリソースについて説明しています サーバの役割 個数 仮想 CPU の数 メモリ (GB) 起動ディスク (GB) WFE サーバ 3 4 4 40 100 検索ディスク (GB) インデックス サーバ アプリケーション サーバ Excel サーバ ( ホスト一元管理 ) 1 4 6 50 150 1 2 2 40 該当なし 1 2 2 40 該当なし SQL Server 2008 1 4 16 40 該当なし この仮想化環境における SharePoint 2007 インフラストラクチャ リソース割り当ての合計を次に示します 仮想 CPU:24 メモリ :38 GB 起動ディスク :290 GB 検索ディスク :450 GB 31
テスト アプローチ : SharePoint ファームのユーザー ロード プロファイル SharePoint にランダム ユーザー データを適用するのに KnowledgeLake DocLoaderLite が使用されました KnowledgeLake DocLoaderLite は Microsoft VSTS (Visual Studio Team System) がクライアント ユーザー ロードをエミュレートした状態で ロード プロファイルに基づいてドキュメントを取り込み コピーし SharePoint ファームのドキュメント ライブラリに配信しました 次の表は 仮想化された SharePoint ファームでのドキュメントの配信を示しています ドキュメントの種類 ドキュメントの数 ドキュメントの平均サイズ (KB) 割合.doc 289056 261.6 15.79%.docx 285902 110.3 15.62%.gif 90514 76.5 4.94%.jpg 71566 95.0 3.91%.mpp 287140 240.6 15.69%.pptx 269118 199.6 14.70%.vsd 262014 485.4 14.31%.xlsx 275172 27.0 15.03% 合計 1830482 187.0 100.00% Microsoft SharePoint 2007 サーバ ファームが 許容できる制限内で平均的な応答時間を確保しつつ 維持することのできる最大ユーザー数を確認するのに 検証時に Microsoft ヘビー ユーザー ロード プロファイルが使用されました Microsoft の基準では ヘビー ユーザーは 1 時間に 60 のリクエスト ( つまり 60 秒ごとに 1 つのリクエスト ) を実行することが示されています ( ユーザー ロードのガイドラインに関する詳細については 次の記事を参照してください : http://technet.microsoft.com/en-us/library/cc261795.aspx) このテストのユーザー プロファイルは 次の 3 つのユーザー オペレーションで構成されています 閲覧 (80%) 検索 (10%) 修正 (10%) 32
仮想化された SharePoint Server 2007 環境の検証 テストの概要 次のセクションでは VPLEX Metro クラスタへのカプセル化を実行する前および実行した後の SharePoint Server 2007 のオペレーションを検証することに加えて 実行時の VMotion のサイト間テストの検証も行います まず SharePoint 2007 ファームのベースとなるパフォーマンスを記録するため ベースライン テストが実行されます 次に SharePoint ファーム向けの CLARiX FLARE LUN が VPLEX Metro クラスタにカプセル化された後のパフォーマンス上の影響が テストにより検証されます 最大 100 km 離れたところにあるローカル サイト ( サイト A) とリモート サイト ( サイト B) 間で VMware VMotion のテストが実行されます テストによる検証の実行中 VSTS(Virtual Studio Team System) は WFE に対して継続的にワークロード ( たとえば ポータルおよびサブ サイトの閲覧 ドキュメントのランダム検索 ドキュメントのランダム置換 ) を生成します このオペレーションにより 各テスト セッションで WFE CPU 使用率がおよそ 80% に維持されます テスト実行中 SharePoint 2007 VPLEX Metro VMware のパフォーマンス データは分析用に記録されます このデータは VSTS 2008 からの結果に関する評価を提供します VSTS 2008 は SQL と Oracle OLTP ワークロードを同じ VMware vsphere 4.0 データセンターに同時に統合しつつ SharePoint 2007 ファームの WFE に継続的なワークロード ( 閲覧 / 検索 / 修正 ) を生成します VPLEX へのカプセル化を実行しない場合の検証 次のグラフは SharePoint 仮想マシン上の VPLEX LUN へのカプセル化を実行しなかった場合の 1 秒あたりの通過テストのベースライン パフォーマンスを示しています 80/10/10 の混在したユーザー プロファイルにより 仮想化された SharePoint ファームは 次の表に示すように Microsoft の許容できる応答時間に関する基準を満たしつつ 1% が同時実行する最大 107,400 のユーザーをサポートできます ユーザー アクティビティの割合 : 閲覧 / 検索 / 修正 許容できる応答時間 ( 秒 ) ベースライン応答時間 ( 秒 ) 80/10/10 <3/<3/<5 2.41/1.79/1.48 33
コンテンツの混在 : 閲覧 / 検索 / 修正 RPS (1 秒あたりのリクエスト数 ) Microsoft ユーザー プロファイル 同時実行の割合 (%) 最大ユーザー数 80/10/10 17.4 ヘビー 1 107,400 ローカル サイトとリモート サイト間で実行している VMotion による検証 このホワイト ペーパーでは SharePoint 2007 ファームに対して VSTS ワークロードを実行している場合の ローカル サイトおよびリモート サイトにおける VMware VMotion のインパクトを検証します VMotion は VMware vcenter Server から起動できます VMotion を介して WFE インデックス SQL Server を サイト A からサイト B に またはサイト B からサイト A に移行できます サイト間で VMotion を実行している間の一秒あたりのトランザクション数は変動します これは サイト A からサイト B への移行を実行している間 サイト B の比較的負荷の軽いワークロードにより 一時的にファームの応答時間 ( 閲覧 / 検索 / 修正 ) が速くなり 1 秒あたりの通過テストが増加するためです 仮想マシンを元のホストに戻している間 元のホストのワークロードが一時的に増加する場合があります したがって VMotion の移行プロセス中の応答時間と 1 秒あたりの通過テストは変動し 1 秒あたりの通過テストに若干の影響が出ることがあります これを比較するために RPS と平均的なファーム オペレーションの応答時間を示した前の表を参照してください ただし VMotion は 次のグラフで示すとおり 実行中のアプリケーションを中断することはなく データセンターに対し サイト間でリソースを手動で再配置できる機能を提供します 次の表は サイト A とサイト B 間で VMotion を実行している場合のテスト結果を示しています ユーザー アクティビティの割合 : 閲覧 / 検索 / 修正 許容できる応答時間 ( 秒 ) VMotion 実行時の平均応答時間 ( 秒 ) 80/10/10 <3/<3/<5 2.38/1.47/1.00 34
コンテンツの混在 : 閲覧 / 検索 / 修正 RPS (1 秒あたりのリクエスト数 ) Microsoft ユーザー プロファイル 同時実行の割合 (%) 最大ユーザー数 80/10/10 18.6 ヘビー 1 111,600 サイト間 VMotion の検証 このホワイト ペーパーでは 仮想化された VPLEX Metro LUN における長距離サイト VMotion を検証します サイト間 VMotion のテスト検証には 距離に関するレイテンシーが含まれていません 同じ SharePoint クライアント ワークロードが使用され テスト実行時に SharePoint ファーム サーバの役割に対して VMotion が起動されました VMotion は 基盤となる VMware ESX システムにまたがる形で 仮想マシンの実行中のアーキテクチャの状態を移行します これにより VMotion の実行中に 仮想マシンの実行中の状態に影響が出ます 2 つのデータセンター間の距離が 100 km の場合 すべてのサーバの役割において より長いサイト間 VMotion が引き起こされます この影響は 仮想マシンに割り当てられているリソースに比例します たとえば 距離に関するレイテンシーがある WFE 向けの平均的な VMotion 実行時間は レイテンシーがない場合よりも 34 秒長くなります 一方で WFE よりも大容量のメモリ構成 (6 GB) のインデックス サーバは VMotion を完了するのに 5~6 秒多くの時間を必要とします さらに ファーム内で最大数のデータベース アクティビティと最大のメモリ構成 (16 GB) を有する SharePoint SQL Server は レイテンシーのない場合に比べて ほぼ 3 倍の VMotion 実行時間を必要とします 次の表は SharePoint ファーム サーバの役割に関する レイテンシーがある場合とない場合の VMotion の実行時間を示しています SharePoint ファーム サーバの役割 距離のレイテンシーがない場合の VMotion の実行時間 ( 秒 ) 100 km 離れている場合の VMotion の実行時間 ( 秒 ) WFE 39 73 インデックス サーバ 37 78 SPS SQL Server 90 217 35
Microsoft SQL Server 2008 Microsoft SQL Server 2008 の概要 このセクションでは 以下のトピックについて説明します Microsoft SQL Server 2008 の構成 仮想化された SQL Server 2008 環境の検証 Microsoft SQL Server 2008 の構成 設計に関する考慮事項 SQL Server のテスト構成は 次のプロファイルをベースとしています サポートされている SQL ユーザーの数 :40,000 同時実行率 1% とシンク タイム ゼロでシミュレーションされたユーザー ワークロード これは Microsoft のテスト手法と一貫性がある ユーザー データ :1 TB SQL Server テスト アプリケーション この環境で使用される SQL ロード テスト ツールは OLTP ワークロードのシミュレーションを実行します このツールは 複雑な OLTP アプリケーション環境を代表する方法でシステム機能を実行するよう設計されたトランザクション オペレーションで構成されています OLTP ワークロード このテスト環境でユーザー ロードの生成に使用される OLTP アプリケーションは TPC-E(TPC Benchmark-E) 規格に基づいています TPC-E テストは 処理アクティビティを表すトランザクションのセットで構成されています データベース スキーマ データ ポピュレーション トランザクション 実装ルールは 最新の OLTP システムを広く表すよう設計されています TPC-E アプリケーションは 次の項目を実行する証券会社のアクティビティをモデル化します 顧客アカウントの管理 顧客の取引オーダーの実行 金融市場における顧客のアクティビティの管理 SQL Server のテストの主なコンポーネント このベンチマークは 市場データ 顧客データ ブローカー データを表す 3 つのデータベース テーブル セットに対して実行されるトランザクション セットで構成されます 4 つ目のテーブル セットには 郵便番号などの一般的な大きさのデータが含まれます 36
SQL データベース パーティション設定 データを より小さく そして管理しやすいセクションに分割するのに SQL テーブル パーティション設定が使用されます テーブル パーティション設定により 並列オペレーションを通じて パフォーマンスの向上を実現できます 極めて大きなデータセット ( たとえば 数百万の行 ) に対して大規模なアプリケーションを実行する場合 個別のサブセットに対して並行して複数のオペレーションを実行することで パフォーマンス上のメリットがもたらされます I/O 競合を効果的に削減するため 個別のサブセットを複数のディスク ドライブに移動させることができます 割り当てるテーブル パーティションの数は 次の項目に依存します テーブルのサイズ LUN の使用率 このアプリケーションの証券会社および顧客のファイル グループは パーティション設定を実行するのに 最も大きくて最適な候補です 証券会社および顧客ファイル グループのパーティション設定 証券会社および顧客ファイル グループはそれぞれ 11 のパーティションに分割されます 各パーティションは 個別の LUN 上の VMDK ファイルに格納されます 最初の 10 のパーティションは 最初のデータ ポピュレーション時に生成されたデータを保持します 11 番目のパーティションは シミュレートされた新しいユーザー アクティビティの実行時に生成された新しいデータを保持します 証券会社および顧客ファイル グループ 次の表は テスト アプリケーションで使用されるファイル グループの詳細を示しています ファイル グループ名 broker_fg1-10 テーブル名 CASH_TRANSACTION SETTLEMENT TRADE TRADE_HISTORY ドライブ ( マウント ポイントが設定されたディレクトリ ) S:\B\B1-B10 customer_fg1-10 broker_fg customer_fg HOLDING HOLDING_HISTORY CHARGE COMMISSION_RATE TRADE_TYPE TRADE_REQUEST BROKER ACCOUNT_PERMISSION CUSTOMER CUSTOMER_ACCOUNT CUSTOMER_TAXRATE HOLDING_SUMMARY S:\C\C1-C4 S:\B\B0 S:\C\C0 37
ファイル グループ名 market_fg misc_fg テーブル名 EXCHANGE INDUSTRY SECTOR STATUS_TYPE COMPANY COMPANY_COMPETITOR DAILY_MARKET FINANCIAL LAST_TRADE NEWS_ITEM NEWS_XREF SECURITY WATCH_ITEM WATCH_LIST TAXRATE ZIP_CODE ADDRESS ドライブ ( マウント ポイントが設定されたディレクトリ ) S:\TPCE_ROOT S:\TPCE_ROOT Tempdb 適用不可 G:\, H:\, I:\, J:\ Transaction Log 適用不可 T:\ 38
仮想化された SQL Server 2008 環境の検証 テストの概要 Microsoft TPCE ベンチマーク キットを使用して OLTP データベースにデータが適用されました また検証テスト中に ユーザー ロードのシミュレーションを実行するのにもこのベンチマーク キットが使用されました SQL Server 2008 OLTP 環境で次のテスト シナリオが実行されました この後のテストに関する比較ポイントを確立するためにベースライン テストが実施された VPLEX Metro > VPLEX Metro DR1 への移行 : ホスト アクセスの停止が発生する で説明された方法を使用して アプリケーション ストレージが DR1 構成にカプセル化された ユーザー ワークロードが SQL Server OLTP アプリケーション SharePoint Server 2007 Oracle アプリケーションに対して生成されている状態で アプリケーション可用性テストが実施された カプセル化前の検証 各サイトで 1 つずつ 合計 2 つのインスタンスで SQL Server OLTP アプリケーションが実行しています SQL Server インスタンスは VMware ESX サーバ上のゲスト ホストで実行しています 両方のインスタンスは VMware ESX サーバに接続された CLARiX ストレージを使用しています さらに両方のインスタンスは 同じ方法で実行されます SQL Server OLTP アプリケーションは データ アクセス パターンが均等でないことを示しています 一部の LUN が頻繁に使用されますが それ以外の LUN はあまり使用されませんでした 次の表は 検証テスト中に最も頻繁に使用されたストレージ デバイスのパフォーマンスを表しています LUN IOPS レイテンシー Broker\B10 569.9 9 ミリ秒 Broker\B2 712.6 8 ミリ秒 Broker\B6 719.3 6 ミリ秒 Broker\B1 714.7 5 ミリ秒 Broker\B8 714.7 5 ミリ秒 カプセル化後の検証 SQL Server のストレージがカプセル化および仮想化されました ストレージが 2 つのサイト間で DR1 構成に変換され VPLEX Metro を介して SQL Server で利用できるようになりました その後 ストレージ パフォーマンスへの影響を監視するため 以前と同じロードを使用して OLTP アプリケーションが再起動されました 次の表は 検証テスト中に最も頻繁に使用されたストレージ デバイスのパフォーマンスを表しています 39
カプセル化前 カプセル化後 LUN IOPS レイテンシー IOPS レイテンシー Broker\B0 569.9 9 ミリ秒 550.0 10 ミリ秒 Broker\B1 712.6 8 ミリ秒 683.5 9 ミリ秒 Broker\B2 719.3 6 ミリ秒 689.5 7 ミリ秒 Broker\B3 714.7 5 ミリ秒 712.5 5 ミリ秒 Broker\B4 714.7 5 ミリ秒 712.5 5 ミリ秒 最も頻繁に使用される LUN は 平均的なレイテンシーがわずかに増加するほか IOPS がわずかに減少しました サイト間 VMotion の検証 VPLEX Metro を介してストレージにアクセスされると 長距離 VMotion が検証されます 各 SQL Server OLTP アプリケーションのストレージは DR1 デバイスとして構成されています データのコピーが VPLEX Metro の両方のサイトに存在します この検証テストでは SQL Server アプリケーションをホストしているゲスト仮想マシンが ロード実行中にサイト間で VMotion を介して移行されました 他のアプリケーションからもワークロードが生成されました 両方のサイトでデータのコピーが利用できるため 次の表に示された時間は 16 GB のメモリを使用して 実行中のアプリケーションが 1 台の VMware ESX サーバからもう一方のサイトのサーバに移行するのにかかる時間を表しています 移行の実行中でも OLTP アプリケーションは利用可能です 距離のシミュレーション VMotion の実行時間 0 km 3 分 57 秒 100 km 5 分 17 秒 40
SAP SAP の概要 このセクションでは 以下のトピックについて説明します SAP の構成 仮想化された SAP 環境の検証 SAP の構成 SAP ERP 6.0 SAP ECC6(ERP 2005) は あらゆる業界およびマーケット セクターで中堅企業および大企業のコアとなるビジネス ニーズを満たす 完全に統合された世界最高クラスのソリューションです SAP NetWeaver テクノロジー プラットフォームによって実現される SAP ERP 6.0 により 企業は 分析 企業サービス エンド ユーザー サービスの提供向けの機能によってサポートされる 財務分析 人材管理 調達 / 物流 製品開発と製造 セールス / サービスを実行することが可能になります SAP ERP 6.0 は SAP NetWeaver およびエンタープライズ サービスのリポジトリと組み合わせて活用することで 継続的な拡張 技術革新 優れたオペレーションをサポートする 堅牢なビジネス プロセス プラットフォームとして機能することができます SAP BW 7.0 SAP BI としても知られる SAP NetWeaver BW(SAP NetWeaver Business Warehouse) は BI( ビジネス インテリジェンス ) 分析レポート データ ウェアハウジング ソリューションです このソリューションは SAP NetWeaver テクノロジーに含まれており ビジネス オペレーションをサポートするためにエンタープライズ SAP ランドスケープの他の SAP アプリケーションと緊密に統合されます ビジネス シナリオ VPLEX Metro により アプリケーション向けの仮想化ストレージが データセンター サイト間の LUN にアクセスできるようになるほか データセンター間で仮想マシンを移動させる機能が提供されます これにより データセンターのリソースが最適化され データセンターの移転およびサーバの保守に伴うダウンタイムがゼロになります SAP アプリケーションとモジュールを複数の仮想サーバに分散でき 標準のオペレーションに こうしたアプリケーションとモジュール間の広範囲に及ぶ通信が含まれるため 個別の仮想マシンをサイト間で移動するときに 通信が中断されないことが重要となります サイト間で仮想マシンを無停止で移動できる VPLEX Metro の機能を示すため SAP ERP から SAP BI にデータを転送するよう SAP BW 抽出プロセスが構成されました 抽出プロセスの実行中 サイト間で SAP ERP インスタンス (DB と CI を含む ) の移動が実行されました テストにより 移動中も抽出プロセスが中断されないこと オペレーションのパフォーマンス全体にほとんど影響を及ぼさないことが明らかとなっています 41
設計に関する考慮事項 次の図は SAP 向け論理ランドスケープの構成を示しています 以下の表に 仮想マシン リソースの割り当てを示します 仮想マシン 仮想 CPU の数 メモリ (GB) SAP ERP DB 4 16 SAP ERP CI 4 16 SAP BI DB 4 16 SAP BI CI 4 16 SAP セットアップには 次の設計に関する考慮事項が反映されています SAP ランドスケープは 分散環境として構成され 100 km 離れた各サイトに 1 つのクラスタ ( 合計 2 つ ) を導入した ERP および BI アプリケーションで構成されます ERP DB および CI をホストする 4 つの仮想マシンと BI DB/CI インスタンスが 各データセンターの 2 台の ESX サーバで実行しています SAP ERP および SAP BI は 分散システムとしてインストールされています つまり CI および DB は 異なる仮想マシン上で実行しています /sapmnt/<sid> と /usr/sap/trans はグローバルにアクセス可能にする必要があることに注意してください この場合 仮想マシンを起動したときに 両方のディレクトリが NFS に構成され マウントされます 42
VPLEX Metro の管理下で共有 VMFS ボリュームを使用するよう すべての SAP ホストが構成されています VMFS ボリュームの仮想マシンのディスクは 両方のクラスタからアクセス可能です 両方のデータセンターの仮想マシンは 共有リソース プールを持つクラスタに構成されています 次の表は 使用されるマウント ポイントについて示しています マウント ポイントアクセス性 RAID タイプ容量 SAP ERP <RED> /sapmnt/red グローバル RAID-5 10 GB /usr/sap/red ローカル RAID-5 8 GB /usr/sap/trans グローバル RAID-5 10 GB /db2/red ローカル RAID-5 10 GB /db2/red/sapdata1 ローカル RAID-5 82 GB /db2/red/sapdata2 ローカル RAID-5 82 GB /db2/red/sapdata3 ローカル RAID-5 82 GB /db2/red/sapdata4 ローカル RAID-5 82 GB /db2/red/saptemp1 ローカル RAID-5 1 GB /db2/red/log_dir ローカル RAID-1/0 15 GB /db2/red/log_archive ローカル RAID-5 15 GB SAP BI <RBD> /sapmnt/rbd グローバル RAID-5 10 GB /usr/sap/rbd ローカル RAID-5 8 GB /usr/sap/trans グローバル RAID-5 10 GB /db2/rbd ローカル RAID-5 10 GB /db2/rbd/sapdata1 ローカル RAID-5 82 GB /db2/rbd/sapdata2 ローカル RAID-5 82 GB /db2/rbd/sapdata3 ローカル RAID-5 82 GB /db2/rbd/sapdata4 ローカル RAID-5 82 GB /db2/rbd/saptemp1 ローカル RAID-5 2 GB /db2/rbd/log_dir ローカル RAID-1/0 15 GB /db2/rbd/log_archive ローカル RAID-5 40 GB 43
仮想化された SAP 環境の検証 テストの目的 このテストの目的は次のとおりです VMotion と VPLEX Metro によって実現する データセンター間での SAP DB および CI インスタンスの無停止での移動を検証する データセンター間の仮想ストレージへの SAP アクセスを検証する テスト シナリオ テスト シナリオとして BW 抽出が選択されました ERP システムから 150 万個のレコードが BI システムのデータ ソースの PSA(Persistent Staging Area) に抽出されました このシナリオの意図は VMotion におけるビジネス継続性と連携ソリューション ランドスケープを適切な抽出プロセスによって検証できるよう 抽出時の BI と ERP 間のアクティブな接続を確保することにあります 注 SAP システムのパフォーマンスがこのシナリオの主な目的ではないため システムはテスト シナリオ用に最適化されませんでした テスト手順 このテストは 次の表に示す手順に従って実施されました ステップ アクション 1 BW 抽出は SAP BI インスタンス (DB と CI) が 1 つのデータセンターに存在し SAP ERP インスタンス (DB と CI) が他のデータセンターに存在している状態で開始されました 2 BW 抽出が開始されました 抽出プロセスの実行中 ERP DB および ERP CI インスタンスへの VMotion の移行が順次実行されました 3 BW 抽出は SAP ERP インスタンス (DB と CI) と SAP BI インスタンス (DB と CI) が同じデータセンターに存在している状態で開始されました 44
テストの結果 次の表に テストの詳細な統計情報を示します シナリオ転送されたレコード抽出時間 ( 分 : 秒 ) VMotion の実行時間 ( 分 : 秒 ) SAP ERP と SAP BI が 2 つのデータセンターに分散している 15,800,009 7:02 - SAP ERP が SAP BI の存在する同じデータセンターに移動する 15,800,009 7:35 01:53*(SAP ERP DB) 00:52(SAP ERP CI) SAP ERP と SAP BI が両方とも同じデータセンターに存在する 15,800,009 7:02 - * SAP ERP DB と SAP ERP CI は 異なるデータ ストアを持つよう構成されるため 利用可能なネットワーク帯域幅と FC 接続性に応じて この 2 つのインスタンスで vmotion がサイト間で移行を実行する時間は異なります この検証テストは 次の項目を示します SAP 連携ランドスケープの 2 つの相互依存 SAP アプリケーション間の接続は VPLEX Metro によって促進される VMotion オペレーションの実行中および完了後も中断されることはない SAP アプリケーションは データセンター間の障壁を越えて VPLEX Metro で管理されるストレージにアクセスできる VMotion オペレーションが既存プロセスに与える影響は最小限に抑えられる 45
Oracle Oracle の概要 Oracle E-Business Suite 12.1 は 業界および地域を問わずあらゆる規模の組織に対して 迅速なメリットを実現するソリューション ポートフォリオ 統合されたビジネス プロセス 業界にフォーカスしたソリューションを介して コストの削減と生産性の向上を実現するグローバルなビジネス基盤を提供します このセクションでは 以下のトピックについて説明します Oracle の構成 仮想化された Oracle 環境の検証 Oracle の構成 Oracle E-Business Suite 環境の構成 次の図は このソリューションの Oracle の構成を示しています 46
設計に関する考慮事項 Oracle E-Business Suite のインストールは ビジネス継続性の基盤を実証することにフォーカスしています 高可用性については対応していませんが 仮想化のメリットを強調しています 特に 完全な高可用性を実現した本番環境において 次に示す単一点障害に対処する必要があります シングル インスタンスの RDBMS(Relational Database Management System) は マルチノードの RAC(Real Application Cluster) です NFS サーバはマルチノード クラスタです Apache ソフトウェアによって提供されるロード バランシング機能は ハードウェア ロード バランサーのクラスタ化されたペアです 次の表は このソリューションで使用される Oracle E-Business Suite インフラストラクチャ サーバの構成を示します コンポーネント オペレーティング システム カーネル CPU メモリ ディスク構成 Apache サーバ ( ロード バランサー ) 説明 Red Hat Enterprise Linux 5(64 ビット ) リリース 5.3 2.6.18-128.el5 #1 SMP 仮想 CPU 2 4,096 MB ルート 80 GB 仮想ディスク 150 GB がマップされた raw LUN 2 この LUN を組み合わせて 300 GB の /u01/apps ファイル システムが形成される これは 他のすべての Oracle E-Business Suite サーバに共有される Apache/2.2.3(Red Hat) http://g2svoebsinfra01.g2sv.emc.com/ 47
Oracle E-Business Suite データベース サーバ 次の表は このソリューションで使用される Oracle E-Business Suite データベース サーバを保持する仮想マシンの構成を示します コンポーネント 説明 オペレーティング システム カーネル CPU メモリ ディスク構成 Oracle データベースのバージョン Oracle アプリケーションのバージョン Oracle E-Business Active Tier のコンポーネント Red Hat Enterprise Linux 5(64 ビット ) リリース 5.3 2.6.18-128.el5 #1 SMP 仮想 CPU 2 4,096 MB ルート 80 GB 仮想ディスク Oracle HOME および DB ファイル :500 GB/u01 Oracle REDO 1:50 GB/u02 Oracle REDO 2:50 GB/u03 共有 APPL_TOP:/u01/apps として G2SVOEBSINFRA01.g2sv.emc.com:/u01/apps からの 300 GB NFS マウント Oracle Database 11g Enterprise Edition リリース 11.1.0.7.0: パーティション設定 OLAP データ マイニング リアル アプリケーションのテスト オプションを含む 64 ビット本番バージョン 12.1.1 データベース 並列処理 フォーム : これが DB ノードとなるため ロード バランサーにはフォームは含まれない したがって エンド ユーザーはアクセスできない Web: これが DB ノードとなるため ロード バランサーには Web は含まれない したがって エンド ユーザーはアクセスできない IAS のバージョン 10.1.3.4.0 Oracle E-Business Suite Vision Demo Database の標準インストールから単一マウント ポイント /u01 に至るまで インストール後に行われた変更は セッションの増加 (4000) とプロセスの増加 (2000) だけでした オンライン REDO ログも /u02 と /03 に移動しました それぞれに 2 つのメンバーを持つ 9 つのログ グループが作成され 1 つのメンバーは /u02 に もう 1 つのメンバーは /u03 に設定されました 作成された各ログ ファイルの容量は 300 MB でした 48
Oracle E-Business Suite アプリケーション サーバ 1 と 2 次の表は このソリューションで使用される Oracle E-Business Suite アプリケーション サーバ 1 と 2 向けの仮想マシンの構成を示します コンポーネント オペレーティング システム 説明 Red Hat Enterprise Linux 5(64 ビット ) リリース 5.3 カーネル CPU メモリ ディスク構成 Oracle アプリケーションのバージョン Oracle E-Business Active Tier のコンポーネント 2.6.18-128.el5 #1 SMP 仮想 CPU 2 4,096 MB ルート 80 GB 仮想ディスク 共有 APPL_TOP:/u01/apps として G2SVOEBSINFRA01.g2sv.emc.com:/u01/apps からの 300 GB NFS マウント 12.1.1 フォーム Web IAS のバージョン 10.1.3.4.0 Oracle E-Business Suite インフラストラクチャ サーバ このサーバは 他の Oracle E-business Suite サーバそれぞれに対し NFS を介した共有 APPL_TOP ファイル システムを提供します また ソフトウェア ベースのネットワーク ロード バランサーの機能も実行します 49
仮想化された Oracle 環境の検証 チューニング テストとベースライン テスト 次のテストが実施されました 可用性テスト チューニング テスト 可用性テスト OATS(Oracle Application Testing Suite) サーバ ( バージョン 9.01.0165) が仮想マシンにインストール / 構成されました このサーバは テスト環境外で実行し Microsoft Windows Server 2003 R2 Enterprise Edition Service Pack 2 を使用しており 2 つの仮想 CPU と 4 GB の RAM を提供します OpenScript を使用して Oracle E-Business Suite にログインし General Ledger ジャーナルに対してクエリーを実行し T-Accounts を使用してジャーナルをレビューしたスクリプトが記録されました その後でこのスクリプトはログオフしました このスクリプトは General Ledger ジャーナルのクエリを繰り返し 起動時にログインをレビューして実行のみを行い 最後にログアウトするよう修正されました 2 つのスクリプトが作成されています 1 つは Oracle Application Server ミッドティア 1 向けであり もう 1 つは Oracle Application Server ミッドティア 2 向けです Oracle Load Testing for Web Applications を使用して 2 つのテスト スクリプトそれぞれが 10 の仮想ユーザーを増やすよう許可されました この結果 20 のユーザーのロードが提供され それは 1 つのミッドティアにつき 10 のユーザーというように均等に配分されました このロードの目的は テストのパフォーマンスではなく VMware VMotion および Storage VMotion を使用した移行を実行中でも ユーザーの操作性が変わらないことを確認することでした このテストは 移行中すべての仮想ユーザーがエラー無しで継続的に操作を行えた場合 成功したと見なされます チューニング テスト変更を実行する前の元の構成の基準を明確にする目的で 広範囲に及ぶデータベース I/O を実行するための 時間のかかるコンカレント プログラムが選択されました このコンカレント プログラム Gather Schema Statistics は データベース仮想マシン上で稼働し テスト インフラストラクチャでこのレベルの要求を満たす データベース全体で実行するための優れた候補となります このコンカレント プログラムは 次のコマンド ラインからサブミットされました $FND_TOP/bin/CONCSUB Apps/Apps SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND FNDGSCST ALL 10 '""' NOBACKUP '""' LASTRUN GATHER '""' Y このコンカレント プログラムが完了するまでの時間がベースラインとして記録され 次に示す各テストとの比較材料として使用されます コンカレント プログラムの実行中 ディスク CPU ネットワークも VSphere Client ツールを使用して記録されました 50
ベースライン テスト 20 の仮想ユーザーの Web アプリケーション向けのベースライン Oracle Application Testing Suite Load Testing が実行されました これにより 次のグラフに示すとおり ベースライン テストの実行中 1~3 秒の安定した応答時間が得られました vstorage への RDM (Raw Device Mapping) のカプセル化 VPLEX Metro にボリュームをカプセル化した後 20 の仮想ユーザーの Web アプリケーション向けのベースライン Oracle Application Testing Suite Load Testing が再度実行されました 仮想ユーザーが体感する応答速度は ほぼ例外なく 1~3 秒に収まり 先ほどのテストと同じ結果になります 平均の応答速度は 1.43 秒まで低下しています 次のグラフで応答速度を確認できます 51
VMotion 移行テスト 次に実行されたテストでは サイト A からサイト B にすべての仮想マシンを移行しました このテストは OATS で 20 の仮想ユーザーを開始してから約 25 分後に行われました 仮想ユーザーに対する影響は 移行中および移行後も認められませんでした テスト サイクルに要した 25 分から 40 分のうち 各移行にかかった時間は 5 分以内でした 次のグラフで応答速度を確認できます 強調表示された領域は VMotion の移行期間を示しています テスト全体の平均の応答時間は 1.56 秒で 移行期間における平均の応答時間は 1.62 秒でした 移行時間を次の表で確認できます 仮想マシン VMotion の開始 VMotion の完了 時間 ( 分 : 秒 ) APPS-01 05:28:45 05:32:21 03:36 APPS-02 05:32:21 05:35:59 03:38 INFRA01 05:35:59 05:39:37 03:38 DB10 05:39:37 05:43:29 03:52 52
FC に関する 100 km の距離のシミュレーション 次のテスト セットでは 100 km 離れている 2 つの VPLEX Metro のシミュレーションを実行しています 20 の仮想ユーザーの Web アプリケーション向けのベースライン Oracle Application Testing Suite Load Testing が再度実行されました このテストにより 次のグラフに示すとおり ベースライン テストの実行中 1~3 秒の応答時間が得られ 平均応答時間は 1.48 秒でした このベースライン テストの完了後 20 の仮想ユーザーの Web アプリケーション向けのベースライン Oracle Application Testing Suite Load Testing の負荷がかかった状態で VMotion を使用してすべての仮想マシンがサイト A からサイト B に移行されました このテストの実行中 1~3 秒の安定した応答時間が得られました 次のグラフに示したとおり テスト全体の平均の応答時間は 1.59 秒で 移行期間における平均の応答時間は 1.83 秒でした 強調表示された領域は VMotion の移行期間を示しています 移行時間を次の表で確認できます 53
仮想マシン VMotion の開始 VMotion の完了 時間 ( 分 : 秒 ) DB-01 07:33:55 07:38:24 00:04:29 APPS-01 07:38:39 07:42:32 00:03:53 INFRA-01 07:42:32 07:46:30 00:03:58 APPS-02 07:46:30 07:50:32 00:04:02 予想したとおり ネットワークのレイテンシーが 1 ms 増加することで VMotion を使用して各仮想マシンを移行するのに要する時間が若干延びています 移行期間中 トランザクションの平均応答時間も増加しますが 許容できる範囲に収まっています バッチ プロセス テスト 環境に変更を加える前に データベース内のすべてのスキーマの統計情報を収集するのにどのくらいの時間がかかるのかを確認するため ベースラインが取得されました このテストは 13:39:15 から 19:26:10 まで (5 時間 46 分 55 秒 ) 実行されました カプセル化およびサイト A からサイト B への移行の後 このテストは 合計 4 時間 52 分 52 秒かかりました 次の表にバッチ ラン時間が示されています テスト名開始時間終了時間時間 VMotion ベースライン 13:39:15 19:26:10 5:46:55 - カプセル化後 12:07:33 16:24:02 4:16:29 - 標準の VMotion 実行 100 km ベースライン 100 km レイテンシー : VMotion 10:46:43 15:39:35 04:52:52 03:28 18:22:05 23:46:17 05:24:12-08:23:47 13:49:55 5:26:08 04:29 サイト A からサイト B へのライブ移行の実行中または移行の実行後も バッチ プロセスで障害は発生しませんでした さらにこのプロセスはバッチ プロセスを認識しませんでした バッチ プロセスはデータベースと同じ仮想マシンで実行され 標準的な実行においてネットワーク レイテンシーは要素として考慮されませんでした したがって ベースライン バッチ プロセスは ネットワーク レイテンシーの影響についてはテストされていません バッチの実行中 大きなネットワーク レイテンシーにより VMotion での移行時間が 4 分 29 秒長くなることが確認されています 54
結論 要約 今日のオンデマンドの 24 時間 365 日の運用によって生じるビジネス課題を解決するには データの高可用性を確保し 企業にとって適切な場所 時間 コストでデータを利用できるようにする必要があります このソリューションは VMware vsphere 4 SAP Microsoft SharePoint Server 2007 SQL Server 2008 Oracle E-Business Suite Release 12 を使用した仮想化されたアプリケーション環境における VPLEX Metro の新しい仮想ストレージ機能を示しています EMC VPLEX Metro により 企業は 次の項目を実現することで それぞれの仮想ストレージ環境をより効果的に管理することができます 既存のアプリケーションおよびインフラストラクチャとの透過的な統合 サービスを停止させることなく リモート データセンター間でデータを移動させる機能 予定されていないアプリケーションの停止が発生した場合の保護機能の向上 保守およびテクノロジー更新オペレーションを行うためにストレージ アレイ間でデータ ストアを無停止で移動させる機能 結論 このソリューションでは VMware の VMotion テクノロジーを使用することで ワークロードを移行できるよう 100 km 離れた場所にある複数のデータセンター サイトに展開している ESX サーバに LUN を提供することに対する VPLEX Metro の有効性を検証しました アプリケーション セクションで詳細に説明したように 仮想マシンの移行時間はすべて許容範囲に収まっており すべてのケースで 移行中にユーザー アクセスが遮断されてしまう事態は発生しませんでした 分散されたミラー ボリュームを使用して 同じデータを両方のサイトに保持し キャッシュの一貫性を確保しました テストの結果 100 km 離れた距離において 予想される許容範囲内に収まったことが検証されています このテストの結果 エンド ユーザーに対して影響を与えることなく サイト A からサイト B への仮想マシンのライブ移行を迅速に実行できることが証明されました このテストで示された VPLEX Metro の機能は 運用およびビジネスに関する要件をサポートするため 大都市圏のデータセンター間における真の意味での動的なワークロード バランシングと移行を実現できることを示しています VPLEX Metro は 本当の意味での拡張性を備えた動的な仮想データセンターを提供するため ストレージの柔軟性を備えた VMware vsphere により サーバ インフラストラクチャにおける柔軟性を向上させます 次の手順 このソリューションおよび他のソリューションに関する詳細については EMC 担当営業までお問い合わせいただくか 次のサイトにアクセスしてください http://japan.emc.com/ 55
関連資料 ホワイト ペーパー 関連情報については 次のホワイト ペーパーを参照してください EMC Virtual Infrastructure for Microsoft Applications Data Center Solution Enabled by EMC SymmetrixVMAX and VMware vsphere 4 - Applied Technology 製品ドキュメント 関連情報については 次の製品ドキュメントを参照してください EMC サポート マトリックス EMC VPLEX CLI Guide EMC VPLEX Installation and Setup Guide EMC VPLEX Management Console オンライン ヘルプ その他のドキュメント 関連情報については 次のドキュメントを参照してください Vblock Infrastructure Packages Reference Architecture Master Guide:SAP ERP 6.0 - Support Release 3 Installation Guide SAP ERP 6.0 - EHP4 Ready ABAP on Linux:IBM DB2 for Linux, UNIX, and Windows Based on SAP NetWeaver 7.0 Including Enhancement Package 1 Using Load-Balancers with Oracle E-Business Suite Release 12 VMware VMotion と CPU の互換性については 次のドキュメントを参照してください VMware ホワイト ペーパー :VMware インフラストラクチャにおける SAP ソリューションのベスト プラクティス ガイドライン 56