SharePoint Adventskalender 4. Woche

SharePoint BLOB Management – Shredded Storage und RBS “Better Together”

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

In den letzten beiden Türchen hatten wir jeweils den RBS und Shredded Storage im Fokus. Da jede der beiden Technologien ihre Vorteile hat, können wir uns überlegen, wie wir sie gemeinsam nutzen und was es dabei zu beachten gibt.

Die verschiedenen Funktionsweisen sind deutlich voneinander zu unterscheiden. Kurz zusammengefasst, lagert der RBS Dateien aus SQL aus, um die Datenbankgröße zu verringern und eine verbesserte Performance zu erhalten. Der Shredded Storage hingegen optimiert lediglich den Speicher, indem beispielsweise bei versionierten Dokumenten nur das Delta und nicht jeweils eine komplett neue Datei gespeichert werden muss. Die Daten bleiben jedoch im SQL! Dateien, die doppelt und dreifach über verschiedene Listen und Seiten gespeichert sind, belegen so auch mehrfach Speicherplatz. Durch Auslagerung kann diese „Dopplung“ jedoch durch den Windows Server Deduplication Service egalisiert oder zumindest minimiert werden.

Wir haben außerdem erfahren, dass jede Technologie auch ihre bestimmten Konfigurationen hat, um bestmögliche Ergebnisse zu erzielen. Das ist auf der einen Seite die Chunk-Größe des Shredded Storage und auf der anderen Seite der RBS-Grenzwert, also ab welcher Dateigröße ausgelagert werden soll. Und in der Tat, ist die Chunk-Größe geringer als der Grenzwert, so würde die Auslagerung nie aktiviert werden. Bitte beachten Sie daher diese Abhängigkeit, wenn Sie zum Shredded Storage auch eine Auslagerung in Echtzeit nutzen möchten.

Da solche Echtzeitprozesse jedoch sehr ressourcenhungrig sind, werden sie nicht mehr von Microsoft empfohlen. Stattdessen kann man bei RBS Providern von Drittanbietern konfigurieren, dass die Datei als Ganzes zählen soll und nicht nur die Fragmente betrachtet werden. Auch andere Regeln sind möglich, die nicht nur auf die Dateigröße abzielen.

Die Unterschiede und Funktionsweisen kennen wir nun. Aber für welche Szenarien ist welche Technologie am besten geeignet? Je nachdem, welche Fragen Sie in der folgenden Tabelle mit „Ja“ beantworten, umso mehr ist die entsprechende Technologie für Ihr Szenario besser geeignet. Können Sie Fragen in beiden Spalten mit „Ja“ beantworten, so wäre eine Kombination aus beiden Technologien das Beste für Sie.

Shredded Storage? Antworten Sie mit Ja!	RBS? Antworten Sie mit Ja!
Gibt es viele Transaktionen?	Haben Sie viele große Dateien (> 1 MB)?
Nutzen Sie die Versionierung?	Sind diese Dateien versioniert?
Haben Sie viele Office und xml-basierte Dokumente?	Haben Sie ein SQL-Speicher-„Problem“ (Inhaltsdatenbanken von mehr als 100 GB)?
Nutzen Sie intensiv das Co-Authering Feature?	Sollen die Backups der Inhaltsdatenbanken beschleunigt werden?
Haben Sie I/Ops und Netzwerkprobleme?	Haben Sie (bewusst) viele Datei-Duplikate in verschiedenen SharePoint-Bibliotheken (und möchten Sie die Deduplication nutzen)?

Beide Technologien erzielen Geschwindigkeitsvorteile gegenüber der bisherigen nativen Mittel. Noch interessanter wird es jedoch, wenn wir beide Technologien aufeinander abstimmen, um so alle ihre Vorteile anwenden zu können. Besonders im Szenario mit großen Dateien können in Kombination zusätzlich bis zu etwa80% verbesserte Downloadzeiten erreicht werden. Der Hintergrund ist die gestern angesprochene deutlich einfachere Verarbeitung von „vorgekürzten“ Fragmenten, als die gesamte Datei selbst in Pakete zerschneiden zu müssen.

Die allgemeinen Best Practices sind dafür 1250 KB als FileWriteChunkSize für den Shredded Storage und1024 KB für den RBS Grenzwert. Microsoft MVP Chris McNulty zeigt auch sehr schön im Detail, dass diese Werte je nach Dateigröße und Umgebung etwas variieren. Bei Interesse empfehle ich Ihnen daher sehr seinen Vortrag von der SharePoint Konferenz 2014: https://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC424.

