EMCによるSAPのミッションクリティカルなビジネス継続性

Presentation on theme: "EMCによるSAPのミッションクリティカルなビジネス継続性"— Presentation transcript:

1 EMCによるSAPのミッションクリティカルなビジネス継続性
プレゼンターへのメモ： このプレゼンテーションは、ホワイト ペーパー 「EMCによるSAPのミッシ ョン クリティカルなビジネス継続性：EMC VPLEX、Symmetrix VMAX、VNX、VMware vSphere HA、Brocade Networking、Oracle RAC、SUSE Linux Enterprise」で説明されているソリュー ションをサポートするものです。 このプレゼンテーションは、24時間365日稼動するミッション ク リティカルなSAPアプリケーションの設計、構築、管理に携わるSAP Basis管理者、Oracle DBA（ データベース管理者）、ストレージ管理者、ITアーキテクト、技術管理者を対象としています。 _______________________________________________________ ようこそ。 本日は、SAPアプリケーションのミッション クリティカルなビジネス継続性に対応するEMCソリューションについて説明します。 このコンポーネントのリストからおわかりのように、このソリューションは、EMC、VMware、Brocade、Oracle、SUSEのテクノロジを組み合わせたもので、 SAP ERPアプリケーション プラットフォーム向けに設計されています。 EMC VPLEX、EMC Symmetrix VMAX、EMC VNX、VMware vSphere HA、Brocade Networking、Oracle RAC、SUSE Linux Enterprise EMCソリューション グループ

2 アジェンダ ソリューションの概要とアーキテクチャ ソリューションのコンポーネントと構成 テストおよび検証 まとめ
EMC VPLEX Metro VMware vSphere SAPシステムのアーキテクチャ Oracleデータベース Brocadeネットワーク EMCストレージ テストおよび検証 まとめ このプレゼンテーションは、わかりやすい構成になっています。 まず、このソリューションの概要を紹介します。このソリューションが対応する課題やその方法も説明します。 次に、このソリューションの全体的なアーキテクチャを確認します。 続いて、このソリューションを実現するテクノロジとその構成方法について、順を追って説明します。 次に、このソリューションを検証するためにEMCが実施したテストの概要を説明します。 最後に、このプレゼンテーションのポイントのまとめと、このソリューションがビジネスにもたらすメリットを紹介します。

3 EMCによるSAPのミッション クリティカルなビジネス継続性
環境内のすべてのレイヤーで単一障害点を排除 RPOとRTOがほぼゼロのアクティブ/アクティブ構成 データセンターを提供 ビジネス継続性と高可用性の戦略を設計するときには、幅広い課題を考慮する必要があります。RPO（Recovery Point Objective：目標復旧時点）とRTO（Recovery Time Objective：目標復旧時間）は重要なメトリックであり、企業が対応しなければならない基本的な2つの質問への答えになります。 消失しても許容できるデータ量はどの程度か（RPO） システムやアプリケーションはどれくらい高速にリカバリする必要があるか（RTO） ミッション クリティカルなアプリケーションについては、RPO（目標復旧時点）とRTO（目標復旧時間）の最小化が重要な課題の1つです。 その他の主な課題には次のものがあります。 単一障害点（テクノロジ、人、プロセス）の排除 リソース使用率の最大化 インフラストラクチャ コストの削減 複数のポイント ソリューションの統合、保守、テストの複雑さの管理 ここで紹介するソリューションは、SAP ERPアプリケーションのこれらすべての課題に対応します。 このソリューションは、最大100 km離れたデータセンター向けの革新的なアクティブ/アクティブ構成の導入モデルを実証しており、 従来のアクティブ/パッシブ構成のDR（災害復旧）モデルを、24時間365日のアプリケーション可用性、単一障害点なし、ほぼゼロのRTOとRPOを実現する、高可用性ビジネス継続性ソリューションに変革します。 またこのソリューションは、完全に自動化されています。 このソリューションのシナリオは、地理的に離れた2つのデータセンターで構成され、両サイトともVMware仮 想マシン上でSAP ERPを運用し、物理サーバー上でOracle Databaseを運用しています。 EMC VMAXおよび VNXアレイが、この環境に物理ストレージを提供し、EMC VPLEX Metroが両サイト間に分散ストレージ フェ デレーションを提供します。 概要レベルでは、このソリューションは次のことを実現します。 環境内のすべてのレイヤー（ストレージ、データベース、アプリケーションを含む）で単一障害点を排除。 ほぼゼロのRPO（目標復旧時点）とRTO（目標復旧時間）をサポートしてミッション クリティカルなビジ ネス継続性を実現する、アクティブ/アクティブ構成データセンターを提供。 このスライドには、それ以外のメリットも示しています。 これらのすべてのメリットによって、ビジネスのコ スト削減も可能になります。 アクティブ/アクティブ構成データセ ンター ほぼゼロのRTOとRPO 24時間365日のアプリケーションの 可用性 単一障害点なし 高可用性管理を合理化 完全に自動的な障害対応とロード バラン シング ダウンタイムなしのメンテナンス 拡張ディスタンス クラスター上のOracle RACの導入をシンプル化 インフラストラクチャ使用率を向上

4 課題とソリューション 課題 SAPの単一障害点 ソリューション 高可用性とビジネス継続性 SAP導入：課題とソリューション
ソリューション 高可用性とビジネス継続性 SAP導入：課題とソリューション 従来のSAPの導入では、次のような複数のSPOF（単一障害点）がありました。 中央サービス エンキュー サーバー メッセージ サーバー データベース サーバー 単一サイトの導入 ローカルのディスク ストレージ スライドの左側の図はSPOF（単一障害点）を表しています。右側の図は、正確な1対1のマッピングではありませんが、それらのSPOFに対応するソリューション コンポーネントを表しています。 たとえば、VMware vSphereはSAPアプリケーション コンポーネントを仮想化して、単一障害点としてのこれらのコンポーネントを排除します。VPLEX Metroはストレージ レイヤーを仮想化し、地理的に離れた2か所のサイトに分散されたアクティブ/アクティブ構成データセンターを実現します。 全体として、このソリューションのアーキテクチャとコンポーネントは、SAPスタック全体に対してアクティブ/アクティブ構成のクラスター ソリューションを構築します。 これにより、信頼性と可用性が強化されると同時に、環境の導入と管理が合理化されます。 このソリューションでは、SAPエンキュー サーバーとメッセージ サーバーはASCSインスタンス内にサービスとして実装されることに注意してください。

