Prestazioni e procedure consigliate per la migrazione a Office 365

Sono disponibili diversi percorsi per eseguire la migrazione dei dati da un'organizzazione di posta elettronica locale a Microsoft Office 365. Quando si pianifica una migrazione a Office 365, spesso ci si chiede come migliorare le prestazioni e ottimizzare la velocità della procedura.

Nota : Le informazioni sulle prestazioni riportate in questo articolo non si applicano al servizio Office 365 per i piani di abbonamento dedicati. Per altre informazioni sui piani dedicati, vedere Descrizione dei servizi dei piani dedicati di Office 365.

In questo argomento

Panoramica della migrazione della posta elettronica a Office 365

Office 365 supporta diversi metodi per eseguire la migrazione di posta elettronica, calendario e contatti dall'attuale ambiente di messaggistica a Office 365, come descritto in Modalità di migrazione di più account di posta elettronica a Office 365.

Per altre informazioni sulle funzionalità di rete e le prestazioni di Office 365, vedere Pianificazione della rete e ottimizzazione delle prestazioni per Office 365.

Metodi di migrazione usati di frequente

Metodo di migrazione

Descrizione

Risorse

Migrazione IMAP (Internet Message Access Protocol)

È possibile usare l'Interfaccia di amministrazione di Exchange o Exchange Management Shell per eseguire la migrazione del contenuto delle cassette postali degli utenti da un sistema di messaggistica IMAP alle cassette postali di Office 365, nonché la migrazione delle cassette postali da altri servizi di posta elettronica ospitata, come Gmail o Yahoo Mail.

Eseguire la migrazione di cassette postali IMAP in Office 365

Migrazione completa

Con la migrazione completa, tutte le cassette postali locali vengono trasferite in Office 365 nel giro di alcuni giorni. Usare questo tipo di migrazione se si prevede di spostare l'intera organizzazione di posta elettronica in Office 365 e di gestire gli account utente in Office 365. Con una migrazione completa, è possibile eseguire la migrazione di un massimo di 2.000 cassette postali dall'organizzazione di Exchange locale a Office 365. Il numero consigliato è tuttavia 150   . Con un numero più elevato possono infatti verificarsi effetti negativi sulle prestazioni. Viene eseguita la migrazione anche dei contatti di posta e dei gruppi di distribuzione dell'organizzazione di Exchange locale.

Migrazione completa a Office 365

Migrazione a fasi

Usare una migrazione a fasi se si prevede di trasferire alla fine tutte le cassette postali dell'organizzazione in Office 365. Con questo tipo di migrazione si spostano batch di cassette postali locali in Office 365 nel corso di alcune settimane o mesi.

Informazioni utili su una migrazione a fasi della posta elettronica a Office 365

Distribuzione ibrida

La distribuzione ibrida offre alle organizzazioni la possibilità di estendere nel cloud l'esperienza completa e il controllo amministrativo che attualmente hanno sulle organizzazioni di Exchange locali. Una distribuzione ibrida fornisce l'aspetto uniforme di una singola organizzazione di Exchange tra Exchange Server 2013 o Microsoft Exchange Server 2010 locale e Office 365. Inoltre, può fungere da passaggio intermedio del trasferimento completo a un'organizzazione di Office 365.

Distribuzioni ibride di Exchange Server 2013

Migrazione di terze parti

Sono disponibili numerosi strumenti di terze parti, che si basano su protocolli e approcci distinti per eseguire la migrazione della posta elettronica da piattaforme come IBM Lotus Notes e Novell GroupWise.

Ecco alcuni strumenti di migrazione e partner di terze parti che possono risultare utili per la migrazione di Exchange da piattaforme non Microsoft:

  • Binary Tree   Provider di software di coesistenza e migrazione della messaggistica multipiattaforma, con prodotti che forniscono l'analisi, la coesistenza e la migrazione tra ambienti aziendali di messaggistica e collaborazione online e locali basati su IBM Lotus Notes e Domino e Exchange e SharePoint.

  • BitTitan   Provider di soluzioni di migrazione a Office 365.

  • Dell   Provider di software di coesistenza e migrazione locale e ospitata, con analisi pre-migrazione e coesistenza completa di utenti e applicazioni. Fornisce migrazioni complete da ambienti locali di Exchange, IBM Domino, Novell GroupWise, Zimbra e altri a Office 365 e SharePoint Online.

  • BitTitan   Provider di soluzioni di migrazione a Office 365 e SharePoint Online.

  • SkyKick Provider di soluzioni automatizzate di migrazione per spostare ambienti locali di Exchange, Gmail, POP3, IMAP e Lotus Notes a Office 365. Gli strumenti di migrazione completi aiutano i partner nelle fasi di vendita, pianificazione, migrazione, gestione e operazioni in sede del progetto di migrazione.

  • TransVault   Provider di soluzioni di migrazione a Office 365.

Prestazioni dei metodi di migrazione

La tabella seguente confronta i risultati osservati delle prestazioni per i diversi metodi di migrazione di cassette postali e relativi dati con Office 365. Questi risultati sono basati su test interni e migrazioni effettive eseguite dai clienti a Office 365.

Nota : A causa delle differenze con cui vengono eseguite le migrazioni e del momento in cui si svolgono, la velocità effettiva della migrazione può essere più o meno elevata.

