Landing zone hub and spoke su OVHcloud Public Cloud

Obiettivo

Questa guida accompagna gli architetti cloud nell'implementazione di una landing zone hub and spoke su OVHcloud Public Cloud tramite un singolo vRack condiviso con routing in transito — la topologia hub and spoke più semplice disponibile su OVHcloud.

Copre la struttura dei progetti, la governance, la topologia di rete privata, la sicurezza di rete, la centralizzazione dei log, il controllo della fatturazione e la gestione del ciclo di vita degli spoke.

Questa guida spiega come costruire una landing zone hub and spoke in produzione su OVHcloud Public Cloud, dalle prime decisioni di architettura fino alle operazioni correnti.

Prerequisiti

• Un account OVHcloud attivo con credenziali API (Application Key, Application Secret, Consumer Key)
• Un accesso Public Cloud con una quota sufficiente per creare progetti, un vRack, istanze e una Floating IP
• OpenTofu ≥ 1.11.4 installato sulla tua postazione di lavoro (HashiCorp Terraform non è compatibile — la cifratura nativa dello stato è una funzionalità specifica di OpenTofu)
• Conoscenza di base dei concetti di rete (CIDR, VLAN, routing)
• Familiarità con il provider Terraform OVHcloud

Accesso allo Spazio Cliente OVHcloud

• Link diretto: Progetti Public Cloud

Procedura

1. Landing zone e architettura hub and spoke

Una landing zone è un ambiente cloud preconfigurato che fornisce le fondamenta di sicurezza, governance, rete, identità e auditabilità di cui i tuoi carichi di lavoro hanno bisogno prima della loro implementazione. Senza di essa, le organizzazioni affrontano una deriva della configurazione, falle di sicurezza, costi non controllati e un'auditabilità limitata.

OVHcloud supporta diverse topologie di landing zone (piatta, segmentata, hub and spoke). Per una presentazione concettuale completa, consulta Comprendere le landing zone. Questa guida si concentra sull'hub and spoke con un singolo vRack condiviso, dove tutti i progetti condividono una stessa dorsale di rete privata e instradano l'insieme del traffico tramite un firewall HA centralizzato a livello dell'hub.

In questa topologia, ogni componente ha un ruolo distinto:

                Internet
                    │
                    ▼
         [OVH Gateway — WAN]
                    │
   [Hub — OPNsense HA (active/passive CARP)]
         ├── WAN  (VLAN 100, 10.1.0.0/24)
         ├── HASYNC (VLAN 199, 10.0.254.0/30)
         └── Transit/LAN (VLAN 200, 192.168.10.0/24)
                    │
          ─── Shared vRack ───
               │           │
  [Spoke A project]   [Spoke B project]
  Neutron router       Neutron router
  (192.168.10.10)      (192.168.10.20)
  ├── App (VLAN 300)   ├── App (VLAN 400)
  └── DB  (VLAN 301)   └── DB  (VLAN 401)
      10.30.0.0/24         10.40.0.0/24

Esempio conduttore — OrbitalEdge SAS: Gli esempi concreti di questa guida sono tratti da OrbitalEdge, una scale-up fittizia di 45 persone con sede a Parigi che sviluppa una piattaforma di edge computing per gli operatori di costellazioni di satelliti (flotte LEO, monitoraggio ambientale). Implementano quattro spoke nella regione EU-WEST-PAR (Parigi): constellation-dev, constellation-prod, signalvault-dev e signalvault-prod. I loro quattro team interagiscono con la landing zone come segue:

La configurazione IaC completa di OrbitalEdge — inclusi i file terraform.tfvars per i quattro spoke — è disponibile sotto examples/orbital-edge nel repository hub-and-spoke-public-cloud.

Pianifica lo spazio di indirizzamento completo prima di implementare qualsiasi infrastruttura. Il VLAN di transito (200) e la sottorete (192.168.10.0/24) sono fissi e condivisi tra tutti i progetti:

2. Principali vantaggi e regioni

2.1 Perché il modello hub and spoke?

2.2 Regioni disponibili

Le regioni OVHcloud Public Cloud coprono l'Europa, il Nord America e l'Asia-Pacifico. L'esempio orbital-edge viene implementato in EU-WEST-PAR (Parigi).

Per l'elenco completo e aggiornato, consulta la pagina di disponibilità delle regioni OVHcloud Public Cloud.

