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

Wdrożenie usługi Azure Virtual Network zapewnia rozszerzone zabezpieczenia i izolację wraz z: podsieciami, zasadami kontroli dostępu i innymi funkcjami w celu dalszego ograniczenia dostępu. Gdy wystąpienie usługi 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 usługi Azure Cache for Redis w warstwie Premium.

Uwaga

Klasyczny model wdrażania zostanie wycofany w sierpniu 2024 r. Aby uzyskać więcej informacji, zobacz Model wdrażania usług Cloud Services (wersja klasyczna) zostanie wycofany 31 sierpnia 2024 r.

Ważne

Usługa Azure Cache for Redis zaleca korzystanie z usługi 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ę wprowadzonych pamięci podręcznych sieci wirtualnej do usługi Private Link, zobacz Migracja wprowadzonych pamięci podręcznych sieci wirtualnej do pamięci podręcznych usługi Private Link.

Ograniczenia iniekcji sieci wirtualnej

• Tworzenie i utrzymywanie konfiguracji sieci wirtualnej jest często podatne na błędy. Rozwiązywanie problemów również jest trudne. Nieprawidłowe konfiguracje sieci wirtualnej mogą prowadzić do problemów:
  • utrudnianie transmisji metryk z wystąpień pamięci podręcznej
  • błąd węzła repliki w celu replikowania danych z węzła podstawowego
  • potencjalna utrata danych
  • niepowodzenie operacji zarządzania, takich jak skalowanie
  • sporadyczne lub kompletne błędy protokołu SSL/TLS
  • w najpoważniejszych scenariuszach utrata dostępności
• Wprowadzone w sieci wirtualnej pamięci podręczne są dostępne tylko dla usługi Azure Cache for Redis w warstwie Premium, a nie dla innych warstw.
• W przypadku korzystania z wstrzyczonej pamięci podręcznej sieci wirtualnej należy zmienić sieć wirtualną na zależności pamięci podręcznej, takie jak listy odwołania certyfikatów/struktura klucza publicznego, usługa Azure Key Vault, usługa Azure Storage, usługa Azure Monitor i inne.
• Nie można wstrzyknąć istniejącego wystąpienia usługi Azure Cache for Redis do sieci wirtualnej. Należy wybrać tę opcję podczas tworzenia pamięci podręcznej.

Konfigurowanie obsługi sieci wirtualnej

Obsługa sieci wirtualnej jest skonfigurowana w okienku Nowa pamięć podręczna Azure Cache for Redis podczas tworzenia pamięci podręcznej.

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

   

2. Na stronie Nowy wybierz pozycję Bazy danych. Następnie wybierz pozycję 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 z zakresu 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 mieć wartość \<DNS name>.redis.cache.windows.net .
   Subskrypcja	Wybierz swoją subskrypcję z listy rozwijanej.	Subskrypcja, w ramach której ma zostać utworzone to nowe wystąpienie usługi 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ą warstwy Premium z listy rozwijanej, aby skonfigurować funkcje warstwy Premium. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Cache for Redis.	Warstwa cenowa decyduje o rozmiarze, wydajności i funkcjach dostępnych dla pamięci podręcznej. Aby uzyskać więcej informacji, zobacz Omówienie usługi 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 witryny Azure Portal lub Tworzenie sieci wirtualnej (klasycznej) przy użyciu witryny Azure Portal. Następnie wróć do okienka Nowa pamięć podręczna Azure Cache for Redis , aby utworzyć i skonfigurować pamięć podręczną w warstwie Premium.

   Ważne

   Podczas wdrażania usługi Azure Cache for Redis w sieci wirtualnej usługi Resource Manager pamięć podręczna musi znajdować się w dedykowanej podsieci, która nie zawiera żadnych innych zasobów z wyjątkiem wystąpień usługi 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. Awaria jest taka, że usługa 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 swoją podsieć z listy rozwijanej.	Zakres adresów podsieci powinien znajdować się w notacji CIDR (na przykład 192.168.1.0/24). Musi ona być zawarta 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 skategoryzować zasób.

10. Wybierz pozycję Przejrzyj i utwórz. Przejdź do karty Przeglądanie i tworzenie , na której platforma Azure weryfikuje konfigurację.

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

Utworzenie pamięci podręcznej zajmuje trochę czasu. Postęp można monitorować na stronie Przegląd usługi 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ę Sieć wirtualna z menu Zasób .

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 sieci usługi Azure Cache for Redis.

