Informazioni sulla progettazione della rete

I componenti dell'infrastruttura di rete OCI, come VCN, subnet e gateway, creati senza una pianificazione appropriata utilizzando i parametri predefiniti, possono causare problemi dopo la distribuzione che possono essere difficili da risolvere. Una progettazione di rete ben pianificata aiuta a impostare un'implementazione di successo e semplifica l'utilizzo da parte del team e dell'organizzazione.

Esegui la progettazione della rete in anticipo

Progettare completamente la rete prima della distribuzione consente di individuare i problemi in anticipo e rimuovere gli ostacoli alla corretta distribuzione. Sebbene sia possibile modificare alcuni elementi di progettazione della rete OCI in un secondo momento, può richiedere uno sforzo significativo e può interrompere temporaneamente il flusso aziendale.

Oracle consiglia quanto segue per la progettazione della rete OCI:

1. Pianifica il tempo appropriato e alloca risorse sufficienti nel piano di progetto per progettare correttamente la tua rete OCI.
2. Includi in modo minimo il layout, la topologia, il dimensionamento di VCN e subnet, il servizio DNS (Domain Name Service) e qualsiasi connettività di rete esterna a CSP on premise o di altro tipo.
3. Prendi in considerazione la possibilità di collaborare con il tuo team di account Oracle per verificare se Oracle è in grado di fornire assistenza agli specialisti di rete OCI.

Di seguito è riportato un esempio di diagramma di progettazione di una rete.

Descrizione dell'illustrazione vcn-network-design-example.png

Suggerimento

Cercare architetture di riferimento pertinenti per la distribuzione specifica da utilizzare come punto di partenza. Ad esempio, Oracle dispone di molte architetture di riferimento per le distribuzioni Oracle OCI comuni come Oracle E-Business Suite, Siebel e ExaCS su Oracle Architecture Center.

Prendi in considerazione una progettazione VCN hub e spoke

Le best practice e i suggerimenti Oracle per la maggior parte delle distribuzioni OCI consiste nell'utilizzare una progettazione VCN multipla in una topologia hub e spoke utilizzando il DRG per la connettività.

Di seguito sono riportati i vantaggi di una progettazione con più hub e spoke VCN mediante il gateway DRG:

• Isolare e segmentare ambienti diversi.
• Fornisci servizi comuni all'interno della VCN hub che tutte le VCN spoke possono condividere, come server di log, DNS e condivisione di file.
• Ridimensiona facilmente il tuo networking poiché il gateway DRG ti consente di connetterti fino a 300 VCN. Una volta progettata una VCN hub e spoke, è facile aggiungere altre VCN.
• Posizionare le appliance di sicurezza di rete, ad esempio i firewall, nella VCN hub per ispezionare il traffico destinato o proveniente dalle VCN spoke.

Il diagramma riportato di seguito mostra un esempio di utilizzo di un'architettura di rete hub e spoke.

Descrizione dell'immagine hub-and-spoke-topology.png

Oracle consiglia quanto riportato di seguito.

• Decidi come e dove potresti voler segmentare diversi ambienti di rete e prendere in considerazione l'idea di inserire ciascuno nella propria VCN. Di seguito sono riportati alcuni esempi di clienti comuni per l'utilizzo di VCN separate per gli ambienti.
  • Ambienti di produzione e non di produzione
  • Clienti interni o esterni
• Se hai una distribuzione OCI molto semplice o di piccole dimensioni, ad esempio una prova pratica (POC) e non hai bisogno di nessuno dei vantaggi discussi qui, l'utilizzo di una singola VCN è un buon approccio. Anche con una singola VCN, puoi sempre inserire un ambiente in una VCN diversa in futuro per sfruttare questi suggerimenti.

Usa convenzioni di denominazione OCI standard

Quando si esegue il provisioning delle risorse di rete necessarie in OCI, ad esempio VCN, subnet, liste di sicurezza e gateway di instradamento dinamico (DRG), verrà richiesto di immettere un nome di risorsa. L'uso di una convenzione di denominazione standard per le risorse OCI consente a te e ad altri utenti OCI di comprendere lo scopo e la posizione delle risorse e indica anche come una risorsa si differenzia dagli altri.

Alcuni di questi nomi di risorse possono essere modificati in seguito, ma alcuni non possono, come l'etichetta DNS. Altri elementi come il nome della VCN devono essere modificati utilizzando l'interfaccia della riga di comando (CLI, Command-Line Interface).

Oracle consiglia quanto riportato di seguito.

1. Utilizzare un acronimo descrittivo da qualche parte nel nome per descrivere lo scopo di una risorsa. Ad esempio:
   • vcn da qualche parte nel nome della VCN (nome VCN: vcn-prod-ashburn)
   • drg in un punto qualsiasi del nome DRG (nome DRG: drg-ashburn)
   • sl da qualche parte nel nome della lista di sicurezza (Nome lista di sicurezza: web-sn-sl)
2. Assicurarsi che la convenzione di denominazione delle risorse di rete OCI faccia parte della convenzione di denominazione complessiva delle risorse OCI.
3. Valutare la possibilità di utilizzare le tag per aggiungere informazioni sui metadati alle risorse.

Progetta un DNS ibrido con il DNS privato OCI

Il comportamento predefinito di OCI è limitato all'esecuzione della risoluzione DNS interna alla VCN utilizzando oraclevcn.com come dominio predefinito. Ciò può causare problemi di connettività in un secondo momento perché non è possibile risolvere i nomi DNS per le risorse in altri VCN o ambienti on premise.

Il servizio DNS privato OCI offre la possibilità di risolvere senza problemi il DNS tra OCI e l'infrastruttura on-premise:

• Crea e gestisce domini e record DNS personalizzati all'interno delle reti VCN (ad esempio, oci.customer.com).
• Integra la risoluzione DNS tra VCN, con DNS on-premise e altri ambienti come CSP o DNS partner affidabili.

Oracle consiglia quanto riportato di seguito.

• Includi DNS come parte della progettazione iniziale della rete e coinvolgi gli amministratori DNS.
• Prendi in considerazione tutti gli ambienti in cui desideri una risoluzione dei nomi DNS trasparente (da o verso ambienti on-premise, VCN OCI, altri CSP e così via) e utilizza il DNS privato OCI per abilitare una soluzione DNS ibrida.
• Considera le avvertenze in anticipo e determina la direzione da seguire. Decidere se utilizzare il nome di dominio oraclevcn.com predefinito o un nome di dominio personalizzato.

Il diagramma seguente mostra un'architettura di esempio con nomi di dominio personalizzati che utilizzano un resolver DNS privato per la risoluzione delle risorse locali interne con nomi di dominio personalizzati:

Descrizione dell'illustrazione architecture-deploy-private-dns.png

Suggerimento

Quando si utilizza un nome di dominio OCI personalizzato, la gestione delle zone e dei record personalizzati è manuale. Il valore predefinito oraclevcn.com è automatico.

Decidere i tipi di subnet prima del provisioning

I CIDR VCN devono essere suddivisi in una o più subnet per organizzare le risorse. Le subnet possono essere subnet regionali o specifiche di AD (Availability Domain) e possono anche essere subnet pubbliche o private.

Le decisioni relative alle subnet specifiche regionali e AD e alle subnet pubbliche e private non possono essere modificate in un secondo momento. Assicurati che siano corretti quando li esegui il provisioning inizialmente per ridurre al minimo le interruzioni e la complessità in una fase successiva.

Oracle consiglia quanto riportato di seguito.

• Prima di crearle, determinare se sono necessarie subnet pubbliche o private. Considera i potenziali flussi di traffico e dove il traffico è proveniente o destinato.
• Posiziona le risorse che hanno un requisito specifico per la connettività Internet in entrata nelle subnet pubbliche e in tutte le altre risorse nelle subnet private.
• Eseguire il provisioning delle subnet regionali a meno che non si disponga di un requisito specifico che richiede l'uso di subnet specifiche di AD.

