Premium Azure Redis Cache の Virtual Network のサポートを構成する方法How to configure Virtual Network Support for a Premium Azure Redis Cache

Azure Redis Cache には、クラスタリング、永続性、仮想ネットワークのサポートといった Premium レベルの機能など、キャッシュのサイズと機能を柔軟に選択できるさまざまなキャッシュ サービスがあります。Azure Redis Cache has different cache offerings, which provide flexibility in the choice of cache size and features, including Premium tier features such as clustering, persistence, and virtual network support. VNet とは、クラウド内のプライベート ネットワークです。A VNet is a private network in the cloud. VNet を使用して Azure Redis Cache インスタンスを構成する場合、パブリックにアドレスを指定することはできないため、VNet 内の仮想マシンとアプリケーションからしかアクセスできません。When an Azure Redis Cache instance is configured with a VNet, it is not publicly addressable and can only be accessed from virtual machines and applications within the VNet. この記事では、Premium Azure Redis Cache インスタンスの仮想ネットワークのサポートを構成する方法について説明します。This article describes how to configure virtual network support for a premium Azure Redis Cache instance.

注意

Azure Redis Cache では、クラシック VNet と Resource Manager VNet の両方がサポートされています。Azure Redis Cache supports both classic and Resource Manager VNets.

Premium キャッシュのその他の機能の詳細については、「 Azure Redis Cache Premium レベルの概要」を参照してください。For information on other premium cache features, see Introduction to the Azure Redis Cache Premium tier.

VNet を選ぶ理由Why VNet?

Azure Virtual Network (VNet) のデプロイにより、Azure Redis Cache のセキュリティと分離が強化されるとともに、サブネット、アクセス制御ポリシー、アクセスをさらに制御する他の機能も提供されます。Azure Virtual Network (VNet) deployment provides enhanced security and isolation for your Azure Redis Cache, as well as subnets, access control policies, and other features to further restrict access.

Virtual Network のサポートVirtual network support

仮想ネットワーク (VNet) のサポートは、キャッシュの作成中に [新規 Redis Cache] ブレードで構成します。Virtual Network (VNet) support is configured on the New Redis Cache blade during cache creation.

Premium キャッシュを作成するには、Azure Portal にサインインし、[新規] > [データベース] > [Redis Cache] の順にクリックします。To create a premium cache, sign-in to the Azure portal and click New > Databases > Redis Cache.

キャッシュの作成

注意

キャッシュは、Azure ポータルだけでなく、Resource Manager テンプレート、PowerShell、または Azure CLI を使用して作成することもできます。In addition to creating caches in the Azure portal, you can also create them using Resource Manager templates, PowerShell, or Azure CLI. Azure Redis Cache の作成について詳しくは、キャッシュの作成に関するページをご覧ください。For more information about creating an Azure Redis Cache, see Create a cache.

Premium 機能を構成するには、まず [料金レベル] ドロップダウン リストで Premium 価格レベルのいずれかを選択します。To configure premium features, first select one of the premium pricing tiers in the Pricing tier drop-down list. 各価格レベルの詳細については、[価格の詳細を表示] をクリックし、[価格レベルの選択] ブレードから価格レベルを選択します。For more information about each pricing tier, click View full pricing details and select a pricing tier from the Choose your pricing tier blade.

[料金レベルの選択]

Premium 価格レベルを選択すると、キャッシュと同じサブスクリプションと場所にある VNet を選択することで、Redis VNet 統合を構成できます。Once you have selected a premium pricing tier, you can configure Redis VNet integration by selecting a VNet that is in the same subscription and location as your cache. 新しい VNet を使用するには、まず「Azure ポータルを使用した仮想ネットワークの作成」または「Azure ポータルを使用した仮想ネットワーク (従来型) の作成」の手順に従って VNet を作成した後、[新規 Redis Cache] ブレードに戻り、Premium キャッシュを作成して構成します。To use a new VNet, create it first by following the steps in Create a virtual network using the Azure portal or Create a virtual network (classic) by using the Azure portal and then return to the New Redis Cache blade to create and configure your premium cache.

