Virtuális hálózat (VNet) támogatásának konfigurálása Prémium Szintű Azure Cache for Redis-példányhoz

  • Cikk

Az Azure Virtual Network üzembe helyezése fokozott biztonságot és elkülönítést biztosít, valamint az alhálózatokat, a hozzáférés-vezérlési szabályzatokat és más funkciókat a hozzáférés további korlátozásához. Ha egy Azure Cache for Redis-példány virtuális hálózattal van konfigurálva, az nem nyilvánosan címezhető. Ehelyett a példány csak a virtuális hálózaton belüli virtuális gépekről és alkalmazásokból érhető el. Ez a cikk bemutatja, hogyan konfigurálhatja a virtuális hálózat támogatását egy prémium szintű Azure Cache for Redis-példányhoz.

Megjegyzés:

A klasszikus üzemi modell 2024 augusztusában visszavonul. További információ: A Cloud Services (klasszikus) üzemi modellje 2024. augusztus 31-én visszavonul.

Fontos

Az Azure Cache for Redis az Azure Private Link használatát javasolja, amely leegyszerűsíti a hálózati architektúrát, és biztonságossá teszi az Azure-beli végpontok közötti kapcsolatot. Privát végponton keresztül csatlakozhat az Azure Cache-példányhoz egy virtuális hálózatról, amelyhez a virtuális hálózat egyik alhálózatának magánhálózati IP-címe van hozzárendelve. Az Azure Private Link minden szinten elérhető, és Azure Policy-támogatást, valamint az NSG-szabályok egyszerűsített kezelését foglalja magában. További információkért lásd a Private Link dokumentációját. A virtuális hálózatba ágyazott gyorsítótárak Private Linkbe való migrálásához lásd a virtuális hálózatba ágyazott gyorsítótárakból Private Link-gyorsítótárakba való migrálást ismertető cikket.

A virtuális hálózat injektálásának korlátozásai

  • A virtuális hálózati konfigurációk létrehozása és karbantartása gyakran hibalehetőség. A hibaelhárítás is kihívást jelent. A helytelen virtuális hálózati konfigurációk problémákat okozhatnak:
    • a gyorsítótárpéldányokból érkező, akadályozott metrikák átvitele
    • a replikacsomópont nem replikálja az adatokat az elsődleges csomópontról
    • lehetséges adatvesztés
    • olyan felügyeleti műveletek meghiúsulása, mint a skálázás
    • a legsúlyosabb forgatókönyvekben a rendelkezésre állás elvesztése
  • A virtuális hálózatokba injektált gyorsítótárak csak a Prémium szintű Azure Cache for Redishez érhetők el, más szinteken nem.
  • A virtuális hálózatba injektált gyorsítótár használatakor módosítania kell a virtuális hálózatot olyan függőségek gyorsítótárazására, mint a CRLs/PKI, az AKV, az Azure Storage, az Azure Monitor stb.
  • Meglévő Azure Cache for Redis-példány nem ágyazható be virtuális hálózatba. A gyorsítótár létrehozásakor ezt a lehetőséget kell választania.

Virtuális hálózat támogatásának beállítása

