Thursday, March 28, 2024
HomeAvePoint BlogSharePoint Adventskalender 3. Woche

SharePoint Adventskalender 3. Woche

SharePoint Adventskalender – 14. Türchen

SharePoint Configuration Best Practices – Benamte SQL Instanzen und dedizierte Ports

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

Bei der Installation von SQL kann man sicherlich auch die Standardinstanz ohne eigenen Namen und mit dem Standard TCP/IP Port 1433 verwenden, aber dies ist nicht praktikabel und auch nicht zu empfehlen für produktive Systeme. Schon allein, wenn mehr als eine Instanz auf einem SQL laufen sollen, muss logischerweise mindestens ein Name oder ein anderer dedizierter Port vergeben werden. Zudem können Sie mit dedizierten Namen Ihre Infrastruktur besser verwalten und überblicken. Neben der einfacheren Verwaltung spielt in diesem Kontext aber auch die Sicherheit der Infrastruktur eine Rolle.

Sicherheit:

Da Port 1433 der Standardport ist, wird dieser gern von Hackern als einer der ersten abgefragt, um Zugriff auf die Datenbanken zu erhalten. Es ist daher ratsam, der Instanz einen dedizierten Port zu vergeben, der nicht 1433 ist.

Verwaltbarkeit:

Für SQL können dynamische Ports verwendet werden, sodass wir uns nicht auf einen festlegen müssen. Der Nachteil liegt aber auf der Hand. Eine Firewall-Konfiguration anhand von Ports wird dadurch nahezu unmöglich. Sollte nämlich nach einem Restart der Instanz ein neuer Port vergeben werden, weil der vorherige einem anderen Service mit dynamischer Portvergabe zugewiesen wurde, so kann im schlimmsten Falle der SharePoint (weiterhin) nicht verfügbar sein. Der Grund ist, der neue Port wurde vermutlich noch nicht in der Firewall geöffnet. Empfehlenswert ist hierbei eine Firewall-Regel, die programmbasiert ankommende Verbindungen am SQL erlaubt. Dafür müssen Sie aber auch alle Programme kennen, die auf den SQL zugreifen können und dürfen. Dies kann umständlich sein, weshalb ich daher empfehle, einen festen Port zu wählen und die Firewall entsprechend zu konfigurieren.

Denken Sie auch daran, dass Sie bei benamten Instanzen auch den Port 1434 für das UDP Protokoll öffnen – unabhängig davon, ob Sie fixe oder dynamische Ports nutzen. Warum ist das so? Nur bei nicht benamten Standard-Instanzen hört der SQL Server selbst auf Port 1433. Bei allen anderen Szenarien hört der SQL Browser Service auf ankommende Verbindungen und weist diesen dann die jeweiligen dynamischen oder fixen Ports zu. Erst danach kommt die Verbindung am tatsächlichen Port an, auf den die SQL Instanz hört. Logischer Weise muss dafür auch immer der SQL Browser Service laufen, da sonst die ankommenden Verbindung nicht zugewiesen werden können.

Im SQL Konfigurationsmanager empfehle ich daher, den fixen Port für die TCP/IP Konfiguration zu setzen und den Dynamischen Port komplett zu löschen (also auch den standardmäßig hinterlegten Wert „0“ zu entfernen, wie im Screenshot zu sehen ist). Achten Sie auch darauf, dass Sie den Port für den Alias im Konfigurationsmanager oder über das cliconfg.exe Tool korrekt setzen.

sql server configuration manager

Ist dies alles erledigt, so ist auch die Firewall-Konfiguration ein leichtes Spiel und schließt die SQL Instanz- und Portkonfiguration ab.

Viel Spaß beim „SharePointen“!

 

SharePoint Adventskalender – 15. Türchen

SharePoint Configuration Best Practices – Super User und Super Reader

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“!

 

SharePoint Adventskalender – 16. Türchen

SharePoint Configuration Best Practices – Distributed Cache Service

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 genauso 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 Fehlerbehebung 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

 

SharePoint Adventskalender – 17. Türchen

SharePoint Configuration Best Practices – Request Management Service

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:

expiration

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).

execution

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
  1. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  2. 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
  3. 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)
  4. Nun kann die Routing-Regel mit obigen Server-Pool und Filter-Kriterium angelegt werden
    • $RM | Add-SPRoutingRule -Name “DOCX Regel” -Criteria $Krit -MachinePool $Pool
  5. 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“

 

SharePoint Adventskalender – 18. Türchen

SharePoint BLOB Management – BLOB Cache

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:

anfrage 

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“!

 

SharePoint Adventskalender – 19. Türchen

SharePoint BLOB Management – BLOB Storage (EBS und RBS)

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.

Im gestrigen Kalendertürchen sprachen wir noch vom BLOB Caching, um in bestimmten Szenarien die Performance für eine bessere Nutzererfahrung zu steigern. Leider optimiert dies in keinster Weise die Speicherlaufwerke, denn die BLOBs liegen witerhin wie bisher als „Image“ mit einem Dateilimit von 2 GB in den Datentabellen des SQL. Der SQL Server-Storage ist aber sehr ressourcenhungrig und damit teuer. Die Reduzierung der Datenbankgröße durch Auslagerung von Daten und die damit einhergehende Performance-Verbesserung waren daher Ziele bei der Einführung von EBS und RBS. (Die Performance-Verbesserung durch Auslagerung ist auf die Limitationen der Datenbankalgorithmen für große Dateien zurückzuführen, wie gestern bereits erwähnt.)

Der für SharePoint 2007 eingeführte External BLOB Storage (EBS) konnte auf Farmebene angewendet werden. Anhand konfigurierbarer Regeln konnten so große Dateien aus der SQL Datenbank auf einen günstigeren Storage ausgelagert werden. Dafür verwendetet man nun nicht mehr das Image, sondern das VARBINARY Format. Ein Größenlimit gibt es damit theoretisch zwar nicht mehr, aber aus Performance-Gründen behielt Microsoft weiterhin die 2 GB-Limits für SharePoint Datenbanken bei. Mit SharePoint 2016 ist dieses Limit nun endlich auf (aktueller Stand) 10 GB pro Datei angehoben worden.

Da schnell die Grenzen des EBS deutlich wurden, kündigte Microsoft dieses Feature in SharePoint 2010 wieder ab und führte den Remote BLOB Storage (RBS) ein. Dieser kann pro Datenbank angewendet werden und ist somit deutlich flexibler einsetzbar für SharePoint Farm Administratoren.

Ziele und Funktionsweise des RBS