La scelta della tua regione influisce su:

• La localizzazione dei dati: per la conformità GDPR/NIS2, scegli regioni francesi o europee continentali.
• La disponibilità dei flavor di istanze: non tutti i flavor (b3-16, b3-64) sono disponibili in ogni regione — verifica prima del provisioning.
• La latenza: co-localizza l'hub e tutti i progetti spoke nella stessa regione per ridurre al minimo la latenza di routing sul VLAN di transito.

3. Governance e gestione degli accessi

Per una guida dettagliata sull'IAM OVHcloud, consulta Proteggere e strutturare i progetti Public Cloud.

3.1 Base di sicurezza dell'account

Prima di creare qualsiasi progetto:

• Attiva l'autenticazione a due fattori (2FA) sull'account principale: Spazio Cliente > iniziali in alto a destra > Sicurezza.
• Aggiungi un indirizzo e-mail di riserva (deve essere diverso dall'indirizzo principale).
• Definisci una password robusta e univoca (consulta la guida alla gestione delle password).

3.2 Utenti locali, gruppi e policy RBAC

Le policy IAM vengono provisionate automaticamente da OpenTofu (iam.tf) ad ogni implementazione di spoke. Definisci i gruppi qui sotto e assegna policy con scope a ciascun progetto Public Cloud:

Nell'esempio OrbitalEdge, iam.tf crea e assegna automaticamente le policy ad ogni tofu apply. Tuttavia, gli account utente locali stessi devono essere creati nello Spazio Cliente OVHcloud prima del primo tofu apply — costituiscono un prerequisito, non un output: Alice e Baptiste (team Platform), Camille (FleetOS), Driss (SignalVault) ed Elena (CISO).

Per creare una policy:

1. Vai su IAM > Policy > Crea una policy.
2. Nominala seguendo il modello {resource}-RO o {resource}-RW.
3. Assegna il gruppo di destinazione, il tipo di prodotto (Progetto Public Cloud), la risorsa e l'autorizzazione.

3.3 Federazione delle identità (opzionale)

Collega il tuo provider di identità aziendale all'IAM OVHcloud affinché gli utenti si autentichino con le loro credenziali esistenti:

• AD FS (SAML)
• Microsoft Entra ID
• Okta
• Google Workspace

I gruppi definiti nel tuo IdP sono inclusi nell'asserzione SAML e mappati ai gruppi IAM OVHcloud.

3.4 Account di servizio per l'IaC

Crea un account di servizio dedicato (e non il tuo account personale) per autenticare il tuo strumento IaC presso l'API OVHcloud. Concedigli le autorizzazioni minime richieste:

• Creare e gestire progetti Public Cloud
• Creare e gestire un vRack, collegare progetti
• Creare utenti OpenStack nei progetti

Genera credenziali API con il generatore di token API OVHcloud. Conserva l'Application Key, l'Application Secret e la Consumer Key in modo sicuro — mai nel controllo di versione.

3.5 Utenti OpenStack per progetto

Gli utenti OpenStack vengono provisionati automaticamente da OpenTofu (users.tf), uno per progetto. Come minimo, crea utenti con la seguente ripartizione di ruoli:

Questa separazione impedisce ai carichi di lavoro runtime di modificare accidentalmente le configurazioni di rete o di sicurezza. Nell'esempio orbital-edge, OpenTofu conserva le credenziali OpenStack generate nello stato Terraform; Alice le recupera dopo l'apply e le conserva in HashiCorp Vault.

3.6 Governance delle credenziali IaC

Modelli raccomandati:

• Sviluppo locale: conserva i file di variabili al di fuori del repository o in un percorso ignorato da .gitignore.
• Pipeline CI/CD: inietta le credenziali come variabili d'ambiente tramite il gestore di segreti della tua pipeline (HashiCorp Vault, GitHub Secrets, GitLab CI Variables, ecc.). Nell'esempio orbital-edge, Alice inietta tutti i segreti TF_VAR_* da HashiCorp Vault prima di ogni tofu apply.
• Stato remoto: utilizza un backend compatibile S3¹ (OVHcloud Object Storage) con la cifratura lato server o la cifratura nativa dello stato attivata. Isola ciascuna implementazione (hub, ogni spoke) nel proprio file di stato. OpenTofu ≥ 1.11.4 supporta la cifratura nativa dello stato con PBKDF2 + AES-GCM.

4. Implementare l'architettura

I passaggi delle sezioni 4.1–4.4 descrivono cosa automatizza landing-zone/tofu apply. Seguili se preferisci implementare senza IaC.

4.1 Creare i progetti Public Cloud

Crea come minimo due progetti per iniziare:

• Progetto hub — ospita il cluster firewall HA OPNsense, il gateway Internet e i servizi condivisi.
• Progetto Spoke-QA — un primo spoke per convalidare la topologia prima di passare in produzione.

Utilizza una convenzione di denominazione coerente per consentire lo scoping della governance, l'isolamento della fatturazione e l'automazione — ad esempio: {dominio}_{applicazione}_{ambiente} (es. infra_hub_prod, finance_invoicing_qa). Ogni progetto ha il proprio limite di fatturazione, il proprio perimetro di accesso e il proprio insieme di credenziali OpenStack. OrbitalEdge utilizza hubonevrack-orb, constellation-dev, constellation-prod, signalvault-dev e signalvault-prod — tutti creati automaticamente da OpenTofu.

4.2 Creare il vRack condiviso e collegarvi i progetti

Un vRack è una dorsale layer-2 privata OVHcloud. In questa architettura, un singolo vRack condiviso è utilizzato per tutti i progetti — l'hub e tutti gli spoke si collegano allo stesso vRack. Questo è ciò che rende possibile il routing in transito: il LAN dell'hub e l'interfaccia di rete di transito di ciascuno spoke condividono lo stesso segmento VLAN 200 attraverso il vRack.

Ordine di collegamento:

1. Crea un vRack per l'intera landing zone.
2. Collega il progetto hub al vRack.
3. Collega il progetto spoke-QA allo stesso vRack.
4. Pianifica e registra la tabella completa dei VLAN e dei CIDR prima di creare qualsiasi rete (consulta la sezione 1). Le assegnazioni di VLAN sono praticamente irreversibili — modificarle successivamente richiede di riprovisionare tutte le reti interessate.

4.3 Cluster firewall HA dell'hub e rete di transito

Il cluster HA OPNsense dell'hub è l'unico firewall e punto di controllo del routing per l'intera landing zone. Provisionalo prima di qualsiasi spoke. Nell'esempio orbital-edge, l'intero hub — reti, coppia HA OPNsense, Floating IP, VIP CARP e HASYNC — viene implementato automaticamente da landing-zone/tofu apply (da 5 a 8 minuti).

1. 3 reti private nel progetto hub, ciascuna su un VLAN distinto:

   • Rete WAN (VLAN 100, 10.1.0.0/24) — si connette all'OVH Gateway per l'uscita Internet/NAT.
   • Rete Transit/LAN (VLAN 200, 192.168.10.0/24) — la sottorete di transito condivisa. Tutti i router Neutron degli spoke si connettono qui. La VIP CARP LAN OPNsense dell'hub (192.168.10.99) è il gateway predefinito per tutti gli spoke.
   • Rete HASYNC (VLAN 199, 10.0.254.0/30) — dedicata alla replica dello stato HA OPNsense (CARP/pfsync); nessun altro traffico su questo VLAN.

2. OVH Gateway sulla rete WAN — fornisce il NAT e il routing Internet per tutto il traffico in uscita dagli spoke. Consulta la guida Rete privata con Gateway per i passaggi di configurazione.

3. Due istanze OPNsense (principale e secondaria) — implementa a partire da un'immagine cloud-ready (es. OPNsense 26.1-cloudready). Dimensionamento minimo raccomandato: b3-16 (4 vCPU / 16 GB RAM). Utilizza un gruppo di server anti-affinità per posizionare le istanze principale e secondaria su hypervisor diversi. Collega ciascuna istanza alle tre reti (WAN, Transit/LAN, HASYNC).

4. Floating IP — collega una Floating IP pubblica alla porta della VIP CARP WAN. È l'unico IP pubblico di tutta la landing zone: accesso di gestione (SSH, interfaccia web OPNsense sulla porta 8443) e uscita Internet per tutti gli spoke.

5. VIP CARP — configura due IP virtuali CARP:

   • VIP CARP WAN (es. 10.1.0.99) — indirizzo sorgente NAT per tutto il traffico in uscita.
   • VIP CARP LAN (192.168.10.99) — gateway predefinito per ciascun router Neutron di spoke. Questo indirizzo deve rimanere stabile durante i failover.

6. HASYNC e pfsync — configura la sincronizzazione HA OPNsense sull'interfaccia HASYNC affinché lo stato del firewall, le regole e la configurazione si replichino automaticamente tra l'istanza principale e secondaria.

openstack network set --disable-port-security <network_id>

4.4 Base di sicurezza

Applica i controlli seguenti prima di esporre l'hub a qualsiasi traffico:

Gruppo di sicurezza OpenStack sulla porta WAN dell'hub — limita l'accesso in entrata alla Floating IP:

Qualsiasi altro traffico in entrata è bloccato a livello OpenStack prima di raggiungere OPNsense.

Chiavi SSH — inietta la chiave pubblica SSH dell'operatore in tutte le istanze tramite cloud-init al momento del provisioning. Non utilizzare l'autenticazione SSH tramite password.

Password admin OPNsense — utilizza una password robusta generata casualmente. Trasmettila sotto forma di hash bcrypt a cloud-init affinché il testo in chiaro non appaia mai nei metadati dell'istanza. Conservala nel tuo gestore di segreti, non nel controllo di versione.

File di stato IaC — conserva lo stato in un backend compatibile S3 (OVHcloud Object Storage) con cifratura lato server. I file di stato possono contenere output sensibili (Floating IP, chiavi API, password).

4.5 Registrare i parametri dell'hub per l'onboarding degli spoke

Una volta implementato l'hub, registra questi valori — ogni spoke ne avrà bisogno:

Conserva queste informazioni nel gestore di segreti condiviso del tuo team o in un runbook sicuro.

5. Registrazione dei log e monitoraggio

5.1 Raccolta centralizzata dei log

Configura OPNsense per trasmettere i syslog verso OVHcloud Logs Data Platform (LDP):

1. In OPNsense: Sistema > File di log > Log remoto.
2. Definisci la destinazione syslog sul tuo endpoint di ingresso LDP (UDP/TCP 514 o GELF).
3. Attiva la registrazione dei log per le regole del firewall e gli eventi di sistema.

Segui la guida di avvio rapido LDP per provisionare il tuo flusso di log e la tua dashboard Kibana/OpenSearch.

I servizi gestiti OVHcloud (Managed Databases, Managed Kubernetes) supportano anche la trasmissione nativa dei log verso LDP — consulta Trasmettere log dai prodotti OVHcloud verso Logs Data Platform.

5.2 Metriche e avvisi

Soglie di avviso raccomandate:

6. Onboarding di un nuovo spoke

6.1 Prerequisiti

Prima di aggiungere uno spoke, conferma di disporre di:

• Hub implementato e accessibile in HTTPS su https://<hub_floating_ip>:8443
• VIP CARP LAN dell'hub (192.168.10.99) e CIDR LAN dell'hub (192.168.10.0/24) annotati (sezione 4.5)
• Nome del servizio vRack dell'hub annotato (sezione 4.5)
• Credenziali API OPNsense dell'hub disponibili
• Un IP di router di transito univoco assegnato nella sottorete di transito, al di fuori del pool DHCP dell'hub (.100–.200) — es. 192.168.10.10 per il primo spoke, 192.168.10.20 per il secondo
• Identificativi VLAN e CIDR univoci assegnati per tutte le reti LAN dello spoke (sezione 1)

6.2 Provisionare le risorse dello spoke

Nell'esempio OrbitalEdge, constellation-dev è il primo spoke: IP del router di transito 192.168.10.10, VLAN 300 (10.30.0.0/24) per il suo livello di carico di lavoro Kubernetes. Lo spoke signalvault-dev aggiunge due reti LAN — app (VLAN 310, 10.31.0.0/24) e data (VLAN 311, 10.31.1.0/24) — con un solo router Neutron a 192.168.10.11. Tutti i passaggi seguenti sono automatizzati da spoke-template/tofu apply; Alice inserisce i valori VLAN/CIDR in terraform.tfvars ed esegue tofu apply (~3 minuti per spoke).

I passaggi seguenti descrivono cosa automatizza spoke-template/tofu apply. Seguili se preferisci effettuare l'onboarding degli spoke senza IaC.

Esegui questi passaggi nell'ordine, attendendo che ciascuna operazione dell'API OVHcloud sia terminata prima di continuare:

1. Crea un progetto Public Cloud per lo spoke (segui la convenzione di denominazione della sezione 4.1) — es. constellation-dev.
2. Collega il progetto spoke al vRack condiviso utilizzando il nome del servizio vRack dell'hub (es. pn-123456). Attendi il tempo di propagazione (30 secondi) prima di creare reti.
3. Crea la rete di transito nel progetto spoke: VLAN 200, CIDR 192.168.10.0/24, DHCP disattivato, senza gateway. Questo espone il segmento di transito dell'hub nel contesto OpenStack dello spoke affinché il router Neutron possa collegarvisi.
4. Crea le reti LAN dello spoke — una rete per livello di carico di lavoro (app, db, ecc.), ciascuna su un VLAN univoco con DHCP attivato — es. VLAN 300, 10.30.0.0/24.
5. Crea un router OpenStack Neutron:
   • Collega la rete di transito con un IP fisso all'IP del router di transito dello spoke (es. 192.168.10.10 per constellation-dev).
   • Collega ciascuna sottorete LAN dello spoke come interfaccia interna.
   • Definisci la rotta predefinita: 0.0.0.0/0 tramite la VIP CARP LAN dell'hub (192.168.10.99).
6. Crea utenti OpenStack (operatore IaC e operatore runtime) per il progetto spoke — creati automaticamente da OpenTofu (users.tf) nell'esempio orbital-edge.

6.3 Configurare il routing lato hub

I passaggi seguenti descrivono cosa automatizza spoke-template/tofu apply per il routing lato hub. Seguili se non utilizzi l'IaC.

Una volta che il router Neutron dello spoke è operativo, registralo sull'OPNsense dell'hub tramite l'API REST:

Aggiungi un gateway che punta all'IP del router di transito dello spoke:

curl -ks -u <hub_api_key>:<hub_api_secret> \
  -X POST https://<hub_floating_ip>:8443/api/routing/settings/add_gateway \
  -H "Content-Type: application/json" \
  -d '{
    "gateway_item": {
      "name": "Spoke<N>TransitGW",
      "interface": "lan",
      "ipprotocol": "inet",
      "gateway": "<spoke_transit_router_ip>"
    }
  }'

