0
9. Mai 2017

System Center 2016 Blogpostreihe – Teil 3: Data Protection Manager – Vorteile von Modern Backup Storage (MBS)

Haben Sie sich System Center Data Protection Manager 2016 schon angeschaut? Kennen Sie DPM schon von vorherigen Versionen? Lesen Sie in diesem Teil meiner Blogpostreihe, wie Microsoft mit Modern Backup Storage die DPM Storage Verwaltung revolutioniert.


Im dritten Teil meiner Blogpostreihe zu System Center 2016 geht es um die Vorteile von Modern Backup Storage (MBS) mit DPM 2016. Dieses Mal ist es kein Erfahrungsbericht zur Installation, sondern ein Rückblick auf die vergangenen Jahre mit DPM, bezogen auf den Storage und die Verbesserungen, die mit MBS eingeführt wurden. Ich stelle die alten Probleme bzw. Einschränkungen vor und wie man diese in der Vergangenheit umgehen bzw. lösen konnte. Damit ist der Blogpost auch für die interessant, die auf einer älteren Version von DPM bzw. auch mit DPM 2016 beim klassischen Storage bleiben müssen. Ich zeige auf, wie die alten Probleme und Einschränkungen nun mit MBS gelöst sind. OK, Sie mussten nun schon lange genug auf den dritten Teil der Blogpostreihe warten, deshalb geht es nun endlich los.

Modern Backup Storage

Wenn Sie noch nichts über Modern Backup Storage wissen, stelle ich hier ein paar interessante Links zum Thema bereit:

Im zweiten Teil meiner Blogpostreihe bin ich auch schon kurz auf MBS eingegangen und wie die Migration vorhandener Datasources auf MBS nach einem Upgrade auf DPM 2016 erfolgen kann:

System Center 2016 Blogpostreihe – Teil 2: Data Protection Manager

Einführung in Modern Backup Storage von Microsoft:

Introducing DPM 2016 Modern Backup Storage

Link zur offiziellen Microsoft Dokumentation:

Add Storage to DPM 2016

Nachdem Sie nun im Bilde sind, was MBS grundsätzlich ist, lesen Sie weiter und erfahren Sie, welche Vorteile Sie damit noch erlangen.

Logical Disk Manager Datenbank (LDM)

ohne Modern Backup Storage

Die dynamischen Disks, die DPM bisher als Storage nutzte, werden vom Logical Disk Manager (LDM) von Windows verwaltet. Hier gibt es harte Grenzen, die dazu führen können, dass keine neuen Replica/Recoverypoint Volumes mehr erstellt und bereits bestehende nicht mehr erweitert werden können. Schuld daran ist die begrenzte Anzahl von Slots in der LDM Datenbank, die mit einer maximalen Anzahl von 2960 zwar recht hoch liegen, aber in größeren DPM-Installationen schnell erreicht werden. Jedes Volume (egal ob Replica oder Recoverypoint) benötigt 1-2 Slots, jede Erweiterung (Extend) eines Volumes (z.B. weil die Datasource größer geworden ist) verwendet einen weiteren Slot. Genauere Informationen finden Sie hier.
Da ich schon seit den Anfängen von DPM auf das Produkt für die Datensicherung setze, bin ich auch schon in diese Situation geraten, ohne zuvor irgendwo darauf hingewiesen worden zu sein. Seit Version 2010 warnt DPM zumindest frühzeitig vor dieser Situation.

Modern Backup Storage - LDM-Warnung
LDM-Warnung

Die Warnung wird frühzeitig ausgegeben, damit der Admin noch genügend Zeit hat, durch Storage Migrationen oder Löschen von Protections und Wiederneuaufnahme die verwendeten Slots zu reduzieren.
Wer sich die Situation auf seinem DPM anschauen will, kann dies mit diesem Script tun. Dieses hat mir schon wertvolle Dienste erwiesen, weil man mit dessen Hilfe auch schnell erkennen kann, welche Datasources angegangen werden sollten um den effektivsten Nutzen zu haben.

mit Modern Backup Storage

Mit MBS ist die LDM Datenbank nicht mehr relevant. MBS speichert die Backups auf ReFS Volumes als VHDX. Somit können die oben beschriebenen Grenzen nicht mehr erreicht werden.

Colocating und Reprotection

ohne Modern Backup Storage

