SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Azure を触ったことのあるエンジニアが AWS で AlwaysOn 可用性グループを構築しようとした際のメモ

one comment

Azure は多少触ったことがあったのですが、AWS はあまり触ったことがないので、AWS 上で AlwaysOn を組もうとした際にいろいろと調べたメモを。
調べながら、適宜追記していきたいと思います。

組んでみて思ったのが「マネージドなデータベースサービスを使うのがよい」ですのぅ。

基本的な情報


AWS 上で AlwaysOn を組むための情報は、以下を読むとよいかと。

Implementing Microsoft Windows Server Failover Clustering and SQL Server AlwaysOn Availability Groups in the AWS Cloud
Microsoft WSFC and SQL Server AlwaysOn Quick Start Reference Deployment
AWS Webcast – Implementing Windows and SQL Server with High Availability on AWS

SQL Server with WSFC on the AWS Cloud
Active Directory Domain Services on the AWS Cloud
User Guide for Microsoft Windows Instances

SQL – Creating a SQL Server AlwaysOn on Amazon EC2, Part 1
Windowsシステムの AWS移行とMulti-AZ化 – JAWS DAYS 2015
SQL Server Failover between AWS and Azure – Part 1

Azure の構築方法と比較したい場合は、
チュートリアル:Azure AlwaysOn 可用性グループ (GUI)
Azure の仮想マシン内の SQL Server の高可用性と災害復旧

 

ネットワーク構成


Azure と AWS で大きく変わるのがネットワークの構成になるのかと。

Azure では

  • 仮想ネットワーク (VNET)
  • サブネット

AWS では

  • VPC
  • サブネット

を使用して、ネットワークを構成することになるかと思います。

 

Azure の仮想ネットワークは基本的に同一のリージョン内で設定をすることになります。
東日本と西日本で仮想マシンを構築したいという場合は、各リージョンに仮想ネットワークを作成し、仮想ネットワーク間を VNET 間接続をする形になるかと。
VNET 間接続: 異なるリージョン間での Azure Virtual Network の接続
VNET to VNET で、複数の Microsoft Azure 仮想ネットワーク間を接続する
Azure ポータルでサイト間 VPN 接続を使用して仮想ネットワークを作成する
従来の VNet を新しい VNet に接続する

Azure の場合、

  • 同一リージョン
  • 同一仮想ネットワーク
  • 可用性セットを使用して複数台で障害ドメイン / 更新ドメインを分ける

ことで、仮想マシンの可用性を高めることになるかと。

 

AWSの場合も、VPC 単位で一つのリージョンになりますが、VPC のサブネット単位で Availability Zone (AZ) を設定することができます。
そのため、サブネット単位で明示的に AZ を分けて指定することができ、AlwaysOn のようなクラスター環境の場合は、Multi-AZ 環境で構築するのが一般的になるかと。

そのため、AWS の場合は、

  • 同一リージョン
  • 同一仮想ネットワーク
  • 異なるサブネット
  • 異なる AZ

を使用することで仮想マシンの可用性を高めることになるかと思います。

Azure でも異なるサブネットに分けることはできますが、同一のサブネットに配置するのが一般的になるのではないでしょうか。

また、Azure でクラシックタイプの仮想マシンを使用していて AWS と大きく異なっていると感じるのが、VPC のネットワーク設定の中でも、以下ではないかと感じました。

  • パブリック IP の割り当て
  • ルートテーブル (0.0.0.0/0 を指定してインターネットアクセスさせるか)
  • インターネットゲートウェイの追加

Azure で仮想マシンを作成した場合、特に何もしなくてもインターネットに出れますが、AWS でデフォルトの VPC ではなく、自分で作成した VPC を使用する場合は、インターネットに接続する場合は、いくつかのネットワークの設定を意識する必要がありますので、この辺の違いを意識するのが重要なのかと思います。

  • パブリックまたは、Elastic IP を設定し、ネットワーク経路を設定したうえで各環境が直接インターネットへ接続
  • SSHポートフォワーディングや RD GW 経由でインターネットから各仮想マシンへ接続
  • NAT インスタンスを介して仮想マシンがインターネットへ接続