A virtuális hálózat támogatása az Új Azure Cache for Redis panelen van konfigurálva a gyorsítótár létrehozása során.

  1. Prémium szintű gyorsítótár létrehozásához jelentkezzen be az Azure Portalra, és válassza az Erőforrás létrehozása lehetőséget. Létrehozhatja őket Resource Manager-sablonokkal, PowerShell-lel vagy az Azure CLI-vel is. További információ az Azure Cache for Redis-példány létrehozásáról: Gyorsítótár létrehozása.

    Screenshot that shows Create a resource.

  2. Az Új lapon válassza az Adatbázisok lehetőséget. Ezután válassza az Azure Cache for Redis lehetőséget.

    Screenshot that shows selecting Azure Cache for Redis.

  3. Az Új Redis Cache lapon konfigurálja az új prémium szintű gyorsítótár beállításait.

    Setting Ajánlott érték Leírás
    DNS-név Adjon meg egy globálisan egyedi nevet. A gyorsítótár nevének 1 és 63 karakter közötti sztringnek kell lennie, amely csak számokat, betűket vagy kötőjeleket tartalmaz. A névnek számmal vagy betűvel kell kezdődnie és végződnie, és nem tartalmazhat egymást követő kötőjeleket. A gyorsítótárpéldány gazdagépneve a következő lesz \<DNS name>.redis.cache.windows.net: .
    Előfizetés Válassza ki előfizetését a legördülő listából. Az előfizetés, amely alatt létre kell hozni ezt az új Azure Cache for Redis-példányt.
    Erőforráscsoport Válasszon ki egy erőforráscsoportot a legördülő listából, vagy válassza az Új létrehozása lehetőséget, és adjon meg egy új erőforráscsoportnevet. Annak az erőforráscsoportnak a neve, amelyben létre kívánja hozni a gyorsítótárat és más erőforrásokat. Ha az összes alkalmazás-erőforrást egy erőforráscsoportba helyezi, egyszerűen kezelheti vagy törölheti őket.
    Helyen Válasszon egy helyet a legördülő listából. Válasszon ki egy régiót más szolgáltatások közelében, amelyek a gyorsítótárat fogják használni.
    Gyorsítótár típusa Válassza ki a prémium szintű gyorsítótárat a legördülő listából a prémium szintű szolgáltatások konfigurálásához. További információkért lásd az Azure Cache for Redis díjszabását. A tarifacsomag határozza meg a gyorsítótár méretét, teljesítményét és elérhető funkcióit. További információ: Azure Cache for Redis – áttekintés.

  4. Válassza a Hálózatkezelés lapot, vagy válassza a Lap alján található Hálózatkezelés gombot.

  5. A Hálózatkezelés lapon válassza a Virtuális hálózatok lehetőséget kapcsolati módszerként. Új virtuális hálózat használatához először hozza létre a virtuális hálózat létrehozása az Azure Portalon vagy virtuális hálózat létrehozása (klasszikus) az Azure Portal használatával című témakörben leírt lépéseket követve. Ezután térjen vissza az Új Azure Cache for Redis panelre a prémium szintű gyorsítótár létrehozásához és konfigurálásához.

    Fontos

    Amikor az Azure Cache for Redist egy Resource Manager virtuális hálózaton helyezi üzembe, a gyorsítótárnak egy dedikált alhálózatban kell lennie, amely nem tartalmaz más erőforrásokat, kivéve az Azure Cache for Redis-példányokat. Ha az Azure Cache for Redis-példányt olyan Resource Manager-alapú virtuális hálózat alhálózatán próbálja üzembe helyezni, amely más erőforrásokat is tartalmaz, vagy NAT-átjáró van hozzárendelve, az üzembe helyezés meghiúsul. A hiba oka az, hogy az Azure Cache for Redis alapszintű terheléselosztót használ, amely nem kompatibilis a NAT-átjáróval.

    Setting Ajánlott érték Leírás
    Virtuális hálózat Válassza ki a virtuális hálózatot a legördülő listából. Válasszon ki egy olyan virtuális hálózatot, amely ugyanabban az előfizetésben és helyen található, mint a gyorsítótár.
    Alhálózat Válassza ki az alhálózatot a legördülő listából. Az alhálózat címtartományának CIDR-jelölésben kell lennie (például 192.168.1.0/24). A virtuális hálózat címterének kell tartalmaznia.
    Statikus IP-cím (Nem kötelező) Adjon meg egy statikus IP-címet. Ha nem ad meg statikus IP-címet, a rendszer automatikusan kiválaszt egy IP-címet.

    Fontos

    Az Azure minden alhálózaton lefoglal néhány IP-címet, amelyek nem használhatók. Az alhálózat első és utolsó IP-címét a protokollok megfelelősége érdekében, további három címet pedig az Azure-szolgáltatások számára foglal le. További információ: Vannak az IP-címek használatára vonatkozó korlátozások ezekben az alhálózatokban?

    Az Azure virtuális hálózat infrastruktúra által használt IP-címeken kívül az alhálózat minden egyes Azure Cache for Redis-példánya két IP-címet használ szegmensenként, valamint további egy IP-címet a terheléselosztóhoz. A fürtözetlen gyorsítótárak egyetlen szegmensnek minősülnek.

  6. Válassza a Tovább: Speciális lapot, vagy válassza a Tovább: Speciális gombot a lap alján.

  7. A Prémium szintű gyorsítótárpéldány Speciális lapján konfigurálja a nem TLS-port, a fürtözés és az adatmegőrzés beállításait.

  8. Válassza a Tovább: Címkék lapot, vagy válassza a Következő: Címkék gombot a lap alján.

  9. Ha kategorizálni szeretné az erőforrást, a Címkék lapon adja meg a nevet és az értéket.

  10. Select Review + create. Ekkor megjelenik a Véleményezés + létrehozás lap, ahol az Azure ellenőrzi a konfigurációt.

  11. A zöld érvényesítési üzenet megjelenése után válassza a Létrehozás lehetőséget.

