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

Azure Cache for Redis には、クラスタリング、永続性、仮想ネットワークのサポートといった Premium レベルの機能を含め、キャッシュのサイズと機能を柔軟に選択できるさまざまなキャッシュ サービスがあります。Azure Cache for Redis 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 Cache for Redis インスタンスを構成する場合、パブリックにアドレスを指定することはできないため、VNet 内の仮想マシンとアプリケーションからしかアクセスできません。When an Azure Cache for Redis 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 Cache for Redis インスタンスの仮想ネットワークのサポートを構成する方法について説明します。This article describes how to configure virtual network support for a premium Azure Cache for Redis instance.

注意

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

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

VNet を選ぶ理由Why VNet?

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

Virtual Network のサポートVirtual network support

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

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

キャッシュの作成

注意

キャッシュは、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 Cache for Redis の作成について詳しくは、キャッシュの作成に関するページを参照してください。For more information about creating an Azure Cache for Redis, 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 portal を使用した仮想ネットワークの作成のページまたは Azure portal を使用した仮想ネットワーク (クラシック) の作成のページの手順に従って VNet を作成した後、 [New Azure Cache for Redis](新しい Azure Cache for Redis) ブレードに戻り、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 Azure Cache for Redis blade to create and configure your premium cache.

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

仮想ネットワーク

[サブネット] ドロップダウン リストから目的のサブネットを選択します。Select the desired subnet from the Subnet drop-down list. 必要に応じて、 [静的 IP アドレス] を指定します。If desired, specify a Static IP address. [静的 IP アドレス] フィールドは省略可能です。指定しない場合は、選択したサブネットから 1 つが選択されます。The Static IP address field is optional, and if none is specified, one is chosen from the selected subnet.

重要

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

仮想ネットワーク

重要

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.

仮想ネットワーク

VNet の使用時に Azure Cache for Redis インスタンスに接続するには、次の例に示すように、接続文字列でキャッシュのホスト名を指定します。To connect to your Azure Cache for Redis 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 Cache for Redis VNet の FAQAzure Cache for Redis VNet FAQ

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

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

Azure Cache for Redis が VNet でホストされている場合は、次の表にあるポートが使用されます。When Azure Cache for Redis 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 Cache for Redis を使用する場合、構成の誤りに関する最も一般的な問題は、これらのポートのうち 1 つ以上がブロックされていることです。Having one or more of these ports blocked is the most common misconfiguration issue when using Azure Cache for Redis in a VNet.

送信ポートの要件Outbound port requirements

送信ポートには 9 個の要件があります。There are nine outbound port requirements. これらの範囲内の送信要求は、キャッシュが機能するために必要な他のサービスに送信されるか、またはノード間通信のために Redis サブネットの内部に送信されます。Outbound requests in these ranges are either outbound to other services necessary for the cache to function or internal to the Redis subnet for internode communication. geo レプリケーションの場合は、プライマリ キャッシュとセカンダリ キャッシュのサブネット間の通信のための追加の送信要件が存在します。For geo-replication, additional outbound requirements exist for communication between subnets of the primary and secondary cache.

ポートPort(s) DirectionDirection トランスポート プロトコル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) *
443443 送信Outbound TCPTCP Azure Key Vault に対する Redis の依存関係Redis dependency on Azure Key Vault (Redis サブネット)(Redis subnet) AzureKeyVault 1AzureKeyVault 1
5353 送信Outbound TCP/UDPTCP/UDP DNS (インターネット/VNet) に対する Redis の依存関係Redis dependencies on DNS (Internet/VNet) (Redis サブネット)(Redis subnet) 168.63.129.16 および 169.254.169.254 2 およびサブネットのカスタム DNS サーバー 3168.63.129.16 and 169.254.169.254 2 and any custom DNS server for the subnet 3
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 および geo レプリケーションの内部通信Internal communications for Redis and Geo-Replication (Redis サブネット)(Redis subnet) (Redis サブネット) (geo レプリカ ピア サブネット)(Redis subnet) (Geo-replica peer subnet)
6379-63806379-6380 送信Outbound TCPTCP Redis の内部通信Internal communications for Redis (Redis サブネット)(Redis subnet) (Redis サブネット)(Redis subnet)

