Schlagwort-Archive: Performance

FileShare Migration nach O365

9. Türchen

Nachdem wir gestern mit ein paar Tricks unseren FileShare vorbereitet haben oder zumindest die Daten sortiert haben, die wir migrieren möchten, steht heute die wirkliche Migration ins Haus. Wir wollen dabei nicht kleckern, sondern klotzen. Damit meine ich nicht, dass wir nicht lange warten wollen, um per CSOM langsam Daten hochzuladen oder eine Festplatte verschicken wollen, wofür es auch einige Limitationen gibt. Stattdessen wollen wir die – mittlerweile nicht mehr – neue High Speed Migration (HSM) API nutzen und Daten direkt über einen Azure Storage in eine SharePoint Online Bibliothek migrieren.

Dazu müssen wir aber folgendes beachten:

  • Die Pfadlängen im Ziel dürfen 255 Zeichen nicht überschreiten. Dies ist eine SharePoint Limitation, die wir im FileShare nicht kennen. Achtet daher darauf, dass eure Ordnerstruktur nicht zu tief ist, um dieses Limit nicht zu erreichen.
  • Sonderzeichen wie “ ? < > # % / \ werden in SharePoint nicht unterstützt
  • Dateien aus dem FileShare, die gerade von einem anderen Programm verwendet werden, sind gesperrt und daher auch nicht für den Migrationsprozess zugänglich.

Um nun loslegen zu können, müssen wir (neben dem Ziel-Tenant und einer Quellumgebung mit Daten) noch folgenden Dinge vorbereiten:

  1. Azure Verbindungs-Assistent
  2. Online PowerShell Module – Beides aus dem O365Adventskalender Türchen 6
  3. Azure Storage (Erstellung siehe unten)

Ok, dann starten wir nun in sechs Schritten.

1. Azure Storage erstellen

Diesen Storage brauchen wir, um das Migrationspaket in der Microsoft Cloud ablegen zu können. Ein komplett direktes Befeuern unseres SharePoints ist nämlich leider doch nicht möglich. Als Hinweis, der Storage muss aber nicht unter dem gleichen Tenant aufgehängt werden. Der Storage kann ganz woanders liegen – und auch unter einem anderen Konto laufen – als der Ziel SharePoint-Tenant. In unserem Test Tenant können wir uns auch einen Test Storage einfach konfigurieren.

  1. Im Azure Portal zu Speicher navigieren und ein neues Speicherkonto anlegen
    02a-fs-migration
    01a-fs-migration
  2. Anschließend werden wir gebeten, die Art des Speichers auszuwählen – in unserem Falle ein Testkonto – und unsere Identität per Telefonnummer und Kreditkarte zu überprüfen. Keine Sorge, es fallen wirklich keine Gebühren an, wenn man nicht explizit einem kostenpflichtigen Abo zustimmt.
    01-fs-migration 02-fs-migration
  3. Nun vergeben wir unserem Speicher einen Namen, der nur Kleinbuchstaben und Ziffern enthalten darf. Als Storage Replikation empfehle ich den Lokal Redundanten Speicher (LRS), da dieser einfach der günstigste Storage ist für 2,02 je 100 GB (aktuell) und für unsere (Test-) Migration völlig ausreichend ist. Die Ressourcengruppe, in der wir unseren Storage einordnen, muss auch noch einen Namen bekommen und die Region, die wir auswählen, sollte aus persönlicher Empfehlung immer nahe zu unserem Upload-Ort sein, denn die Verbindung der Speicher und Tenant untereinander ist von Microsoft extrem gut verkabelt. Also von welcher Azure Storage Region wir die Daten in SharePoint pumpen hat kaum einen Einfluss, aber natürlich unsere eigene Upload-Leitung zu einer entsprechenden Azure Storage Location schon.
    03-fs-migrationDie Bereitstellung des Speichers dauert nur wenige Sekunden bis Minuten. Danach finden wir unseren Storage Namen sowie den Storagy Key unter der Kategorie Zugriffsschlüssel. (für manche Prozesse ist auch die Application ID nötig, aber nicht für unsere Migration.)
    04-fs-migration
    05-fs-migration

 

2. Verbindungsaufbau zu O365

Zur Erinnerung, bevor wir mit PowerShell loslegen können, müssen wir zunächst der Verbindungsaufbau zu O365 aufbauen und die Module in der Azure PowerShell Konsole laden, die ihr als Administrator geöffnet habt:

  • $Creds = Get-Credentials
  • Import-Module Microsoft.Online.SharePoint.PowerShell -ErrorAction SilentlyContinue
  • Connect-SPOService -Credential $Creds -Url https://yourdomain-admin.sharepoint.com

3. Paket erstellen 

Nun haben wir alle Vorbereitungen getroffen, also erstellen wir uns nun ein Migrationspaket. Dabei geben wir mit, welche Dateien von dem FileShare inkludiert werden sollen. Daher ist die gestrige Vorbereitung so hilfreich gewesen. Ich habe versucht, in der Eingabeaufforderung die Variablen so eindeutig wie möglich zu formulieren, daher kommentiere ich es nicht weiter aus. Wenn ihr Fragen habt, einfach fragen! 🙂

