Archivio gestito

Si applica a: Exchange Server 2013

Tutte le versioni precedenti di Exchange Server, da Exchange Server 4.0 a Exchange Server 2010, hanno supportato l'esecuzione di una singola istanza del processo di Archivio informazioni (Store.exe) nel ruolo del server Cassette postali. Questa singola istanza di Store ospita tutti i database nel server: attivo, passivo, in ritardo e ripristino. Nelle architetture di Exchange precedenti l'isolamento tra i diversi database ospitati in un server Cassette postali è minimo, se presente. Un problema con un singolo database delle cassette postali può influire negativamente su tutti gli altri database e gli arresti anomali causati da un danneggiamento delle cassette postali possono influire sul servizio per tutti gli utenti i cui database sono ospitati in tale server.

Un'altra sfida con una singola istanza di Store nelle versioni precedenti di Exchange è che il motore di archiviazione estendibile (ESE) viene ridimensionato bene fino a 8-12 core del processore, ma oltre tale soglia, i problemi di comunicazione tra processori e sincronizzazione della cache portano a una scalabilità negativa. Dati i server più grandi di oggi, con oltre 16 sistemi core disponibili, ciò comporterebbe l'imposizione della sfida amministrativa di gestire l'affinità di 8-12 core per ESE e di usare gli altri core per i processi non store (ad esempio, Assistenti, Search Foundation, Disponibilità gestita e così via). Inoltre, l'architettura precedente limitava l'aumento del numero di istanze per il processo dello Store.

Il processo Store.exe si è evoluto considerevolmente nel corso degli anni man mano che Exchange Server stessa si è evoluta, ma come un unico processo, alla fine la sua scalabilità è limitata e rappresenta un singolo punto di guasto. A causa di questi limiti, Store.exe non è più disponibile in Exchange 2013 e viene sostituito da Managed Store.

Archivio gestito

L'archivio gestito è il nome dei processi dell'Archivio informazioni (noto anche come Archivio) in Exchange Server 2013. L'archivio gestito usa un modello di processo controller/lavoro che fornisce l'isolamento del processo di archiviazione e un failover del database più veloce. L'archivio gestito include anche un nuovo meccanismo di memorizzazione nella cache del database statico che sostituisce l'algoritmo di buffer dinamico nelle versioni precedenti di Exchange Server. Nel modello multiprocesso usato dall'archivio gestito è presente un singolo processo del controller del servizio di archiviazione (in questo caso, Microsoft.Exchange.Store.Service.exe noto come MSExchangeIS) e un processo di lavoro (in questo caso, Microsoft.Exchange.Store.Worker.exe) per ogni database montato. Quando viene montato un database, viene creata un'istanza di un nuovo processo di lavoro che esegue solo tale database. Quando un database viene smontato, il processo di lavoro per tale database viene terminato.

Ad esempio, se si dispone di 40 database montati in un server, saranno in esecuzione 41 processi per l'archivio gestito, uno per ogni database e uno per il controller del processo del servizio di archiviazione.

Il controller del processo del servizio di archiviazione è sottile e affidabile, ma se muore o viene terminato, tutti i processi di lavoro muoiono (rileveranno che il processo del controller di servizio è andato e si chiude). Il controller del processo di archiviazione monitora l'integrità di tutti i processi di lavoro dell'archivio nel server. Una terminazione forzata o imprevista del Microsoft.Exchange.Store.Service.exe causa un failover immediato di tutte le copie attive del database. L'archivio gestito è inoltre strettamente integrato con il servizio Replica di Microsoft Exchange (MSExchangeRepl.exe) e Active Manager. Il processo del controller, i processi di lavoro e il servizio replica interagiscono per garantire maggiore disponibilità e affidabilità:

• Processo del servizio Replica di Microsoft Exchange (MSExchangeRepl.exe)

  • Responsabile del rilascio di operazioni di montaggio e smontaggio nello Store

  • Avvia l'azione di ripristino per gli errori di archiviazione o di database segnalati da Store, dal motore di archiviazione estendibile (ESE) e dai risponditori di disponibilità gestita

  • Rileva errori imprevisti del database

  • Fornisce l'interfaccia amministrativa per le attività di gestione

• Store service process/controller (Microsoft.Exchange.Store.Service.exe)

  • Gestisce la durata di ogni processo di lavoro in base alle operazioni di montaggio e smontaggio ricevute dal servizio replica

  • Gestisce le richieste in ingresso da Gestione controllo servizi Windows

  • Registra gli elementi di errore quando vengono rilevati problemi del processo di lavoro dell'archivio (ad esempio, blocco o uscita imprevista)

  • Termina i processi di lavoro dell'archivio nell'evento di failover della risposta

• Processo di lavoro dell'archivio (Microsoft.Exchange.Store.Worker.exe)

  • Responsabile dell'esecuzione di operazioni RPC per le cassette postali in un database

  • L'istanza dell'endpoint RPC all'interno del processo di lavoro è il GUID del database

  • Fornisce la cache del database per un database