1 Resource Manager ネットワーク セキュリティ グループにサービス タグ 'AzureKeyVault' を使用できます。1 You can use the service tag 'AzureKeyVault' with Resource Manager Network Security Groups.

2 Microsoft が所有するこれらの IP アドレスは、Azure DNS を提供するホスト VM をアドレス指定するために使用されます。2 These IP addresses owned by Microsoft are used to address the Host VM which serves Azure DNS.

3 カスタム DNS サーバーのないサブネット、またはカスタム DNS を無視する新しい redis キャッシュには必要ありません。3 Not needed for subnets with no custom DNS server, or newer redis caches that ignore custom DNS.

geo レプリケーション ピア ポートの要件Geo-replication peer port requirements

Azure Virtual Network 内のキャッシュ間で geo レプリケーションを使用している場合、推奨される構成は、両方のキャッシュに対する受信および送信方向両方において、サブネット全体に対してポート 15000-15999 のブロックを解除することです。これにより、サブネット内のすべてのレプリカ コンポーネントが将来の geo フェールオーバーが発生した場合でも相互に直接通信できるようになります。If you are using georeplication between caches in Azure Virtual Networks, please note that the recommended configuration is to unblock ports 15000-15999 for the whole subnet in both inbound AND outbound directions to both caches, so that all the replica components in the subnet can communicate directly with each other even in the event of a future geo-failover.

受信ポートの要件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) DirectionDirection トランスポート プロトコルTransport Protocol 目的Purpose ローカル IPLocal IP リモート IPRemote IP
6379, 63806379, 6380 受信Inbound TCPTCP Redis へのクライアント通信、Azure 負荷分散Client communication to Redis, Azure load balancing (Redis サブネット)(Redis subnet) (Redis サブネット)、Virtual Network、Azure Load Balancer 1(Redis subnet), Virtual Network, Azure Load Balancer 1
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 負荷分散、geo レプリケーションへのクライアント通信Client communication to Redis Clusters, Azure load Balancing, and Geo-Replication (Redis サブネット)(Redis subnet) Virtual Network、Azure Load Balancer、(geo レプリカ ピア サブネット)Virtual Network, Azure Load Balancer, (Geo-replica peer subnet)
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)

1 NSG 規則を作成するために、サービス タグ 'AzureLoadBalancer' (Resource Manager) (または、クラシックの場合 'AZURE_LOADBALANCER') を使用できます。1 You can use the Service Tag 'AzureLoadBalancer' (Resource Manager) (or 'AZURE_LOADBALANCER' for classic) for authoring the NSG rules.

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

Azure Cache for Redis のネットワーク接続要件には、仮想ネットワークで最初から満たされていないものがある可能性があります。There are network connectivity requirements for Azure Cache for Redis that may not be initially met in a virtual network. 仮想ネットワーク内で使用したときに正常に動作させるには、Azure Cache for Redis に次の項目すべてが必要になります。Azure Cache for Redis 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 Cache for Redis インスタンスと同じリージョンにあるエンドポイントと、他の Azure リージョンにあるストレージ エンドポイントが含まれます。This includes endpoints located in the same region as the Azure Cache for Redis 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 に対する発信ネットワーク接続。Outbound network connectivity to ocsp.msocsp.com, mscrl.microsoft.com, and crl.microsoft.com. この接続は、SSL 機能をサポートするために必要です。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 Cache for Redis インスタンスに接続している場合、キャッシュ クライアントは同じ VNET にあるか、または同じ Azure リージョン内の VNET ピアリングが有効な VNET にある必要があります。When connecting to an Azure Cache for Redis instance that is hosted in a VNET, your cache clients must be in the same VNET or in a VNET with VNET peering enabled within the same Azure region. グローバル VNET ピアリングは現在サポートされていません。Global VNET Peering isn't currently supported. これには、テスト アプリケーションや診断 ping ツールが含まれます。This includes any test applications or diagnostic pinging tools. クライアント アプリケーションがどこでホストされているかに関係なく、クライアントのネットワーク トラフィックが Redis インスタンスに到達できるようネットワーク セキュリティ グループを構成する必要があります。Regardless of where the client application is hosted, Network security groups must be configured such that the client's network traffic is allowed to reach the Redis instance.

