Fattori relativi alle prestazioni e procedure consigliate per le migrazioni ibride
Esistono molti percorsi per eseguire la migrazione dei dati da un'organizzazione di posta elettronica locale a Microsoft 365 o Office 365. Quando si pianifica la migrazione, una domanda comune riguarda come migliorare le prestazioni della migrazione dei dati e ottimizzare la velocità di migrazione. Questo articolo illustra le prestazioni di migrazione per le distribuzioni ibride di Exchange. Per informazioni sulle prestazioni di altri metodi di migrazione, vedere Microsoft 365 e Office 365 le prestazioni e le procedure consigliate per la migrazione.
La migrazione della distribuzione ibrida supporta la migrazione senza problemi tra server Exchange locali e Exchange Online in Microsoft 365 o Office 365.
La migrazione della distribuzione ibrida è di gran lunga il metodo di migrazione più veloce per eseguire la migrazione dei dati delle cassette postali a Microsoft 365 o Office 365. Sono stati rilevati fino a 100 GB/ora di velocità effettiva durante le distribuzioni dei clienti reali. La tabella seguente fornisce un elenco di fattori che si applicano agli scenari di migrazione ibrida nativi di Microsoft 365 e Office 365.
Se l'ambiente locale contiene più siti in aree geograficamente distanti, è possibile migliorare le prestazioni di migrazione creando endpoint di migrazione geograficamente vicini. Infatti, in uno scenario simile la migrazione sfrutta la rete Microsoft anziché utilizzare un endpoint di migrazione centralizzato che usa la rete locale.
Fattore 1: origine dati (Exchange Server)
| Elenco di controllo | Descrizione | Procedure consigliate |
|---|---|---|
| Prestazioni del sistema | L'estrazione dei dati è un'attività intensiva. Il sistema di origine deve disporre di risorse sufficienti, ad esempio tempo cpu e memoria, per offrire prestazioni di migrazione migliori. Al momento della migrazione, il sistema di origine è in genere vicino alla capacità completa per gestire il normale carico di lavoro dell'utente finale. Un carico di lavoro di migrazione aggiuntivo a volte riduce anche l'accesso degli utenti finali a causa della mancanza di risorse di sistema. | Monitorare le prestazioni del sistema durante un test di migrazione pilota. Se il sistema è impegnato, evitare una pianificazione di migrazione aggressiva per il sistema in questione a causa di potenziali rallentamenti della migrazione e problemi di disponibilità dei servizi. Se possibile, migliorare le prestazioni del sistema di origine aggiungendo risorse hardware e riducendo il carico del sistema tramite lo spostamento di attività e utenti su altri server che non sono coinvolti nella migrazione. Per ulteriori informazioni, vedere: Chiedere Perf Guy: Sizing Exchange 2016 Deployments integrità e prestazioni Exchange Server Informazioni sulle prestazioni di Exchange 2010 Quando si esegue la migrazione da un'organizzazione di Exchange locale in cui sono presenti più server Cassette postali e più database, è consigliabile creare un elenco di utenti coinvolti nella migrazione che sia equamente distribuito tra più server Cassette postali e database. In base alle prestazioni dei singoli server, l'elenco può essere ulteriormente perfezionato per ottimizzare la velocità effettiva. Ad esempio, se il server A ha il 50% in più di disponibilità di risorse rispetto al server B, è ragionevole avere il 50% in più di utenti dal server A nello stesso batch di migrazione. Procedure analoghe possono essere applicate ad altri sistemi di origine. Eseguire le migrazioni quando la disponibilità di risorse nei server è massima, ad esempio dopo l'orario di lavoro oppure nei fine settimana e in giorni festivi. |
| Attività di back-end | Altre attività di back-end in esecuzione durante la migrazione. Poiché le procedure consigliate prevedono di eseguire la migrazione dopo l'orario di lavoro, non è raro che le migrazioni entrino in conflitto con altre attività di manutenzione eseguite nei server locali, come il backup dei dati. | Valutare altre attività di sistema che potrebbero essere eseguite durante la migrazione. È consigliabile eseguire la migrazione dei dati quando non sono in esecuzione altre attività a elevato utilizzo di risorse. Nota: per i clienti che usano Microsoft Exchange locale, le attività back-end comuni sono le soluzioni di backup e la manutenzione dell'archivio di Exchange . |
Fattore 2: server di migrazione
La migrazione i distribuzione ibrida è un metodo di migrazione con pull/push di dati avviato sul cloud e il server ibrido di Exchange funge da server di migrazione. Questa situazione è spesso sottovalutata e i clienti utilizzano una macchina virtuale su bassa scala come server ibrido. Ciò determina prestazioni di migrazione insoddisfacenti
Procedura consigliata per il server di migrazione
Oltre ad applicare le procedure consigliate descritte in precedenza, sono state sottoposte a test le seguenti procedure consigliate che hanno determinato un miglioramento delle prestazioni in scenari reali di migrazione dei clienti:
- Utilizzare potenti computer fisici di livello server anziché macchine virtuali per i server ibridi di Exchange.
- Utilizzare più server ibridi alle spalle del servizio di bilanciamento del carico di rete del cliente.
Ad esempio, in migrazioni di clienti reali è stata registrata una velocità effettiva costante di 30 GB/ora utilizzando la seguente configurazione:
- Rete: pipe in uscita da 500 mb verso Internet; rete interna su 1 GB con backbone in fibra da 10 GB.
- Hardware: le specifiche per i due server di accesso client/HUB (fisico) sono:
- CPU: CPU Intel® Xeon® E5520 da 2,27 GHz e 2,26 GHz (due processori).
- RAM: 24 GB.
- Dischi: otto a 146 GB per disco. Configurazione RAID 5 = spazio raw totale 960 GB.
- MRSProxy: configurato con una concorrenza pari a 100.
Fattore 3: modulo di migrazione
La migrazione della distribuzione ibrida usa microsoft 365 e strumenti di Office 365 nativi. È soggetto alla limitazione di Microsoft 365 e Office 365 servizio di migrazione.
Exchange 2003 e versioni successive di Exchange
Quando si esegue la migrazione da Exchange 2003, esiste una differenza sostanziale per l'esperienza dell'utente finale. A differenza delle ultime versioni di Exchange, gli utenti finali di Exchange 2003 non possono accedere alle cassette postali mentre è in corso la migrazione dei dati. Di conseguenza, i clienti che dispongono di Exchange 2003 sono in genere più preoccupati riguardo al momento in cui pianificare le migrazioni e al tempo necessario per completarle, in particolare quando le prestazioni di migrazione sono basse a causa di elevate dimensioni delle cassette postali o una rete lenta.
La migrazione da Exchange 2003 è anche soggetta a interruzioni. Ad esempio, in una migrazione reale del cliente, durante la migrazione di una cassetta postale da 10 GB, si è verificato un evento imprevisto del servizio quando la migrazione della cassetta postale è stata completata al 50%. È stato quindi necessario riavviare il server Accesso client di Office 365, che stava elaborando la migrazione dei dati, per risolvere il problema. In questo caso, è stato necessario riavviare la migrazione di tale cassetta postale, il che significa che il cliente ha dovuto eseguire nuovamente la migrazione di tutti i 10 GB di dati. Non è infatti stato possibile riprendere la migrazione dal punto in cui si era interrotta. Per Exchange 2010, e le ultime versioni di Exchange, è invece possibile riprendere le migrazioni in seguito alle interruzioni.
Procedura consigliata per il motore di migrazione
Alcuni clienti scelgono di eseguire migrazioni in due passaggi per le cassette postali più estese e importanti di Exchange 2003:
- Primo hop: eseguire la migrazione delle cassette postali da Exchange 2003 a un server Exchange 2010 o versione successiva, che in genere è il server ibrido. Il primo passaggio è uno spostamento offline, ma in genere si tratta di una migrazione molto veloce su una rete locale.
- Secondo hop: eseguire la migrazione delle cassette postali da Exchange 2010 o versione successiva a Microsoft 365 o Office 365.
Il secondo passaggio consiste in uno spostamento online, che garantisce un miglioramento dell'esperienza utente e della tolleranza d'errore. Questo approccio in due passaggi richiede una licenza di Exchange per la cassetta postale temporanea locale.
Proxy di servizio di replica delle cassette postali (MRSProxy)
MRS Proxy è la funzionalità di migrazione locale che funziona con il servizio di replica delle cassette postali in esecuzione sul lato Microsoft 365 e Office 365. Per ulteriori informazioni, vedere Informazioni sulle richieste di spostamento.
Procedura consigliata per MRSProxy
È possibile configurare il numero massimo di connessioni al proxy MRS per l'istanza locale del server ibrido di Exchange. Eseguire il comando di Windows PowerShell riportato di seguito.
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
Nota
Per la maggior parte delle migrazioni dei clienti non è necessario modificare il valore MRSMaxConnections predefinito. Se è necessario proteggere il server di origine affinché non venga sovraccaricato dalle operazioni di migrazione, i clienti possono ridurre il numero di connessioni. Questa impostazione è specifica per ogni server MRSProxy. Se un cliente dispone di due server MRSProxy, ognuno impostato su 10 connessioni, il numero totale di connessioni proxy MRS sarà 20 (2x10). Per ulteriori informazioni sulla configurazione del servizio proxy MRS nell'organizzazione di Exchange 2010 locale, vedere Avvio del servizio di MRSProxy su un server Accesso client remoto.
Fattore 4: rete
Test di verifica
Per i clienti di Exchange 2010 o versioni successive il testing delle prestazioni di rete per le migrazioni ibride può essere eseguito esaminando più migrazioni di cassette postali. In alternativa, è possibile eseguire la migrazione delle effettive cassette postali degli utenti con l'opzione -SuspendWhenReadyToComplete per ottenere un'indicazione delle prestazioni di migrazione. Al termine del test, rimuovere la richiesta di spostamento per evitare conseguenze per gli utenti finali.
Per ulteriori informazioni sulle richieste di spostamento, vedere New-MoveRequest.
Fattore 5: Servizio Office 365
Microsoft 365 e Office 365 limitazione basata sull'integrità delle risorse influisce sulle migrazioni che usano le migrazioni di distribuzione ibrida di Microsoft 365 o Office 365. Per altri dettagli, vedere la sezione Factor 3: Migration engine (Fattore 3: motore di migrazione ).