Konfigurowanie obsługi sieci wirtualnej dla wystąpienia usługi Azure Cache for Redis w wersji Premium

Wdrożenie usługi Azure Virtual Network zapewnia zwiększone zabezpieczenia i izolację, a także: podsieci, zasady kontroli dostępu i inne funkcje umożliwiające dalsze ograniczanie dostępu. Gdy wystąpienie Azure Cache for Redis jest skonfigurowane z siecią wirtualną, nie jest ono publicznie adresowane. Zamiast tego dostęp do wystąpienia można uzyskać tylko z maszyn wirtualnych i aplikacji w sieci wirtualnej. W tym artykule opisano sposób konfigurowania obsługi sieci wirtualnej dla wystąpienia Azure Cache for Redis w warstwie Premium.

Uwaga

Klasyczny model wdrażania zostanie wycofany w sierpniu 2024 r. Aby uzyskać więcej informacji, zobacz Cloud Services (klasyczny) model wdrażania jest wycofywalny 31 sierpnia 2024 r.

Ważne

Usługa Azure Cache for Redis obsługuje teraz usługę Azure Private Link, co upraszcza architekturę sieci i zabezpiecza połączenie między punktami końcowymi na platformie Azure. Umożliwia łączenie się z wystąpieniem usługi Azure Cache z sieci wirtualnej za pośrednictwem prywatnego punktu końcowego, który ma przypisany prywatny adres IP w podsieci w sieci wirtualnej. Usługa Azure Private Link, która jest oferowana we wszystkich warstwach, obejmuje obsługę usługi Azure Policy i uproszczone zarządzanie regułami sieciowej grupy zabezpieczeń. Aby dowiedzieć się więcej, zobacz Dokumentacja usługi Private Link. Aby przeprowadzić migrację wstrzykniętych pamięci podręcznych sieci wirtualnej do Private Link, zobacz tutaj.

Konfigurowanie obsługi sieci wirtualnej

Obsługa sieci wirtualnej jest konfigurowana w okienku Nowe Azure Cache for Redis podczas tworzenia pamięci podręcznej.

  1. Aby utworzyć pamięć podręczną w warstwie Premium, zaloguj się do Azure Portal i wybierz pozycję Utwórz zasób. Można je również utworzyć przy użyciu szablonów Resource Manager, programu PowerShell lub interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji na temat tworzenia wystąpienia Azure Cache for Redis, zobacz Tworzenie pamięci podręcznej.

    Zrzut ekranu przedstawiający tworzenie zasobu.

  2. Na stronie Nowy wybierz pozycję Bazy danych. Następnie wybierz pozycję Azure Cache for Redis.

    Zrzut ekranu przedstawiający wybieranie Azure Cache for Redis.

  3. Na stronie Nowa pamięć podręczna Redis Cache skonfiguruj ustawienia nowej pamięci podręcznej w warstwie Premium.

    Ustawienie Sugerowana wartość Opis
    Nazwa DNS Podaj globalnie unikatową nazwę. Nazwa pamięci podręcznej musi być ciągiem od 1 do 63 znaków, które zawierają tylko cyfry, litery lub łączniki. Nazwa musi zaczynać się i kończyć cyfrą lub literą i nie może zawierać kolejnych łączników. Nazwa hosta wystąpienia pamięci podręcznej będzie nazwą <DNS.redis.cache.windows.net>.
    Subskrypcja Wybierz swoją subskrypcję z listy rozwijanej. Subskrypcja, w ramach której ma zostać utworzone to nowe wystąpienie Azure Cache for Redis.
    Grupa zasobów Wybierz grupę zasobów z listy rozwijanej lub wybierz pozycję Utwórz nową i wprowadź nową nazwę grupy zasobów. Nazwa grupy zasobów, w której ma zostać utworzona pamięć podręczna i inne zasoby. Umieszczając wszystkie zasoby aplikacji w jednej grupie zasobów, można je łatwo zarządzać lub usuwać razem.
    Lokalizacja Wybierz lokalizację z listy rozwijanej. Wybierz region w pobliżu innych usług, które będą używać pamięci podręcznej.
    Typ pamięci podręcznej Wybierz pamięć podręczną w warstwie Premium z listy rozwijanej, aby skonfigurować funkcje warstwy Premium. Aby uzyskać więcej informacji, zobacz Azure Cache for Redis cennik. Warstwa cenowa decyduje o rozmiarze, wydajności i funkcjach dostępnych dla pamięci podręcznej. Aby uzyskać więcej informacji, zobacz omówienie Azure Cache for Redis.
  4. Wybierz kartę Sieć lub wybierz przycisk Sieć w dolnej części strony.

  5. Na karcie Sieć wybierz pozycję Sieci wirtualne jako metodę łączności. Aby użyć nowej sieci wirtualnej, utwórz ją najpierw, wykonując kroki opisane w temacie Tworzenie sieci wirtualnej przy użyciu Azure Portal lub Tworzenie sieci wirtualnej (klasycznej) przy użyciu Azure Portal. Następnie wróć do okienka Nowa Azure Cache for Redis, aby utworzyć i skonfigurować pamięć podręczną w warstwie Premium.

    Ważne

    Podczas wdrażania Azure Cache for Redis w sieci wirtualnej Resource Manager pamięć podręczna musi znajdować się w dedykowanej podsieci, która nie zawiera żadnych innych zasobów z wyjątkiem wystąpień Azure Cache for Redis. Jeśli spróbujesz wdrożyć wystąpienie usługi Azure Cache for Redis w podsieci sieci wirtualnej struktury Resource Manager, która zawiera inne zasoby lub ma przypisaną bramę NAT, wdrożenie zakończy się niepowodzeniem. Błąd jest spowodowany tym, że Azure Cache for Redis używa podstawowego modułu równoważenia obciążenia, który nie jest zgodny z bramą translatora adresów sieciowych.

    Ustawienie Sugerowana wartość Opis
    Sieć wirtualna Wybierz sieć wirtualną z listy rozwijanej. Wybierz sieć wirtualną znajdującą się w tej samej subskrypcji i lokalizacji co pamięć podręczna.
    Podsieć Wybierz podsieć z listy rozwijanej. Zakres adresów podsieci powinien znajdować się w notacji CIDR (na przykład 192.168.1.0/24). Musi on być zawarty w przestrzeni adresowej sieci wirtualnej.
    Statyczny adres IP (Opcjonalnie) Wprowadź statyczny adres IP. Jeśli nie określisz statycznego adresu IP, adres IP zostanie wybrany automatycznie.

    Ważne

    Platforma Azure rezerwuje kilka adresów IP w każdej podsieci i tych adresów nie można używać. Pierwsze i ostatnie adresy IP podsieci są rezerwowane na potrzeby zgodności protokołów, a trzy dodatkowe adresy są używane przez usługi platformy Azure. Aby uzyskać więcej informacji, zobacz Czy istnieją ograniczenia dotyczące używania adresów IP w tych podsieciach?

    Oprócz adresów IP używanych przez infrastrukturę sieci wirtualnej platformy Azure każde wystąpienie usługi Azure Cache for Redis w podsieci używa dwóch adresów IP na ekstent i jednego dodatkowego adresu IP dla modułu równoważenia obciążenia. Uważa się, że nieklastrowana pamięć podręczna ma jeden ekstent.

  6. Wybierz kartę Dalej: Zaawansowane lub wybierz przycisk Dalej: Zaawansowane w dolnej części strony.

  7. Na karcie Zaawansowane dla wystąpienia pamięci podręcznej w warstwie Premium skonfiguruj ustawienia portów innych niż TLS, klastrowanie i trwałość danych.

  8. Wybierz kartę Dalej: Tagi lub wybierz przycisk Dalej: Tagi w dolnej części strony.

  9. Opcjonalnie na karcie Tagi wprowadź nazwę i wartość, jeśli chcesz sklasyfikować zasób.

  10. Wybierz pozycję Przejrzyj i utwórz. Zostanie wyświetlona karta Przeglądanie i tworzenie , na której platforma Azure weryfikuje konfigurację.

  11. Po pojawieniu się zielonego komunikatu Weryfikacja przekazana pomyślnie wybierz pozycję Utwórz.

Utworzenie pamięci podręcznej zajmuje trochę czasu. Postęp można monitorować na stronie Przegląd Azure Cache for Redis. Gdy stan jest wyświetlany jako Uruchomiono, pamięć podręczna jest gotowa do użycia. Po utworzeniu pamięci podręcznej możesz wyświetlić konfigurację sieci wirtualnej, wybierając pozycję Virtual Network z menu Zasób.

Sieć wirtualna

Często zadawane pytania dotyczące sieci wirtualnej usługi Azure Cache for Redis

Poniższa lista zawiera odpowiedzi na często zadawane pytania dotyczące skalowania Azure Cache for Redis.

Jakie są typowe problemy z błędną konfiguracją Azure Cache for Redis i sieciami wirtualnymi?

Gdy Azure Cache for Redis jest hostowana w sieci wirtualnej, używane są porty w poniższych tabelach.

Ważne

Jeśli porty w poniższych tabelach są zablokowane, pamięć podręczna może nie działać poprawnie. Zablokowanie co najmniej jednego z tych portów jest najczęstszą błędną konfiguracją podczas korzystania z Azure Cache for Redis w sieci wirtualnej.

Wymagania dotyczące portów wychodzących

Istnieje dziewięć wymagań dotyczących portów wychodzących. Żądania wychodzące w tych zakresach to: a) wychodzące do innych usług niezbędnych do działania pamięci podręcznej lub b) wewnętrzne do podsieci Redis na potrzeby komunikacji międzywęźle. W przypadku replikacji geograficznej istnieją inne wymagania dotyczące ruchu wychodzącego dla komunikacji między podsieciami podstawowej i repliki pamięci podręcznej.

Porty Kierunek Protokół transportu Przeznaczenie Lokalny adres IP Zdalny adres IP
80, 443 Wychodzący TCP Zależności usługi Redis w usłudze Azure Storage/infrastrukturze kluczy publicznych (Internet) (Podsieć redis) * 4
443 Wychodzący TCP Zależność usługi Redis od usług Azure Key Vault i Azure Monitor (Podsieć redis) AzureKeyVault, AzureMonitor 1
53 Wychodzący TCP/UDP Zależności usługi Redis w systemie DNS (internet/sieć wirtualna) (Podsieć redis) 168.63.129.16 i 169.254.169.254 2 i dowolny niestandardowy serwer DNS dla podsieci 3
8443 Wychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)
10221-10231 Wychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)
20226 Wychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)
13000-13999 Wychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)
15000-15999 Wychodzący TCP Komunikacja wewnętrzna na potrzeby usługi Redis i replikacji geograficznej (Podsieć redis) (Podsieć redis) (Podsieć równorzędna repliki geograficznej)
6379-6380 Wychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)

1 Możesz użyć tagów usług AzureKeyVault i AzureMonitor z Resource Manager sieciowych grup zabezpieczeń.

2 Te adresy IP należące do firmy Microsoft są używane do adresowania maszyny wirtualnej hosta, która obsługuje usługę Azure DNS.

3 Te informacje nie są potrzebne w przypadku podsieci bez niestandardowego serwera DNS ani nowszych pamięci podręcznych Redis, które ignorują niestandardowy system DNS.

4 Aby uzyskać więcej informacji, zobacz Dodatkowe wymagania dotyczące łączności z siecią wirtualną.

Wymagania dotyczące portów równorzędnych replikacji geograficznej

Jeśli używasz replikacji geograficznej między pamięciami podręcznymi w sieciach wirtualnych platformy Azure: a) odblokuj porty 15000–15999 dla całej podsieci zarówno w kierunkach przychodzących, jak i wychodzących, a b) do obu pamięci podręcznych. Dzięki tej konfiguracji wszystkie składniki repliki w podsieci mogą komunikować się bezpośrednio ze sobą, nawet jeśli w przyszłości nastąpi przejście w tryb failover z replikacją geograficzną.

Wymagania dotyczące portów przychodzących

Istnieje osiem wymagań dotyczących zakresu portów wejściowych. Żądania przychodzące w tych zakresach są przychodzące z innych usług hostowanych w tej samej sieci wirtualnej. Mogą też być wewnętrzne w komunikacji z podsiecią usługi Redis.

Porty Kierunek Protokół transportu Przeznaczenie Lokalny adres IP Zdalny adres IP
6379, 6380 Przychodzący TCP Komunikacja klienta z usługą Redis, równoważeniem obciążenia platformy Azure (Podsieć redis) (Podsieć usługi Redis), (podsieć klienta), AzureLoadBalancer 1
8443 Przychodzący TCP Komunikacja wewnętrzna usługi Redis (Podsieć redis) (Podsieć redis)
8500 Przychodzący TCP/UDP Równoważenie obciążenia na platformie Azure (Podsieć Redis) AzureLoadBalancer
10221-10231 Przychodzący TCP Komunikacja klienta z klastrami Redis, komunikacja wewnętrzna dla usługi Redis (Podsieć Redis) (Podsieć redis), AzureLoadBalancer, (podsieć klienta)
13000-13999 Przychodzący TCP Komunikacja klienta z klastrami Redis, równoważeniem obciążenia platformy Azure (Podsieć Redis) (Podsieć redis), (Podsieć klienta), AzureLoadBalancer
15000-15999 Przychodzący TCP Komunikacja klienta z klastrami Redis, równoważeniem obciążenia platformy Azure i replikacją geograficzną (Podsieć Redis) (Podsieć redis), (Podsieć klienta), AzureLoadBalancer, (podsieć równorzędna repliki geograficznej)
16001 Przychodzący TCP/UDP Równoważenie obciążenia na platformie Azure (Podsieć Redis) AzureLoadBalancer
20226 Przychodzący TCP Komunikacja wewnętrzna dla usługi Redis (Podsieć Redis) (Podsieć Redis)

1 Możesz użyć tagu usługi AzureLoadBalancer dla Resource Manager lub AZURE_LOADBALANCER dla klasycznego modelu wdrażania na potrzeby tworzenia reguł sieciowej grupy zabezpieczeń.

Dodatkowe wymagania dotyczące łączności z siecią wirtualną

Istnieją wymagania dotyczące łączności sieciowej dla Azure Cache for Redis, które mogą nie zostać początkowo spełnione w sieci wirtualnej. Azure Cache for Redis wymaga prawidłowego działania wszystkich następujących elementów w przypadku użycia w sieci wirtualnej:

  • Wychodząca łączność sieciowa z punktami końcowymi usługi Azure Key Vault na całym świecie. Punkty końcowe usługi Azure Key Vault rozpoznawane w vault.azure.net domeny DNS.
  • Wychodząca łączność sieciowa z punktami końcowymi usługi Azure Storage na całym świecie. Uwzględniane są punkty końcowe znajdujące się w tym samym regionie co wystąpienie Azure Cache for Redis i punkty końcowe magazynu znajdujące się w innych regionach świadczenia usługi Azure. Punkty końcowe usługi Azure Storage są rozpoznawane w następujących domenach DNS: table.core.windows.net, blob.core.windows.net, queue.core.windows.net i file.core.windows.net.
  • Wychodząca łączność sieciowa z ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.com i crl.microsoft.com. Ta łączność jest wymagana do obsługi funkcji PROTOKOŁU TLS/SSL.
  • Konfiguracja DNS dla sieci wirtualnej musi być w stanie rozpoznać wszystkie punkty końcowe i domeny wymienione we wcześniejszych punktach. Te wymagania DNS można spełnić, upewniając się, że prawidłowa infrastruktura DNS jest skonfigurowana i utrzymywana dla sieci wirtualnej.
  • Łączność sieci wychodząca z następującymi punktami końcowymi usługi Azure Monitor, które są rozpoznawane w następujących domenach DNS: 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, shoebox3.prod.microsoftmetrics.com, shoebox3-red.prod.microsoftmetrics.com, shoebox3-black.prod.microsoftmetrics.com, azredis-red.prod.microsoftmetrics.com i azredis-black.prod.microsoftmetrics.com.

Jak sprawdzić, czy moja pamięć podręczna działa w sieci wirtualnej?

Ważne

Po nawiązaniu połączenia z wystąpieniem Azure Cache for Redis hostowanym w sieci wirtualnej klienci pamięci podręcznej muszą znajdować się w tej samej sieci wirtualnej lub w sieci wirtualnej z włączoną komunikacją równorzędną sieci wirtualnych w tym samym regionie świadczenia usługi Azure. Globalna komunikacja równorzędna sieci wirtualnych nie jest obecnie obsługiwana. To wymaganie dotyczy wszystkich aplikacji testowych i narzędzi diagnostycznych do wysyłania poleceń ping. Niezależnie od tego, gdzie jest hostowana aplikacja kliencka, sieciowe grupy zabezpieczeń lub inne warstwy sieciowe muszą być skonfigurowane tak, aby ruch sieciowy klienta mógł docierać do wystąpienia usługi Azure Cache for Redis.

Po skonfigurowaniu wymagań dotyczących portów zgodnie z opisem w poprzedniej sekcji możesz sprawdzić, czy pamięć podręczna działa, wykonując następujące kroki:

  • Uruchom ponownie wszystkie węzły pamięci podręcznej. Pamięć podręczna nie będzie mogła zostać pomyślnie uruchomiona ponownie, jeśli nie można uzyskać dostępu do wszystkich wymaganych zależności pamięci podręcznej---as udokumentowane w wymaganiach dotyczących portów przychodzących i wymaganiach dotyczących portów wychodzących.
  • Po ponownym uruchomieniu węzłów pamięci podręcznej zgodnie ze stanem pamięci podręcznej w Azure Portal można wykonać następujące testy:
    • Wyślij polecenie ping do punktu końcowego pamięci podręcznej przy użyciu portu 6380 z maszyny znajdującej się w tej samej sieci wirtualnej co pamięć podręczna przy użyciu polecenia tcping. Przykład:

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

      tcping Jeśli narzędzie zgłasza, że port jest otwarty, pamięć podręczna jest dostępna dla połączenia z klientów w sieci wirtualnej.

    • Innym sposobem testowania: utwórz testowego klienta pamięci podręcznej, który łączy się z pamięcią podręczną, a następnie dodaje i pobiera niektóre elementy z pamięci podręcznej. Testowy klient pamięci podręcznej może być aplikacją konsolową przy użyciu usługi StackExchange.Redis. Zainstaluj przykładową aplikację kliencką na maszynie wirtualnej, która znajduje się w tej samej sieci wirtualnej co pamięć podręczna. Następnie uruchom go, aby zweryfikować łączność z pamięcią podręczną.

Kiedy próbuję nawiązać połączenie z wystąpieniem Azure Cache for Redis w sieci wirtualnej, dlaczego występuje błąd informujący, że certyfikat zdalny jest nieprawidłowy?

Podczas próby nawiązania połączenia z wystąpieniem Azure Cache for Redis w sieci wirtualnej zostanie wyświetlony błąd weryfikacji certyfikatu, taki jak ten:

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

Przyczyną może być to, że łączysz się z hostem za pomocą adresu IP. Zalecamy użycie nazwy hosta. Innymi słowy, użyj następującego ciągu:

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

Unikaj używania adresu IP podobnego do następujących parametrów połączenia:

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

Jeśli nie możesz rozpoznać nazwy DNS, niektóre biblioteki klienckie zawierają opcje konfiguracji, takie jak sslHost, które są udostępniane przez klienta StackExchange.Redis. Ta opcja umożliwia zastąpienie nazwy hosta używanej do walidacji certyfikatu. Przykład:

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

Czy mogę używać sieci wirtualnych ze standardową lub podstawową pamięcią podręczną?

Sieci wirtualne mogą być używane tylko z pamięciami podręcznymi w warstwie Premium.

Dlaczego tworzenie wystąpienia Azure Cache for Redis kończy się niepowodzeniem w niektórych podsieciach, ale nie w innych?

Jeśli wdrażasz wystąpienie Azure Cache for Redis w sieci wirtualnej, pamięć podręczna musi znajdować się w dedykowanej podsieci, która nie zawiera innego typu zasobu. Jeśli podjęto próbę wdrożenia wystąpienia Azure Cache for Redis w podsieci sieci wirtualnej Resource Manager zawierającej inne zasoby---such jako wystąpienia Azure Application Gateway i wychodzący translator adresów sieciowych--- wdrożenie zwykle kończy się niepowodzeniem. Usuń istniejące zasoby innych typów przed utworzeniem nowego wystąpienia usługi Azure Cache for Redis.

Musisz również mieć wystarczającą liczbę adresów IP dostępnych w podsieci.

Jakie są wymagania dotyczące przestrzeni adresowej podsieci?

Platforma Azure rezerwuje kilka adresów IP w każdej podsieci i tych adresów nie można używać. Pierwsze i ostatnie adresy IP podsieci są rezerwowane na potrzeby zgodności protokołów, a trzy dodatkowe adresy są używane przez usługi platformy Azure. Aby uzyskać więcej informacji, zobacz Czy istnieją ograniczenia dotyczące używania adresów IP w tych podsieciach?

Oprócz adresów IP używanych przez infrastrukturę sieci wirtualnej platformy Azure każde wystąpienie Azure Cache for Redis w podsieci używa dwóch adresów IP na fragment klastra oraz adresów IP dla dodatkowych replik, jeśli istnieją. Dla modułu równoważenia obciążenia jest używany jeszcze jeden adres IP. Uważa się, że nieklasowana pamięć podręczna ma jeden fragment.

Czy mogę nawiązać połączenie z pamięcią podręczną z równorzędnej sieci wirtualnej?

Jeśli sieci wirtualne znajdują się w tym samym regionie, możesz połączyć je przy użyciu komunikacji równorzędnej sieci wirtualnej lub połączenia między sieciami wirtualnymi VPN Gateway.

Jeśli równorzędne sieci wirtualne platformy Azure znajdują się w różnych regionach: maszyna wirtualna klienta w regionie 1 nie może uzyskać dostępu do pamięci podręcznej w regionie 2 za pośrednictwem adresu IP ze zrównoważonym obciążeniem ze względu na ograniczenie z podstawowymi modułami równoważenia obciążenia. Oznacza to, że jest to pamięć podręczna ze standardowym modułem równoważenia obciążenia, który jest obecnie tylko pamięcią podręczną utworzoną ze strefami dostępności.

Aby uzyskać więcej informacji na temat ograniczeń komunikacji równorzędnej sieci wirtualnych, zobacz Virtual Network — Komunikacja równorzędna — wymagania i ograniczenia. Jednym z rozwiązań jest użycie połączenia między sieciami wirtualnymi VPN Gateway zamiast komunikacji równorzędnej sieci wirtualnej.

Czy wszystkie funkcje pamięci podręcznej działają, gdy pamięć podręczna jest hostowana w sieci wirtualnej?

Gdy pamięć podręczna jest częścią sieci wirtualnej, tylko klienci w sieci wirtualnej mogą uzyskiwać dostęp do pamięci podręcznej. W związku z tym następujące funkcje zarządzania pamięcią podręczną nie działają w tej chwili:

  • Konsola redis: ponieważ konsola Redis działa w przeglądarce lokalnej---usually na maszynie dewelopera, która nie jest połączona z siecią wirtualną---it nie może następnie nawiązać połączenia z pamięcią podręczną.

Korzystanie z usługi ExpressRoute z usługą Azure Cache for Redis

Klienci mogą połączyć obwód usługi Azure ExpressRoute z infrastrukturą sieci wirtualnej. W ten sposób rozszerzają swoją sieć lokalną na platformę Azure.

Domyślnie nowo utworzony obwód usługi ExpressRoute nie używa wymuszonego tunelowania (anonsowanie trasy domyślnej, 0.0.0.0/0) w sieci wirtualnej. W związku z tym łączność wychodząca z Internetu jest dozwolona bezpośrednio z sieci wirtualnej. Aplikacje klienckie mogą łączyć się z innymi punktami końcowymi platformy Azure, które obejmują wystąpienie Azure Cache for Redis.