Metodo di migrazione

Limitazione degli utenti di Office 365

Limitazione del servizio di migrazione a Office 365

Limitazione basata sull'integrità delle risorse di Office 365

Velocità effettiva media osservata per ora e per client (se applicabile)

Migrazione IMAP

No

10-14 gigabyte (GB) (20 simultanee)

Migrazione completa

No

10-14 GB (20 simultanee)

Migrazione a fasi

No

10-14 GB (20 simultanee)

Migrazione ibrida

No

10-14 GB per Exchange 2013 locale o 2010 CAS (servizio di replica delle cassette postali di Microsoft Exchange, servizio MRSProxy) con 20 spostamenti simultanei1

Migrazione MAPI di terze parti

No

4-12 GB (20 simultanee) 2

Migrazione di Servizi Web Exchange di terze parti

No

5-10 GB (20 simultanee) 3

Caricamento client (da file PST di Outlook)

No

0,5 GB

1La velocità effettiva osservata dello spostamento di una singola cassetta postale rientra nell'intervallo 0,3-1,0 GB/ora. Una velocità effettiva maggiore di 1000 MB/h per cassetta postale può essere raggiunta con una rete in grado di sostenere meno del 2% di tempo di stallo dovuto a errori temporanei e meno di 100 ms di latenza della rete. Per ottenere velocità di migrazione dei dati più elevate, è possibile eseguire più migrazioni simultanee delle cassette postali. La velocità effettiva dello spostamento di singole cassette postali rallenta quando il server CAS (servizio MRSProxy) locale raggiunge il massimo di capacità hardware, se la larghezza di banda non è sufficiente oppure se la latenza di rete è troppo elevata. Per aumentare la velocità della migrazione, è consigliabile aggiungere altri server o migliorare temporaneamente la connettività di rete.

2La velocità effettiva osservata della migrazione MAPI rientra nell'intervallo 0,1-0,5 - 1,0 GB/ora. Per ottenere velocità di migrazione dei dati più elevate, è possibile eseguire più migrazioni simultanee. La velocità effettiva di singole migrazioni MAPI rallenta quando i server locali o la rete raggiungono il massimo della capacità.

3La velocità effettiva osservata della migrazione di Servizi Web Exchange rientra nell'intervallo 0,2-0,5 GB/ora. Per ottenere velocità di migrazione dei dati più elevate, è possibile eseguire più migrazioni simultanee. Ad esempio, con venti migrazioni simultanee la velocità effettiva complessiva rientrerà nell'intervallo 4-10 GB/ora. La velocità effettiva di singole migrazioni di Servizi Web Exchange rallenta quando i server locali o la rete raggiungono il massimo della capacità.

Fattori che influiscono sulle prestazioni della migrazione

Diversi fattori comuni possono influire sulle prestazioni della migrazione della posta elettronica.

Fattori comuni che influiscono sulle prestazioni della migrazione

La tabella seguente contiene un elenco dei fattori comuni che influiscono sulle prestazioni della migrazione. Altri dettagli sono riportati nelle sezioni che descrivono i singoli metodi di migrazione.

Fattore

Descrizione

Esempio

Origine dati

Il dispositivo o il servizio che ospita i dati di cui eseguire la migrazione. Alle origini dati potrebbero applicarsi diverse limitazioni, a causa di specifiche hardware, carico di lavoro degli utenti finali e attività di manutenzione del back-end.

Gmail limita la quantità di dati che è possibile estrarre in uno specifico periodo di tempo.

Tipo e densità dei dati

Considerando la natura particolare del business dei clienti, il tipo e la combinazione degli elementi contenuti nelle cassette postali sono estremamente variabili.

La migrazione di un'unica cassetta postale di 4 GB con 400 elementi, ognuno con circa 10 magabyte (MB) di allegati, viene eseguita più velocemente di quella di una cassetta di 4 GB con 100.000 elementi più piccoli.

Server di migrazione

In molte soluzioni di migrazione si usa una workstation o un server specifico, di tipo "jump box", per completare la procedura.

I clienti usano spesso una macchina virtuale a basse prestazioni per ospitare il servizio MRSProxy per le distribuzioni ibride o per le migrazioni non ibride di PC client.

Motore di migrazione

Il motore di migrazione dei dati che recupera i dati dal server di origine, se necessario, converte i dati. Li trasmette quindi tramite la rete e li inserisce nella cassetta postale di Office 365.

Il servizio MRSProxy prevede funzionalità e limitazioni specifiche.

Appliance di rete locali

Le prestazioni di rete end-to-end, ossia dall'orgine dati ai server Accesso client di Exchange Online, influiscono sulle prestazioni della migrazione.

Configurazione e specifiche del firewall nell'organizzazione locale.

Servizio Office 365

Office 365 include il supporto e funzionalità incorporate per gestire il carico di lavoro della migrazione.

I criteri di limitazione degli utenti includono impostazioni predefinite e limitano la velocità massima complessiva di trasferimento dei dati.

Fattori che influiscono sulle prestazioni di rete

