SE の雑記

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

ローリングアップグレードを使用した AlwaysOn 環境のアップグレード

leave a comment

Windows Server 2016 では、クラスターの環境をローリングアップグレードを使用して、OS をバージョンアップする仕組みが追加されています。

Cluster operating system rolling upgrade

AlwaysOn 可用性グループでもローリングアップグレードをする仕組みが提供されています。
AlwaysOn 可用性グループのレプリカ インスタンスのアップグレード

Windows Server 2016 が RTM した現状であれば、OS を含めてアップグレードをするケースが出てくるかもしれません。
そこで、調査がてら少し検証してみました。

Ignite の Understand how ChannelAdvisor is using SQL Server 2016 to improve their business のアップグレードについても、可用性グループのローリングアップグレードを使用しているのかと。

image


■Windows Server 2016 のクラスターノードの追加

現状、クラスターは以下のような環境となっています。

image

AlwaysOn 可用性グループは WSFC のテクノロジを使用して構築が行われているため、最初に Windows Server 2012 R2 のクラスターに対して、Windows Server 2016 のノードを追加する必要があります。

これについては、冒頭で紹介した Cluster operating system rolling upgrade の作業を実施することになります。

クラスターのローリングアップグレードはクリーンインストールを実施した Windows Server 2016 をノードとして追加することで実施します。
TechNet のドキュメントでは、ノードの台数を変更しないで入れ替えを行う手順となっているかと思いますが、今回は 2 ノードクラスターの環境に増強する形で作業を実施していきたいと思います。

ノードの追加については、通常の手順で実施します。
Windows Server 2012 R2 を使用したクラスターに対して、Windows Server 2016 のクラスターの追加を行います。

image

 

クラスターの追加ですが、Windows Server 2016 のフェールオーバークラスターマネージャーで実施するのがよいかと思います。
Windows Server 2012 R2 のフェールオーバークラスターマネージャーからも構築することもできますが、2012 R2 から構築した場合は、クラスターのルールの検証が 2016 に対応していないため、「オペレーティング システムのバージョンの検証」がエラーとなります。

image

Windows Server 2016 のマネージャーから構築した場合には、、「オペレーティング システムのバージョンの検証」は、ローリングアップグレードに対応した検証内容となっているため、エラーではなく警告の扱いとなります。

image

Windows Server 2012 R2 でも、エラーを無視すれば構築することができますが、2016 から構築するのがよいかと。

これで、クラスターとしては以下のような環境となります。

image

現状は、Windows Server 2012 R2 と Windows Server 2016 が混在した環境となっているため、クラスターの機能レベルにつては 8 (Windows Server 2012 R2) となっています。
# クラスターの機能レベルについては、Windows Server 2016 の Get-Cluster で確認できます。2012 R2 では取得できないかと。
image

この後、AlwaysOn 可用性グループの追加を行う必要があるため、このタイミングでは機能レベルのアップデートは実施せずに、可用性グループへのノード追加に移ります。

 

■可用性グループへのノードの追加

次に、可用性グループにノードの追加を行います。

現状は、以下のような SQL Server 2012 SP2 のみで構築された可用性グループの構成としています。

image

現状は、2 台の SQL Server 2012 SP2 で自動フェールオーバーの同期モードとして設定を行っています。

image

これに、SQL Server 2016 の環境を可用性レプリカとして追加します。

今回は、1 台を同期モード、1 台を非同期モードのレプリカとして追加しています。

image

これで各 SQL Server 間で同期が行われている状態となりますが、異なるバージョンである SQL Server 2016 側については、警告の状態となっています。
SQL Server 2016 側は、「同期済み/復旧中」となっているため、このような状態になっているのかと。

imageimage

これで以下の状態となりました。

image

■可用性グループから SQL Server 2012 SP2 を切り離し

次に可用性グループから SQL Server 2012 SP2 を切り離します。

まずは、SQL Server 2016 にプライマリをフェールオーバーします。

image

これで、以下の状態となりました。

image

実業務で考えた場合、このタイミングで SQL Server 2012 SP2 への切り戻しの方法を検討する必要が出てきます。
一度 SQL Server 2016 にフェールオーバーすると、2012 SP2 へのデータ同期が切り離されますので。

image

可用性グループ側の最後の設定として、可用性レプリカと同期モードを調整して以下の構成にします。
image

これで、SQL Server 2016 のみの可用性グループに移行できました。

image

 

■WSFC から Windows Server 2012 R2 を切り離し

最後に WSFC から、Windows Server 2012 R2 のノードを切り離し、以下の構成にします。
image

切り離し自体は、フェールオーバークラスターマネージャーからノードの削除を実施します。
image

クラスター内のすべてのノードが Windows Server 2016 になっていないと、「Update-ClusterFunctionalLevel」を実行して、クラスターの機能レベルをアップグレードすることができません。

image

すべてのノードが Windows Server 2016 になっていれば、クラスターの機能レベルをアップグレードすることができます。
image

これで、以下の構成にアップグレードすることができました。

image

 

ミラーリングの構成でもローリングアップグレードのシナリオがあります。
ミラー化されたインスタンスのアップグレード

ミラーリングでは、プライマリ / セカンダリのペアの構成となりますが、可用性グループの場合は、複数台のセカンダリを設定することができますので、アップグレードの容易性は上がっているかと。

また、2016 の基本的な可用性グループでも可用性レプリカは 2 台になりますので、今後、SQL Server の新しいバージョンがリリースされた際のローリングアップグレードを使用するかは考えておいた方がよいのかもしれないですね。

Written by masayuki.ozawa

10月 10th, 2016 at 3:57 pm

Posted in SQL Server

Tagged with

Leave a Reply

*