SharePoint - SQL Failover Cluster

[Ralf123 0]

Guten Morgen,

 

ich begleite aktuell einen Kunden, welcher die Ablöse von Lotus Domino durch Exchange und SharePoint plant.

Es ist vorgesehen, das der Exchange geclustert  wird, soweit kein Problem. Allerdings stellt mich die SharePoint Infrastruktur vor Herausforderungen.

 

Dem Kunden geht es hauptsächlich darum, dass die SharePoint Infrastruktur hochverfügbar ist, und auch geplante Downtimes vermieden werden. d.h. auch bei Patchvorgängen etc.

 

Auf Exchange Ebene funktioniert das noch relativ einfach aber wie sieht das bei SharePoint und SQL aus?

 

Wie müsste da Design aussehen?

1. Auf SharePoint ebene ?

2 auf SQL Ebene (SQL Mirror, AlwaysOn-Verfügbarkeitsgruppen, AlwaysOn-Failoverclusterinstanzen) ?

 

Wie ist zu lizenzieren?

 

Welche Möglichkeiten zur Datensicherung von SharePoint Infrastrukturen haben sich bewährt?

 

Über eine Rasche Antwort würde ich mich sehr freuen.

 

Viele Grüße und allen ein schönes Wochenende.

 

Beste Grüße

Ralf

[zahni 521]

Auch hier muss wieder schreiben: SharePoint ist nicht ganz einfach und kann einem den Schlaf rauben. Unbedingt jemand fragen, der sich damit auskennt.

Beim SharePoint muss z.B. bei solchen Anforderungen nicht nur der SQL geclustert werden. Bei Microsoft findest Du div. Design-Beispiele.

 

Bei SP ist übrigens das Farm-Backup, ein Backup der einzelnen Sites und des Managed Meta Data Service eine gute Grundlage. SQL Backup kann man machen, muss man aber nicht.

[Ralf123 0]

Vielen Dank! Tatsächlich ist es sehr schwer hier jemanden zu finden, der sich mit dieser Thematik sehr gut auskennt.

 

Gibt's Erfahrungen mit Docave als Sicherungstool für SharePoint?

 

Über viele weitere Antworten würde ich mich sehr freuen.

 

Vielen Dank

 

Ralf

[Dukel 436]

Bei Sharepoint gibt es verschiedene Ebenen, die zwecks Verfügbarkeit überprüft werden.

Prinzipell sind das die Web Frontend Rolle, die per Load Balancer verfügbar gemacht wird.

Die Application Rolle kommt auf die Service Applikation an. Bei den meisten sind diese automatisch Verfügbar, solange man diese Dienste auf mehreren Sharepoint Servern aktiviert. Bei anderen Applikationen (Suche z.B.) muss man konfigurieren, welche Funktion auf welchem Server läuft.

Die SQL Rolle muss man mit SQL Mitteln verfügbar aufsetzen. Dabei sind Failover Cluster, SQL Mirror oder Alway On AG's supportet.

 

Das Backup geht mit Bordmitteln (Backup-SPFarm) oder diverse Backuphersteller bieten SharePoint Agenten an. Wir nutzen z.B. Commvault.

In Sharepoint gibt es mehrere Papierkörbe, die gelöschte Inhalte eine gewisse Zeit aufgewahren, daher ist unter umständen das Backup kaum nötig.

 

Zur Lizenzierung: Du benötigst (ausser bei Sharepoint Foundation, was ich bei 2013 nicht empfehlen würde) für jeden Server eine SharePoint Server Lizenz.

Neben den Server Lizenzen benötigst du CAL's für die Anwender. Je nach Funktionen Standard oder Standard und Enterprise CAL's.

Die SQL Sever Zugriff müssen auch lizenziert sein, die Windows Server Zugriffe auch.

[Doso 77]

Ein Sharepoint kriegt man nie ganz 100 Prozent verfügbar. Klassischer Failover Cluster für die SQL Absicherung erlebt man beim Failover eine kurze Unterbrechung, für unsere Umgebung kein Problem. Du hast leider nicht geschrieben wie groß die Umgebung ist, daher kann man schlecht beurteilen wie viele Sharepoint Server da Sinn machen..

 

Für das Backup kann man etwas mit Bordmitteln machen, viele Backup Lösungen bieten da aber auch direkte Sicherung und Wiederherstellung an. Bisher habe ich hier Erfahrung mit Backup Exec von Symantec und DPM von Microsoft gesammelt. Backup Exec kann toll sichern nur ist die Wiederherstellung hakelig, DPM ist als Microsoft Produkt da logischerweise besser.

 

Auch ich möchte nochmal darauf hinweisen das Sharepoint ein Biest ist. Sehr arbeitsintensiv für den/die Admins, viele verschiedene Technologien, hoch komplex.

[Dukel 436]

