次の方法で共有

Azure の SQL Server データ ファイル

Azure の SQL Server データ ファイルを使用すると、Azure BLOB として格納されている SQL Server データベース ファイルをネイティブにサポートできます。 これにより、オンプレミスで実行されている SQL Server または Azure の仮想マシンで、Azure Blob Storage 内のデータ専用のストレージ場所を使用してデータベースを作成できます。 この機能強化により、デタッチ操作とアタッチ操作を使用してマシン間でデータベースを移動することが特に簡単になります。 さらに、Azure Storage からまたは Azure Storage に復元できるようにすることで、データベース バックアップ ファイルの代替ストレージの場所を提供します。 そのため、データの仮想化、データ移動、セキュリティと可用性、および高可用性とエラスティック スケーリングのための簡単な低コストとメンテナンスのための利点を提供することで、複数のハイブリッド ソリューションを実現できます。

このトピックでは、SQL Server データ ファイルを Azure Storage Service に格納する際の中心となる概念と考慮事項について説明します。

この新機能の使用方法に関する実践的なエクスペリエンスについては、「 チュートリアル: Azure Storage サービスの SQL Server データ ファイル」を参照してください。

次の図は、この機能強化により、サーバーが存在する場所に関係なく、SQL Server データベース ファイルを Azure Blob として Azure Storage に格納できる点を示しています。

SQL Server と Azure Storage

Azure で SQL Server データ ファイルを使用する利点

  • 簡単かつ迅速な移行の利点: この機能により、アプリケーションを変更することなく、オンプレミスのマシン間とオンプレミスとクラウド環境の間で一度に 1 つのデータベースを移動することで、移行プロセスが簡略化されます。 そのため、既存のオンプレミス インフラストラクチャを維持しながら、増分移行をサポートします。 さらに、一元化されたデータ ストレージにアクセスできるため、オンプレミス環境の複数の場所でアプリケーションを実行する必要がある場合に、アプリケーション ロジックが簡略化されます。 場合によっては、地理的に分散した場所にコンピューター センターを迅速にセットアップし、さまざまなソースからデータを収集することが必要になる場合があります。 この新しい拡張機能を使用すると、データをある場所から別の場所に移動する代わりに、多くのデータベースを Azure BLOB として格納し、Transact-SQL スクリプトを実行してローカル マシンまたは仮想マシンにデータベースを作成できます。

  • コストと無制限のストレージの利点: この機能を使用すると、オンプレミスのコンピューティング リソースを活用しながら、Azure に無制限のオフサイト ストレージを使用できます。 Azure をストレージの場所として使用する場合、ハードウェア管理のオーバーヘッドなしでアプリケーション ロジックに簡単に集中できます。 オンプレミスで計算ノードを失った場合は、データ移動なしで新しいノードを設定できます。

  • 高可用性とディザスター リカバリーの利点: Azure 機能で SQL Server データ ファイルを使用すると、高可用性とディザスター リカバリーのソリューションが簡略化される場合があります。 たとえば、Azure 内の仮想マシンまたは SQL Server のインスタンスがクラッシュした場合は、Azure BLOB へのリンクを再確立するだけで、新しいマシンにデータベースを再作成できます。

  • セキュリティ上の利点: この新しい機能強化により、コンピューティング インスタンスをストレージ インスタンスから分離できます。 完全に暗号化されたデータベースでは、復号はコンピュートインスタンスでのみ行われ、ストレージインスタンスでは行われません。 言い換えると、この新しい拡張機能を使用すると、データから物理的に分離された Transparent Data Encryption (TDE) 証明書を使用して、パブリック クラウド内のすべてのデータを暗号化できます。 TDE キーはマスター データベースに格納できます。これは、物理的にセキュリティで保護されたオンプレミス コンピューターにローカルに格納され、ローカルにバックアップされます。 これらのローカル キーを使用して、Azure Storage に存在するデータを暗号化できます。 クラウド ストレージ アカウントの資格情報が盗まれた場合でも、TDE 証明書は常にオンプレミスに存在するため、データは引き続きセキュリティで保護されます。

概念と要件

Azure Storage の概念

Azure 機能で SQL Server Data Files を使用する場合は、Azure でストレージ アカウントとコンテナーを作成する必要があります。 次に、コンテナーのポリシーに関する情報と、コンテナーにアクセスするために必要な共有アクセス署名を含む SQL Server 資格情報を作成する必要があります。

Azure では、ストレージ アカウントは BLOB にアクセスするための名前空間の最上位レベルを表します。 ストレージ アカウントの合計サイズが 500 TB を超える限り、ストレージ アカウントには無制限の数のコンテナーを含めることができます。 ストレージ制限の最新情報については、「 Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。 コンテナーは、一連の BLOB のグループ化を提供します。 すべての BLOB はコンテナー内に存在する必要があります。 アカウントには、無制限の数のコンテナーを含めることができます。 同様に、コンテナーには無制限の数の BLOB を格納することもできます。 Azure Storage に格納できる BLOB には、ブロック BLOB とページ BLOB の 2 種類があります。 この新機能では、最大 1 TB のサイズのページ BLOB が使用され、ファイル内のバイト範囲が頻繁に変更される場合の効率が向上します。 BLOB には、次の URL 形式を使用してアクセスできます: http://storageaccount.blob.core.windows.net/<container>/<blob>。

Azure の課金に関する考慮事項

Azure サービスを使用するコストの見積もりは、意思決定と計画のプロセスにおいて重要な問題です。 Azure Storage に SQL Server データ ファイルを格納する場合は、ストレージとトランザクションに関連するコストを支払う必要があります。 さらに、Azure Storage 機能に SQL Server データ ファイルを実装するには、暗黙的に 45 秒から 60 秒ごとに BLOB リースを更新する必要があります。 また、.mdfや .ldf など、データベース ファイルあたりのトランザクション コストも発生します。 見積もりに基づいて、2 つのデータベース ファイル (.mdf と .ldf) のリースを更新するコストは、現在の価格モデルに従って 1 か月あたり約 2 セントになります。 Azure Storage と Azure Virtual Machines の使用に関連する月額コストの見積もりには、 Azure の価格 ページの情報を使用することをお勧めします。

SQL Server の概念

この新しい拡張機能を使用する場合は、次の操作を行う必要があります。

  • コンテナーにポリシーを作成し、Shared Access Signature (SAS) キーも生成する必要があります。

  • データまたはログ ファイルで使用されるコンテナーごとに、名前がコンテナー パスと一致する SQL Server 資格情報を作成する必要があります。

  • Azure Storage コンテナー、関連付けられているポリシー名、SAS キーに関する情報を SQL Server 資格情報ストアに格納する必要があります。

次の例では、Azure Storage コンテナーが作成され、ポリシーが読み取り、書き込み、一覧、権限で作成されていることを前提としています。 コンテナーにポリシーを作成すると、SAS キーが生成されます。このキーは、安全に暗号化せずにメモリに保持でき、SQL Server がコンテナー内の BLOB ファイルにアクセスするのに必要です。 次のコード スニペットでは、 'your SAS key' を次のようなエントリに置き換えます: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'。 詳細については、「Shared Access Signature の作成と使用」を参照してください。

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')

重要

コンテナー内のデータ ファイルへのアクティブな参照がある場合、対応する SQL Server 資格情報の削除が失敗します。

安全

AZURE Storage に SQL Server データ ファイルを格納する場合のセキュリティに関する考慮事項と要件を次に示します。

  • Azure Blob Storage サービスのコンテナーを作成するときは、アクセスをプライベートに設定することをお勧めします。 アクセスをプライベートに設定すると、コンテナーと BLOB のデータは Azure アカウント所有者のみが読み取ることができます。

  • AZURE Storage に SQL Server データベース ファイルを格納する場合は、共有アクセス署名、コンテナー、BLOB、キュー、およびテーブルへの制限付きアクセス権を付与する URI を使用する必要があります。 Shared Access Signature を使用すると、Azure ストレージ アカウント キーを共有することなく、SQL Server がストレージ アカウント内のリソースにアクセスできるようになります。

  • さらに、データベースの従来のオンプレミス セキュリティ プラクティスを引き続き実装することをお勧めします。

インストールの前提条件

Azuree に SQL Server データ ファイルを格納する場合のインストールの前提条件を次に示します。

  • オンプレミスの SQL Server: SQL Server 2014 バージョンには、この機能が含まれています。 SQL Server 2014 をダウンロードする方法については、 SQL Server 2014 を参照してください。

  • Azure 仮想マシンで実行されている SQL Server: Azure 仮想マシンに SQL Server をインストールする場合は、SQL Server 2014 をインストールするか、既存のインスタンスを更新します。 同様に、SQL Server 2014 プラットフォーム イメージを使用して、Azure に新しい仮想マシンを作成することもできます。 SQL Server 2014 をダウンロードする方法については、 SQL Server 2014 を参照してください。