A gyorsítótár létrehozása eltarthat egy ideig. Az előrehaladást az Azure Cache for Redis áttekintési oldalán követheti nyomon. Ha az állapot futásként jelenik meg, a gyorsítótár készen áll a használatra. A gyorsítótár létrehozása után megtekintheti a virtuális hálózat konfigurációját az Erőforrás menü Virtuális hálózat elemének kiválasztásával.

Virtual network

Az Azure Cache for Redis virtuális hálózatával kapcsolatos gyakori kérdések

Az alábbi lista válaszokat tartalmaz az Azure Cache for Redis hálózatkezelésével kapcsolatos gyakori kérdésekre.

Milyen gyakori helytelen konfigurációs problémák merülnek fel az Azure Cache for Redis és a virtuális hálózatok esetében?

Ha az Azure Cache for Redis virtuális hálózaton fut, a rendszer az alábbi táblázatokban szereplő portokat használja.

Fontos

Ha a következő táblák portja le van tiltva, előfordulhat, hogy a gyorsítótár nem működik megfelelően. Ha egy vagy több port le van tiltva, az a leggyakoribb helytelen konfigurációs probléma, ha az Azure Cache for Redist virtuális hálózaton használja.

Kimenő portokkal kapcsolatos követelmények

Kilenc kimenő portra vonatkozó követelmény van. Ezekben a tartományokban a kimenő kérések a következők: a) kimenők a gyorsítótár működéséhez szükséges egyéb szolgáltatásokra, vagy b) a Redis-alhálózaton belül a csomópontok közötti kommunikációhoz. Georeplikáció esetén az elsődleges és a replikagyorsítótár alhálózatai közötti kommunikációra más kimenő követelmények is vonatkoznak.

Ports Direction Transport protocol Cél Helyi IP-cím Távoli IP
80, 443 Outbound TCP Redis-függőségek az Azure Storage-on/PKI-n (internet) (Redis alhálózat) * 4
443 Outbound TCP Redis-függőség az Azure Key Vaulton és az Azure Monitoron (Redis alhálózat) AzureKeyVault, AzureMonitor 1
53 Outbound TCP/UDP Redis-függőségek a DNS-en (internet/virtuális hálózat) (Redis alhálózat) 168.63.129.16 és 169.254.169.254 2 és bármely egyéni DNS-kiszolgáló a 3. alhálózathoz
8443 Outbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)
10221-10231 Outbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)
20226 Outbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)
13000-13999 Outbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)
15000-15999 Outbound TCP Belső kommunikáció a Redishez és a georeplikációhoz (Redis alhálózat) (Redis alhálózat) (Georeplika társalhálózat)
6379-6380 Outbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)

1 Az AzureKeyVault és az AzureMonitor szolgáltatáscímkéket Resource Manager hálózati biztonsági csoportokkal (NSG-kkel) használhatja.

2 Ezek a Microsoft tulajdonában lévő IP-címek az Azure DNS-t kiszolgáló gazda virtuális gép kezelésére szolgálnak.

3 Ez az információ nem szükséges az egyéni DNS-kiszolgáló nélküli alhálózatokhoz vagy az egyéni DNS-t figyelmen kívül hagyó újabb Redis-gyorsítótárakhoz.

