events
3月31日 23時 - 4月2日 23時
究極の SQL、Power BI、Fabric、AI コミュニティ主導のイベント。 3 月 31 日から 4 月 2 日。 コード MSCUST を使用して 150 ドルの割引。 価格は2月11日に上昇します。
今すぐ登録このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
この記事では、Azure portal を使用して、Azure Cache for Redis インスタンスのペアでパッシブ geo レプリケーションを構成する方法について説明します。
パッシブ geo レプリケーションによって 2 つの Premium レベル Azure Cache for Redis インスタンスがリンクされ、アクティブ/パッシブ データ レプリケーション関係が作られます。 アクティブ/パッシブとは、データが同期されているキャッシュのペア (プライマリとセカンダリ) があることを意味します。 ただし、ペアの一方の側 (プライマリ) にのみ書き込むことができます。 ペアのもう一方の側であるセカンダリ キャッシュは読み取り専用です。
"アクティブ/パッシブ" を "アクティブ/アクティブ" と比較すると、後者では、ペアのどちら側にも書き込むことができ、それが反対側と同期します。
パッシブ geo レプリケーションを使用する場合、これらのキャッシュ インスタンスは通常、異なる Azure リージョンに置かれますが、必須ではありません。 1 つのインスタンスはプライマリとして、もう 1 つはセカンダリとして機能します。 プライマリによって読み取りと書き込み要求が処理され、変更がセカンダリに反映されます。
フェールオーバーは自動では行われません。 フェールオーバーを使用する方法の詳細については、geo プライマリから geo セカンダリへのフェールオーバーの開始に関する記事を参照してください。
注意
パッシブ geo レプリケーションは、ディザスター リカバリー ソリューションとして設計されています。
レベル | Basic、Standard | Premium | Enterprise、Enterprise Flash |
---|---|---|---|
使用可能 | いいえ | イエス | はい |
パッシブ geo レプリケーションは、Azure Cache for Redisの Premium レベルでのみ使用できます。 Enterprise および Enterprise Flash レベルでも geo レプリケーションは提供されますが、これらのレベルでは、''アクティブ geo レプリケーション'' と呼ばれるより高度なバージョンが使用されます。
2 つのキャッシュの間に geo レプリケーションを構成するには、次の前提条件を満たす必要があります。
注意
Azure リージョン間のデータ転送は、標準の帯域幅レートで課金されます。
geo レプリケーションでは一部の機能がサポートされていません。
geo レプリケーションを構成した後、次の制限が、リンク キャッシュ ペアに適用されます。
セカンダリ リンク キャッシュは読み取り専用です。 そこから読み取ることはできますが、データを書き込むことはできません。 geo セカンダリ インスタンスからの読み取りを選択した場合は、geo プライマリと geo セカンダリの間で完全データ同期が実行されているときは、完全データ同期が完了するまで、geo セカンダリ インスタンスはそれに対する Redis 操作でエラーをスローします。 エラーは、完全なデータ同期が進行中であることを示します。 また、geo プライマリまたは geo セカンダリのいずれかが更新されたときや、一部の再起動シナリオの際に、エラーがスローされます。 geo セカンダリから読み取るアプリケーションは、geo セカンダリがこのようなエラーをスローするたびに geo プライマリにフォールバックするように構築する必要があります。
リンクが追加される前にセカンダリ リンク キャッシュにあったデータはすべて削除されます。 ただし、geo レプリケーションが後で削除された場合、レプリケートされたデータはセカンダリ リンク キャッシュに残ります。
キャッシュがリンクされている間は、どちらのキャッシュもスケーリングできません。
キャッシュでクラスタリングが有効になっている場合は、シャードの数を変更できません。
どちらのキャッシュでも永続化を有効にすることはできません。
どちらのキャッシュからもエクスポートできます。
セカンダリ リンク キャッシュにはインポートできません。
キャッシュをリンク解除するまでは、リンクされたキャッシュ、またはそれらを含むリソース グループのどちらも削除できません。 詳しくは、「リンクされたキャッシュを削除しようとすると、操作が失敗するのはどうしてですか」をご覧ください。
キャッシュが異なるリージョンに存在する場合、ネットワーク送信コストはリージョン間で移動されたデータに適用されます。 詳しくは、「Azure リージョン間でデータをレプリケートするコストはどれくらいですか」をご覧ください。
フェールオーバーは自動では行われません。 プライマリからセカンダリ リンク キャッシュへのフェールオーバーを開始する必要があります。 フェールオーバーを使用する方法の詳細については、geo プライマリから geo セカンダリへのフェールオーバーの開始に関する記事を参照してください。
プライベート リンクは、既に geo レプリケートされているキャッシュには追加できません。 geo レプリケートされたキャッシュにプライベート リンクを追加するには: 1. geo レプリケーションのリンクを解除します。 2. プライベート リンクを追加します。 3. 最後に、geo レプリケーションを再リンクします。
geo レプリケーションのために 2 つのキャッシュをリンクするには、まずプライマリ リンク キャッシュにするキャッシュのリソース メニューの [geo レプリケーション] を選択します。 次に、作業ウィンドウで [キャッシュ レプリケーション リンクの追加] をクリックします。
[互換性のあるキャッシュ] の一覧で目的のセカンダリ キャッシュの名前を選択します。 そのセカンダリ キャッシュが一覧に表示されていない場合は、セカンダリ キャッシュの geo レプリケーションの前提条件が満たされていることを確認します。 キャッシュをリージョンでフィルター処理するには、マップ内のリージョンを選択して、 [互換性のあるキャッシュ] の一覧にあるキャッシュのみを表示します。
また、コンテキスト メニューを使用してリンク プロセスを開始したり、セカンダリ キャッシュに関する詳細を表示したりすることもできます。
[リンク] を選択して、2 つのキャッシュをリンクし、レプリケーション プロセスを開始します。
[リソース] メニューの [geo レプリケーション] を使用して、レプリケーション プロセスの進行状況を表示できます。
プライマリとセカンダリ キャッシュの両方の [リソース] メニューから [概要] を使用して、リンクの状態を表示することもできます。
レプリケーション プロセスが完了すると、[リンクのプロビジョニング状態] が [成功] に変わります。
プライマリ リンク キャッシュは、リンク プロセス中も引き続き使用できます。 セカンダリ リンク キャッシュは、リンク プロセスが完了するまで使用できません。
キャッシュがリンクされると、常に geo プライマリ キャッシュを指す各キャッシュの URL が生成されます。 geo プライマリから geo セカンダリへのフェールオーバーが開始された場合、URL は変わりませんが、基になる DNS レコードは新しい geo プライマリを指すように自動的に更新されます。
次の 3 つの URL が表示されます。
<cachename>.geo.redis.cache.windows.net
の形式のプロキシ URL です。 URL は常に、現在の geo プライマリである geo レプリケーション ペア内のキャッシュを指します。redis.cache.windows.net
であり、geo.redis.cache.windows.net
ではありません。 フィールドに一覧表示されているアドレスは、フェールオーバーが開始されると変更されます。redis.cache.windows.net
であり、geo.redis.cache.windows.net
ではありません。 フィールドに一覧表示されているアドレスは、フェールオーバーが開始されると変更されます。1 回の選択で、geo プライマリから geo セカンダリへのフェールオーバーをトリガーできます。
これにより、次の手順が実行されます。
geo フェールオーバー プロセスが完了するまでに数分かかります。
フェールオーバーが開始されると、geo プライマリと geo セカンダリのキャッシュが入れ替えられます。 新しい geo プライマリが geo セカンダリとは異なる方法で構成されている場合は、アプリケーションに問題が発生する可能性があります。
次の項目を必ず確認してください
geo フェールオーバー イベントでは、特にクライアントがフェールオーバー プロセス中に古い geo プライマリへの接続を維持している場合に、移行中にデータの不整合が発生する可能性があります。 次のヒントを使用して、計画された geo フェールオーバー イベントでのデータ損失を最小限に抑えることができます。
CLIENT PAUSE
コマンドを実行します。 CLIENT PAUSE
を実行すると、新しい書き込み要求がブロックされ、代わりにタイムアウト エラーが Azure Cache for Redis クライアントに返されます。 CLIENT PAUSE
コマンドでは、タイムアウト期間をミリ秒単位で指定する必要があります。 フェールオーバーを開始するのに十分な長いタイムアウト時間が指定されていることを確認します。 開始時には、この一時停止の値を約 30 分 (1,800,000 ミリ秒) に設定することをお勧めします。 この数値は、必要に応じていつでも小さくすることができます。新しい geo プライマリはクライアントの一時停止を保持するため、CLIENT UNPAUSE コマンドを実行する必要はありません。
注意
geo フェールオーバー シナリオでは、キャッシュに対して Microsoft Entra ID ベースの認証を使用することをお勧めします。これによって、geo プライマリ キャッシュと geo セカンダリ キャッシュに対する異なるアクセス キーを管理する困難がなくなるためです。
2 つのキャッシュ間のリンクを削除し、geo レプリケーションを停止するには、左側の [geo レプリケーション] で [キャッシュのリンク解除] を選択します。
リンク解除プロセスが完了すると、セカンダリ キャッシュが読み取りと書き込みの両方に対して使用可能になります。
注意
geo レプリケーション リンクが削除された場合も、プライマリ リンク キャッシュからレプリケートされたデータはセカンダリ キャッシュに残ります。
いいえ、パッシブ geo レプリケーションは Premium レベルでのみ使用できます。 アクティブ geo レプリケーションと呼ばれるより高度なバージョンの geo レプリケーションは、Enterprise および Enterprise Flash レベルで使用できます。
フェールオーバー プロセスが開始されると、リンク プロビジョニングの状態が [削除中] に更新されることがわかります。これは、前のリンクがクリーンアップされていることを示します。 これが完了した後、リンク プロビジョニングの状態は [作成中] に更新されます。 これは、新しい geo プライマリが稼働中であり、古い geo プライマリ キャッシュへの geo レプリケーション リンクを再確立しようとしていることを示します。 この時点で、読み取りと書き込みの両方について、新しい geo プライマリ キャッシュ インスタンスにすぐに接続できるようになります。
はい。geo レプリケーションの状態を追跡するのに役立つ使用可能なメトリックがいくつかあります。 これらのメトリックは、Azure portal で利用できます。
geo レプリケーションの正常性メトリックがすべて 1 つのビューに含まれる geo レプリケーション ダッシュボードと呼ばれる事前構築済みのブックもあります。 geo プライマリまたは geo セカンダリ キャッシュ インスタンスからのみ生成される情報を集計するため、このビューを使用することをお勧めします。
いいえ。パッシブ geo レプリケーションを使用する場合、リンクできるのは 2 つのキャッシュのみです。 アクティブ geo レプリケーションでは、最大 5 つのリンク キャッシュがサポートされます。
いいえ、両方のキャッシュが同じ Azure サブスクリプションにある必要があります。
セカンダリ リンク キャッシュがプライマリ リンク キャッシュより大きい場合は可能です。 ただし、キャッシュのサイズが異なる場合は、フェールオーバー機能を使用できません。
両方のキャッシュのシャード数が同じ場合は可能です。
ほとんどの場合、VNet インジェクション経由で Azure Private Link を使用することをお勧めします。 詳細については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。
キャッシュを geo レプリケートするときに VNet インジェクションを使用することは技術的には引き続き可能ですが、Azure Private Link をお勧めします。
重要
Azure Cache for Redis では、ネットワーク アーキテクチャが簡素化され、Azure 内のエンドポイント間の接続がセキュリティで保護される Azure Private Link の使用を推奨しています。 仮想ネットワーク内のサブネットでプライベート IP アドレスが割り当てられているプライベート エンドポイント経由で、仮想ネットワークから Azure Cache インスタンスに接続できます。 Azure Private Link はすべてのレベルで提供されており、Azure Policy のサポートと、簡略化された NSG ルール管理が含まれます。 詳細については、Private Link に関するドキュメントのページを参照してください。 VNet インジェクションされたキャッシュから Private Link に移行する方法については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。
VNet を使用した geo レプリケーションのサポートの詳細については、「Premium キャッシュでの VNet インジェクションを使用した geo レプリケーション」を参照してください。
レプリケーションは継続的かつ非同期に行われます。 特定のスケジュールで実行されるわけではありません。 プライマリに対して実行された書き込みはすべて、セカンダリに瞬時にかつ非同期的にレプリケートされます。
レプリケーションは増分的、非同期、および継続的であるため、かかる時間はリージョン間の待機時間とそれほど変わりません。 特定の状況では、セカンダリ キャッシュがプライマリからのデータの完全な同期を実行することが必要になる場合があります。 この場合のレプリケーション時間は、プライマリ キャッシュへの負荷、使用可能なネットワーク帯域幅、リージョン間の待機時間など、多くの要因によって異なります。 53 GB の完全な geo レプリケートされたペアのレプリケーション時間は 5 ~ 10 分であることがわかりました。 Azure Monitor の Geo Replication Data Sync Offset
メトリックを使用して、まだレプリケートされていないデータの量を追跡できます。
geo レプリケーション モードのキャッシュの場合、永続化は無効になっています。 geo レプリケートされたペアがリンク解除された場合 (顧客始動のフェールオーバーなど)、セカンダリ リンク キャッシュは同期されたデータをその時点まで保持します。 このような状況では、復旧ポイントは保証されません。
復旧ポイントを取得するには、どちらかのキャッシュからエクスポートします。 後で、プライマリ リンク キャッシュにインポートできます。
はい。geo レプリケーションは、Azure Portal、PowerShell、または Azure CLI を使用して管理できます。 詳細については、PowerShell のドキュメントまたは Azure CLI のドキュメントを参照してください。
geo レプリケーションを使用している場合、プライマリ リンク キャッシュからのデータは、セカンダリ リンク キャッシュにレプリケートされます。 2 つのリンクされたキャッシュが同じリージョンに存在する場合、データ転送の料金は必要ありません。 2 つのリンクされたキャッシュが異なるリージョンに存在する場合、データ転送の料金は、どちらかのリージョン内を移動するデータのネットワーク送信コストです。 詳しくは、「帯域幅の料金詳細」をご覧ください。
geo レプリケートされたキャッシュとそのリソース グループは、geo レプリケーション リンクを削除するまでは削除できません。 リンクされたキャッシュの一方または両方を含むリソース グループを削除しようとすると、リソース グループ内の他のリソースは削除されますが、リソース グループは deleting
状態のままとなり、リソース グループ内にあるリンクされたキャッシュは running
状態のままとなります。 リソース グループとその中のリンクされたキャッシュを完全に削除するには、「geo レプリケーション リンクの削除」の説明に従ってキャッシュをリンク解除します。
一般に、キャッシュは、それにアクセスするアプリケーションと同じ Azure リージョンに配置することをお勧めします。 プライマリおよびフォールバック リージョンが個別に存在するアプリケーションの場合は、プライマリおよびセカンダリ キャッシュをそれらの同じリージョンに配置することをお勧めします。 ペアになっているリージョンについて詳しくは、ベスト プラクティス - ペアになっている Azure リージョンに関する記事をご覧ください。
はい。geo レプリケーションを使用して、ファイアウォールを構成することができます。 geo レプリケーションをファイアウォールと共に機能させるには、セカンダリ キャッシュの IP アドレスが、プライマリ キャッシュのファイアウォール規則に追加されていることを確認します。 ただし、キャッシュでパブリック ネットワーク アクセスが無効になっていて、プライベート エンドポイントのみが有効になっている場合、キャッシュでのファイアウォールの使用はサポートされません。
Azure Cache for Redis の機能について
events
3月31日 23時 - 4月2日 23時
究極の SQL、Power BI、Fabric、AI コミュニティ主導のイベント。 3 月 31 日から 4 月 2 日。 コード MSCUST を使用して 150 ドルの割引。 価格は2月11日に上昇します。
今すぐ登録トレーニング
モジュール
Azure Cache for Redis について - Training
Azure Cache for Redis がアプリのパフォーマンスとスケーラビリティを向上させる方法を評価します。 Redis によって、きわめて低遅延かつ高スループットのデータ ストレージ ソリューションがモダン アプリケーションにもたらされる方法を説明します。
認定資格
Microsoft Certified: Azure Database Administrator Associate - Certifications
Microsoft PaaS リレーショナル データベース オファリングを使用して、クラウド、オンプレミス、ハイブリッド リレーショナル データベースの SQL Server データベース インフラストラクチャを管理します。