Ein Sharepoint kriegt man nie ganz 100 Prozent verfügbar. Klassischer Failover Cluster für die SQL Absicherung erlebt man beim Failover eine kurze Unterbrechung, für unsere Umgebung kein Problem. Du hast leider nicht geschrieben wie groß die Umgebung ist, daher kann man schlecht beurteilen wie viele Sharepoint Server da Sinn machen..

 

Mit SQL Mirror / Always On Groups gibt es keine Unterbrechung der Clientverbindungen. Es wird höchstens mal eine Transaktion verworfen.

 

Auch ich möchte nochmal darauf hinweisen das Sharepoint ein Biest ist. Sehr arbeitsintensiv für den/die Admins, viele verschiedene Technologien, hoch komplex.

 

Meine Sharepoint Umgebungen (sind alle eher kleinere Umgebungen) sind nach der Anfangsphase sehr Wartungsarm.

Außer die Regelmäßigen Wartungen, die bei allen IT Systemen erforderlich sind, gibt es unter umständen nicht viel zu tun.

 

Die Einarbeitung / Know-How Aufbau ist initial aber sehr hoch.

bearbeitet 15. März 2014 von Dukel

[Ralf123 0]

Hallo zusammen,

 

herzlichen Dank für die zahlreichen Antworten.

Was würdet ihr dem Kunden also empfehlen?

 

Umgebung einfach aufsetzten (SharePoint Server + SQL) Und dann halt nicht unbedingt jeden Monat Patchen?

Falls doch eine redundante Infrastruktur gewünscht ist -> zwe mal SharePoint Server  & 2 x SQL? Was ist mit Zeugenserver etc.?

 

Ihr würdet also sagen, ein Backupsystem welches einen Agent für SharePoint mitbringt, ist dann eine gute Ergänzung zu den Boardmitteln?

 

Randinformation: Der Kunde hat rund 250 PC Arbeitsplätze.

 

Ich freue mich auf eure Antworten und wünsche euch allen einen schönen Abend.

 

Beste Grüße

Ralf

[Dukel 436]

Ich würde erst mal die Anforderungen sowohl an SharePoint als auch an die Verfügbarkeit und Backup / Restore klären.

 

Wenn nicht genügend Know-How verfügbar ist sollte der Kunde oder ihr diesen extern einkaufen.

Vor allem wird eine Migration von Lotus Domino auch nicht trivial werden. Wofür wird Lotus aktuell verwendet, wofür soll SharePoint verwendet werden.

 

Man kann eine SharePoint Umgebung zwischen einem Server und mehreren Farmen mit jeweils 4-6 Server oder ganz große Farmen mit einer zwei bis dreistelligen Anzahl an Servern aufsetzen und Planen.

Kommt alles auf die Anforderungen an.

[Doso 77]

Sharepoint patcht man sowieso nicht allzu oft. Macht keinen Spass und die CU bringen auch gerne mal Bugs mit. Wie gesagt ist das mit Hochverfügbarkeit und Sharepoint ein schwieriges Thema, und ganz ohne Downtime geht fast gar nicht. Ich kann mir auch nicht vorstellen das man bei Brückentagen o.ä. nicht mal 2 Stunden auf Sharepoint 1x im Jahr verzichten kann.

[Stefan3110 11]

Hallo,

ich bin der festen Meinung dass Du jemanden mit SharePoint Erfahrung hinzuziehen solltest. Exchange kann installiert und konfiguriert werden und es rennt. Ab und an überprüfen und alles ist okay. Sehr grob gesprochen.

SharePoint benötigt 2 Stufen. Einmal Installation und Konfiguration und zum zweiten der Aufbau des SharePoint Inhalts für den Kunden.

SharePoint Installation und Konfiguration fängt beim SQL an. Da kommt die Frage welche SQL Versionen sind im Einsatz? Wie sieht das Storage Konzept aus? Wie sicher sollen die Daten sein?...

Dann kommt SharePoint auf mindestens 2 Servern. Auch hier wieder die Frage welche Services sollen laufen? Wie hoch ist der zu erwartende Content? Wie wichtig ist Suche? Wie sieht die Anbindung ans AD aus? … Es gibt auch Services die nicht hochverfügbar ausgelegt werden können. Wie greifen die Anwender auf den SharePoint zu? Sicherheit? HTTP oder HTTPS?

Der 2. Part ist den User an die Hand nehmen und mit ihm gemeinsam die Struktur des SharePoints bereitstellen. Ein Thema ist die Informationsarchitektur? Hier scheitern sehr viele Sharepoint Projekte da sie vom Enduser nicht angenommen werden. SharePoint muss auf die Prozesse des Kunden angepasst werden.

 

Viele Grüße

Stefan

[Daniel -MSFT- 129]

Für letzteres würde ich eine SharePoint Online-Testversion empfehlen. Die läuft in 10 Minuten, ist hochverfügbar und man kann sich sofort auf die Informationsarchitektur (tolles Wort) konzentrieren. Bei Userakzeptanz dann entscheiden, ob man es im Haus oder weiter online betreiben will.