4 További információ: További virtuális hálózati csatlakozási követelmények.

Georeplikációs társportok követelményei

Ha georeplikálást használ az Azure-beli virtuális hálózatok gyorsítótárai között: a) feloldja az 15000-15999-ös portokat a teljes alhálózat számára bejövő és kimenő irányban, b) mindkét gyorsítótárra. Ezzel a konfigurációval az alhálózat összes replikaösszetevője közvetlenül kommunikálhat egymással, még akkor is, ha a jövőben geo-feladatátvétel történik.

Bejövő portokkal kapcsolatos követelmények

Nyolc bejövő porttartományra vonatkozó követelmény van. Az ezekben a tartományokban lévő bejövő kérések vagy bejövők az ugyanazon a virtuális hálózaton üzemeltetett más szolgáltatásokból. Vagy a Redis-alhálózati kommunikáció belső elemei.

Ports Direction Transport protocol Cél Helyi IP-cím Távoli IP
6379, 6380 Inbound TCP Ügyfélkommunikáció a Redis és az Azure terheléselosztása között (Redis alhálózat) (Redis alhálózat), (ügyfél-alhálózat), AzureLoadBalancer 1
8443 Inbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)
8500 Inbound TCP/UDP Azure-beli terheléselosztás (Redis alhálózat) AzureLoadBalancer
10221-10231 Inbound TCP Ügyfélkommunikáció a Redis-fürtökkel, belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat), (ügyfél-alhálózat), AzureLoadBalancer
13000-13999 Inbound TCP Ügyfélkommunikáció Redis-fürtökkel, Azure-terheléselosztás (Redis alhálózat) (Redis alhálózat), (ügyfél-alhálózat), AzureLoadBalancer
15000-15999 Inbound TCP Ügyfélkommunikáció Redis-fürtökkel, Azure-terheléselosztás és georeplikáció (Redis alhálózat) (Redis-alhálózat), (ügyfél-alhálózat), AzureLoadBalancer, (Georeplika társalhálózat)
16001 Inbound TCP/UDP Azure-beli terheléselosztás (Redis alhálózat) AzureLoadBalancer
20226 Inbound TCP Belső kommunikáció a Redishez (Redis alhálózat) (Redis alhálózat)

1 Használhatja az AzureLoadBalancer szolgáltatáscímkét a Resource Managerhez, vagy AZURE_LOADBALANCER a klasszikus üzemi modellhez az NSG-szabályok létrehozásához.

További virtuális hálózati csatlakozási követelmények

Előfordulhat, hogy az Azure Cache for Redis hálózati kapcsolati követelményei kezdetben nem teljesülnek egy virtuális hálózaton. Az Azure Cache for Redis megköveteli, hogy a következő elemek megfelelően működjenek egy virtuális hálózaton belül:

  • Kimenő hálózati kapcsolat az Azure Key Vault végpontjaihoz világszerte. Az Azure Key Vault végpontjai a DNS-tartomány vault.azure.netalatt oldódnak fel.
  • Kimenő hálózati kapcsolat az Azure Storage-végpontokkal világszerte. A rendszer az Azure Cache for Redis-példánysal azonos régióban található végpontokat és a többi Azure-régióban található tárolási végpontokat tartalmazza. Az Azure Storage-végpontok a következő DNS-tartományokban oldódnak fel: table.core.windows.net, blob.core.windows.net, queue.core.windows.netés file.core.windows.net.
  • Kimenő hálózati kapcsolat a ocsp.digicert.com, , , ocsp.msocsp.commscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.comoneocsp.microsoft.comés crl.microsoft.com. crl4.digicert.com Ez a kapcsolat a TLS/SSL-funkciók támogatásához szükséges.
  • A virtuális hálózat DNS-konfigurációjának képesnek kell lennie a korábbi pontokban említett összes végpont és tartomány feloldására. Ezeket a DNS-követelményeket úgy lehet teljesíteni, hogy egy érvényes DNS-infrastruktúra van konfigurálva és karbantartva a virtuális hálózathoz.
  • Kimenő hálózati kapcsolat a következő Azure Monitor-végpontokhoz, amelyek a következő DNS-tartományokban oldódnak fel: shoebox2-black.shoebox2.metrics.nsatc.net, , north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.metrics.nsatc.netshoebox2-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, azredis-red.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.comés azredis-black.prod.microsoftmetrics.com.