Algoritmo di memorizzazione nella cache del database statico

L'algoritmo di memorizzazione nella cache del database noto come allocazione dinamica del buffer introdotto in Exchange Server 5.5 e usato anche dall'Archivio informazioni in Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 e Exchange Server 2010, è passato anche da Exchange 2013. Exchange 2013 usa un algoritmo semplice e semplice per determinare la cache del database. L'archivio gestito non rialloca più dinamicamente la cache tra i database quando si verifica il failover, semplificando notevolmente la gestione interna della cache. Al contrario, la memoria allocata per ogni cache del database (ad esempio, ogni processo di lavoro dell'archivio) si basa sul numero di copie del database locale e sul valore di MaximumActiveDatabases, se configurato. Se il valore di MaximumActiveDatabases è maggiore del numero di copie correnti del database, il calcolo della cache si basa sul numero di copie del database.

L'algoritmo statico usato da Exchange 2013 alloca memoria per la cache ESE di ogni processo di lavoro dell'archivio in base alla RAM fisica. Questa memoria viene definita destinazione cache massima di un database. Il 25% della memoria totale del server viene allocato alla cache ESE. Questa percentuale di memoria viene definita destinazione delle dimensioni della cache del server.

Una quantità statica di questa cache viene allocata alle copie attive e passive. Al processo di lavoro dell'archivio verrà allocata la destinazione cache massima solo quando si esegue la manutenzione di una copia attiva del database. Le copie passive del database vengono allocate al 20% della destinazione cache massima. Il resto viene riservato dallo Store e allocato al processo di lavoro se il database passa da passivo a attivo.

La destinazione cache massima viene calcolata solo all'avvio dello Store. Pertanto, se si aggiungono o si rimuoveno database o copie di database, è necessario riavviare il servizio controller di archiviazione (MSExchangeIS) in modo che la cache possa essere regolata di conseguenza. Se il servizio non viene riavviato, i database appena creati avranno una destinazione di dimensioni della cache inferiori rispetto ai database creati prima dell'avvio del servizio. In questo caso, la somma delle destinazioni delle dimensioni della cache del database supererà probabilmente la destinazione delle dimensioni della cache del server fino al riavvio di MSExchangeIS.

Esempio di calcoli della cache del database

Di seguito sono riportati alcuni calcoli di memorizzazione nella cache del database basati sulla memoria e la configurazione del database di un server Cassette postali.

Esempio 1

In questo esempio, il server Cassette postali ha 48 GB di memoria e ospita due database attivi e due database passivi. Inoltre, il parametro MaximumActiveDatabases non è configurato. In questa configurazione, la quantità di cache del database è di 3 GB per ogni processo di lavoro di copia del database attivo e di 0,6 GB per ogni processo di lavoro di copia del database passivo. Ecco come sono stati ottenuti questi valori.

Per ottenere la destinazione delle dimensioni della cache del server, moltiplicare la quantità di memoria per il 25%:

48 GB X 25% = 12 GB

Per ottenere la destinazione cache massima del database, dividere la destinazione dimensioni cache server per il numero totale di database attivi e passivi:

12 GB / 4 database = 3 GB

Per determinare la quantità di memoria usata per le copie passive del database, moltiplicare la destinazione cache massima del database per il 20%:

3 GB X 20% = 0,6 GB

Dei 12 GB di memoria assegnati alla destinazione delle dimensioni della cache del server, i processi di lavoro del database useranno 7,2 GB e 4,8 GB saranno riservati dall'Archivio informazioni per le due copie passive del database nel caso in cui diventino copie attive. In questo caso, useranno la destinazione cache massima di 3 GB.

Esempio 2

In questo esempio, il server Cassette postali ha anche 48 GB di memoria e ospita due database attivi e due database passivi; Tuttavia, il parametro MaximumActiveDatabases è configurato con un valore pari a 2. In questa configurazione, la quantità di cache del database è di 5 GB per ogni processo di lavoro di copia del database attivo e di 0,2 GB per ogni processo di lavoro di copia del database passivo. Ecco come sono stati ottenuti questi valori.

Per ottenere la destinazione delle dimensioni della cache del server, moltiplicare la quantità di memoria per il 25%:

48 GB X 25% = 12 GB

Per ottenere la destinazione cache massima del database, dividere la destinazione delle dimensioni della cache del server per il numero totale di database attivi più il numero totale di database passivi moltiplicati per il 20%:

12 GB / (2A + (2P X 20%)) = 5 GB

Per determinare la quantità di memoria usata per le copie passive del database, moltiplicare la destinazione cache massima del database per il 20%:

5 GB X 20% = 1 GB

Dei 12 GB di memoria assegnati alla destinazione delle dimensioni della cache del server, 12 GB verranno usati dai processi di lavoro del database e l'Archivio informazioni non riserva memoria per le due copie passive del database perché non possono diventare copie attive in questa configurazione (perché MaximumActiveDatabases è configurato con un valore pari a 2, e sono già presenti 2 copie di database attive nel server).