# Applicare la configurazione del gateway
curl -ks -u <hub_api_key>:<hub_api_secret> \
  -X POST https://<hub_floating_ip>:8443/api/routing/settings/reconfigure

Aggiungi una rotta statica per ciascun CIDR LAN dello spoke:

curl -ks -u <hub_api_key>:<hub_api_secret> \
  -X POST https://<hub_floating_ip>:8443/api/routes/routes/addroute \
  -H "Content-Type: application/json" \
  -d '{
    "route": {
      "network": "<spoke_lan_cidr>",
      "gateway": "Spoke<N>TransitGW",
      "descr": "Spoke N LAN via transit"
    }
  }'

# Applicare la configurazione delle rotte
curl -ks -u <hub_api_key>:<hub_api_secret> \
  -X POST https://<hub_floating_ip>:8443/api/routes/routes/reconfigure

6.4 Verificare la connettività

Connettiti in SSH alla Floating IP dell'hub e conferma che lo spoke sia raggiungibile:

# SSH verso l'hub
ssh root@<hub_floating_ip>

# Confermare che la rotta verso il LAN dello spoke sia presente
ip route show | grep <spoke_lan_cidr>

# Effettuare il ping dell'IP di transito del router Neutron dello spoke
ping <spoke_transit_router_ip>