Questa sezione descrive le procedure consigliate per migliorare le prestazioni di rete durante la migrazione. La discussione è generica, perché l'impatto maggiore sulle prestazioni di rete durante la migrazione riguarda l'hardware di terze parti e i provider di servizi Internet (ISP).

Usare l'analizzatore di Exchange per acquisire informazioni più approfondite sulla connettività di rete con Office 365. Per eseguire i test dell'analizzatore di Exchange in Assistente supporto e ripristino, passare a Diagnostica avanzata > Exchange Online > Verificare la connettività di rete di Exchange Online > Sì. Per altre informazioni sull'Assistente supporto e ripristino, vedere Risolvere i problemi di Outlook e Office 365 con l'Assistente supporto e ripristino per Office 365.

Fattore

Descrizione

Procedure consigliate

Capacità della rete

La quantità di tempo necessaria per eseguire la migrazione delle cassette postali a Office 365 dipende dalla capacità disponibile e massima della rete.

  • Identificare la capacità di rete disponibile e determinare quella massima di caricamento.

  • Contattare l'ISP per verificare la larghezza di banda assegnata e ottenere informazioni sulle restrizioni, ad esempio la quantità totale di dati che è possibile trasferire in uno specifico periodo di tempo.

  • Usare gli strumenti per valutare la capacità di rete effettiva. Assicurarsi di testare il flusso end-to-end dei dati dalle origini dati locali ai server gateway dei data center Microsoft.

  • Identificare altri carichi imposti alla rete, ad esempio le utilità di backup e la manutenzione pianificata, che possono influire sulla capacità della rete.

Stabilità della rete

Una rete veloce non sempre implica migrazioni veloci. Se la rete non è stabile, il trasferimento dei dati richiede più tempo a causa della correzione degli errori. In base al tipo di migrazione, la correzione degli errori può influire in modo significativo sulle prestazioni.

I problemi dell'hardware e dei driver di rete spesso causano problemi di stabilità. Collaborare con i fornitori dell'hardware per ottenere informazioni accurate sui dispositivi di rete e applicare le versioni più recenti dei driver e gli aggiornamenti software consigliati.

Ritardi della rete

Le funzionalità di rilevamento delle intrusioni configurate in un firewall di rete spesso causano ritardi significativi e possono influire sulle prestazioni della migrazione.

La migrazione di dati alle cassette postali di Office 365 si basa sulla connessione Internet. I ritardi di Internet influiscono sulle prestazioni complessive della migrazione.

Inoltre, gli utenti della stessa società potrebbero avere cassette postali sul cloud che risiedono in data center ubicati in aree geografiche diverse. Le prestazioni della migrazione possono variare in base all'ISP del cliente.

  • Valutare i ritardi della rete con tutti i possibili data center Microsoft per assicurarsi che il risultato sia uniforme. In questo modo è anche possibile fornire un'esperienza coerente agli utenti finali. Collaborare con l'ISP per affrontare i problemi legati a Internet.

  • Aggiungere gli indirizzi IP dei server dei data center Microsoft all'elenco di mittenti consentiti oppure bypassare tutto il traffico legato alla migrazione dal firewall di rete. Per altre informazioni sugli indirizzi IP di Office 365, vedere URL e intervalli di indirizzi IP per Office 365.

Per un'analisi più approfondita delle migrazioni all'interno dell'ambiente, consultare il post di blog sull'analisi degli spostamenti. Il post include uno script per analizzare le richieste di spostamento.

Limitazione di Office 365

Office 365 usa vari meccanismi di limitazione per garantire sicurezza e disponibilità del servizio. I tre tipi seguenti di limitazione possono influire sulle prestazioni della migrazione:

  • Limitazione degli utenti

  • Limitazione del servizio di migrazione

  • Limitazione basata sull'integrità delle risorse

Nota : I tre tipi di limitazione di Office 365 non influiscono su tutti i metodi di migrazione.

Limitazione degli utenti di Office 365

La limitazione degli utenti influisce sulla maggior parte degli strumenti di migrazione di terze parti e sul metodo di migrazione con caricamento del client. Questi metodi di migrazione usano protocolli di accesso client, come il protocollo RPC (Remote Procedure Call) su HTTP per la migrazione dei dati alle cassette postali di Office 365. Si tratta di strumenti usati per eseguire la migrazione dei dati da piattaforme come IBM Lotus Domino e Novell GroupWise.

La limitazione degli utenti è il metodo più restrittivo di Office 365. Poiché viene configurata per funzionare rispetto a un singolo utente finale, ogni utilizzo a livello di applicazione supererà facilmente i criteri di limitazione, rallentando la migrazione dei dati.

Limitazione del servizio di migrazione a Office 365

La limitazione del servizio di migrazione influisce su tutti gli strumenti di migrazione a Office 365. Gestisce la simultaneità della migrazione e l'assegnazione di risorse per le soluzioni di migrazione a Office 365.

La limitazione del servizio di migrazione influisce sulle migrazioni eseguite con i metodi seguenti:

  • Migrazione IMAP

  • Migrazione completa di Exchange

  • Migrazione a fasi di Exchange

  • Migrazioni ibride (spostamenti basati sul servizio MRSProxy in ambienti ibridi)