Hogyan ellenőrizhetim, hogy a gyorsítótáram működik-e virtuális hálózaton?

Fontos

Amikor egy virtuális hálózaton üzemeltetett Azure Cache for Redis-példányhoz csatlakozik, a gyorsítótár-ügyfeleknek ugyanabban a virtuális hálózatban vagy egy olyan virtuális hálózaton kell lenniük, amelyen engedélyezve van a virtuális hálózatok közötti társviszony-létesítés ugyanazon az Azure-régión belül. A globális virtuális hálózatok közötti társviszony-létesítés jelenleg nem támogatott. Ez a követelmény minden tesztalkalmazásra és diagnosztikai pingelési eszközre vonatkozik. Függetlenül attól, hogy az ügyfélalkalmazás hol üzemel, az NSG-ket vagy más hálózati rétegeket úgy kell konfigurálni, hogy az ügyfél hálózati forgalma elérje az Azure Cache for Redis-példányt.

Miután a portkövetelmények az előző szakaszban leírtak szerint lettek konfigurálva, az alábbi lépések végrehajtásával ellenőrizheti, hogy a gyorsítótár működik-e:

  • Indítsa újra az összes gyorsítótár-csomópontot. A gyorsítótár nem fog tudni sikeresen újraindulni, ha az összes szükséges gyorsítótár-függőség nem érhető el--- a bejövő portkövetelményekben és a kimenő portra vonatkozó követelményekben dokumentáltak.
  • Miután a gyorsítótár-csomópontok újraindultak, az Azure Portal gyorsítótár-állapota szerint a következő teszteket végezheti el:

    • Pingelje a gyorsítótárvégpontot a 6380-as port használatával egy olyan gépről, amely ugyanazon a virtuális hálózaton belül található, mint a gyorsítótár.tcping Például:

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

      Ha az tcping eszköz azt jelenti, hogy a port nyitva van, a gyorsítótár elérhető a virtuális hálózaton lévő ügyfelek közötti kapcsolathoz.

    • A tesztelés másik módja: hozzon létre egy tesztgyorsítótár-ügyfelet, amely csatlakozik a gyorsítótárhoz, majd hozzáad és lekér néhány elemet a gyorsítótárból. A tesztgyorsítótár-ügyfél lehet egy konzolalkalmazás a StackExchange.Redis használatával. Telepítse a mintaügyfél-alkalmazást egy virtuális gépre, amely ugyanabban a virtuális hálózaton található, mint a gyorsítótár. Ezután futtassa a gyorsítótárhoz való kapcsolódás ellenőrzéséhez.

Amikor virtuális hálózaton próbálok csatlakozni az Azure Cache for Redis-példányomhoz, miért kapok hibaüzenetet, amely szerint a távoli tanúsítvány érvénytelen?

Amikor egy virtuális hálózaton próbál csatlakozni egy Azure Cache for Redis-példányhoz, a következőhöz hasonló tanúsítványérvényesítési hiba jelenik meg:

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

Ennek oka az lehet, hogy az IP-cím alapján csatlakozik a gazdagéphez. Javasoljuk, hogy használja a gazdagép nevét. Más szóval használja a következő sztringet:

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

Kerülje az ALÁBBI kapcsolati sztring hasonló IP-cím használatát:

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

Ha nem tudja feloldani a DNS-nevet, egyes ügyfélkódtárak olyan konfigurációs beállításokat tartalmaznak, mint a sslHostStackExchange.Redis-ügyfél által biztosított beállítások. Ezzel a beállítással felülbírálhatja a tanúsítványérvényesítéshez használt gazdagépnevet. Például:

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

Használhatok virtuális hálózatokat standard vagy alapszintű gyorsítótárral?

A virtuális hálózatok csak prémium szintű gyorsítótárakkal használhatók.

Miért nem sikerül létrehozni egy Azure Cache for Redis-példányt egyes alhálózatokban, másokban nem?