# Effettuare il ping di un'istanza nel LAN dello spoke
ping <spoke_instance_ip>

6.5 ProxyJump per l'accesso SSH alle istanze dello spoke

Le istanze degli spoke non hanno un IP pubblico diretto. Accedivi tramite la Floating IP dell'hub:

# ~/.ssh/config
Host hub
  HostName <hub_floating_ip>
  User root
  IdentityFile ~/.ssh/id_rsa

Host spoke-*.internal
  User root
  IdentityFile ~/.ssh/id_rsa
  ProxyJump hub

# Connessione diretta successivamente:
ssh spoke-app01.internal

Per un accesso verificato su larga scala, implementa OVHcloud Bastion su un'istanza dedicata nel progetto hub.

6.6 Lista di controllo dell'onboarding

• Identificativi VLAN e CIDR registrati nel documento di progettazione di rete e assegnati in modo univoco
• IP del router di transito assegnato — univoco in 192.168.10.0/24, al di fuori del pool DHCP (.100–.200)
• Progetto spoke creato e collegato al vRack condiviso
• Rete di transito (VLAN 200, DHCP disattivato) creata nel progetto spoke
• Reti LAN dello spoke create con DHCP attivato
• Router Neutron creato con IP fisso di transito e interfacce LAN
• Rotta predefinita sul router Neutron impostata sulla VIP CARP LAN dell'hub (192.168.10.99)
• Gateway dell'hub (Spoke<N>TransitGW) aggiunto tramite l'API OPNsense e riconfigurato
• Rotte statiche dell'hub aggiunte per ciascun CIDR LAN dello spoke e riconfigurate
• LAN dello spoke raggiungibile dall'hub tramite ping
• Policy IAM create per il progetto spoke (gruppi sviluppatori + SRE)
• Utenti OpenStack provisionati e credenziali distribuite al team dello spoke
• Log trasmessi verso LDP
• Accesso SSH tramite ProxyJump o Bastion configurato e testato

7. Ciclo di vita — Scalabilità, evoluzione, eliminazione

7.1 Scalabilità — aggiunta di spoke

Ripeti il processo di onboarding (sezione 6) per ciascun nuovo spoke. Assegna un IP di router di transito univoco e identificativi VLAN univoci dal tuo piano di rete. Ogni spoke è indipendente — l'aggiunta di un nuovo spoke non ha alcun impatto sugli spoke esistenti e aggiunge solo un gateway e rotte statiche sull'OPNsense dell'hub.

Man mano che il numero di spoke aumenta, monitora la CPU e il throughput dell'OPNsense dell'hub. L'hub elabora tutto il traffico nord-sud ed est-ovest per ciascuno spoke — dimensionalo di conseguenza (b3-16 per la maggior parte delle implementazioni, b3-64 per gli ambienti ad alto traffico o con numerosi spoke).

Quando OrbitalEdge ha avuto bisogno di un quinto spoke per l'archiviazione dei dati storici (telemetry-archive-prod), il processo ha richiesto meno di 30 minuti: riservare l'IP di transito 192.168.10.30, assegnare il VLAN 510 (10.51.0.0/24) per il livello app e il VLAN 511 (10.51.1.0/24) per il livello data, copiare la directory del template spoke, compilare terraform.tfvars ed eseguire tofu apply. I quattro spoke esistenti non sono stati interessati — nessuna interruzione dell'hub, nessun riavvio del firewall.

7.2 Eliminare uno spoke

I passaggi seguenti descrivono cosa effettua tofu destroy durante la dismissione di uno spoke. Seguili se non utilizzi l'IaC.

Dismetti nell'ordine inverso del provisioning:

1. Elimina il routing lato hub — sull'OPNsense dell'hub, elimina le rotte statiche per i CIDR LAN dello spoke e il gateway dello spoke:
   • Sistema > Rotte: elimina le rotte LAN dello spoke, poi clicca su Applica modifiche.
   • Sistema > Gateway: elimina il gateway di transito dello spoke.
   • O tramite API: POST /routes/routes/delroute/{id} poi POST /routes/routes/reconfigure, e POST /routing/settings/del_gateway/{id} poi POST /routing/settings/reconfigure.
2. Distruggi le risorse dello spoke — elimina le interfacce del router Neutron e il router, le reti LAN, la rete di transito e il progetto Public Cloud. Se utilizzi l'IaC, esegui un'operazione di distruzione limitata allo stato dello spoke.
3. Verifica sull'hub — conferma che non rimanga alcun oggetto orfano:
   • Sistema > Rotte: rotte LAN dello spoke eliminate.
   • Sistema > Gateway: gateway dello spoke eliminato.
4. Aggiorna il documento di progettazione di rete — libera gli identificativi VLAN e l'IP di transito per il riutilizzo.

7.3 Aggiornare OPNsense

Gli aggiornamenti OPNsense (patch di sicurezza, versioni minori) seguono una procedura di failover CARP:

1. Verifica che CARP sia operativo: Interfacce > IP virtuali > Stato.
2. Metti il nodo secondario in modalità di manutenzione CARP (retrocedi a BACKUP).
3. Aggiorna il secondario: Sistema > Firmware > Aggiornamenti.
4. Riavvia il secondario; verifica che si unisca a CARP come BACKUP.
5. Effettua un failover controllato: promuovi temporaneamente il secondario a MASTER.
6. Aggiorna e riavvia il primario.
7. Ripristina i ruoli originali MASTER/BACKUP.

7.4 Lista di controllo trimestrale

8. Fatturazione, centri di costo e impronta di carbonio

8.1 Isolamento dei costi per progetto

La fatturazione OVHcloud Public Cloud è limitata per progetto. Ogni progetto spoke ti fornisce un limite di costo chiaro per un team, un'applicazione o un'unità di business.

Esporta i dati di costo tramite l'API OVHcloud:

# Elencare il consumo di un progetto
curl -s -X GET "https://eu.api.ovh.com/v1/cloud/project/{project_id}/usage/current" \
  -H "X-Ovh-Application: $OVH_APPLICATION_KEY" \
  -H "X-Ovh-Consumer: $OVH_CONSUMER_KEY" \
  -H "X-Ovh-Timestamp: $(date +%s)" \
  -H "X-Ovh-Signature: $SIG"

Consulta la guida alla fatturazione Public Cloud per i dettagli completi dell'API e le opzioni di esportazione CSV.

8.2 Strategia di tagging

Tagga tutte le risorse in modo coerente al momento del provisioning, ad esempio:

metadata = {
  environment  = "prod"
  owner        = "platform-team"
  cost-centre  = "infra-shared"
  project-id   = "hub"
}

I tag consentono report di allocazione dei costi, policy di pulizia automatizzate e audit di conformità.

8.3 Avvisi di budget

Configura soglie di spesa nello Spazio Cliente OVHcloud:

1. Vai su Fatturazione > Avvisi di budget.
2. Definisci una soglia mensile per progetto.
3. Configura una notifica tramite e-mail o webhook quando l'80 % e il 100 % del budget vengono raggiunti.

8.4 Impronta di carbonio

I datacenter OVHcloud in Europa (GRA, SBG, WAW, LIM) presentano tra le migliori misurazioni di Power Usage Effectiveness (PUE) del settore, con impegni in materia di energia rinnovabile su diversi siti.

Per ridurre al minimo il tuo impatto di carbonio:

• Privilegia le regioni europee con fonti di energia rinnovabile dichiarate.
• Dimensiona correttamente l'hub: b3-16 è sufficiente per la maggior parte delle implementazioni — evita il sovradimensionamento.
• Utilizza le policy di ciclo di vita di Object Storage per far passare i log freddi verso l'accesso poco frequente e far scadere i dati temporanei.
• Dismetti gli spoke inutilizzati piuttosto che lasciare in funzione un'infrastruttura inattiva.

9. Conclusione

Il modello hub and spoke a vRack unico su OVHcloud Public Cloud offre alle organizzazioni una landing zone pronta per la produzione, verificabile ed evolutiva. Un firewall HA OPNsense centralizzato controlla tutto il traffico in uscita e inter-spoke. I progetti spoke richiedono solo router OpenStack Neutron standard — nessun cluster firewall per spoke, nessun tunnel IPsec — il che ne fa la topologia hub and spoke più semplice disponibile su OVHcloud.

L'implementazione e la gestione di questa architettura richiedono solide competenze cloud e di rete, in particolare la gestione del vRack e dei VLAN OVHcloud, la gestione di un cluster HA OPNsense e le pratiche di Infrastructure as Code. I team che iniziano con queste tecnologie sono vivamente incoraggiati a rivolgersi agli OVHcloud Professional Services per una revisione della progettazione, un'implementazione assistita o una valutazione della maturità operativa prima di passare in produzione.

Richiedi un preventivo agli OVHcloud Professional Services

Per saperne di più

• Comprendere le landing zone
• Riferimento di architettura — Costruire una landing zone con OVHcloud Public Cloud
• Best practice per proteggere e strutturare i progetti OVHcloud Public Cloud
• Come utilizzare Terraform con OVHcloud Public Cloud
• Configurare il vRack per Public Cloud tramite l'API OVHcloud v6
• Iniziare con Logs Data Platform

Contatta la nostra Community di utenti.

¹: S3 è un marchio di Amazon Technologies, Inc. Il servizio di OVHcloud non è sponsorizzato, approvato o affiliato in alcun modo ad Amazon Technologies, Inc.