新しいキャッシュ用に VNet を構成するには、[新規 Redis Cache] ブレードの [仮想ネットワーク] をクリックし、ドロップダウン リストから目的の VNet を選択します。To configure the VNet for your new cache, click Virtual Network on the New Redis Cache blade, and select the desired VNet from the drop-down list.

Virtual Network

[サブネット] ボックスの一覧で目的のサブネットを選択し、必要な静的 IP アドレスを指定します。Select the desired subnet from the Subnet drop-down list, and specify the desired Static IP address. クラシック VNet を使用している場合、[静的 IP アドレス] フィールドは省略可能です。何も指定しないと、選択したサブネットから 1 つのアドレスが選択されます。If you are using a classic VNet the Static IP address field is optional, and if none is specified, one is chosen from the selected subnet.

重要

Azure Redis Cache を Resource Manager VNet にデプロイする場合、キャッシュは、Azure Redis Cache インスタンス以外のリソースを含まない専用サブネット内に存在する必要があります。When deploying an Azure Redis Cache to a Resource Manager VNet, the cache must be in a dedicated subnet that contains no other resources except for Azure Redis Cache instances. Resource Manager VNet で他のリソースが含まれるサブネットに Azure Redis Cache をデプロイしようとすると、そのデプロイは失敗します。If an attempt is made to deploy an Azure Redis Cache to a Resource Manager VNet to a subnet that contains other resources, the deployment fails.

Virtual Network

重要

Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。Azure reserves some IP addresses within each subnet, and these addresses can't be used. サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。The first and last IP addresses of the subnets are reserved for protocol conformance, along with three more addresses used for Azure services. 詳細については、「 これらのサブネット内の IP アドレスの使用に関する制限はありますかFor more information, see Are there any restrictions on using IP addresses within these subnets?

Azure VNET インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Redis インスタンスは、シャードごとに 2 つの IP アドレスおよびロード バランサー用に 1 つの追加 IP アドレスを使用します。In addition to the IP addresses used by the Azure VNET infrastructure, each Redis instance in the subnet uses two IP addresses per shard and one additional IP address for the load balancer. クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。A non-clustered cache is considered to have one shard.

キャッシュが作成されたら、[リソース] メニューの [仮想ネットワーク] をクリックすることで、VNet の構成を表示できます。After the cache is created, you can view the configuration for the VNet by clicking Virtual Network from the Resource menu.

Virtual Network

VNet の使用時に Azure Redis Cache インスタンスに接続するには、次の例に示すように、接続文字列でキャッシュのホスト名を指定します。To connect to your Azure Redis cache instance when using a VNet, specify the host name of your cache in the connection string as shown in the following example:

private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    return ConnectionMultiplexer.Connect("contoso5premium.redis.cache.windows.net,abortConnect=false,ssl=true,password=password");
});

public static ConnectionMultiplexer Connection
{
    get
    {
        return lazyConnection.Value;
    }
}

Azure Redis Cache VNet についてよく寄せられる質問 (FAQ)Azure Redis Cache VNet FAQ

次の一覧は、Azure Redis Cache のスケーリングに関するよく寄せられる質問への回答です。The following list contains answers to commonly asked questions about the Azure Redis Cache scaling.

Azure Redis Cache と VNet の誤った構成に関してよく見られる問題を教えてくださいWhat are some common misconfiguration issues with Azure Redis Cache and VNets?

Azure Redis Cache が VNet でホストされている場合は、次の表にあるポートが使用されます。When Azure Redis Cache is hosted in a VNet, the ports in the following tables are used.

重要

次の表のポートがブロックされている場合、キャッシュが正常に動作しない可能性があります。If the ports in the following tables are blocked, the cache may not function correctly. VNet で Azure Redis Cache を使用する場合、構成の誤りに関する最も一般的な問題は、これらのポートのうち 1 つ以上がブロックされていることです。Having one or more of these ports blocked is the most common misconfiguration issue when using Azure Redis Cache in a VNet.

送信ポートの要件Outbound port requirements

送信ポートには 7 個の要件があります。There are seven outbound port requirements.

  • 必要に応じて、インターネットに対するすべての送信接続をクライアントのオンプレミス監査デバイス経由にすることができます。If desired, all outbound connections to the internet can be made through a client's on-premises auditing device.
  • 3 つのポートは、Azure Storage と Azure DNS を提供する Azure エンドポイントにトラフィックをルーティングします。Three of the ports route traffic to Azure endpoints servicing Azure Storage and Azure DNS.
  • その他のポート範囲は、内部の Redis サブネット通信用です。The remaining port ranges and for internal Redis subnet communications. 内部 Redis サブネット通信用にサブネット NSG 規則は必要ありません。No subnet NSG rules are required for internal Redis subnet communications.
ポートPort(s) 方向Direction トランスポート プロトコルTransport Protocol 目的Purpose ローカル IPLocal IP リモート IPRemote IP
80、44380, 443 送信Outbound TCPTCP Azure Storage/PKI (インターネット) に対する Redis の依存関係Redis dependencies on Azure Storage/PKI (Internet) (Redis サブネット)(Redis subnet) *
5353 送信Outbound TCP/UDPTCP/UDP DNS (インターネット/VNet) に対する Redis の依存関係Redis dependencies on DNS (Internet/VNet) (Redis サブネット)(Redis subnet) *
84438443 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)
10221-1023110221-10231 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)
2022620226 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)
13000-1399913000-13999 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)
15000-1599915000-15999 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)

受信ポートの要件Inbound port requirements

受信ポートの範囲には、8 個の要件があります。There are eight inbound port range requirements. これらの範囲の受信要件は、同じ VNET でホストされている他のサービスからの受信、または Redis サブネット通信への内部の要件です。Inbound requests in these ranges are either inbound from other services hosted in the same VNET or internal to the Redis subnet communications.

ポートPort(s) 方向Direction トランスポート プロトコルTransport Protocol 目的Purpose ローカル IPLocal IP リモート IPRemote IP
6379, 63806379, 6380 受信Inbound TCPTCP Redis へのクライアント通信、Azure 負荷分散Client communication to Redis, Azure load balancing (Redis サブネット)(Redis subnet) Virtual Network、Azure Load BalancerVirtual Network, Azure Load Balancer
84438443 受信Inbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)
85008500 受信Inbound TCP/UDPTCP/UDP Azure 負荷分散Azure load balancing (Redis サブネット)(Redis subnet) Azure Load BalancerAzure Load Balancer
10221-1023110221-10231 受信Inbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)、Azure Load Balancer(Redis subnet), Azure Load Balancer
13000-1399913000-13999 受信Inbound TCPTCP Redis クラスターへのクライアント通信、Azure 負荷分散Client communication to Redis Clusters, Azure load balancing (Redis サブネット)(Redis subnet) Virtual Network、Azure Load BalancerVirtual Network, Azure Load Balancer
15000-1599915000-15999 受信Inbound TCPTCP Redis クラスターへのクライアント通信、Azure 負荷分散Client communication to Redis Clusters, Azure load Balancing (Redis サブネット)(Redis subnet) Virtual Network、Azure Load BalancerVirtual Network, Azure Load Balancer
1600116001 受信Inbound TCP/UDPTCP/UDP Azure 負荷分散Azure load balancing (Redis サブネット)(Redis subnet) Azure Load BalancerAzure Load Balancer
2022620226 受信Inbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)

その他の VNET ネットワーク接続の要件Additional VNET network connectivity requirements

