文書番号 :LK20180829-211-001 SIOS SANLess Clusters ホワイトクラウド ASPIRE 検証レポート
目次 1. はじめに... 3 2. システム構成... 3 2.1 構成図... 3 2.2 クラウド構成... 4 2.3 ソフトウェア構成... 4 2.4 クラスター構成... 5 3. 検証内容... 7 2
1. はじめに Softbank 社が提供するパブリッククラウドサービスホワイトクラウド ASPIRE 上で DataKeeper Cluster Edition を使用した SANLess Cluster 検証をいたしましたので 本書に検 証構成と検証内容を記載いたします 2. システム構成 検証実施時の構成は以下のとおりです 2.1 構成図 3
2.2 クラウド構成 ノード A サーバータイプ CPU RAM ネットワーク First Disk Second Disk Virtual Server 1vCPU 4GB Public 1, Private 1 40GB(SAN) 10GB(SAN) ノード B サーバータイプ CPU RAM ネットワーク First Disk Second Disk Virtual Server 1vCPU 4GB Public 1, Private 1 40GB(SAN) 10GB(SAN) 共通 ネットワーク仮想 IP アドレス 1 2.3 ソフトウェア構成 OS Windows Server 2016 Standard Edition( ホワイトクラウド提供 ) DataKeeper SIOS DataKeeper Cluster Edition v8.6.1 Microsoft SQL Server SQL Server 2016 Standard Edition ( ホワイトクラウド提供 ) 4
2.4 クラスター構成 以下のクラスター構成で検証を実施しました クラスターコアリソースサーバー名名前 :Win2016cluster.lkg.wc IP アドレス :192.168.1.50 ファイル共有監視ファイル共有監視 : Win2016STDDC share ノード Win2016Std01 Win2016Std02 役割 SQL Server (MSSQLSERVER) 記憶域 DataKeeper Volume S サーバー名名前 :MSSQLSERVER IP アドレス :192.168.1.60 その他のリソース SQL Server SQL Server Agent 役割 SQL Server CEIP (MSSQLServer) DataKeeper ボリューム情報 ノード A Volume Root = S: Last Modified = Mon Aug 27 12:00:20 2018 Mirror Role = SOURCE Label = FileSystem = NTFS Total Space = 10734268416 Num Targets = 1 Attributes : 80h >> Remote[0] = 172.128.1.12, S: Mirror State = MIRROR Mirror Type = ASYNCHRONOUS 5
ノード B Volume Root = S: Last Modified = Mon Aug 27 12:00:32 2018 Mirror Role = TARGET Label = N/A FileSystem = N/A Total Space = 0 Num Targets = 1 Attributes : 80h >> Remote[0] = 172.128.1.11, S: Mirror State = MIRROR Mirror Type = ASYNCHRONOUS 6
3. 検証内容 以下のとおり検証を実施し 結果に問題がないことを確認しました 1 システム起動確認 1.a システム起動後 全保護対象リソースステータスが Online で かつアクティブサーバーが Owner Node になること 1.b アクティブサーバー上で仮想 IP アドレスが起動していること スタンバイサーバー上で仮想 IP アドレスが停止していること 1.c アクティブサーバー上で保護対象ボリュームにアクセスできること スタンバイサーバー上で保護対象ボリュームにアクセスできないこと 1.d アクティブサーバー上で SQL Server のサービスが起動し データベースにログインし SQL クエリを発行したとき正常に結果が返ること スタンバイサーバー上で SQL Server のサービスが停止していること 2 DataKeeper 停止 開始確認 2.a Windows Server のサービス画面より DataKeeper のサービスを正常に停止できること 2.b Windows Server のサービス画面より DataKeeper のサービスを正常に開始できること 2.c ボリュームリソースおよび SQL Server リソースはアクティブサーバー上で Online のまま DataKeeper サービスの停止動作および開始動作の影響を受けないこと 3 役割の移動確認 3.a フェールオーバークラスターマネージャーで SQL Server リソースのスタンバイサーバーへの移動が成功し スタンバイサーバーが Owner Node になること 3.b フェールオーバークラスターマネージャーで クラスターコアリソースのスタンバイサーバーへの移動が成功し スタンバイサーバーが Owner Node になること 3.c フェールオーバークラスターマネージャーで 使用可能な記憶域のスタンバイサーバーへの移動が成功し スタンバイサーバーが Owner Node になること 3.d 移動操作後 全保護対象リソースステータスが Online になっていること 3.e 移動操作後 スタンバイサーバー上で SQL Server のサービスが起動し データベースにログインし SQL クエリを発行したとき正常に結果が返ること アクティブサーバー上で SQL Server のサービスが停止していること 4 IP アドレス障害時のフェールオーバー確認 4.a アクティブサーバーで仮想 IP アドレスが紐づいたネットワークインタフェースカードのアダプターを停止し 意図的に障害を引き起こす その後 仮想 IP アドレスリソースの障害を検知してスタンバイノードにフェールオーバーすること 4.b フェールオーバー後 SQL Server リソースが Online で かつスタンバイサーバーが SQL Server リソースの Owner Node になること 4.c フェールオーバー後 スタンバイサーバー上で SQL Server のサービスが起動し データベースにログインし SQL クエリを発行したとき正常に結果が返ること アクティブサーバー上で SQL Server のサービスが停止していること 7
5 ネットワーク切断時の動作確認 5.a 任意のノード上で仮想 IP アドレスに使用しないネットワークアダプターを切断し 暫らく時間を置いてから フェールオーバークラスターマネージャーのネットワーク接続の画面で稼働中のインターフェースとして表示されないこと 5.b 仮想 IP アドレスおよび SQL Server の役割はアクティブサーバー上で Online のまま ネットワークアダプター切断の影響を受けないこと 5.c 停止したネットワークアダプターを接続した後 フェールオーバークラスターマネージャーのネットワーク接続の画面で 稼働中のインターフェースとして表示されること 6 アプリケーションリソース障害時のフェールオーバー確認 6.a アクティブサーバーで SQL Server のサービスを停止し 意図的に障害を引き起こす その後 SQL Server リソースの障害を検知してスタンバイノードにフェールオーバーすること 6.b フェールオーバー後 SQL Server リソースが Online で かつスタンバイサーバーが SQL Server リソースの Owner Node になること 6.c フェールオーバー後 スタンバイサーバー上で SQL Server のサービスが起動し データベースにログインし SQL クエリを発行したときに正常に結果が返ること アクティブサーバー上で SQL Server のサービスが停止していること 7 ノード障害によるフェールオーバー確認 7.a 意図的にノード障害を引き起こすため ホワイトクラウド ASPIRE ポータル上でアクティブサーバーをパワーオフする その後 ノード障害を検知してスタンバイノードにフェールオーバーすること 7.b フェールオーバー後 全保護対象リソースステータスが Online で かつスタンバイサーバーが Owner Node になること 7.c フェールオーバー後 スタンバイサーバー上で SQL Server のサービスが起動し データベースにログインし SQL クエリを発行したときに正常に結果が返ること 8 Data Replication の動作確認 8.a 役割の移動 およびフェールオーバーの動作に伴い Owner Node が切り替わった際 SQL Server で行 ったデータベースへの変更が正しく反映されること 8