Viel Spaß beim “SharePointen”!

 

SharePoint BLOB Management – Archivierung

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

In den letzten Tagen haben wir uns das BLOB Management von aktuellen Inhalten näher angeschaut und wie wir es optimieren können. Der Lebenszyklus von Inhalten sollte aber ebenso im BLOB Management berücksichtigt werden, weil der Datenbestand mit dem Alter des SharePoints exponentiell steigt. Besonders passive Daten beeinflussen diese Entwicklung.

Passive Daten sind beispielsweise Dateien, die veraltet und nicht mehr aktuell oder aus anderen Gründen nicht mehr relevant für die Aufbewahrung in SharePoint sind. Solche Dateien beeinflussen nicht nur die Performance, sondern tauchen auch immer wieder in den Ergebnislisten der SharePoint-Suche auf.

Sind die Daten im SharePoint nicht mehr aktuell, bzw. es ist aufwendiger für Endanwender, die aktuellen Daten zu finden, so sinkt auch die Nutzerakzeptanz. Dies ist neben der allgemeinen Geschwindigkeit des SharePoints ein sehr entscheidender Punkt.

Um die Daten nun aktuell zu halten, empfehle ich die Verwendung von Archiven. Dies kann mit dem SharePoint nativen Records Management realisiert werden. Dateien, die als Record markiert werden, können von einem Workflow „eingesammelt“ und zur Archivierung im Records Center abgelegt werden. Lösungen von Drittanbieter können noch weitere Funktionen in ein SharePoint-Archiv integrieren, sodass Dokumente, die beispielsweise seit drei Jahren nicht mehr bearbeitet oder gar geöffnet wurden, ganz automatisch in ein Archiv verschoben werden.

Auf diese Weise sehen Endnutzer auch stets nur die aktuellen Dokumente in den Suchergebnislisten. Für den Administrator kann außerdem die Größe der Inhaltsdatenbanken reduziert werden und dies sorgt für eine schnellere Bearbeitung der SharePoint-Anfragen an den SQL.

Das Archiv kann zusätzlich mit günstigeren Datenbanken betrieben werden, weil Microsoft geringere Anforderung an entsprechende Speicherlaufwerke stellt. Sie sehen also, wie viele Vorteile das Daten- und BLOB-Management über die Lebenszeit des SharePoint bringt. Machen Sie sich also bitte rechtzeitig Gedanken darüber, wie Dateien im SharePoint verwaltet werden sollen.

Viel Spaß beim „SharePointen“!

 

SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Disaster Recovery Plan

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

Backup kann jeder! Nur bei der Wiederherstellung aus einem Backup wird es interessant. Was alles berücksichtigt werden muss und Best Practices für Backup & Recovery Strategien möchte ich Ihnen in den letzten beiden Türchen unseres SharePoint Adventskalenders mitgeben. Wir schauen uns dafür folgende Kategorien an:

Heute: Service Level Agreement (SLA)

• Verstehen von RTO, RPO und RLO
• Komponenten und Backup-Umfang
• Kapazitätsplanung

Morgen: Disaster Recovery Plan

• Überwachung
• Recovery Scenarios
• Dokumentation

Verstehen von RTO, RPO und RLO:
Wenn wir mit SharePoint arbeiten als Kollaborationsportal arbeiten, so generieren wir darin viel Wissen (Intellectual Property – IP). Da immer mehr das IP den Wettbewerbsvorteil von Unternehmen definiert, muss es geschützt und gesichert werden. Es sind aber häufig dieselben Fragen, die mir bei Kunden begegnen:

• Haben wir überhaupt ein Backup?
• Wie lange brauchen wir, um ein einziges Objekt wieder herzustellen?
• Erfüllen wir immer unsere SLAs?
• Was ist unser Disaster Recovery Konzept?

All diese Fragen müssen in einem Disaster Recovery Plan beantwortet werden. Den Anfang machen die RTOs, RPOs und RLOs.

Recovery Time Objective (RTO):
Dies ist die Zeit, die benötigt wird, um alle Systeme nach einem Ausfall wieder zum Laufen zu bekommen. Darin fallen alle Verantwortlichkeiten und Prozesse, die durchlaufen werden müssen, um den letzten laufenden Zustand wieder herzustellen.