Ha egy Azure Cache for Redis-példányt helyez üzembe egy virtuális hálózaton, a gyorsítótárnak egy dedikált alhálózaton kell lennie, amely nem tartalmaz más erőforrástípust. Ha az Azure Cache for Redis-példányt más erőforrásokat tartalmazó Resource Manager virtuális hálózati alhálózaton próbálják üzembe helyezni--- mivel Azure-alkalmazás átjárópéldányok és kimenő NAT--- az üzembe helyezés általában meghiúsul. Mielőtt új Azure Cache for Redis-példányt hoz létre, törölje a meglévő, más típusú erőforrásokat.

Az alhálózatban elegendő IP-címmel is rendelkeznie kell.

Mik az alhálózat címterére vonatkozó követelmények?

Az Azure minden alhálózaton lefoglal néhány IP-címet, amelyek nem használhatók. Az alhálózat első és utolsó IP-címét a protokollok megfelelősége érdekében, további három címet pedig az Azure-szolgáltatások számára foglal le. További információ: Vannak az IP-címek használatára vonatkozó korlátozások ezekben az alhálózatokban?

Az Azure-beli virtuális hálózati infrastruktúra által használt IP-címeken kívül az alhálózat minden Azure Cache for Redis-példánya fürtönként két IP-címet, valamint további replikák IP-címeit használja, ha vannak ilyenek. A rendszer még egy IP-címet használ a terheléselosztóhoz. A nem fürtözött gyorsítótáraknak egy szegmense van.

Csatlakozhatok a gyorsítótáramhoz egy társhálózatról?

Ha a virtuális hálózatok ugyanabban a régióban találhatók, virtuális hálózatok közötti társviszony-létesítéssel vagy VPN Gateway VNET–VNET kapcsolattal csatlakoztathatja őket.

Ha a társviszonyban álló Azure-beli virtuális hálózatok különböző régiókban találhatók: az 1. régióban lévő ügyfél virtuális gép az alapszintű terheléselosztókra vonatkozó korlátozás miatt nem tudja elérni a 2. régió gyorsítótárát a 2. régióban a terheléselosztási IP-címén keresztül. Vagyis ha nem egy standard terheléselosztóval rendelkező gyorsítótárról van szó, amely jelenleg csak rendelkezésre állási zónákkal létrehozott gyorsítótár.

A virtuális hálózatok társviszony-létesítési korlátozásairól további információt a Virtuális hálózat – Társviszony-létesítés – Követelmények és korlátozások című témakörben talál. Az egyik megoldás a VPN Gateway virtuális hálózatok közötti virtuális hálózatok közötti kapcsolat használata a virtuális hálózatok közötti társviszony-létesítés helyett.

Működik az összes gyorsítótár-funkció, ha egy gyorsítótár virtuális hálózaton van üzemeltetve?

Ha a gyorsítótár egy virtuális hálózat része, csak a virtuális hálózaton lévő ügyfelek férhetnek hozzá a gyorsítótárhoz. Ennek eredményeképpen a következő gyorsítótár-kezelési funkciók jelenleg nem működnek:

  • Redis-konzol: Mivel a Redis-konzol a helyi böngészőben fut---a virtuális hálózathoz nem csatlakozó fejlesztői gépen--- ezután nem tud csatlakozni a gyorsítótárhoz.

Támogatott a virtuális hálózatok injektálása olyan gyorsítótárban, ahol engedélyezve van az Azure Lighthouse?

Nem, ha az előfizetésben engedélyezve van az Azure Lighthouse, akkor nem használhat virtuális hálózatinjektálást egy Azure Cache for Redis-példányon. Ehelyett használjon privát hivatkozásokat.

Az ExpressRoute használata az Azure Cache for Redis szolgáltatással

Az ügyfelek csatlakoztathatnak egy Azure ExpressRoute-kapcsolatcsoportot a virtuális hálózati infrastruktúrájukhoz. Ily módon kiterjesztik helyszíni hálózatukat az Azure-ra.