Un esempio di limitazione del servizio di migrazione consiste nel controllare il numero di cassette postali trasferite simultaneamente durante le migrazioni semplici di Exchange e le migrazioni IMAP. Il valore predefinito è 10. Questo significa che in un determinato momento viene eseguita la migrazione di un massimo di 10 cassette postali da tutti i batch di migrazione. È possibile aumentare il numero di migrazioni simultanee delle cassette postali per un batch di migrazione nel Pannello di controllo di Exchange o in Windows PowerShell. Per altre informazioni su come ottimizzare questa impostazione, vedere Gestire i batch di migrazione in Office 365.

Limitazione basata sull'integrità delle risorse di Office 365

Tutti i metodi di migrazione sono soggetti alla governance della limitazione di disponibilità. La limitazione del servizio Office 365, tuttavia, non influisce sulle migrazioni a Office 365 quanto gli altri tipi descritti in precedenza.

La limitazione basata sull'integrità delle risorse rappresenta il metodo di limitazione meno aggressivo. Si verifica quando c'è un problema di disponibilità del servizio che potrebbe influire sugli utenti finali e su operazioni strategiche.

Prima che le prestazioni del servizio peggiorino al punto da influire negativamente sulle prestazioni degli utenti finali, la migrazione ibrida verrà bloccata finché le prestazioni non vengono ripristinate e il servizio non torna a un livello inferiore alla soglia di limitazione.

Gli esempi seguenti sono tratti da un report di statistiche su una migrazione di Exchange. Mostrano le voci aggiunte quando la soglia di limitazione viene superata.

  • 25/01/2012 12:56:01 [BL2PRD0410CA012] Stato copia: 723/1456 messaggi, 225,8 MB (236.732.045 byte)/416,5 MB (436.712.733 byte).

    25/01/2012 12:57:53 [BL2PRD0410CA012] Lo spostamento relativo alla cassetta postale '/o=ExchangeLabs/ou=Gruppo amministrativo di Exchange (FYDIBOHF23SPDLT)/cn=Destinatari/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' è bloccato, in quanto la condizione DataMoveReplicationConstraint non è soddisfatta del database 'NAMPRD04DG031-db081' (agente MailboxDatabaseReplication). Motivo dell'errore: Il database edbf0766-1f2a-4552-9115-bb3a53a8380b non soddisfa il vincolo SecondDatacenter. Non sono disponibili copie integre del database. Si attenderà fino al 25/01/2012 1:27:53.

    25/01/2012 12:58:24 [BL2PRD0410CA012] La richiesta non è più bloccata e continuerà.

    30/06/2017 00:03:58 [CY4PR19MB0056] Interruzione del processo a causa di notevoli ritardi dovuti allo stato non integro del server o a limitazioni nel budget con uno stato di limitazione della richiesta 'StalledDueToTarget_DiskLatency'.

Soluzione e procedura   

Se si verifica una condizione simile, attendere il ripristino del servizio Office 365. Per altre informazioni, vedere la sezione Integrità dei servizi nel portale di Office 365.

Fattori che influiscono sulle prestazioni e procedure consigliate per le migrazioni di distribuzioni non ibride

Questa sezione descrive i fattori che influiscono sulle migrazioni IMAP, complete o a fasi. Identifica inoltre le procedure consigliate per migliorare le prestazioni.

Fattore 1: origine dati

La tabella seguente descrive l'impatto dei server di origine sulla migrazione nell'organizzazione di posta elettronica corrente e le procedure consigliate per alleviarlo.

Elenco di controllo

Descrizione

Procedure consigliate

Prestazioni di sistema

L'estrazione dei dati è un'attività intensiva. Il sistema di origine deve avere risorse sufficienti, ad esempio tempo della CPU e memoria, per offrire prestazioni ottimali della migrazione. Durante la migrazione, il sistema di origine si avvicina spesso alla piena capacità in termini del normale carico di lavoro degli utenti finali. Se le risorse di sistema sono inadeguate, il carico di lavoro aggiuntivo risultante dalla migrazione può influire sugli utenti finali.

Monitorare le prestazioni di sistema durante un test di migrazione pilota. Se il sistema è occupato, è consigliabile evitare una pianificazione aggressiva della migrazione per il sistema specifico, perché si potrebbero verificare problemi di lentezza della migrazione e di disponibilità del servizio. Se possibile, migliorare le prestazioni del sistema di origine aggiungendo risorse hardware e ridurre il carico sul sistema spostando attività e utenti in altri servizi non coinvolti nella migrazione.

Per maggiori informazioni, vedere:

Quando si esegue la migrazione da un'organizzazione locale di Exchange che comprende più server delle cassette postali, è consigliabile creare un elenco degli utenti della migrazione equamente distribuiti tra più server. In base alle prestazioni dei singoli server, l'elenco può essere ulteriormente perfezionato per massimizzare la velocità effettiva.

Se ad esempio il server A ha il 50% di disponibilità di risorse in più rispetto al server B, è ragionevole avere il 50% di utenti in più del server A nello stesso batch di migrazione. Procedure analoghe possono essere applicate ad altri sistemi di origine. Eseguire le migrazioni quando i server hanno la massima disponibilità di risorse, ad esempio fuori orario oppure nei weekend o durante le festività.

Attività di back-end