制限事項

  • この機能の現在のリリースでは、 FileStream データを Azure Storage に格納することはサポートされていません。 Filestreamデータは Azure Storage 統合ローカル データベースに格納できますが、Azure Storage を使用してマシン間で Filestream データを移動することはできません。 FileStreamデータの場合は、従来の手法を引き続き使用して、Filestream に関連付けられているファイル (.mdf、.ldf) を異なるマシン間で移動することをお勧めします。

  • 現在、この新しい機能強化では、Azure Storage 内の同じデータベース ファイルに同時にアクセスする複数の SQL Server インスタンスはサポートされていません。 ServerA がアクティブなデータベース ファイルでオンラインで、ServerB が誤って起動され、同じデータ ファイルを指すデータベースがある場合、2 番目のサーバーはエラー コード 5120 でデータベースを起動できません。"%.*ls" の物理ファイルを開くことができません。オペレーティング システム エラー %d: "%ls"。

  • Azure の SQL Server データ ファイル機能を使用して Azure Storage に格納できるのは、.mdf、.ldf、および .ndf のファイルのみです。

  • Azure の SQL Server データ ファイル機能を使用する場合、ストレージ アカウントの geo レプリケーションはサポートされていません。 ストレージ アカウントが geo レプリケートされ、geo フェールオーバーが発生した場合、データベースの破損が発生する可能性があります。

  • 各 BLOB の最大サイズは 1 TB です。 これにより、Azure Storage に格納できる個々のデータベース データとログ ファイルの上限が作成されます。

  • Azure Storage の SQL Server データ ファイル機能を使用して、In-Memory OLTP データを Azure BLOB に格納することはできません。 これは、In-Memory OLTP は FileStream に依存しており、この機能の現在のリリースでは、 FileStream データを Azure Storage に格納することはサポートされていないためです。

  • Azure 機能で SQL Server データ ファイルを使用する場合、SQL Server は、 master データベースで設定された照合順序を使用して、すべての URL またはファイル パスの比較を実行します。

  • AlwaysOn Availability Groups は、プライマリ データベースに新しいデータベース ファイルを追加しない限りサポートされます。 データベース操作でプライマリ データベースに新しいファイルを作成する必要がある場合は、まずセカンダリ ノードで AlwaysOn 可用性グループを無効にします。 次に、プライマリ データベースに対してデータベース操作を実行し、プライマリ ノード内のデータベースをバックアップします。 次に、セカンダリ ノードにデータベースを復元し、セカンダリ ノードで AlwaysOn 可用性グループを有効にします。 Azure の SQL Server データ ファイル機能を使用する場合、AlwaysOn フェールオーバー クラスター インスタンスはサポートされないことに注意してください。

  • 通常の操作中、SQL Server は一時的なリースを使用して、45 秒から 60 秒ごとに各 BLOB リースを更新してストレージ用に BLOB を予約します。 サーバーがクラッシュし、同じ BLOB を使用するように構成された SQL Server の別のインスタンスが開始された場合、新しいインスタンスは BLOB の既存のリースの有効期限が切れるまで最大 60 秒待機します。 データベースを別のインスタンスにアタッチする場合、60 秒以内にリースの有効期限が切れるのを待つことができない場合は、BLOB のリースを明示的に解除して、アタッチ操作でエラーが発生しないようにすることができます。

ツールとプログラミングリファレンスのサポート

このセクションでは、Sql Server データ ファイルを Azure Storage に格納するときに使用できるツールとプログラミング参照ライブラリについて説明します。

PowerShell のサポート

SQL Server 2014 では、PowerShell コマンドレットを使用して、ファイル パスではなく Blob Storage URL パスを参照することで、Azure Blob Storage サービスに SQL Server データ ファイルを格納できます。 BLOB には、次の URL 形式を使用してアクセスできます: http://storageaccount.blob.core.windows.net/<container>/<blob> 。

SQL Server オブジェクトとパフォーマンス カウンターのサポート

SQL Server 2014 以降では、Azure Storage の SQL Server データ ファイル機能で使用する新しい SQL Server オブジェクトが追加されました。 新しい SQL Server オブジェクトは SQL Server として呼び出 され、HTTP_STORAGE_OBJECT 、Azure Storage で SQL Server を実行するときに、システム モニターでアクティビティを監視するために使用できます。

SQL Server Management Studio のサポート

SQL Server Management Studio では、複数のダイアログ ウィンドウを使用してこの機能を使用できます。 たとえば、新しいデータベース、データベースのアタッチ、データベースの復元など、複数のダイアログ ウィンドウでパスとしてhttps://teststorageaccnt.blob.core.windows.net/testcontainer/など、ストレージ コンテナーの URL パスを入力できます。 詳細については、「 チュートリアル: Azure Storage サービスの SQL Server データ ファイル」を参照してください。

SQL Server 管理オブジェクトのサポート

Azure の SQL Server データ ファイル機能を使用する場合、すべての SQL Server 管理オブジェクト (SMO) がサポートされます。 SMO オブジェクトにファイル パスが必要な場合は、 https://teststorageaccnt.blob.core.windows.net/testcontainer/などのローカル ファイル パスの代わりに BLOB URL 形式を使用します。 SQL Server 管理オブジェクト (SMO) の詳細については、 SQL Server オンライン ブックの SQL Server 管理オブジェクト (SMO) プログラミング ガイド を参照してください。

