Pianificazione e progettazione della fase preliminare alla migrazione verso IBM Cloud VPC

Valutare i carichi di lavoro di " VMware ", progettare la connettività " Transit Gateway " e selezionare i profili di istanza VPC prima di effettuare la migrazione a " IBM Cloud VPC ".

Valutazione e categorizzazione del carico di lavoro

Prima di iniziare la migrazione, è necessario capire di cosa si dispone al di là di un inventario del proprio ambiente. Le sezioni seguenti aiutano a valutare e classificare gli ambienti di migrazione.

Scoperta e dipendenze

Per estrarre l'inventario di VMware, è possibile utilizzare strumenti di estrazione come RVTools. Per ogni server virtuale, tenere presente le seguenti informazioni.

  • Identificare le dipendenze. Con cosa comunica questo server virtuale? Il server virtuale può migrare in modo indipendente?
  • Caratteristiche della rete. L'ambiente utilizza un indirizzo IP statico o il protocollo DHCP (Dynamic Host Configuration Protocol)? Dispone di più schede di rete (NIC)? L'ambiente presenta requisiti specifici relativi alle reti locali virtuali (VLAN)?
  • Disposizione dei magazzini. Quanti dischi ha l'ambiente? Qual è l'utilizzo attuale di IOPS? Qual è la capacità totale?
  • Prestazioni di base. Quali sono le CPU, la memoria, la rete e le opzioni di archiviazione utilizzate?
  • Caratteristiche dell'applicazione. Avete dei database? L'ambiente ospita un server web? L'ambiente può supportare una migrazione a freddo?
  • Requisiti di conformità. Posizione dei dati, tipo di crittografia, registrazione di audit.

Conoscere queste informazioni aiuta la pianificazione delle onde, la selezione dei metodi e la stima dei tempi.

Indirizzare il re-IP

Poiché non è possibile estendere le sottoreti e la VPC riserva determinati indirizzi, è necessario considerare le seguenti scelte durante la fase di pianificazione della migrazione.

  • Avete bisogno di altre sottoreti? Se non è possibile migrare subnet per subnet, potrebbe essere necessario riassegnare le subnet con determinate applicazioni. Considerate la possibilità di separare le applicazioni in sottoreti proprie.
  • Quale server virtuale è necessario ri-IP? Se gli IP utilizzano .0, .1, .2, .3, indirizzi di broadcast, o se è necessario consolidare gli intervalli IP, è necessario cambiare gli IP.
  • Quale strategia è necessario utilizzare per aggiornare il DNS e i bilanciatori di carico? Anche se si mantengono gli IP all'interno della VPC, potrebbe essere necessario aggiornare il DNS esterno, i bilanciatori di carico e le regole del firewall per indirizzarli al nuovo ambiente.

Tenete queste informazioni a disposizione durante il processo di migrazione.

Architettura di connettività

I vostri server virtuali potrebbero avere bisogno di parlare tra loro durante la migrazione. Si prevede di migrare una sottorete alla volta, ma potrebbe essere necessario utilizzare più sottoreti se la latenza è un problema. Vedere le seguenti informazioni sulla connettività di migrazione.

IBM Cloud Transit Gateway

Transit Gateway è il meccanismo principale per collegare l'ambiente VMware alla VPC. Si tratta di un router cloud che collega diversi domini di rete.

Da IBM Cloud Classic ( VMware su infrastruttura Classic)

  • Transit Gateway si collega direttamente al vostro conto Classic
  • Fornisce il routing tra le VLAN classiche e le sottoreti VPC

Da VMware su NSX (classico con sovrapposizione NSX)

  • Transit Gateway si connette ai bordi di NSX attraverso tunnel GRE
  • Si configurano gli endpoint GRE sui bordi di NSX e in Transit Gateway
  • Il routing si propaga tra i segmenti NSX e le sottoreti VPC

Da " VMware Cloud Foundation " as a Service ( VCFaaS )

  • Transit Gateway si connette all'edge di VCFaaS attraverso tunnel GRE
  • Viene seguito uno schema simile a quello di NSX, ma gestito attraverso il portale VCFaaS

Considerazioni sulla progettazione

  • Predisporre Transit Gateway fin dalle prime fasi del progetto di migrazione
  • Pianificate attentamente il routing perché la sovrapposizione di intervalli IP tra VMware e VPC può causare problemi
  • Considerate una topologia hub-and-spoke se dovete collegare più VPC o account Classic
  • Testate a fondo la connettività prima della prima ondata di migrazione

Selezione del profilo dell'istanza

I profili delle istanze combinano la generazione della CPU, il numero di unità centrali di elaborazione virtuali ( vCPU ), la memoria, la larghezza di banda di rete e il numero massimo di interfacce di rete. Questi profili sono diversi da VMware, dove vCPUs e RAM sono impostati in modo indipendente.

Comprendere i rapporti tra vCPU e pCPU

VMware utilizza rapporti di oversubscription di 4:1 o 8:1 per l' vCPU e rispetto ai core fisici ( pCore ). I profili di istanza standard VPC garantiscono un rapporto 1:1 tra CPU virtuali e core hyperthreaded. Questo oversubscription significa che un'istanza di 8 vCPU in VPC ha 8 hyperthread dedicati (non 8 vCPUs che possono potenzialmente condividere meno core).

