Nota: Questo articolo è una guida e non una procedura dettagliata. Si presuppone che tu abbia familiarità con l'amministrazione del sistema Linux® e con rsync utility. Non eseguire i comandi in questo articolo se non li conosci completamente. In tutti i casi, assicurati di aver eseguito il backup dei dati prima di seguire i passaggi di questa guida. Si applicano le tariffe standard per la larghezza di banda.
Questa guida ti aiuta a ridurre i tempi di migrazione del server. Se le applicazioni del tuo server corrispondono a una qualsiasi delle caratteristiche evidenziate in questo articolo, continua a leggere:questo articolo potrebbe rendere i tempi di rsync più brevi e più prevedibili per te. Mostra anche di ridurre i tempi di migrazione adottando azioni preventive prima di farlo.
Accelera il processo di rsync
Il volume di spazio su disco utilizzato su un server determina i tempi di rsync. Cioè, più dati da copiare, più tempo richiederà il lavoro. In genere, un rsync del sistema operativo vuoto richiede 10-15 minuti per essere completato. I seguenti casi d'uso del server possono estendere notevolmente il tempo di rsync:
- Server contenenti molti file di piccole dimensioni, come file di sessione Ruby, file di cache, file di messaggi del server di posta o miniature di immagini di server Web . La migrazione di tali dati tramite rsync richiede più tempo per il completamento di quanto ci si potrebbe aspettare. Ciò significa che una sincronizzazione iniziale richiede più tempo, ma un secondo passaggio in modalità di ripristino, con tempi di inattività associati, è più breve.
- Server contenenti più file aggiornati durante la rsync in tempo reale . In genere, si tratta di file di tabella MySQL® MyISAM o server Web che ospitano più domini, ciascuno configurato per accedere a file separati. La necessità di aggiornare questi file scritti attivamente dopo la copia rsync del primo passaggio estende il tempo di inattività da un riavvio al completamento di un secondo passaggio del processo rsync.
- Server contenenti uno o più file di grandi dimensioni aggiornati durante la migrazione . Gli esempi includono database MySQL che utilizzano il formato InnoDB, server di posta con registri di posta di grandi dimensioni e server Web che registrano file singoli e di grandi dimensioni. L'aggiornamento di questi file scritti attivamente con una seconda rsync dopo la copia di rsync del primo passaggio può estendere notevolmente i tempi di inattività associati.
Il segreto per ridurre i tempi di rsync è gestire i dati sul tuo server e identificare tutte le applicazioni che scrivono sul disco durante la migrazione in tempo reale.
Problema:sovraccarico di file di piccole dimensioni
Sebbene non occupino molto spazio su disco individuale, i server che ospitano molti file di piccole dimensioni forzano il processo di rsync a eseguire molti file-open , file-copy efile-check processi.
Ad esempio, un file di dati da un gigabyte richiede un insieme di processi di apertura, copia e controllo del file. Confrontalo con un blocco di dati di un gigabyte distribuito su 10.000 singoli file che richiede 10.000 singoli set di processi di file. Questo è molto più sovraccarico di sistema e di rete.
L'elenco seguente mostra le applicazioni che creano molti file di piccole dimensioni e hanno tempi di preparazione della migrazione più lunghi:
- Server web che servono molte piccole miniature o file di immagine
- Server di memorizzazione nella cache che memorizzano nella cache su disco file di piccole dimensioni
- Server di posta elettronica con archivi di grandi dimensioni di posta non eliminata
- Server Ruby o Rails, che tendono a creare più file di sessione di piccole dimensioni e non a eliminarli
- repository git
- Server di applicazioni personalizzate che creano ma non eliminano file di sessione per ciascun visitatore
Il problema con i file di piccole dimensioni rende la rsync meno prevedibile e richiede più tempo.
Come migrare
Controlla le tue applicazioni server rispetto all'elenco precedente. Se le tue applicazioni sono nell'elenco, fai il possibile per eliminare piccoli file indesiderati prima di eseguire l'effettivo rsync comando. Se stai utilizzando Ruby o Rails, supponi il peggio e cerca nei forum della community le posizioni tipiche dei file di cache e sessione, oltre a come identificare quali puoi eliminare in sicurezza. Considerare la memorizzazione dei dati di sessione in MySQL con il seguente comando:
rake db:sessions:create
Tronca i file di registro in log/ a zero byte con il seguente comando:
rake log:clear
Se stai eseguendo un server di memorizzazione nella cache che esegue la memorizzazione nella cache su disco anziché sulla RAM, identifica la sua directory di archiviazione file ed elimina in modo aggressivo. Controlla il tuo file system per sessioni di piccole dimensioni e file di cache creati da applicazioni personalizzate. Di nuovo, potare con vigore. Se stai migrando un server di posta elettronica con un Mail DeliveryAgent (MDA) come Dovecot installato, chiedi ai tuoi utenti di posta elettronica di pulire prima i loro archivi di posta elettronica di oldemail.
Problema:file in continuo cambiamento
È necessario copiare nuovamente i file che cambiano tra l'inizio e la fine di una rsync con un follow-up rsync per una migrazione completa del server. Questo processo estende il tempo di completamento della migrazione.
I server di database sono i colpevoli più frequenti che aggiornano file di dati di grandi dimensioni tra l'inizio e la fine di una migrazione. Queste modifiche impongono al sistema di copiare nuovamente l'intero file di database in un secondo processo di sincronizzazione che potresti eseguire durante una migrazione.
Alcune combinazioni di struttura e tipo di database tendono ad esacerbare questo tipo di problema. Ad esempio, supponiamo di avere un database MyISAM multi-tabella MySQL con molti file di tabella aggiornati all'interno di singole transazioni SQL. In tal caso, molti, se non tutti, i file di tabella potrebbero dover essere copiati di nuovo durante la seconda operazione di rsync in modalità di ripristino.
Dato che i file di database possono essere di grandi dimensioni, le implicazioni di questi aggiornamenti per i tempi di migrazione diventano chiare. È difficile prevedere con precisione quanto tempo potrebbe richiedere una rsync di migrazione. Dopo tutto, come possiamo prevedere quali e quanti aggiornamenti SQL si verificheranno tra l'inizio e la fine della migrazione?
Come migrare
Se il database contiene molti dati obsoleti, considerare l'archiviazione di tali dati e quindi eliminarli dal database live prima di migrare il server. MySQL, ad esempio, ti consente di archiviare i dati utilizzando mysqldump script, dopodiché puoi eliminare i dati obsoleti nel livedatabase. Il grande mysqldump il file di output contenente i dati obsoleti non si estende per una seconda rsync perché non sarà cambiato dal primo passaggio.
Un'altra opzione se hai applicazioni che scrivono su molti file durante il ridimensionamento è impostare l'applicazione in modalità di sola lettura immediatamente prima di eseguire rsync comando. Di solito è possibile impostare i database in modalità di sola lettura temporanea. Con altre applicazioni, il tuo chilometraggio potrebbe variare. Puoi anche impedire la scrittura su più file disattivando le applicazioni, ma l'impostazione delle applicazioni in modalità di sola lettura è in genere l'opzione preferita.
Problema:file di grandi dimensioni, in continuo aggiornamento
File molto grandi (10 GB o più) aggiornati durante una rsync pongono problemi simili per il tempo di migrazione a file più piccoli e costantemente aggiornati ma sotto steroidi. Se il tuo server ospita file su cui vengono scritti frequentemente, questa sezione è per te.
Un secondo rsync deve ricopiare completamente questi file di grandi dimensioni e costantemente aggiornati per acquisire tutti gli aggiornamenti effettuati dopo l'inizio di un processo di migrazione o ridimensionamento. Ciò estende notevolmente il tempo di migrazione a causa delle dimensioni di quella seconda copia di rsync.
I server di database MySQL che utilizzano il formato di file di dati InnoDB scrivono i dati in un unico file che diventa davvero molto grande. Allo stesso modo, MySQL in modalità InnoDB registra su un unico file di registro di grandi dimensioni.
Un aggiornamento di un file di registro o di dati MySQL InnoDB di grandi dimensioni, come /var/lib/mysql/ibdata1 , forza il processo di rsync a ricopiare l'intero file in un secondo passaggio. Se questi file sono di grandi dimensioni, la ricopia può richiedere del tempo, il che mantiene il database offline.
Un'altra fonte di file di grandi dimensioni sono i registri delle applicazioni, inclusi i registri prodotti dai server di posta e da alcuni server Web. Apache® può produrre file di registro di dimensioni pari o superiori a 16 Gb, quindi non è lecito ritenere che la registrazione predefinita di Apache ti aiuti a evitare questo problema di file di grandi dimensioni.
I registri delle transazioni MySQL possono anche aumentare di dimensioni se è stata attivata la registrazione delle transazioni. Le persone lo fanno raramente, ed è ancora più raro che attivino la registrazione delle transazioni senza esaurire lo spazio su disco in seguito. Tuttavia, è saggio tenere d'occhio questa possibilità.
Come migrare
Come descritto in precedenza, l'eliminazione dei database di cruft potrebbe aiutare a ridurre il tempo totale di rsync. Archivia ed elimina database vecchi o obsoleti prima di tentare una migrazione.
Anche in questo caso, la disattivazione delle scritture del database, se possibile, riduce i tempi di migrazione. Anche la disattivazione della registrazione può aiutare i database InnoDB.
Se hai attivato la registrazione delle transazioni MySQL e il file di registro delle transazioni è di grandi dimensioni, vale la pena disattivarlo, archiviarlo e quindi eliminarlo sulla slice prima di avviare una rsyncmigration.
Sui server di posta, controlla le dimensioni di /var/log/mail.log o /var/log/maillog prima della migrazione. Prendi in considerazione la possibilità di disattivare il server di posta prima della migrazione, soprattutto se disponi di un server di posta di backup per prelevare il carico.
Allo stesso modo, controlla come sta registrando Apache. Se sta registrando tutte le richieste in un file, controlla le dimensioni di quel file e considera l'archiviazione e l'eliminazione o la disattivazione di Apache prima di avviare il processo di migrazione. Lo stesso consiglio si applica a qualsiasi altra applicazione che sai sta scrivendo su un file di registro di grandi dimensioni.
Per queste applicazioni e per tutte le altre, controlla il tuo logrotate politica (se ne hai una) per verificare che mantenga un controllo sulle dimensioni del file di registro. Ciò consente di risparmiare tempo di inattività durante la migrazione e semplifica la vita con qualsiasi server Linux.
Prepara la tua borsa degli attrezzi
Naturalmente, è difficile tenere traccia dei file creati dopo aver configurato il server. Questo vale per le applicazioni che creano file di sessione. Conviene trovare ed eliminare queste grandi raccolte di piccoli file.
Puoi identificare le dieci directory e file più grandi emettendo il seguente comando come root :
du -a / | sort -n -r | head -n 10
Cambia quel 10 finale a qualsiasi altro numero per modificare il numero di file e directory restituiti dalla ricerca. Questo comando è un buon strumento di mezzo per identificare grandi directory di file piccoli e file di grandi dimensioni. Se vuoi cercare solo file di grandi dimensioni, prova questo cercatore di file di grandi dimensioni (come root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Se vuoi trovare solo directory di grandi dimensioni, prova questo cercatore di directory di grandi dimensioni (come root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Dati tecnici
Supponiamo che il tuo server non corrisponda a nessuno dei tipi comuni che abbiamo esaminato sopra. In tal caso, puoi valutare come potrebbe apparire il tempo di migrazione se consideri le tue applicazioni con una comprensione di come funziona il processo di migrazione (rsync).
La prima fase tipica di una migrazione è un live rsync, che è fondamentalmente una copia dell'intero file system del server. Tutte le applicazioni vengono lasciate in esecuzione durante questa fase.
È qui che la previsione del tempo di migrazione incontra la sua prima incertezza. Senza una conoscenza dettagliata del tuo utilizzo del file system del tuo server, non puoi prevedere con precisione per quanto tempo il file-copy la fase di una rsync richiederà il completamento.
Questa imprevedibilità è vera per la directory finale sui file system Linux:/var/ directory. Si chiama var perché la dimensione dei dati che contiene è variabile e cambia mentre le applicazioni del server sono in esecuzione.
La seconda incertezza è che la fase finale di una migrazione include un componente della modalità di salvataggio (tempo di inattività). Durante questa fase, il processo copia nuovamente i file aggiornati dopo l'inizio della fase live rsyncfirst. La durata del tempo di inattività dipende dalla dimensione e dal numero di file aggiornati. Anche in questo caso, il processo rsync non può dire in anticipo quanti aggiornamenti le applicazioni come MySQL stanno scrivendo su file di dati, quindi è difficile prevedere la durata di questo salvataggio finale- modalità di sincronizzazione copia.
Le informazioni precedenti si applicano a un tipico processo di migrazione manuale. Il nostro Cloud cambia il processo di ridimensionamento per far scendere il server per una singola rsync, aumentando i tempi di inattività e aumentando l'affidabilità della sincronizzazione.
Riepilogo
Se sai in che modo le tue applicazioni utilizzano lo spazio su disco e scrivono sui file, potresti essere in grado di giudicare se una migrazione richiederà più tempo del previsto e fare i preparativi di conseguenza. Come minimo, puoi utilizzare le tue nuove conoscenze sulla migrazione per pianificare meglio la migrazione in modo che soddisfi i tuoi requisiti di tempistica.
Utilizza la scheda Feedback per inserire commenti o porre domande. Puoi anche iniziare una conversazione con noi.