5 単一障害点の排除 このスライドは、ミッション クリティカル高可用性を提供するために環境内の各レイヤーに実装される高可用性ソリューションを示しています。 a）ローカル ストレージを持つ独立した物理サーバー EMC検証チームは、まず高可用性やビジネス継続性保護スキームを含まない環境を設置して検証しました。 SAPアプリケーションおよびデータベース コンポーネントは、ローカル ストレージを持つ独立した物理サーバーに導入されました。 次に、フォルト トレラント コンポーネントと高可用性クラスタリング テクノロジを使用することで、それぞれの単一障害点が緩和されました。 b）ストレージ レイヤーのHA 環境内のサーバーが必要とするすべてのストレージは、エンタープライズ クラスのEMCストレージ（サイトAではSymmetrix VMAX、サイトBではVNX5700）に移動されました。また、ストレージ アクセスについて冗長SANファブリックを提供するために、Brocade 8510バックボーンが導入されました。 これで、アレイとSANバックボーンの実績ある99.999%のアップタイムと、高度な管理性とビジネス継続性機能を活用できるようになりました。 c）データベースのHA データベース レイヤーでは、バックエンド データベース サーバーがOracleシングル インスタンス データベースからOracle ASM上の4ノードのOracle RACデータベースに移行されました。 これにより、単一障害点としてのデータベース サーバーは排除されました。 d）SAPアプリケーションのHA SAPアプリケーション サーバーは、VMware ESXi 5.0を使用して完全に仮想化されました。各SAP仮想マシンは、SUSE Linux Enterprise Server for SAP Applicationsをゲスト オペレーティング システムとして使用して導入されました。 SUSE Linux Enterprise High Availability ExtensionとSAP ERS（Enqueue Replication Server）も、SAPメッセージ サーバーおよびエンキュー サーバーの保護のために導入されました。 これにより、単一障害点としてのASCSは排除されました。 e）データセンターのHA これまでに説明した高可用性クラスター構成の実装は、データセンター内でSAPを保護します。 2つのデータセンター間の高可用性を実現するために、このソリューションはEMC VPLEX Metroストレージ仮想化テクノロジを使用します。 VPLEX Metroの独自のアクティブ/アクティブ クラスタリング テクノロジにより、同期距離内の分散されたボリュームへの読み取り/書き込みアクセスが可能になり、両方の場所のユーザーが同時に同じ情報にアクセスできるようになります。 このソリューションは、VPLEX MetroをSUSE Linux Enterprise HAE（オペレーティング システム レイヤー）およびOracle RAC（データベース レイヤー）と組み合わせることにより、単一障害点としてのデータセンターを排除するとともに、ミッション クリティカルなアプリケーションに堅牢なビジネス継続戦略を提供します。 f）ネットワークのHA これについては、後のスライドで説明します。

6 ソリューションのコンポーネント SAP ERP向けのミッション クリティカルなビジネス継続性は、EMC、VMware、 Oracle、SUSE、Brocadeのテクノロジの組み合わせによって実現 EMC VPLEX Metro EMC VPLEX Witness EMC Symmetrix VMAXおよびEMC VNX 拡張ディスタンス クラスター上のOracle RAC VMware vSphere VMware vSphere High Availability SUSE Linux Enterprise Server for SAP ApplicationsとSUSE Linux Enterprise High Availability Extension SAP Enqueue Replication Server Brocade MLXeコア ルーター Brocade DCX 8510バックボーン このスライドに示したのは、このソリューションで使用される主要なテクノロジです。 EMC VPLEX Metroは、このソリューションを実現するプライマリ テクノロジです。 EMC VPLEX Metroは、ローカル ストレージ フェデレーションと分散ストレージ フェデレーションの両方を提供するSANベースのフェデレーション ソリューションです。 このソリューションにおいては、アクティブ/アクティブ構成のMetroデータセンターを実現する仮想ストレージ レイヤーを提供するテクノロジです。 EMC VPLEX Witnessは、一方のデータセンターが停止した場合でも継続的なアプリケーション可用性をサポートする高可用性コンポーネントです。 EMC VMAXおよびEMC VNXアレイは、実績ある99.999%の高可用性、FAST（Fully Automated Storage Tiering）、レプリケーション テクノロジの選択肢を備えたエンタープライズ クラスのプラットフォームをこのソリューションに提供します。 このソリューションは、仮想マシン上のSAPサービスと物理サーバー上のデータベースで構成されるSAP ERPシステム向けに設計されています。 Oracle Database 11gは、このソリューションにデータベース プラットフォームを提供します。 遠隔地間のデータベース レイヤーの単一障害点を排除するために、シングル インスタンス データベースが拡張ディスタンス クラスター上のOracle RACに移行されました。 VMware vSphereは、SAPアプリケーション コンポーネントを仮想化し、単一障害点としてのこれらのコンポーネントを排除します。 またVMware HA（High Availability）は、物理サーバーおよびOSの障害発生時に仮想マシンを保護します。 SUSE Linux Enterprise Server for SAP ApplicationsとSUSE Linux Enterprise High Availability Extension、およびSAP Enqueue Replication Serverは、2つのクラスター ノード間でSAP中央サービスを保護することにより、単一障害点としてのこれらのサービスを排除します。 Brocade EthernetファブリックとMLXeコア ルーターは、サイト間のシームレスなネットワークとレイヤー2拡張を提供します。 Brocade DCX 8510バックボーンは、ファブリック拡張を含む冗長SANインフラストラクチャを提供します。

7 ソリューションのアーキテクチャ この図は、このソリューションの全レイヤーの物理アーキテクチャ（ネットワーク コンポーネントを含む）を示しています。 各データセンターでは、Brocade VCS（仮想クラスター スイッチ）テクノロジを使用してEthernetファブリックが構築されました。このテクノロジは、すべてのリンク転送に対応する、自己修復性と回復力に優れたアクセス レイヤーを提供します。 vLAG（仮想リンク統合グループ）は、VCSファブリックを、レイヤー2ネットワークを2つのデータセンター間に拡張するBrocade MLXeコア ルーターに接続します。 VPLEX Witness この図に含まれているVPLEX Witnessは、このソリューションが2つのVPLEXクラスター間の接続を監視し、クラスター間のネットワーク パーティション障害やクラスター障害の発生時に継続的な可用性を保証するために使用するコンポーネントです。 VPLEX Witnessは、第3の分離された障害ドメインの仮想マシン上に導入されます。

8 保護レイヤー このソリューションを実現する各テクノロジの構成方法を確認する前に、このスライドで、このソリューションが単一障害点を排除するために使用するHAレイヤーの概要を見てみましょう。 中央の表は、ローカル高可用性を提供するために導入されたコンポーネントの概要です。 VPLEX Metroは、データセンターの境界をなくすクラスタリング アーキテクチャによってこのローカル高可用性をさらに高め、複数のデータセンターのサーバーから共有ブロック ストレージ デバイスへの読み取り/書き込みアクセスを可能にします。 VPLEX WitnessとVPLEXクロス クラスター接続構成を使用することで、さらに高度な回復力を達成できます。VPLEX WitnessとVPLEXクロス クラスター接続については、プレゼンテーションの後半で説明します。

9 VPLEX Metro：概要 サイトA サイトB サイトC SANベースのストレージ フェデ レーション
アクティブ/アクティブ構成データセ ンター 最大距離100 km ワークロードのリバランシング ほぼゼロのRPO/RTO データセンターの移行 プレゼンターへのメモ： このスライドには、アニメーションが含まれています。 最初のクリックでVPLEX Witnessコンポーネントが表示され、2回目のクリックでクロス クラスター接続構成が表示されます。 VPLEX EMC VPLEXは、EMCストレージ アレイとEMC以外のストレージ アレイの両方に対応するストレージ仮想化ソリューションです。 EMCは、3つの構成でVPLEXを提供しています。 VPLEX Localは、1つのデータセンター内でストレージを仮想化します。VPLEX Metroは、同期距離間でのストレージ仮想化をサポートします。VPLEX Geoは、非同期距離間でのストレージ仮想化に対応します。 VPLEX Metro このソリューションは、VPLEX Metroをベースにしています。 VPLEX Metroは、AccessAnywhereと呼ばれる独自のクラスタリング アーキテクチャを使用して、地理的に離れた2つの場所に同一のデータを配置し、両方の場所から同時にアクセスおよび更新できるようにすることで、お客様のデータセンターの境界をなくします。 2つのデータセンターは、2点間の距離が最大100 km、または往復時間が最大5ミリ秒の場所に設置できます。 このアーキテクチャは、同期距離内にある2つのサイトのデータへのアクティブ/アクティブのブロック レベル アクセスを提供し、ワークロードのバランシング、ほぼゼロのRPOとRTO、無停止でのデータセンター移行をサポートします。 プレゼンターへのメモ： ここでクリックしてVPLEX Witnessを表示します。 VPLEXの高可用性 VPLEX Metroは、アプリケーションとデータの移動を実現しますが、VPLEX Witnessとともに構成された場合は、Oracle RACなどのクラスター化されたアプリケーションに高可用性インフラストラクチャを提供します。 VPLEX Witnessは、VPLEXクラスターとは別の障害ドメインに仮想マシンとしてインストールされる、オプションの外部サーバーです。 VPLEX Witnessは、管理IPネットワークを介するVPNを使用して、両方のVPLEXクラスターに接続します。 Witnessは、自身による監視とクラスターから定期的に報告される情報を照合することにより、クラスターがクラスター間ネットワーク パーティション障害とクラスター障害を識別し、適切なサイトで自動的にI/Oを再開できるようにします。 VPLEX Metroを使用すると、ローカル クラスターのように拡張クラスター（ストレッチ クラスター）を構築できるようになり、単一障害点としてのデータセンターを排除できます。 さらに、両方のサイトでデータとアプリケーションがアクティブになるため、このソリューションはシンプルなビジネス継続戦略を提供します。 プレゼンターへのメモ： ここでクリックしてVPLEXクロス クラスター接続を表示します。 VPLEXクロス クラスター接続構成を使用することで、さらに高度な可用性を実現できます。 このケースでは、各ホストが両方のサイトのVPLEXクラスターに接続されています。 これにより、万一1つのVPLEXクラスターが完全に停止しても、ホストは稼動を継続するVPLEXクラスターへの代替パスを使用することができます。 サイトC VPLEX WITNESS AccessAnywhere VPLEXの高可用性 VPLEX Witness VPLEXクロス クラスター接続 アクティブ アクティブ

10 VPLEX Metro構成 VPLEX論理インフラストラク チャ コンシステンシ グループ 仮想ボリューム 分散デバイス デバイス
エクステント ストレージ ボリューム VPLEXは、従来の物理的なストレージ アレイ デバイスをカプセル化し、エクスポートされたLUNに 論理的な抽象化レイヤーを適用します。 このスライドは、VPLEX論理ストレージ構造の概要と、こ のソリューションでこれらのストレージを構成する方法を示しています。 まず、このストレージ構造階層の下部から説明します。 ストレージ ボリュームは、アレイからエクスポートされたLUNで、VPLEXによってカプセル化されます。 エクステントは、ストレージ ボリュームを分割するためにVPLEXが使用するメカニズムで、基盤のストレージ ボリュームの全部または一部の容量を使用できます。 デバイスは、1つのエクステントをカプセル化するか、複数のエクステントや他のデバイスを特定RAIDタイプの1つの大きなデバイスに結合したものです。 このソリューションでは、各サイトで、ストレージ ボリューム、エクステント、デバイスの間に1対1のマッピングが存在します。 サイトAでカプセル化されたデバイスは、仮想的にプロビジョニングされるシン デバイスで、サイトBでカプセル化されるデバイスは従来のLUNです。 次の階層は分散デバイスです。 これらは、2つの異なるVPLEXクラスターの別のデバイスをカプセル化したものです。 ストレージ構造の最上階層にあるのは仮想ボリュームです。 これらのボリュームは、最上位のデバイス（デバイスまたは分散デバイス）から作成されます。 仮想ボリュームは、VPLEXがホストに公開する要素です。 このソリューションの分散デバイスを作成するために、すべてのクラスター1デバイスが分散RAID 1構成でクラスター2にリモート ミラーリングされます。 これらの分散デバイスは、仮想ボリュームによってカプセル化され、この仮想ボリュームがストレージ ビューを通じてホストに提示されます。 ストレージ ビューでは、どのホストがどのVPLEXポート上の仮想ボリュームにアクセスできるかを定義します。 次の階層はコンシステンシ グループです。コンシステンシ グループにより、複数の仮想ボリュームを集約し、同じ属性をすべてのボリュームに適用できます。 VPLEX Metroは、（非同期でなく）同期コンシステンシ グループを使用します。 同期コンシステンシ グループでは、レーテンシーが最大5ミリ秒の場所に配置されたクラスターをサポートできます。 この場合、VPLEX Metroは書き込みをバックエンドのストレージ ボリュームに送信し、両方のクラスターのバックエンドのストレージ ボリュームがこの書き込みを確認した場合にのみ、アプリケーションへの書き込みを確認します。 このソリューションでは、単一のコンシステンシ グループに、Oracleデータベース バイナリ、ASMディスク グループ、OCRと投票ファイルを保持するすべての仮想ボリュームが配置されます。 このコンシステンシ グループには、クラスター1（サイトA）を優先クラスターとして指定するデタッチ ルールが定義されます。

11 VMware仮想化コンポーネント vSphere 5.0 vMotion Storage vMotion VMware HA
このスライドは、このソリューションの仮想化プラットフォームの概要を示しています。 ご覧のように、SAPアプリケーション サーバーはVMware vSphere 5.0を使用して完全に仮想化さ れており、仮想マシンにはVPLEX Witnessも導入されています。 VMware vMotionとVMware Storage vMotion、そしてVMware High AvailabilityとvSphere分散 リソース スケジューラも、ソリューションの一部として導入されています。 直前に挙げた2つは、vSphere用のEMCプラグ インです。 PowerPath/VEは、拡張されたパス管理機能をVMware ESXiホストに提供するマルチパス プラ グ インとして機能します。 VSIはvSphereプラグ インであり、vSphere環境内のEMCストレージの管理に使用される単一の 管理インターフェイスを提供します。 vSphere 5.0 vMotion Storage vMotion VMware HA DRS（分散リソース スケ ジューラ） EMC PowerPath/VE EMC VSI（Virtual Storage Integrator）

12 VPLEX Metro上のVMware vSphere
クロス クラスター接続 ここでは、VPLEX Metro上の一般的なVMware環境を紹介し、このソリューションで使用される特定の構成に ついて説明します。 VPLEX Metroは、物理的に離れた2つの場所にある同一のデバイス セットへの同時アクセスを提供します。 し たがって、VMware vSphereをベースとする地理的に拡張されたクラスターを実現する、アクティブ/アク ティブ構成インフラストラクチャを提供できます。 また、Brocade vLAGテクノロジを使用することで、 VLAN、つまりサブネットを、2つの物理データセンター間で拡張することができます。 では、vSphereの機能とコンポーネントをVPLEX Metroとあわせて導入すると、何を実現できるでしょうか。 vMotion： ハードウェアのメンテナンスなど、計画されたイベントに対応するために、2つのサイト間で仮想マシンをライブ移行する機能を提供します。 Storage vMotion： 仮想マシンの可用性に影響を一切与えずに、仮想マシンのストレージを移行する機能を提供します。 これにより、使用中の仮想マシンを新しいデータストアに移動できます。 VMware DRS： DRSグループと親和性ルールの使用を通じて、2つのサイト間で自動的な負荷分散と仮想マシンの配置を行います。 VMware HA： VMware HAは、ホスト フェイルオーバー クラスタリング テクノロジです。クラスター として構成された複数のESXiホストを活用して、システム停止からの迅速なリカバリを提供するとともに 、仮想マシン上で稼動するアプリケーションにコスト パフォーマンスに優れた高可用性をもたらします。 また、クラスター内の別のESXiサーバー上でVMを再開することでサーバー障害からの保護に対応し、VM を監視してゲストOSの障害発生時にVMをリセットすることにより、アプリケーション障害からの保護に対 応します。 VPLEX Metro HAとVMware HAを組み合わせると、サイト レベルのあらゆる災害の発生時に アプリケーションを自動的に再開することができます。 VPLEX Metro HAクロス クラスター接続： VMware HAクラスターの保護は、このスライドに示したように、ローカルのVMware ESXiサーバーと、リモート サイトのVPLEXクラスター間にクロス クラスター接続を追加することで、さらに強化できます。 vSphere環境をVPLEXクラスターにクロス接続すると、ローカルでデータが使用できなくなる事象（VMware vSphere 5.0はこれらの事象を認識しません）からの保護に対応することができ、停止した仮想マシンは、稼動を継続しているサイトに自動的に移動されます。 このソリューションは、VPLEX Metro HAとクロス クラスター接続を使用してVMware仮想マシンの可用性を最大限に高めます。 注： VPLEXのクロス クラスター接続は、距離によるレーテンシーが1ミリ秒までの場合に使用できます。

13 VMware拡張クラスター構成 vCenterの スクリーン ショット
分散VPLEX仮想ボリュームをVMware HAおよびVMware DRSとともに使用することにより、単一のvSphereクラスターがサイトAとサイトBにわたって拡張されます。 このクラスターには、各サイトに2つずつ、合計4つのホストがあります。 VPLEX Metro HAクロス クラスター接続により、この構成の回復力が強化されます。 最初のスクリーン ショットはvCenterのもので、vSphereクラスターの構成（ホスト数4、vSphere DRSとvSphere HAを有効化）を示しています。 2つ目のスクリーン ショットは、このソリューションのために作成されたデータストア（EXT_SAP_VPLEX_DS01）の構成を示しています。 このデータストアは、1 TBのVPLEX分散ボリューム上に作成され、拡張クラスター内のESXiに提示されました。 仮想マシンはすべて、Storage vMotionを使用してこのデータストアに移行されました。理由は、仮想マシンが仮想ディスクを共有する必要があるか、サイト間でvMotionを使用して移行を行う必要があるためです。 vCenterの スクリーン ショット

14 VMware HAおよびDRSの構成 vSphereのHA構成 vSphere DRS
このVMware拡張クラスターでは、vSphereおよびDRSの両方が有効化されていました。 このスラ イドの最初のスクリーン ショットは、このクラスターに対して構成されたこれらのオプションを示し ています。 vSphereのHA構成 VMの監視は、個々の仮想マシンのハートビートが60秒以内に受信されない場合に、仮想マシンを再起 動するように構成されました。 2つ目のスクリーン ショットに示したように、4つのSAP VMの［VM Restart Priority］オプション は［High］に設定されました。 これにより、システム停止が発生した場合に、必ずこれらのVMに最 初に電源が投入されます。 このスクリーン ショットは、デフォルトの［Leave powered on］のま ま［Host Isolation Response］設定も示しています。 次のスクリーン ショットは、ハートビートに使用されるデータストアを示しています。 vSphere HA では、ハートビートの実装に少なくとも2つのデータストアが必要であるため、2つ目のデータストア が20 GB VPLEX分散ボリュームに作成され、すべてのESXiホストに提示されました。 vSphere DRS 最後のスクリーン ショットは、このソリューションに構成されたDRS親和性ルールを示しています。 これは、ASCS（SAPASCS1）およびERS（SAPASCS2）仮想マシンを常に別のホストで保持するこ とを指定したVM-VM親和性ルールです。 SAP VMのHA再起動の優先順位 VMware拡張クラスターに対してHAとDRSを有効化 HAハートビート データストア DRS VM-VM親和性ルール

15 EMC Virtual Storage IntegratorとVPLEX
EMC VSI（Virtual Storage Integrator）for VMware vSphereは、VMware vSphereクライアントのプラグ インであり、vSphere環境内でEMCストレージを管理する単一管理インターフェイスを提供します。 優れた方法でvCenter GUIから直接VPLEXを可視化できます。 ［EMC VSI］タブから、Storage Viewer機能とパス管理機能にアクセスできます。 このソリューションでは、VPLEX分散ボリュームがEXT_SAP_VPLEX_DS01 VMFSデータストアをホストします。Storage Viewerには、このデータストアの仮想ボリューム、ストレージ ボリューム、パスの詳細が表示されます。 このスクリーン ショットは、このデータストアを構成するLUNが、PowerPathを介してアクセス可能な、分散RAID 1構成の4つの256 GB VPLEX Metroボリュームであることも示しています。 vCenter GUIの［EMC VSI］タブ

16 SAPシステムのアーキテクチャ SAPアプリケーション ソフトウェア オペレーティング システム 仮想化
SAP Enhancement Package 4 for SAP ERP 6.0 IDES SAP NetWeaver Application Server for ABAP 7.01 SAP Enqueue Replication Server オペレーティング システム SUSE Linux Enterprise Server（SLES）for SAP Applications 11 SP1 SUSE Linux Enterprise High Availability Extension 仮想化 VMware仮想マシン上のSAPサービス 物理サーバー上のOracle RACデータベース このスライドは、このソリューションのSAPシステム アーキテクチャを示しています。 SAPアプリケーション レイヤーの基盤は、SAP ERP 604とSAP NetWeaver 7.01です。SAP ASCS インスタンス、ERSインスタンス、ダイアログ インスタンスは、VMware ESXiサーバー上で仮想化 されています。 各SAP VMは、ゲスト オペレーティング システムとしてSUSE Linux Enterprise Server for SAP Applicationsを使用して導入されています。 また、SUSE Linux Enterprise High Availability ExtensionとSAP Enqueue Replication Serverも、SAPメッセージ サーバーとエンキュー サーバ ーの保護のために導入されています。

17 SAPシステム アーキテクチャ：設計上の考慮事項
エンキュー サーバーとメッセージ サーバーは、 セントラル インスタンスから分離され、ASCSイ ンスタンス内のサービスとして実装される ERSは、アプリケーション ロックによる損失を排 除するために、HAアーキテクチャの一部として インストールされる 2つのダイアログ インスタンスが、ダイアログ、 バックグラウンド、更新、スプールなどの冗長 ワーク プロセスを提供する ASCSインスタンスは、VMホスト名から分離す るために仮想ホスト名でインストールされる ERSインスタンスは、ASCSとERS両方がクラス ターに制御される場合に混乱を防止するために、 異なるインスタンス番号でインストールされる このソリューションでは、次のような特徴を持つ高可用性SAPシステム アーキテクチャが導入されま す。 エンキュー サーバーとメッセージ サーバーは、セントラル インスタンスから分離され、ASCS インスタンス内のサービスとして実装されます。 SAP ERSは、アプリケーション ロックによる損失を排除するため、およびエンキュー サーバー の保護を強化するために、HAアーキテクチャの一部としてインストールされます。 2つのダイアログ インスタンスが、ダイアログ、バックグラウンド、更新、スプールなどの冗長 ワーク プロセスを提供するためにインストールされます。 このソリューションで導入されるSAPシステムは、複数の重要な設計上の特徴も備えています。 ASCSインスタンスは、VMホスト名から分離するために仮想ホスト名でインストールされます。 ERSインスタンスは、将来ASCSとERS両方がクラスターに制御される場合に混乱を防止するた めに、異なるインスタンス番号でインストールされます。

18 SAPシステム アーキテクチャ：設計上の考慮事項（続き）
ASCS、ERS、Start、ダイアログ インスタン ス プロファイルは、ERS構成によって更新さ れる SAP共有ファイル システムは、Oracle ACFSに保管され、SAP VMにNFS共有とし てマウントされ、Oracle Clusterwareが管 理する高可用性NFSリソースとして提示さ れる SAP環境全体のストレージがカプセル化、 仮想化され、2つのサイトに分散され、 VPLEX Metroを通じてSAPサーバーに使 用可能になる このソリューションでは、次のような特徴を持つ高可用性SAPシステム アーキテクチャが導入されま す。 エンキュー サーバーとメッセージ サーバーは、セントラル インスタンスから分離され、ASCS インスタンス内のサービスとして実装されます。 SAP ERSは、アプリケーション ロックによる損失を排除するため、およびエンキュー サーバー の保護を強化するために、HAアーキテクチャの一部としてインストールされます。 2つのダイアログ インスタンスが、ダイアログ、バックグラウンド、更新、スプールなどの冗長 ワーク プロセスを提供するためにインストールされます。 このソリューションで導入されるSAPシステムは、複数の重要な設計上の特徴も備えています。 SAP更新プロセスは、追加のアプリケーション サーバー インスタンス上に構成されます。 SAP ASCS、ERS、Start、ダイアログ インスタンス プロファイルは、ERS構成によって更新さ れます。 SAP共有ファイル システムは、Oracle ACFSに保管され、SAP VMにNFS共有としてマウントさ れます。 これらのファイル システムは、Oracle Clusterwareが管理する高可用性NFSリソース として提示されます。 このソリューションのSAP環境全体のストレージは、カプセル化、仮想化されます。 このスト レージは2つのサイトに分散され、VPLEX Metroを通じてSAPサーバーに使用可能になります。

19 SUSE Linux Enterprise HAEの構成
SLES HAEは、VMware VM上に構築さ れた2つのクラスター ノード間のエンキュー サーバーとメッセージ サーバーを保護 VMware High AvailabilityはVMを保護 仮想IPアドレス、マスター/スレーブ、 SAPInstanceの各リソース エージェント が、リソースの可用性を監視および制御 SAPInstanceエージェントがASCSおよび ERSインスタンスを制御。このエージェント をマスター/スレーブ リソースとして構成し て、ASCSとERSが同一ノード上で開始さ れないようにする VMDKパーティションをSBD STONITHデ バイスとして使用。［multi-writer］オプ ションを構成し、複数のVMによる書き込み アクセスを許可 このスライドは、このソリューションがSUSE Linux Enterprise High Availability Extensionを使 用して、VMware仮想マシン上に構築された2つのクラスター ノード間の中央サービス（メッセージ サーバーとエンキュー サーバー）を保護し、VMHAによって仮想マシンを保護する方法を示していま す。 このソリューションで実装されるSUSE Linux Enterprise HAEの主なコンポーネントには、次のも のがあります。 OpenAIS/Corosync。マルチノード フェイルオーバーをサポートする高可用性クラスター マ ネージャーとして機能します。 リソースの可用性の監視と制御を行うリソース エージェント。実装されるリソース エージェント は、仮想IPアドレス、マスター/スレーブ、SAPInstanceです。 高可用性GUIと各種コマンド ライン ツール。 このソリューションで導入されるSUSE HAEシステムは、複数の重要な設計上の特徴も備えていま す。 このソリューションのSBD STONTHデバイスは、仮想ディスクのパーティションを使用します。 つまり、両方のクラスター ノードがこのディスクに同時アクセスできる必要があります。 仮想 ディスクは、SAP仮想マシンと同じデータストアに保管されます。 仮想ディスクは、VPLEXに よってプロビジョニングおよび保護され、両方のサイトで使用することができます。 デフォルトでは、VMFSは複数の仮想マシンによる同一のVMDKへのアクセスと書き込みを禁止 します。 ただし、multi-writerオプションを構成することで、共有が可能になっています。 SAPInstanceリソース エージェントは、ASCSインスタンスとERSインスタンスを制御します。 また、マスター/スレーブ リソースとして構成されています。 障害が発生した場合、スレーブは マスターの役割にプロモートされ、SAP ASCSインスタンスを開始します。 同様に、マスターは スレーブの役割にデモート（降格）され、ERSインスタンスを開始します。 このマスター/ス レーブ モードにより、ASCSインスタンスがERSと同じノードで開始されることはなくなりま す。 注： Corosyncトークン パラメーターの構成 Corosync構成ファイル（corosync.conf）では、トークン タイムアウトによって、トークンが受信されない場合にトークンの損失を宣言するまでの時間（ミリ秒）を指定します。 このタイムアウトは、現在の構成でプロセッサ障害を検知するために費やす時間に相当します。 このソリューションでは、このパラメーターの値は、不要なクラスター サービスのフェイルオーバーを発生させずに基盤レイヤーの切り換えを処理できるように、10,000ミリ秒に設定されています。

20 Oracle Databaseアーキテクチャ
Oracle Database 11g Release 2 Enterprise Edition Oracle ASM Oracle ACFS Oracle Clusterware シングル インスタンス データベースをASM上の4ノードの物理RACクラスターに 移行 VPLEX上のOracle Extended RAC 管理をシンプル化 ホストはローカルのVPLEXクラスターのみに接続 ホストはローカル クラスターに1回だけI/Oを送信、二重の書き込みは不要 第3のサイトへのOracle投票ディスクとClusterwareの導入は不要 ホスト ベースのミラーリングによる、ホストCPUサイクルの消費を排除 複数のデータベースやアプリケーションを1つの単位として保護 Oracleのコンポーネントと構成 Oracle Database 11g Release 2は、SAPアプリケーションに基盤のデータベースを提供します。 各データ センターでは、データベースは当初物理シングル インスタンスとして導入されました。 しかし、単一障害点と してのデータベース サーバーを排除するために、シングル インスタンス データベースは4ノードの物理Oracle RACクラスターに移行され、OracleデータベースはASM上に配置されました。 Oracleデータベース ファイル とSAP ERPアプリケーション ファイルは、Oracle ACFS（ASM Cluster File System）に配置されました。 拡張ディスタンス クラスター上のOracle RACアーキテクチャの導入により、クラスター内のサーバーを物理 的に離れた場所に配置することが可能になり、単一障害点としてのデータセンターは排除されました。 VPLEX上にOracle Extended RACを導入する理由 Oracle RACは、通常はローカル データセンター内で稼動します。これは、距離によるレーテンシーの影響の 可能性や、Oracle ASMを使用したホスト ベースのミラーリングでデータセンター間に既存のOracle RACを拡 張した場合の相対的な複雑さやオーバーヘッドを考慮してのことです。 しかしEMC VPLEX Metroを使用する 場合、Oracle Extended RAC環境は、Oracle DBAにとって標準のOracle RACのインストールおよび構成と 同じに扱いなります。 VPLEX上にOracle Extended RACを導入することの主なメリットを示します。 VPLEXでは、インフラストラクチャ レベルにサイト間の高可用性が組み込まれるため、Extended Oracle RACの管理がシンプル化されます。 Oracle DBAにとって、インストール、構成、メンテナンス作業がOracle RACの単一サイトへの実装とまったく同じになります。 VPLEXによって、ASMディスクのホスト ベース ミラーリングが不要になり、これによるホストCPUサイクルの消費がなくなります。 VPLEXでは、ASMディスク グループは外部に冗長化されて構成され、VPLEXの分散ミラーリングによって保護されます。 ホストが接続する必要があるのはローカルVPLEXクラスターのみで、I/Oはそのノードから1回だけ送信されます。 ただしホストは、両方のサイトの同じデータベースへの完全な読み取り/書き込みアクセス権を持ちます。 アプリケーション レベルで定数デバイスとして機能するOracle投票ディスクを第3のサイトに導入する必要はありません。 VPLEXでは、複数のデータベースやアプリケーションを1つの単位として保護するコンシステンシ グループを作成できます。

21 Oracle Database構成 4つのACFSボリュームをRACクラスターにマウント
TRANS、ASCS500、SAPMNTをNFS共有としてSAP サーバーにエクスポート 共有ファイル システムを、Oracle Clusterwareが管 理する高可用性NFSリソースとして提示 ASMディスク グループを、既存のシングル インスタン ス レイアウトを反映するように構成 このスライドの図は、このソリューションでVPLEX Metroに導入されたOracle Extended RACを論理的に示したものです。 このソリューションは、Oracle RACクラスターにマウントされた4つのACFSボリュームを使用します。 ACFSボリュームのうち3つ（SAPMNT、USRSAPTRANS、ASCS00）は、Oracle Clusterwareの制御下で仮想IPアドレスと高可用性NFSリソースを使用し、NFS共有としてSAPサーバーにエクスポートされました。 このソリューションのASMディスク グループは、既存のOracleデータベース レイアウトを反映するように構成されました。スライド下部の表は、ASMディスク グループとその構成を示しています。 ACFSボリューム マウント ポイント SAP_O_HOME /oracle/VSE/112 SAPMNT /sapmnt/VSE USRSAPTRANS /usr/sap/trans ASCS00 /usr/sap/VSE/ASCS00 ASMディスク グ ループ ディスク数 ディスク グ ループ サ イズ（GB） 冗長性 OCR 5 40 通常 EA_SAP_ACFS 4 64 外部 EA_SAP_DATA 16 2,048 EA_SAP_REDO EA_SAP_REDOM EA_SAP_FRA 256

22 Brocadeネットワーク インフラストラクチャ
このスライドは、このソリューションのために2つのデータセンターに導入されたIPネットワークと SANネットワーク、および2つのデータセンター間のレイヤー2拡張を示しています。 これらのネッ トワークは、Brocadeネットワーク テクノロジを使用して構築されています。 IPネットワーク 各データセンターのIPネットワークは、VCS（仮想クラスター スイッチ）構成で導入された2台のBrocade VDX 6720スイッチを使用して構築されました。 すべてのサーバーは、Brocade 1020 CNAが提供する冗長10 GbE接続を使用してこのネットワークに接続されます。 各サイトの2台のVDXスイッチは、vLAG（仮想リンク統合グループ）を使用してBrocade MLXシリーズ ルーターに接続されます。 MLXシリーズ ルーターは、2つのデータセンター間にレイヤー2ネットワークを拡張します。 サイトAとサイトBの間のすべてのトラフィックは、LAGとして構成された複数のポートを使用して、MLXルーターを介してルーティングされます。 Oracle RACは、プライベート ネットワーク通信のために高可用性仮想IPを使用します。 このソリューションでは、この相互接続のために特定のVLAN（VLAN 10）が使用され、すべてのパブリック トラフィックはVLAN 20によって処理されます。 SANネットワーク 各データセンターのSANは、Brocade DCX 8510バックボーンを使用して構築されています。 すべてのサーバーは、Brocade 825 HBAが提供する冗長8 Gb接続を使用してSANに接続されます。 データセンター間のVPLEX対VPLEX接続では、DCX 8510バックボーン間の複数のFC接続が使用されます。 これらは、フェイルオーバーに対応するアクティブ/アクティブ モードで使用されます。 IPネットワーク SAN

23 EMCストレージ レイアウト サイトA：EMC Symmetrix VMAX サイトB：EMC VNX5700 仮想プロビジョニング
従来のRAIDグループおよびLUN 各サイトのストレージは、エンタープライズ クラスのEMCストレージ アレイ（サイトAはSymmetrix VMAX、サイトBはVNX5700）によって提供されます。 VMAXとVNXはともに、実績ある99.999%の可用性を提供します。 また、両ストレージとも幅広いタイプのデバイス タイプでEMC FAST（Fully Automated Storage Tiering）テクノロジをサポートしており、強力なIntel Xeonプロセッサも搭載しています。 VPLEXは、異機種混在アレイ、このケースではVMAXおよびVNX上でストレージを仮想化します。 ただし、使用しているストレージ アレイのベスト プラクティスに従うことも大切です。 このソリューションのVMAX： VPLEX Metro、Oracle Extended RAC、SAPボリュームは、EMC Virtual Provisioningを使用して配置されます。 この構成では、Oracleデータ ファイルとログ ファイルが別々のシン プールに配置されるため、それぞれが異なるRAID保護を使用できます。 データ ファイルはRAID 5で保護されたプール、REDOログはRAID 1で保護されたプールに配置されます。 このレイアウトは、このスライドの最初の図に示しています。 ストレージは、EMCの推奨どおりに、Oracle REDOログ デバイスを除き、どのデバイスにも事前割り当てされませんでした。 このソリューションのVNX5700： VPLEX Metro、Oracle Extended RAC、SAPボリュームは、従来のRAIDグループおよびLUNを使用して配置されます。 この構成では、Oracleデータ ファイルとログ ファイルが別々のRAIDグループに配置されるため、それぞれが異なるRAID保護を使用できます。 データ ファイルはRAID 5で保護されたRAIDグループ、REDOログはRAID 10で保護されたRAIDグループに配置されます。 FRAディスク グループは、RAID 6で保護されたNL-SASドライブに配置されます。 このレイアウトは、このスライドの右側の図に示しています。 Virtual Provisioningと従来のプロビジョニング方法の両方に、同様のEMCのベスト プラクティスが適用され、VNXおよびVMAX上に同じASMディスク グループが作成されました。 また、VNX上に作成されたLUNは、VMAX上に作成されたシン デバイスと数およびサイズが一致します。

24 テストおよび検証 テスト SAPエンキュー サービス プロセス の障害 SAP ASCSインスタンス仮想マシ ンの障害
Oracle RACノードの障害 サイトの障害 （VPLEXクラスター、ESXiサーバー、ネットワーク、RAC ノード） VPLEXクラスターの孤立 EMC検証チームは、まず高可用性やビジネス継続性保護スキームを導入せずにソリューション環境を設置して検証しました。 次にこの環境を、このプレゼンテーションで説明したミッション クリティカルなビジネス継続性ソリューションに変革しました。 このソリューションの検証、およびすべての単一障害点が排除されたことの実証のために、検証チームはこのスライドに示したテストを実施しました。 各テストとも結果は同じでした。 つまりアプリケーションは、停止せずに稼動を継続しました。 期待される動作 アプリケーションは停止せ ずに稼動を継続

25 SAPエンキュー サービス プロセスの障害 結果
SAPInstanceリソース エージェ ントが障害を検知/報告 マスター/スレーブ リソース エー ジェントが、SAPASCS1をマス ター（ASCSサービスのホスト）に プロモート マスター/スレーブ リソース エー ジェントが、SAPASCS2がクラス ターに再度参加するときにこの ノード上でERSを開始 レプリケートされたロック表をリス トア 1 2 このスライドに、EMC検証チームが実施した「SAPエンキュー サービス プロセスの障害」テストの概要を示しました。 このテストは、SAPエンキュー サーバーでプロセス障害が発生したときのシステムの動作を検証するものです。 障害のシミュレーション このタイプの障害をテストするために、アクティブなASCSノード上のエンキュー サービス プロセスを、killコマンドを実行して中断しました。 システムの動作 ノードに障害が発生すると、スライドの最上部のスクリーン セグメントに示したように、障害が報告されます。 次に、メインのスクリーン ショットに示したように、スレーブだったノード（SAPASCS1）がマスター ノードにプロモートされ、ASCSサービスをホストします。 SAPASCS2（障害が発生したノード）がクラスターに再度参加すると、このノード上でERSが再開されます。 最後に、レプリケートされたロック表がリストアされます。 結果 このテストの結果、エンキュー プロセスに障害が発生しても、アプリケーションは停止せずに稼動を継続することと、この障害に対処するために管理上の介入は不要であることが実証されました。 3 結果 アプリケーションは停止せずに稼動を継続 管理上の介入は不要 4

26 SAP ASCSインスタンスVMの障害 結果 SAPInstanceリソース エージェント が障害を検知/報告
SAPASCS2がvSphere Clientか ら使用できなくなる SAPInstanceリソース エージェント が障害を検知/報告 VMHAが稼動を継続するESXiホス ト上で、障害が発生したVMを再開 マスター/スレーブ リソース エージェ ントがSAPASCS1をマスター （ASCSサービスのホスト）にプロ モートし、SAPASCS2がクラスター に再度参加するときにこのノード上 でERSを開始 レプリケートされたロック表をリストア 1 2 3 このスライドに、EMC検証チームが実施した「SAP ASCSインスタンスVMの障害」テストの概要を示しました。 このテストは、ASCSインスタンスが稼動しているVMで障害が発生したときシステムの動作を検証するものです。 障害のシミュレーション このタイプの障害をシミュレートするために、ASCSインスタンスVMをホストしているESXiサーバーの電源を、DRACを介して切りました。 次にこのサーバーは、メンテナンス モードに入らずに再起動されました。 システムの動作 このシステムは、スライドに示した1～5の手順でこの障害に対応しました。 結果 このテストの結果、ASCSインスタンスVMに障害が発生しても、アプリケーションは停止せずに稼動を継続することと、この障害に対処するために管理上の介入は不要であることが実証されました。 4 結果 アプリケーションは停止せずに稼動を継続 管理上の介入は不要 5

27 Oracle RACノードの障害 結果 SAPインスタンス ワーク プロセスが別の RACノードに接続する
DIワーク プロセスが別のRACノー ドに再接続するときに、エンド ユー ザーへのトランザクション応答時間 が長くなる コミットされていないトランザクション は、DBレベルでロール バックされ るため、データの整合性が保証され る。エンド ユーザーは、システム エ ラー メッセージを受信し、トランザク ションを再開する必要がある 管理上の介入は不要 このスライドに、EMC検証チームが実施した「Oracle RACノードの障害」テストの概要を示しました。 このテストは、予期しないRACノード障害が発生したときのシステムの動作を検証するものです。 障害のシミュレーション このタイプの障害をテストするために、サーバーを再起動し、このサーバー上で稼動していたOracle RACをオフラインにしました。 システムの動作 RACノードがオフラインになると、インスタンスVSE003が使用不能になりました。 次に、SAPインスタンス ワーク プロセスが自動的に別のRACノードに接続されました。これは、このスライドのスクリーン ショットに示しています。 結果 テスト結果の概要もこのスライドに示しました。 RACノードがオフラインになる：インスタン スVSE003が使用不能 SAPインスタンス ワーク プロセスが別の RACノードに接続する 1 2

28 サイト障害前の環境のステータス ステータス すべてのRACノードが稼動 両方のサイトでVPLEXクラス ターが使用可能
両方のサイトでESXiサーバー が使用可能 サイトAとサイトBのSAP仮想 マシンが稼動 次の2つのテストは、完全なサイト障害とVPLEXクラスターの孤立に関連するものです。 このスライドに、テストが実施される前の環境のステータスを示しました。

29 サイトの障害 VPLEX Witnessがコンシステンシ グループのデタッチ ルールを無効 にするため、サイトBのVPLEXは引 き続き使用可能。 サイトBのRACノードは引き続き使 用可能。 VMHAがサイトBでSAPASCS1と SAPDI1を再開。 SLE HAEがSAPASCS1の障害を 検知し、このノードがクラスターに再 度参加するときにERSを再開。 SAPDI1上のエンド ユーザーは セッションを失うが、サイトBで再開 されたときに再度ログイン可能。新 しいユーザーはSAPDI2にダイレク トされる。 1 2 このスライドに、EMC検証チームが実施した「サイトの障害」テストの概要を示しました。 このテストは、完全なサイト障害が発生したときのシステムの動作を検証するものです。 障害のシミュレーション この障害のシナリオをテストするために、検証チームは、VPLEXクラスター、ESXiサーバー、ネットワーク、Oracle RACノード コンポーネントを含むサイトAの完全な障害をシミュレートしました。 VPLEX Witnessは、サイトCで引き続き使用可能でした。また、サイトBでは、VPLEXクラスター2がこのVPLEX Witnessと通信を継続しました。 システムの動作 手順1～5は、このシステムが障害に対応する方法の概要を示しています。左側の図は、サイト障害発 生後の環境のステータスを示しています。 サイトAに障害が発生すると、VPLEX Witnessがコンシステンシ グループのデタッチ ルール （クラスター1を優先クラスターとして定義）を無効化し、サイトBのVPLEXクラスター2によっ て提供されているストレージを引き続き使用できるようにします。 サイトBのRACノードsse-ea-erac-n03とsse-ea-erac-n04は引き続き使用できます。 サイトAのESXiサーバーに障害が発生すると、VMHAがサイトBでSAPASCS1とSAPDI1を再開し ます。SAPASCS1はSAPASCS2とは異なるESXiホスト上で再開されます。 SUSE Linux Enterprise HAEが、クラスター ノードSAPASCS1の障害を検知します。ERSはこ のノードで実行されていたため、クラスターはSAPASCSがクラスターに再度参加するときにERS を再開する以外、アクションを実行しません。 ロック表は保持され、常に使用可能です。 SAPDI1上のエンド ユーザーは、ESXiサーバー障害のためにセッションを失います。 再開プロ セス中、新しいユーザーはSAPDI2にリダイレクトされます。SAPDI1がサイトBで再開すると、 ユーザーはSAPDI1に再びログインできます。 結果 結果を総合すると、サイト全体の障害が発生しても、アプリケーションは介入を必要とせずに稼動を継続します。 3 4 5

