Nätverkstopologi och anslutning för Oracle Database@Azure
Den här artikeln bygger på flera överväganden och rekommendationer som definieras i designområdet för Azure-landningszonen för nätverkstopologi och anslutning. Den innehåller viktiga designöverväganden och rekommendationer för Oracle Database@Azure nätverk och anslutning.
Utformningsbeaktanden
Tänk på följande när du utformar nätverkstopologin för Oracle Database@Azure:
Du kan fysiskt placera Oracle Database@Azure-tjänsten i Azure-datacenter eller i en Azure-tillgänglighetszon. Tillgänglighetszoner är prenumerationsspecifika, vilket påverkar nätverksfördröjning och återhämtning. En tillgänglighetszon har till exempel inte nödvändigtvis samma fysiska datacenter från en prenumeration till en annan prenumeration. Mer information finns i Vad är tillgänglighetszoner?.
Varje Oracle-Database@Azure SKU kan ha upp till åtta virtuella datorkluster (VM). Du måste ha ett virtuellt nätverk innan du skapar ett VM-kluster. Du kan ansluta virtuella datorkluster till antingen samma virtuella nätverk eller till olika virtuella nätverk.
Oracle Database@Azure-tjänsten distribueras till privata undernät i Azure och är inte omedelbart tillgänglig från Internet.
Det minsta storleksundernät som du behöver för Oracle Database@Azure-tjänsten beror på vilken SKU du använder. Mer information finns i Nätverkskonfiguration för Exadata Cloud Infrastructure-instanser.
Till skillnad från vanliga undernät har undernät som du delegerar till Oracle Database@Azure lösning begränsningar. Mer information finns i Nätverksplanering för Oracle Database@Azure.
Databasnoder har ingen standardnamnregistrering eller lösning eftersom Oracle Database@Azure endast körs i privata undernät.
Designrekommendationer
Tänk på följande rekommendationer när du utformar nätverkstopologin för Oracle Database@Azure:
Dirigera inte trafik mellan program- och databasundernäten med hjälp av virtuella Azure-nätverksinstallationer (NVA), brandväggar (till exempel Azure Firewall), Azure Virtual WAN-hubb eller partner-NVA:er. Den här konfigurationen lägger till nätverksfördröjning. I stället kan du använda direkt kommunikation mellan undernät i samma virtuella nätverk för effektivt trafikflöde. Om program- och databasundernäten finns i olika virtuella nätverk använder du direkt peering för virtuella nätverk i stället för transitiv routning via hubben.
Samlokalisera programportföljen och databastjänsterna i samma virtuella nätverk om du har ett begränsat antal databaser som betjänar en begränsad programportfölj som hanteras av ett enda team. Samlokalisering minskar svarstiden och förenklar nätverksdesignen.
Behandla Oracle-Database@Azure lösning som en dedikerad tjänst om du har flera databaser som hanterar olika program som hanteras av olika team. Distribuera Oracle Database@Azure-lösningen i en eller flera dedikerade prenumerationer. Distribuera programlösningarna i separata prenumerationer och använd peering för virtuella nätverk för att ansluta programnätverken till databasnätverken. Använd den här konfigurationen för att hantera program- och databasundernät oberoende av varandra.
Se till att du placerar program- och databaskomponenter i samma region och tillgänglighetszon för att minska svarstiden mellan ditt program och din databas. Om dina programkomponenter finns i olika prenumerationer från databaskomponenterna kan du läsa Fysiska och logiska tillgänglighetszoner. Använd egenskapen
AvailabilityZoneMappings
för att identifiera den specifika fysiska tillgänglighetszonen för samlokalisering av tjänsterna.Oracle Database@Azure undernät stöder inte nätverkssäkerhetsgrupper (NSG:er). Följ dessa rekommendationer för säkerhet:
Använd NSG:er i programundernäten för att styra trafik till och från programundernäten.
Använd brandväggsprodukter på plattformen, till exempel SELinux och cellvägg, på Oracle Database@Azure VM-kluster för att styra trafiken till tjänsten.
Använd privata DNS-zoner i Azure för namnmatchning mellan program- och databasundernät. Mer information finns i Privat DNS.
Följande exempel på nätverkstopologi är för en komplex programportfölj som hanteras av en enda eller flera databaser.