Einen Hinweis noch: die Zielpfade müssen schon existieren, da im Konvertierungsprozess bereits eine Verbindung zum Ziel aufgebaut wird, um entsprechend die Daten zu mappen. Die PowerShell Befehle verwenden zudem die internen SharePoint-Namen. Also in Office 365 ist die „Documents“ Bibliothek intern immer noch die „Shared Documents“ MIT Leerzeichen, aber ohne „%20“. Darauf müsst ihr achten.

  • $QuellPfad =   „\\Server\C`$\FileShare\O365Migration“
  • $QuellPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket“
  • $ZielPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket-Output“
  • $Zielweburl = „https://yourdomain.sharepoint.com/sites/yoursite“
  • $Zielbibliothek = „FileShare“
  • $ZielOrdner = „OnlineMigration“ (optoinal)

 

  • New-SPOMigrationPackage -SourceFilesPath $QuellPfad -OutputPackagePath $QuellPaketpfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner –NoAzureADLookup

 

4. Paket konvertieren

Nachdem wir das Paket erstellt haben, müssen wir es in ein von SharePoint Online verständliches Format konvertieren. Dafür nutzen wir den ConvertTo-SPOMigrationTargetedPackage Befehl. Mit diesem Verbinden wir uns auch schon auf die zukünftige SharePoint Online Bibliothek, damit schon die Mappings auf die Zielbibliothek und Ordner vorgenommen werden können. Und ich kann sogar noch mehr mappen – nämlich Benutzer! Denn On-Premises Benutzer haben nicht immer genau die gleiche ID in O365. Ist das der Fall, macht also ein Mapping Sinn. Dazu müssen wir den -NoAzureADLookup Switch weg lassen, aber ersetzen ihn durch den -UserMappingFile Switch. Damit können wir eine CSV Datei referenzieren, in der für jeden Nutzer eine OnPremSID, UPN sowie eine Wahr/Falsch Angabe zur Gruppenzugehörigkeit angegeben wird. Was diese genau aussagen, seht ihr in der Tabelle:

OnPremSID UPN isGroup
Die Active Directory-SID des lokalen Benutzers oder der lokalen Gruppe (Windows/AD-Authentifizierung an der Quelle vorausgesetzt), die für den Nachschlag des Eintrags in der Datei UserGroup.XML verwendet wird. Der UPN (z. B. E-Mail-Adresse) des Kontos, der im Ziel verwendet werden soll. Handelt es sich bei dem Konto um eine Benutzer- oder Domänengruppe? (Gebt TRUE oder FALSE ein)

So eine CSV muss schon vor der Migration für alle Benutzer erzeugt worden sein, die vermutlich im Migrationspaket enthalten sein werden. Solltet ihr jedoch kein User Mapping brauchen, dann reicht nun also zum Konvertieren dieser Befehl:

  • ConvertTo-SPOMigrationTargetedPackage -SourceFilesPath $QuellPfad -SourcePackagePath $QuellPaketPfad -OutputPackagePath $ZielPaketPfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner -Credentials $Creds

 

5. Hochladen

Nun laden wir das neue Paket, das im Ordner kaum anders aussieht, als das erste Pakte, auf unseren Azure Storage hoch. Die entsprechenden Namen für unsere Pakete und Container dürfen übrigens auch nur Kleinbuchstaben und keine Sonderzeichen enthalten. Der Payload stellt dann die eigentlichen Daten dar und der PaketContainer das Manifest und Einstellungen für die Migration. Zusätzlich brauchen wir in diesem Schritt das Speicherkonto und den Schlüssel.

  • $PayloadContainer = „migrationayload“
  • $PaketContainer = „paketcontainer“
  • $AzureWarteschleife = „fileshareupload“
  • $AzureKontoName = „robtheninja“
  • $AzureStorageKey =“hierdeinazurekey==“

 

  • $Upload = Set-SPOMigrationPackageAzureSource –SourceFilesPath $QuellPfad –SourcepackagePath $ZielPaketPfad –FileContainerName $PayloadContainer –PackageContainerName $PaketContainer –AzureQueueName $AzureWarteschleife –AccountName $AzureKontoName -AccountKey $AzureStorageKey

Wer möchte, und wem der „Ladebalken“ in der PowerShell Konsole zu langweilig ist, der kann diesen Vorgang mit einem Explorer-Fenster verfolgen. Dazu gibt es auf Codeplex einen sogenannte Azure Storage Explorer, in dem das Ganze dann folgendermaßen aussieht.

08-fs-migration

Dieser Explorer ist auch sonst noch sehr nützlich, wenn man seinen Speicher auch noch für anderen Dinge verwendet, als nur zum Migrationsupload. Also schaut ihn euch wirklich einmal an.

 

6. Migration Starten

Das sieht ja nun schon mal gar nicht schlecht aus. Also müssen wir jetzt nur noch die Migration starten. Dies geht mit folgendem Befehl:

Submit-SPOMigrationJob –TargetwebUrl $Zielweburl –MigrationPackageAzureLocations $Upload –Credentials $Creds

Auch hier können wir mit dem Azure Storage Explorer den Migrationsfortschritt beobachten und schauen, welche Events in der Warteschleife hinzukommen.

08a-fs-migration

Optional können wir auch:

  1. den Status der Migration direkt in der Konsole abfragen mit
    Get-SPOMigrationJobStatus -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
  2. den Migrationsjob am Ende der Migration löschen mit
    Remove-SPOMigrationJob -JobId GUID -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
    Weitere Informationen zum Remove-SPOMigrationJob gibt es hier: https://technet.microsoft.com/en-us/library/mt143607.aspx

Mit diesen beiden Befehlen könnt ihr also direkt den Status abfragen und sicher den Prozess beenden. Mit dem Azure Storage Explorer seht ihr es auch, wenn in der Warteschleife (hier: Queue „fileshareupload“) ein Event „End“ auftaucht. Danach wird auch eine Log-Datei zum abgeschlossenen Migrationsjob in den Payload-Ordner (hier: „migrationpayload“) gelegt.

Im Ziel kommt dann in der Tat alles so an, wie es auf dem FileShare war, sogar mit Ordnerstruktur und den originalen Metadaten, wie Ersteller oder Erstellungsdatum (siehe Screenshot).

10-fs-migration

Sicherlich ist eine Migration mit Hilfe des Microsoft FastTrack noch einfacher, auch wenn selbst dies keine „White Gloves“ Migration ist. Und generell sind 82% aller Migrationen keine einfachen Migrationen. Aber für kleine Firmen und einfache FileShares ist dieser Ansatz mit der HSM API kein komplizierter. Ich kann nur empfehlen, einfach mal ausprobieren, mir hat es wirklich Spaß gemacht, wie schnell und einfach hier alles funktionierte. Ich drücke die Daumen, dass dies auch bei euch der Fall ist.

Weitere Informationen zum Datendurchsatz und möglicher Drosselung der API erfahrt ihr hier:
https://support.office.com/de-de/article/Migrationsgeschwindigkeit-von-SharePoint-Online-und-OneDrive-for-Business-21cfb6a0-fa4c-44c6-9a39-0f45e85e371f?ui=de-DE&rs=de-DE&ad=DE&fromAR=1

Sollte euch das dennoch zu stressig sein oder ihr habt einfach nicht die Zeit und Ressourcen, so ein Projekt durchzuführen, dann gibt es auch sehr gute 3rd Party Lösungen am Markt, die ebenfalls die HSM API nutzen, aber auch direkt ohne Storage mit Multi-Threading die Daten hochladen können – und das Ganze nicht nur von FileShares, sondern auch Notes, LiveLink, Documentum, etc. Immer optimistisch denken, für jedes Problem, gibt es eine Lösung. 🙂

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

Konfigurieren des Windows Performance Monitors

In Anlehnung an das Performance Monitoring aus meinem SharePoint Adventskalender gibt es noch ein paar Dinge, die man beachten sollte, wenn man sich ein Performance Counter Set zusammmen stellt. In diesem Beitrag möchte ich daher erläutern, wie Sie sich ein Set erstellen und worauf man dabei achten muss, um im Anschluss auch valide Daten auswerten zu können.

Auch wenn es natürlich auch 3rd Party Software gibt, welche unsere Rechner-Systeme überwachen kann, so bringt Windows Server aber bereits selbst sehr viele Messgrößen mit, die man ganz einfach mit dem mitgelieferten Performance Monitor (perfmon.exe) überwachen kann. Um sich nun ein Collector Set anzulegen, gehen Sie folgendermaßen vor.

1. Im PerfMon-Fenster navigieren Sie zu den Data Collector Sets > User Definied. Mit einem Rechtsklick oder über den Button oben im Fenster beginnen Sie, ein neues Set anzulegen.

2. Vergeben Sie dem Set einen aussagekräftigen Namen und wählen Sie, ob Sie mit einer Vorlage oder mit einem leeren Set starten möchten. Haben Sie bereits ein Collector Set angelegt (als xml-Datei gespeichert), so können Sie auch dieses als Vorlage auswählen. Hinweis: Ein unter Windows Server 2012 angelegtes Set kann zwar in frühere Serverversionen eingelesen werden, jedoch kann es nicht gestartet werden. Bitte beachten Sie dies, wenn Sie ein Set aus einer Vorlage erstellen möchten.

3. Auf der Folgeseite sehen Sie, dass Sie den PerfMon auch als Werkzeug nutzen können, um sich beim Über- oder Unterschreiten eines Grenzwertes informieren zu lassen. Auch andere Aktionen können ausgeführt werden. Dies ist natürlich ein sehr schöner Ansatz, um pro-aktiv die Systeme zu überwachen.

Ebenso können Sie aber auch re-aktiv z.B. Daten über Registry-Einträge („System Configuration Information“) oder Events verschiedener Dienste wie exemplarisch der Firewall („Event Trace Data“) sammeln und überwachen. Und dies gilt auch für den Performance Counter Fall, den ich beschreiben möchte. Dafür haben wir folgendes Szenario: Unser SharePoint ist bereits langsam und nun wollen wir heraus finden, woran es liegt. Wir wählen also die Performance Counter.

4. Auf der Folgeseite können wir nun unsere verschiedenen Counter auswählen. Welche ich für SharePoint empfehle, können Sie in meinem Adventskalender, Türchen 9-12, nachlesen (Bsp.: http://blogs.msdn.com/b/robert_mulsow/archive/2015/12/09/sharepoint-performance-monitoring-performance-counter-f-252-r-den-prozessor.aspx). Bitte achten Sie darauf, dass Sie in diesem Fenster auch die Intervallzeit einstellen. Ich empfehle bei längeren Überwachungen ein Intervall von 60 Sekunden. Damit wachsen die Logs auf nicht mehr als wenige MB an, wenn Sie einen Überwachungszeitraum von 24 Stunden wählen.

5. Ganz wichtig bei der Auswahl der Counter ist, für welche Quellen die Daten aufgezeichnet werden sollen. Zum Beispiel haben unsere Server mehr als eine Netzwerkkarte oder mehr als ein Laufwerk. Möchte Sie beispielsweise ein Problem bei den Disk I/Ops überwachen und wählen „_Total“ aus, dann wird der Durchschnitt über alle Laufwerke gesammelt. Sind also vier von fünf Laufwerken optimal eingerichtet, aber das Fünfte und vielleicht Wichtigste ist es eben nicht mit einer Disk Queue Length von über 10, dann komme Sie bei der Auswertung leider nicht der Ursache für eine langsame SharePoint Performance auf die Schliche. Achten Sie also darauf, dass Sie wirklich die einzelnen Laufwerke auswählen. In meinem Screenshot sind dies die Laufwerke C: und D:, die ich überwachen möchten.

6. Haben Sie alle Counter ausgewählt, dann können Sie auf der Folgeseite noch den Ort auswählen, wo die Logs gespeichert werden sollen.

7. Im letzten Schritt achten Sie bitte darauf, unter welchem Benutzer die Daten gesammelt werden sollen. Standardmäßig ist dies der lokale System Account.

Die Auswahl des Benutzers ist besonders wichtig, wenn die Daten zusätzlich für andere Computer in einem Set gesammelt werden sollen. Unter Schritt fünf können Sie im Screenshot erkennen, dass die Daten für den „Local Computer“ gesammelt werden. Wenn Sie jedoch auch Daten von anderen Computern sammeln möchten, muss der Benutzer auch über die entsprechenden Rechte auf den anderen Rechnern verfügen. Der lokale System Account hat diese Rechte natürlich nicht. Verwenden Sie also einen Benutzer, der sich auf den anderen Rechnern auch in den Gruppen „Performance Monitor Users“ und „Performance Log Users“ befindet.

 

(Auf älteren Windows Systemen Microsoft .NET Framework 2.0 muss zusätzlich der RemoteRegistry Service auf den Rechnern laufen, auf die „aus der Ferne“ zugegriffen werden soll.)

Damit ist das Anlegen des Performance Counter Sets abgeschlossen. Wenn Sie diese Sets nun zu einem bestimmten Zeitpunkt starten möchten, können Sie dies direkt tun, indem Sie diesen manuell starten. Mann kann dies aber auch takten. Dazu empfehle ich, eine Stopp-Kondition zu deifnieren. Das einfachste Beispiel ist das Stoppen nach 24 Stunden.

 

Anders kann man die Sets auch jeden Tag zu einer bestimmten Zeit starten und nach z.B. vier Stunden stoppen. Ein Szenario, um beispielsweise die Backup Performance jede Nacht zu überwachen.

Welches Szenario Sie auch haben, die zusätzlichen Informationen, die mir der Performance Monitor liefern kann, helfen deifnitiv, um den Ursachen meiner Performance-Probleme auf die Schliche zu kommen. Denn die alte Weisheit „wir brauchen mehr RAM“ löst leider nicht alle Probleme.

 

 

SharePoint BLOB Management – Archivierung

SharePoint Adventskalender – 22. Türchen

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 Dokumenten in den Suchergebnislisten. Für den Administrator kann außerdem die Größe der Inhaltsdatenbanken reduziert werden und dies sorgt für eine schnellere Bearbeitungen 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“!

————————————————————-

Weitere Türchen:

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

SharePoint Adventskalender – 21. Türchen

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, in dem 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 Auslagerungen 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 nach dem, 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“ (Inhaktsdatenbanken 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 etwa 80% verbesserte Downloadzeiten erreicht werden. Der Hintergrund ist die gestern angesprochene deutlich einfachere Verarbeitung von „vorgekürzten“ Fargmenten, 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 und 1024 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”!

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – Shredded Storage

SharePoint Adventskalender – 20. Türchen

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

————————————————————-

Seit Microsoft den Shredded Storage für SharePoint 2013 herausgegeben hat, kursieren verschiedene Mythen und Gerüchte über Best Practices und die kombinierte Anwendung mit dem Remote BLOB Storage (RBS) bei IT-Administratoren. So habe ich bei Kunden bereits gehört, dass RBS als Synonym für Shredded Storage verwendet wurde. Außerdem hört man, dass aufgrund der kleinen Datei-Chunks, der RBS-Grenzwert nie berührt wird, oder aber, dass Shredded Storage den RBS sogar obsolet macht.

Um mit diesen Mythen aufzuräumen und Best Practice Empfehlungen geben zu können, besonders in der Kombination des Shredded Storage mit RBS, konzentrieren wir uns heute zunächst auf die Spezialitäten des Shredded Storage.

Abstrakt betrachtet macht der Shredded Storage Algorithmus folgendes:


Technisch sieht dies aber natürlich etwas anders aus. Einfach gesprochen ist der Shredded Storage die Aufteilung einer Datei in viele kleine Teile, sogenannte Chunks. Die „FileWriteChunkSize“ ist dabei der Wert, der angibt, wie groß die Fragmente beim Schreiben in den SQL sein dürfen. Es sind jedoch nicht alle Teile gleich groß, denn z.B. der Header und Footer der Datei kann eine andere Größe haben. Diese Architektur lässt somit auch erahnen, dass eine Datei im Shredded Storage Konzept zunächst etwas größer ist, als im alten Format, da mehr Informationen gespeichert werden müssen, um die einzelnen Chunks am Ende wieder zusammensetzen zu können. Sobald jedoch erste Änderungen einer Datei mit Versionierung gespeichert werden, wird dieser anfängliche Mehrbedarf an Speicher wieder egalisiert.

Der Algorithmus macht auch keine Unterschiede mehr zwischen Office Dokumenten, Bildern oder anderen Dateitypen. Er versucht grundsätzlich jedes Dokument in Chunks zu zerlegen. Je nach Dateityp und Komplexität der Datei kann dies besser oder schlechter funktionieren. Zum Beispiel: Bei einem meiner Kunden hat eine neue Version einer PowerPoint-Datei fast die gleiche Größe gehabt, wie die Erstversion. Normalerweise sollte mit dem Shredded Storage aber nur das Delta, also beispielsweise die kleine Änderung im Titel, neu gespeichert werden und nicht das gesamte Dokument. Offensichtlich konnte der Algorithmus die Datei aber nicht in kleinere Chunks zerlegen.

Ziele des Shredded Storage:
Während das Hauptziel des gestern vorgestellten RBS die Auslagerung von großen Dateien ist, so verfolgte Microsoft bei der Entwicklung des Shredded Storage folgende vier Ziele:

  1. Bandbreitenoptimierung
    • nur noch Teile einer gesamten Datei müssen gesendet werden
    • dies ermöglicht und verbessert auch das Co-Authoring bei Office-Dokumenten
  2. I/Ops optimieren
    • durch kleinere Datenpakete werden die I/O Muster geglättet
    • es wird realisiert, dass Schreibkosten proportional zur Größe der Änderungen sind
    • es müssen weniger Änderungen an den SQL gesendet werden (nur Delta, nicht gesamte Datei). Dies verkleinert die Transaction Logs und erhöht damit auch die Backup-Performanc
  3. Storage reduzieren
    • es werden nur noch die Änderungen gespeichert, nicht erneut die gesamte Datei
  4. Sicherheit
    • es ist nun schwieriger eine gesamte Datei mit einem PowerShell-Befehl auszulesen
    • mit aktivierter Verschlüsselung kann jedes Datei-Chunk einzelnd verschlüsselt werden

Best Practice:
Basierend auf mehreren Tests mit unterschiedlichen Dateigrößen hat sich ergeben, dass eine FileWriteChunkSize von 1250 KB die beste Performance für Up- und Downlaods erzielt. Je nach Umgebung sowie Art und Größe der Daten, kann auch ein etwas höherer Wert Sinn machen. Als Beispiel, beim Microsoft Cloud-Storage OneDrive werden 2 MB verwendet. Allerdings sollte der Wert nicht größer als 4 MB sein. Warum? Der Hintergrund ist, dass viele System-Operationen Änderung in 4 MB Paketen verarbeiten. Kommt nun ein größeres Datenpaket, so wird dies nur in 4 MB Schritten gelesen – also in 4 MB Pakete „zerschnitten“. Das verursacht einen signifikanten Anstieg der I/Ops. Stattdessen sind zuvür „gekürzte“ Fragmente durch den Shredded Storage deutlich einfach zu verarbeiten.

„For Your Information:“

  • Zusätzlich zu der FileWriteChunkSize gab es auch noch die FileReadChunkSize. Diese Variable sollte zusätzlich die Größe der Pakete definieren, in denen die Daten ausgelesen werden. Da dies aber keine entscheidenen Vorteile brachte, wurde diese Einstellung wieder abgekündigt und man verwendet nur noch die FileReadChunkSize.
  • In SharePoint 2016 wird der Shredded Storage nicht mehr mit dem Cobalt, sondern mit dem BITS (Background Intelligent Transfer Service) Protokoll arbeiten. Damit sind zusätzliche Vorteile möglich, wie z.B. das Unterbrechen und Fortsetzen von Übertragungen (für mehr Stabilität) oder die Verwendung von ungenutzten Netzwerkresourcen zur Übertragung (um nicht andere Netzwerkaktivitäten negativ zu beeinflussen)

Zur Vollständigkeit hier noch die PowerShell Befehle, um den Shredded Storage zu konfigurieren. Achten Sie darauf, dass der Wert nur für die gesmate Farm konfiguriert werden kann, auch wenn der allgemeine PS-Ansatz etwas anderes vermuten lässt. Dies liegt daran, dass der Shredded Storage ein Web Service ist. Sollten Sie also den Shredded Storage im „gewöhnlich“ Fall mit einer bestimmten Web Application konfigurieren, behalten Sie im Hinterkopf, dass die anderen Web Applications dieses Wert auch übernehmen. Die folgenden Befehle machen diesen Sachverhalt deutlich:

Casual:
$webapp = Get-SPWebApplication http://WebAppUrl
webapp.WebService.FileWriteChunkSize =
chunk size in Bytes
$webapp.webservice.update()

Formal :
[void][System.Reflection.Assembly]::LoadWithPartialName(„Microsoft.SharePoint“)
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$service.FileWriteChunkSize = 1280000
$service.Update()

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – BLOB Cache

SharePoint Adventskalender – 18. Türchen

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

————————————————————-

Heute und in den nächsten Kalendertürchen widmen wir uns dem BLOB Management für optimierte Speicherlaufwerke und der daraus resultierenden Verbesserung unserer SharePoint Performance.

Nach einer Umfrage der AIIM (Association for Information and Image Management) verzeichnen Firmen ein Datenwachstum von 50-75% pro Jahr. Durchschnittlich sind dabei von allen Daten 20% strukturiert und 80% unstrukturiert oder semi-strukturiert. Der nicht strukturierte Anteil wird in den meisten Fällen von BLOBs (Binary Large Objects) repräsentiert.

Leider ist aber die Funktionsweise eines Datenbanksystems und damit auch SQL dafür optimiert, kleine Informationspakete aus den verschiedenen Datenbanken und Tabellen zu kummulieren. Dies würd über „Queries“ realisiert und die Ergebnisse an den „Anfrager“ zurück geschickt. Die dazugehörigen Algorithmen können jedoch gar nicht gut mit großen Dateien (BLOBs) umgehen. Eine Anfrage auf eine einzige Datei mit einer Größe von 10 MB wird besipielsweise von SQL langsamer bedient, als würde ich sie direkt über das Netzwerk von einem File-Share laden. Somit ist klar, warum ein optimiertes BLOB Management große Performance-Verbesserungen für die Endnutzer bringt.

Beginnen wir mit dem vermutlich bekanntesten Ansatz, dem SharePoint BLOB Cache. Dieser speichert Dateien auf den WFEs, sodass SQL diese nicht bei einer erneuten Anfrage laden muss. Den Vorgang kann man sich vereinfacht folgendermaßen vorstellen:

 

Wie man sieht, ist auch hier der „frühe Vogel“ etwas langsamer unterwegs, weil er zunächst durch seinen Request den Cache des Servers „füttert“. Wird er bei einer Aktualisierung auf einen anderen WFE durch den Load Balancer geroutet, so muss auch da der Cache zunächst befüllt werden. Bei kleinen Bildern ist der Cache-Vorteil kaum zu spüren. Aber wenn wir von Dateien jenseits der 10 MB-Grenze reden, dann werden die Geschwindigkeitsunterschiede schnell deutlich.

Damit die jeweilige Datei zum Rendern schnell wieder gefunden werden kann, wird ein BLOB Cache Index erzeugt. Der Umfang dieses Index kann bei extrem vielen verschiedenen Dateien im Cache auch durchaus etwas größer werden. Im RAM-Speicher werden dafür etwa 800 Bytes pro Eintrag benötigt. Achten Sie daher darauf, welche Werte Sie für den BLOB Cache in der web.config-Datei der jeweiligen Web Application IIS-Webseiten konfigurieren. Sie können dabei definieren, welche Dateien ge-cached werden sollen und wie groß der Cache maximal werden darf (Angabe ist in GB! – standard sind 10 GB). Der ObjectCache definiert hingegen, wie viel vom Arbeitsspeicher für das Caching maximal verwendet werden darf (Standard = 100 MB!).

Der BLOB Cache ist jedoch nicht für alle Szenarien gut geeignet. Entscheiden Sie selbst, welche der beiden folgenden Szenarien bei Ihnen zu finden ist und werden Sie entsprechend tätig.

BLOB Caching besonders nützlich

BLOB Caching weniger nützlich

Seiten und deren Inhalte werden häufig besucht Weniger häufig genutzte Dateien
Vor allem “Rich Media”, also größere Dateien, wie Videos, sind solche Inhalte Dateien, die häufig geändert werden

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Request Management Service

SharePoint Adventskalender – 17. Türchen

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

————————————————————-

Bei dem heutigen Thema schauen wir uns einen weniger bekannten Service an, der jedoch sehr interessante Funktionen für uns bereit hält. Die Rede ist vom Request Management Service. Dies ist eine Art Load Balancer hinter dem Load Balancer. Damit kann SharePoint selber bei ankommenden Anfragen entscheiden, ob wirklich der vom Load Balancer zugewiesene WFE die Anfrage bearbeitet, oder ob noch einmal zu einem anderen WFE geroutet wird.

Ein Load Blanacer, wie der F5, arbeitet für ein Netzwerk-Load-Balancing während das Request Management (RM) auf Application-Eben die Last verteilt. Dazu können Throttling Regeln zum „bremsen“ und Routing Regeln zum priorisieren verwendet werden. Der Service ist standardmäßig ausgeschaltet, aber kann pro Web Application über PowerShell konfiguriert werden.

Funktionsweise:
Jedem Server kann über PowerShell ein statischer „Health“-Wert gesetzt werden. Zusätzlich prüft SharePoint alle 5 Sekunden die dynamische „Health“ jedes WFE Servers. Die Skala geht von 0 („am gesündesten“) bis 10. Bekommt ein Server drei mal hintereinander den Wert 10 (z.B. weniger als 20 MB RAM verfügbar), drosselt das RM die Anfragen auf diesem Server. Damit kann verhindert werden, dass ein Routing vom Load Balancer zu einem hängenden Server keine Fehlermeldung beim Endnutzer generiert. Stattdessen wird die Anfrage neu geroutet. Der Request Service fungiert praktisch als Proxy und erstellt eine neue Anfrage, die der alten zwar gleicht, jedoch zu einem neuen WFE geht.

Ablauf:

Zunächst kommt eine Abfrage vom Endnutzer oder vom Load Balancer am SharePoint an.

  1. Dieser evaluiert den Request anhand definierter Regeln. Diese können Eigenschaften (Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader) oder Methoden (StartsWith, EndsWith, Equals, RegEx) überprüfen.
  2. Mögliche Server werden anhand der Regelkriterien und/oder der Server-Gesundheit identifiziert (siehe Bild unten)
  3. Nach Identifizierung des Servers wird der Request dorthin geroutet (bzw. gebremst, bei Throttling Regel).

Regeln werden innerhalb von drei Gruppen (Execution Groups 0 bis 2) zusammengefasst und entsprechend priorisiert. Diese Gruppen repräsentieren Servergruppen, zu denen geroutet werden soll.

  1. Gruppe 0 wird als erste geprüft.
  2. Gibt es keinen Match, werden die Regeln von Gruppe 1 geprüft.
  3. Gibt es ein Match, werden alle Regeln einer niedrigeren Priorität (Execution Group 2) verworfen und der Request direkt bearbeitet.

Gäbe es auch in Gruppe 2 keinen Match, dann wird der Request zu irgendeinem Server geleitet – aber nur dann, wenn ich mindestens in die letzte Gruppe auch eine Art „Catch-All“ Regel definiere, die alle nicht geregelten Anfragen abarbeitet (sollten keine weiteren „freien“ WFE außerhalb der Execution Gruppen existieren).

Vorteile:

  • Ablehnen gefährlicher Anfragen (z.B. von bestimmten Quellen)
  • Priorisieren von Anfragen basierend auf Server-Health und Regeln (z. B OneNote Verkehr immer über Server1; Search Crawler immer auf Server4; neuere Server mit mehr Resourcen können mehr Anfragen übernehmen, etc.)
  • Anfragen können „umgeschrieben“ werden mit beispielsweise sogar einem anderen Port
  • Traffic Isolierung zur Fehleranalyse (z.B. von einer bestimmten Site Collection zu einem bestimmten Server)
  • Regeln kann man auch ein Ablaufdatum mitgeben, sodass spezielle Routings automatisch enden

Nachteile:

  • Zusätzliche Last auf den WFE-Servern durch den RM Service
    Oder besser: Den RM Service auf einem dedizierten Server laufen lassen, z.B. gemeinsam mit einem Distributed Cache Service

Beispiele:

Erstellen einer Routing Regel, um alle Anfragen für Word Dokumente für Web Application http://intranet.contoso.com zum WFE „Server1“ zu leiten.

  1. Request Manager Service auf den WFEs aktivieren:
    1. Central Administration im Browser öffnen
    2. Zu Manage Services navigieren
    3. Request Management Service starten
  2. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  3. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  4. Erstellen eines neuen Filter-Kriteriumsmit der “Url” Eigenschaft und RegEx für alle Dokumente vom Typ DOCX
    • $Krit = New-SPRequestManagementRuleCriteria -Property Url -Value „.*\.docx“ -MatchType Regex
  5. Sollte dies die erste Regel sein, die wir erstellt haben, müssen wir auch einen Server-Pool erstellen, zu dem diese Anfragen geroutet werden sollen.
    • $Pool = Add-SPRoutingMachinePool -RequestManagementSettings $RM -Name AdventsPool -MachineTargets ($RM | Get-SPRoutingMachineInfo -Name Server1)
  6. Nun kann die Routing-Regel mit obigen Server-Pool und Filter-Kriterium angelegt werden
    • $RM | Add-SPRoutingRule -Name „DOCX Regel“ -Criteria $Krit -MachinePool $Pool
  7. Fertig und testen! (ULSViewer is your friend…)

Erstellen einer Throttling Regel, um Anfragen von OneNote auf die Web Application http://intranet.contoso.com zu bremsen, wenn der Health-Wert 8 ist.

  1. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  2. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  3. Hinzufügen eines neuen Kriteriums für OneNote 2010 Anfragen. Dies kann über den UserAgent im Request realisiert werden.
    • $Krit = New-SPRequestManagementRuleCriteria -Property UserAgent -Value „.*Microsoft Office OneNote 2010*“ -MatchType Regex
  4. Nun fügen wir die Throttling Regel für die Server-Health 8 hinzu.
    *Hinweis: Throttling Regeln gelten im Gegensatz zu Routing Regeln für die gesamte Farm und nicht für einzelne Server(-Pools). Daher müssen wir hier keinen Server-Pool mit angeben.

    • $RM | Add-SPThrottlingRule -Name „OneNote Throttle Rule“ -Criteria $Krit –Threshold 8

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Distributed Cache Service

SharePoint Adventskalender – 16. Türchen

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

————————————————————-

Heute wenden wir uns dem in SharePoint 2013 neu eingeführten Distributed Cache Service zu. Dieser basiert auf dem „AppFabric Distributed Caching“ Dienst, der unter der Windows Service Konsole läuft. Er wurde dazu konzipiert, unter anderem Authentifizierungs-Tokens vom Security Token Service (STS) für den „sozialen“ Teil der MySite zu speichern. Diese zwischengespeicherten Daten sind über alle Cache-Server verteilt.

Der Vorteil dieser Technologie ist, dass Daten schnell aus dem Cache geladen werden können. Die Nachteile:

  1. Die Daten sind leider genau so alt, wie die letzte „Cache-Fütterung“. Nämlich der Timer Job mit dem Namen “User Profile Service – Feed Cache Repopulation Job” ist dafür zuständig, den Cache mit aktuellen Feeds zu füttern. Unabnhängig davon wird dieser Vorgang auch immer dann getriggert, wenn auf entsprechende Seiten zugegriffen wird. Gehe ich also auf meine MySite, so wird diese schnell aus dem Cache gerendert. Aber im Hintergrund fragt SharePoint erneut an, ob denn nicht schon aktuellere Daten für die Feeds vorhanden sind. Ist dies der Fall, wird der Cache damit versorgt und bei einem Refresh, bzw. beim nächsten Aufruf der MySite, werden dann eben diese aktualisierten Cache-Daten gerendert. Hinweis: Der Feed-Cache Timer Job läuft zusätzlich alle 5 Minuten nach Standardeinstellung.
  2. Geht ein Cache Server vom Netz, fehlen die dort gespeicherten Daten und müssen erst erneut geladen werden. Den Nachladeprozess all dieser Daten kann man folgendermaßen beschleunigen:
  • Den User Profile Service – Feed Cache Repopulation Job manuell starten oder
  • Folgende PowerShell-Befehle verwenden:
    – Clear-SPDistributedCacheItem
    – Update-SPRepopulateMicroblogLMTCache
    – Update-SPRepopulateMicroblogFeedCache

Sollte einmal bewusst geplant sein, einen solchen Server vom Netz zu nehmen, kann man auch pro-aktiv die gespeicherten Daten auf die anderen Server verteilen:

  • Stop-SPDistributedCacheServiceInstance -Graceful

Infrastrukturplanung:
Zu jeder SharePoint Farm muss auch mindestens ein Cache Host existieren, also ein Server, der den Distributed Cache Service hosted. Der – bzw. in einer größeren Farm mindestens ein – Cache Service sollte auch auf dem gleichen Server laufen, wo die User Profile Application (UPA) läuft. Andernfalls kann es vorkommen, dass sich der oben erwähnte “User Profile Service – Feed Cache Repopulation Job” nicht mit der UPA verbinden kann.

Zudem sollten Sie bei Farmen mit mehr als vier Servern explizit den Distributed Cache Service auf einem oder mehr Servern stoppen. Eine Verteilung von Cache-Daten auf zu viele verschiedene Server würde nämlich im Endeffekt die Performance negativ beeinflussen.

Weiterhin gibt es zur Planung des Distributed Cache Service folgendes zu beachten. Jeder Cache Server benötigt etwa 50% seiner Leistung für einen sogenannten RAM-Speicher-Overhead. Also administrative Aufgaben, um die tatsächlich gecachten Informationen zu verwalten. Damit wird empfohlen, Server mit maximal 16 GB RAM als Cache Server zu hosten. Prinzipiell sind auch größere Speicher möglich, aber durch den Overhead würde es bei einem Cache-Flushing so wirken, als sei der Server „eingefroren“. Dies ist nicht optimal für die „Nutzererfahrung“.

Neben den max. 16 GB RAM sollten auch etwa 2 GB für das Betriebssystem reserviert werden. Als Grundlage haben wir somit 14 GB für den Cache, wovon die eine Hälfte (7 GB) tatsächlich für den Cache und die andere Häfte für den administrativen Overhead genutzt werden soll. Somit teilen wir die gesamte benötigte Cache-Kapazität durch 7 und erhalten die Anzahl für die benötigten Cache Server.

Cache Bedarf / 7 GB = Anzahl nötiger Cache Server

Den Cache Bedarf gibt Microsoft anhand der Nutzer pro Farm mit folgender Tabelle an:

Bereitstellungsgröße Kleine Farm Mittlere Farm Große Farm
Gesamtzahl der Benutzer < 10.000 < 100.000 < 500.000
Empfohlene Cachegröße für den verteilten Cachedienst 1 GB 2,5 GB 12 GB
Gesamtspeicherzuordnung für den verteilten Cachedienst (doppelter Wert der oben empfohlenen Cachegröße, plus Reserve von 2 GB für das Betriebssystem) 2 GB 5 GB 34 GB
Empfohlene Architekturkonfiguration Dedizierter Server oder auf einem Front-End-Server Dedizierter Server Dedizierter Server
Mindestanzahl von Cachehosts pro Farm 1 1 2

Quelle: https://technet.microsoft.com/de-de/library/jj219572.aspx

Berechtigungen:
Weiterhin zu beachten ist die Berechtigung des Service Acconts, unter dem der Distributed Cache Service läuft. Ähnlich wie beim User Profile Service sind temporär erhöhte Berechtigungen (Local Admin) für das Einrichten erforderlich, um die Tokens vom STS ziehen zu können. Danach können diese Berechtigungen wieder genommen werden. Da es beispielsweise hin und wieder vorkommt, dass der Service neu gestartet werden muss oder andere administrative Eingriffe erforderlich sind, empfehle ich, die erhöhten Berechtigungen dauerhaft zu belassen. Dies widerspricht zwar dem „Least-Privilege“ Ansatz von Microsoft, erleichtert aber die Administration und Fehelerbehebung im Störungsfall.

Viel Spaß beim „SharePointen“

Hinweis:
– Die MySite wurde von Microsoft wieder abgekündigt und wird in O365 bereits durch Delve ersetzt.
– Weitere Informationen zum Distributed Cache Service finden Sie hier: https://technet.microsoft.com/de-de/library/jj219613.aspx?f=255&MSPPError=-2147217396

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Super User und Super Reader

SharePoint Adventskalender – 15. Türchen

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

————————————————————-

Besondere Funktionen erfordern besondere Einstellungen. Bei einem Feature ist das besonders wichtig. Die Rede ist von dem „SharePoint Server Publishing Infrastructure“ Feature oder auf deutsch, der „SharePoint Server-Veröffentlichungsinfrastruktur“.

Was ist an dieser Funktionalität so besonders? Die Veröffentlichungsinfrastruktur ist dazu gedacht, den SharePoint auch dafür zu nutzen, um reine Intranet- oder sogar Internetseiten zu hosten. Wichtig dabei ist, dass der Inhalt stets auf dem aktuellen Stand ist. Für Aktualisierungen werden von Dateien (Seiten) Zwischenversionen erstellt. Die Änderungen werden erst nach Veröffentlich einer neuen Hauptversion für alle Nutzer sichtbar. Dies ist natürlich auch für normale Kollaborationsszenarien denkbar, aber der Hauptfokus dieses Features liegt auf dem Veröffentlichen von Intranet- oder Internetseiten.

Das wichtigste Kriterium für eine erfolgreiche Intranetpräsenz ist ein schneller Seitenaufbau. Die Veröffentlichungsinfrastruktur nutzt dafür einen dedizierten Objekt-Cache. Wenn nun jeder Besucher durch den Aufruf einer entsprechenden Seite eine Anfrage an den SQL sendet, muss dieser auch jede einzelne bedienen. Erst bei jeder zweiten Anfrage der gleichen Seite würde der Cache tatsächlich greifen. Und dies gilt nun für jeden einzelnen Nutzer. Die Last auf dem SQL ist somit hoch und die Performance dadurch nicht optimal. Außerdem wächst der Cache schnell an, weil Dateien theoretisch doppelt und dreifach zwischengespeichert werden müssten.

Die Lösung liefern der Super User und der Super Reader Account. Bei einem Seitenaufruf werden so nur zwei Anfragen im jeweiligen Kontext der beiden Nutzer an den SQL gesendet. Der Super User („Full Control“) bekommt als Ergebnis auf diese Abfrage alle Entwürfe von Dateien, also die Zwischenversionen. Der Super Reader („Full Read“) bekommt alle veröffentlichten Versionen. Die Dateien aus beiden Abfragen landen im Cache. Für den eigentlichen Endnutzer werden dann die Berechtigungen aus den Zugriffssteuerungslisten (Acces Control List – ACL) geladen und dementsprechend nur die Informationen (aus dem Cache) gerendert und angezeigt, die er mit seinen Berechtigungen sehen darf. Der Vorteil dieses Verfahrens ist der schnelle Cache und es müssen nur die Ergebnisse für zwei Anfragen darin gespeichert werden. Dies ist also eine Performance- und Cache-Speicheroptimierung.

Nun kann es aber bei der Verwendung der Standardeinstellungen, nämlich des Systemkontos einer Website als „Portal Super User“ und des „NT Authority\Local Service“ als „Portal Super Reader“, zu Problemen kommen. Kurz: mit dem Systemkonto als „Portal Super User“ kann es zu Performance-Einbußen kommen, da hierbei manche „Entwurfsdateien“ doppelt abgefragt werden müssen. Da der „Local Service“ hingegen nicht explizit auf die jeweiligen veröffentlichten Seiten berechtigt ist, bekommt auch der Endnutzer eine Zugriffsverweigerung. Eine detailliertere Beschreibung finden Sie hier: https://technet.microsoft.com/de-de/library/ff758656.aspx)

Worauf ich aber eigentlich hinaus möchte, das ist die Authentifizierungsmethode. Microsoft änderte diese von SharePoint 2010 (Classic) zu SharePoint 2013 (Claims). Nun migrieren wir in SP2013 eine Classic-WebApplication zu Claims.

Convert-SPWebApplication -Identity „http://YourWebApp:80“ -To Claims -RetainPermissions -Force

Dies migriert auch alle berechtigten Benutzer dieser WebApplication zu Claims. Dennoch bekommen anschließend alle Nutzer – inklusive der Administratoren – einen „Zugang verweigert“ beim Zugriff auf die Seite. Besonders bei öffentlichen Seiten macht dies sehr viel „Spaß“.

Der Hintergrund ist einfach, dass bei der Classic zu Claims Migrations, auch inklusive der Benutzer, eben nicht der Super User und Super Reader mitgenommen werden. Diese verbleiben mit ihrem Classic Account und können sich daher nicht mehr authentifizieren. Sie müssen daher diese Konten erneut mit ihrer Claims-Nutzerkennung anlegen, um das Problem zu lösen. Bitte denken Sie auch daran, wenn Sie Farmlösungen oder ähnliche Programme nutzen, dass diese entsprechend mitgenommen werden müssen und sich in Zukunft über Claims authentifizieren.

Der Vollständigkeit halber hier noch die PowerShell Befehle, um die User mit Windows-Claims anzulegen:

$webapp = Get-SPWebApplication “http://WebAppURL”
$webapp.Properties[“portalsuperuseraccount”] = “i:0#.w|domain\SuperUser”
$webapp.Properties[“portalsuperreaderaccount”] = “i:0#.w|domain\SuperReader”
$webapp.Update()

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Performance Monitoring – Performance Counter für System und Netzwerk

SharePoint Adventskalender – 12. Türchen

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

————————————————————-

Am letzten Tag für die SharePoint Performance Counter schauen wir uns zwei System und vier Netzwerk Messgrößen an. Die System-Indikatoren sind dabei zusätzliche Checks für den den Prozesser und die Netzwerkmessgrößen können – wie der Name schon sagt – einen möglichen Engpass am Netzwerk identifizieren.

System:

Context Switches/sec

Kontextwechsel treten auf, wenn der Prozessor zwischen zwei Threads wechselt. Dies kann z.B. geschene, wenn ein Thread, der eine höhere Priorität hat als der aktuell zu verarbeitende Thread hat, bereit für die Bearbeitung durch den Prozessor ist. Eine hohe Rate ist ein Zeichen dafür, dass sich viele gleichrangige Threads um die Bearbeitung im prozessor „streiten“.

Eine Anwendung (Application), besteht aus einem oder mehreren Prozessen. Ein Prozess ist einfach betrachtet das auszuführende Programm für die Anwendung. Also im Prinzip der Worker-Prozess (w3wp.exe) für SharePoint. Ein oder mehrere Threads, welche die Basiseinheit des Betriebssystems darstellen, die dem Prozessor zugeweisen werden können, laufen dann im Kontext eines Prozesses und erledigen die eigentliche Arbeit. In diesem Zusammenhang wird also deutlich, dass viele Kontextwechsel die Performance des Servers negativ beeinflusst. Obwohl auch ein Problem mit der Netzwerkkarte oder eines Gerätetreibers die Ursache für hohe Kontestwechsel sein können (siehe auch 9. Türchen über Privilege und User Mode Anfragen), so zeigt dieser Indikator auch auch, dass SharePoint einfach extrem viele Aufgaben abzuarbeiten hat, die der Prozesser nicht mehr bedienen kann. Ein Messwert von mehr als 1.000 Wechsel ist nicht optimal und deutet so ein Szenario an. Ein besserer Prozessor mit auch mehreren Kernen kann das Problem lösen.

Processor queue length

Prozessor-Warteschlangen entstehen, wenn neue Anfragen bereit sind, bearbeitet zu werden, aber die CPU aktuell mit noch anderen Anfragen voll beschäftigt ist. Ähnlich wie bei der Warteschlange, auf die Festplatten schreiben zu können (siehe 10. Türchen, Avg Disk Queue Length), ist bereits ein Wert von mehr also 2 (pro Kern) schlecht. Zufällig eintreffende Anfragen mit hoher Priorität oder unerwartet lang andauernde Threads können temporäre Warteschlangen entstehen lassen. Sind die Werte aber dauerhaft über dem Grenzwert, dann kann der Prozessor einfach nicht mehr alle Anfragen zeitnah abarbeiten. Die einfachste Lösung ist ein zweiter Server, den man in einem Load-Balancer Verbund dazu schaltet. Andere Ursachen können auch ein bestimmter „hängender“ Prozesse sein, ein schlechter Gerätetreiber mit vielen Kernerl-Mode Anfragen. Analysieren Sie also genau, welche Ursachen bei Ihnen eine dauerhafte Prozessor-Warteschlangen haben entstehen lassen.

Netzwerk:

Bytes total/sec

Dieser Indikator gibt an, wie viele Daten die Netzwerkkarte(n) insgesamt pro Sekunde verarbeiten, also die Summe aus erhaltenen und gesendeten Bytes. Ein dauerhafter Wert von mehr als 80% der angegebenen Kapazität der Netzwerkkarte, deuten auf einen Engpass hin. Ganz schnell kann man so nämlich am absoluten Limit sein und so verhindert die NIC (Network Interface Card), dass de Server sein volles Potential ausschöpfen kann. Achten Sie aber auch im Detail darauf, ob die Einzelgrößen, also nur das Empfangen oder nur das Senden, auffällig sind. Ein ein weiterer kleiner Tipp: Die NIC Kapazitäten werden in Bit angegeben, dieser Indikator wird hingegen in Byte gemessen.

Current Bandwidth

Diese Messgröße gibt einfach die geschätzte maximale Bandbreite der Netzwerkkarte an. Dies sollte der Kapazitätenangabe für die NIC entsprechen. Also eine NIC mit 1 Gbps sollte auch bei diesem Indikator genau diese 1 Gbps anzeigen. Ist dies geringer, haben Sie nicht bekommen, wofür Sie bezahlt haben.

Network Utilization

Bei der Netzwerknutzung kommen die ersten beiden Indikatoren zusammen. Sie stellt also die insgesamt verarbeiteten Bytes ins Verhältnis zur möglichen Bandbreite. Mehr als 40% Ausnutzung kann bereits nicht mehr optimal sein. Eine hohe Nutzung deutet nämlich an, dass viele Daten und Informationen verarbeitet und gesendet werden müssen. Geschicht dies im selben (Teil-) Netzwerk, so kann es zu Kollisionen kommen, wenn gleichzeit zwei Stationen eines Netzwerksegments versuchen, zu senden. Diese Paketkollisionen führe zu einer Verzögerung der Sendung, da ein erneuter Sendeversuch gestartet werden muss.

Die Grenzwerte sind hier aber mit Vorsicht zu genießen. Sind besipielsweise Server und Netze mit Switches und/oder Netzwerkbrücken verbunden, die auf einer höheren OSI-Ebene arbeiten, können gleichzeitig gesendete Pakete weitgehend minimiert werden. Denn in diesem Falle ist der Server meist direkt mit dem nächsten Switch verbunden und nur ein gleichzeitiger Sendeversuch dieser beider Stationen kann zu einer Kollision führen. Bei gleich hohen Sende- und Empgangswerten kann dies dennoch häufiger der Fall sein und dies ist schon mehrheitlich bei mehr als 40% Auslastung der Fall. Dedizierte Netzwerke, z.B. für Backup-Vorgänge, prinzipiell höhere Netzwerkkapazitäten aber auch Netzwerkkonfigurationen lösen dieses Problem.

Output Queue Length

Die Länge der Warteschlange für Datenpakete, die gesendet werden sollen, ist äquivalent zu den Warteschlangen bei Prozessor und Festplatte. Kommt es zu so einer Warteschlange, hat die Netzwerkkarte einfach nicht genug Leistung, um die zu sendenen Anfragen zeitnah abzuarbeiten. Auch hier ist ein dauerhafter Wert von über 2 nicht optimal.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen: