EMC Multisite Disaster Recovery For Microsoft SQL Server 2012—EMC VNX5700, EMC FAST Cache, SQL Server AlwaysOn Availability Groups

Transcription

1 ホワイトペーパー MICROSOFT SQL SERVER 2012 向け EMC 複数サイト災害復旧 EMC VNX5700 EMC FAST Cache SQL Server AlwaysOn 可用性グループ ミッションクリティカルな高可用性 自動化されたストレージの最適化 EMC ソリューショングループ 要約 このホワイトペーパーでは AlwaysOn 可用性グループを使用する地理的に分散した Microsoft SQL Server 2012 環境を EMC VNX5700 プラットフォームに導入および実装する方法のベストプラクティスについて説明します このホワイトペーパーでは EMC FAST Cache によって SQL Server 2012 にもたらされる 自動化された無停止でのストレージパフォーマンスの大幅な向上の仕組みについても説明します 2012 年 4 月

2 Copyright 2012 EMC Corporation.All rights reserved.( 不許複製 禁無断転載 ) このドキュメントに記載されている情報は ドキュメントの出版日現時点の情報です この情報は予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適合性の黙示的保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェアライセンスが必要です 最新の EMC 製品名については EMC.com で EMC Corporation の商標を参照してください Intel および Xeon は Intel Corporation の商標です その他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H J 2

3 目次 エグゼクティブサマリー... 6 ビジネスケース... 6 ソリューション概要... 6 主な結果... 6 はじめに... 7 目的... 7 適用範囲... 7 対象読者... 7 用語... 7 技術概要 概要 EMC VNX EMC Unisphere EMC FAST Cache EMC Storage Integrator EMC PowerPath Microsoft SQL Server AlwaysOn 可用性グループ ソリューションの構成 概要 物理環境 ハードウェアリソース ソフトウェアリソース 環境プロファイル SQL Server 2012 AlwaysOn SQL Server 高可用性ソリューション概要 AlwaysOn フェイルオーバークラスタリング AlwaysOn 可用性グループ 可用性レプリカと役割 プライマリとセカンダリの役割 セカンダリレプリカ 読み取り可能なセカンダリレプリカ バックアップの選択 可用性モード 可用性グループリスナー フェイルオーバーモード

4 管理とモニタリング SQL Server Management Studio AlwaysOn 可用性グループの構成 概要 前提条件 WSFC WSFC クォーラムモードと投票の構成 AlwaysOn の有効化 ストレージ設計 概要 VP プールと FAST Cache のサイズ設定 ストレージ構成 VNX5700 ストレージ割り当て RAID グループの使用 ストレージプール シードのための共有ストレージ要件 FAST Cache FAST Cache の有効化 EMC Storage Integrator ディスクの作成 検証 テストの目的 テストの方法 テストシナリオ パフォーマンステストプロシージャ テスト結果 スループットテスト IOPS のスループット ( 転送数 / 秒 ) SQL Server の CPU の利用率 トランザクション数 / 秒 (TPS) のスループット レーテンシ 物理ディスク使用率 ストレージプロセッサ使用率 可用性グループ作成時間 フェイルオーバー 結論 サマリー 評価結果

5 関連資料 ホワイトペーパー その他のドキュメント

6 エグゼクティブサマリー ビジネスケース 急速に変化する世界経済環境で競合する企業にとって ミッションクリティカルなデータへのアクセスの重要性が今までにないほど高まっています ビジネス分析 在庫管理 プロジェクト管理 顧客インサイトとコラボレーションのほか Microsoft アプリケーションの可用性に依存するビジネス機能には アプリケーションおよびデータの可用性が 24 時間 365 日求められます しかも ビジネスクラスの可用性を提供するだけでは不十分です ユーザーがいる場所や使用しているデバイスに関係なく 即時にユーザーに情報を届ける必要があります Microsoft と EMC は共同で Microsoft SQL Server 2012 データベースおよびアプリケーション向けの高パフォーマンスなビジネスクラスの可用性ソリューションを提供します SQL Server 2012 AlwaysOn 可用性グループの高機能と EMC VNX ユニファイドストレージを組み合わせることで この共同ソリューションはデータベースの可用性と総合的なシステム使用率の向上を実現します EMC VNX シリーズは 物理または仮想アプリケーション向けに最適化された 優れたシンプルさおよび効率性を実現する高パフォーマンスのユニファイドストレージによって構成されています VNX5700 は コストおよび複雑さの低減に必要な要件を満たす一方 データベースおよびアプリケーションの必要を満たす処理能力と柔軟性を提供します 特に EMC FAST Cache テクノロジーと組み合わせると フラッシュドライブでシステムメモリを拡張してリアルタイムのパフォーマンス向上を実現できるようになります VNX プラットフォームと FAST Cache を使用して SQL Server 2012 環境で大幅なパフォーマンス向上を実現できます ストレージを手動で再設計する必要も アプリケーションレベルで変更を行う必要もありません ソリューション概要 AlwaysOn テクノロジーで保護された地理的に分散した SQL Server 2012 環境をベースとし 離れた場所に対する同期および非同期両方のマルチサブネットサポートが強調されています ミッションクリティカルでアクティブな OLTP( オンライントランザクション処理 ) データベースが SQL Server AlwaysOn 可用性グループ機能を使用して災害復旧サイトにレプリケートされます 主な結果 テストと検証の結果 次のことが明らかになりました 注 SQL Server AlwaysOn 可用性グループテクノロジーは 使いやすさ モニタリング パフォーマンスに関して 以前のバージョンで提供されていた従来のネイティブの SQL Server 保護サービスと比較した場合 ネイティブの保護レベルに大幅な向上をもたらす EMC VNX5700 は 50,000 を超える SQL Server オンライントランザクション処理 (OLTP に類似 )IOPS を容易に処理すると同時に SQL Server 2012 AlwaysOn 可用性グループ構成を通して HA( 高可用性 ) を実現する その結果 FAST Cache テクノロジーを有効化することで SQL Server トランザクションの大幅なパフォーマンス向上をいかに簡単に実現できるかが強調されている VNX5700 アレイは このホワイトペーパーに記録されているよりもはるかに多くの IOPS を処理できます このソリューションで実現されるパフォーマンスは 特定の容量のストレージデバイス ( ソリューションのシステム構成 のセクションを参照 ) 6

7 はじめに 目的 ソリューションは AlwaysOn 可用性グループの AlwaysOn 高可用性機能を強調し SQL Server 2012 AlwaysOn トランザクションレベルのレプリケーションテクノロジーを重視しています これにより 2 つの離れた場所にあるマルチサブネットサイトのユーザーデータベースの可用性を最大化すると同時に VNX ストレージシリーズで利用可能な FAST Cache テクノロジーを使用して データベースストレージの効率性と最適化の度合いを高めます 適用範囲 対象読者 このホワイトペーパーでは 次の内容について説明します SQL Server 2012 AlwaysOn 可用性グループ機能を使用したマルチサブネット災害復旧システム構成を持つ 重要性の高いエンタープライズレベルの SQL Server 2012 環境に対する VNX ストレージプラットフォームの検証 SQL Server 2012 環境の大量の OLTP ワークロードを容易に処理する VNX5700 の機能の説明 ( このソリューションは 容量またはパフォーマンスに関しては VNX5700 の機能に達しているわけではありません ) SQL Server 2012 環境のパフォーマンスを大幅に向上させる EMC FAST Cache テクノロジーの機能の紹介 このホワイトペーパーは EMC の従業員 パートナー お客様を対象としています これには お客様の環境にこのようなソリューションを導入する作業を担当する IT プランナー ストレージアーキテクト SQL Server データベース管理者 EMC のフィールド担当者が含まれます 読者にこのソリューションのさまざまなコンポーネントについて知識があることを前提にしています 用語 このホワイトペーパーでは 表 1 に定義した用語を使用しています 表 1. 用語 用語アクティブセカンダリ自動フェイルオーバー可用性データベース可用性グループ可用性グループリスナー 定義 アクティブに使用されるセカンダリレプリカデータベース ( たとえば 読み取り可能なセカンダリレプリカとして構成されたデータベースなど ) 同期コミットモードの可用性グループに使用するフェイルオーバーオプション 可用性グループに属するデータベース 可用性データベースごとに 可用性グループには 1 個の読み取り / 書き込みコピー ( プライマリデータベース ) と 1~4 個の読み取り専用コピー ( セカンダリデータベース ) が維持されます 同時にフェイルオーバーする可用性データベースのセットのコンテナー AlwaysOn 可用性グループのプライマリまたはセダンダリレプリカ内のデータベースにアクセスするためにクライアントが接続できる接続先サーバー名 可用性グループリスナーは受信接続をプライマリレプリカまたは読み取り専用のセカンダリレプリカへ経路指定します 7

8 用語 可用性レプリカ 定義 SQL Server の特定のインスタンスによってホストされている可用性グループをインスタンス化したもの 可用性グループに属する各可用性データベースのローカルコピーを維持します 2 種類の可用性レプリカが存在します 1 個のプライマリレプリカ ( プライマリレプリカの定義を参照 ) と 1~4 個のセカンダリレプリカ ( セカンダリレプリカの定義を参照 ) です データ同期プライマリデータベースに対する変更がセカンダリデータベースにコピーされるプロセス フェイルオーバーパートナー可用性レプリカと呼ばれる複数のフェイルオーバーパートナーのセットで構成される可用性グループ FAST Cache FAST VP 柔軟性のあるフェイルオーバーポリシー 強制フェイルオーバー IOPS LUN 手動フェイルオーバー マルチサブネット OLTP プライマリデータベース EMC VNX シリーズストレージアレイのパフォーマンス最適化機能として FAST(Fully Automated Storage Tiering) Cache がある FAST Cache は フラッシュドライブを使用して既存のキャッシュ容量を拡張し システムパフォーマンスを大きく改善するとともに アプリケーションワークロードの予期しない急増を自動的に吸収します Fully Automated Storage Tiering for Virtual Pools FAST VP は サブ LUN レベルで自動的なストレージ階層化を提供します 可用性グループの柔軟性のあるフェイルオーバーポリシーでは 自動フェイルオーバーを発生させる原因について 細分性の高い制御が可能 非同期コミットモードで可用性グループに使用できる唯一のオプション 1 秒あたりの I/O( 入力 / 出力 ) 回数 I/O コマンド処理の 1 秒あたりのスループットを表すディスクパフォーマンスの測定基準です 論理ユニット番号 ストレージサブシステムの論理ストレージオブジェクトを表現および識別するために使用する識別子です 同期コミットモードで可用性グループに使用できるフェイルオーバーオプション SQL Server マルチサブネットフェイルオーバークラスターとは フェイルオーバークラスターノードが複数のネットワークに接続されている構成を指す このようなネットワークは 物理的に同じ 1 つの場所にある場合と 物理的に分散したネットワークである場合があります オンライントランザクション処理 ( 株取引または銀行業務アプリケーションのワークロードなど ) 可用性データベースの本番用の読み取り / 書き込みコピー 8

9 用語 プライマリレプリカ RDM 読み取り可能セカンダリレプリカ 再シード セカンダリデータベース セカンダリレプリカ ターゲットセカンダリレプリカ TPS 定義 プライマリデータベースをクライアントからの読み取り / 書き込み接続用に使用できるようにする 可用性レプリカ 各プライマリデータベースのトランザクションログレコードをそれぞれのセカンダリレプリカに送信します raw デバイスマッピング 読み取り専用クライアント接続を可能にするように構成された セカンダリレプリカデータベース ( セカンダリレプリカの定義を参照 ) プライマリレプリカから対応するセカンダリレプリカへデータベースをコピーするプロセス 可用性データベースの読み取り専用コピー 各可用性グループは 1 個のプライマリレプリカと最大 4 個のセカンダリレプリカをサポート セカンダリデータベースは 読み取り専用アクセスやバックアップ操作に使用可能にすることができます ターゲットセカンダリレプリカは フェイルオーバー中にプライマリの役割に移行 1 秒あたりのトランザクション 9

10 技術概要 概要 次のコンポーネントがこのソリューションで使用されています EMC VNX5700 EMC FAST Cache ESI(EMC Storage Integrator) EMC PowerPath Microsoft SQL Server 2012 Microsoft SQL Server 2012 AlwaysOn Microsoft SQL Server 2012 AlwaysOn 可用性グループ EMC VNX5700 EMC VNX5700 はハイエンドのエンタープライズストレージアレイで ストレージプロセッサエンクロージャ DAE( ディスクアレイエンクロージャ ) を備えた最大 2 個のストレージプロセッサ 500 台のディスクドライブまでスケールアップできる個別のストレージベイを含むシステムベイで構成されます VNX5700 アレイは フラッシュ SAS(serial-attached SCSI) があり NL-SAS( ニアライン SAS) ドライブを含む複数のドライブテクノロジーと すべての範囲の RAID タイプをサポートします VNX シリーズは パフォーマンスを自動的かつ効果的に拡張しながら ミッションクリティカルな SQL Server 環境向けのデータの整合性 セキュリティ 24 時間 365 日のアップタイムを確実に実現する インテリジェントストレージ用の Intel Xeon プロセッサを使用しています EMC Unisphere EMC Unisphere では 分散ストレージ環境向けのシンプルかつ統合されたユーザーインターフェイスを使用して どこからでも簡単に VNX システムを管理できます Unisphere ダッシュボードは概要表示やレポート作成のための単一スクリーンで 管理者は環境の状況とその対応方法についての情報を瞬時に把握できます Unisphere のシングルサインオンによって 環境内にシームレスな構成でインストールされているすべての VNX EMC CLARiX EMC Celerra EMC RecoverPoint SE が自動的に検出されます EMC FAST Cache VNX シリーズは FAST Cache と呼ばれるオプションのパフォーマンス向上機能をサポートしています FAST Cache は I/O アクセラレータとして機能する 特別に構成されたフラッシュドライブのセットです グローバルリソースとして使用でき RAID グループおよびプール内の LUN をサポートできます 同等のワークロードの場合 FAST Cache を使用すると次のようにパフォーマンスが向上します ホストに対するレスポンスタイムの短縮 プールおよび RAID グループの物理ドライブ使用率の低減 注 FAST Cache は プールベースの LUN と従来の LUN の両方をサポートします 10

11 ストレージプロセッサは 読み取りおよび書き込み I/O をキャッシュで処理する以外にも 書き込みをまとめ 読み取りをプリフェッチすることにより パフォーマンスを向上させます ただし これらの操作は一般に ランダムな読み取り負荷の大きい I/O の高速化にはつながりません そこで FAST Cache が役立ちます FAST Cache はストレージプロセッサの I/O アクティビティを監視し 複数回読み取りまたは書き込みされるストレージのブロックを特定して それらのブロックがまだキャッシュに入れられていない場合は FAST Cache にプロモートします 以降は はるかに短いレスポンスタイムでブロックにアクセスできます EMC Storage Integrator ESI(EMC Storage Integrator) は エージェントを使用しない無料のプラグインであり Microsoft Windows サーバーアプリケーションを対象にしたアプリケーション対応ストレージプロビジョニングを実現します Windows 管理者は ( ウィザードを使用して ) Windows 環境でブロックストレージやファイルストレージを簡単にプロビジョニングできます ESI は EMC VNX EMC VNXe EMC CLARiX CX4 EMC VMAX VMAXe ストレージプラットフォームをサポートします EMC PowerPath EMC PowerPath ソフトウェアは VMware HA クラスターの vsphere ホストで使用されていました PowerPath を使用すると ホストは複数のストレージプロセッサポートを介して LUN に接続できます このような接続をマルチパスと呼びます PowerPath は ロードバランシングアルゴリズムを通じてマルチパス LUN を最適化します ポートロードバランシングによりすべての使用可能なチャネルの I/O ワークロードが均等化されます VNX に接続されているホストは マルチパスのメリットを得ます マルチパスのメリットは次のとおりです 同じストレージプロセッサ上のポートからポートへのフェイルオーバーでは 均等なシステム負荷が維持され LUN のトレスパスが最小限に抑えられる ストレージプロセッサポートおよび HBA( ホストバスアダプター ) 全体でのポートロードバランシング 高帯域幅でのホストからストレージシステムへの接続 Microsoft SQL Server 2012 SQL Server 2012 は e コマース 基幹業務 データウェアハウジングソリューション向けの Microsoft のデータベース管理および解析システムの最新バージョンです SQL Server 2012 には次のようなテクノロジーが組み込まれています データベースエンジン DQS( データ品質サービス ) 分析サービス 統合サービス マスターデータサービス レプリケーション レポート作成サービス (SSRS) このソリューションは SQL Server 2012 の新しい最も重要なレプリケーション機能の 1 つである AlwaysOn 特に AlwaysOn 可用性グループを重視しています 11

12 AlwaysOn SQL Server AlwaysOn は SQL Server 2012 向けの包括的な HA および災害復旧ソリューションです AlwaysOn は 特定のデータベースとインスタンス全体の両方に対する新しい拡張された機能を表します その機能は次の要素を通じて さまざまな高可用性構成をサポートする柔軟性を提供します AlwaysOn FCI( フェイルオーバークラスターインスタンス ) AlwaysOn 可用性グループ AlwaysOn 可用性グループは このソリューションで重視されていますが AlwaysOn FCI については SQL Server 高可用性ソリューション概要 セクションで説明しています 可用性グループ AlwaysOn 可用性グループは SQL Server 2012 で導入された HA および DR ソリューションであり 管理者はこのソリューションを使用して 1 つ以上のユーザーデータベースの可用性を最大限に高めることができます SQL Server インスタンスは 単一のプライマリデータベースまたはプライマリデータベースのグループで WSFC (Windows Server フェイルオーバークラスター ) ノードに最大 4 個のセカンダリデータベースを配置できるように構成されます 可用性グループは 2 種類の可用性モードで構成できます 非同期コミットモード 同期コミットモード 12

13 ソリューションの構成 概要 このホワイトペーパーでは AlwaysOn テクノロジーによって保護された地理的に分散した SQL Server 2012 環境をサポートする VNX5700 ストレージアレイの特徴を説明し 検証していますが 特に同期および非同期式の 80 km 800 km 4,000 km の距離でのマルチサブネットサポートに重点を置いています 現在の VNX ストレージ構成のベストプラクティスが EMC FAST Cache とともに使用され OLTP のパフォーマンス向上をもたらします 物理環境 図 1 は 環境の全体的な物理アーキテクチャを示しています 図 1. 物理アーキテクチャ 13

14 ハードウェアリソース 表 2 は このソリューションで使用されているハードウェアリソースを示しています 表 2. ハードウェア 装置個数構成 ストレージプラットフォーム 2 VNX5700 ファイバースイッチ 2 8 GB 48 ポートの部門ファイバーチャネルスイッチ FC HBA 4 8 GB(SQL Server 本番ホストごとに 2 個 ) ネットワークスイッチ 2 1 GB スイッチ 48 ポート 距離シミュレーター 1 IP 1~10 GigE/FC 1~8 GB 光メディアベースの物 理デバイス SQL Server 物理サーバー 管理およびロードジェネレーター ( ローカルおよびリモートサイト ) 2 32 コア /256 GB メモリ ( プロセッサ : Intel Xeon X7560) 1GigE ポート x 6 デュアルポート 8 GB FC HBA x コア /96 GB メモリ x 2 ( プロセッサ : Intel Xeon X7560) Hyper-V を実行している仮想化サーバー 仮想マシン : SQL Server テストロードサーバー x 4 ドメインコントローラー x 2 ソフトウェアリソース 表 3 は このソリューションで使用されているソフトウェアリソースを示しています 表 3. ソフトウェア 説明個数バージョン目的 EMC VNX ブロックオペレーティング環境 VNX オペレーティング環境 EMC Storage Integrator 新しいストレージおよび拡 張ストレージビューのプロ ビジョニングとレポート作成 EMC PowerPath SQL Server 本番ホスト HBA の拡張マルチパス EMC Unisphere VNX 管理ソフトウェア EMC Navisphere CLI VNXストレージアレイを管理 するための CLI ソフトウェア Windows Server 2008 R2 Enterprise Edition Microsoft SQL Server 2012 Enterprise Edition R2 x64 SP1 サーバーのオペレーティン グシステム データベースサーバー 14

15 環境プロファイル このソリューションは 表 4 に示す環境プロファイルを使用して検証されました 表 4. 環境プロファイル プロファイルの特徴 数量 / タイプ / サイズ Microsoft SQL Server 2012 SQL Server インスタンス x 2 OLTP データベース 1(OLTP_1) OLTP データベース 2(OLTP_2) OLTP データベース 3(OLTP_3) OLTP データベース 4(OLTP_4) 100,000 ユーザー /TPC-E と同様 /1 TB 50,000 ユーザー /TPC-E と同様 /500 GB 25,000 ユーザー /TPC-E と同様 /250 GB 5,000 ユーザー /TPC-E と同様 /50 GB 15

16 SQL Server 2012 AlwaysOn SQL Server 高可用性ソリューション概要 SQL Server には 管理者向けに サーバーとデータベースの両方に高可用性を構成するための複数のオプションが用意されています これまで これらの高可用性構成には次の要素が含まれていました データベースミラーリング : プリンシパルデータベースと呼ばれる本番データベースの 1 個のスタンバイデータベースつまりミラーデータベースが維持されます ほぼ瞬時のフェイルオーバーをサポートすることによりデータベースの可用性を向上させるこのソリューションは 基本的にはソフトウェアソリューションです ログ配布 : プライマリデータベースと呼ばれる 1 個の本番データベースに対して 1 個以上のウォームスタンバイデータベース ( セカンダリデータベース ) を維持します レプリケーション : パブリッシャーと呼ばれるプライマリサーバーがデータを 1 個以上のセカンダリサーバー ( サブスクライバー ) に分散します レプリケーションにより これらのサーバー全体でリアルタイムの可用性と拡張性が実現します また レプリケーションは データのサブセットのみをサブスクライバーに提供するフィルタリングをサポートし パーティション単位の更新も可能です サブスクライバーはオンラインであり レポート作成やクエリーのリカバリを伴わない他の機能に使用できます 3 種類のレプリケーションを使用できます スナップショット トランザクション マージです トランザクションレプリケーションは レーテンシが最も少なく 高可用性の実現に最も多く使用されます SQL Server 2012 では SQL Server AlwaysOn の一部として次の 2 種類の高可用性構成を導入しており アプリケーションデータベースレベルまたはインスタンスレベルでの可用性を提供します AlwaysOn フェイルオーバークラスタリング AlwaysOn 可用性グループ AlwaysOn フェイルオーバークラスタリング 複数の WSFC(Windows Server フェイルオーバークラスター ) ノード全体で単一の SQL Server インスタンスがインストールされます WSFC 機能により FCI はクラスターの仮想名を使用してアクセスできる 1 台のコンピューターとしてネットワークに表示され インスタンスレベルの高可用性が提供されます この構成は 以前のバージョンの SQL Server で使用可能であった SQL Server FCI 機能に対する機能拡張です SQL Server 2008 R2 とそれ以前のバージョンでは SQL Server は起動時にフェイルオーバークラスターリソースグループ内のすべての IP アドレスを反復的に処理してすべての IP アドレスのバインドを試み バインディングエラーが発生すると SQL Server の起動が失敗していました このため SQL Server 2008 R2 とそれ以前のバージョンでは 拡張 VLAN を使用して SQL Server 複数サイトフェイルオーバークラスタリングを実現していました SQL Server 2012 では 複数サイト 特にマルチサブネットフェイルオーバークラスタリングの実装に対する改善が行われています マルチサブネットクラスタリングをサポートするために行われた 2 つの主要な機能拡張は 次のとおりです 16

17 クラスターセットアップのサポート : 統合インストール用の AddNode および拡張インストール用の CompleteFailoverCluster の両方で マルチサブネット環境をインテリジェントに検出し OR に対する IP アドレスリソースの依存関係を自動的に設定できます SQL Server エンジンのサポート :SQL Server のリソースをオンラインにするために SQL Server エンジンの起動ロジックでは オンライン状態でない IP アドレスへのバインディングをスキップします ( 図 2 を参照 ) 図 2. クラスタープロパティ : 依存関係 AlwaysOn 可用性グループ AlwaysOn 可用性グループは 可用性データベースと呼ばれる 同時にフェイルオーバーする特定のユーザーデータベースのセットのフェイルオーバー環境をサポートします AlwaysOn 可用性グループでは WSFC ノード上に SQL Server インスタンスが構成されている必要があるのは AlwaysOn フェイルオーバークラスタリングと同様ですが それらのインスタンスはネットワークに対して個別のコンピューターとして表示されます 可用性グループは 一連のプライマリデータベースと それに対応する 1~4 個のセカンダリデータベースをサポートします 可用性グループは可用性レプリカのレベルでフェイルオーバーし オプションでセカンダリデータベースを読み取り専用アクセスおよび一部のバックアップ操作に使用できるようにすることができます 可用性レプリカと役割 可用性グループは 可用性レプリカと呼ばれる複数のフェイルオーバーパートナーのセットで構成されます それぞれの可用性レプリカは SQL Server の個別インスタンスでホストされ それぞれの SQL Server インスタンスは WSFC クラスターの個別ノード上に存在します それぞれの SQL Server インスタンスは SQL Server FCI( 図 3 を参照 ) または AlwaysOn 可用性グループが有効化されたスタンドアロンインスタンス ( 図 4 を参照 ) のいずれかです 17

18 図 3. Microsoft SQL Server FCI 図 4. Microsoft SQL Server AlwaysOn 可用性グループ 18

19 表 5 では FCI ノードと可用性グループレプリカの機能を比較しています 表 5. FCI ノードと可用性グループレプリカの比較 機能 FCI 内のノード可用性グループ内のレプリカ WSFC クラスターの使用はいはい ストレージタイプ共有非共有 ストレージのフェイルオーバーの実行 はい いいえ 保護レベルインスタンスデータベース ノード / レプリカの数標準 : 2 5( プライマリを含む ) エンタープライズおよびデータセンター : 16 読み取り可能なセカンダリコピー 適用可能なフェイルオーバーポリシー設定 フェイルオーバーするリソース いいえ WSFC クォーラム FCI 固有 可用性グループの設定 サーバー インスタンス データベース はい WSFC クォーラム可用性グループの設定データベースのみ プライマリとセカンダリの役割 それぞれの可用性レプリカは 可用性グループ内の可用性データベースのコピーをホストします それぞれの可用性レプリカには 最初にプライマリまたはセカンダリの役割が割り当てられます プライマリレプリカ : プライマリの役割を保持し 1 つのみ存在させることができる プライマリレプリカは プライマリデータベースと呼ばれる読み取り / 書き込みデータベースをホストします セカンダリレプリカ : 最大 4 つをサポートし それぞれがセカンダリの役割を保持 各セカンダリレプリカは読み取り専用データベースをホストします セカンダリレプリカ 各セカンダリレプリカは フェイルオーバー時にプライマリレプリカに移行するように構成できます 初期可用性グループが作成された後 可用性グループに追加するその他のデータベースは プライマリレプリカをホストするサーバー上のオンラインの読み取り / 書き込みデータベースでなければなりません 可用性グループに新しいデータベースを追加すると クライアントに対してデータベースがオンライン状態に維持されますが データと移行ログのバックアップがセカンダリレプリカホストにリストアされるまで セカンダリコピーは存在しません ( リストアに使用する RESTORE WITH NORECOVERY では リストアプロセスの UNDO フェーズを省略し コミットされていないトランザクションを保存します これにより 追加のバックアップをリストアしてデータベースをさらに先の時点までロールフォワードすることができます ) 19

20 新しいセカンダリデータベースは 可用性グループへの参加が完了するまで RESTORING 状態としてマークされます 可用性グループへのセカンダリデータベースの参加が完了すると セカンダリデータベースの状態は ONLINE に変わります すると可用性グループは セカンダリデータベースとそれに対応するプライマリデータベースの間でデータの同期を開始します 同期化中 プライマリレプリカからセカンダリレプリカにプライマリデータベースのトランザクションログレコードが送信されます 次に セカンダリレプリカからディスクにトランザクションログレコードが書き込まれ ( ログの書き込み ) ログレコードがセカンダリデータベースに適用されます たとえば 場合によってはフェイルオーバー中に可用性レプリカの役割を特定できないことがあります その場合は 可用性グループ内のデータベースは NOT SYNCHRONIZING( 同期しない ) 状態にあるとしてマークされ レプリカの役割が特定されるまで それらのデータベースの役割は RESOLVING と設定されます 可用性レプリカがプライマリの役割と特定された場合 データベースはプライマリデータベースになり セカンダリの役割と特定された場合 データベースはセカンダリデータベースになります 読み取り可能なセカンダリレプリカ セカンダリレプリカは セカンダリの役割である間はローカルデータベースへの読み取り専用クライアント接続を受け入れるように構成できます このようなセカンダリデータベースを読み取り可能なセカンダリレプリカと呼びます 注 これらのセカンダリデータベースは読み取り専用に設定されません 静的な読み取り専用データベースとは異なり セカンダリレプリカつまりセカンダリデータベースは動的であり 対応するプライマリデータベースの変更が適用されるたびに継続的に変更されます バックアップの選択 セカンダリレプリカは データベース全体 ファイル ファイルグループのバックアップのみ およびログバックアップのみのコピーの実行もサポートしています 可用性グループの作成時に複数の設定項目を指定して バックアップに使用するレプリカの選択を制御できます バックアップの選択の設定 : Prefer Secondary この可用性グループの自動化されたバックアップはセカンダリレプリカに対して実行されます セカンダリレプリカが使用可能でない場合 バックアップはプライマリレプリカに対して実行されます Secondary only この可用性グループの自動化されたすべてのバックアップはセカンダリレプリカに対して実行されます Primary この可用性グループの自動化されたすべてのバックアップは現在のプライマリレプリカに対して実行されます Any Replica バックアップは可用性グループ内の任意のレプリカに対して実行されます 20