Recovery Point Objective (RPO):
Dies ist der maximal akzeptable Datenverlust und definiert damit, mit welcher Häufigkeit Backups durchgeführt werden müssen.

Addiert man die RTO und RPO, so erhalten wir die Zeitspanne, für die keine produktive Arbeit mit dem SharePoint möglich ist sowie bereits erledigte Arbeiten verloren gehen.

Recovery Level Objective (RLO)
Diese Deifnition wird oft vergessen, aber sie ist eine ganz Entscheidende, da sie die RTO und RPO beeinflusst. Die RLO soll bestimmen, mit welchem Granularitätslevel gesichert und wieder hergestellt werden kann. Sollen beispielsweise auch alle Metadaten, Berechtigungen, Nutzerdaten, etc. gesichert werden, so macht dies den Datenbestand komplexer. Dadurch können sich wiederum die Backupzeiten verlängern und ich muss vielleicht meine Backup-Fenster – das RPO – erweitern. Je komplexer die Daten sind, desto schwieriger wird in der Regel auch die Wiederherstellung. Besonders bei einer Single-Item-Wiederherstellung ist meine RTO unverhältnismäßig groß mit nativen Mitteln.

Somit müssen wir einen geeigneten Konsens finden, der zunächst niedrige RTOs und RPOs ermöglicht, aber idealerweise auch eine kleine Granularität erlaubt. Nähere ich mich diesen Zielen an, so steigen leider die Kosten auf der anderen Seite. Und genau diese Kosten stellen die nächste Variable in unserem Hebel für ein Backup Konzept dar. Eine allgemeingültige Regel über RTO, RPO und RLO, die für alle Unternehmen anwendbar ist, gibt es leider nicht. Die müssen Sie für Ihr Unternehmensrichtlinien selbst bestimmen.

Komponenten und Backup-Umfang:

Ein SharePoint besteht nicht nur aus den Inhaltsdatenbanken. Weiterhin sind die Service Applications zu betrachten, Farm-Solutions, InfoPath Formulare, IIS Settings, BLOB Storage und vielleicht noch weitere Anpassungen und Komponenten, wie z.B. Microsoft Project. Exemplarisch sehen Sie in der Abbildung links die Komponenten einer SharePoint 2013 Farm. Es wird also schnell deutlich, was Ihnen alles fehlt, wenn Sie nur auf die Inhaltsdatenbanken schauen. Dennoch wäre ein nahezu vollständiger Wiederaufbau der Farm nach einem Desaster prinzipiell möglich. Da wir dafür jedoch unzählige (manuelle) Schritte benötigen, läge die RTO weit außerhalb eines akzeptablen Niveaus.

Weiterhin bestehen bei der Wiederherstellung verschiedenste Abhängigkeiten. Einfaches Beispiel: es müssen Farm Solutions ausgerollt werden, bevor die Datenbanken wieder an die Web Application angehängt werden. Wir sehen also, wie komplex so eine Backup Strategie ist. Es gibt Drittanbieter-Lösungen, die Ihnen dabei viel abnehmen, weil sie automatisch verschiedenste Komponenten sichern und wiederherstellen können. Achten Sie dabei besonders darauf, ob diese Lösung SharePoint wirklich „versteht“. Beispielsweise würden wir mit einer Wiederherstellung der Konfigurationsdatenbank einen Zustand erschaffen, der unvorhersehbare Folgen hätte. Zudem würden wir den Support mit Microsoft verlieren. Das Data Protection Modul der Firma AvePoint ist beispielsweise so ein Produkt, dass SharePoint versteht und all die angesprochen Komponenten sichern und wiederherstellen kann. Die Microsoft Support Richtlinien werden dabei nicht verletzt.

Kapazitätsplanung:
Ein Backup von SharePoint benötigt Platz, aber die Speicherlaufwerke haben nur begrenzte Kapazitäten. Daher ist auch die Kapazitätsplanung ein wichtiger Bestandteil von SLAs im Rahmen eines Disaster Recovery Plans. Ist beispielsweise nicht mehr genügend Speicherplatz für ein neues Backup vorhanden, dann befinde ich mich sehr schnell außerhalb der definierten SLAs, weil das RPO nicht mehr eingehalten werden kann. Folgende Punkte müsse für die Kapazitätsplanung berücksichtigt werden:

1. Wie sichere ich?
   • Full Backup (alles wird zum eingestellten Zeitpunkt gesichert)
   • Differential (nur Änderungen seit dem letzten Full oder Differential werden gesichert)
   • Incremental (nur Änderungen seit dem letzten Full, Differential oder Incremental werden gesichert)
2. Wie häufig sichere ich?
   • Es ist wichtig zu klären, in welchen Zyklen ich sichere. Ein Zyklus zählt von einem Full Backup zum nächsten. Legen Sie also fest, wie häufig Full Backups durchgeführt werden sollen und welche Art Backups (DIFF oder INCR) Sie dazwischen nutzen möchten.
3. Wie lange halte ich die Sicherungen vor?
   • Dies hängt von Ihren Unternehmensvorgaben ab, bis zu welchem Zeitpunkt in die Vergangenheit Sie in der Lage sein müssen, Daten wieder herzustellen. Muss es z.B. möglich sein, Dateien wieder auf einen Zustand von vor 45 Tagen zu bringen, dann müssen die dazugehörigen Backups auch mindestens 45 Tage aufbewahrt werden.
4. Wie hoch ist die Änderungsrate meiner Inhalte?
   • Durchschnittlich kann angenommen werden, dass sich 10% meines Datenbestandes pro Woche ändert. Dies kann aber in Ihrem Szenario auch deutlich mehr oder weniger sein. Auch dies muss für die Kapazitätsplanung geklärt werden.

Basierend auf obigen Annahmen und Erfahrungen bei Kunden kann folgende Allgemeinregel angewendet werden:

Benötigter Speicherplatz = 1,5 x D x Z + D

D: Datenbestand der gesamten Farm (inkl. Service Datenbanken, etc.)
Z: Anzahl der Backup-Zyklen, die vorgehalten werden sollen

Wenn Sie diese drei Kategorien von heute beherzigen und Sie auf Ihr Unternehmen anwenden, sind Sie bereits sehr gut aufgestellt für das Durchführen von Backups. Damit haben Sie die „halbe Miete“. Noch wichtiger ist jedoch der Wiederherstellungsfall. Dies muss ebenso Teil eines Disaster Recovery Plans sein, was wir uns morgen als finalen Abschluss des SharePoint Adventskalenders genauer anschauen werden.

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

Im zweiten Teil zu unserem Disaster Recovery Plan geht es um

• Überwachung
• Recovery Szenarios
• Dokumentation

Überwachung:
Sind unsere regelmäßigen Backup-Pläne in Abstimmung auf die Unternehmens-SLAs eingerichtet und der benötigte Speicherplatz für die Backupdaten vorbereitet, so kann es nun losgehen. Es würde mich überraschen, wenn alles von Anfang an problemlos läuft.

Es können zum Beispiel plötzlich Ports geschlossen werden oder Datenbanken sind hinzu gekommen oder neue Lösungen wurden ausgerollt etc. Dies müssen wir für die Backup Jobs genau im Auge behalten und gegebenenfalls nachbessern. Denn ein fehlgeschlagenes Backup ist ebenso nutzlos, wie ein erfolgreiches, das aber entscheidende Komponenten für eine Wiederherstellung nicht berücksichtigt hat. Auch das gestern angesprochene Szenario mit dem mangelnden Backupspeicherplatz führt mich ganz schnell an die Grenzen meiner SLAs. Überwachen Sie daher sehr genau alle Komponenten Ihres Backups und greifen Sie gegebenenfalls pro-aktiv ein.

Recovery Szenarios:
Angenommen, alle Backup Pläne werden stets erfolgreich ausgeführt, sodass wir sichere Backupdaten haben. Was passiert, wenn der Ernstfall eintritt? Wissen Sie sicher, dass die Wiederherstellung aus den Backupdaten reibungslos funktioniert? Wie lange dauert es? Reicht die Zeit aus, um meine RTO einzuhalten?

Um diese Fragen beantworten zu können, müssen Sie sich realistische Wiederherstellungsszenarien schaffen, die Sie auch in regelmäßigen Abständen testen. Ganz wichtig sind dafür standardisierte Prozesse und Verantwortlichkeiten. Beispielhaft möchte ich folgende Szenarien vorschlagen:

