リアルタイムの高レベルリファレンスデザイン
変更を提案
PDF
このセクションでは、Azure NetApp Files SMB ボリュームを使用した AOAG 構成での SQL データベース エステートのリアルタイム デプロイについて説明します。
-
ノード数: 4
-
データベース数: 21
-
可用性グループの数: 4
-
バックアップ保存期間: 7日間
-
バックアップアーカイブ: 365日
|
Azure NetApp Files共有を使用して Azure 仮想マシンに SQL Server を使用した FCI を展開すると、データのコピーが 1 つあるコスト効率の高いモデルが実現します。このソリューションは、ファイル パスがセカンダリ レプリカと異なる場合にファイル追加操作の問題を防ぐことができます。 |
次の図は、AOAG 内のデータベースがノード全体に分散している様子を示しています。
データレイアウト
ユーザー データベース ファイル (.mdf) とユーザー データベース トランザクション ログ ファイル (.ldf) は、tempDB とともに同じボリュームに保存されます。サービスレベルはUltraです。
構成は 4 つのノードと 4 つの AG で構成されます。 21 個のデータベースすべて (Dynamic AX、SharePoint、RDS 接続ブローカー、インデックス サービスの一部) は、Azure NetApp Filesボリュームに保存されます。ノード上のリソースを効率的に使用するために、データベースは AOAG ノード間でバランスが取られます。 AOAG 構成に参加する WSFC に 4 つの D32 v3 インスタンスが追加されます。これら 4 つのノードは Azure 仮想ネットワークにプロビジョニングされており、オンプレミスからは移行されていません。
注記:
-
アプリケーションの性質や実行されるクエリに応じて、ログにさらなるパフォーマンスとスループットが必要な場合は、データベース ファイルを Premium サービス レベルに配置し、ログを Ultra サービス レベルで保存できます。
-
tempdb ファイルがAzure NetApp Filesに配置されている場合は、 Azure NetApp Filesボリュームをユーザー データベース ファイルから分離する必要があります。以下は、AOAG 内のデータベース ファイルの配布例です。
注記:
-
スナップショット コピーベースのデータ保護の利点を維持するために、 NetApp、データとログ データを同じボリュームに結合しないことを推奨しています。
-
セカンダリ データベースのファイル パスが対応するプライマリ データベースのパスと異なる場合、プライマリ レプリカで実行されたファイル追加操作がセカンダリ データベースで失敗する可能性があります。これは、プライマリ ノードとセカンダリ ノードの共有パスが異なる場合 (コンピューター アカウントが異なるため) に発生する可能性があります。この障害により、セカンダリ データベースが中断される可能性があります。増加またはパフォーマンス パターンを予測できず、後でファイルを追加する計画の場合は、 Azure NetApp Filesを使用した SQL Server フェールオーバー クラスターが適切なソリューションです。ほとんどのデプロイメントでは、 Azure NetApp Files がパフォーマンス要件を満たしています。
移住
オンプレミスの SQL Server ユーザー データベースを Azure 仮想マシン内の SQL Server に移行する方法はいくつかあります。移行はオンラインでもオフラインでも行えます。選択するオプションは、SQL Server のバージョン、ビジネス要件、および組織内で定義された SLA によって異なります。データベース移行プロセス中のダウンタイムを最小限に抑えるために、 NetAppAlwaysOn オプションまたはトランザクション レプリケーション オプションのいずれかを使用することをお勧めします。これらの方法を使用できない場合は、データベースを手動で移行できます。
マシン間でデータベースを移動するための最もシンプルで徹底的にテストされたアプローチは、バックアップと復元です。通常は、データベースのバックアップから開始し、その後データベースのバックアップを Azure にコピーします。その後、データベースを復元できます。最適なデータ転送パフォーマンスを得るには、圧縮されたバックアップ ファイルを使用してデータベース ファイルを Azure VM に移行します。このドキュメントで参照されている高レベルの設計では、Azure ファイル同期を使用して Azure ファイル ストレージにバックアップし、その後 Azure NetAppファイルに復元するというアプローチが使用されています。
|
|
Azure Migrate を使用すると、SQL Server ワークロードを検出、評価、移行できます。 |
移行を実行するには、次の大まかな手順を実行します。
-
要件に基づいて接続を設定します。
-
オンプレミスのファイル共有の場所に完全なデータベース バックアップを実行します。
-
Azure ファイル同期を使用して、バックアップ ファイルを Azure ファイル共有にコピーします。
-
必要なバージョンの SQL Server を使用して VM をプロビジョニングします。
-
バックアップファイルをVMにコピーするには、 `copy`コマンドプロンプトからコマンドを実行します。
-
完全なデータベースを Azure 仮想マシン上の SQL Server に復元します。
|
|
21 個のデータベースを復元するのに約 9 時間かかりました。このアプローチはこのシナリオに固有のものです。ただし、状況や要件に応じて、以下にリストされている他の移行手法を使用することもできます。 |
オンプレミスの SQL Server からAzure NetApp Filesにデータを移動するその他の移行オプションは次のとおりです。
-
データ ファイルとログ ファイルをデタッチし、Azure Blob ストレージにコピーしてから、URL からマウントされた ANF ファイル共有を使用して Azure VM 内の SQL Server に接続します。
-
オンプレミスでAlways On可用性グループ展開を使用している場合は、 "Azure レプリカの追加ウィザード" Azure にレプリカを作成し、フェールオーバーを実行します。
-
SQL Serverを使用する "トランザクションレプリケーション"Azure SQL Server インスタンスをサブスクライバーとして構成し、レプリケーションを無効にして、ユーザーを Azure データベース インスタンスにポイントします。
-
Windows インポート/エクスポート サービスを使用してハード ドライブを発送します。
バックアップとリカバリ
バックアップとリカバリは、あらゆる SQL Server 展開の重要な側面です。 AOAG などの高可用性ソリューションと組み合わせて、さまざまなデータ障害や損失のシナリオから迅速に回復するための適切なセーフティ ネットを備えることが必須です。 SQL Server データベース静止ツール、Azure Backup (ストリーミング)、または Commvault などのサードパーティのバックアップツールを使用して、データベースのアプリケーション整合性のあるバックアップを実行できます。
Azure NetApp Filesスナップショット テクノロジを使用すると、パフォーマンスやネットワーク使用率に影響を与えずに、ユーザー データベースのポイントインタイム (PiT) コピーを簡単に作成できます。このテクノロジを使用すると、スナップショット コピーを新しいボリュームに復元したり、ボリュームを元に戻す機能を使用して、影響を受けたボリュームをそのスナップショット コピーが作成された時点の状態にすばやく戻したりすることもできます。 Azure NetApp Files のスナップショット プロセスは非常に高速かつ効率的であり、Azure バックアップで提供されるストリーミング バックアップとは異なり、毎日複数のバックアップを実行できます。特定の日に複数のスナップショット コピーが可能になるため、RPO と RTO 時間を大幅に短縮できます。スナップショットコピーが作成される前にデータがそのままディスクに適切にフラッシュされるようにアプリケーションの整合性を追加するには、SQL Serverデータベースの静止ツールを使用します。("SCSQLAPIツール" （このリンクにアクセスするには、 NetApp SSO ログイン資格情報が必要です）。このツールは PowerShell 内から実行でき、SQL Server データベースを静止させ、アプリケーション整合性のあるストレージ スナップショット コピーをバックアップ用に取得できます。
*注記: *
-
SCSQLAPI ツールは、SQL Server の 2016 バージョンと 2017 バージョンのみをサポートします。
-
SCSQLAPI ツールは一度に 1 つのデータベースでのみ動作します。
-
各データベースのファイルを個別のAzure NetApp Filesボリュームに配置して分離します。
SCSQL APIには大きな制限があるため、 "Azure バックアップ" SLA 要件を満たすためにデータ保護に使用されました。 Azure Virtual Machines およびAzure NetApp Filesで実行されている SQL Server のストリーム ベースのバックアップを提供します。 Azure Backup では、頻繁なログ バックアップと最大 1 秒の PiT 回復により、15 分の RPO が可能になります。
監視
Azure NetApp Files は、時系列データ用に Azure Monitor と統合されており、割り当てられたストレージ、実際のストレージ使用量、ボリューム IOPS、スループット、ディスク読み取りバイト数/秒、ディスク書き込みバイト数/秒、ディスク読み取り数/秒、ディスク書き込み数/秒、および関連する待機時間に関するメトリックを提供します。このデータを使用すると、アラートによってボトルネックを特定し、ヘルス チェックを実行して SQL Server の展開が最適な構成で実行されているかどうかを確認できます。
この HLD では、適切なサービス プリンシパルを使用してメトリックを公開することで、ScienceLogic を使用してAzure NetApp Files を監視します。次の画像は、Azure NetApp Filesメトリック オプションの例です。
シッククローンを使用したDevTest
Azure NetApp Filesを使用すると、データベースの即時コピーを作成して、アプリケーション開発サイクル中に現在のデータベース構造とコンテンツを使用して実装する必要がある機能をテストしたり、データ ウェアハウスにデータを入力するときにデータ抽出および操作ツールを使用したり、誤って削除または変更されたデータを回復したりすることができます。このプロセスでは、Azure Blob コンテナーからデータをコピーする必要がないため、非常に効率的です。ボリュームが復元されると、読み取り/書き込み操作に使用できるようになるため、検証と市場投入までの時間が大幅に短縮されます。アプリケーションの一貫性を保つために、これを SCSQLAPI と組み合わせて使用する必要があります。このアプローチは、Azure NetApp Files の「新しいボリュームに復元」オプションと合わせて、さらに別の継続的なコスト最適化手法を提供します。
注記:
-
「新しいボリュームの復元」オプションを使用してスナップショット コピーから作成されたボリュームは、容量プールの容量を消費します。
-
追加コストを回避するために、REST または Azure CLI を使用して複製されたボリュームを削除できます (容量プールを増やす必要がある場合)。
ハイブリッドストレージオプション
NetApp、SQL Server 可用性グループ内のすべてのノードに同じストレージを使用することを推奨していますが、複数のストレージ オプションを使用できるシナリオもあります。このシナリオは、AOAG 内のノードが Azure Azure NetApp Files Azure NetApp Files Files で可能です。このような場合は、 Azure NetApp Files SMB 共有にユーザー データベースのプライマリ コピーが保持され、Premium ディスクがセカンダリ コピーとして使用されていることを確認します。
注記:
-
このような展開では、フェールオーバーの問題を回避するために、SMB ボリュームで継続的な可用性が有効になっていることを確認してください。継続的な可用性属性がない場合、ストレージ層でバックグラウンド メンテナンスが行われると、データベースが失敗する可能性があります。
-
データベースのプライマリ コピーをAzure NetApp Files SMB ファイル共有に保存します。
事業継続性
一般的に、災害復旧はどの展開でも後から考えられます。ただし、ビジネスへの影響を回避するために、初期の設計および展開フェーズで災害復旧に対処する必要があります。 Azure NetApp Filesでは、リージョン間レプリケーション (CRR) 機能を使用して、ボリューム データをブロック レベルでペアのリージョンにレプリケートし、予期しないリージョンの停止に対処できます。 CRR 対応の宛先ボリュームは読み取り操作に使用できるため、災害復旧シミュレーションに最適です。さらに、CRR 宛先に最低のサービス レベル (たとえば、標準) を割り当てて、全体的な TCO を削減することもできます。フェイルオーバーが発生した場合、レプリケーションが解除され、それぞれのボリュームが読み取り/書き込み可能になります。また、動的サービス レベル機能を使用することでボリュームのサービス レベルを変更できるため、災害復旧コストを大幅に削減できます。これは、Azure 内でのブロック レプリケーションを備えたAzure NetApp Filesのもう 1 つの独自の機能です。
長期スナップショットコピーアーカイブ
多くの組織では、必須のコンプライアンス要件として、データベース ファイルからのスナップショット データを長期保存する必要があります。このプロセスはこのHLDでは使用されませんが、簡単なバッチスクリプトを使用して簡単に実行できます。 "Azコピー"スナップショット ディレクトリを Azure Blob コンテナーにコピーします。スケジュールされたタスクを使用すると、特定のスケジュールに基づいてバッチ スクリプトをトリガーできます。プロセスは簡単で、次の手順が含まれます。
-
AzCopy V10 実行可能ファイルをダウンロードします。インストールするものは何もありません。 `exe`ファイル。
-
適切なアクセス許可を持つコンテナー レベルの SAS トークンを使用して、AzCopy を承認します。
-
AzCopy が承認されると、データ転送が開始されます。
注記:
-
バッチ ファイルでは、SAS トークン内に表示される % 文字を必ずエスケープしてください。これは、SAS トークン文字列内の既存の % 文字の横に % 文字を追加することで実行できます。
-
その "安全な転送が必要です"ストレージ アカウントの設定によって、ストレージ アカウントへの接続がトランスポート層セキュリティ (TLS) で保護されるかどうかが決まります。この設定はデフォルトで有効になっています。次のバッチ スクリプトの例では、スナップショット コピー ディレクトリから指定された BLOB コンテナーにデータを再帰的にコピーします。
SET source="Z:\~snapshot" echo %source% SET dest="https://testanfacct.blob.core.windows.net/azcoptst?sp=racwdl&st=2020-10-21T18:41:35Z&se=2021-10-22T18:41:00Z&sv=2019-12-12&sr=c&sig=ZxRUJwFlLXgHS8As7HzXJOaDXXVJ7PxxIX3ACpx56XY%%3D" echo %dest%
次の例の cmd は PowerShell で実行されます。
–recursive
INFO: Scanning... INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support Job b3731dd8-da61-9441-7281-17a4db09ce30 has started Log file is located at: C:\Users\niyaz\.azcopy\b3731dd8-da61-9441-7281-17a4db09ce30.log 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, INFO: azcopy.exe: A newer version 10.10.0 is available to download 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, Job b3731dd8-da61-9441-7281-17a4db09ce30 summary Elapsed Time (Minutes): 0.0333 Number of File Transfers: 2 Number of Folder Property Transfers: 0 Total Number of Transfers: 2 Number of Transfers Completed: 2 Number of Transfers Failed: 0 Number of Transfers Skipped: 0 TotalBytesTransferred: 5 Final Job Status: Completed
注記:
-
長期保存用の同様のバックアップ機能は、まもなくAzure NetApp Filesでも利用可能になります。
-
バッチ スクリプトは、任意のリージョンの BLOB コンテナーにデータをコピーする必要があるあらゆるシナリオで使用できます。
コスト最適化
データベースに対して完全に透過的なボリュームの再形成と動的なサービス レベルの変更により、 Azure NetApp Filesでは Azure での継続的なコスト最適化が可能になります。この機能は、ワークロードの急増に対応するために追加のストレージが過剰にプロビジョニングされるのを避けるために、この HLD で広く使用されています。
ボリュームのサイズ変更は、Azure アラート ログと組み合わせて Azure 関数を作成することで簡単に実行できます。