Best Practices SharePoint and SQL Installation

  • 1,599 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,599
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
29
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • http://technet.microsoft.com/en-us/library/ff758659.aspxErstellen eines TestplansIhr Plan sollte Folgendes enthalten:Hardware, die für die Ausführung bei erwarteten Produktionsleistungszielen konzipiert ist. Sie sollten die Leistung von Testsystemen immer konservativ messen.Bei Verwendung von benutzerdefiniertem Code oder benutzerdefinierten Komponenten ist es wichtig, diese Komponenten zuerst isoliert zu testen, um ihre Leistung und Stabilität zu überprüfen. Wenn sie stabil sind, sollten Sie das System mit den installierten Komponenten testen und die Leistung mit der Farm ohne die installierten Komponenten vergleichen. Häufig stellen benutzerdefinierte Komponenten die Hauptverursacher von Problemen im Zusammenhang mit der Leistung und Zuverlässigkeit in Produktionssystemen dar.Die Zielsetzung der Tests sollte bekannt sein. Sie sollten im Voraus wissen, welche Ziele im Rahmen der Tests erreicht werden sollten. Soll die Leistung neuer benutzerdefinierter Komponenten, die für die Farm entwickelt wurden, beurteilt werden? Soll die Zeitdauer für das Durchforsten und Indizieren einer Reihe von Inhalten erfasst werden? Soll festgestellt werden, wie viele Anforderungen pro Sekunde von der Farm unterstützt werden können? Für einen Test kann es viele verschiedene Zielsetzungen geben; bei der Ausarbeitung eines guten Testplans sollten Sie als erstes die Ziele festlegen, die verfolgt werden sollen.Wissen, wie das Testziel gemessen werden kann. Wenn Sie beispielsweise die Durchsatzkapazität Ihrer Farm messen möchten, müssen Sie die Anforderungen pro Sekunde (RPS) sowie die Seitenwartezeit erfassen. Wenn Sie die Suchleistung messen möchten, müssen Sie die Durchforstungszeit und die Dokumentindizierungsraten bestimmen. Wenn Sie sich über die Zielsetzung Ihrer Tests im Klaren sind, ist es einfacher, die Schlüsselleistungsindikatoren zu definieren, die im Rahmen der Tests bewertet werden müssen.Erstellen der TestumgebungNachdem Sie die Ziele für die Tests festgelegt, die Messungen definiert und die Kapazitätsanforderungen für Ihre Farm (aus den Schritten 1 und 2 dieses Prozesses) bestimmt haben, besteht die nächste Aufgabe darin, die Testumgebung zu entwerfen und zu erstellen. Der Aufwand, der mit dem Erstellen einer Testumgebung verbunden ist, wird häufig unterschätzt. Die Testumgebung sollte die Produktionsumgebung so nah wie möglich duplizieren. Zu den Features und Funktionen, die beim Entwurf der Testumgebung berücksichtigt werden sollten, gehören die folgenden:Authentifizierung - Legen Sie fest, ob die Active Directory-Domänendienste (Active Directory Domain Services, AD DS), die formularbasierte Authentifizierung (und wenn ja, mit welchem Verzeichnis) und die anspruchsbasierte Authentifizierung usw. in der Farm verwendet werden sollen. Unabhängig vom verwendeten Verzeichnis werden wie viele Benutzer in der Umgebung benötigt und wie sollen diese erstellt werden? Wie viele Gruppen oder Rollen werden benötigt und wie erstellen Sie sie und füllen sie auf? Sie müssen auch sicherstellen, dass Sie den Authentifizierungsdiensten ausreichend Ressourcen zugewiesen haben, damit keine Engpässe während der Tests auftreten.DNS - Bestimmen Sie, welche Namespaces bei Ihren Tests benötigt werden. Identifizieren Sie die Server, die auf diese Anforderungen reagieren, und stellen Sie sicher, dass in Ihrem Plan die IP-Adressen berücksichtigt werden, die von den jeweiligen Servern verwendet werden sowie die DNS-Einträge, die erstellt werden müssen.Lastenausgleich - Vorausgesetzt, Sie verwenden mehr als einen Server (was normalerweise der Fall ist, da Sie sonst nicht ausreichend Auslastung für die Durchführung von Auslastungstests haben), benötigen Sie eine Art von Lastenausgleichslösung. Dabei kann es sich um ein Hardwarelastenausgleichsmodul oder um Softwarelastenausgleich wie den Windows-Netzwerklastenausgleich (Network LoadBalancing, NLB) handeln. Legen Sie fest, was verwendet werden soll, und schreiben Sie alle Konfigurationsinformationen auf, die Sie für das schnelle und effiziente Setup benötigen. Darüber hinaus sollten Sie bedenken, dass Auslastungstest-Agents in der Regel die Adresse zur einer URL nur alle 30 Minuten versuchen aufzulösen. Sie sollten also keine Datei für lokale Hosts oder Roundrobin-DNS für den Lastenausgleich verwenden, da sich die Test-Agents voraussichtlich bei jeder einzelnen Anforderung an denselben Server wenden, anstatt die Last auf alle verfügbaren Server zu verteilen.Testserver - Bei der Planung der Testumgebung müssen Sie nicht nur die Server für die SharePoint Server 2010-Farm einplanen, sondern auch die für die Tests erforderlichen Computer. Dazu gehören in der Regel mindestens 3 Server, ggf. sind mehr erforderlich. Wenn Sie Visual Studio Team System (Team Test Load Agent) für die Tests verwenden, wird ein Computer als Auslastungstestcontroller verwendet. Im Allgemeinen werden mindestens 2 Computer als Auslastungstest-Agents eingesetzt. Die Agents sind die Computer, die die Anweisungen vom Testcontroller darüber, was getestet werden soll, entgegen nehmen und die Anforderungen an die SharePoint Server 2010-Farm herausgeben. Die Testergebnisse werden auf einem SQL Server-basierten Computer gespeichert. Sie sollten nicht denselben SQL Server-basierten Computer verwenden, der für die SharePoint Server 2010-Farm verwendet wird, da durch das Schreiben der Testdaten die verfügbaren SQL Server-Ressourcen für die SharePoint Server 2010-Farm beeinträchtigt werden. Beim Ausführen der Tests müssen auch die Testserver überwacht werden, genauso wie die Server in der SharePoint Server 2010-Farm oder Domänencontroller usw., um sicherzustellen, dass die Testergebnisse der Farm repräsentativ für die geplante Farm sind. Gelegentlich kann es vorkommen, dass die Auslastungs-Agents oder -Controller selbst einen Engpass darstellen. In diesem Fall entspricht der im Test angezeigte Durchsatz nicht dem Maximum, das von der Farm unterstützt werden kann.SQL Server - Folgen Sie in Ihrer Testumgebung den Hinweisen in den Abschnitten "Konfigurieren von SQL Server" und "Überprüfen von Speicherleistung und -zuverlässigkeit" im Artikel Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).Überprüfung des Datasets - Bei der Auswahl der Inhalte, die Tests unterzogen werden, sollten Sie bedenken, dass in einem optimalen Szenario Daten aus einem vorhandenen Produktionssystem verwendet werden. So können Sie beispielsweise Ihre Inhaltsdatenbanken aus einer Produktionsfarm sichern und in Ihrer Testumgebung wiederherstellen. Fügen Sie dann die Datenbanken an, um die Inhalte in die Farm zu übertragen. Immer wenn Sie Tests auf erfundene Daten oder Beispieldaten anwenden, besteht das Risiko, dass die Ergebnisse aufgrund von Unterschieden der gesammelten Inhalte verfälscht werden.Wenn Sie Beispieldaten erstellen müssen, sollten Sie die folgenden Aspekte für die Inhalte berücksichtigen:Alle Seiten sollten veröffentlicht sein; es sollten keine Inhalte ausgecheckt sein.Die Navigation sollte realistisch sein; erstellen Sie nicht mehr als das, was Sie normalerweise in einer Produktionsumgebung verwenden würden.Sie sollten eine Vorstellung von den Anpassungen haben, die in der Produktionswebsite verwendet werden. So sollten beispielsweise Gestaltungsvorlagen, Stylesheets, JavaScript usw. so eng wie möglich in der Produktionsumgebung implementiert sein. Bestimmen Sie die Anzahl der erforderlichen SharePoint-Gruppen und/oder Berechtigungsebenen und wie Benutzer diesen zugeordnet werden.Stellen Sie fest, ob Profile importiert werden müssen, und wie lange dies ggf. dauert.Finden Sie heraus, ob Benutzergruppen benötigt werden, wie diese ggf. erstellt und aufgefüllt werden. Legen Sie fest, ob zusätzliche Inhaltsquellen für Suchen erforderlich sind und was Sie benötigen, um diese zu erstellen. Wenn Sie keine Inhaltsquellen erstellen müssen, finden Sie heraus, ob Sie Netzwerkzugang haben, um sie zu durchforsten. Stellen Sie fest, ob ausreichend Beispieldaten vorhanden sind - Dokumente, Listen, Listenelemente usw. Erstellen Sie andernfalls einen Plan dafür, wie Sie diese Inhalte erstellen.Erstellen Sie einen Plan, damit ausreichend eindeutige Inhalte im Rahmen der Tests durchsucht werden können. Häufig wird der Fehler gemacht, dass dasselbe Dokument sogar hundert- oder tausendfach unter unterschiedlichen Namen in verschiedene Dokumentbibliotheken hochgeladen wird. Dies kann sich auf die Suchleistung auswirken, da der Suchprozessor beträchtliche Zeit mit der Erkennung von Duplikaten verbringt, was in einer Produktionsumgebung mit tatsächlichen Inhalten nicht notwendig wäre.Erstellen von Tests und ToolsNach dem Einrichten der Testumgebung ist es Zeit, die Tests zu erstellen und zu optimieren, die für die Messung der Leistungskapazität der Farm verwendet werden. In diesem Abschnitt wird gelegentlich spezifisch auf Visual Studio Team System (Team Test Load Agent) verwiesen, doch können viele der Konzepte unabhängig vom verwendeten Auslastungstool angewendet werden. Weitere Informationen zu Visual Studio Team System finden Sie unter Visual Studio Team System im MSDN (http://msdn.microsoft.com/de-de/library/fda2bad5.aspx" ).Sie können auch das SharePoint LoadTesting Kit (LTK) zusammen mit VSTS für die Durchführung von Auslastungstests von SharePoint 2010-Farmen verwenden. Mit dem LoadTesting Kit wird ein Visual Studio Team System 2008-Auslastungstest auf der Grundlage von Windows SharePoint Services 3.0- und Microsoft Office SharePoint Server 2007-IIS-Protokollen generiert. Der VSTS-Auslastungstest kann verwendet werden, um als Bestandteil der Kapazitätsplanungsübung oder des Stresstests vor dem Upgrade eine synthetische Last für SharePoint Foundation 2010 oder SharePoint Server 2010 zu generieren.Das LoadTesting Kit gehört zum Lieferumfang des Microsoft SharePoint 2010 Administration Toolkit Version 1.0, das im Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=de-de) verfügbar ist.Ein wesentliches Kriterium für den Erfolg der Tests ist die Fähigkeit, eine realistische Arbeitslast zu simulieren, indem Anforderungen für die unterschiedlichsten Testwebsitedaten generiert werden, so als würden Benutzer auf die unterschiedlichsten Inhalte einer SharePoint Server 2010-Farm im Produktionsbetrieb zugreifen. Dazu müssen Sie die Tests in der Regel so konstruieren, dass sie datengesteuert sind. Anstatt Hunderte individueller hardcodierter Tests zu erstellen, die auf eine bestimmte Seite zugreifen, sollten Sie nur einige wenige Tests verwenden, die Datenquellen mit den URLs für diese Elemente enthalten, um dynamisch auf diese Gruppe von Seiten zuzugreifen.In Visual Studio Team System (Team Test Load Agent) kann eine Datenquelle die unterschiedlichsten Formate aufweisen, doch sind CSV-Dateien häufig am einfachsten zu verwalten und zwischen Entwicklungs- und Testumgebungen zu transportieren. Wenn CSV-Dateien mit solchen Inhalten erstellt werden, ist es eventuell notwendig, benutzerdefinierte Tools zum Aufzählen der SharePoint Server 2010-basierten Umgebung und Aufzeichnen der verschiedenen URLs zu erstellen.Möglicherweise benötigen Sie Tools für Aufgaben wie die folgenden:Erstellen von Benutzern und Gruppen in Active Directory oder anderen Authentifizierungsspeichern bei Verwendung der formularbasierten AuthentifizierungAufzählen von URLs für Websites, Listen und Bibliotheken, Listenelemente, Dokumente usw. sowie Übertragen in CSV-Dateien für AuslastungstestsHochladen von Beispieldokumenten für verschiedene Dokumentbibliotheken und WebsitesErstellen von Websitesammlungen, Webs, Listen, Bibliotheken, Ordner und ListenelementenErstellen von "Meine Websites"Erstellen von CSV-Dateien mit Benutzernamen und Kennwörtern für Testbenutzer. Dies sind die Benutzerkonten, über die die Auslastungstests ausgeführt werden. Es sollten mehrere Dateien vorhanden sein, sodass einige beispielsweise nur Administratorbenutzer enthalten, einige Benutzer mit erhöhten Rechten (wie z. B. Autor/Mitwirkender, Hierarchie-Manager usw.) und andere wiederum nur Leser usw.Erstellen einer Liste von Beispielstichwörtern und -begriffen für die SucheAuffüllen von SharePoint-Gruppen und Berechtigungsebenen mit Benutzern und Active Directory-Gruppen (oder Rollen bei Verwendung der formularbasierten Authentifizierung)Beim Erstellen der Webtests sollten Sie u. a. die folgenden optimalen Methoden beachten und implementieren:Aufzeichnen einfacher Webtests als Ausgangspunkt. Diese Tests enthalten hartcodierte Werte für Parameter wie URLs und IDs usw. Ersetzen Sie diese hartcodierten Werte durch Hyperlinks aus Ihren CSV-Dateien. Die Datenbindung dieser Werte ist in Visual Studio Team System (Team Test Load Agent) äußerst einfach.Festlegen von Gültigkeitsregeln für die Tests. Wenn beispielsweise eine Seite angefordert wird, erhalten Sie als Antwort auf einen Fehler oft die Seite error.aspx. Aus Webtestperspektive handelt es sich einfach um eine weitere positive Antwort, da in den Auslastungstestergebnissen der HTTP-Statuscode 200 (erfolgreich) angezeigt wird. Offensichtlich ist jedoch ein Fehler aufgetreten, der anderweitig nachverfolgt werden sollte. Durch eine oder mehrere Gültigkeitsregeln können Sie bestimmten, als Antwort gesendeten Text abfangen, sodass die Überprüfung nicht erfolgreich ausgeführt und die Anforderung als Fehler gekennzeichnet wird. In Visual Studio Team System (Team Test Load Agent) kann als einfache Gültigkeitsregel ResponseUrl bei der Überprüfung verwendet werden. Dabei wird ein Fehler ausgegeben, wenn die nach Umleitungen gerenderte Seite nicht dieselbe Antwortseite ist, die im Test aufgezeichnet wurde. Sie können auch eine FindText-Regel hinzufügen, bei der ein Fehler aufgezeichnet wird, wenn der Ausdruck "Zugriff verweigert" beispielsweise in der Antwort gefunden wird.Verwenden von mehreren Benutzern in verschiedenen Rollen für Tests. Verschiedene Verhalten, wie z. B. das Zwischenspeichern der Ausgabe wird abhängig von den Rechten des jeweiligen Benutzers unterschiedlich gehandhabt. So erhalten beispielsweise ein Websitesammlungsadministrator oder ein authentifizierter Benutzer mit Genehmigungs- oder Dokumenterstellungsrechten keine zwischengespeicherten Ergebnisse, da es ihnen stets möglich sein sollte, auf die aktuellste Version von Inhalten zuzugreifen. Anonyme Benutzer hingegen erhalten zwischengespeicherte Inhalte. Sie müssen sicherstellen, dass es sich bei den Testbenutzern um eine Kombination dieser Rollen handelt, die in etwa der Zusammenstellung der Benutzer in der Produktionsumgebung entspricht. Wenn beispielsweise in einer Produktionsumgebung nur zwei oder drei Websitesammlungsadministratoren vorkommen, sollten Sie keine Tests erstellen, bei denen 10% der Seitenanforderungen von Benutzerkonten stammen, die Websitesammlungsadministratoren für die Testinhalte sind.Die Analyse abhängiger Anforderungen ist ein Attribut von Visual Studio Team System (Team Test Load Agent), das bestimmt, ob der Test-Agent versuchen sollte, nur die Seite oder die Seite einschließlich aller zugehörigen Anforderungen, die Teil der Seite sind, abzurufen, wie z. B. Bilder, Stylesheets und Skripts usw. Beim Testen der Auslastung werden diese Elemente in der Regel aus verschiedenen Gründen ignoriert:Nach dem erstmaligen Zugreifen eines Benutzers auf eine Website werden diese Elemente häufig vom lokalen Browser zwischengespeichertDie Elemente stammen in einer SharePoint Server 2010-basierten Umgebung in der Regel nicht von SQL Server. Wenn der BLOB-Cache aktiviert ist, werden sie vielmehr von den Webservern bereitgestellt, sodass keine SQL Server-Last generiert wird.Wenn der Prozentsatz der Benutzer Ihrer Website, die diese erstmalig besuchen hoch ist, oder wenn Sie die Browserzwischenspeicherung deaktiviert haben oder aus einem sonstigen Grund nicht vorhaben, den BLOB-Cache zu verwenden, kann es sinnvoll sein, die Analyse abhängiger Anforderungen in Ihren Tests zu aktivieren. Für die meisten Implementierungen stellt dies jedoch tatsächlich eine Ausnahme und nicht die Regel dar. Durch Aktivieren der Funktion können die vom Testcontroller gemeldeten RPS-Zahlen deutlich ansteigen. Diese Anforderungen werden so schnell bereitgestellt, dass Sie möglicherweise zu dem trügerischen Schluss gelangen, dass mehr Kapazität in der Farm verfügbar ist als tatsächlich vorhanden.Denken Sie daran, auch die Aktivität von Clientanwendungen zu modellieren. Auch durch Clientanwendungen, wie Microsoft Word, PowerPoint, Excel und Outlook, werden Anforderungen für SharePoint Server 2010-Farmen generiert. Durch Senden der Serveranforderungen, wie z. B. beim Abrufen von RSS-Feeds, Abrufen thematischer Informationen, Anfordern von Details zur Website- und Listenstruktur und Synchronisieren von Daten usw., steigt die Auslastung innerhalb der Umgebung. Diese Anforderungstypen sollten berücksichtigt und modelliert werden, wenn diese Clients Teil Ihrer Implementierung sind.In den meisten Fällen sollte ein Webtest nur eine einzelne Anforderung enthalten. Die Optimierung und Problembehandlung der Testumgebung und einzelner Anforderungen ist einfacher, wenn der Test nur eine einzelne Anforderung enthält. Webtests müssen in der Regel mehrere Anforderungen enthalten, wenn der simulierte Vorgang auf mehreren Anforderungen zusammen gesetzt ist. Wenn Sie beispielsweise diese Reihe von Aktionen testen möchten, benötigen Sie einen aus mehreren Schritten bestehenden Test: Auschecken eines Dokuments, Bearbeiten des Dokuments, Einchecken und Veröffentlichen. Ebenfalls erforderlich ist es, zwischen den Schritten den Zustand zu erhalten. So sollte beispielsweise dasselbe Benutzerkonto für das Auschecken, Bearbeiten und Einchecken verwendet werden. Solche Vorgänge aus mehreren Schritten, die erfordern, dass zwischen den einzelnen Schritten der Zustand erhalten bleibt, werden am besten mit mehreren Anforderungen in einem einzelnen Webtest durchgeführt.Führen Sie jeden Webtest einzeln aus. Stellen Sie sicher, dass jeder Test erfolgreich beendet werden kann, ehe er innerhalb eines umfangreicheren Auslastungstests ausgeführt wird. Überprüfen Sie, dass alle Namen für Webanwendungen aufgelöst werden und die im Test verwendeten Benutzerkonten über ausreichende Rechte für die Ausführung des Tests verfügen.Webtests umfassen die Anforderungen nach einzelnen Seiten, das Hochladen von Dokumenten und das Anzeigen von Listenelementen usw. Diese werden in Auslastungstests alle kombiniert. Ein Auslastungstest ist eine Kombination der verschiedenen Webtests, die ausgeführt werden sollen. Jedem Webtest wird ein Prozentsatz der Zeit für die Ausführung eingeräumt. Wenn Sie beispielsweise feststellen, dass 10% der Anforderungen in einer Produktionsfarm Suchabfragen sind, konfigurieren Sie einen Abfragewebtest für den Auslastungstest, der 10% der Zeit ausgeführt wird. In Visual Studio Team System (Team Test Load Agent) befassen sich Auslastungstests auch mit der Konfiguration von Faktoren wie der Browsermischung, der Netzwerkmischung, Auslastungsmustern und Ausführungseinstellungen. Für Auslastungstests sollten zusätzlich die folgenden optimalen Methoden beachtet und implementiert werden:Verwenden eines angemessenen Lese-/Schreibverhältnisses bei den Tests. Eine überhöhte Anzahl von Schreibvorgängen kann sich deutlich auf den Gesamtdurchsatz eines Tests auswirken. Selbst Farmen für die Zusammenarbeit tendieren zu Lese-/Schreibverhältnissen mit deutlich mehr Lese- als Schreibvorgängen. Weitere Informationen finden Sie unter Abschätzen von Leistungs- und Kapazitätsanforderungen (Office SharePoint Server).Berücksichtigen der Auswirkungen anderer ressourcenintensiver Vorgänge und Festlegen, ob diese während des Auslastungstests ausgeführt werden sollen. So werden beispielsweise Vorgänge wie Sichern und Wiederherstellen im Allgemeinen nicht während eines Auslastungstests ausgeführt. Eine vollständige Durchforstung sollte in der Regel nicht während eines Auslastungstests ausgeführt werden, während eine inkrementelle Durchforstung nicht ungewöhnlich ist. Überlegen Sie sich, wie der Zeitplan für diese Aufgaben in der Produktion aussieht - werden sie zu Spitzenauslastungszeiten ausgeführt? Wenn dies nicht der Fall ist, sollten sie vermutlich von den Auslastungstests ausgenommen werden, wenn Sie versuchen, die maximale Auslastung bei gleichbleibendem Zustand zu ermitteln, die zu Spitzenzeiten unterstützt werden kann.Keine Verwendung von Reaktionszeiten. Reaktionszeiten sind ein Feature von Visual Studio Team System (Team Test Load Agent), das die Simulierung des Zeitraums ermöglicht, den ein Benutzer zwischen dem Klicken auf einer Seite verstreichen lässt. So lädt beispielsweise ein typischer Benutzer möglicherweise eine Seite, verbringt drei Minuten mit Lesen und klickt dann auf eine Verknüpfung auf der Seite, um eine andere Site zu besuchen. Die korrekte Modellierung in einer Testumgebung ist beinahe unmöglich und bringt den Testergebnissen keinen zusätzlichen Wert. Die Modellierung ist deshalb so schwierig, da die meisten Organisationen keine Möglichkeit haben, verschiedene Benutzer und den Zeitraum zwischen Klicks in verschiedenen Typen von SharePoint-Websites zu überwachen (wie z. B. Veröffentlichungssites im Gegensatz zu Websites für die Zusammenarbeit usw.). Darüber hinaus stellt die Modellierung keinen tatsächlichen Mehrwert dar, da ein Benutzer zwar zwischen Seitenanforderungen pausiert, SharePoint Server 2010-basierte Server jedoch nicht. Sie erhalten nur einen konstanten Strom von Anforderungen mit Spitzen und Senken im Laufe der Zeit, verbringen jedoch keine Zeit im Leerlauf, so wie Benutzer zwischen dem Klicken auf Hyperlinks auf einer Seite pausieren.Kenntnisse über den Unterschied zwischen Benutzern und Anforderungen. Visual Studio Team System (Team Test Load Agent) weist ein Auslastungsmuster auf, bei dem Sie zur Eingabe der Anzahl der simulierenden Benutzer aufgefordert werden. Dies hat nichts mit den Anwendungsbenutzern zu tun, vielmehr geht es nur um die Anzahl der Threads, die von den Auslastungstest-Agents zum Generieren von Anforderungen verwendet werden. Ein häufiger Fehler besteht darin, anzunehmen, dass bei einer Bereitstellung für 5.000 Benutzer die Zahl 5.000 in Visual Studio Team System (Team Test Load Agent) verwendet werden sollte - was nicht der Fall ist. Dies ist einer der zahlreichen Gründe, weshalb bei der Schätzung der Anforderungen für die Kapazitätsplanung die Verwendungsanforderungen auf der Anzahl der Anforderungen pro Sekunde und nicht der Anzahl von Benutzern basieren sollten. Bei einem Visual Studio Team System (Team Test Load Agent)-Auslastungstest werden Sie feststellen, dass häufig Hunderte von Anforderungen pro Sekunde bei nur 50 bis 75 Auslastungstest-"Benutzern" generiert werden.Verwenden eines konstanten Auslastungsmusters für zuverlässige und reproduzierbare Testergebnisse. In Visual Studio Team System (Team Test Load Agent) haben Sie die Option, die Auslastung für eine konstante Anzahl von Benutzern (Threads, wie im vorherigen Punkt erläutert), ein intensiviertes Benutzerauslastungsmuster oder einen zielbasierten Verwendungstest zu simulieren. Ein intensiviertes Auslastungsmuster bedeutet, dass Sie mit einer niedrigeren Anzahl von Benutzern beginnen und alle paar Minuten zusätzliche Benutzer hinzufügen. Bei einem zielbasierten Verwendungstest wird ein Schwellenwert für einen bestimmten Diagnoseindikator, wie die CPU-Auslastung, eingerichtet und Versuche getestet, die Auslastung so zu halten, dass der Leistungsindikator sich zwischen den definierten Mindest- und Höchstschwellenwerten bewegt. Wenn Sie jedoch nur den maximalen Durchsatz der SharePoint Server 2010-Farm während Spitzenauslastungszeiten ermitteln möchten, ist es sinnvoller und genauer, nur ein konstantes Auslastungsmuster auszuwählen. Damit können Sie die auf das System anwendbare Auslastung einfacher bestimmen, ehe die Schwellenwerte, die in einer fehlerfreien Farm eingehalten werden sollten, regelmäßig überschritten werden.Bei der Ausführung eines Auslastungstests sollten Sie bedenken, dass Daten in der Datenbank geändert werden. Unabhängig davon, ob Dokumente hochgeladen, Listenelemente bearbeitet oder nur Aktivitäten in der Verwendungsdatenbank aufgezeichnet werden, werden Daten auf SQL Server geschrieben. Um konsistente und seriöse Testergebnisse aus den einzelnen Auslastungstests zu erhalten, sollten Sie vor der Ausführung des ersten Auslastungstests eine Sicherung erstellen. Nach jedem einzelnen Auslastungstest sollte der Inhalt mithilfe der Sicherung so wiederhergestellt werden, wie er zu Beginn des Tests vorlag.
  • http://technet.microsoft.com/en-us/library/ff823736.aspx