Azure Redis Cache のネットワーク接続要件には、仮想ネットワークで最初に満たされていないものがある可能性があります。There are network connectivity requirements for Azure Redis Cache that may not be initially met in a virtual network. 仮想ネットワーク内で使用したときに正常に動作させるには、Azure Redis Cache に次の項目すべてが必要になります。Azure Redis Cache requires all the following items to function properly when used within a virtual network.

  • 世界各国の Azure Storage エンドポイントに対する発信ネットワーク接続Outbound network connectivity to Azure Storage endpoints worldwide. これには、Azure Redis Cache インスタンスと同じリージョンにあるエンドポイントと、他の Azure リージョンにあるストレージ エンドポイントが含まれます。This includes endpoints located in the same region as the Azure Redis Cache instance, as well as storage endpoints located in other Azure regions. Azure Storage エンドポイントは、次の DNS ドメインで解決されます: table.core.windows.netblob.core.windows.netqueue.core.windows.netfile.core.windows.netAzure Storage endpoints resolve under the following DNS domains: table.core.windows.net, blob.core.windows.net, queue.core.windows.net, and file.core.windows.net.
  • ocsp.msocsp.commscrl.microsoft.comcrl.microsoft.com に対する発信ネットワーク接続。この接続は、SSL 機能をサポートするために必要です。Outbound network connectivity to ocsp.msocsp.com, mscrl.microsoft.com, and crl.microsoft.com. This connectivity is needed to support SSL functionality.
  • 仮想ネットワークの DNS 構成は、前述したすべてのエンドポイントとドメインを解決できるようにする必要があります。The DNS configuration for the virtual network must be capable of resolving all of the endpoints and domains mentioned in the earlier points. これらの DNS 要件を満たすには、仮想ネットワークの有効な DNS インフラストラクチャを構成し、保守します。These DNS requirements can be met by ensuring a valid DNS infrastructure is configured and maintained for the virtual network.
  • 次の DNS ドメインで解決される次の Azure Monitoring エンドポイントに対する発信ネットワーク接続: shoebox2-black.shoebox2.metrics.nsatc.net、north-prod2.prod2.metrics.nsatc.net、azglobal-black.azglobal.metrics.nsatc.net、shoebox2-red.shoebox2.metrics.nsatc.net、east-prod2.prod2.metrics.nsatc.net、azglobal-red.azglobal.metrics.nsatc.net。Outbound network connectivity to the following Azure Monitoring endpoints, which resolve under the following DNS domains: shoebox2-black.shoebox2.metrics.nsatc.net, north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.metrics.nsatc.net, shoebox2-red.shoebox2.metrics.nsatc.net, east-prod2.prod2.metrics.nsatc.net, azglobal-red.azglobal.metrics.nsatc.net.

VNET で自分のキャッシュの動作を確認するにはどうすればよいですかHow can I verify that my cache is working in a VNET?

重要

VNET にホストされている Azure Redis Cache インスタンスに接続している場合、キャッシュ クライアントはテスト アプリケーションや診断 ping ツールを含む同じ VNET にある必要があります。When connecting to an Azure Redis Cache instance that is hosted in a VNET, your cache clients must be in the same VNET, including any test applications or diagnostic pinging tools.

前のセクションで説明したようにポート要件を構成した後、次の手順を実行して、キャッシュが動作していることを確認できます。Once the port requirements are configured as described in the previous section, you can verify that your cache is working by performing the following steps.

  • すべてのキャッシュ ノードを再起動します。Reboot all of the cache nodes. 必要なすべてのキャッシュ依存関係 (「受信ポートの要件」「送信ポートの要件」で説明) に到達できない場合、キャッシュは正常に再起動できません。If all of the required cache dependencies can't be reached (as documented in Inbound port requirements and Outbound port requirements), the cache won't be able to restart successfully.
  • キャッシュ ノードが再起動したら (Azure Portal のキャッシュの状態で報告されます)、次のテストを実行できます。Once the cache nodes have restarted (as reported by the cache status in the Azure portal), you can perform the following tests:

    • tcping を使って、キャッシュと同じ VNET 内にあるコンピューターからキャッシュ エンドポイントを ping します (ポート 6380 を使用)。ping the cache endpoint (using port 6380) from a machine that is within the same VNET as the cache, using tcping. For example:For example:

      tcping.exe contosocache.redis.cache.windows.net 6380

      tcping ツールでポートが開いていることがレポートされる場合、キャッシュは VNET 内のクライアントからの接続に使用できます。If the tcping tool reports that the port is open, the cache is available for connection from clients in the VNET.

    • キャッシュに接続してキャッシュのいくつかの項目を追加および取得するテスト キャッシュ クライアント (StackExchange.Redis を使ったシンプルなコンソール アプリケーションにできます) を作成することでテストする方法もあります。Another way to test is to create a test cache client (which could be a simple console application using StackExchange.Redis) that connects to the cache and adds and retrieves some items from the cache. このサンプル クライアント アプリケーションをキャッシュと同じ VNET 内の VM にインストールし、実行してキャッシュへの接続性を確認します。Install the sample client application onto a VM that is in the same VNET as the cache and run it to verify connectivity to the cache.

Standard キャッシュまたは Basic キャッシュで VNet を使用できますかCan I use VNets with a standard or basic cache?

VNet は Premium キャッシュでのみ使用できます。VNets can only be used with premium caches.

Redis Cache の作成が失敗するサブネットと成功するサブネットがあるのはなぜですかWhy does creating a Redis cache fail in some subnets but not others?

Azure Redis Cache を Resource Manager VNet にデプロイする場合、キャッシュは、他の種類のリソースが含まれない専用サブネット内に存在する必要があります。If you are deploying an Azure Redis Cache to a Resource Manager VNet, the cache must be in a dedicated subnet that contains no other resource type. 他のリソースが含まれる Resource Manager VNet サブネットに Azure Redis Cache をデプロイしようとすると、そのデプロイは失敗します。If an attempt is made to deploy an Azure Redis Cache to a Resource Manager VNet subnet that contains other resources, the deployment fails. 新しい Redis Cache を作成する前に、サブネット内の既存のリソースを削除する必要があります。You must delete the existing resources inside the subnet before you can create a new Redis cache.

使用可能な IP アドレスが十分にあれば、複数の種類のリソースをクラシック VNet にデプロイできます。You can deploy multiple types of resources to a classic VNet as long as you have enough IP addresses available.

サブネット アドレス空間の要件には何がありますかWhat are the subnet address space requirements?

Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。Azure reserves some IP addresses within each subnet, and these addresses can't be used. サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。The first and last IP addresses of the subnets are reserved for protocol conformance, along with three more addresses used for Azure services. 詳細については、「 これらのサブネット内の IP アドレスの使用に関する制限はありますかFor more information, see Are there any restrictions on using IP addresses within these subnets?

Azure VNET インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Redis インスタンスは、シャードごとに 2 つの IP アドレスおよびロード バランサー用に 1 つの追加 IP アドレスを使用します。In addition to the IP addresses used by the Azure VNET infrastructure, each Redis instance in the subnet uses two IP addresses per shard and one additional IP address for the load balancer. クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。A non-clustered cache is considered to have one shard.

VNET でキャッシュをホストしている場合、キャッシュ機能はすべて動作しますかDo all cache features work when hosting a cache in a VNET?

キャッシュが VNET の一部である場合は、VNET のクライアントだけがキャッシュにアクセスできます。When your cache is part of a VNET, only clients in the VNET can access the cache. そのため、次のキャッシュ管理機能は現時点では動作しません。As a result, the following cache management features don't work at this time.

  • Redis コンソール - Redis コンソールは、VNET の外部にあるローカル ブラウザーで実行されるため、キャッシュに接続できません。Redis Console - Because Redis Console runs in your local browser, which is outside the VNET, it can't connect to your cache.

Azure Redis Cache と ExpressRoute の使用Use ExpressRoute with Azure Redis Cache

顧客は、 Azure ExpressRoute 回線を自分の仮想ネットワーク インフラストラクチャに接続することで、オンプレミスのネットワークを Azure に拡張できます。Customers can connect an Azure ExpressRoute circuit to their virtual network infrastructure, thus extending their on-premises network to Azure.

既定では、新たに作成した ExpressRoute 回線では VNET での強制トンネリングは実行されません (既定のルートのアドバタイズ、0.0.0.0/0)。By default, a newly created ExpressRoute circuit does not perform forced tunneling (advertisement of a default route, 0.0.0.0/0) on a VNET. その結果、発信インターネット接続は VNET から直接行うことができ、クライアント アプリケーションは、Azure Redis Cache を含む他の Azure エンドポイントに接続できます。As a result, outbound Internet connectivity is allowed directly from the VNET and client applications are able to connect to other Azure endpoints including Azure Redis Cache.

ただし、顧客の一般的な構成では、発信インターネット トラフィックを強制的にオンプレミスにフローさせる強制トンネリング (既定のルートのアドバタイズ) が使用されます。However a common customer configuration is to use forced tunneling (advertise a default route) which forces outbound Internet traffic to instead flow on-premises. このトラフィック フローは、送信トラフィックの場合には、Azure Redis Cache との接続を切断し、Azure Redis Cache インスタンスがその依存関係と通信できないように、オンプレミスでブロックされます。This traffic flow breaks connectivity with Azure Redis Cache if the outbound traffic is then blocked on-premises such that the Azure Redis Cache instance is not able to communicate with its dependencies.

