Guida all'upgrade a Data Center
Tutte le organizzazioni sono diverse. Ecco perché ogni percorso di migrazione è unico. Segui la nostra guida all'upgrade dettagliata per assicurare una transizione ottimale da Atlassian Server a Data Center.
Valutazione
Ogni organizzazione ha esigenze e requisiti specifici. Ecco perché per pianificare un aggiornamento di successo è fondamentale capire le varie opzioni a disposizione.
Comprensione dei requisiti dell'architettura e dell'infrastruttura
Hai optato per Data Center? Allora devi conoscere l'architettura e le configurazioni di distribuzione di Data Center supportate.
Data Center può essere distribuito in due modi diversi, ovvero con o senza clustering. Entrambi consentono di sfruttare le funzioni e le capacità di livello enterprise, ma per ogni opzione occorre fare considerazioni diverse. Ecco una tabella che descrive le differenze tra le architetture con e senza clustering:
Senza clustering
Requisiti dell'infrastruttura
Un'architettura senza clustering ti permette di effettuare l'upgrade a Data Center usando la tua infrastruttura esistente senza dover apportare alcuna modifica.
Casi d'uso consigliati
Una disponibilità elevata non è immediatamente necessaria.
Vantaggi
Sblocca le funzioni di livello enterprise che non richiedono il clustering:
Per molti clienti, gli upgrade non in cluster sono in genere il punto di partenza del percorso verso Data Center. Ti consigliamo di approfittare di questo upgrade di 2 minuti per garantire una transizione senza intoppi.
Con clustering
Requisiti dell'infrastruttura
Per effettuare l'upgrade a Data Center in un cluster ti serviranno i componenti qui sotto:
- Bilanciamento del carico
- Nodi applicativi
- File system accessibile da tutti i nodi applicativi
- Nodo Elasticsearch (Bitbucket)
Casi d'uso consigliati
- Hai bisogno di elevata disponibilità
- Vuoi effettuare l'upgrade senza tempi di inattività
- Prevedi una crescita di scala XL nel breve periodo
Vantaggi
Sblocca le funzionalità aziendali che il clustering può offrire:
- Funzioni e capacità di livello enterprise
- Disponibilità elevata e failover: se un nodo nel tuo cluster applicativo non funziona, gli altri si accollano il carico, assicurando agli utenti l'accesso ininterrotto al prodotto.
- Scalabilità immediata: aggiungi nuovi nodi al cluster senza tempi di inattività o costi di licenza aggiuntivi. Sincronizzazione automatica di indici e app.
- Ripristino di emergenza: distribuire un sistema di ripristino di emergenza esterno assicura produttività, anche in caso di interruzione completa del sistema. Con gli indici di prodotto condivisi si torna subito a lavorare.
Pianifica e prepara
Ora che hai scelto il tuo percorso nel Data Center, puoi iniziare a creare un piano di aggiornamento dettagliato.
Crea una sequenza temporale necessario
Qui trovi le timeline di base che puoi usare per valutare la possibile durata del tuo aggiornamento.
| | Senza clustering | Con clustering |
|---|---|---|
| Pianificazione | Senza clustering 0-2 settimane | Con clustering Più di 1 mese |
| Dry-run | Senza clustering 0-1 settimana | Con clustering 3-6 mesi |
| Distribuzione | Senza clustering 0-1 settimana | Con clustering Circa 6-9 mesi |
Le tempistiche indicate si basano su un gruppo di clienti che hanno completato l'upgrade a Data Center, ma è importante notare che quelle effettive variano in base a fattori specifici del tuo ambiente tra cui, a titolo esemplificativo, le dimensioni, la complessità e la preparazione.
Definisci l'ambiente Data Center necessario
Livello dell'applicazione
Istanze e posizioni
- Desideri federare o consolidare le tue istanze?
- Come sarà la tua crescita futura?
- Hai bisogno di isolare i tuoi dati?
- Quanti ambienti, ad esempio quelli di staging o di produzione, ha il tuo team?
Profili delle istanze
- Quante persone accederanno alla tua istanza?
- Dove si troveranno i tuoi team?
- Quanti dati sono attualmente presenti nell'istanza e quanti dati prevedi di aggiungere?
App, integrazioni e personalizzazioni
Ti servono tutti questi elementi o vuoi cogliere questa opportunità per semplificare?
Livello dell'infrastruttura
Dimensioni dell'istanza
- Quali sono le tue proiezioni di crescita futura?
- Ci sono momenti in cui i livelli di traffico utente sono inferiori?
Per maggiori informazioni, consulta la nostra panoramica sul dimensionamento dei nodi.
Struttura dell'account
- Su quali account deve essere distribuito l'ambiente?
- Desideri che ciascuno dei tuoi ambienti sia associato ad account diversi?
- Vuoi che i tuoi prodotti Data Center utilizzino lo stesso account degli altri strumenti CI/CD o di collaborazione?
Modello di governance
- Che aspetto ha il tuo modello di governance?
- Quali sono gli standard minimi del sistema?
- Stai utilizzando la registrazione centralizzata?
- Quali sono le tue esigenze di gestione degli utenti?
Prendi in considerazione l'utilizzo delle soluzioni AWS Landing Zone e AWS System Manager come parte del tuo modello di governance.
VPC
-
Vuoi utilizzare un nuovo cloud privato virtuale (VPC)?
Puoi sfruttare il modello di Atlassian Standard Infrastructure (ASI) sia se desideri eseguire la distribuzione in un nuovo VPC o utilizzarne uno esistente.
- Ci sono principi di rete che vuoi modificare, come la limitazione dell'accesso pubblico a Internet e le impostazioni degli IP interni per l'instradamento delle reti VPN e aziendale?
- Devi usare i certificati TLS?
Geografia
-
Se utilizzi un VPC esistente, hai elaborato un piano per l'accesso alle reti VPN e aziendale?
Ti consigliamo di consentire l'accesso da tutti gli uffici e le VPN poiché è molto probabile che l'utilizzo del prodotto aumenti nel tempo.
Direct Connect
- Vuoi utilizzare Direct Connect per migliorare le prestazioni e la sicurezza?
- Quanti dati devi spostare dall'istanza Server a Data Center?
Se stai spostando grandi quantità di dati potresti prendere in considerazione la risorsa AWS Snow Family.
Continuità aziendale e ripristino di emergenza
Backup
Com'è strutturata la tua strategia di backup?
Ti consigliamo di utilizzare una combinazione della strategia di backup esistente e delle funzioni di backup integrate in AWS. Per maggiori informazioni, consulta:
AWS fornisce servizi di infrastruttura meno soggetti a singole interruzioni.
Failover regionale
Hai bisogno di implementare siti cold, warm e hot in diverse regioni?
In genere, le esigenze di ripristino di emergenza vengono soddisfatte facendo in modo che i servizi siano eseguiti su più zone di disponibilità, ma potresti voler ridurre anche le interruzioni regionali. Mentre decidi se vuoi implementare questi siti in diverse regioni, tieni a mente quanto segue:
- Costo dell'infrastruttura e del trasferimento dei dati
- Velocità di ripristino rispetto ad AWS
- Tempo impiegato per la manutenzione e la verifica del sito di ripristino
- Costo di gestione del sito
Upgrade a Data Center (senza clustering)
Se hai scelto un'architettura non cluster, puoi facilmente effettuare l'upgrade a Data Center.
Upgrade a Data Center (con clustering)
Se hai scelto di utilizzare un'architettura con clustering e hai approntato un piano, puoi procedere senza problemi.
Ottieni l'infrastruttura di cui hai bisogno per il tuo cluster
Per distribuire Data Center in un cluster, ti serviranno i componenti seguenti:
- Database
- Bilanciamento del carico
- Nodi applicativi
- File system condiviso
- Nodo Elasticsearch (Bitbucket)
Bilanciamento del carico
Il bilanciamento del carico è la prima cosa che le richieste dei tuoi utenti colpiscono se hai effettuato la distribuzione in un cluster. Le richieste, infatti, arrivano nel bilanciamento del carico, che le distribuisce ai nodi applicativi. Puoi usare un bilanciamento del carico basato su hardware o su software. Sia per le soluzioni hardware che per quelle software, il bilanciamento del carico deve essere collegato al cluster applicativo tramite una connessione LAN ad alta velocità per garantite una larghezza di banda elevata e una latenza ridotta. Tutti i bilanciamenti del carico software devono essere eseguiti su computer dedicati.
I prodotti Data Center presuppongono che la richiesta di ogni utente sia indirizzata allo stesso nodo nel corso di una sessione. Se le richieste vengono indirizzate a nodi diversi, gli utenti potrebbero essere disconnessi in maniera inaspettata rischiando persino di perdere le informazioni archiviate nella sessione. È quindi necessario vincolare una sessione allo stesso nodo abilitando le "sticky-session" basate su cookie (o l'affinità di sessione) nel bilanciamento del carico. Con le sticky session basate su cookie, puoi usare i cookie emessi dal prodotto o un cookie generato dal bilanciamento del carico.
Aggiungi un ulteriore livello di protezione e impedisci che il bilanciamento del carico diventi un singolo punto di guasto aggiungendo ridondanza alla tua soluzione di bilanciamento del carico. Puoi farlo configurando due bilanciamenti del carico in una configurazione attiva-passiva, usando un indirizzo IP virtuale su entrambi. Se il bilanciamento del carico attivo fallisce, passerà il task al bilanciamento del carico passivo.
Per maggiori informazioni, consulta le nostre opzioni di configurazione del bilanciamento del carico.
Nodi applicativi
I nodi applicativi sono il punto in cui risiede il prodotto effettivo. Ogni nodo nel cluster Data Center deve essere eseguito sulla stessa versione del prodotto ed essere posizionato nello stesso punto per minimizzare la latenza. Tuttavia, per supportare le prestazioni dei tuoi team distribuiti puoi abilitare una Content Delivery Network (CDN). Questi nodi devono essere configurati in un cluster, agendo all'unisono, affinché tu possa fornire il prodotto agli utenti. Il numero di nodi nel cluster dipende dalle tue esigenze e dalla modalità di configurazione del prodotto. Di norma, 2-4 nodi sono sufficienti per la maggior parte dei cluster, ma usa le nostre guide al dimensionamento dei nodi per aiutarti a prendere la decisione giusta.
Bitbucket richiede un nodo applicativo aggiuntivo appositamente dedicato su ElasticSearch, che abilita la ricerca di codice.
File system condiviso
Il file system condiviso è il luogo in cui vengono archiviati i dati che dovrebbero essere accessibili da qualsiasi nodo applicativo, come i file allegati e i repository Git.
In un ambiente Data Center devi configurare il file system condiviso come suo nodo. Puoi usare qualsiasi programma NAS o SAN basato to NFS per il tuo file system condiviso, ma per mantenere le prestazioni consigliamo NFS3. Assicurati di evitare protocolli distribuiti come DFS, che non sono supportati.
Crea un ambiente di staging
Per eseguire un aggiornamento di successo ad ambienti multinodo, ti consigliamo di creare un ambiente di staging che ti consenta di provare Data Center prima di distribuirlo nella produzione.
L'ambiente di staging deve replicare il più fedelmente possibile il tuo ambiente di produzione, inclusi eventuali proxy inversi, configurazioni SSL o bilanciamenti del carico. Potresti decidere di usare un server fisico diverso o una soluzione virtualizzata. In ogni caso, assicurati che si tratti di una replica appropriata del tuo ambiente di produzione.
Per istruzioni dettagliate, consulta:
Parla con un esperto
Hai una domanda sul tuo percorso di migrazione o sulle opzioni a tua disposizione? Ricevi i consigli di un esperto dal nostro team di specialisti.