Mit DPM 2010 wurde das Colocating eingeführt. Eigentlich eine sehr gute Sache. Damit wurden z.B. SQL-DBs innerhalb einer Protectiongroup nicht jeweils auf ein eigenes Volumepaar (Replica und Recoverypoint) gespeichert, sondern mehrere DBs auf das gleiche Volumepaar. Damit wurde die Gesamtanzahl der Volumes und somit der Slots in der LDM Datenbank (siehe Ausführungen oben) wesentlich reduziert. Allerdings konnte man dadurch in ein anderes Problem geraten, welches hier sehr gut beschrieben wird. Anders als im Blogpost des Autors beschrieben, sind Situationen, in denen das Problem auftreten kann recht schnell erreicht. Ich bin schon oft auf das Problem gestoßen, vor allem bei SQL-DBs. Die klassische Situation: Eine Datenbank wird im DPM initial aufgenommen und steht im Recoverymodel SIMPLE. Der Datenbankadministrator (DBA) stellt die DB später auf Full, weil sie in den produktiven Betrieb übergeht und informiert (hoffentlich) den DPM-Admin darüber. Damit die DB ab dann transaktionell gesichert wird, muss sie im DPM neu aufgenommen, „reprotected“ werden. Das bedeutet, ich setzte die DB auf Inactive, behalte die Recoverypoints auf Disks bei und nehme die DB neu auf. Soweit so gut. Nun kommt innerhalb der Aufbewahrungszeit (bei DBs nicht unüblich 30 und mehr Tage) irgendeine Situation, aufgrund derer ich die DB nochmal reprotecten muss. Sei es, weil die Sicherung einfach nicht mehr läuft (manchmal zickt DPM halt einfach rum), die DB in einer anderen Protectiongroup gesichert werden soll oder die DB kurzzeitig nicht gesichert werden soll (z.B. weil eine große Migration in die DB erfolgen soll). In allen der Fällen muss ich die DB reprotecten. Und schon bin ich in der Premisse, eigentlich die Backups löschen zu müssen und somit die Backuphistorie meiner produktiven DB. Wenn man SLAs einhalten muss keine einfache Entscheidung bzw. nicht einfach, mit dem Kunden abzustimmen, geschweige denn es ihm zu erklären.

mit Modern Backup Storage

Mit MBS gibt es kein Colocating mehr. Damit tritt das Problem bezüglich der mehrmaligen Neuaufnahme mit Beibehaltung der Backups nicht mehr auf.

Die Frage „Wo liegen meine Backups“

ohne Modern Backup Storage

Ich gebe zu, als ich mit DPM angefangen habe, musste ich mich auch erst umgewöhnen. Verglichen mit klassischen Backuplösungen wie z.B. Backup Exec war es schon teilweise „harter Tobak“, was mit DPM alles anders war. Nicht nur, dass ich lediglich in begrenztem Maße Einfluss auf die Wahl der Bänder, die DPM für die Bandsicherung einer bestimmten Protectiongroup verwendet, nehmen konnte, auch die Wahl der Disk bzw. des darunterliegenden Storage lies mich DPM nicht frei wählen (abgesehen von Custom Volumes, aber gehen wir darauf nicht weiter ein). Ein großer Storagepool, und das war‘s. DPM sorgte für eine Verteilung der Volumes und deren Erweiterungen. Mit der Zeit lernte man das aber auch schätzen. Wenn der Speicherplatz im Storage Pool aufgebraucht war, schmiss man DPM einfach irgendeine Disk dazu und schon kümmerte er sich um die weitere Verteilung. Migrationen auf ein neues Storagesystem waren möglich, aber nicht einfach. Es benötigte dazu ein Script.

mit Modern Backup Storage

Diese Frage kann nun mit MBS beantwortet werden. Für jede Datasource kann ich das DPM-Volume im Storage Pool angeben. Sofern ich den Storage Pool entsprechend aufgebaut habe, kann die gezielte Speicherung bestimmter Backups auf speziellen Volumes durchgeführt werden. Zum Beispiel ließe sich für SQL-Sicherungen ein Volume bereitstellen, welches auf schnellen Disks liegt, so dass eine viertelstündige transaktionelle Sicherung zur Einhaltung der SLAs erfolgen kann.

Storageklassen und Custom Volumes

ohne Modern Backup Storage

Mit dem klassischen DPM Storage Pool konnte man Storageklassen nur mit Custom Volumes definieren. Storageklassen meinen unterschiedliche Hardware für hohe IO Anforderungen. Wenn man SLAs einhalten und damit SQL-Backups von vielen DBs in einer bestimmten Zeit sicherstellen musste und deshalb schnellen DPM-Storage für genau nur diese SQL-DBs bereitstellen wollte, ging dies nur mit Custom Volumes. Fügte man den High Performance Storage als normale Disk dem DPM Storage Pool hinzu, dann verwendete DPM diesen für beliebige Datasources, also nicht nur für die SQL-DBs. Mit Custom Volumes hatte man die Möglichkeit für eine Protectiongroup ein bestimmtes Volumepaar als Recplica- und Recoverypointvolume bereitzustellen und somit die Möglichkeit zu steuern, wo die Backups abgelegt werden. Allerdings verlor man dadurch die Vorteile der automatischen Erweiterung der Volumes. Und wenn der Speicherplatz auf der Disk, wo die Custom Volumes lagen, ausgeschöpft und keine Erweiterung möglich war, stand man an der Wand. Man musste neue Volumes auf neuem Storage bereitstellen und die Recoverypoints migrieren.

mit Modern Backup Storage