Typową konfiguracją klienta jest użycie wymuszonego tunelowania (anonsowanie trasy domyślnej), która wymusza wychodzący ruch internetowy do zamiast przepływu lokalnego. Ten przepływ ruchu przerywa łączność z Azure Cache for Redis, jeśli ruch wychodzący jest blokowany lokalnie, tak aby wystąpienie Azure Cache for Redis nie mogło komunikować się z jego zależnościami.

Rozwiązaniem jest zdefiniowanie co najmniej jednej trasy zdefiniowanej przez użytkownika w podsieci zawierającej wystąpienie Azure Cache for Redis. Trasa zdefiniowana przez użytkownika definiuje trasy specyficzne dla podsieci, które będą honorowane zamiast trasy domyślnej.

Jeśli to możliwe, użyj następującej konfiguracji:

  • Konfiguracja usługi ExpressRoute anonsuje 0.0.0.0/0 i domyślnie wymusza tunele całego ruchu wychodzącego lokalnie.
  • Trasa zdefiniowana przez użytkownika zastosowana do podsieci zawierającej wystąpienie Azure Cache for Redis definiuje 0.0.0.0/0 z działającą trasą ruchu TCP/IP do publicznego Internetu. Na przykład ustawia typ następnego przeskoku do Internetu.

Połączony efekt tych kroków polega na tym, że trasa zdefiniowana na poziomie podsieci ma pierwszeństwo przed wymuszonym tunelowaniem usługi ExpressRoute i zapewnia wychodzący dostęp do Internetu z wystąpienia Azure Cache for Redis.

Nawiązywanie połączenia z wystąpieniem Azure Cache for Redis z aplikacji lokalnej przy użyciu usługi ExpressRoute nie jest typowym scenariuszem użycia ze względu na wydajność. Aby uzyskać najlepszą wydajność, klienci Azure Cache for Redis powinni znajdować się w tym samym regionie co wystąpienie Azure Cache for Redis.

Ważne

Trasy zdefiniowane w trasach zdefiniowanych w trasie zdefiniowanej przez użytkownika muszą być wystarczająco szczegółowe, aby mieć pierwszeństwo przed wszystkimi trasami anonsowanymi przez konfigurację usługi ExpressRoute. W poniższym przykładzie użyto szerokiego zakresu adresów 0.0.0.0/0. W związku z tym potencjalnie można przypadkowo zastąpić anonsami tras, które używają bardziej szczegółowych zakresów adresów.

Ostrzeżenie

Azure Cache for Redis nie jest obsługiwana w przypadku konfiguracji usługi ExpressRoute, które nieprawidłowo anonsują trasy krzyżowe ze ścieżki publicznej komunikacji równorzędnej do ścieżki prywatnej komunikacji równorzędnej. Konfiguracje usługi ExpressRoute, które mają skonfigurowaną publiczną komunikację równorzędną, odbierają anonse tras od firmy Microsoft dla dużego zestawu zakresów adresów IP platformy Microsoft Azure. Jeśli te zakresy adresów są niepoprawnie anonsowane krzyżowo na prywatnej ścieżce komunikacji równorzędnej, wynikiem jest to, że wszystkie pakiety sieciowe wychodzące z podsieci wystąpienia Azure Cache for Redis są niepoprawnie tunelowane do lokalnej infrastruktury sieciowej klienta. Ten przepływ sieciowy przerywa Azure Cache for Redis. Rozwiązaniem tego problemu jest zatrzymanie tras między reklamami ze ścieżki publicznej komunikacji równorzędnej do prywatnej ścieżki komunikacji równorzędnej.

Podstawowe informacje na temat tras zdefiniowanych przez użytkownika są dostępne w routingu ruchu w sieci wirtualnej.

Aby uzyskać więcej informacji na temat usługi ExpressRoute, zobacz Omówienie techniczne usługi ExpressRoute.

Następne kroki

Dowiedz się więcej o funkcjach Azure Cache for Redis.