Hauptziel des RBS ist die Auslagerung von entweder großen Dateimengen oder bestimmten Daten anhand definierter Regeln. Hinsichtlich SharePoint-Limitationen werden diese Daten zwar weiterhin zu einer Datenbank hinzugezählt, sie befinden sich jedoch auf einem anderen Storage. Dadurch kann SQL deutlich schneller und effizienter arbeiten, weil keine Table-Queries mehr mit großen BLOBs, sondern nur noch mit kleinen Stubs(Referenz auf den tatsächlichen Speicherort), durchgeführt werden müssen. Außerdem können so auch die erweiterten Datenbankgrenzwerte angewendet werden. Microsoft unterstützt z.B. in SharePoint 2013 Inhaltsdatenbanken mit bis zu 4 TB und einem Disk Subsystem von mindestens 0,25 I/Ops pro GB. Da durch die Auslagerung beispielsweise keine 4 TB, sondern effektiv nur 150 GB in der Datenbank liegen, kann man so auch mit günstigen Laufwerken die erforderten 0,25 I/Ops pro GB erreichen (empfohlen sind 2 I/Ops pro GB – https://technet.microsoft.com/de-de/library/cc262787.aspx).

Beispielrechnung:

Effektive Daten in der Datenbank

Erforderliche I/Ops für das Disk Subsystem

4 TB        (à 0,25 I/Ops * 1024 * 4)

1024

150 GB  (à 0,25 I/Ops * 150)

37,5

Sollten Sie also dieses Szenario verfolgen und mit RBS die 200 GB „virtuell“ überschreiten, bedenken Sie Situationen, in denen die BLOBs wieder zurück in den Datenbanken müssen, z.B. bei Migrationen. Auch dafür gibt es zwar Lösungen, z.B. Migrationssoftware von Drittanbietern wie AvePoint. Ich möchte an dieser Stelle aber lediglich darauf hinweisen, dass im RBS-Fall bestimmte Dinge zu berücksichtigen sind.

Die Auslagerung von Daten als Hauptziel ermöglicht zudem weitere Nebenziele:

Performance:
Die Downloadzeiten, also die Dauer bis ein Dokument oder allgemein ein BLOB gerendert ist, wird deutlich reduziert aufgrund der gestern erwähnten Limitation.

Der RBS-Provider kann also deutlich mehr Daten direkt vom Storage in der gleichen Zeit lesen, als es SQL allein aus seinen Datenbanken kann. Diese Unterscheide sind natürlich abhängig von dem Speicher-Subsystem des SQL sowie vom RBS Storage und der Netzwerkgeschwindigkeit (sollte diese eine andere und langsamere als zum SQL sein). Um das BLOB vom Storage zu lesen und zu rendern, muss der Browser für gewöhnlich folgende Schritte unternehmen:

  1. DNS Lookup
  2. Initiale Verbindung
  3. Warten
  4. Daten erhalten
  5. Verbindung schließen

Das Warten auf Daten wird als sogenannte TTFB (Time To First Byte – Zeit bis zum ersten Byte) bezeichnet. 100-200 ms sind grundsätzlich gute Werte. Möchten Sie jedoch einen NAS als RBS-Storage nutzen, erfordert Microsoft eine TTFB von unter 20 ms (https://technet.microsoft.com/de-de/library/Ff628583.aspx).

Deduplication:
Auf dem RBS-File-System kann die Deduplication (ein Windows Service) genutzt werden. Ist also ein Dokument doppelt und dreifach in mehreren Bibliotheken abgelegt, so erkennt dies der Deduplication-Algorithmus und komprimiert alle Duplikate in ein einziges und verweist dies in einem Index – einfach ausgedrückt.

In Tests hat sich herausgestellt, dass die beste Performance grundsätzlich mit einem RBS-Grenzwert von 1024 KB erreicht wird. Bei kleineren Dateien ist der SQL Algorithmus schneller. Der Wert kann aber auch minimal abweichen, je nach dem, für welches Szenario Ihre Farm eingesetzt wird und somit welche Dateigrößen hauptsächlich gespeichert sind. Dazu aber morgen mehr in Form von Informationen und Mythen zum Shredded Storage.

Hinweis: Auslagerung kann nicht von SharePoint erfolgen. Stattdessen müssen entsprechende RBS Provider installiert werden. Der Microsoft-eigene Provider, genannt FILESTREAM, erfüllt das Grundgerüst, also das Auslagern von Dateien anhand einer konfigurierten Größe x. Leider kann der FILESTREAM auch nur lokale Laufwerke des SQLs als Auslagerungs-Storage verwenden. Wenn Sie Daten auch auf andere Storages, wie z.B. einen SAN oder Cloud-Speicher, bringen oder weitere Auslagerungsregeln, z.B. per Dokumentenversionen oder bestimmte Spaltenwerte, verwenden möchten, dann kann dies nur eine Drittanbieterlösungen ermöglichen. Exemplarisch möchte ich auch hier AvePoint mit dem “Storage Manager” nennen.

Viel Spaß beim „SharePointen“

 

SharePoint Adventskalender – 20. Türchen

SharePoint BLOB Management – Shredded Storage

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:

drive

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“

Robert Mulsow
Robert Mulsow
Robert Mulsow is VP of TSP EMEA at AvePoint, and a Microsoft P-TSP. Together with his previous experience at Microsoft, he specializes in SharePoint infrastructure and peripheral technologies SQL, Windows Server and Active Directory. As a Microsoft MVP and Certified Trainer for Office servers and services, he brings extensive experience in the field of consulting, implementation and troubleshooting.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

More Stories