Freigeben über

Pianificazione della capacità: sì, lo spazio disponibile per il registro delle transazioni è fondamentale per mantenere i database accessibili e integri

  • Artikel

Articolo originale pubblicato mercoledì 09 nov. 2011

L'altro giorno, mentre chiacchieravo con uno dei nostri Responsabili dei programmi di supporto, Nino Bilic, questi ha accennato a un aspetto piuttosto allarmante: il motivo principale per cui i nostri clienti più importanti aprono situazioni critiche relative a Exchange 2010 consiste nel fatto che i database Mailbox diventano inaccessibili a causa dell'esaurimento dello spazio disponibile per il LUN del registro delle transazioni. 

ma lasciamo da parte questo problema per un momento.  Naturalmente sono scioccato... A essere sinceri pensavo che, con il calcolatore per i requisiti di Mailbox e le istruzioni fornite su TechNet, avessimo ormai risolto questo problema. Dopo avermi comunicato questo dato, Nino ha deciso che io, e non lui, dovessi scrivere un articolo per il blog sull'argomento della pianificazione della capacità del registro delle transazioni (mmh, grazie Nino!).

Pianificazione della capacità 101

Per dimensionare correttamente il LUN del registro delle transazioni, è necessario comprendere alcune cose sull'ambiente:

  1. Quante cassette postali saranno presenti nel database?
  2. Qual è il profilo dei messaggi delle cassette di posta del database?
  3. Qual è la dimensione media dei messaggi?
  4. Qual è la dimensione media delle cassette di posta?
  5. Quante cassette di posta vengono spostate al giorno?
  6. Qual è la soluzione di backup e ripristino?
  7. Questa soluzione deve prendere in considerazione altri scenari di malfunzionamento, come i guasti di rete?

Ai fini di questa discussione, supponiamo che ogni database ospiti 250 cassette di posta. Ognuna di esse invia/riceve 150 messaggi al giorno, con una dimensione media dei messaggi pari a 100 KB. In base alla tabella contenuta in Database delle cassette di posta e fattori di capacità di registrazione, sappiamo che un profilo di 150 messaggi con una dimensione media dei messaggi pari a 75 KB genera 30 registri delle transazioni al giorno (24 ore). Poiché nel nostro caso la dimensione dei messaggi è maggiore di 75 KB, è necessario tenere in considerazione questo dato nei nostri registri delle transazioni per la generazione di ciascuna cassetta di posta. Le istruzioni dettano quanto segue:

Se la dimensione media dei messaggi raddoppia arrivando a 150 KB, i registri generati per ciascuna cassetta di posta aumenta moltiplicandosi per un fattore di 1,9. Questo numero rappresenta la percentuale del database che contiene gli allegati e le tabelle dei messaggi (corpo del messaggio e allegati).

È possibile quindi determinare l'impatto di una dimensione media dei messaggi pari a 100 KB con questa formula:

150/1,9 = [dimensione media dei messaggi del profilo]/x

x = (100 * 1,9)/150

x = 1,266666666666667 ~ 1,27

Dal momento che la dimensione dei messaggi supera di 25 KB il valore di base, il numero di registri di transazione generati al giorno per ciascuna cassetta di posta aumenta moltiplicandosi per un fattore di 1,27. Quindi, 30 registri delle transazioni * 1,27 = 39 registri delle transazioni/giorno/cassetta di posta. Ciò significa che per un database di 250 cassette di posta, ogni database genererà 39 * 250 = 9.750 registri delle transazioni generati dalle cassette di posta/giorno/database.

