Configurazione del tenant: account, ambienti e modalità di accesso
L'account cloud su cui viene eseguita la distribuzione, il tenant del vault separato, gli ambienti esistenti in ciascun anno e se il tenant è raggiungibile da Internet pubblico o solo privatamente.
Quando si parla di "inquilino privato" e "inquilino pubblico", si intendono tre cose diverse. In TRANXACT Private Cloud, queste due tipologie di contratto sono nettamente distinte e si suddividono in tre categorie distinte, per le quali è opportuno utilizzare i seguenti termini:
| Decisione | Opzioni | Deciso |
|---|---|---|
| Isolamento: c'è qualcosa in comune con un altro cliente? | No. Ogni implementazione è a tenant singolo: una VPC/VNet, un cluster e un database dedicati per ogni cliente, senza registro o database condivisi. | Non è una scelta; è sempre stato così. |
| Titolare dell'account: a chi appartiene l'account cloud? | Ospitato da TRANXACT: un account o un abbonamento dedicato fornito da TRANXACT. Di proprietà del cliente: l'account del cliente stesso, che TRANXACT gestisce tramite un ruolo di automazione delegato. | Prima della firma; inserito per iscritto nell'allegato del contratto. |
| Assunzione della postura: come si raggiunge? | Pubblico: gli utenti vi accedono tramite HTTPS su Internet (impostazione predefinita). Solo privato: il listener pubblico è chiuso ed è accessibile solo tramite VPN, connessione privata o peering. | Prima di firmare, con l'opzione di connettività. |
Non esiste una versione multi-tenant o condivisa di TRANXACT Private Cloud denominata "public tenant". Quando un cliente parla di "public tenant", quasi sempre si riferisce a un'implementazione accessibile da Internet, che è la configurazione predefinita di un tenant dedicato, non di un prodotto diverso.
Titolare dell'account
| ospitato da TRANXACT | di proprietà del cliente | |
|---|---|---|
| Chi crea l'account | TRANXACT (INFRA_2.1.01) | Il cliente: lo crea, imposta la fatturazione, applica le policy della landing zone e concede il ruolo di automazione TRANXACT (INFRA_2.1.02, Escluso) |
| Chi paga la fattura del cloud? | Secondo il modulo d'ordine | Il cliente viene fatturato direttamente dal fornitore secondo le sue tariffe di listino. |
| capacità riservata | TRANXACT raccomanda (INFRA_2.1.05) | TRANXACT raccomanda; il cliente acquista (INFRA_2.1.06, Escluso) |
| Guardrail, etichettatura, avvisi di bilancio | TRANXACT (INFRA_2.1.04) | TRANXACT li applica all'interno delle politiche della zona di atterraggio del cliente |
| RACI | Contabilità clienti per conto, zona di atterraggio e fatturazione in entrambi i casi; consultazione con TRANXACT. |
In entrambi i casi, TRANXACT predispone anche un account vault o tenant separato con identità, autenticazione a più fattori (MFA) e chiavi proprie (INFRA_2.1.03). È l'unico elemento che non si trova mai nello stesso account di produzione: vedi Disponibilità, Live DR, backup e vault.
La capacità riservata in genere riduce i costi di elaborazione del 30-40%. Su un account di proprietà del cliente, è il cliente stesso ad acquistarla, quindi è opportuno presentare la raccomandazione al reparto finanziario, non solo all'IT.
Ambienti
Un ambiente è un'istanza TRANXACT isolata: produzione, test/QA, formazione o sandbox. Il livello di utilizzo ne comprende diversi:
| Livello | Ambienti inclusi |
|---|---|
| S | Produzione + 1 non produzione |
| M | Produzione + 2 non di produzione |
| L | Produzione + 3 non di produzione |
| XL | Per paesaggio |
- I database non di produzione vengono eseguiti senza un server di standby ad alta disponibilità.
- Live DR aggiunge una copia a grandezza naturale della riga di produzione, nella seconda regione.
- Ulteriori ambienti non di produzione sono opzionali (TO_4.1.04), dimensionati in base al livello di utilizzo.
- L'ambiente di migrazione per il primo anno è facoltativo (MIG_8.1.03) e viene disattivato dopo il passaggio al nuovo sistema (TO_4.1.05, una richiesta di servizio standard).
- La disponibilità non produttiva è del 95%, misurata mensilmente.
Un quadro generale per anno contrattuale (ad esempio, livello M)
| Ambiente | Scopo | Nodi | DB gestito | Anno 1 | Anni 2–5 |
|---|---|---|---|---|---|
| PRD | Produzione | 3 × 8 vCPU / 32 GB | 8 vCPU / 64 GB HA, 1 TB | SÌ | SÌ |
| DR | Live DR di PRD | 3 × 8 vCPU / 32 GB | Replica, 1 TB | SÌ | SÌ |
| QAS | Test / regression | 3 × 4 vCPU / 16 GB | 4 vCPU / 32 GB, 1 TB | SÌ | SÌ |
| TRN | Allenamento / ambiente di prova | Condiviso con QAS | 2 vCPU / 16 GB, 500 GB | SÌ | Sì, ridimensionato |
| MIG | Carichi di prova per la migrazione | 3 × 8 vCPU / 32 GB | 8 vCPU / 64 GB, 1 TB | SÌ | No, dismesso |
| Volta | backup isolati dalla rete | — | Solo per l'archiviazione | SÌ | SÌ |
Pianifica il primo anno con la capacità aggiuntiva necessaria in termini di migrazione e formazione, per poi ridimensionarla gradualmente. Ogni modifica rappresenta una richiesta di modifica, quindi è opportuno includere il ridimensionamento nella proposta fin da subito, anziché doverlo negoziare nel secondo anno.
Ordine di messa in scena
- Prima della firma, concordare la proprietà dell'account, la regione e la regione di ripristino di emergenza (Live DR). La regione, gli intervalli di indirizzi, il FQDN e il motore del database non possono essere modificati dopo l'avvio della build senza una ricostruzione e una richiesta di modifica.
- Se di proprietà del cliente: il cliente crea l'account, applica le proprie policy di landing zone e assegna il ruolo di automazione, in parallelo con la stipula del contratto.
- TRANXACT gestisce il conto di deposito, applica le misure di sicurezza, l'etichettatura e gli avvisi di budget.
- Crea la rete per regione: una VPC/VNet dedicata con le relative sottoreti (vedi Topologie di rete).
- Creare ambienti tramite infrastruttura come codice (TO_4.1.01): il cluster, il database HA, l'archiviazione degli oggetti e la regione di ripristino Live DR, se contrattualizzata.
- Copia l'infrastruttura come codice e la configurazione nel vault (TO_4.1.06). Il runtime viene ricostruito, non ripristinato.
- Inviare le credenziali solo al contatto tecnico indicato (TO_4.1.02); il cliente verifica la connettività e l'SSO (TO_4.1.03).
Posizione di accesso
| Pubblico (predefinito) | Solo privato | |
|---|---|---|
| Come arrivano gli utenti | DNS pubblico → gestore del traffico globale → bilanciatore di carico + WAF su TLS 1.2+ | Zona privata DNS del cliente → VPN / collegamento privato → bilanciatore di carico interno |
| Ciò di cui ha bisogno | Un FQDN, un record DNS pubblico, un certificato CA pubblico | Tutto ciò, oltre a connettività privata, una zona DNS privata o inoltro condizionale |
| Restringendolo | Inserimento opzionale di indirizzi IP consentiti nel listener pubblico (INFRA_2.6.04, Standard) | Il listener pubblico è stato chiuso (INFRA_2.6.05, Opzionale) |
| Utenti remoti | Accesso diretto, SSO e MFA tramite l'IdP del cliente. | È necessario un accesso VPN o zero-trust al percorso privato |
| È ora di andare in diretta | Il più veloce — nessuna creazione di rete | Più a lungo: la pianificazione degli indirizzi, il routing, il firewall e il DNS lavorano sul percorso critico |
È importante valutare fin da subito se l'accesso tramite solo HTTPS sia sufficiente. La connettività privata comporta un lavoro aggiuntivo che si aggiunge al percorso critico per la messa in produzione, e spesso l'attivazione di circuiti privati da parte del provider richiede settimane.
I valori contrassegnati come predefiniti proposti sono i punti di partenza consigliati dalla guida all'implementazione. Confermare ciascun valore per ogni cliente; il contratto, il modulo d'ordine, l'accordo sui livelli di servizio (SLA) e l'accordo sulla protezione dei dati (DPA) prevalgono su questa pagina.