Az újonnan létrehozott ExpressRoute-kapcsolatcsoportok alapértelmezés szerint nem használnak kényszerített bújtatást (egy alapértelmezett útvonal hirdetése, 0.0.0.0/0) egy virtuális hálózaton. Ennek eredményeképpen a kimenő internetkapcsolat közvetlenül a virtuális hálózatról engedélyezett. Az ügyfélalkalmazások más Azure-végpontokhoz is csatlakozhatnak, például egy Azure Cache for Redis-példányhoz.

Gyakori ügyfélkonfiguráció a kényszerített bújtatás használata (alapértelmezett útvonal meghirdetése), amely a kimenő internetes forgalmat a helyszíni forgalomra kényszeríti. Ez a forgalom megszakítja a kapcsolatot az Azure Cache for Redis szolgáltatással, ha a kimenő forgalom a helyszínen le van tiltva, így az Azure Cache for Redis-példány nem tud kommunikálni a függőségeivel.

A megoldás az Azure Cache for Redis-példányt tartalmazó alhálózaton egy vagy több felhasználó által definiált útvonal (UDR) definiálása. Az UDR az alapértelmezett útvonal helyett az alhálózat-specifikus útvonalakat határozza meg.

Ha lehetséges, használja a következő konfigurációt:

  • Az ExpressRoute-konfiguráció meghirdeti a 0.0.0.0/0-t, és alapértelmezés szerint kényszeríti az alagutakat a helyszíni kimenő forgalomra.
  • Az Azure Cache for Redis-példányt tartalmazó alhálózatra alkalmazott UDR a 0.0.0.0/0-t határozza meg a nyilvános internet felé irányuló TCP/IP-forgalom munkaútvonalával. A következő ugrástípust például az internetre állítja.

Ezeknek a lépéseknek az együttes hatása az, hogy az alhálózati szintű UDR elsőbbséget élvez az ExpressRoute kényszerített bújtatásával szemben, és ez biztosítja a kimenő internet-hozzáférést az Azure Cache for Redis-példányból.

Az Azure Cache for Redis-példányra való Csatlakozás helyszíni alkalmazásból az ExpressRoute használatával történő használata teljesítménybeli okokból nem tipikus használati forgatókönyv. A legjobb teljesítmény érdekében az Azure Cache for Redis-ügyfeleknek ugyanabban a régióban kell lenniük, mint az Azure Cache for Redis-példány.

Fontos

Az UDR-ben meghatározott útvonalaknak elég specifikusnak kell lenniük ahhoz, hogy elsőbbséget élvezhessenek az ExpressRoute-konfiguráció által meghirdetett útvonalakkal szemben. Az alábbi példa a széles 0.0.0.0/0 címtartományt használja, és mint ilyen, véletlenül felül lehet bírálni azokat az útvonalhirdetéseket, amelyek pontosabb címtartományokat használnak.

Figyelmeztetés

Az Azure Cache for Redis nem támogatott olyan ExpressRoute-konfigurációkkal, amelyek helytelenül hirdetik a nyilvános társviszony-létesítési útvonalról a privát társviszony-létesítési útvonalra irányuló útvonalakat. A nyilvános társviszony-létesítéssel konfigurált ExpressRoute-konfigurációk útválasztási hirdetéseket kapnak a Microsofttól a Microsoft Azure IP-címtartományainak nagy halmazához. Ha ezek a címtartományok helytelenül vannak meghirdetve a privát társviszony-létesítési útvonalon, az eredmény az, hogy az Azure Cache for Redis-példány alhálózatából származó kimenő hálózati csomagok helytelenül lesznek átirányítva az ügyfél helyszíni hálózati infrastruktúrájára. Ez a hálózati folyamat megszakítja az Azure Cache for Redist. A probléma megoldására az a megoldás, hogy a nyilvános társviszony-létesítési útvonalról a privát társviszony-létesítési útvonalra mutató kereszthirdetési útvonalakat leállítja.

Az UDR-ekre vonatkozó háttérinformációk a virtuális hálózati forgalom útválasztásában érhetők el.

Az ExpressRoute-ról további információt az ExpressRoute műszaki áttekintésében talál.

Kapcsolódó tartalom

További információ az Azure Cache for Redis funkcióiról.