【SQL Server on EC2】インスタンス間でAlwaysOnを構成する [1. OS準備編]

記事タイトルとURLをコピーする

こんにちは。技術4課の伊藤Kです。 個人的に「感謝しあう雰囲気」が好きですが、 システムとしてそれを実現したUnipos株式会社のサービス「Unipos」に 弊社では「さばチップ」なるネーミングをして導入、好評を博しております。 感謝を伝える仕組みを作る。ピアボーナス「さばチップ」プロジェクトとは?

さてこれまで小ネタが多かったのですが、今回は大きめなテーマ、「2台のEC2インスタンス間でSQL Server AlwaysOnを構成する」で書きます。

SQL Server AlwaysOnには以下の二種類があります。 ・AlwaysOn フェールオーバークラスタインスタンス ・AlwaysOn 可用性グループ 今回は、「AlwaysOn 可用性グループ」を構成します。基本的にSQL ServerのEnterprise Editionが必要となりますが(注1)、クラウドの利点を生かすならばほぼこちらの選択肢になるかと思います(注2)。

1エントリにまとめるとさすがに分量が多いため、3回に分けます。

の3本です。

<リンク(修正予定)> 1. OS準備編 (この記事) 2. WSFC設定編 3. AlwaysOn設定編(作成予定)

作業前の状態、前提

・2台のEC2インスタンスにSQL Serverがインストール済みで、Active Directoryドメイン参加も完了していることを前提とします。

・ドメインコントローラーについては、今回は「AWS Managed Microsoft AD」を構築しました。  作業はDomain Adminsの権限で、と思いましたが、  「AWS Managed Microsoft AD」では「AWS Delegated Administrators」が管理者権限グループなので、そのグループに所属させたユーザーアカウントで実施します。  (このグループが必要最小限の権限かの調査検討はここでは行いません)

・SQL Server の言語はAMIにプリインストールの英語版、ただしSQL Server Management Studioについては日本語版の最新バージョンをダウンロードして各サーバーにインストールしました。(わかりやすさ重視)

・OSの「Windows ファイアウォール」は無効にしております。

・Windows Server 、SQL Serverのバージョンエディションは下表の通りです。

OS Windows Server 2012 R2 Standard Edition
SQL Server SQL Server 2014 Enterprise Edition SP2 (12.0.5000.0)

ちなみに小ネタとして、簡単なSQL Serverのバージョンの確認方法は、 SQL Server Management Studioを起動、対象のコンピューターに接続して、 コンピューター名の右にカッコで表示されるバージョンを確認、それを以下URLの表と照らし合わせることで可能です。 バージョン、エディション、および SQL Server の更新プログラム レベルとそのコンポーネントを確認する方法

・2台のEC2インスタンスの情報、また構築されるクラスターリソースの名前やIPアドレスは下表の通りとします。 「コンピューター名 / リソース名 / リスナー名」は全てADドメインのDNSに登録されるホスト名となります。

内容 コンピューター名 /
リソース名 /
リスナー名
IPアドレス
AlwaysOn インスタンス #1
(文中「1号機」と記します)
sql01 172.20.10.4
AlwaysOn インスタンス #2
(文中「2号機」と記します)
sql02 172.20.11.4
クラスターコアリソース t-cluster 172.20.10.5 / 172.20.11.5
AlwaysOn リスナー t-aonlis01 172.20.10.6 / 172.20.11.6

VPC、EC2の構成上、WSFC(AlwaysOn)の利点を生かそうとするとマルチサブネットのクラスター構成となります。 そのため、クラスターコアリソース、AlwaysOn リスナーには各サブネットから1つずつIPアドレスが必要です。

EC2インスタンスへのIPアドレス割り当て

では構築に入りますが、まずはEC2のマネジメントコンソールからインスタンスのENIへ設定予定(上記表)のIPアドレスを割り当てます。OSが起動された状態で作業をしても問題ないような気はしますが、念のためにOSをシャットダウンした状態から作業を始めます。