解決策は、Azure Redis Cache を含むサブネット上で 1 つ (以上) のユーザー定義ルート (UDR) を定義することです。The solution is to define one (or more) user-defined routes (UDRs) on the subnet that contains the Azure Redis Cache. UDR は、既定のルートに優先するサブネット固有のルートを定義します。A UDR defines subnet-specific routes that will be honored instead of the default route.

可能であれば、次の構成を使用することをお勧めします。If possible, it is recommended to use the following configuration:

  • ExpressRoute 構成は 0.0.0.0/0 をアドバタイズし、既定でオンプレミスのすべての発信トラフィックを強制的にトンネリングします。The ExpressRoute configuration advertises 0.0.0.0/0 and by default force tunnels all outbound traffic on-premises.
  • Azure Redis Cache を含むサブネットに適用される UDR は、たとえば、次ホップの種類を 'Internet' に設定することにより、パブリックなインターネットへの TCP/IP トラフィックの作業ルートを持つ 0.0.0.0/0 と定義します。The UDR applied to the subnet containing the Azure Redis Cache defines 0.0.0.0/0 with a working route for TCP/IP traffic to the public internet; for example by setting the next hop type to 'Internet'.

これらの手順を組み合わせた結果として、サブネット レベル UDR は ExpressRoute 強制トンネリングよりも優先されるので、Azure Redis Cache からの発信インターネット アクセスを確保できます。The combined effect of these steps is that the subnet level UDR takes precedence over the ExpressRoute forced tunneling, thus ensuring outbound Internet access from the Azure Redis Cache.

ExpressRoute を使用したオンプレミス アプリケーションから Azure Redis Cache インスタンスへの接続は、パフォーマンス上の理由から一般的な使用シナリオではありません (最適なパフォーマンスを得るには、Azure Redis Cache クライアントを Azure Redis Cache と同じリージョンに配置する必要があります)。Connecting to an Azure Redis Cache instance from an on-premises application using ExpressRoute is not a typical usage scenario due to performance reasons (for best performance Azure Redis Cache clients should be in the same region as the Azure Redis Cache).

重要

ExpressRoute 構成でアドバタイズされたルートよりも優先するには、UDR に定義されているルートを詳細にする 必要がありますThe routes defined in a UDR must be specific enough to take precedence over any routes advertised by the ExpressRoute configuration. 以下の例では、0.0.0.0/0 の広域なアドレス範囲を使用しているので、より詳細なアドレス範囲を使用するルート アドバタイズで誤って上書きされる可能性があります。The following example uses the broad 0.0.0.0/0 address range, and as such can potentially be accidentally overridden by route advertisements using more specific address ranges.

警告

Azure Redis Cache は、パブリック ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない ExpressRoute 構成ではサポートされません。Azure Redis Cache is not supported with ExpressRoute configurations that incorrectly cross-advertise routes from the public peering path to the private peering path. パブリック ピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルート アドバタイズを受信します。ExpressRoute configurations that have public peering configured, receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. これらのアドレス範囲がプライベート ピアリング パスで誤ってクロスアドバタイズされている場合、Azure Redis Cache インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。If these address ranges are incorrectly cross-advertised on the private peering path, the result is that all outbound network packets from the Azure Redis Cache instance's subnet are incorrectly force-tunneled to a customer's on-premises network infrastructure. このネットワーク フローでは、Azure Redis Cache が機能しません。This network flow breaks Azure Redis Cache. この問題を解決するには、パブリック ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。The solution to this problem is to stop cross-advertising routes from the public peering path to the private peering path.

ユーザー定義ルートの背景情報については、この 概要を参照してください。Background information on user-defined routes is available in this overview.

ExpressRoute の詳細については、「ExpressRoute の技術概要」を参照してください。For more information about ExpressRoute, see ExpressRoute technical overview.

次のステップNext steps

Premium キャッシュ機能をさらに使用する方法を学習します。Learn how to use more premium cache features.