Anche gli spostamenti delle cassette di posta generano registri delle transazioni. Ogni cassetta di posta spostata nel database di destinazione genera un numero sufficiente di registri (alla destinazione, non all'origine) che è pari alla dimensione della cassetta di posta (compreso quanto contenuto nelle cartelle dei messaggi recuperabili). Ad esempio, spostare l'1% delle cassette di posta al giorno significa che ogni giorno 2,5 cassette di posta vengono spostate in un altro database. Se ogni cassetta di posta ha una dimensione media di 5,4 GB (compresi i messaggi eliminati conservati per 14 con la funzione di recupero dei singoli messaggi attivata), si hanno 2,5 * 5,4 GB/1024 = 13.888 registri delle transazioni per spostamenti di cassette di posta/giorno/database.

Dal punto di vista del backup/ripristino, è necessario prendere in considerazione il tipo di architettura di backup utilizzata. Per ogni scenario di backup, esiste un numero consigliato di giorni aggiuntivi che è necessario prevedere dal punto di vista della capacità per quanto riguarda i registri delle transazioni generati per la cassetta di posta. Prevedendo uno spazio ulteriore, è possibile superare vari guasti senza andare incontro a interruzioni del servizio. Per ulteriori informazioni sul troncamento dei registri delle transazioni, vedere Backup, ripristino e ripristino di emergenza.

  Troncamento dei registri delle transazioni Protezione consigliata contro i problemi di backup
Backup completo quotidiano Quotidiano 3 giorni
Backup completo settimanale/Incrementale quotidiano Quotidiano 3 giorni
Backup completo settimanale/Incrementale quotidiano Settimanale 7 giorni
Backup completo bimensile/Incrementale quotidiano Quotidiano 3 giorni
Protezione dei dati nativi di Exchange Quando i registri non sono più necessari 3 giorni

Esistono ovviamente anche altri scenari che potrebbe essere necessario considerare. Ad esempio, se si distribuisce un gruppo di disponibilità database (DAG) esteso tra due centri dati, il troncamento dei registri avverrà solo se il collegamento di rete tra i due centri dati è operativo e se le copie del database sono in condizioni ottimali. Se si è a conoscenza del fatto che un'interruzione del collegamento della WAN potrebbe richiedere cinque giorni per essere riparato, è necessario adattare la protezione contro i problemi di backup in modo da provvedere a questa situazione.

Per lo scenario qui esaminato, ipotizziamo di dovere superare il problema per soli tre giorni di eventi di malfunzionamento del troncamento. Questo significa che sono necessari 9.750/1024 * 3 = 28,5 GB di spazio su disco per i registri delle transazioni generati dalle cassette postali.

È inoltre necessario tenere in considerazione la quantità di spazio su disco necessaria per gli eventi di spostamento delle cassette postali dell'intera settimana: 13.888 / 1014 * 7 giorni = 94,9 GB di spazio su disco per le operazioni di spostamento delle cassette postali.

Nel complesso, ciò significa che per ogni database sono necessari 123 GB di spazio su disco per i registri delle transazioni. Occorre inoltre includere un fattore relativo ai dati di overhead per tenere conto di eventuali fenomeni inspiegabili che potrebbero verificarsi: 123 GB * 1,2 = 148 GB di spazio su disco per i registri delle transazioni.

Se si sta distribuendo un LUN dedicato per i registri di transazione, non sarebbe opportuno prevedere un LUN di 150 GB, perché ciò significherebbe consumare tutto lo spazio su disco in caso di problemi di backup e di un eccesso di spostamenti delle cassette postali. Di norma l'obiettivo è eseguire il provisioning per ogni LUN in modo tale che solo l'80% della capacità del disco sia utilizzata. La formula è:

Spazio del LUN = [utilizzo previsto dello spazio su disco]/(1 – [percentuale desiderata di spazio libero])

Spazio del LUN = 148 GB/(1 – 0,2) = 148 GB/0,8 = 185 GB di spazio del LUN per il volume dedicato ai registri delle transazioni

Se si distribuiscono i registri delle transazioni sullo stesso LUN del database, è sufficiente combinare i requisiti di spazio su disco per i registri delle transazioni con i requisiti di spazio su disco del database per il valore [utilizzo previsto dello spazio su disc].

In che modo è possibile evitare di esaurire completamente lo spazio su disco per i registri delle transazioni?

Come primissima cosa è necessario ottenere un valore di base dell'ambiente in uso per determinare il tasso tipico di generazione di registri al giorno. Occorre poi impostare il monitoraggio e prendere provvedimenti per qualsiasi avviso che venga generato.  Il monitoraggio deve prevedere gli scenari seguenti:

  1. Spazio su disco del LUN per i registri delle transazioni. Impostare più soglie e diversi meccanismi di avviso. Il primo avviso generato non deve essere quello indicante che è già stato esaurito il 90% dello spazio su disco. Se si conosce il valore di base tipico della generazione di registri, è possibile impostare una soglia per segnalare che si è superato, ad esempio, del 20% tale valore.
  2. Verificare che i backup vengano completati correttamente (se non si fa ricorso alla protezione dei dati nativi di Exchange). La prima indicazione di problemi di backup non deve giungere quando lo spazio su disco è già esaurito.
  3. Verificare gli eventi di troncamento nel registro delle applicazioni.
  4. Verificare l'integrità delle repliche delle copie del database. 

E se si verifica un aumento inspiegato dei registri delle transazioni?

Il mio amico Mike Lagase ha scritto un articolo molto interessante sulla risoluzione dei problemi in questo scenario: https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (si noti che l'articolo è stato scritto pensando a Exchange 2007, quindi molti degli strumenti e/o dei consigli potrebbero non essere più validi per Exchange 2010). Oltre ai passaggi indicati da Mike, è possibile utilizzare le misure seguenti in Exchange 2010 per comprendere l'aumento inspiegato dei registri delle transazioni (grazie a Todd Luttinen per avere compilato l'elenco):

  1. È possibile utilizzare il comando cmdlet per le statistiche di utilizzo dello spazio di archiviazione (get-StoreUsageStatistics with DigestCategory = ‘LogBytes’) per identificare le cassette della posta che generano conteggi di byte di registro elevati. Si noti che questo comando non funziona sempre per i casi in cui i byte di registro non sono generati dal titolare della cassetta postale o se l'operazione è eseguita a nome del client (come CopyOnWrite) e non include byte di registro generati da servizi del sistema (segnalato nell'ID evento 9826). Queste statistiche forniscono un riepilogo degli ultimi 10 minuti di attività per le principali cassette postali che generano attività di registro (fino a 6 campioni a copertura dell'ultima ora). Di seguito viene indicato come utilizzare le statistiche di utilizzo dello spazio di archiviazione per individuare le principali cassette postali che hanno generato byte di registro nell'ultima ora:

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Selezionare -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. Esistono anche eventi delle applicazioni generati per i client di amministrazione (ID evento 9826). Queste statistiche rappresentano due ore di attività:

    A iniziare da <date/time> il servizio <name> ha eseguito questa attività sul server:
    Operazioni RPC: 24168.
    Pagine di database lette: 1329 (di cui 629 pagine pre-lette).
    Pagine di database aggiornate: 12.418 (di cui 11555 pagine riaggiornate).
    Record di registro del database generati: 13.906.
    Byte dei record di registro del database generati: 660.331.
    Tempo sul server: 19.142 ms.
    Tempo in modalità Utente: 6.100 ms.
    Tempo in modalità Kernel: 63 ms.

  3. Il contatore di monitoraggio delle prestazioni “MSExchangeIS Client(*)\JET Log Record Bytes/sec” può essere utilizzato per identificare quale tipo di client sta causando l'aumento dei registri.

Credo che tutti noi comprendiamo quanto sia importante assicurare che vi sia una capacità sufficiente per evitare che la disponibilità dei database non sia compromessa. Ci auguriamo che queste informazioni siano utili per pianificare la capacità dei registri delle vostre transazioni.

Ross Smith IV
Direttore programmi
Exchange Customer Experience

Questo è un post di blog localizzato. Consultate l'articolo originale: Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted