windowsシステムのaws移行とmulti-az化 - jaws days 2015

Copyright © 2014 H.I.S. Co., Ltd. All Right Reserved.Copyright © 2015 H.I.S. Co., Ltd. All Right Reserved.

WindowsシステムのAWS移行とMulti-AZ化

本社情報システム本部基盤システムグループインフラソリューションチームチームリーダー榎本貴之


@jawsdays

参加方法は簡単！3ステップ

@awscloud_jp ＋

#jawsdaysをつけてツイート投稿！

1番リツイート数を集めた人が優勝者です！

AWS公式TwitterとJAWS DAYS公式Twitterをフォロー

??

17:00～の懇親会で優勝者発表です。※9:00～16:50のTweetが対象です。

＋

Kindle JAWS Tシャツ

＋

ウェアラブルMoff Band JAWS Tシャツ

Step 1 （参加条件になります）

Step 2

Step 3

（Jaws Daysに関する投稿なら何でもOK！）

JAWS Tシャツ

お知らせ

TwitterでJaws Daysに参加しよう！たくさんリツイートされた人にプレゼント！


自己紹介

榎本貴之

えのもとたかゆき

本社情報システム本部基盤システムグループインフラソリューションチームチームリーダー

【好きなAWSサービス】Direct Connect、CloudFront

【主な業務とか】サーバやネットワーク、ミドルウェアの導入・運用・管理比較的得意なのはMicrosoft SQL Serverで、ネットワーク機器が苦手


Agenda

株式会社エイチ・アイ・エス会社概要 WindowsシステムのAWS移行とMulti-AZ化

基本方針 AWS移行とMulti-AZ化のポイント

データベース：SQL Server

ファイル共有：DFS（分散ファイルシステム）データセンター内システムとの連携：Direct Connect

バックアップ：AWS CLI

まとめ


会社概要

名称株式会社エイチ・アイ・エス（東証1部：会社コード 9603）

登録番号観光庁長官登録旅行業第724号

資本金 11,000百万円（平成27年2月1日現在）

設立昭和55年（1980年）12月19日

本社〒163-6029 東京都新宿区西新宿6-8-1 新宿オークタワー29階

売上高 5,232億円（平成26年10月期連結業績）

従業員数 12,723名（グループ全体平成26年10月31日現在）

加盟・認可団体日本旅行業協会（JATA）、国際航空運送協会（IATA）

主な関連会社

旅行事業テーマパーク事業ホテル事業その他事業


全世界拠点網

世界127都市、186拠点、日本国内303店鋪のネットワーク※

※2015年3月22日現在

●ヨハネスブルグ

Johannesburg

直近ＯＰＥＮ

2015/02/02 シアヌークビル（カンボジア）

2015/02/27 クスコツアーデスク（ペルー）

2015/03/09 ジョグジャカルタ（インドネシア）


Agenda





バックアップ：AWS CLI （CLI Tools）まとめ


これから話すシステムについて

現地ツアー（オプショナルツアー）、レンタカーのあたりの話になります

http://activities.his-j.com/

http://restaurant.his-j.com/

http://cars.his-j.com/

http://www.his-j.com/


AWS移行にあたって

移行のきっかけハードウェアの保守切れ Windows Server 2003のサポート終了

移行における要件ハードウェアの保守期限までに移行を完了させる OS（Windows）などのバージョンアップ（最新化）を行うメンテナンスコスト等も含めて、全体のコストを下げたいオンプレミスで稼働していたときよりサービスレベルが下がるのはNG

使えるサービスは使うが、クラウドサービスを使うための無理な改修は行わない（改修による不具合発生のリスク抑えるため）

最重要ポイント SIerやベンダーに頼らず、自分達で作る※納期短縮、コスト削減、自社主導


H.I.S. オプショナルツアー/レンタカー on AWS システム概要図

Availability Zone Availability Zone

Remote Desktop

Gateway

WEB/APWEB/APNAT NAT

Managers

Remote Desktop

Gateway

Batch/ETC Batch/ETCSQL Server SQL ServerDFS DFS

AD-DC AD-DC

AlwaysOn

DFS-R

DFS-N

Managers

Route53 IAM Cloud Watch Cloud Trail

Snapshots

S3

Direct Connect

Elastic Load Balancing

WSFC


WindowsシステムのAWS移行とMulti-AZ化のポイント

データベース SQL Server AlwaysOn on EC2

ファイル共有 DFS （分散ファイルシステム）

データセンター内システムとの連携 AWS Direct Connect

バックアップ AWS CLI （CLI Tools）


比較：Amazon RDS for SQL Server vs SQL Server on EC2

Amazon RDS for SQL Server SQL Server on EC2

管理 ◎マネージド ×自分で管理

バックアップ ◎自動△バックアップ時に若干のフリーズ

×自分で管理○自分で制御可能

メンテナンスウィンドウ

△時間指定のみで回避はできない ○自分で管理、制御できる

タイムゾーン △基本的にUTC固定 ○日本時間が選択可能（EC2のタイムゾーンに依存）

冗長化 ×Single AZ※2015/3時点でのap-northeast-1

◎AlwaysOnによるMulti-AZ対応

スケールアップ ○可能（SPLAは2xlargeまで） ○可能（ライセンスは別）

スケールアウト ×不可 ○セカンダリをReadonlyで利用可能

ディスクの拡張 ×インスタンス再作成＆データ移行 ○EBS追加で対応

費用 ○RDSの課金 △EC2の課金×SQL Server EEのライセンス


RDS for SQL Serverについてサポートに聞いてみた

Q.

A.

RDS Single-AZの場合、障害時にどうなりますか？

Multi-AZであれば障害発生に伴いフェイルオーバーが行われますが、 Single-AZの

場合フェイルオーバーができませんので、DBが直ちに影響を受け、アクセス不可もしくはパフォーマンス低下といった状態が予想されます。

RDSへ接続するアプリケーションから通常のDBアクセスを行う事はできず、アプリケーションとしては接続エラーや、極端な応答速度低下といった形で影響が現れます。

サービス側で復旧が行われるまで、それらの症状は継続しますの

で、DBへ接続する処理については実行不能な状態が続くとお考え頂ければと思います。サービス側では可能な限り障害の影響を抑えるべく復旧を行いますが、直ちに復旧

は難しいケースや、場合によっては最後のバックアップ取得以降のデータ復旧が難しいケース等も考えられます。

※実際の回答です


SQL Server AlwaysOn on EC2のホワイトペーパー

Implementing Microsoft Windows Server Failover Clustering

and SQL Server AlwaysOn Availability Groups in the AWS Cloud

http://aws.amazon.com/jp/whitepapers/microsoft-wsfc-sql-alwayson/

※構築していた当時より内容が更新されています


SQL Server AlwaysOn on EC2 の作り方（手作り編）

ステップ０：VPCの構築 VPCの作成 Internet Gateway、Route Table、Subnet、NACL等の設定セキュリティグループの作成

ステップ１：Active Directoryの構築ドメインコントローラ用のWindowsサーバをLunch

Active DirectoryとDNSをインストールドメインコントローラに昇格

ステップ２：Windows Server Failover Clusterの構築 SQL Server用のWindowsサーバをLunch

メンバサーバとしてActive Directoryドメインに参加 Windows Server Failover Clusterの構築

ステップ３：SQL Server AlwaysOnの構築 SQL Serverのインストールデータベースの作成 AlwaysOn 可用性グループの作成


SQL Server AlwaysOn on EC2 基本事項


SQL Server SQL ServerAD-DC AD-DC

AlwaysOn

構築手順を全部紹介すると時間が足りないため、ポイントだけお話します

基本的な事項 SQL Server とは別にActive Directoryが必要 Windows Server Failover Clusterが必要 SQL Serverは2台で、AZを分ける

WSFC

SQL Server AlwaysOn 完成図


Windows Server Failover Clusterの構築の重要ポイント

SQL Server用のWindows インスタンスに対してPrivate IP Addressを3つ設定する Lunch時 or Lunch後

プライマリアドレス

WSFC用アドレス

SQL Server用アドレス


SQL Server AlwaysOnの構築の重要ポイント

SQL Serverを構築するにあたっての超重要事項

データ、ログ、tempdb、バックアップで、ディスクを分ける

SQL Serverを実行するユーザに「メモリ内のページのロック」の権限を付与する

MAX DOPを設定する

tempdbのデータファイルをCPUのコア数分作る


SQL Server の設定：MAX DOP（並列処理の最大限度）

設定値は論理CPUコア数の「4分の1」、またはNUMAノード上のCPUコア数(ソケット上のCPUコア数)の、どちらか小さい値

わからなかったら「1」

デフォルトはゼロゼロはダメ、絶対！※ゼロ＝無制限


Amazon RDS for SQL Server での MAX DOP設定

Amazon RDSを使う場合も、前述のルールでMAX DOPの設定が必要です！設定にはRDSのParameter Groupsを使用パラメータ名は「max degree of parallelism」 RDSのデフォルトは「0」なので注意


Amazon RDS for SQL Server MAX DOPの推奨値

インスタンスタイプ vCPU 推奨MAX DOP

db.m3.medium 1 1

db.m3.large 2 1

db.m3.xlarge 4 1

db.m3.2xlarge 8 2

db.r3.large 2 1

db.r3.xlarge 4 1

db.r3.2xlarge 8 2

db.r3.4xlarge 16 4

db.r3.8xlarge 32 8

db.t2.micro 1 1

db.t2.small 2 1

db.t2.medium 2 1


Amazon RDS for SQL Server をSAPで利用する場合のMAX DOPの推奨値

インスタンスタイプ vCPU 推奨MAX DOP

db.m3.medium 1 1

db.m3.large 2 1

db.m3.xlarge 4 1

db.m3.2xlarge 8 1

db.r3.large 2 1

db.r3.xlarge 4 1

db.r3.2xlarge 8 1

db.r3.4xlarge 16 1

db.r3.8xlarge 32 1

db.t2.micro 1 1

db.t2.small 2 1

db.t2.medium 2 1


RDS for SQL Server が東京リージョンでMulti-AZ対応していない理由

RDS for SQL Server はミラーリングによってMulti-AZを実現している自動フェールオーバーをサポートするミラーリング構成を作るには

3台のSQL Serverが必要。RDS的には3つのSubnetが必要 3台を別々のSubnet/AZにするには3つのAZが必要

東京リージョンはAZが実質2つでAZが足りない

Availability Zone A

Availability Zone B

SQL Server

プリンシパル

SQL Server

監視

Availability Zone C

SQL Server

ミラー

Amazon RDS for SQL Server Multi-AZ構成図 ※当人の適当な調べによる推測

クライアントアプリケーション


Availability Zone

Availability Zone

分散ファイルシステム（DFS）

Windowsファイル共有の仮想化と冗長化 DFS名前空間（DFS-N）とDFSレプリケーション（DFS-R）を使う

WEB/AP

名前空間サーバファイル共有の実体（フォルダ・ターゲット）

DFS名前空間（DFS-N）

クライアント

Datas

DFS

DFS

DFSレプリケーション（DFS-R）

\\dfs01\Datas

\\dfs02\Datas

名前空間サーバを複数用意して冗長化

フォルダに対してレプリケートされているフォルダを割り当て

\\his-j.com\Share\Datas

名前空間サーバ経由で実体にアクセス

\\his-j.com\Share

ルートとフォルダを作る

サーバが停止した場合は、自動的に別のサーバに接続


分散ファイルシステム（DFS）の良し悪し

メリット既存アプリケーションの改修がエンドポイントの変更程度となる EC2＋EBSとなるため、基本的にS3よりも高速 re:Inventでも紹介されている、由緒正しい構成

デメリット Active Directoryが必須 DFSの管理が必要インスタンスが最低２つ必要（コスト高） S3のほうが安くて堅牢


オンプレミス（データセンター）にある他システムとの通信

AWS Direct Connectで万事解決

Amazon VPC

専用線1Gbps × 2本ルータ

Direct Connect

データセンター（オンプレミス環境）

相互接続ポイントEquinix TY2

ルータ

Publicサービス（VPC外サービス）

AWS

エイチ・アイ・エス Direct Connect 事例： http://www.kvhasia.com/ja/case-studies/h-i-s-co-ltd/


AWS Direct Connect の導入効果

安心感専用線という安心感は何物にも変えがたい VPN接続が切れてしまうという不安からの開放

AWS≒新しいデータセンターオンプレミスとまったく同じではない従来と考え方が変わり、制約に対して柔軟に対応してゆくことが必要

EeterpriseでAWSを使う場合、一番最初に使うべきサービスはDirect Connectだと思う


EC2インスタンスのバックアップ概要

Region: ap-northeast-1 Region: eu-west-1IAM

IAM Role

EC2

EC2 AMI Snapshot

メンテナンス用のEC2を用意し、バックアップ等のメンテナンスタスクを実行。該当EC2にはIAM Roleで必要な権限を割り当て。

バックアップはEC2が作られると、翌日よりAMI（スナップショット）を自動で取得。登録作業等は不要（とても重要）。

取得したAMI（スナップショット）を別リージョン（たとえばヨーロッパ等）に転送することで、データを遠隔地に保管。

IAM Roleを割り当てたメンテナンス用EC2

EC2インスタンスすべてについて、自動でAMI作成

AMIを別リージョンに転送

ec2-create-image

ec2-copy-image

ec2-describe-instances

AMI Snapshot


EC2インスタンスのバックアップ

インスタンスIDの一覧取得

AMI作成

AMIの削除削除するAMIに紐づくSNAPSHOTの情報を取得

削除するAMIをderegister

削除するAMIに紐づいていたSNAPSHOTをdelete

ec2-describe-instances --region ${REGION} | grep ^INSTANCE | awk '{print $2}'

ec2-create-image ${INSTANCE_ID} --name ${AMI_NAME} --no-reboot --region ${REGION}

ec2-deregister ${DEL_AMI_ID} --region ${REGION}

ec2-delete-snapshot ${SNAPSHOT_ID} --region ${REGION}

ec2-describe-images ${DEL_AMI_ID} --owner self --region ${REGION} \

| grep ^BLOCKDEVICEMAPPING | grep EBS


ec2-create-imageの注意点

ec2-create-imageは成功しない（失敗する）場合があるので、結果のチェックが必要

成功したかどうかはec2-describe-imageしてステータスをチェック pending→実行中 available→成功（完了） failed→失敗

失敗していても、慌てず騒がず、もう１回ec2-create-imageを実行原因を追究するのは時間のムダ

ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep pending | wc –l

ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep available | wc –l

ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep failed | wc -l


SQL Server データベースのバックアップ概要

バックアップ用EBSを用意しBACKUP DATABASEコマンドでフルバックアップファイルを出力。その後、バックアップ用EBSのスナップショットを取る。

トランザクションログもバックアップ用EBSに出力。回数が多いため、スナップショットではなく個別にS3へ転送。

古いデータの削除はS3のLifecycleを使う。


SQL Server SQL Server

AlwaysOn

①BACKUP DATABASE

②BACKUP LOG

①バックアップ用EBSのスナップショットを取る

②LOGは個別にS3へ転送③Lifecycleで古いデータを削除

バックアップ用EBS

スナップショット

S3バケットバックアップ用のEBSを追加


SQL Server データベースのバックアップ

フルバックアップ

トランザクションログバックアップ

S3転送

S3 Lifecycle

BACKUP DATABASE [HISDB] TO DISK = N'D:\SQLServer\backup\hisdb\hisdb_20150322.bak‘

WITH NOFORMAT, NOINIT, NAME = N'hisdb_20150322‘,

SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10

BACKUP LOG [HISDB] TO DISK = N'D:\SQLServer\backup\hisdb\hisdb_20150322_0300.trn'

WITH NOFORMAT, NOINIT, NAME = N'hisdb_20150322_0300',

SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10

aws s3 cp D:\SQLServer\backup\hisdb\hisdb_20150322.bak

s3://his-backup/SQLServer/Backup/hisdb/hisdb_20150322.bak


Agenda





バックアップ：AWS CLI （CLI Tools）まとめ


まとめ

Windows環境をAWSに移行しても、特に問題なく稼働中

良かったことハードウェアの保守切れが無いので、５年後にリプレースを考えなくて良いスケールアップの余地がハードウェアにしばられることがなくなった障害時の対応がものすごく楽に（STOP→STARTで完了）難しいネットワーク機器の設定が不要短期間でのインフラ構築が可能

タイヘンだったこと ap-northeast-1ではRDS for SQL ServerがSingle-AZだった AlwaysOnやDFSの構築、検証にそこそこ時間が必要だった必要となる運用系のスクリプトは、マニュアル片手にイチから自作した障害報告で、理由を完全に説明できず、突っ込まれるとツライそれなりにソフトウェアの改修と期間が必要だったソフトウェアライセンス（SQL Server EE）が高額


Thank you !

windowsシステムのaws移行とmulti-az化 - jaws days 2015

Technology

copyright c

jataiata copyright

aws cli cli tools copyright

sql server vs sql server

awswindows server

ec2 dfs aws

ec2amazon rds

deep dive