Mit MBS können nun Storageklassen definiert werden. Durch die gezielte Speicherung der Backups auf festgelegte Volumes können z.B. SQL-DB Sicherungen auf ein oder mehrere Volumes gespeichert werden, die auf High Performance Storage liegen. Nicht nur dass, es können im DPM auch Storageklassen definiert werden. Durch Festlegen des Parameters DataSourceType kann z.B. ein DPM-Volume für SQL-DBs festgelegt werden. Dies ist nicht über die GUI möglich und muss per DPM-Shell erfolgen. Hier ein Beispiel: Zunächst wird das DPM-Volume über den Mountpoint „D:\DPM-Storage\SQL“, unter welchem es im System eingebunden ist per Get-DPMDiskStorage eingelesen und dann mittels Update-DPMDiskStorage der Anzeigename „SQL-DBs“ und der DataSourceType „SQL“ gesetzt.

$tempDPMDisk = Get-DPMDiskStorage -Volumes -All | where {$_.AccessPath -LIKE "*D:\DPM-Storage\SQL*"}
Update-DPMDiskStorage -Volume $tempDPMDisk -FriendlyName “SQL-DBs” -DatasourceType SQL

 

Dies sieht dann wie folgt in der DPM Konsole aus:

Modern Backup Storage - Volumes mit Storageklassen
Volumes mit Storageklassen

Folgende DataSourceTypes sind möglich:

  • FileSystem
  • Client
  • SQL
  • SharePoint
  • Exchange
  • SystemProtection
  • HyperV
  • VMware
  • Other
  • All

Bei der Aufnahme von Datasources erkennt DPM automatisch die richtige Storageklasse und schlägt diese vor. Ich kann sie an der Stelle aber noch manuell ändern, wenn ich das möchte.

Storage Pool Verbrauch, Erweiterungen und Shrinks

ohne Modern Backup Storage

Für jede Datasource legte DPM zwei Volumes im DPM Storage Pool an. Eines war das Replica Volume, welches z.B. bei einem Laufwerk D: mit einer Größe von 10 TB mindestens 11TB groß war. Das zweite Volume war das Recoverypoint Volme, dessen Größe von DPM anhand der Aufbewahrungszeit und weiterer Faktoren hochgerechnet wurde. Nehmen wir mal an, das wäre 3 TB. Für die Sicherung des 10 TB Volumes benötigte ich also mindestens 14 TB an DPM-Storage. Das sind 40 % mehr als die eigentliche Größe der Datasource. Wenn man das bei der Planung des DPM Servers (ja, es war und ist wichtig, die Implementierung eines Backupservers gut zu planen) berücksichtigt hat, OK. Nun nehmen wir mal an, durch Bereinigungen auf dem Quelllaufwerk D: haben über eine gewisse Zeit viele Änderungen stattgefunden und diese haben das Recoverypoint Volume auf 6 TB anwachsen lassen. Der auf dem Quelllaufwerk belegte Speicherplatz ist nach den Bereinigungen nur noch 5 TB groß und somit auch der verwendete Speicherplatz auf dem Replica Volume. Irgendwann ist dann die Aufbewahrungszeit abgelaufen und der verwendete Speicherplatz auf dem Recoverypoint Volume sinkt auf unter 1 TB. Also werden im DPM Storage nur noch 6 TB verwendet, es sind aber 17 TB allokiert. Das Recoverypoint Volume konnte man nun shrinken – hoffentlich, denn es konnte unter bestimmten Umständen auch mal nicht funktionieren. Das Replica Volume lies sich aber nicht shrinken. Somit blieb man mit 12 TB allokiertem Speicherplatz bei nur 6 TB Verwendung zurück – 100% mehr Speicherplatz im DPM als die Datasource groß war. Um aus dieser Situation heraus zu kommen, musste man die Datasource im DPM reprotecten und die alten Backups löschen. Dadurch legte DPM ein neues Volumepaar an und somit auch ein kleineres Replica Volume.

mit Modern Backup Storage

MBS speichert die Backups nicht mehr auf dynamischen Volumes, sondern in VHDX. Für jede Datasource wird genau eine VHDX als „Replica“ angelegt. Alle weiteren Recoverypoints werden als VHDX-Clone auf dem ReFS Volume gespeichert. DPM kümmert sich hier selbstständig um die Vergrößerung und auch Verkleinerung der VHDX. Lediglich der Speicherplatz auf den DPM-Volumes an sich muss durch den Admin überwacht werden. Vergrößerungen der DPM-Volumes obliegen dem Admin und werden nicht automatisch von DPM durchgeführt.
Mit folgendem Befehl lässt sich der Status des Speicherplatzes der DPM-Volumes auslesen:

Get-DPMDiskStorage -Volumes -All | where {$_.AccessPath -LIKE "*SQL*"} | select Name, TotalSpace, UnoptimizedUsedSpace, OptimizedUsedSpace

Die Ausgabe des Befehls sieht wie folgt aus, die Werte sind in Bytes angegeben.

Modern Backup Storage - Speicherplatz Status
Speicherplatz Status

Das war’s für heute. Im nächsten Teil steige ich mit einem DeepDive in die Architektur von MBS ein. Es wird auf jeden Fall interessant! Ich verspreche auch, es dauert nicht wieder so lange bis dahin.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.