Transact-SQLのサポート

この新機能により、Transact-SQL のサーフェス領域に次の変更が加わりました。

  • sys.master_files システム ビューの新しい int 列 (credential_id)。 credential_id列は、Azure Storage を利用するデータファイルが、作成された資格情報の sys.credentials への参照が可能になるようにするために使用されます。 資格情報を使用するデータベース ファイルがある場合は削除できないなど、トラブルシューティングに使用できます。

Azure での SQL Server データ ファイルのトラブルシューティング

サポートされていない機能または制限事項によるエラーを回避するには、まず 制限事項を確認してください。

Azure Storage の SQL Server データ ファイル機能を使用するときに発生する可能性があるエラーの一覧は次のとおりです。

認証エラー

  • 資格情報 '%.*ls' はアクティブなデータベース ファイルで使用されているため、削除できません。
    解決策: Azure Storage のアクティブなデータベース ファイルでまだ使用されている資格情報を削除しようとすると、このエラーが表示されることがあります。 資格情報を削除するには、まず、このデータベース ファイルを含む関連付けられている BLOB を削除する必要があります。 アクティブなリースを持つ BLOB を削除するには、最初にリースを解除する必要があります。

  • Shared Access Signature がコンテナーに正しく作成されていません。
    解決策: コンテナーに Shared Access Signature が正しく作成されていることを確認します。 「チュートリアル: Azure Storage サービスの SQL Server データ ファイル」のレッスン 2 で説明されている手順を確認します。

  • SQL Server 資格情報が正しく作成されていません。
    解決策: ID フィールドに "Shared Access Signature" を使用し、シークレットを正しく作成していることを確認します。 「 チュートリアル: Azure Storage サービスの SQL Server データ ファイル」のレッスン 3 で説明されている手順を確認します。

リース ブロブ エラー:

  • 同じ BLOB ファイルを使用する別のインスタンスがクラッシュした後に SQL Server を起動しようとするとエラーが発生しました。 解決策: 通常の操作中、SQL Server は一時的なリースを使用して、各 BLOB リースを 45 秒から 60 秒ごとに更新してストレージ用に BLOB を予約します。 サーバーがクラッシュし、同じ BLOB を使用するように構成された SQL Server の別のインスタンスが開始された場合、新しいインスタンスは BLOB の既存のリースの有効期限が切れるまで最大 60 秒待機します。 データベースを別のインスタンスにアタッチする場合、60 秒以内にリースの有効期限が切れるのを待つことができない場合は、BLOB のリースを明示的に解除して、アタッチ操作でエラーが発生しないようにすることができます。

データベースのエラー

  1. データベース作成時のエラー
    解決策: 「チュートリアル: Azure Storage サービスの SQL Server データ ファイル」のレッスン 4 に記載されている手順を確認します。

  2. Alter ステートメントの実行時のエラー
    解決策: データベースがオンラインの場合は、Alter Database ステートメントを必ず実行してください。 データ ファイルを Azure Storage にコピーするときは、常にブロック BLOB ではなくページ BLOB を作成します。 それ以外の場合、ALTER Database は失敗します。 「チュートリアル: Azure Storage サービスの SQL Server データ ファイル」のレッスン 7 で説明されている手順を確認します。

  3. エラー コード 5120 物理ファイル "%.*ls" を開くことができません。 オペレーティング システム エラー %d: "%ls"
    解決策: 現在、この新しい機能強化では、Azure Storage 内の同じデータベース ファイルに同時にアクセスする複数の SQL Server インスタンスはサポートされていません。 ServerA がアクティブなデータベース ファイルでオンラインで、ServerB が誤って起動され、同じデータ ファイルを指すデータベースがある場合、2 番目のサーバーはエラー コード 5120 でデータベースを起動できません。"%.*ls" というエラー コードが表示されます。オペレーティング システム エラー %d: "%ls"。

    この問題を解決するには、まず、Azure Storage 内のデータベース ファイルにアクセスするために ServerA が必要かどうかを判断します。 そうでない場合は、ServerA と Azure Storage 内のデータベース ファイルの間の接続を削除するだけです。 この手順を実行するには、以下のステップに従ってください。

    1. ALTER Database ステートメントを使用して、サーバー A のファイル パスをローカル フォルダーに設定します。

    2. サーバー A でデータベースをオフラインに設定します。

    3. 次に、Azure Storage からサーバー A のローカル フォルダーにデータベース ファイルをコピーします。これにより、ServerA にデータベースのコピーがローカルに残ります。

    4. データベースをオンラインに設定します。

こちらもご覧ください

チュートリアル: Azure Storage サービスの SQL Server データ ファイル