System Center Data Protection Manager (DPM) è il componente di System Center dedicato alla protezione del dato. Dopo un lungo periodo di vuoto Microsoft ha finalmente tornato ad investire nella soluzione aggiungendo la possibilità di utilizzare Azure come storage secondario, il supporto per la deduplica, il supporto per gli ultimi workload, il supporto di DPM come sistema di protezione su Azure IaaS.
Come tutti i componenti System Center anche DPM ha il proprio management pack per poterne effettuare il monitor con System Operations Manager (OpsMgr). Anzi molto di più, DPM può usare OpsMgr come console centralizzata dalla quale non solo tenere sotto monitor, ma anche scatenare azioni su più server DPM.
Lo Scenario
Come managed service provider è per noi importante garantire ai nostri clienti livelli certi di RPO e RTO, per farlo a costi contenuti è necessario attivarsi solo quando davvero è necessario. Questa stessa esigenza può essere condivisa da un ICT evoluto che abbia SLA interni con la propria azienda. L’ideale sarebbe attivarsi non quando un singolo backup fallisce (in termini di DPM recovery point), ma quando le risorse protette escono dallo SLA di RPO concordato con il cliente. In molti casi DPM è in grado di recuperare in automatico il fallimento di una singola operazione senza nessun intervento umano. Attualmente il management pack notifica il fallimento dei singoli recovery point, lo fa in modo intelligente, cercando di indicare le root cause quando il fallimento di più recovery point è da imputare alla medesima causa, ma non prende in considerazione gli SLA. Ad ogni fallimento abbiamo un allarme che eventualmente si chiude nel momento in cui le operazioni automatiche di correzione abbiano buon esito.
Con l’Update Rollup 4 di System Center 2012 R2 Microsoft ha iniziato ad introdurre lo scenario di cui sopra, ossia è oggi possibile definire degli SLA per gli RPO di ogni singolo Protection group. La possibilità è scarsamente documentata (per non dire per nulla) perchè lo scenario sarà completato con la prossima Update Rollup 5.
Configurare uno SLA per un Protection Group
Dalla Update Rollup 4 sono stati introdotti due nuovi commandlet PowerShell:
- Set-DPMProtectionGroupSLA
- Get-DPMProtectionGroupSLA
Sulla classe ProtectionGroup (Microsoft.Internal.EnterpriseStorage.Dls.UI.ObjectModel.OMCommon.ProtectionGroup) sono stati aggiunti due metodi che compiono le medesime azioni:
- SetProtectedGroupSLAForAlert
- ReadProtectedGroupSLAForAlert
Come è facile intuire tramite questi comandi è possibile definire e leggere uno SLA in ore, se non definito lo SLA è pari a 0.
Impostare lo SLA per un PG è questione di una riga di PowerShell:
Get-DPMProtectionGroup | where {$_.Name –ieq ‘MyProtectionGroup’} | Set-DPMProtectionGroupSLA –SLAInHours 24
Utilizzando l’help di PowerShell è possibile consultare la scarna documentazione sui nuovi comandi:
help Set-DPMProtectionGroupSLA
NAME Set-DPMProtectionGroupSLA SYNTAX Set-DPMProtectionGroupSLA [-ProtectionGroup] <ProtectionGroup> [-SLAInHours] <int> [<CommonParameters> Set-DPMProtectionGroupSLA [-ProtectionGroupId] <guid> [-SLAInHours] <int> [<CommonParameters>]
Importando il nuovo Management Pack per DPM sarà possibile avere in OpsMgr / Central Console un alert per ogni data source che non rispetti lo SLA. Questo controllo viene effettuato una volta al giorno dal server DPM, un evento scritto in eventlog e il monitor intercetta l’evento. In questo momento l’alert si aggiunge a quelli eventualmente già presenti per il fallimento delle operazioni: se un data source è fuori SLA delle due l’una o ho commesso un errore di configurazione oppure i recovery point sono falliti.
Con la prossima Update Rollup 5 la stessa informazione dovrebbe essere portata in console DPM.
Un Contributo per la Community
Quanto fatto dal team DPM è un ottimo inizio, ma presenta alcuni limiti, in primis:
- Il controllo viene fatto giornalmente, grazie alla “continuos protection” di DPM è comune per workload critici avere SLA nell’ordine di qualche ora. Un controllo giornaliero è insufficiente.
- Tutte le altre segnalazioni puntuali di fallimento rimangono attive, aumentando il rumore in console
Per questo motivo ho deciso di rilasciare per la community un addendum Management Pack per DPM 2012 R2 che implementi i seguenti controlli:
- Con cadenza oraria verifica la presenza di Data Source fuori SLA e nel caso genera un alert in console
- Con cadenza oraria verifica la presenza di protection group che contengono data source fuori SLA e cambia lo stato del protection group in unhealthy senza generare un alert
- Disabilita l’alerting per alcuni monitor su protection group e data source in modo da ridurre il rumore in console
In base alle proprie preferenze è possibile invertire il comportamento e invece di avere un alert per ogni data source fuori SLA è possibile averne uno cumulativo per Protection group e affidarsi all’health explorer per individuare quali data source sono effettivamente problematici.
Oltre a questo il management pack controlla anche la capacità dei disk or storage pool di DPM e genera un alert quando la capacità residua è inferiore al 15% in modo che le opportune azioni possano essere intraprese prima che il disk pool si riempia. Lo stesso valore è anche collezionato come performance data point in modo da permettere trending e reporting. In questa versione il management pack non fornisce report.
Il management pack può essere scaricato da Technet Gallery.