Altre attività di back-end in esecuzione durante la migrazione. Poiché è consigliabile eseguire la migrazione al di fuori degli orari di lavoro, in genere le migrazioni entrano in conflitto con le attività di manutenzione, ad esempio il backup dei dati, eseguite nei server locali.

Esaminare altre attività di sistema che potrebbero essere eseguite durante la migrazione. È consigliabile eseguire la migrazione dei dati mentre non sono in esecuzione altre attività a uso intensivo delle risorse.

Nota      Per i clienti che usano Exchange locale, le comuni attività di back-end sono le soluzioni di backup e la manutenzione dell'archivio di Exchange.

Criteri di limitazione

È pratica comune proteggere i sistemi di posta elettronica con criteri di limitazione che impostano un limite specifico sulla velocità e sulla quantità di dati che è possibile estrarre dal sistema durante un determinato periodo di tempo.

Verificare quali criteri di limitazione sono applicati al sistema di posta elettronica. Ad esempio, Google Mail limita la quantità di dati che è possibile estrarre in un determinato periodo di tempo.

In base alla versione, Exchange include criteri che limitano l'accesso IMAP al server della posta locale (usato dalle migrazioni IMAP) e l'accesso al protocollo RPC su HTTP (usato dalle migrazioni complete di Exchange e dalle migrazioni a fasi di Exchange).

Per verificare le impostazioni di limitazione in un'organizzazione di Exchange 2013, eseguire il cmdlet Get-ThrottlingPolicy. Per altre informazioni, vedere Gestione del carico di lavoro di Exchange.

Per altre informazioni sulla limitazione di IMAP, vedere Eseguire la migrazione di cassette postali IMAP a Office 365

Per altre informazioni sulla limitazione del protocollo RPC su HTTP, vedere:

Fattore 2: server di migrazione

Le migrazioni IMAP, complete e a fasi sono metodi di migrazione con pull dei dati avviate sul cloud, quindi non è necessario avere un server dedicato. Gli host di protocolli Internet (IMAP o RPC su HTTP), tuttavia, fungono da server di migrazione per trasferire cassette postali e relativi dati in Office 365. Di conseguenza, i fattori che influiscono sulle prestazioni e le procedure consigliate, descritti nella sezione precedente sul server di origine dati per l'organizzazione della posta elettronica corrente, si applicano anche ai server perimetrali Internet. Per le organizzazioni di Exchange 2007, Exchange Server 2010 e Exchange 2013, il server Accesso client funge da server di migrazione.

Per maggiori informazioni, vedere:

Fattore 3: motore di migrazione

Le migrazioni IMAP, complete e a fasi di Exchange vengono eseguite con il dashboard Migrazione dell'Interfaccia di amministrazione di Exchange, che è soggetto alla limitazione del servizio di migrazione di Office 365.

Soluzione e procedura   

I clienti ora possono specificare la simultaneità delle migrazioni, ad esempio il numero di cassette postali da trasferire simultaneamente, usando Windows PowerShell. Il valore predefinito è 20 cassette postali. Dopo aver creato un batch di migrazione, è possibile usare il cmdlet di Windows PowerShell seguente per aumentare questo valore fino a un massimo di 100.

Set-MigrationEndPoint <Identity> –MaxConcurrentMigrations <value between 1 and 100>

Per altre informazioni, vedere Gestire i batch di migrazione in Office 365.

Nota : Se l'origine dati non ha risorse sufficienti per gestire tutte le connessioni, è consigliabile evitare una simultaneità elevata. Iniziare con un valore ridotto, ad esempio 10. Aumentare questo numero monitorando le prestazioni dell'origine dati per evitare problemi di accesso per gli utenti finali.

Fattore 4: rete

Test di verifica   

In base al metodo di migrazione, è possibile provare i test di verifica seguenti:

  • Migrazioni IMAP      Prepopolare una cassetta postale di origine con dati di esempio. Quindi da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine con un client di posta elettronica IMAP standard, ad esempio Microsoft Outlook, e misurare le prestazioni di rete determinando quanto tempo richiede il download di tutti i dati dalla cassetta postale di origine. La velocità effettiva dovrebbe essere simile a quella che si ottiene usando lo strumento di migrazione IMAP in Office 365, purché non siano presenti altri vincoli.

  • Migrazioni di Exchange complete e a fasi      Prepopolare una cassetta postale di origine con dati di esempio. Quindi da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine con Outlook usando il protocollo RPC su HTTP. Assicurarsi di connettersi usando la modalità cache. Misurare le prestazioni di rete controllando quanto tempo richiede la sincronizzazione di tutti i dati della cassetta postale di origine. La velocità effettiva dovrebbe essere simile a quella che si ottiene usando i semplici strumenti di migrazione di Exchange in Office 365, purché non siano presenti altri vincoli.

Nota : Durante una migrazione IMAP, completa o a fasi di Exchange si potrebbe verificare un sovraccarico. La velocità effettiva, tuttavia, dovrebbe essere simile a quella dei risultati di questi test di verifica.

Fattore 5: servizio Office 365

La limitazione basata sull'integrità delle risorse di Office 365 influisce sulle migrazioni eseguite con i semplici strumenti di migrazione nativi di Office 365. Vedere la sezione Limitazione basata sull'integrità delle risorse di Office 365.

Richieste di spostamento nel servizio Office 365

Per informazioni generali su come ottenere dati sullo stato per le richieste di spostamento, vedere Visualizzare altre proprietà delle richieste.

Nel servizio Office 365, a differenza di Exchange Server 2010 locale, la coda di migrazione e le risorse del servizio assegnate alle migrazioni sono condivise tra tenant. La condivisione influisce sul modo in cui vengono gestite le richieste di spostamento in ogni fase del processo.

Ci sono due tipi di richieste di spostamento in Office 365:

  • Richieste di spostamento onboarding      Le migrazioni di nuovi clienti. Queste richieste hanno una priorità standard.

  • Richieste di spostamento all'interno del data center      Le richieste di spostamento delle cassette postali avviate dai team di operazioni del data center. Queste richieste hanno una priorità più bassa, perché l'esperienza degli utenti finali non ne risente qualora vengano ritardate.

Possibile impatto dei ritardi delle richieste di spostamento con stato "in coda" e "in corso"

  • Richieste di spostamento in coda      Questo stato specifica che lo spostamento è stato accodato ed è in attesa di essere gestito dal servizio di replica delle cassette postali di Exchange. Per le richieste di spostamento di Exchange 2003, gli utenti possono comunque accedere alle loro cassette postali in questa fase.

    Due fattori influiscono sulla richiesta che verrà gestita dal servizio di replica delle cassette postali:

    • Priorità      Le richieste di spostamento in coda con una priorità più alta vengono gestite prima di quelle con priorità bassa. In questo modo ci si assicura che le richieste di spostamento delle migrazioni dei clienti vengano sempre elaborate prima di quelle interne al data center.

    • Posizione nella coda      Se le richieste di spostamento hanno la stessa priorità, quanto prima entrano nella coda tanto prima verranno gestite dal servizio di replica delle cassette postali. Poiché potrebbero esserci più clienti che eseguono le migrazioni delle cassette postali contemporaneamente, è normale che le nuove richieste di spostamento rimangano nella coda prima di essere elaborate.

      Spesso il tempo di attesa nella coda prima che le richieste di cassette postali vengano elaborate non viene considerato durante la pianificazione della migrazione. Il risultato è che ai clienti non viene assegnato un tempo sufficiente per completare tutte le migrazioni pianificate.

  • Richieste di spostamento in corso      Questo stato specifica che lo spostamento è ancora in corso. Se si tratta di uno spostamento di cassette postali online, l'utente avrà comunque la possibilità di accedervi. Per gli spostamenti offline, invece, le cassette postali degli utenti non saranno disponibili.

    Quando la richiesta di spostamento delle cassette postali ha lo stato "in corso", la priorità non ha più importanza e le nuove richieste di spostamento verranno elaborate solo dopo il completamento di quelle attualmente in corso, anche se la nuova richiesta ha una priorità più alta.

Procedure consigliate

Pianificazione      Come accennato in precedenza, poiché gli utenti di Exchange 2003 perdono l'accesso durante una migrazione ibrida, i clienti di Exchange 2003 devono valutare con più attenzione quando pianificare le migrazioni e quanto tempo richiederanno.

Quando si pianifica il numero di cassette postali di cui eseguire la migrazione durante uno specifico periodo di tempo, considerare quanto segue:

  • Includere la quantità di tempo in cui la richiesta di spostamento sarà in attesa nella coda. Per calcolarlo, usare la formula seguente:

    (numero totale di cassette postali da spostare) = ((tempo totale) – (tempo medio in coda)) * (velocità effettiva della migrazione)

    dove la velocità effettiva della migrazione equivale al numero totale di cassette postali che è possibile spostare ogni ora.

    Si supponga ad esempio di avere una finestra temporale di sei ore per eseguire la migrazione delle cassette postali. Se il tempo medio in coda è di un'ora e la velocità effettiva della migrazione è di 100 cassette postali all'ora, nel periodo di tempo di sei ore è possibile spostare 500 cassette postali: 500 = (6 – 1) * 100.

  • Avviare la migrazione prima di quanto inizialmente pianificato per tenere conto del tempo in coda. Quando le cassette postali sono in coda, gli utenti di Exchange 2003 possono comunque accedere alle loro cassette postali.

Determinare il tempo in coda      Il tempo in coda cambia continuamente, perché Microsoft non gestisce le pianificazioni delle migrazioni dei clienti.

Per determinare il potenziale tempo in coda, è possibile provare a pianificare uno spostamento di test diverse ore prima dell'avvio della migrazione effettiva. Quindi, in base alla quantità di tempo osservata durante il quale la richiesta rimane in coda, è possibile stimare in modo più accurato quando iniziare la migrazione e quante cassette postali è possibile spostare in uno specifico periodo.

Se ad esempio una migrazione di test viene completata quattro ore prima dell'avvio di una migrazione pianificata, è possibile determinare che il tempo in coda della migrazione di test è di circa un'ora. Quindi, è consigliabile avviare la migrazione un'ora prima di quanto originariamente pianificato per assicurarsi il tempo sufficiente per completare tutte le migrazioni.

Strumenti di terze parti per le migrazioni a Office 365