• Jakie są typowe problemy z błędną konfiguracją usługi Azure Cache for Redis i sieci wirtualnych?
• Jak sprawdzić, czy moja pamięć podręczna działa w sieci wirtualnej?
• Kiedy próbuję nawiązać połączenie z wystąpieniem usługi Azure Cache for Redis w sieci wirtualnej, dlaczego występuje błąd informujący, że certyfikat zdalny jest nieprawidłowy?
• Czy mogę używać sieci wirtualnych ze standardową lub podstawową pamięcią podręczną?
• Dlaczego tworzenie wystąpienia usługi Azure Cache for Redis kończy się niepowodzeniem w niektórych podsieciach, ale nie w innych?
• Jakie są wymagania dotyczące przestrzeni adresowej podsieci?
• Czy mogę nawiązać połączenie z pamięcią podręczną z równorzędnej sieci wirtualnej?
• Czy iniekcja sieci wirtualnej jest obsługiwana w pamięci podręcznej, w której włączono usługę Azure Lighthouse?
• Czy wszystkie funkcje pamięci podręcznej działają, gdy pamięć podręczna jest hostowana w sieci wirtualnej?
• Czy iniekcja sieci wirtualnej jest obsługiwana w pamięci podręcznej, w której włączono usługę Azure Lighthouse?

Jakie są typowe problemy z błędną konfiguracją usługi Azure Cache for Redis i sieci wirtualnych?

Gdy usługa 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ęstszym problemem z błędną konfiguracją podczas korzystania z usługi Azure Cache for Redis w sieci wirtualnej.

• Wymagania dotyczące portów wychodzących
• Wymagania dotyczące portów przychodzących

Wymagania dotyczące portów wychodzących

Istnieją 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 obsługi pamięci podręcznej lub b) wewnętrznej podsieci redis na potrzeby komunikacji między węzłami. W przypadku replikacji geograficznej istnieją inne wymagania ruchu wychodzącego dotyczące komunikacji między podsieciami podstawowej i repliki pamięci podręcznej.

Porty	Kierunek	Protokół transportowy	Purpose	Lokalny adres IP	Zdalny adres IP
80, 443	Wychodzący	TCP	Zależności usługi Redis w usłudze Azure Storage/PKI (Internet)	(Podsieć redis)	* 4
443	Wychodzący	TCP	Zależność usługi Redis od usługi Azure Key Vault i usługi Azure Monitor	(Podsieć redis)	AzureKeyVault, AzureMonitor 1
12000	Wychodzący	TCP	Zależność usługi Redis od usługi Azure Monitor	(Podsieć redis)	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
123	Wychodzący	UDP	Zależność systemu operacyjnego od NTP	(Podsieć redis)	*
1688	Wychodzący	TCP	Zależność systemu operacyjnego na potrzeby aktywacji	(Podsieć redis)	*
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)

¹ Możesz użyć tagów usługi AzureKeyVault i AzureMonitor z sieciowymi grupami zabezpieczeń usługi Resource Manager.

² Te adresy IP należące do firmy Microsoft są używane do adresowania maszyny wirtualnej hosta obsługującej usługę Azure DNS.

³ 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.

⁴ 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 istnieje przyszłe przejście w tryb failover geograficznego.

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. Lub są one wewnętrzne do komunikacji z podsiecią Redis.

Porty	Kierunek	Protokół transportowy	Purpose	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 usługi Redis	(Podsieć redis)	(Podsieć redis), (podsieć klienta), AzureLoadBalancer
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ć usługi 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 usługi Redis	(Podsieć redis)	(Podsieć redis)

¹ Możesz użyć tagu usługi AzureLoadBalancer dla usługi 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 usługi Azure Cache for Redis, które mogą nie zostać początkowo spełnione w sieci wirtualnej. Usługa 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 są rozpoznawane w domenie *.vault.azure.netDNS.
• Wychodząca łączność sieciowa z punktami końcowymi usługi Azure Storage na całym świecie. Uwzględnione są punkty końcowe znajdujące się w tym samym regionie co wystąpienie usługi 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.neti *.file.core.windows.net.
• Wychodząca łączność sieciowa z ocsp.digicert.com, ocsp.msocsp.comoneocsp.microsoft.comcacerts.digicert.comcrl3.digicert.commscrl.microsoft.comcrl4.digicert.comi crl.microsoft.comcacerts.geotrust.com, www.microsoft.com, , . status.geotrust.comcdp.geotrust.com Ta łączność jest wymagana do obsługi funkcji TLS/SSL.
• Wychodząca łączność sieciowa z następującymi punktami końcowymi usługi Azure Monitor, które są rozpoznawane w następujących domenach DNS: shoebox3.prod.microsoftmetrics.com, , , azredis-red.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.comshoebox3-red.prod.microsoftmetrics.comazredis-black.prod.microsoftmetrics.comglobal.prod.microsoftmetrics.comazredis.prod.microsoftmetrics.comgcs.prod.monitoring.core.windows.neti .*.prod.warm.ingest.monitor.core.windows.net
• Wychodząca łączność sieciowa z następującymi punktami końcowymi na potrzeby diagnostyki wewnętrznej, która jest rozpoznawana w następujących domenach DNS: azurewatsonanalysis-prod.core.windows.net, , *.data.microsoft.comshavamanifestazurecdnprod1.azureedge.neti shavamanifestcdnprod1.azureedge.net.
• Wychodząca łączność sieciowa z następującymi punktami końcowymi dla usługi aktualizacji systemu operacyjnego, która jest rozpoznawana w następujących domenach DNS: *.update.microsoft.com, *.ctldl.windowsupdate.comi ctldl.windowsupdate.com, *.delivery.mp.microsoft.comi download.windowsupdate.com.
• Wychodząca łączność sieciowa z następującymi punktami końcowymi programu antywirusowego, które są rozpoznawane w następujących domenach DNS: go.microsoft.com, , wdcp.microsoft.comwdcpalt.microsoft.comi definitionupdates.microsoft.com.
• 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.

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