30 VPLEXクラスターの孤立 VPLEX Witnessがコンシステンシ グループのデタッチ ルールを無効に するため、サイトBのVPLEXは引き 続き使用可能。 サイトBのRACノードは引き続き使用 可能。 サイトAのRACノードは除外される。 サイトAのESXiサーバーは引き続き 使用可能。 仮想マシンSAPASCS1および SAPDI1は、VPLEX Metro HAクロ ス クラスター接続の使用により、アク ティブ状態を継続。 1 2 このスライドに、EMC検証チームが実施した「VPLEXクラスターの孤立」テストの概要を示しました。 このテストは、VPLEXクラスターの一方が孤立した際のシステムの動作を検証するものです。 障害のシミュレーション この障害シナリオをテストするために、検証チームは、外部IP管理ネットワークとVPLEX WAN通信ネットワーク両方を分断して、サイトAの優先クラスターの孤立をシミュレートしました。 LAGネットワークは引き続き使用可能でした。 VPLEX Witnessは、サイトCで引き続き使用可能でした。また、サイトBでは、VPLEXクラスター2がVPLEX Witnessと通信を継続しました。 システムの動作 手順1～5は、このシステムが障害に対応する方法の概要を示しています。左側の図は、クラスター孤立発生後の環境のステータスを示しています。 サイトAのVPLEXが孤立すると、VPLEX Witnessがコンシステンシ グループのデタッチ ルール（クラスター1を優先クラスターとして定義）を無効化し、サイトBのVPLEXクラスター2によって提供されているストレージを引き続き使用できるようにします。 サイトBのRACノードsse-ea-erac-n03とsse-ea-erac-n04は引き続き使用できます。 サイトAのRACノードsse-ea-erac-n01とsse-ea-erac-n02は除外されます。 サイトAのESXiサーバーは引き続き使用できます。 仮想マシンSAPASCS1およびSAPDI1は、VPLEX Metro HAクロス クラスター接続の使用により、アクティブ状態を継続します。 結果 結果を総合すると、優先VPLEXクラスターが孤立しても、アプリケーションは介入を必要とせずに稼動を継続します。 3 4 5

31 テストおよび検証 テスト SAPエンキュー サービス プロセス の障害 SAP ASCSインスタンス仮想マシ ンの障害
Oracle RACノードの障害 サイトの障害 （VPLEXクラスター、ESXiサーバー、ネットワーク、RAC ノード） VPLEXクラスターの孤立 EMC検証チームは、まず高可用性やビジネス継続性保護スキームを導入せずにソリューション環境を設置して検証しました。 次にこの環境を、このプレゼンテーションで説明したミッション クリティカルなビジネス継続性ソリューションに変革しました。 このソリューションの検証、およびすべての単一障害点が排除されたことの実証のために、検証チームはこのスライドに示したテストを実施しました。 各テストとも結果は同じでした。 つまりアプリケーションは、停止せずに稼動を継続しました。 確認された動作 アプリケーションは停止せ ずに稼動を継続

32 まとめ 完全に自動的な障害対応とロード バラン シング アクティブ/アクティブ構成データセ ンター ダウンタイムなしのメンテナンス
EMC、SAP、VMware、Oracle、SUSE、Brocadeのテクノロジを組み合 わせたソリューションによって可能になること： 環境内のすべてのレイヤーで単一障害点を排除 RPOとRTOがほぼゼロのアクティブ/アクティブ構成データセンターを提供 SAPアプリケーションのミッション クリティカルなビジネス継続性を実現 このソリューションは、従来のアクティブ/パッシブ構成のSAP環境を、アクティブ/アクティブ構成データセンターとアプリケーションの常時可用性による高可用性ビジネス継続性ソリューションに変革できることを実証しています。 このソリューションは、EMC、VMware、Oracle、SUSE、Brocadeの高可用性コンポーネントを組み合わせることによって、以下を可能にします。 環境内のすべてのレイヤーで単一障害点を排除 RPOとRTOがほぼゼロのアクティブ/アクティブ構成データセンターを提供 SAPアプリケーションのミッション クリティカルなビジネス継続性を実現 次に、フォルト トレラント コンポーネントと高可用性クラスタリング テクノロジを使用することで、特定されたそれぞれの単一障害点が緩和されました。 リソースの使用率は、アクティブ/アクティブ構成のデータ アクセスを可能にすることで向上しました。 障害処理は、人間とプロセスという、多くの場合最も予測が難しい最終的なSPOFをアーキテクチャから排除するために、完全に自動化されました。 さらに、vSphere Client、EMC Virtual Storage Integrator、VPLEXパフォーマンス ツールなどの管理/監視ツールの使用を通じて、運用管理がシンプル化され、インフラストラクチャ スタックの監視とマッピングが可能になりました。 EMC検証チームによって実施されたテストの結果、このソリューションの設計原則とコンポーネントを使用することにより、ローカル レベルの単一障害点を排除し、SAPのミッション クリティカルなビジネス継続性を実現する、アクティブ/アクティブ構成データセンターを構築できることが実証されました。 このソリューションで使用されたコンポーネントは、 EMC VPLEX Metro、EMC VPLEX Witness、EMC Symmetric VMAX、VMware vSphere HA、Oracle RAC、SUSE Linux Enterprise HAE、Brocadeネットワーク コンポーネントです。 またこのテストにより、VPLEX Metroと、SUSE Linux Enterprise HAE、Oracle Extended RAC、Brocadeネットワーク コンポーネントを組み合わせることで、データセンターの境界を越えてこの高可用性を拡張し、複数のデータセンターのサーバーから共有ブロック ストレージ デバイスへの読み取り/書き込みアクセスを可能にできることも実証されました。 VPLEX Witnessとクロス クラスター接続は、さらに高いレベルの復元性を提供します。 これらのテクノロジは連携を通じて、従来のアクティブ/パッシブ構成データセンター環境を、アクティブ/アク ティブ構成データセンター、24時間365日のアプリケーションの可用性、単一障害点なし、ほぼゼロのRTOと RPOを実現する、ミッション クリティカルなビジネス継続性ソリューションに変革します。 アクティブ/アクティブ構成データセ ンター ほぼゼロのRTOとRPO 24時間365日のアプリケーションの 可用性 単一障害点なし 高可用性管理を合理化 完全に自動的な障害対応とロード バラン シング ダウンタイムなしのメンテナンス 拡張ディスタンス クラスター上のOracle RACの導入をシンプル化 インフラストラクチャ使用率を向上

33 ありがとうございました。