Gli strumenti di terze parti vengono usati prevalentemente in scenari di migrazione che non includono Exchange, ad esempio quelle da Google Mail, IBM Lotus, Domino e Novell GroupWise. Questa sezione riguarda principalmente i protocolli di migrazione usati da strumenti di terze parti, piuttosto che i prodotti e gli strumenti specifici. La tabella seguente include un elenco dei fattori applicabili agli strumenti di terze parti per gli scenari di migrazione a Office 365.

Fattore 1: origine dati

Elenco di controllo

Descrizione

Procedure consigliate

Prestazioni di sistema

L'estrazione dei dati è un'attività intensiva. Il sistema di origine deve avere risorse sufficienti, ad esempio tempo della CPU e memoria, per offrire prestazioni ottimali della migrazione. Durante la migrazione, il sistema di origine si avvicina spesso alla piena capacità in termini del normale carico di lavoro degli utenti finali. Se le risorse di sistema sono inadeguate, il carico di lavoro aggiuntivo risultante dalla migrazione può influire sugli utenti finali.

Monitorare le prestazioni di sistema durante un test di migrazione pilota. Se il sistema è occupato, è consigliabile evitare una pianificazione aggressiva della migrazione per il sistema specifico, perché si potrebbero verificare problemi di lentezza della migrazione e di disponibilità del servizio. Se possibile, migliorare le prestazioni del sistema di origine aggiungendo risorse hardware e riducendo il carico sul sistema. Il carico sul sistema può essere ridotto spostando attività e utenti in altri server che non fanno parte della migrazione.

Per maggiori informazioni, vedere:

Quando si esegue la migrazione da un'organizzazione locale di Exchange che comprende più server delle cassette postali, è consigliabile creare un elenco degli utenti della migrazione equamente distribuiti tra più server. In base alle prestazioni dei singoli server, l'elenco può essere ulteriormente perfezionato per massimizzare la velocità effettiva.

Se ad esempio il server A ha il 50% di disponibilità di risorse in più rispetto al server B, è ragionevole avere il 50% di utenti in più del server A nello stesso batch di migrazione. Procedure analoghe possono essere applicate ad altri sistemi di origine.

Eseguire le migrazioni quando il sistema ha la massima disponibilità di risorse, ad esempio fuori orario oppure nei weekend o durante le festività.

Attività di back-end

Altre attività di back-end solitamente eseguite durante la migrazione. Poiché è consigliabile eseguire la migrazione al di fuori degli orari di lavoro, in genere le migrazioni entrano in conflitto con altre attività di manutenzione, ad esempio il backup dei dati, eseguite nei server locali.

Esaminare altre attività di sistema che eseguite durante la migrazione. È consigliabile creare una finestra temporale pulita solo per la migrazione dei dati, quando non sono in esecuzione altre attività a uso intensivo di risorse.

Per i clienti di Exchange locale, le attività comuni sono soluzioni di backup. Per altre informazioni, vedere Manutenzione dell'archivio di Exchange.

Criteri di limitazione

È pratica comune proteggere i sistemi di posta elettronica con criteri di limitazione che impostano un limite specifico sulla velocità e sulla quantità di dati che è possibile estrarre dal sistema entro un determinato periodo di tempo e usando uno specifico metodo di migrazione.

Verificare quali criteri di limitazione sono applicati al sistema di posta elettronica. Ad esempio, Google Mail limita la quantità di dati che è possibile estrarre in un determinato periodo di tempo.

In base alla versione, Exchange include criteri che limitano l'accesso IMAP al server della posta locale (usato dalle migrazioni IMAP) e l'accesso al protocollo RPC su HTTP (usato dalle migrazioni complete di Exchange e dalle migrazioni a fasi di Exchange).

Per altre informazioni sulla limitazione IMAP, vedere Suggerimenti per ottimizzare le migrazioni IMAP.

Per altre informazioni sulla limitazione del protocollo RPC su HTTP, vedere:

Per altre informazioni su come configurare la limitazione di Servizi Web Exchange vedere Exchange 2010: Informazioni sui criteri di limitazione dei client.

Fattore 2: server di migrazione

La maggior parte degli strumenti di terze parti usati per le migrazioni a Office 365 sono avviati dal client ed effettuano il push dei dati inOffice 365. Questi strumenti richiedono in genere un server di migrazione. A questi server di migrazione si applicano fattori come le prestazioni di sistema, le attività di back-end e i criteri di limitazione dei server di origine.

Nota : Alcune soluzioni di migrazione di terze parti sono ospitate su Internet come servizi basati sul cloud e quindi non richiedono un server di migrazione locale.

Soluzione e procedura   

Per migliorare le prestazioni della migrazione quando si usa un server di migrazione, applicare le procedure consigliate descritte nella sezione Fattore 1: origine dati.

Fattore 3: motore di migrazione

Per gli strumenti di migrazione di terze parti, i protocolli più diffusi sono Servizi Web Exchange e RPC su HTTP.

Servizi Web Exchange   