Transcript

  • 1. Best Practices &Performance OptimierungSamuel Zürcher, Sen. Consultant Experts Inside GmbH
  • 2. Agenda Einführung Setup- und Serviceaccounts (Least Privileged) SQL Server Installation Farm Setup (Varianten, Authentifizierung) Datenbankdesign und Erstellung Farm Konfiguration Fine Tuning (Crawling, Icons, Filehandling etc.) Q&A
  • 3. SpeakerSamuel ZürcherSenior Consultant / EvangelistSharePoint und SQL ServerMCTS, MCITP, MCT, MVPKontakt und Webauftritteszu@expertsinside.comSamuel.Zuercher@sharepointcommunity.chBlog: http://sharepointszu.comCommunity: http://www.sharepointcommunity.chKonferenz: http://www.collaborationdays.chXING: https://www.xing.com/profile/Samuel_Zuercher3Facebook: http://www.facebook.com/sharepointszuTwitter: @sharepointszuSamuel Zürcher [MVP] hat Langjährige Erfahrung mit SharePoint seit der Version 2.0, breites TechnologieKnow-how und ist seit 15 Jahren in der IT tätig. Er ist im Projektmanagement in verschiedenenProjektgrössen und Komplexitätsstufen daheim, kennt sich aber auch mit dem innersten Kern von SharePointaus. Verschiedene Zertifizierungen für SharePoint und der Microsoft Certified Trainer runden sein Profil ab(MCT, MCTS, MCIPT). Er ist der Initiant und zusammen mit Stefan Heinz Begründer derwww.sharepointcommunity.ch und Co-Organisator der Collaboration Days.
  • 4. Einführung SharePoint Komponenten (Rollen)  Web Frontend  Applikationsserver  Datenbankserver  Mail Server (Verbindung zu Exchange) Vor der Installation  Technische Voraussetzungen  Mengengerüst  Farm- und Storage Sizing (HP Sizing Tool, Capacity Planning, Farm Design beim Anmeldefenster auf Abbrechen) Hardware  Abgestimmt auf das Mengengerüst  Security- bzw. Policy Anforderungen? (DMZ, Verfügbarkeit etc.)
  • 5. Hardware Voraussetzungen Nur x64 fähige Hardware wird unterstützt Frontend- und Applikationsserver  4 Kern Prozessor  8GB RAM  80GB Systemfestplatte  Anzahl wächst mit dem Mengengerüst SQL Server (Clustered, Mirrored oder Standallone)  2 x 4 Kern Prozessor  16GB RAM  80GB Systemfestplatte  RAID 10 Disksubsystem oder Attached Storage  In der Regel 1 DB Server, in grossen Farmen 1-n DB Server  Datenbankserver langsam = SharePoint langsam
  • 6. Software Voraussetzungen Windows Server (ausschliesslich x64)  Ab Version 2008 SP2  Installieren der Prerequisites (Für Serverprodukte automatisch mit dem Prerequisites Installer) SQL Server (ausschliesslich x64)  SQL Server 2005 SP3 CU3  SQL Server 2008 SP1 CU2 (oder >= CU5) Active Directory  AD DS von Windows Server 2003 SP2 (Auch Functional Level)  Wichtig für die Profilsynchronisation, nicht wichtig für Foundation
  • 7. Merkmale erfolgreicher Projekte Erfolgreiche Intranet-Projekte mit SharePoint 2010 sind… …mit einem dedizierten Projektleiter ausgestattet …Management driven …auf die (grössten) Bedürfnisse der Mitarbeitenden fokussiert …sorgfältig geplant und gut vorbereitet …mit genügend Ressourcen unterwegs …auf scale out und scale up Szenarien vorbereitet …nicht dazu da, die User endlich auf interne Prozesse zu zwingen …new Technology, new way of work aware …klein gestartet und mit weiteren Iterationen gewachsen
  • 8. Setup- und Serviceaccounts Admin Account (Optional) Setup Account (dbcreator, securityadmin Rolle in SQL) SQL Account (SQL Instanz Principal) SharePoint Farm Account (Farm Principal) Services Account (Service Applications) 1-n Webapplikations-Accounts (1 pro Webapplikation) Webapplikations-Account für MySite Import Account für Profile (Replicate Directory Changes auf Active Directory) Crawling Account (Indexer)
  • 9. Vorbereitungen für Kerberos Wann Kerberos und wann NTLM?  Kernfrage: Muss ich später auf weitere Daten ausserhalb SharePoint zugreifen? Wenn ja, dann Kerberos zwingend Zusammensetzung eines SPN  Dienstname/Server:Port  z.B. SQLSvc/MyServer:1433 und SQLSvc/MyServer.MyDomain.ch:1433 Für welche Accounts?  SQL Service Account  Alle Webapplication Service Accounts  Farm Account ACHTUNG: Beim Crawling mit Kerberos sind nur Ports 80 und 443 zulässig, also zwingend mit Host Headers arbeiten (ausser CA)
  • 10. SQL Server Installation Genug starke Hardware Grundsatz: SQL langsam => SharePoint langsam Testumgebung 8GB RAM, Live Umgebung 16GB Sollte ein SQL virtualisiert werden? Wenn immer möglich, Nein Vorsicht, Verwirrung bei Collations  Supportmeldung: http://support.microsoft.com/kb/2008668  Technet Anweisung: http://technet.microsoft.com/en- us/library/cc262869.aspx (dient auch für’s Aufsetzen) Richtig ist Latin1_General_CI_AS_KS_WS
  • 11. Parametrisierung Fill Factor 70% T-Log Backup alle 15min bis max. 24h Disable Boost SQL Server Priority Max Degree of Parallelism 1 (für SharePoint only Instanzen) Min und Max Memory konfigurieren Temp DB auf 10GB und 4 Files verteilen, Autogrowth 1GB Lock Pages in Memory (für SQL Std. –T845) und Perform Volume Maintennance Tasks für SQL Account setzen Traceflag 1117 (-T1117) für gleichmässigen Filegrowth Backupcompression einschalten Index Maintennance <=30% Reorganisation, sonst Rebuild Update Statistics täglich, DBCC Checkdb vor Fullbackup
  • 12. Best Practice auf dem SQL Transaction Log Datenbanken Temp DBSQL Instanz für Search L1 L2 L3SQL Instanz für Daten und Konfiguration L4 L5 L6
  • 13. Farm Setup Verschiedene Varianten  Vollständig per vom DBA erstellten Datenbanken  Nur Content Datenbanken vom DBA erstellt  Setup Wizzardd Ja / Nein  Power Shell (z.B. Codeplex) Grösse der Farm ist ausschlaggebend  Kleine Farm  Von Hand, nur Content DB vom DBA erstellt  Mittlere Farm  Grossteil von Hand, DBs wenn möglich vom DBA erstellt  Grosse Farm  Je nach Deployment von Hand oder per Script und alle DBs vom DBA erstellt
  • 14. Skalierung «Single Server» WFE Applikation SQL Express
  • 15. Skalierung «Small Farm» WFE SQL ServerApplikation
  • 16. Skalierung «Medium Farm» WFE WFEApplikation SQL Server Cluster
  • 17. Skalierung «Big Farm» WFE WFE WFEApplication SQL Server Cluster 1 SQL Server Cluster 2
  • 18. Datenbankdesign und Erstellung Vom DBA erstellte DBs per Script erstellen Datenfiles auf mehrere Dateien verteilen Faustregel: 0.25 bis 0.5 mal Prozessorkerne, in der Regel 4-8 Files 1. File 128 MB und Nogrowth für System Tables Restliche Files auf gesamte DB Grösse aufteilen Log Initial 1GB (wenn es grösser sein muss 8GB) Nie Shrinkfile auf DBs ausführen Achtung, Script muss im SQLCMD Mode ausgeführt werden
  • 19. Round Robin
  • 20. SQL Scripthttp://sharepointszu.com/2012/02/17/sql-script-fr-die-erstellung-von-best-practice-sharepoint-datenbanken/
  • 21. Farm Konfiguration My Site (je nach Variante des Aufsetzens) Search Setup und Konfiguration PDF Crawling  iFilter (Foxit oder Adobe für x64 Systeme) User Profil Import aus dem AD  Achtung bei NetBios Verwendung  Timeouts und Probleme (BlogPost) Blocked Filetypes anpassen (lnk, url, pdf) Analytics und Diagnostic Logging DisableLoopBackCheck damit auf dem Server selbst lokale IIS Sites aufgerufen werden können (KB896861) Login Prompt für Explorerview vermeiden (BlogPost)
  • 22. Fine Tuning Icons für pdf, url und lnk Dateien Browserfilehandling (BlogPost, wenn das nicht hilft) OpenControl Anpassung (BlogPost) SharePoint Governance nicht vergessen (Blog Serie) Social Timer Jobs aktivieren Die Krux mit dem Search Center Für Publishing infrastruktur (Event ID 7362 BlogPost)  Cash Reader  Cash Super User Probleme nach August 11 CU (Event ID 3 BlogPost) SAN Zertifikate und Binding auf mehreren IIS Seiten appcmd set site /site.name:"<IISSiteName>" /+bindings.[protocol=https,bindingInformation=*:443:<hostHeaderValue>]
  • 23. Lasttesten von SharePoint mit Visual Studio Christian Glessner Christian Glessner
  • 24. Glauben ist gut, wissen ist besser! Ist meine Farm performant? Passt meine Topologie? Reicht meine Hardware? Wie viele Benutzer können auf meiner Farm maximal parallel arbeiten? Hat meine custom SharePoint Solution ein Memory Leak?
  • 25. Vorgehen Erstellen eines Testplans Erstellen der Testumgebung Erstellen von Tests, Tools & Testdaten Lasttest ausführen Optimieren der Architektur Bereitstellung in der Produktionsumgebung
  • 26. SharePoint Load Test Kit (LTK) Enthalten im SharePoint 2010 Administration Toolkit Generiert VS 2008 Load Test Projekt basierend auf IIS logs VS 2008 Team System und SharePoint müssen lokal installiert sein Gutes Muster, schlechte Doku
  • 27. Einfache Testumgebung Domain ControllerTest Agent & Controller SP WFE SQL Server
  • 28. Komplexe Testumgebung Azure Test Agents Domain Controller SP WFETest Controller SQL Server SP APP
  • 29. Questions & Answers….noch Fragen?!Kontakt:szu@expertsinside.comMehr zum Thema:http://sharepointszu.com/category/die-serie-best-practice/