というような、ネットワーク的な特徴が AWS にはあるのではと思います。
# リソースマネージャーではなく、クラシックな Azure の仮想マシンでは、基本パブリック IP がありますので。

 

セキュリティグループの設定


Azure の場合、同一の仮想ネットワーク内の通信は、OS 側の Windows ファイアウォールを意識することはありますが、ネットワーク的なファイアウォールを意識することはあまりないかと思います。
# サブネットを分けても、ネットワーク的な F/W を意識することは少ないかと。

AWS で Multi-AZ の環境を構築した場合、セキュリティグループによるインバウンド/アウトバウンドの通信制御を意識する必要が出てくるかと。

AlwaysOn を組む場合には以下のような通信が必要となります。

  • Active Directory ドメインコントローラー間の通信
  • Active Directory ドメインに参加するクライアントとドメインコントローラーの通信
  • WSFC を組むノード間の通信
  • AlwaysOn 可用性グループを組むノード間の SQL Server の通信
  • AlwaysOn 可用性グループに接続する SQL Server への通信

AD DS 間の通信については、以下を参考に設定をするとよいかと思います。

Active Directory および Active Directory ドメイン サービスのポートの要件
ドメイン環境で使用されるポートについて

WSFC 間の通信ですが、上記の二つに加えて以下が特徴的になるかと思います。

  • ICMP (ALL)
  • TCP 3343
  • UDP 3343

ICMP が有効でないと、クラスターを追加する際にノード間の死活確認ができずに、クラスターのノードとして追加することができません。
また、TCP 3343 / UDP 3343 が有効になっていないとクラスターサービスからの通信がブロックされてしまい、クラスターの構築時にサービス起動ができずにエラーとなりますので、この辺を意識しておくとよいかと。

設定については、Microsoft Windows Server Failover Clustering (WSFC) and SQL Server AlwaysOn Availability Groups on the AWS Cloud: Quick Start Reference Deployment にも載っていますので、どのポートが必要かはこちらも併せてみるとよいかと思います。

 

Multi-AZ でのドメインコントローラーの構築


Azure で AD を AlwaysOn を構築する場合、Azure 内で完結する場合、

  • ドメインコントローラーと SQL Server が同一のサブネットに所属している
  • ドメインコントローラーと SQL Server が異なるサブネットに所属している

というような構成となるケースが多いと思いますので、Active Directory のサイトについてはあまり意識していないのではないでしょうか。
Azure 上に AlwaysOn を組むドキュメントで、AD のサイトを記載しているものってほとんどないのではと。

AWS の場合、調べたところ、以下の構成で設定をしているケースが多いのではと思います。
適切なサイト設定をすることが意識されているドキュメントが多いですよね。
# 正しい。

  • Multi-AZ の各 AZ にドメインコントローラーを配置する
  • SQL Server が配置されている AZ のドメインコントローラーを使用する

 

WSFC の IP アドレスについて


Azure も AWS も WSFC の基本設定として、オンプレミスと以下の設定が独特になっているかと思います。

  • WSFC の CNO の IP アドレス
  • AlwaysOn のリスナーの IP アドレス

Azure も AWS も、GUI を使用して、普通に構築すると、上記の IP アドレスが DHCP 割り当てにより、オンラインになっているノードのプライマリの IP アドレスが割り当てられ、IP アドレスのリソースをオンラインにすることができません。
そのため、クラスターの IP アドレスリソースについては手動で静的な IP アドレスを設定する必要があります。

Azure の場合は以下のような設定が必要となります。

  • WSFC / リスナーに仮想ネットワーク内の未使用の IP アドレスを割り当てる
  • リスナーの IP アドレスのリソースに Probe ポートを設定する
  • Direct Server Return / Probe ポート付きの負荷分散エンドポイントを作成

 

AWS の場合は、以下のような設定が必要となるかと。

  • EC2 インスタンスのネットワークインタフェースの設定として、以下を設定する
    • プライマリ IP アドレス
    • WSFC の CNO の IP アドレス
    • AlwaysOn のリスナーの IP アドレス
  • WSFC のクラスターマネージャーから CNO / リスナーの IP アドレスを静的に設定