Servizi Web Exchange è il protocollo consigliato da usare per le migrazioni a Office 365, perché supporta grandi batch di dati e prevede una limitazione orientata al servizio più efficace. In Office 365, se usato in modalità di rappresentazione, le migrazioni che usano Servizi Web Exchange non consumano la quantità preventivata di risorse di Servizi Web Exchange di Office 365 dell'utente, perché usano invece una copia di tali risorse:

  • Tutte le chiamate che rappresentano Servizi Web Exchange effettuate dallo stesso account di amministratore vengono calcolate separatamente rispetto al budget applicato a tale account.

  • Per ogni sessione di rappresentazione, viene creata una copia shadow del budget effettivo dell'utente. Tutte le migrazioni di questa specifica sezione consumeranno questa copia shadow.

  • La limitazione in rappresentazione è isolata per ogni sessione di migrazione degli utenti.

Procedure consigliate   

  • Le prestazioni della migrazione per gli utenti che usano strumenti di terze parti basati sulla rappresentazione di EWA competono con le migrazioni basate su Servizi Web Exchange e con l'utilizzo delle risorse da parte di altri tenant. Pertanto, le prestazioni della migrazione possono variare.

  • Se possibile, usare strumenti di migrazione di terze parti basati sulla rappresentazione di Servizi Web Exchange, perché in genere sono più veloci ed efficienti rispetto all'uso di protocolli come RPC su HTTP.

Protocollo RPC su HTTP   

Molte soluzioni di migrazione tradizionali usano il protocollo RPC su HTTP. Questo metodo si basa interamente su un modello di accesso client come quello di Outlook e offre scalabilità e prestazioni limitate, perché il servizio Office 365 limita l'accesso basandosi sul presupposto che l'utilizzo avvenga da parte di un utente invece che di un'applicazione.

Procedure consigliate   

  • Per gli strumenti di migrazione che usano il protocollo RPC su HTTP, è pratica comune aumentare la velocità effettiva aggiungendo altri server di migrazione e usando più account di utente amministrativo di Office 365. Questa procedura consente di acquisire un parallelismo nell'inserimento di dati e di ottenere una velocità effettiva dei dati più elevata, perché ogni utente amministrativo è soggetto alla limitazione degli utenti di Office 365. Molti clienti aziendali segnalano di aver dovuto configurare più di 40 server di migrazione per ottenere una velocità effettiva di 20-30 GB/ora.

  • Nella fase di sviluppo degli strumenti di migrazione, è fondamentale valutare il numero di operazioni RPC necessarie per eseguire la migrazione di un messaggio. Per illustrare questo aspetto, abbiamo raccolto i log acquisiti dai servizi di Office 365 per due soluzioni di migrazione di terze parti usate dai clienti per eseguire la migrazione delle cassette postali a Office 365. Abbiamo confrontato le due soluzioni di migrazione sviluppate da altre aziende. Per ogni soluzione, abbiamo confrontato la migrazione di due cassette postali e il relativo caricamento in un file PST di Outlook. Ecco i risultati.

    Metodo

    Dimensioni cassetta postale

    Numero elementi

    Tempo di migrazione

    Totale transazioni RPC

    Latenza media client (ms)

    AvgCasRPCProcessingTime (ms)

    Soluzione A (cassetta postale 1)

    376,9 MB

    4.115

    4:24:33

    132.040

    48,4395

    18,0807

    Soluzione A (cassetta postale 2)

    249,3 MB

    12.779

    10:50:50

    423.188

    44,1678

    4,8444

    Soluzione B (cassetta postale 1)

    618,1 MB

    4.322

    1:54:58

    12.196

    37,2931

    8,3441

    Soluzione B (cassetta postale 2)

    56,7 MB

    2.748

    0:47:08

    5,806

    42,1930

    7,4439

    Outlook

    201,9 MB

    3.297

    0:29:47

    15.775

    36,9987

    5,6447

    Si noti che i tempi di elaborazione di client e servizio sono simili, ma la soluzione A esegue un numero molto più elevato di operazioni RPC per la migrazione dei dati. Poiché ogni operazione consuma tempo di latenza client e tempo di elaborazione server, la soluzione A è molto più lenta per eseguire la migrazione della stessa quantità di dati della soluzione B e in Outlook.

Fattore 4: rete

Procedura consigliata   

Per le soluzioni di migrazione di terze parti che usano il protocollo RPC su HTTP, ecco un metodo valido per misurare le potenziali prestazioni di migrazione:

  1. Dal server di migrazione, connettersi alla cassetta postale di Office 365 con Outlook usando il protocollo RPC su HTTP. Assicurarsi di connettersi usando la modalità cache.

  2. Importare un file PST di grandi dimensioni con dati di esempio nella cassetta postale di Office 365.

  3. Misurare le prestazioni della migrazione calcolando il tempo richiesto per caricare il file PST. La velocità effettiva della migrazione dovrebbe essere simile a quella che i clienti possono ottenere con uno strumento di migrazione di terze parti che usa il protocollo RPC su HTTP, purché non siano presenti altri vincoli. Durante una migrazione effettiva si verifica un sovraccarico, quindi la velocità potrebbe essere leggermente diversa.

Fattore 5: servizio Office 365

La limitazione basata sull'integrità delle risorse di Office 365 influisce sulle migrazioni eseguite con strumenti di migrazione di terze parti. Per altre informazioni, vedere Limitazione basata sull'integrità delle risorse di Office 365.

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

Grazie per i tuoi commenti e suggerimenti

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×