21 これらの選択により バックアップの優先度 ( 最低 =1 最高 =100) を指定することや 特定のレプリカを除外することもできます 可用性モード それぞれの可用性グループには可用性モードが設定されます これにより 対応するセカンダリレプリカでトランザクションログがディスクに書き込まれる ( ログの書き込み ) まで プライマリレプリカがデータベースへのトランザクションのコミットを待機する必要があるかどうかが決定します AlwaysOn 可用性グループは 2 種類の可用性モードをサポートします 非同期コミットモード 非同期コミットモードでは プライマリレプリカは非同期コミットレプリカでのログの書き込み完了の確認がなくても トランザクションをコミットします 非同期コミットモードではトランザクションのレーテンシが最小限に抑えられ セカンダリデータベースでプライマリよりもコミットが遅れることを許可します このため データ消失の可能性があります 同期コミットモード 同期コミットモードでは プライマリレプリカは同期コミットセカンダリでのログの書き込み完了の確認を待ってから トランザクションをコミットします 同期コミットモードではトランザクションのレーテンシが増加しますが データ消失が防止されます つまり セカンダリデータベースがプライマリデータベースと同期された状態にある限り コミットされたトランザクションは完全に保護されます 可用性グループリスナー 可用性グループリスナーを作成することによって 指定した可用性グループのデータベースでクライアントの接続性が提供されます これは VNN( 仮想ネットワーク名 ) となる一意の DNS 名であり 可用性グループに接続されて クライアント接続を適切な可用性レプリカに経路指定するリソースのセットを提供します 可用性グループリスナーを使用すると マルチサブネット環境におけるクライアント接続が効果的に確保されます 可用性グループリスナーの要素は次のとおりです VNN( 仮想ネットワーク名 ) リスナーポート ( 着信リクエストをリスンする ) 1 つ以上のサブネット用に構成された 1 つ以上の VIP( 仮想 IP) DHCP( 動的ホスト構成プロトコル ) または固定 IP を使用するための構成 ( 固定 IP を推奨 ) リスナーは プライマリレプリカに読み取り / 書き込み接続をリダイレクトし 適切に構成された読み取り専用のセカンダリレプリカに読み取り専用接続をリダイレクトします プライマリレプリカがオフラインになり プライマリの役割がターゲットのセカンダリレプリカに移行した場合は そのレプリカがプライマリレプリカになり 可用性グループリスナーは新しいプライマリにクライアント接続をリダイレクトします また 新しいプライマリに対するすべての新しい読み取り専用接続は 適切に構成されたセカンダリにリダイレクトされます ( 可能な場合 ) 21

22 可用性グループリスナーポートの構成時には SQL Server 用のデフォルトポートである TCP ポート 1433 を使用して構成をシンプルにすることができます 代替ポートを使用する場合は クライアント接続文字列にポート番号を含めて 適切なファイアウォール設定を適用する必要があります また ポートの競合が発生するのを回避するために クラスターノード上の他のサービスではこのポートを使用しないでください 可用性グループリスナーは 1 つの SQL Server インスタンス上の複数の可用性グループリスナー間で構成されている同じポートを共有することもできます ただし 同じポートをリスンするように SQL Server のマルチインスタンス ( サイドバイサイド ) を構成しないでください 注 可用性グループで保護するデータベースに対するクライアントアクセスのための接続文字列を構成する方法の詳細については msdn.microsoft.com を参照してください フェイルオーバーモード SQL Server 2012 の可用性グループを使用したフェイルオーバーでは ターゲットのセカンダリレプリカがプライマリレプリカに移行し プライマリの役割を引き継ぎます フェイルオーバーの形式は 3 種類あります このうちの 2 種類 ( 自動フェイルオーバーと計画的な手動フェイルオーバー ) では レプリカを同期コミットモードにする必要がありますが 潜在的にデータ消失なしです 3 つ目のオプション ( 強制フェイルオーバー ) ではデータ消失のリスクがありますが これは非同期コミットモードで使用できる唯一のオプションです 自動フェイルオーバー ( データ消失なし ) 自動フェイルオーバーでは プライマリレプリカとターゲットのセカンダリレプリカが同期コミットモードで実行され セカンダリレプリカが Synchronized( 同期 ) 状態である必要があります また WSFC クォーラムを構成し そのクォーラムが可用性グループの柔軟性の高いフェイルオーバーポリシーで指定された条件を満たす必要があります 詳細については WSFC クォーラムモードと投票の構成 を参照してください フェイルオーバーは プライマリレプリカの障害に応じて発生します セカンダリレプリカがプライマリの役割に移行され プライマリレプリカになります 元のプライマリレプリカがリカバリされて使用可能な状態になると そのレプリカはセカンダリの役割に移行されます このレプリカは 再び Synchronized( 同期 ) 状態になるまでプライマリレプリカになることはできません 注 SQL Server FCI では AlwaysOn 自動フェイルオーバーがサポートされません FCI でホストされる可用性レプリカは手動フェイルオーバー用としてのみ構成できます 自動フェイルオーバーが必要な場合は SQL Server インスタンスを WSFC の一部として構成する必要があります 計画的な手動フェイルオーバー ( データ消失なし ) 手動フェイルオーバーでは プライマリレプリカとターゲットのセカンダリレプリカが同期コミットモードで実行され セカンダリレプリカが Synchronized( 同期 ) 状態である必要があります フェイルオーバーが発生するのは ターゲットのセカンダリレプリカがプライマリの役割に移行され プライマリレプリカになるための手動フェイルオーバーコマンドが発行された後です 元のプライマリレプリカはセカンダリレプリカになります 22

23 強制手動フェイルオーバー ( データ消失の可能性あり ) 強制手動フェイルオーバーは プライマリレプリカとセカンダリレプリカが非同期コミットモードで実行されている場合に使用できる唯一のオプションです フェイルオーバーが発生するのは ターゲットのセカンダリレプリカがプライマリの役割に移行され プライマリレプリカになるための手動フェイルオーバーコマンドが発行された後です 注 プライマリレプリカとセカンダリレプリカが同期コミットモードで実行されていて セカンダリレプリカが Synchronized( 同期 ) 状態でない場合に使用可能な唯一のオプションは この強制手動フェイルオーバーです 強制手動フェイルオーバーは手動で開始する必要があるため 一種の手動フェイルオーバーといえます フェイルオーバーが発生する原因は データベースの問題 ( データファイルの消失 データベースの削除 トランザクションログの破損よってデータベースに障害が発生している可能性がある場合など ) ではありません 管理とモニタリング AlwaysOn 可用性グループの導入により 管理および監視のためのさまざまな機能とメトリックが SQL Server の管理者に提供されます Microsoft では 管理や監視を容易にする次のような一連の機能を提供しています これらの機能はすぐに利用可能です SSMS(SQL Server Management Studio) システムモニター ( パフォーマンスカウンター ) T-SQL(Transact-SQL) PowerShell SQL Server Management Studio SSMS は 通常のオブジェクトエクスプローラーウィンドウを使用して可用性グループを作成 編集 監視する機能を管理者に提供します 可用性グループの作成が完了すると 集中型の可用性グループダッシュボードが使用可能になります オブジェクトエクスプローラーで [AlwaysOn 高可用性 ] オブジェクトまたは [ 可用性グループ ] オブジェクトを右クリックすると 図 5 に示すように 構成済みのすべての可用性グループの詳細が表示され 可用性グループのプライマリインスタンス そのフェイルオーバーモード 現在の警告が一覧表示されます オブジェクトエクスプローラーで可用性グループ名を右クリックするか またはダッシュボードで可用性グループ名をクリックすると 図 5 に示すように 選択した可用性グループの詳細ダッシュボードビューを開くことができます 23

24 図 5. 可用性グループ OLTP_AG1 の詳細ダッシュボードビュー 図 5 に示すように このビューには 同期の状態やフェイルオーバーの準備などの詳細 および [ フェイルオーバーウィザードの開始 ] などのオプションが表示されます 注 可用性グループが非同期コミットモードで実行されている場合は ラグが発生し セカンダリレプリカが待機状態のままになるため セカンダリレプリカが常に 同期化中 と表示されます また ダッシュボードは柔軟に構成できます デフォルトビューを編集したり 多数の追加設定や統計を表示したりできます ダッシュボードビューのカスタマイズの詳細については msdn.microsoft.com を参照してください 24

25 AlwaysOn 可用性グループの構成 概要 以下のセクションでは 2 つの SQL Server インスタンスに AlwaysOn 可用性グループを実装するプロセスの概要を示します プライマリサーバーは本番サイトにあり セカンダリサーバーは複数のサブネットにまたがる DR サイトにあります 両方のサーバーは 2 台の VNX5700(1 サイトにつき 1 台 ) に接続されています 前提条件 WSFC WSFC クォーラムモードと投票の構成 AlwaysOn 可用性グループを実装する前に 最新の要件を必ず確認してください 最新の前提条件は msdn.microsoft.com で確認できます SQL Server 2012 の可用性グループ作成のための構成の一部として EMC では Windows Server 2008 R2 上に 2 ノードの複数サイトのクラスターを構成しました WSFC および SQL Server AlwaysOn 可用性グループの設定の詳細については msdn.microsoft.com を参照してください SQL Server AlwaysOn 可用性グループと AlwaysOn FCI では WSFC テクノロジーを利用します WSFC では クォーラムベースのアプローチを使用して クラスターの全体的な稼働状態のモニタリングを実施し ノードレベルのフォルトトレランスを最大限に高めます WSFC クラスター内の各ノードでは ハートビートシグナルを発行して ノードの稼働状態のステータスをクラスター内の他のノードと共有します 応答しないノードは障害が発生していると見なされます クォーラムノードセットは WSFC クラスター内の大多数の投票ノードおよび監視サーバーです WSFC クラスターのステータスと稼働状態は 定期的なクォーラムの投票に基づいて決定されます クォーラムの存在は クラスターが正常な状態で ノードレベルのフォルトトレランスを提供できることを示します クォーラムの投票が失敗すると WSFC クラスターはオフライン状態になり クラスター内のすべての SQL Server インスタンスが停止します クォーラムの障害が原因で WSFC クラスターがオフラインになった場合 WSFC クラスターを再び起動するには 手動による介入が必要になります Windows Server 2008 R2 には 次の 4 種類のクォーラムモードがあります ノードマジョリティ : ホストの台数が奇数の場合に使用します この場合 各ノードが 1 つの票を持ちます この構成にファイル共有やディスク監視はありません クォーラムを作成するには 過半数のノードが使用可能である必要があります ノードおよびファイル共有マジョリティ : 複数サイトのクラスター内のノード数が偶数の構成で使用されます この場合 ファイル共有が投票の監視サーバーとして構成されます これにより ディスク監視が使用可能な場合は 半数のノードの障害に耐えることができます ディスク監視を使用できない場合 クォーラムを作成するには過半数のノードが使用可能である必要があります ノードおよびディスクマジョリティ : ノード数が偶数の構成で使用されます ただし この場合のノードは複数サイトのクラスターに含まれていないノードです この構成では ノードと共有ディスクに投票権が与えられます これにより ディスク監視が使用可能な場合は 半数のノードの障害に耐えることができます ディスク監視を使用できない場合 クォーラムを作成するには過半数のノードが使用可能である必要があります 25

26 ディスクのみ : この構成では 共有ディスクリソースが監視サーバーとして使用されます クォーラムを作成するには ディスク監視が使用可能である必要があります このソリューションには ノード数が偶数の複数サイトのフェイルオーバークラスターがあるため ノードおよびファイル共有マジョリティのクォーラム構成が使用されています クラスター外部のホストには ファイル共有監視が構成されています このソリューションでは サーバー ProdDC 上に Witness という共有が作成されています CorkCluster というクラスターには その共有に対する読み取り / 書き込み権限 ( 共有レベルと NTFS レベルの両方の権限 ) が付与されています 適切な権限を持つ共有フォルダーを構成した後に クォーラムの種類を変更しました この処理は フェイルオーバークラスターマネージャーを使用して 次のステップで行われました 1. クラスターを右クリックして [ その他のアクション ] を選択し [ クラスタークォーラム設定の構成 ] を選択します 2. クォーラム構成として [ ノードおよびファイル共有マジョリティ ] を選択します 3. ウィザードの指示に従って 作成したファイル共有 (Witness) へのパスを入力します ウィザードの残りのステップが完了すると 図 6 に示すように フェイルオーバークラスターマネージャーにクォーラム構成として ノードおよびファイル共有マジョリティ が表示されます 図 6. フェイルオーバークラスターマネージャー : クォーラム構成 ノードおよびファイル共有マジョリティクォーラムの主要な構成の 1 つでは ファイル共有監視を配置します 次の 3 つの配置オプションがあります プライマリサイトにファイル共有を配置する 本番サイト全体で障害が発生した場合 DR サイトのセカンダリノードはクラスター内に残る唯一の投票になるため 自動的にはオンラインにならず ユーザーの入力によってクォーラムを手動で強制的にオンラインにする必要があります セカンダリサイトにファイル共有を配置する このオプションによって DR サイトにおける自動リカバリの問題は解消されますが 誤ったフェイルオーバーが行われる可能性もあります たとえば DR サイトで障害が発生した場合は プライマリが監視サーバーに接続できず 投票数が 1 のみになるため プライマリもオフライン状態になります 26

27 3 番目のサイトにファイル共有を配置する これは ファイル共有クォーラムの配置に最適なオプションです 本番サイトと DR サイト全体が停止した場合は 3 番目のサイト上のファイル共有があるために どのサイトも単一障害点にはなりません このシナリオでは サイトが停止した場合にクラスターが自動的にフェイルオーバーされます このソリューションでは 2 サイトのシナリオを使用しているため プライマリサイトにファイル共有を配置するオプションを実装して 本番サイトのホストにファイル共有マジョリティクォーラムを配置しています AlwaysOn の有効化 SQL Server 構成マネージャーで AlwaysOn 高可用性を有効にする方法は次のとおりです 1. SQL Server 構成マネージャーを開きます 2. SQL Server エンジンサービスを右クリックします 3. [AlwaysOn 高可用性 ] をクリックし 図 7 に示すように [AlwaysOn 可用性グループを有効にする ] チェックボックスをオンにします クラスターの 2 つのノード上の両方のインスタンスに対してこの操作を行う必要があります 注 AlwaysOn を有効にするには ノードとインスタンスの両方で SQL Server サービスを再起動する必要があります 図 7. SQL Server 構成マネージャーでの AlwaysOn 高可用性の有効化 27

28 ストレージ設計 概要 SQL Server AlwaysOn 可用性グループを使用して 本番サイト上のプライマリデータベースを DR サイト上のセカンダリレプリカのコピーにレプリケートする場合は DR サイトへのフェイルオーバー後のストレージのパフォーマンスを考慮することが重要です 次のセクションでは SQL Server のデータファイルをホストするためのストレージプールのサイズ設定に関する検討事項を示します このソリューションでは トランザクションログと Tempdb ファイルが専用のスピンドルに分離され 従来の RAID 1/0 RAID グループをホストします また ターゲットワークロードにサービスを提供する VNX ストレージアレイで必要とされる機械回転ディスクのボリュームが大幅に削減される場合に FAST Cache が及ぼす影響に関する検討事項も示されます VP プールと FAST Cache のサイズ設定 このセクションでは 特定のワークロードに対処するために必要な回転ディスク数を決定する場合の FAST Cache の影響について説明します このソリューションで使用している 特定の OLTP と同様のワークロードでは 読み取り / 書き込み率が 9:1 の 50,000 件の IOPS が生成されます RAID 構成のライトペナルティの影響のため RAID 5 構成は RAID 1/0 と比較してバックエンド IOPS が増加しますが 各構成には特定のワークロードプロファイルに関して独自の利点があります 注 FAST Cache によってもたらされる潜在的なパフォーマンスの向上は ワークロードと構成されているキャッシュ容量に依存します 参照のローカル性が高く ブロック長が短く 並列性が高い ランダム読み取り I/O のワークロードは FAST Cache から最大のメリットを得ることができます シーケンシャル I/O で構成されるワークロードでは 最小限のメリットしか得られません ストレージプールでは RAID 5 保護レベルが使用され 読み取り / 書き込み率が 9:1 のワークロードを処理するように容量と機能のバランスを調整します ストレージプールは 40 台の 2.5 インチ 10k SAS ドライブを使用する同種プールとして作成されます 14 台の 3.5 インチ 100 GB フラッシュドライブからなる FAST Cache 構成によって ソリューションの機能のバランスが調整され 641 GB の FAST Cache を使用できるようになります このソリューションで 40 台の SAS ディスクからなるプールは 7,652 件のホスト IOPS を 65% の使用率で処理できますが FAST Cache は 42,348 件のホスト IOPS を処理できます 表 6 に 50,000 件の I/0 ワークロードを処理するために必要な物理回転メカニカルドライブの数を示します FAST Cache を使用すると パフォーマンス能力が向上し ディスク数が大幅に削減されます 表 6. テスト環境の論理ドライブ ドライブのタイプディスク数仕様 RAID タイプ フラッシュドライブ GB RAID 1 SAS(10k) GB RAID 5 28

29 バックエンドディスクの IOPS の計算 ホスト IOPS は 表 6 に示すように 50,000 件です 通常 バックエンド IOPS 件数は さまざまな I/O ライトペナルティのためにホスト IOPS よりも多くなります これは 使用される RAID 保護テクノロジーによっても変わります SAS 単独の同種プールで 50,000 件の IOPS に対処するために必要なドライブ容量を決定するには 次のように 対応するバックエンド IOPS を RAID 5 プールについて計算します 構文 : バックエンドディスク IOPS = ホスト読み取り IOPS + 4 x ホスト書き込み IOPS 計算バックエンドディスク IOPS = 0.9 x 50, * (0.1 x 50,000)) = 65,000 SAS のみの構成のディスク要件の計算 このソリューションでは プールのために 600 GB 10k 2.5 インチ SAS ディスク (1 ディスクあたりの処理能力は 150 IOPS) が使用されます 比較できるように 次の計算にはこのディスクのディスク要件と 300 GB 15k 3.5 インチ SAS ディスクのディスク要件を含めています 後者は 小さいブロックのランダム I/O パフォーマンス ( この環境の I/O ワークロード ) の場合に 180 IOPS を処理できます 構文 : ディスク要件 = バックエンドディスク IOPS/ ディスクあたりの IOPS 処理能力 計算 (600 GB 10k SAS ドライブ ) 65,000 / 150 = 433 ディスク 計算 (300 GB 15k SAS ドライブ ) 65,000 / 180 = 361 ディスク FAST Cache ソリューションと SAS のみのソリューションの比較 このソリューションの FAST Cache 構成は 14 台の 100 GB フラッシュドライブと 40 台の 600 GB 10k SAS ドライブで作成されます 表 7 に FAST Cache がない場合に 50,000 件の I/0 ワークロードを処理するために必要な SAS ドライブの数を示します この表では 300 GB 15K SAS ドライブ構成と 600 GB 10K SAS ドライブ構成が FAST Cache ソリューションと比較されます 表 7. FAST Cache ソリューションに相当する SAS ディスク要件 FAST Cache ソリューション 300 GB 15K SAS 600 GB 10K SAS フラッシュドライブ SAS ドライブ フロントエンド IOPS の合計 50,000 50,000 50,000 29

30 図 8 では 使用可能なストレージ TB を提供する 14 台のフラッシュドライブと 40 台の SAS ディスクは 拡張の余地も十分にあり 1.8 TB のデータベースに適していることが示されます これと同等の SAS のみのプール (300 GB 15k と 600 GB 10K) は次のとおりです 433 台の 600 GB 10k SAS ディスクにより 有効容量 TB のストレージが提供される つまり 未使用ストレージは約 TB です 361 台の 300 GB 15k SAS ディスクによって 有効容量 TB のストレージが提供される つまり 未使用ストレージは約 TB です 図 8. 50,000 件の IOPS を処理する計算に基づく SAS 容量およびフラッシュドライブ容量 この図から FAST Cache テクノロジーを適切に使用すると VNX5700 を最適なパフォーマンスレベルで使用でき ROI( 投資収益率 ) を上げ TCO( 総所有コスト ) を削減できることが明らかです FAST Cache ドライブと 40 台の SAS が前述の 50,000 件の IOPS を処理できるということから 14 台のフラッシュドライブが 集約型の OLTP と同様のワークロードに最適であることが分かります 30

31 ストレージ構成 このソリューションの本番ストレージ構成を表 8 に示します 表 8. 本番アレイストレージ構成 RAID タイプ プール /RAID グループ ディスク構成 目的 RAID 5 SAS ドライブプール ( プール : 本番 OLTP データ ) 2.5 インチ 600 GB 10k SAS x 40 OLTP データベースデータファイル RAID 5 SAS RAID グループ (RAID グループ 0) 3.5 インチ 600 GB 10k SAS x 4 SQL Server システムデータベース RAID 1/0 SAS RAID グループ (RAID グループ 1) 2.5 インチ 600 GB 15k SAS x 4 SQL Server TempDB RAID 1/0 SAS RAID グループ (RAID グループ 2) 2.5 インチ 600 GB 10k SAS x 8 OLTP データベースログ RAID 1 フラッシュドライブ FAST Cache プール 3.5 インチ 100 GB フラッシュドライブ x 14 FAST Cache プール このソリューションの DR ストレージ構成を表 9 に示します 表 9. DR アレイストレージ構成 RAID タイプ プール /RAID グループ ディスク構成 目的 RAID 5 SAS ドライブプール ( プール : 本番 OLTP データ ) 2.5 インチ 600 GB 10k SAS x 40 OLTP データベースデータファイル RAID 5 SAS RAID グループ (RAID グループ 0) 3.5 インチ 600 GB 10k SAS x 4 SQL Server システムデータベース RAID 1/0 SAS RAID グループ (RAID グループ 1) 3.5 インチ 600 GB 15k SAS x 4 SQL Server TempDB RAID 1/0 SAS RAID グループ (RAID グループ 2) 2.5 インチ 600 GB 10k SAS x 8 OLTP データベースログ 31

32 VNX5700 ストレージ割り当て 表 10 に このソリューションのためにプロビジョニングされた VNX5700 アレイのストレージ LUN の詳細を示します 表 10. SQL Server LUN の設計 名前 RAID タイプ ストレージプール ユーザー容量 (GB) 現在の所有者 FAST Cache OLTP1_DATA_1 RAID 5 プール PROD 450 SP A オン OLTP1_DATA_2 OLTP データ 450 SP A オン OLTP1_DATA_3 450 SP A オン OLTP2_DATA_1 200 SP B オン OLTP2_DATA_2 200 SP B オン OLTP2_DATA_3 200 SP B オン OLTP3_DATA_1 175 SP B オン OLTP3_DATA_2 175 SP B オン OLTP4_DATA_1 100 SP A オン OLTP1_Log RAID 1/0 RAID グループ SP A オフ OLTP2_Log 100 SP B オフ OLTP3_Log 100 SP B オフ OLTP4_Log 100 SP A オフ SYSTEM_DB RAID 5 RAID グループ 0 10 SP B オフ TempDB_Data_1 RAID 1/0 RAID グループ SP B オフ TempDB_Data_2 400 SP B オフ TempDB_Log 200 SP B オフ 表 10 から LUN プロビジョニング中に ワークロードの要件を見込んだストレージプロセッサ全体のバランス調整が行われたことが分かります 注 注 バランス調整では 割り当てられた LUN によって処理される合計 I/O が使用されます 各ストレージプロセッサに割り当てられる LUN の数ではありません VNX 上で物理ポートに対してフラッシュドライブを分離できることに注意してください 詳細については EMC オンラインサポートで入手できる VNX Best Practice ドキュメント 特に Back-end SAS Port Balancing section を参照してください 保持するファイル数を増やすことで SQL Server が一度にディスクに出力できる物理 I/O 動作数を増やすことができます SQL Server がディスクレベルに出力できる I/O が多くなるほど データベースの実行速度が速くなります これが データベースごとに多くの物理ファイルを保持する理由です 32

33 データベースファイル設計から分かるように データファイルは各 OLTP データベースで同じサイズにする必要があります SQL Server では 空き領域が大きいファイルに優先して割り当てる比例書き込みアルゴリズムが使用されるためです RAID グループの使用 SQL Server ログファイルのベストプラクティスは RAID 1/0 の使用です OLTP ログは 64 KB のシーケンシャル書き込み I/O パターンを含みます したがって 8 台の 2.5 インチ 600 GB 10k SAS による RAID グループ 2 の構成は ログファイルの場所として最適です また 物理ディスクレベルでログをデータから分離することもベストプラクティスです Tempdb を RAID 1/0 構成に配置した場合もパフォーマンスが向上します Tempdb は書き込み率が高いため 使用するのに最適な構成は RAID1/0 です このソリューションでは Tempdb は RAID 10 の 4 台の 2.5 インチ 600 GB からなるグループ内の専用の物理ディスクに存在します ストレージプール 仮想的にプロビジョニングされたプールを容易に作成できます ユーザーが入力する必要があるのは次の項目だけです プール名 ディスク : 数とタイプ 保護レベル : RAID 5 6 1/0 このソリューションでは RAID 5 保護レベルが使用されています ( 図 9) これは 40 台の SAS ドライブを使用する同種プールとして作成されます Virtual Provisioning は RAID 5 プール用の 40 台のドライブから 8 個の 5 ドライブ (4+1) RAID グループを作成します 図 9. ストレージプールのプロパティ : 全般設定 33

34 シードのための共有ストレージ要件 共有ストレージ領域が必要になるのは 可用性グループ作成において初期データ完全同期化を実行するときです シードおよび再シードプロセスの時間を最小限に抑えるために ユーザーはこれらのデータベースのバックアップとリストアで使用されるストレージ領域について検討する必要があります バックアッププロセスは シーケンシャル書き込み / 読み取りワークロードであるため ストレージに対して広帯域幅要件が生じます AlwaysOn 可用性グループを作成するためのデータベースのシード / 再シードには RAID 1/0 が最適です ただし 可用性グループが含むすべてのデータベースの再シードに対応できるように適切な領域を予約する必要があるため 管理者は他の RAID タイプの使用を選択して 容量の使用量を調整することもできます FAST Cache FAST Cache は RAID 1 ペアドライブプロビジョニングを使用し ミラーデータ保護に加えて 読み取りと書き込み両方のキャッシュを提供します すべての FAST Cache ドライブは同じ容量であることが必要です FAST Cache は安全です 統合 LUN テクノロジー上で構築されているため FAST Cache のデータは他の LUN の場合と同様に安全です 不揮発性ストレージで 電源や SP の障害時にもデータが保持されます また 停電の後で再ウォームする必要がありません FAST Cache はすべての LUN でメリットがあり metalun と FLARE LUN では LUN レベル プール LUN ではプールレベルで制御されます 実用的には 少なくとも 4 台のフラッシュドライブを FAST Cache で使用することを推奨します ドライブ数が増えると 並列性が向上して ストレージプロセッサの競合が減少するため キャッシュの役割の効率性が高くなります このソリューションでは 14 台の 3.5 インチ 100 GB フラッシュドライブを FAST Cache 構成で使用しています これには 7 個のミラーペアが含まれます OLTP データベースのデータファイルを含む 同種の 40 台の 2.5 インチ 600 GB 10k SAS ディスクプールに対して FAST Cache を有効化します FAST Cache をバス全体に分散するために 8 台のドライブがバス 0 6 台のドライブがバス 2 を使用するように構成します FAST Cache は ログファイルまたは TempDB をホストする RAID グループ LUN に対しては有効化されません 小さなシーケンシャルワークロードの場合にはパフォーマンスが向上せず 不要なエントリーでトラッキングマップが一杯になるためです シーケンシャルデータは再使用されることがほとんどないため Fast Cache のメリットがありません EMC では 小さなシーケンシャル I/O(128 KB 未満のシーケンシャル ) の読み取りまたは書き込みであることが明らかなワークロードでは FAST Cache を使用しないように推奨しています FAST Cache の有効化 これは 1 回クリックするだけの単純かつ透過的なプロセスです SQL Server レベルでの変更は必要ありません FAST Cache を作成するとき プロセスが完了するまで ストレージシステムの読み取り / 書き込みキャッシュが無効になります この結果 ストレージシステムの書き込みキャッシュがゼロになるようにフラッシュされます その後 少ないメモリで自動的に再構成されます 読み取り / 書き込みキャッシュが無効になっている間 全体的なパフォーマンスは低下する可能性があります 34

35 FAST Cache を完全に構成するためにかかる時間は キャッシュのサイズとストレージシステムのワークロードアクティビティによって異なります FAST Cache が大きければ 構成時間も長くなります 低アクティビティで FAST Cache が小さいクワイエットシステムでは 数分で構成できます 負荷がかかっているストレージシステムでの大きな FAST Cache の構成には 1 時間以上かかる場合があります ドライブの FAST Cache への追加順序は バインド順序と同じです これは naviseccli を使用すると 最も容易に実行できます FAST Cache 構成を作成 破棄 表示するために使用するスイッチは以下のとおりです Cache fast create Cache fast destroy Cache fast info たとえば 以下のコマンドは ディスク 4 とディスク 5 をそれぞれプライマリとセカンダリとしてバインドし ディスク 6 とディスク 7 をバス 0 エンクロージャ 0 にバインドします naviseccli -h IP cache -fast -create -disks 0_0_4 0_0_5 0_0_6 0_0_7 -mode rw -rtype r_1 FAST Cache が作成され 完全に初期化されたら ストレージプールに対する FAST Cache の有効化は 単純なタスクです これを図 10 に示します 図 10. ストレージプールのプロパティ : 詳細設定 EMC Storage Integrator Unisphere 管理スイートによるストレージの管理だけでなく ESI の使用というオプションが用意されています ESI は Windows 環境での EMC ストレージの管理 表示 プロビジョニングを大幅に簡素化できます さらに EMC ユーザーは ESI を無償で使用できます ESI for Windows は ストレージの表示機能とプロビジョニング機能を提供します 表示機能の一部として Windows をストレージリソースマッピングに表示します ストレージのプロビジョニングでは ESI は パーティション設定 フォーマット ドライブ名の作成ステップのための LUN の作成と LUN の準備に関わるステップを簡素化します さらに ESI を使用してファイル共有を作成し そのファイル共有をネットワーク接続ドライブとして Windows 環境にマウントできます 35