1. Monatliche Tests:
   • Dokument / Listenelement
   • Spalte einer Liste / Dokumentbibliothek
   • Komplette Liste / Dokumentbibliothek
   • Komplette SharePoint Site (SubSite)
   • Eine gesamte Inhaltsdatenbank
2. Quartalstests:
   • Gesamte Web Application (inkl. Datenbanken, IIS, Authentifizierung, etc.)
   • Service Applications (z.B. Search, UPA, MMS, etc.)
3. Halbjährliche Tests:
   • Web Front End Server
   • Application Server
   • Index Server
4. Jährliche Tests:
   • Komplettes Disaster Recovery

Dokumentation:
Dieser Teil ist mit Sicherheit am unbeliebtesten, aber der wichtigste. Denn was bringen all die Bemühungen zuvor, wenn im Ernstfall niemand weiß, wer verantwortlich ist, weil der Administrator krank oder im Urlaub ist, welche Skripte oder Aktionen in welcher Reihenfolge auszuführen sind und was die Endbenutzer erwarten dürfen.

Eine klare Dokumentation – so aufwendig sie auch ist – nimmt diese Ängste und soll im Ernstfall das Handbuch sein, in dem die Antworten auf alle Wiederherstellungsfragen stehen. Im perfektesten Fall sollte man so einen Disaster Recovery Plan einem unbeteiligten in die Hand geben können und dieser weiß dann, was zu tun ist – auch wenn der Administrator im Urlaub ist. Innerhalb der Dokumentation müssen dafür klare und messbare Ziele definiert werden.

Nachfolgend ein paar Vorschläge, was zu den gestern und weiter oben erwähnten Punkten noch Teil eines Disaster Recovery Plans sein sollte:

1. Stakeholder:
   1. Für welche Personen im Unternehmen hat das Dokument Relevanz
   2. Dies können Kunden, Endnutzer, Administratoren und auch das Management sein
2. Aktueller Status:

2. • Aktuelle Farm Topologie
   • Eingespielte Anpassungen und Einstellungen
   • Abhängigkeiten
3. Richtlinien:
   • RTO (in Abhängigkeit der RLO, denn eine Single-Item-Wiederherstellung kann schneller gehen, als ein komplettes Disaster Recovery)
   • RPO
   • RLO
   • SLA
4. Verantwortlichkeiten (SharePoint, SQL, Plattform, AD, Netzwerk, etc.):
   • Für Backup Pläne
   • Für Wiederherstellung
5. Backup Strategien:
   • Was ist alles Bestandteil (Scope) von konfigurierten Backup-Plänen
   • Für welche Komponenten werden native Werkzeuge, für welche Drittanbieter verwendet
6. Wiederherstellungsprozesse:
   • In welchen Szenarien soll die gesamte Farm wieder hergestellt werden
   • In welchen Szenarien ist eine Single-Item-Wiederherstellung zu verwenden
   • Für welches Szenario werden native, wann werden Drittanbieterlösungen verwendet
   • Schritt-für-Schritt Anleitungen für die Wiederherstellung der einzelnen Komponenten
   • Gegebenenfalls Skripte und Konfigurationen
7. Regelmäßige Tests:
   • Idealerweise durchzuführen von Mitarbeitern, die nicht hauptverantwortlich sind und auch nicht den DR-Plan geschrieben haben – so können zusätzlich Ungenauigkeiten aufgedeckt werden
   • Festzuhalten sind:
     • Szenario
     • Zeitpunkt
     • Benötigte Zeit
     • Testergebnis
     • Kommentar

Und das wichtigste zum Schluss:

Ein Disaster Recovery Plan mit all den gestern und heute vorgestellten Komponenten ist ein “lebendes Dokument”! Genauso, wie sich Infrastrukturen, Backup- und Test-Szenarien sowie Ansprechpartner ändern, muss sich auch der DR-Plan anpassen, um stets auf dem aktuellen Stand zu sein. Wenn Sie all diese Tipps beherzigen, dann wird Ihnen ein Disaster Recovery keine Kopfschmerzen oder schlaflosen Nächte mehr bescheren.

À propos „bescheren“: Ich wünsche allen ein besinnliches Fest im Kreise Ihrer Liebsten, mit lecker Essen, vielen Geschenken und schönen Momenten auch mal ganz ohne SharePoint! 🙂