また、AWS の大きな特徴として、Multi-AZ によるマルチサブネットフェールオーバークラスターになる点がありますので、以下も意識しておく必要があります。
SQL Server マルチサブネット クラスタリング (SQL Server)
マルチサブネットフェールオーバークラスター利用時の設定の注意点

 

WSFC のクォーラム設定について


Azure と AWS の公開されている構築のドキュメントでここも大きな違いがあります。

Azure の場合は WSFC のクォーラムは以下のように設定するケースが多いです。

  • ノードマジョリティ用の SQL Server をインストールしていないノードを用意して、ノード数を奇数に合わせる
  • ファイル共有用の SQL Server をインストールしていないノードを用意して、共有フォルダーをクォーラムにする

AlwaysOn テンプレート展開をした場合はファイル共有で構築されますので、ノード数で合わせるよりはファイル共有を使用するケースが大半化と。

 

AWS の場合は、いくつかのドキュメントを見たのですが、

  • ドメインコントローラー #1 に共有フォルダーを作成して、その共有フォルダーをクォーラムとして使用する

パターンで紹介されているものが多いかと。
東京の場合、この投稿を書いている時点では AZ が 2 つになるかと思いますので、どちらかのリージョンに共有フォルダーを配置せざるを得なくなるのは仕方がないかと思いますが、ドメインコントローラーに配置するかはちょっと悩みどころかもしれないですね。

RDS の Multi-AZ の場合、

  • AZ #1 : プリンシパルの SQL Server
  • AZ #2 : ミラーの SQL Server
  • AZ #3 : ウィットネスの SQL Server

というように、AZ を分けていますので、以下ができるとベストだと思いますが、現状は 2 つの AZ で担保しないといけないため、共有フォルダーを配置している AZ 全体がダウンした場合に、正常に動作している AZ でいかにして、リカバリーするかの検討が必要になりそうですね。

  • AZ #1 : プリンシパルの SQL Server
  • AZ #2 : セカンダリの SQL Server
  • AZ #3 : WSFC クォーラム用のノード

 

ロードバランサー経由でリスナーに接続


設定上は、ロードバランサー経由でリスナーに接続をすることができるようでした。
# AlwaysOn をフェールオーバーした際の挙動で少し気になることがあったので、検証が必要ですが。

Windows Server 2012 R2 を使っている場合は、アップデートをしなくてもクラスターの IP アドレスのリソースに Probe ポートを設定することができます。

Get-ClusterResource <リスナーIPアドレスリソース #1>| Set-ClusterParameter -Multiple @{"Address"="<リスナー IP アドレス #1>";"ProbePort"="59999";"SubnetMask"="<サブネットマスク>";"Network"="クラスターネットワーク 1";"EnableDhcp"=0}
Get-ClusterResource <リスナーIPアドレスリソース #2>| Set-ClusterParameter -Multiple @{"Address"="<リスナー IP アドレス #2>";"ProbePort"="59999";"SubnetMask"="<サブネットマスク>";"Network"="クラスターネットワーク 2";"EnableDhcp"=0}

これにより、マルチサブネットフェールオーバークラスターで、オンラインになっているリスナーの IP アドレスを保持しているノードについては、TCP 59999 のポートがリスニングしている状態となりますので、ロードバランサーのヘルスチェックとしてこのポートに対して監視をさせるようにすれば、ロードバランサーがアクセスを振るようになります。

Windows Firewall の設定も併せて必要となります。

New-NetFirewallRule -Name "SQL Server Probe Port" -DisplayName "SQL Sever Probe Port" -Protocol TCP -LocalPort 59999

 

 

Azure と AWS の用語のマッピング


一部間違っているものがあるかもしれませんが、触ってみた中で、こんな感じかな~と思った Azure と AWS の用語を比較しながら対応付けを。

あと、Azure と AWS で後からできること/できないことのお作法が結構違うなと感じましたので、EC2起動後に、後からできること・できないこと も参考になりました。

AWS Tools for Windows PowerShell の使い方については、altrive/AWSforPowerShell.md を参考にさせていただくとよさそうです。

Azure
AWS
仮想マシン Amazon Elastic Compute Cloud (EC2) https://azure.microsoft.com/ja-jp/services/virtual-machines/

https://aws.amazon.com/jp/ec2/
仮想マシンサイズ インスタンスタイプ https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-size-specs/

https://aws.amazon.com/jp/ec2/instance-types/
Azure PowerShell AWS Tools for Windows PowerShell https://github.com/Azure/azure-powershell

https://aws.amazon.com/jp/powershell/
VM エージェント Amazon Windows EC2Config Service http://go.microsoft.com/fwlink/?linkid=394789&clcid=0x411

http://aws.amazon.com/developertools/5562082477397515
Azure ロードバランサー (ALB)

内部ロードバランサー (ILB)
Elastic Load Balancing

(インターネット向け/内部向け)
https://azure.microsoft.com/ja-jp/documentation/articles/load-balancer-overview/

https://aws.amazon.com/jp/elasticloadbalancing/
Virtual Machines Market Place Amazon マシンイメージ(AMI) https://azure.microsoft.com/ja-jp/marketplace/virtual-machines/

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AMIs.html
仮想ネットワーク (VNET) Amazon Virtual Private Cloud(Amazon VPC) https://azure.microsoft.com/ja-jp/services/virtual-network/

https://aws.amazon.com/jp/vpc/
VPN VPN 接続 https://azure.microsoft.com/ja-jp/services/virtual-network/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Introduction.html
VNET 間接続 VPC ピア接続 https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-configure-vnet-to-vnet-connection/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-peering.html
ExpressRoute AWS Direct Connect  https://azure.microsoft.com/ja-jp/services/expressroute/

https://aws.amazon.com/jp/directconnect/
サブネット サブネット http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Subnets.html

DNS (仮想ネットワーク) DHCP オプション セット https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-manage-dns-in-vnet/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html
ネットワーク セキュリティ グループ (NSG)

(仮想マシン)
セキュリティグループ https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-nsg/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
ネットワーク セキュリティ グループ (NSG)

(サブネット)
ネットワークACL https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-nsg/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_ACLs.html
ユーザー定義のルート ルートテーブル https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-udr-overview/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
インターネットゲートウェイ http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html
リージョン リージョン https://azure.microsoft.com/ja-jp/regions/

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
可用性セット アベイラビリティゾーン https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-manage-availability/

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
予約済み IP  Elastic IP アドレス https://azure.microsoft.com/ja-jp/pricing/details/ip-addresses/

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-eips
インスタンスレベル パブリック IP パブリック IP アドレス http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-public-ip-addresses

https://azure.microsoft.com/ja-jp/pricing/details/ip-addresses/
パブリック仮想 IP (VIP)  パブリック IP アドレス http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-public-ip-addresses

https://azure.microsoft.com/ja-jp/pricing/details/ip-addresses/
内部 IP アドレス プライベート IP アドレス http://blogs.msdn.com/b/windowsazurej/archive/2014/04/28/blog-static-internal-ip-address-for-virtual-machines.aspx

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses
OS ディスク ルートデバイスボリューム https://msdn.microsoft.com/ja-jp/library/azure/dn790303.aspx

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/RootDeviceStorage.html
一時格納ディスク インスタンスストア

(エフェメラルディスク)
https://msdn.microsoft.com/ja-jp/library/azure/dn790303.aspx

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html
データディスク Amazon Elastic Block Store(Amazon EBS) http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AmazonEBS.html
仮想ネットワークインタフェース Elastic Network Interface(ENI) https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-multiple-nics/

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html
Azure Active Directory

ロールベースのアクセス制御 (RBAC)

Key Vault 

Identity and Access Management  (IAM) https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-whatis/

https://azure.microsoft.com/ja-jp/documentation/articles/role-based-access-control-configure/

https://azure.microsoft.com/ja-jp/services/key-vault/

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html

Written by masayuki.ozawa

10月 10th, 2015 at 11:04 am

Posted in AWS,Microsoft Azure

Tagged with ,

One Response to 'Azure を触ったことのあるエンジニアが AWS で AlwaysOn 可用性グループを構築しようとした際のメモ'

Subscribe to comments with RSS or TrackBack to 'Azure を触ったことのあるエンジニアが AWS で AlwaysOn 可用性グループを構築しようとした際のメモ'.

  1. […] Azure を触ったことのあるエンジニアが AWS で AlwaysOn 可用性グループを構築しようとした際のメモ […]

Leave a Reply

*