まずは1号機のインスタンスを選択した状態で [ネットワークインターフェイス] のリンクをクリックして、 表示される情報の [インターフェイスID] のリンクをクリック。 インスタンスに結びついたネットワークインターフェイスが選択されますので、その状態で [アクション] メニューから [IPアドレスの管理] を選択。 [IPアドレスの管理] 画面が表示され、コンピューターで使用しているIPアドレスが表示されます。 [新しいIPの割り当て] リンクをクリックします。 上記表の「クラスターコアリソース」のIPアドレス(同サブネットの1つのみ)を入力します。入力途中は右に [無効なIPアドレス] とか表示されますが無視して入力続行。 入力が完了すると [無効なIPアドレス] の表示は消えます。 再度 [新しいIPの割り当て] リンクをクリックして、同様に上記表の「AlwaysOn リスナー」のIPアドレス(同サブネットの1つのみ)を入力します。 入力が完了したら右下の [更新する] ボタンをクリック。 [プライベートIP] の欄が入力状態から表示状態になり、 [更新する] ボタンが押せない状態となったら右上の [×] をクリックして [IPアドレスの管理] 画面を閉じます。 インスタンスの管理画面を表示し、対象のインスタンスの [セカンダリプライベートIP] に設定した値が表示されていることを確認します。 同様に、2号機のインスタンスについても上記の表「クラスターコアリソース」のIPアドレスおよび「AlwaysOn リスナー」のIPアドレスを割り当てます。 割り当てが完了したら、インスタンス2台を起動します。

Windows OSでのIPアドレス設定変更

インスタンスの起動が完了したらインスタンスのWindows OSにリモートデスクトップでログオンし、IPアドレス設定を変更します。

まずは1号機です。OSの [ネットワークと共有センター] からネットワークアダプターのプロパティを表示させます。 IPv4のプロパティを表示させます。ここではIPv6は無効にしています。 明示的にコンピューターのIPアドレスとデフォルトゲートウェイを設定します。 [閉じる]をクリックすると設定反映が行われるため一瞬RDPが途切れます。設定を間違えると一瞬途切れるどころでは済まなくなりますので慎重に設定しましょう。

2号機も同様に設定します。

OSで明示的にIPアドレスを設定する理由は後続の記事「WSFC設定編」で説明します。

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

2台のインスタンスに、相互で必要なポートが通信可能となるようにセキュリティグループを設定します。 この記事の通りに設定しました。 【EC2】インスタンス間でSQL Server AlwaysOnを構成する際のセキュリティグループ設定

セキュリティグループの設定が完了したら、「1. OS準備編」は完了です。

ワンポイント

上記「EC2インスタンスへのIPアドレス割り当て」手順で、クラスターのリソースやAlwaysOnリスナーとして割り当てられる予定のIPアドレスをあらかじめネットワークインターフェイスに割り当てておりますが、オンプレミス環境でWSFCやAlwaysOnの構築経験がある方にはやや違和感があるかもしれません。(私がそうでした) VPCではENIに割り当たっていないIPアドレスは他のインスタンスやサービスと通信ができないようです。 私はそれに気づかずに一旦IPアドレスを割り当てないまま手順を進めたところ、AlwaysOn構築手順の完了後、作成されたリスナーに対して自インスタンス以外からアクセスができない事象が発生しました。

AWSのドキュメントでSQL Server AlwaysOnの構築について記載されているのは以下の記事となります。 参考:WSFC ノードでの IP アドレス指定

おわりに

そもそもの話として、わざわざ複数インスタンス間でAlwaysOnを組まなくてもRDS使えば冗長性担保されているよ、という考えもあり、AWSの思想からするとそちらが本筋かもしれません。 それでもRDS移行の前段階として、オンプレミスのAlwaysOnをそのままAWSへ移したい、という要件が時々発生します。そういったケースでお役に立てれば幸いです。

「2.WSFC設定編」へ続きます。

注釈

注1

SQL Server 2016以降のバージョンでは、一部制限があるもののStandard Editionでも「AlwaysOn 可用性グループ」が構築できるようになりました。 参考:基本的な可用性グループ (AlwaysOn 可用性グループ)

注2

「AlwaysOn フェールオーバークラスタインスタンス」はFCやiSCSIを用いて 「2ノードから同時にアタッチ可能でかつ2ノードからは独立した場所にある共有ストレージの存在」 を前提としています。これをAWSで実現するのは追加のリソースが必要となり、難易度も高くなります。