Suggerimento

Per apportare modifiche in un secondo momento, è necessario terminare le subnet e quindi rieseguirne il provisioning. È inoltre necessario arrestare le risorse distribuite nelle subnet, quindi eseguire di nuovo il provisioning delle risorse nelle nuove subnet.

Progetta e ridimensiona le tue subnet

Progetta e ridimensiona le tue subnet per soddisfare i requisiti attuali e futuri. Il dimensionamento di VCN e subnet in modo appropriato durante la progettazione consentirà di:

• Preparati alla crescita e all'espansione future
• Semplifica l'allocazione IP utilizzando uno spazio di indirizzamento IP contiguo e riepilogabile

Oracle consiglia quanto riportato di seguito.

• Prima di creare una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse e subnet che intendi distribuire nella VCN.
• Assicurati di consentire una certa quantità di crescita futura all'interno delle subnet e dei VCN.
• È preferibile affidarsi alla creazione di un CIDR più grande rispetto a un CIDR troppo piccolo.
• Puoi aggiungere fino a cinque CIDR a una VCN, tuttavia aggiungerne altri in un secondo momento per accogliere la crescita potrebbe comportare CIDR non contigui a seconda dell'allocazione dell'indirizzo IP.
  • Ad esempio, hai allocato 10.0.0.0/24 a una VCN per avviare il test di un carico di lavoro. Dopo un test riuscito, se desideri espandere il carico di lavoro in più VM, sono necessari più IP e subnet. Tuttavia, il successivo blocco IP 10.0.1.0/24 è stato allocato nello strumento dell'indirizzo IP per un altro scopo. Di conseguenza, è necessario aggiungere un CIDR non contiguo alla VCN.
• Se possibile, utilizzare i blocchi CIDR all'interno dello spazio di indirizzi IP privati RFC 1918 standard.
• Evitare di utilizzare lo spazio degli indirizzi IP 169.254.0.0/16. Molti provider, tra cui Oracle, utilizzano lo stesso spazio IP nella propria rete e ciò può causare problemi.
• Seleziona blocchi CIDR univoci che non si sovrappongono a qualsiasi altra rete (in OCI, nei tuoi data center on-premise o in un altro CSP).
• Quando progetti le subnet, considera il flusso di traffico e i requisiti di sicurezza. Collega tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet.

Usa tabelle di instradamento e liste di sicurezza personalizzate per ogni subnet

Quando si esegue il provisioning delle subnet, verrà richiesto di scegliere una tabella di instradamento della VCN e una lista di sicurezza da utilizzare con ogni subnet.

OCI fornisce una tabella di instradamento predefinita e una lista di sicurezza predefinita che, se utilizzata, viene condivisa con tutte le subnet ad esse associate. L'utilizzo delle opzioni predefinite è utile per una distribuzione semplice o per iniziare, ma non è un approccio consigliato, per una progettazione di produzione che include più subnet. L'uso delle tabelle di instradamento e degli elenchi di sicurezza VCN specifici di ogni subnet consente di mantenere l'instradamento granulare e il controllo di sicurezza per le singole subnet invece di farle condividere queste risorse.

Ad esempio:

• Potrebbe essere necessario che una subnet privata disponga di un instradamento predefinito a un gateway NAT e che una subnet pubblica disponga di un instradamento predefinito a un gateway Internet che richiederebbe la presenza di tabelle di instradamento VCN separate.
• È possibile consentire un flusso di traffico specifico a una subnet, ma non a un'altra che richiederebbe la presenza di liste di sicurezza separate

Oracle consiglia quanto riportato di seguito.

• Crea e associa una tabella di instradamento VCN univoca per ogni subnet
• Crea e associa una lista di sicurezza univoca per ogni subnet

Suggerimento

Crea e associa queste tabelle di instradamento e queste liste di sicurezza VCN univoche quando esegui il provisioning delle subnet in quanto sarà più difficile passare da quelle predefinite in un secondo momento.