Ważne

Po nawiązaniu połączenia z wystąpieniem usługi 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 ponowne uruchomienie jest konieczne w większości przypadków w celu zapewnienia poprawnego odzwierciedlenia zmian. W przeciwnym razie mogą wystąpić problemy z łącznością. 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. Nie będzie można pomyślnie uruchomić ponownie pamięci podręcznej, 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 wejściowych 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 witrynie 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. Na 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 od klientów w sieci wirtualnej.

  • Inny sposób 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. Klient testowej 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 usługi 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 usługi 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ącego parametry 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 weryfikacji certyfikatu. Na przykład:

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

Ponadto jeśli podsieć, w której jest hostowana usługa Azure Cache for Redis, blokuje połączenia wychodzące TCP przez port 80 dla funkcji PROTOKOŁU SSL/TLS, klienci mogą napotkać sporadyczne błędy weryfikacji certyfikatu TLS.

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 usługi Azure Cache for Redis kończy się niepowodzeniem w niektórych podsieciach, ale nie w innych?

Jeśli wdrażasz wystąpienie usługi 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 zostanie podjęta próba wdrożenia wystąpienia usługi Azure Cache for Redis w podsieci sieci wirtualnej usługi Resource Manager, która zawiera inne zasoby---such jako wystąpienia bramy aplikacja systemu Azure i wychodzący translator adresów sieciowych--- wdrażanie 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 usługi 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 nieklasterowana 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 usługi 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 — Peering — Requirements and constraints (Sieć wirtualna — komunikacja równorzędna — wymagania i ograniczenia). Jednym z rozwiązań jest użycie połączenia między sieciami wirtualnymi usługi VPN Gateway zamiast komunikacji równorzędnej sieci wirtualnych.

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ą.

Czy iniekcja sieci wirtualnej jest obsługiwana w pamięci podręcznej, w której włączono usługę Azure Lighthouse?

Nie, jeśli twoja subskrypcja ma włączoną usługę Azure Lighthouse, nie można używać iniekcji sieci wirtualnej w wystąpieniu usługi Azure Cache for Redis. Zamiast tego użyj linków prywatnych.

Używanie 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ą sieć lokalną na platformę Azure.

Domyślnie nowo utworzony obwód usługi ExpressRoute nie używa wymuszonego tunelowania (anons 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 usługi 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 usługą Azure Cache for Redis, jeśli ruch wychodzący jest blokowany lokalnie, tak aby wystąpienie usługi 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 usługi 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 usługi Azure Cache for Redis definiuje 0.0.0.0/0 z trasą roboczą dla ruchu TCP/IP do publicznego Internetu. Na przykład ustawia typ następnego przeskoku na Internet.

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

Nawiązywanie połączenia z wystąpieniem usługi 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 usługi Azure Cache for Redis powinni znajdować się w tym samym regionie co wystąpienie usługi Azure Cache for Redis.

Ważne

Trasy zdefiniowane 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, a 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

Usługa Azure Cache for Redis nie jest obsługiwana w przypadku konfiguracji usługi ExpressRoute, które niepoprawnie anonsują trasy krzyżowe ze ścieżki komunikacji równorzędnej firmy Microsoft do prywatnej ścieżki komunikacji równorzędnej. Konfiguracje usługi ExpressRoute, które mają skonfigurowaną komunikację równorzędną firmy Microsoft, 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 usługi Azure Cache for Redis są niepoprawnie wymuszane tunelowanie do lokalnej infrastruktury sieciowej klienta. Ten przepływ sieciowy przerywa działanie usługi Azure Cache for Redis. Rozwiązaniem tego problemu jest zatrzymanie tras między reklamami ze ścieżki komunikacji równorzędnej firmy Microsoft 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 ExpressRoute technical overview (Omówienie techniczne usługi ExpressRoute).

Powiązana zawartość

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

• Warstwy usługi Azure Cache for Redis Premium