• Articles
• admin

2019年7月9日に、SQL Server2008および2008R2のサポートは終了します。 これは、定期的なセキュリティ更新プログラムの終了を意味します。 ただし、これらのSQL ServerインスタンスをAzureまたはAzure Stackに移動すると（このガイドの残りの部分では両方をAzureと呼びます）、Microsoftは追加料金なしで3年間の 現在SQL Server2008/2008R2を実行していて、7月9日の期限までにSQL Serverの新しいバージョンに更新できない場合は、将来のセキュリティの脆弱性に直面するリス Sql Serverのパッチが適用されていないインスタンスは、データの損失、ダウンタイム、または壊滅的なデータ侵害につながる可能性があります。

AzureでSQL Server2008/2008R2を実行するときに直面する課題の1つは、高可用性を確保することです。 オンプレミスでは、高可用性のためにSQL Serverフェールオーバークラスター(FCI)インスタンスを実行しているか、仮想マシンでSQL Serverを実行していて、可用性のためにVMware HA Azureに移行する場合、これらのオプションはいずれも使用できません。 Azureでのダウンタイムは、軽減するための措置を講じる必要がある非常に現実的な可能性です。

ダウンタイムの可能性を軽減し、Azureの99.95%または99の資格を得るためです。99％のSLA、あなたはSIOS DataKeeperを活用する必要があります。 DataKeeperは、Azureの共有ストレージの不足を克服し、各インスタンスのローカルに接続されたストレージを活用するAzureでSQL Server FCIを構築できます。 SIOS DataKeeperは、このガイドに記載されているSQL Server2008r2およびWindows Server2008R2をサポートするだけでなく、2008R2からWindows Server2019までの任意のバージョンのWindows Server、およびSQL Server2008からSQL Server2019までの任意のバージョンのSQL Serverをサポートしています。

このガイドでは、Windows Server2008R2で実行されているAzureで2ノードのSQL Server2008R2フェールオーバークラスターインスタンス(FCI)を作成するプロセスについて説明します。 SIOS DataKeeperはアベイラビリティーゾーンまたはリージョンにまたがるクラスターもサポートしていますが、このガイドでは、各ノードが同じAzureリージョンに存在し、異なる SIOS DataKeeperは、SQL Server2008R2FCIを作成するために通常必要な共有ストレージの代わりに使用されます。

前提条件

Active Directory
このガイドでは、既存のActive Directoryドメインがあることを前提としています。 独自のドメインコントローラーを管理したり、Azure Active Directoryドメインサービスを使用したりできます。 このチュートリアルでは、contosoというドメインに接続します。ローカル。 もちろん、このチュートリアルに従うときは、独自のドメインに接続します。

ファイアウォールポートを開く
–SQL Server:1433for Default Instance
–Load Balancer Health Probe:59999
–DataKeeper:これらのファイアウォールルールは、インストール中にWindowsホストベースのファイアウォールに自動的に追 どのポートが開かれているかの詳細については、SIOSのドキュメントを参照してくださ
-クラスタノード間のポートをブロックするネットワークベースのセキュリティがある場合は、そこにもこれらのポートを考慮する必要があります。

DataKeeperサービスアカウント
ドメインアカウントを作成します。 DataKeeperをインストールするときにこのアカウントを指定します。 このアカウントは、クラスターの各ノードのローカルのAdministratorsグループに追加する必要があります。

Azureで最初のSQL Serverインスタンスを作成する

このガイドでは、Azure Marketplaceで公開されているWINDOWS Server2008R2イメージ上のSQL Server2008R2SP3を活用します。

最初のインスタンスをプロビジョニングするときは、新しい可用性セットを作成する必要があります。 このプロセスでは、必ずフォールトドメインの数を3に増やしてください。 これにより、2つのクラスターノードとファイル共有監視がそれぞれ独自のフォールトドメインに存在することが可能になります。

仮想ネットワークがまだ構成されていない場合は、作成ウィザードで新しいネットワークを作成できます。

インスタンスが作成されたら、IP構成に移動し、プライベートIPアドレスを静的にします。 これは、SIOS DataKeeperに必要であり、クラスター化されたインスタンスのベストプラクティスです。

後の手順でドメインに参加できるように、DNSサーバーをローカルのWindows ADコントローラーに設定するように仮想ネットワークが構成されていることを確認して

仮想マシンのプロビジョニングが完了したら、各インスタンスに少なくとも2つのディスクを追加します。 PremiumまたはUltra SSDが推奨されます。 SQLログファイルに使用されるディスクのキャッシュを無効にします。 SQLデータファイルに使用されるディスクで読み取り専用キャッシュを有効にします。 記憶域のベストプラクティスの詳細については、”Azure仮想マシンのSQL Serverのパフォーマンスガイドライン”を参照してください。

Azureで2番目のSQL Serverインスタンスを作成する

上記と同じ手順に従いますが、このインスタンスを1番目のインスタンスで作成したのと同じ仮想ネ

ファイル共有監視(FSW)インスタンスの作成

Windows Serverフェールオーバークラスター(WSFC)を最適に動作させるには、別のWindows Serverインスタンスを作成し、SQL Serverインスタンスと同 同じ可用性セットに配置することで、各クラスターノードとFSWが異なるフォールトドメインに存在することを確認し、フォールトドメイン全体がオフライ このインスタンスはSQL Serverを必要とせず、単純なファイル共有をホストするだけなので、単純なWindowsサーバーにすることができます。

このインスタンスは、WSFCに必要なファイル共有監視をホストします。 このインスタンスは、同じサイズである必要はなく、追加のディスクを接続する必要もありません。 唯一の目的は、単純なファイル共有をホストすることです。 それは実際には他の目的のために使用することができます。 私のラボ環境では、私のFSWも私のドメインコントローラです。

Sql Server2008R2のアンインストール

プロビジョニングされた2つのSQL Serverインスタンスのそれぞれに、SQL Server2008R2が既にインストールされています。 ただし、クラスター化されたインスタンスではなく、スタンドアロンSQL Serverイ クラスターインスタンスをインストールする前に、これらの各インスタンスからSQL Serverをアンインストールする必要があります。 これを行う最も簡単な方法は、以下に示すようにSQLセットアップを実行することです。

セットアップを実行するとき。exe/Action-RunDiscoveryプリインストールされているすべてのものが表示されます

setup.exe /Action=RunDiscovery

セットアップを実行します。exe/Action=Uninstall/FEATURES=SQL,AS,RS,IS,Tools/INSTANCENAME=MSSQLSERVERはアンインストールプロセスを開始します

setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

セットアップを実行します。exe/Action-rundiscoveryはアンインストールが完了したことを確認します

setup.exe /Action-RunDiscovery

このアンインストールプロセスを2番目のインスタンスで再度実行します。

ドメインにインスタンスを追加する

これらのインスタンスはすべてWindowsドメインに追加する必要があります。 “前提条件”セクションで説明したように、既存のWindows Active Directoryに参加するにはアクセス権が必要です。 ここでは、contosoというドメインに参加しています。ローカル。

Windowsフェールオーバークラスタリング機能の追加

フェールオーバークラスタリング機能を2つのSQL Serverインスタンスに追加する必要があります

Add-WindowsFeature Failover-Clustering

Windows Server2008R2SP1用のConvenience Rollup Updateのインストール

AzureでWindows Server2008R2インスタンスを構成するために必要な重要な更新プログラム(kb2854082)があります。 この更新プログラムとその他の多くは、Windows Server2008R2SP1用の便利なロールアップ更新プログラムに含まれています。 この更新プログラムを2つのSQL Serverインスタンスのそれぞれにインストールします。

ストレージのフォーマット