前のセクションで説明したようにポート要件を構成した後、次の手順を実行して、キャッシュが動作していることを確認できます。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:

      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.

VNET で自分の Azure Cache for Redis への接続を試行すると、リモート証明書が無効であることを示すエラーが表示されるのはなぜですかWhen trying to connect to my Azure Cache for Redis in a VNET, why am I getting an error stating the remote certificate is invalid?

VNET で自分の Azure Cache for Redis への接続を試行すると、次のような証明書の検証エラーが表示されます。When trying to connect to an Azure Cache for Redis in a VNET, you see a certificate validation error such as this:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

IP アドレスでホストに接続していることが原因になっている可能性があります。The cause could be you are connecting to the host by the IP address. ホスト名を使用することをお勧めします。We recommend using the hostname. つまり、次を使用してください。In other words, use the following:

[mycachename].redis.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

次の接続文字列のような IP アドレスは使用しないでください。Avoid using the IP address similar to the following connection string:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

DNS 名を解決できない場合、StackExchange.Redis クライアントによって指定される sslHost のような構成オプションが、クライアント ライブラリに含まれている場合があります。If you are unable to resolve the DNS name, some client libraries include configuration options like sslHost which is provided by the StackExchange.Redis client. このオプションによって、証明書の検証に使用されるホスト名をオーバーライドできます。This allows you to override the hostname used for certificate validation. 次に例を示します。For example:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.windows.net

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

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

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

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

使用可能な 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.

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

顧客は、 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 Cache for Redis を含む他の 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 Cache for Redis.

ただし、顧客の一般的な構成では、発信インターネット トラフィックを強制的にオンプレミスにフローさせる強制トンネリング (既定のルートのアドバタイズ) が使用されます。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 Cache for Redis との接続を切断します。そのため、Azure Cache for Redis インスタンスがその依存関係と通信できなくなります。This traffic flow breaks connectivity with Azure Cache for Redis if the outbound traffic is then blocked on-premises such that the Azure Cache for Redis instance is not able to communicate with its dependencies.

解決策は、Azure Cache for Redis を含むサブネット上で 1 つ (以上) のユーザー定義ルート (UDR) を定義することです。The solution is to define one (or more) user-defined routes (UDRs) on the subnet that contains the Azure Cache for Redis. 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 Cache for Redis を含むサブネットに適用される UDR は、たとえば、次ホップの種類を 'Internet' に設定することにより、パブリックなインターネットへの TCP/IP トラフィックの作業ルートを持つ 0.0.0.0/0 と定義します。The UDR applied to the subnet containing the Azure Cache for Redis 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 Cache for Redis からの発信インターネット アクセスを確保できます。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 Cache for Redis.

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

重要

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 Cache for Redis は、パブリック ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない ExpressRoute 構成ではサポートされません。Azure Cache for Redis 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 Cache for Redis インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。If these address ranges are incorrectly cross-advertised on the private peering path, the result is that all outbound network packets from the Azure Cache for Redis instance's subnet are incorrectly force-tunneled to a customer's on-premises network infrastructure. このネットワーク フローでは、Azure Cache for Redis が機能しません。This network flow breaks Azure Cache for Redis. この問題を解決するには、パブリック ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。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.