36 ESI は VMAX VNX VNXe CX4 NS シリーズを ブロックとファイルの両方でサポートします それはエージェント不要のアーキテクチャでもあるため 管理者はエージェントをホストにインストールする必要がありません このソリューションでは ESI を Windows ホストにインストールし それを使用して 本番サイトと DR サイトの両方で SQL Server 2012 ホスト用のストレージをプロビジョニングしました 図 11 に 環境全体の SQL Server ホストと VNX5700 を示します 図は ESI から見た本番 VNX5700 上のストレージプールとすべての LUN を表示しています 図 11. EMC Storage Integrator: ストレージプール ディスクの作成 ホスト用のディスクの作成は ディスク作成ウィザードを使用して容易に実行できます このウィザードは 特定のストレージプールの LUN の作成 LUN の Windows ホストへのマッピング ストレージのホストへの追加に関わるさまざまなステップを簡素化します ESI の使用方法の詳細なステップについては Storage Integrator for Windows 1.3 Product Guide を参照してください 注 このホワイトペーパーでは このソリューションが検証された時点での最新の ESI のバージョンで使用できる機能について説明します EMC は 自社製品とテクノロジーを 新しい機能によって常に改善し 更新しています 最新の機能と更新については japan.emc.com または EMC オンラインサポートを参照してください 36

37 検証 テストの目的 このソリューションのテストでは 50,000 IOPS を超えて生成される OLTP に類するワークロードを実行するインスタンスで SQL Server 2012 をサポートする VNX5700 ストレージアレイの能力を検証しました テストの内容は次のとおりです ストレージアレイにフラッシュドライブを導入し EMC FAST Cache でそれらを利用してパフォーマンスを向上させる AlwaysOn 可用性グループを 以下の可用性モードで比較する 同期コミットモード : 自動フェイルオーバー 同期コミットモード : 手動フェイルオーバー 非同期コミットモード : 強制フェイルオーバー 注 ベンチマークの結果は ワークロード 特定のアプリケーション要件 システムの設計と実装に大きく左右されます これらの要因やその他の要因によって 相対的なシステムパフォーマンスが変動します そのため 重要なキャパシティプランニングや製品評価を検討する際には このワークロードを特定のカスタマーアプリケーションベンチマークの代替として使用しないでください このレポートに含まれるすべてのパフォーマンスデータは 厳密に管理された環境で取得されたデータです 他の動作環境で取得された結果と異なる場合があります テストの方法 テスト方法では OLTP に類するワークロードをターゲットデータベースに対して実行する必要がありました 注 実際のアプリケーションの接続の消失を処理する能力は 設計によって異なります テストで使用されたワークロードを生成するためのツールには特定の動作があり それはお客様の環境を示していない場合があります テストシナリオ EMC では 多数のシナリオを使用してこのソリューションをテストしました 以下が含まれます 40 台の SAS のみで構成されるストレージプールのベースラインテスト FAST Cache が有効なストレージプールのパフォーマンステスト 以下の可用性モードでの AlwaysOn 可用性グループの再シーディング時間の比較とプロファイリング : 同期コミットモード : 自動フェイルオーバー 同期コミットモード : 計画的な手動フェイルオーバー 非同期コミットモード : 強制的な手動フェイルオーバー 以下のフェイルオーバーの検証とプロファイリング : 手動フェイルオーバー 自動フェイルオーバー サイトの接続解除 37

38 パフォーマンステストプロシージャ テストは WSFC とスタンドアロン SQL Server インスタンスで OLTP に類するコンカレントワークロードをターゲットデータベースに対して実行することによって実施されました 注 1. 各 SQL Server インスタンスには データファイル用の独自の RAID 5 ストレージプールがあり トランザクションログが従来の RAID 1/0 グループで実行されていました 2. 安定状態に到達し ベースラインパフォーマンス測定が観察されました 3. 負荷をかけた状態で FAST Cache が有効化され ピークパフォーマンスレベルに到達した状態で再度パフォーマンスが監視されました テスト中 ワークロードプロファイルのパラメーターは変更されませんでした プロファイルは SAS のみのストレージプールを利用するように設定され 環境に対する EMC フラッシュキャッシュの導入によるパフォーマンスに対する影響が示されました このアプローチは ビジーな OLTP 本番環境で FAST Cache を有効化した場合の潜在的なパフォーマンスインパクトを模倣しています FAST Cache は共有リソースであり 処理することを期待される最大ワークロードに合わせて適切にサイズ設定する必要があることに注意してください テスト結果 テストは 以下の領域に分解されました スループット フェイルオーバー スループットテスト 主要なメトリックは以下のとおりです IOPS のスループット ( 転送数 / 秒 ) SQL Server の CPU の利用率 トランザクション数 / 秒 (TPS) のスループット レーテンシ 物理ディスク使用率 (%) ストレージプロセッサ使用率 (%) 可用性グループ作成時間 38

39 IOPS のスループット ( 転送数 / 秒 ) 次の Microsoft Performance Monitor(perfmon) カウンターを使用してスループットを測定しました : 論理ディスク 平均ディスク転送 / 秒 図 12. 平均ディスク転送 / 秒 (IOPS)( プライマリレプリカとセカンダリの両方のレプリカ ) ストレージプール内の 40 台の SAS ディスクを使用したテスト中に プライマリレプリカでのトランザクション I/O スループットは約 11,500 IOPS が生成され セカンダリレプリカでは約 1,400 IOPS が生成されました 30 分後にストレージプールで FAST Cache を有効化したところ パフォーマンスに対する即効性が観察されました I/O スループットは プライマリレプリカで 19,000 IOPS を超え セカンダリレプリカで 2,300 を超えました FAST Cache 実行後わずか 2 時間で プライマリレプリカのスループットが 50,000 IOPS を超えるまで上昇したことを観察しました プライマリレプリカとセカンダリレプリカ間でレプリケートされる読み取り / 書き込みの例として 距離 80 km での 1 TB の OLTP_1 データベースに対する同期コミットモードで FAST Cache 安定状態中のある時点の perfmon カウンターが分析されました これを図 13 に示します 図 13. プライマリレプリカとセカンダリレプリカのディスク読み取り / 書き込みの比較 39

40 プライマリレプリカの読み取りアクティビティのわずか 3.7% がセカンダリレプリカで発生し 書き込みアクティビティは 89.51% 発生していることが分かります この期間中 プライマリレプリカとセカンダリレプリカのトランザクション数 / 秒 (TPS) はどちらも 119 でした これは セカンダリレプリカで読み取りアクセスがなく セカンダリレプリカでの主なアクティビティはレプリケートされる書き込みであることを強調しています SQL Server の CPU の利用率 図 14 に示すように 同期コミットモードが 80 km まで使用された場合 ごくわずかな影響が観察されました 非同期コミットモードの 4,000 km までの使用では CPU の利用率の割合が 4% 上昇したことが示されました すべての同期状態で CPU の最小利用率は セカンダリレプリカデータベースで追加アクティビティが発生していないときに セカンダリレプリカで発生することが分かりました 図 14. 同期状態と距離による SQL Server の CPU への影響 トランザクション数 / 秒 (TPS) のスループット 次の perfmon(microsoft Performance Monitor) カウンターも使用してスループットを測定しました : データベース ディスクトランザクション数 / 秒 図 15. プライマリレプリカとセカンダリレプリカのディスク TPS( トランザクション / 秒 ) ストレージプール内の 40 台の SAS ディスクによるベースラインテスト中に トランザクションアクティビティ (SQL Server TPS として示されます ) は 4,900 TPS を超え セカンダリレプリカでは 300 TPS を超えました 40

41 30 分後にストレージプールで FAST Cache を有効化したところ SQL Server TPS はプライマリレプリカで約 12,000 TPS まで上昇し セカンダリレプリカで約 900 TPS まで上昇しました FAST Cache 実行後わずか 2 時間で トランザクションパフォーマンスが 24,000 TPS を超えるまで上昇したことを観察しました テストは 本番サイトの DR サイト間の距離をエミュレーションして実施され FAST Cache ウォームアップ中は距離 80 km に設定され レプリケーションは同期コミットモードに設定されました その後 距離は 800 km と 4,000 km に順に延長され どちらの距離でもレプリケーションは非同期コミットモードに設定されました レーテンシ レーテンシの監視は 平均ディスク / 秒の読み取りと書き込みを 以下の距離で監視することを通して実行されました 80 km の同期コミットモード 800 km の非同期コミットモード 4,000 km の非同期コミットモード FAST Cache がウォームアップした後 プライマリレプリカでのレーテンシは 距離の 3 つのオプションすべてで 読み取りで 3 ミリ秒未満 書き込みで 1 ミリ秒未満を維持できました これを表 11 に示します ( この表は 表 10 の SQL Server LUN の設計に直接関係しています ) 表 11. 読み取りと書き込みのレーテンシ 平均ディスク / 秒 LUN ID 名前 読み取り 書き込み 100 LUN_100_OLTP1_DATA_ LUN_101_OLTP1_DATA_ LUN_102_OLTP1_DATA_ LUN_200_OLTP1_Log LUN_103_OLTP2_DATA_ LUN_104_OLTP2_DATA_ LUN_105_OLTP2_DATA_ LUN_201_OLTP2_Log LUN_106_OLTP3_DATA_ LUN_107_OLTP3_DATA_ LUN_202_OLTP3_Log LUN_108_OLTP4_DATA_ LUN_203_OLTP4_Log

42 セカンダリレプリカのレーテンシはかなり大きく データファイルでは 20 ミリ秒 ログファイルでは 5 ミリ秒という一般に考えられているルールを大幅に上回っていました ここで考慮する必要があるのは さらにレーテンシを増加させる アクティブなセカンダリコピーに対する読み取りアクティビティが生成されなかったという事実です これは セカンダリレプリカのストレージ設計を慎重に考慮する必要があることを意味します 理由は 不適切に割り当てられたストレージは 維持できる読み取りアクティビティのレベルだけではなく フェイルオーバー発生時の実行とプライマリレプリカの役割への移行というセカンダリレプリカの能力にも影響するためです 物理ディスク使用率 物理ディスク使用率は Unisphere NAR ファイルを分析した後 物理ディスク使用率の割合を調べることで測定されました これを図 16 に示します 図 16. 本番アレイと DR アレイのストレージプールに対する物理ディスク使用率 本番サイトでプライマリレプリカをホスティングしているストレージプールに対する初期ディスク使用率は非常に高い 90% でした FAST Cache が有効化された後 改善が見られました FAST Cache は プールにかかる負荷を軽減できました これは 頻繁にアクセスされるデータが SAS プールからキャッシュに配置されたためです 2 時間のウォームアップ期間が経過した後 本番でのディスク使用率は 90% から 57% に減少しました FAST Cache により SQL Server 2012 に対するストレージパフォーマンスが大幅に向上してプライマリレプリカで処理できる I/O レベルが上がる一方 プライマリレプリカでの書き込みがセカンダリレプリカにレプリケートされるため セカンダリレプリカ用のデータファイルをホスティングしているストレージプールにかかる負荷も同時に増加します これは セカンダリレプリカのストレージを適切にサイズ設定することの重要性を強調しています このソリューションでは 本番ストレージアレイと DR ストレージアレイの両方のストレージプールで 40 台の SAS ディスクを使用しています 差別化要因は 本番サイトではストレージプールで FAST Cache を有効化したことです 42

43 ストレージプロセッサ使用率 ストレージプロセッサ使用率は Unisphere NAR ファイルを分析した後で測定されました これを図 17 に示します 図 17. 本番および DR ストレージアレイ上の SPA および SPB の SP 使用率 本番ストレージアレイの結果は アレイが EMC FAST Cache テクノロジーを通じて自動的にパフォーマンスの向上をもたらすように動作するのにつれて SPA および SPB ストレージプロセッサの使用率がどのように増加するかを示しています SP は頻繁にアクセスされるデータを分析し プロモートします プライマリからセカンダリデータベースにレプリケートされる書き込みデータの増加によるディスク使用率の上昇に伴い DR ストレージアレイの SP 使用率がわずかに増加します 可用性グループ作成時間 可用性グループの作成は スクリプト作成によって または SSMS(SQL Server Management Studio) で新しい可用性グループの詳細を入力するか新しい可用性グループウィザードに従って実行できます ウィザードのステップでスクリプトを生成するオプションもあります 作成時間をテストするために EMC では可用性グループを作成するスクリプトファイルを生成しました このスクリプトは SQL Server コマンドユーティリティである sqlcmd を使用し S server および i file オプションを指定して実行する必要がありました sqlcmd S [Servername] i [filename] 図 18 は 可用性グループ作成の簡略化したプロセスフローを示しています テスト中 複数のデータベースを追加する場合は バックアップ / リストアを実行し セカンダリレプリカを一度に 1 つずつ可用性グループに追加してから ループバックしてその他のデータベースを追加します こうすると データベースが可用性グループに追加されて同期プロセスが開始した時点とリストアプロセスの間隔が長くなりすぎることを回避できます 間隔が長すぎるとプロセスは失敗する可能性があります 43

44 図 18. 可用性グループ作成の簡略化したプロセスフロー 以下のデータの表は 次の場合のデータベース作成時間の概要を示しています 0.8 ミリ秒 (80 km) 同期コミット 8 ミリ秒 (800 km) 非同期コミットモード 40 ミリ秒 (4,000 km) 非同期コミットモード 注 : これらのタイミングは すでに使用中であり 約 50,000 IOPS のフルワークロードで実行されているデータベースの場合です 可用性グループ作成では 可用性グループに含まれる各データベースについて 本番アレイ上でホストされているボリュームに COPY_ONLY フルバックアップとトランザクションログバックアップを取得する必要があります リストアは WAN を経由して実行され セカンダリレプリカが作成されます セカンダリデータベースは 可用性グループの作成が完了してから少し後に状態が Synchronized( 同期 ) に変わった場合 同期コミットモード用に構成されていない限り Synchronizing( 同期化中 ) 状態のままです 表 12. 同期および非同期可用性グループの作成 ( ,000 km) 可用性グループ モード距離所要時間 最大帯域幅 (MB/ 秒 ) バックアップ リストア OLTP_AG1 同期 80 km 4 時間 14m OLTP_AG2 同期 80 km 4 時間 16m OLTP_AG1 非同期 800 km 4 時間 48m OLTP_AG2 非同期 800 km 8 時間 13m OLTP_AG1 非同期 4,000 km 5 時間 50m OLTP_AG2 非同期 4,000 km 8 時間 26m

45 これらのタイミングは 予想どおり 距離が長くなると可用性グループの作成にかかる時間も長くなることを示しています 可用性グループ OLTP_AG1 には 1 TB のデータベースが 1 個しか含まれていませんが 可用性グループ OLTP_AG2 には 3 個のデータベースが含まれています (500 GB 250 GB 50 GB) 使用された帯域幅 (MB/ 秒 ) の数値は 作成時に sqlcmd スクリプトのウィンドウに示されたものです 最初のデータ完全同期に使用された共有領域の構成がこのプロセスに影響する点に注意してください フェイルオーバー このソリューションでは SQL Server Management Studio を使用して AlwaysOn 可用性グループに対する手動と自動の両方のフェイルオーバーの機能をテストしました 手動フェイルオーバーには 計画手動フェイルオーバーと強制手動フェイルオーバー ( 強制フェイルオーバー ) の 2 種類があります 可用性グループは可用性レプリカのレベルでフェイルオーバーします SYNCHRONIZED( 同期 ) 状態のセカンダリレプリカにフェイルオーバーした場合 ウィザードにより計画手動フェイルオーバーが実行され データ消失は発生しません SYNCHRONIZING( 同期化中 ) UNSYNCHRONIZED( 未同期 ) NOT SYNCHRONIZING ( 同期しない ) のいずれかの状態のセカンダリレプリカにフェイルオーバーした場合 ウィザードにより強制手動フェイルオーバー ( 強制フェイルオーバーとも呼ばれる ) が実行されます この場合 データ消失の可能性があります 両方の形式の手動フェイルオーバーで プライマリの役割に接続しているセカンダリレプリカへの移行が行われます 図 19. SQL Server Management Studio から開始されたフェイルオーバー 強制手動フェイルオーバーは SSMS のフェイルオーバー可用性グループウィザードを使用して開始できます ( 図 19 を参照 ) または スクリプトを使用してフェイルオーバーを開始できます ウィザードが強制フェイルオーバーを正常に完了した後 前のプライマリレプリカがオンラインになり セカンダリの役割に移行します 次に DR サイト上の前のセカンダリレプリカが 新しいプライマリレプリカに移行します 自動フェイルオーバーについても このソリューションの一部としてテストに成功しました 自動フェイルオーバーは 同期コミットモード用およびセカンダリレプリカが SYNCHRONIZED( 同期 ) 状態のときは自動フェイルオーバーモード用に構成された プライマリレプリカとセカンダリレプリカの間でのみ使用できます 45

46 結論 サマリー SQL Server 2012 AlwaysOn 可用性グループは 同期または非同期可用性モードで特定のデータベースを個別に またはまとめて保護するための柔軟性を提供します これらの構成を使用すると SQL Server 2012 でデータを離れた場所のセカンダリレプリカにレプリケートできます このソリューションは VNX シリーズストレージアレイのパフォーマンスを向上させる EMC FAST Cache の能力を明確に示しています テスト結果では 使用率の高いストレージプールで FAST Cache を有効にすると 負荷が軽減されるだけでなく 同じストレージプールで 4 倍以上の I/O(11,500 IOPS から 50,000 IOPS へ ) を処理することができ SQL Server データファイルの平均レーテンシ時間も 3 ミリ秒以下 ( 読み取りおよび書き込み ) という非常に低い値を示しました OLTP ワークロード I/O パターンの変化に自動的に対応する FAST Cache の能力は 管理者にとって優れたツールとなります また このソリューションはアクティブな SQL Server 2012 環境をホストする EMC VNX シリーズの機能を重視し 同期および非同期の両方のモードで パフォーマンスへの影響を最小限に抑えながら 新しい AlwaysOn 可用性グループ機能によってデータベースを保護します これらのシナリオで観察されたパフォーマンスの向上は 必ずしもすべての Microsoft SQL Server 2012 環境を表すものではありませんが 自動化されたプロセスを使用して はるかに多い IOPS を処理しながらレーテンシを削減できる潜在力を示しています FAST Cache は 大幅な TCO の削減ももたらします これは アレイで FAST Cache が有効化されていない場合に比べ 必要なドライブ数がはるかに少ないためです たとえば 電力消費量と設置面積を削減すると同時に ビジーな SQL Server 2012 環境を最適化するために管理者が行う必要がある設計と構成を簡素化します 評価結果 テストと検証の結果 次のことが明らかになりました SQL Server AlwaysOn 可用性グループテクノロジーは 使いやすさ モニタリング パフォーマンスに関して 以前のバージョンで提供されていた従来のネイティブの SQL Server 保護サービスと比較した場合 ネイティブの保護レベルに大幅な向上をもたらす EMC のストレージアレイプラットフォーム (EMC VNX など ) は EMC により完全に検証され マルチサブネット災害復旧構成の重要なエンタープライズレベルの SQL Server 2012 環境をサポートする VNX5700 は OLTP に類似した 50,000 以上の SQL Server の IOPS を容易に処理できる一方 SQL Server 2012 AlwaysOn 可用性グループ構成を使用した高可用性を提供する 46

47 EMC FAST Cache テクノロジーを簡単に有効化し SQL Server 2012 トランザクションパフォーマンスの大幅な向上を実現する 注 EMC VNX5700 アレイは このホワイトペーパーに記載されているよりもはるかに多くの IOPS を処理できます このソリューションで実現されるパフォーマンスは 特定の容量のストレージデバイス ( ソリューションのシステム構成 のセクションを参照 ) 大規模な構成では はるかに高いレベルのパフォーマンスを達成できます 結果は SQL Server 2012 と EMC テクノロジーを組み合わせて使用することのメリットを明確に示しています 47

48 関連資料 ホワイトペーパー 追加情報については 次のホワイトペーパーを参照してください Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery その他のドキュメント Microsoft SQL Server 2012 および AlwaysOn に関する追加情報については 次に示すドキュメントを参照してください SQL Server 2012 に関するオンラインブック AlwaysOn 可用性グループ 可用性グループリスナー AlwaysOn ダッシュボード 事前構成データベース最適化 SQL Server のベストプラクティスに関する記事 48