IBM Cloud offre server virtuali burstable che si possono utilizzare per rapporti di oversubscription di 2:1, 4:1 e 10:1, con la possibilità di burst fino a 2x l'allocazione garantita. Per ulteriori informazioni sui server virtuali burstable, vedere Server virtuali burstable.

Allocazione della larghezza di banda della rete

Ogni profilo di istanza specifica la larghezza di banda totale della rete. Per impostazione predefinita, la larghezza di banda totale è allocata con un rapporto di 3:1 tra il traffico di rete e l'I/O dello storage, ma è possibile regolare questa allocazione dopo il provisioning dei server.

Per ulteriori informazioni sull'allocazione della larghezza di banda, vedere Informazioni sull'allocazione della larghezza di banda per i profili di istanza.

Se il vostro profilo lo supporta, scegliete l'opzione di allocazione in pool. L'allocazione in pool condivide dinamicamente la larghezza di banda dello storage (in base all'utilizzo) tra tutti i volumi, anziché dividerla equamente. Il volume di avvio riceve comunque un minimo garantito.

Profili di archiviazione

VPC offre due generazioni di profili di storage.

Profili di archiviazione di prima generazione

I profili di archiviazione di prima generazione sono disponibili nelle seguenti situazioni.

  • Uso generale: Richiesto per i volumi di avvio, 3 IOPS per GB
  • 5iops-tier: 5 IOPS per GB
  • 10iops-tier: 10 IOPS per GB
  • Personalizzato: Specificare gli IOPS esatti, attualmente fino a 48.000 per volume

I profili di archiviazione di prima generazione offrono i seguenti vantaggi.

  • Gruppi di coerenza degli snapshot per creare automaticamente snapshot di più volumi
  • Rilevamento GPT e UEFI per i volumi di avvio
  • Disponibile in tutte le regioni

Utilizzate i profili di prima generazione per i volumi di avvio e per i carichi di lavoro di produzione che richiedono gruppi di coerenza snapshot.

Profili di seconda generazione (sdp)

Il profilo sdp offre prestazioni migliori e un controllo granulare degli IOPS.

Si prega di tenere presenti le seguenti limitazioni:

  • I gruppi di coerenza delle istantanee non sono supportati
  • sdp i profili potrebbero non rilevare i volumi formattati GPT, il che potrebbe causare l'avvio del sistema da BIOS anziché da UEFI
  • L'avvio sicuro non è supportato

A causa di queste limitazioni, non utilizzare sdp per i volumi di avvio. sdp è ideale per i volumi di dati secondari con prestazioni elevate e in grado di tollerare singole istantanee.

Gruppi di sicurezza e crittografia

IBM Cloud VPC offre gruppi di sicurezza e opzioni di crittografia.

Gruppi di sicurezza

Se si utilizza il firewall distribuito (DFW) VMware o la microsegmentazione NSX, è necessario migrare queste regole nei gruppi di sicurezza VPC.

Dettagli del gruppo di sicurezza VPC:

  • I gruppi di sicurezza sono stateful e consentono automaticamente il traffico di ritorno.
  • È possibile assegnare più gruppi di sicurezza a un'interfaccia di rete virtuale (VNI) pur consentendo il traffico.
  • Le regole possono fare riferimento al gruppo di sicurezza come sorgente o destinazione, il che significa che i membri di questo gruppo possono parlare tra loro su queste porte.
  • Non esistono regole di negazione esplicite. I gruppi di sicurezza sono di sola autorizzazione.

Strategia di migrazione:

  • Documentate il vostro attuale DFW o le regole del firewall
  • Raggruppare i server virtuali in base alla posizione di sicurezza (web tier, app tier, database tier)
  • Creare gruppi di sicurezza che rispecchino questi livelli
  • Utilizzare riferimenti da gruppo a gruppo, ove possibile, per evitare di enumerare gli IP
  • Eseguire prima un test approfondito in una migrazione non di produzione

Crittografia

Se si utilizza la crittografia vSAN, i VMDK crittografati o la crittografia del sistema operativo guest, è necessario migrare queste opzioni.

Dettagli della crittografia VPC:

  • Tutti i volumi supportano la crittografia dei dati inattivi tramite chiavi gestite dal provider o dall'utente, tramite il servizio " Key Protect " o " Hyper Protect Crypto Services " (HPCS).
  • I profili di elaborazione riservati offrono una maggiore sicurezza grazie a Intel SGX e TDX e all'avvio sicuro.
  • I dati in transito tra i server virtuali e lo storage sono crittografati dall'infrastruttura IBM Cloud.

Considerazioni sulla migrazione:

  • Per la maggior parte dei carichi di lavoro, la crittografia gestita da IBM Cloud è sufficiente e non richiede interventi specifici per la migrazione.
  • Per la crittografia orientata alla conformità, utilizzare Key Protect o HPCS con chiavi gestite dall'utente.
  • Se si richiede un avvio sicuro, utilizzare un profilo informatico riservato ed evitare l'archiviazione su sdp.

Opzioni di licenza

IBM Cloud offre diverse opzioni di licenza per i sistemi operativi.

Considerazioni sulla licenza:

  • BYOL richiede immagini personalizzate
  • Le regole sulla portabilità delle licenze variano a seconda del fornitore: verificatene la conformità
  • IBM Cloud-le licenze fornite includono il supporto per il sistema operativo