二つのSQL Serverインスタンスがプロビジョニングされたときに接続された追加のディスクをフォーマットする必要があ 各インスタンスのボリュームごとに次の操作を行います。

マイクロソフトのベストプラクティスでは、次のように述べています…

“NTFSアロケーションユニットサイズ: データディスクをフォーマットするときは、データおよびログファイル、およびTempDBに64KBのアロケーションユニットサイズを使用することをお勧めします。”

クラスター検証を実行

クラスター検証を実行して、すべてをクラスター化する準備ができていることを確認します。

Import-Module FailoverClustersTest-Cluster -Node "SQL1", "SQL2"

レポートには、ストレージとネットワークに関する警告が含まれます。 これらの警告は、共有ディスクがなく、サーバー間に単一のネットワーク接続のみが存在することがわかっているため、無視できます。 また、無視できるネットワークバインディング順序に関する警告が表示されることもあります。 エラーが発生した場合は、続行する前にそれらに対処する必要があります。

クラスター検証を実行しようとしているエラーですか？

私はいくつかの機会にこのエラーが発生しましたが、私はまだこれがどのような条件で発生するかを整理しようとしています。 フォーラムの投稿で説明されているように、test-clusterが実行されないことがあります。

Test-ClusterUnable to Validate a Cluster Configuration. The operation has failed. The action validate a configuration did not completeThere is an error in XML document (5, 73). Attempt by methodMicrosoft.Xml.Serialzation.GeneratedAssembly.XmlSerialzationReaderClusterPrep.Config.Read4_As...Bolean) to access methodMS.Internal.ServerClusters.Validation.TestAssemblyCollection.Add(MS.Internal.ServerClusters.V....Failed

これがあなたに起こった場合、私はフォーラムの投稿で推奨される次の修正が私のために働くことを発見しました。この修正ではPowershellからtest-clusterを実行できますが、この修正でもGUIを介してValidateを実行するとエラーがスローされることがわかりました。 解決策があるかどうかを確認するためにMicrosoftにクエリがありますが、今のところクラスター検証を実行する必要がある場合は、PowershellでTest-Clusterを使用する必要

クラスターの作成

Azureでクラスターを作成するためのベストプラクティスは、Powershellを使用して静的IPアドレスを指定してクラスターを作成することです。 Powershellでは静的IPアドレスを指定できますが、GUIメソッドでは指定できません。 残念ながら、AzureのDHCPの実装はWSFCではうまく機能しないため、GUIメソッドを使用する場合は、クラスターを使用する前に修正する必要があるクラスター IPア しかし、私が見つけたのは、-StaticAddressコマンドを使用した典型的なNew-Cluster powershellコマンドが機能しないことです。 重複したIPアドレスの問題を回避するには、クラスタに頼る必要があります。exeユーティリティを実行し、次のコマンドを実行します。

cluster /cluster:cluster1 /create /nodes:"sql1 sql2" /ipaddress:10.0.0.100/255.255.255.0

ファイル共有監視を追加する

次に、ファイル共有監視を追加する必要があります。 FSWとしてプロビジョニングした3番目のサーバーで、以下に示すようにフォルダを作成して共有します。 以下に示すように、共有レベルとセキュリティレベルの両方で、Cluster Name Object(CNO)の読み取り/書き込み権限を付与する必要があります。

共有が作成されたら、いずれかのクラスターノードでクラスタークォーラムの構成ウィザードを実行し、以下に示す手順に従います。

DataKeeperをインストール

以下に示すように、2つのSQL ServerクラスターノードのそれぞれにDataKeeperをインストールします。

ここでは、各ローカルドメイン管理者グループに追加したドメインアカウントを指定します。

DataKeeperの設定

DataKeeperが2つのクラスターノードのそれぞれにインストールされたら、DataKeeperを設定する準備が整いました。

注–次の手順で発生する最も一般的なエラーは、セキュリティ関連であり、ほとんどの場合、既存のAzureセキュリティグループが必要なポートをブロックしています。 サーバーが必要なポートを介して通信できることを確認するには、SIOSのドキュメントを参照してくださ

まず、二つのノードのそれぞれに接続する必要があります。

すべてが適切に構成されている場合は、[サーバーの概要]レポートに次の内容が表示されます。

次に、新しいジョブを作成し、以下の手順に従います

使用可能なストレージにDataKeeper Volumeリソースを登録するには、ここではいを選択します

ボリュームごとに上記の手順を実行します。 完了すると、WSFC UIに次のものが表示されます。

これで、SQL Serverをクラスターにインストールする準備が整いました。

注–この時点で、複製されたボリュームは、現在使用可能なストレージをホストしているノード上でのみアクセスできます。 それは期待されているので、心配しないでください！

最初のノードにSQL Serverをインストールする

インストールをスクリプト化する場合は、SQL Server2008R2のスクリプト化されたクラスターインストールの例をクラスターの最初のノードに含めました。 既存のクラスターにノードを追加するスクリプトは、ガイドのさらに下にあります。

もちろん、あなたの環境に合わせて調整してください。

c:\SQLServerFull\setup.exe /q /ACTION=InstallFailoverCluster /FEATURES=SQL /INSTANCENAME="MSSQLSERVER" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxxx" /SQLDOMAINGROUP="contoso\SQLAdmins" /AGTDOMAINGROUP="contoso\SQLAdmins" /SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS" /FAILOVERCLUSTERGROUP="SQL Server 2008 R2 Group" /FAILOVERCLUSTERDISKS="DataKeeper Volume E" "DataKeeper Volume F" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.0.0.101;Cluster Network 1;255.255.255.0" /FAILOVERCLUSTERNETWORKNAME="SQL2008Cluster" /SQLSYSADMINACCOUNTS="contoso\admin" /SQLUSERDBLOGDIR="E:\MSSQL10.MSSQLSERVER\MSSQL\Log" /SQLTEMPDBLOGDIR="F:\MSSQL10.MSSQLSERVER\MSSQL\Log" /INSTALLSQLDATADIR="F:\MSSQL10.MSSQLSERVER\MSSQLSERVER" /IAcceptSQLServerLicenseTerms

GUIを使用する場合は、以下のスクリーンショットに従ってください。

最初のノードで、SQL Serverセットアップを実行します。

新しいSQL Serverフェールオーバークラスターのインストールを選択し、図の手順に従います。

必要なオプションのみを選択します。

このドキュメントでは、SQL Serverの既定のインスタンスを使用していることを前提としています。 名前付きインスタンスを使用する場合は、リッスンするポートをロックダウンし、後でロードバランサーを構成するときにそのポートを使用する必要があ また、名前付きインスタンスに接続するには、SQL Server Browserサービス（UDP1434）用のロードバランサールールを作成する必要があります。 このガイドでは、これら2つの要件のどちらも説明していませんが、名前付きインスタンスが必要な場合は、これら2つの追加手順を実行すると機能

ここでは、未使用のIPアドレスを指定する必要があります

データディレクトリタブに移動し、データとログファイルを再配置します。 このガイドの最後では、最適なパフォーマンスを得るために、tempdbをミラー化されていないDataKeeperボリュームに再配置する方法について説明します。 今のところ、クラスタ化されたディスクのいずれかに保持してください。

2番目のノードにSQL Serverをインストールする

以下は、既存のクラスターに追加のSQL Server2008r2ノードを追加するために実行できるコマンドの例です。

c:\SQLServerFull\setup.exe /q /ACTION=AddNode /INSTANCENAME="MSSQLSERVER" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxx" /IAcceptSQLServerLicenseTerms

GUIを使用する場合は、以下のスクリーンショットに従ってください。

第二のノードでSQL Serverセットアップを再度実行し、SQL Serverフェールオーバークラスターにノードを追加を選択します。

Congratulations、あなたはほとんど完了です！ ただし、Azureではgratuitous ARPのサポートが不足しているため、次の手順に示すように、クライアントのリダイレクトを支援するために内部ロードバランサー(ILB)を構成

SQLクラスタのIPアドレスの更新

ILBが正常に機能するには、いずれかのクラスタノードから次のコマンドを実行する必要があります。 Sql Cluster IPを使用すると、sql Cluster IPアドレスがILB health probeに応答すると同時に、サブネットマスクを255.255.255.255に設定して、HEALTH probeとのIPアドレスの競合を回避できます。

cluster res <IPResourceName> /priv enabledhcp=0 address=<ILBIP> probeport=59999 subnetmask=255.255.255.255

注-それがまぐれかどうかはわかりませんが、このコマンドを実行すると実行されるように見えますが、ジョブが完了しないため、再度実行する必要が それがうまくいったかどうかを私が知ることができる方法は、SQL Server IPリソースのサブネットマスクを見ることです、それが255.255.255.255でなければ、それが成 これは単純にGUIの更新の問題である可能性があるため、クラスタGUIを再起動してサブネットマスクが更新されたことを確認することもできます。

正常に実行された後、リソースをオフラインにしてオンラインに戻し、変更を有効にします。

ロードバランサーの作成

最後のステップは、ロードバランサーを作成することです。 この場合、ポート1433でリッスンしているSQL Serverの既定のインスタンスを実行していると想定しています。ロードバランサーを作成するときに定義するプライベートIPアドレスは、SQL Server FCIが使用するアドレスとまったく同じになります。

バックエンドプールに2つのSQL Serverインスタンスのみを追加します。 バックエンドプールにFSWを追加しないでください。

この負荷分散ルールでは、Floating IPを有効にする必要があります

クラスターの検証

続行する前に、もう一度クラスターの検証を実行します。 クラスター検証レポートは、最初に実行したときと同じネットワークおよびストレージの警告を返す必要があります。 新しいエラーや警告がないと仮定すると、クラスターは正しく構成されています。

sqlservを編集します。ディレクトリ内のexe設定ファイル

C:\Program Files(x86)\Microsoft SQL Server\100\Tools\Binn sqlpsを作成しました。exe”を起動します。設定ファイルとsqlservr。exe”を起動します。設定ファイル内の次の行を使用して設定します:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/> </startup></configuration>

これらのファイルは、デフォルトでは存在せず、作成される可能性があります。 このファイルが既にインストール用に存在する場合、<supportedruntime version=”v2.0.50727″/>行は、<configuration>…</configuration>セクションの<startup>…</startup>サブセクションとともに配置する必要があります。 これは両方のサーバーで行う必要があります。

クラスターのテスト

最も簡単なテストは、パッシブノードでSQL Server Management Studioを開き、クラスターに接続することです。 あなたが接続することができれば、おめでとう、あなたはすべて正しいことをしました！ あなたが恐れることはありません接続することができない場合は、間違いを犯す最初の人ではないでしょう。 私は問題のトラブルシューティングに役立つブログ記事を書きました。 クラスターの管理は、従来の共有記憶域クラスターの管理とまったく同じです。 すべてはフェールオーバークラスターマネージャーを介して制御されます。

オプション–Tempdbの再配置

最適なパフォーマンスを得るには、tempdbをローカルのレプリケートされていないSSDに移動することをお勧めします。 ただし、SQL Server2008R2では、tempdbがクラスター化されたディスク上にある必要があります。 SIOSには、この問題に対処するNon-Mirrored Volume Resourceと呼ばれるソリューションがあります。 ローカルSSDドライブのミラー化されていないボリュームリソースを作成し、そこにtempdbを移動することをお勧めします。 ただし、ローカルSSDドライブは永続的ではないため、サーバーを再起動するたびにtempdbを保持しているフォルダーとそのフォルダーのアクセス許可が再作成され