Ich stelle es immer wieder fest, wenn ich in ein neues Projekt komme; abhängig davon, wen man fragt, hat der Begriff Architektur eine andere Bedeutung. Das Management, der IT-Leiter und der Projektmanager haben unterschiedliche Vorstellungen. Genau gleich verhält es sich auch innerhalb der IT. Egal wen ich frage – sei es jemand aus dem DB-, Server, Netzwerk- oder Client-Team – jeder hat eine eigene Vorstellung davon, was das Wichtigste an einer SharePoint Architektur ist. Und jeder hat mit dem was er sagt irgendwo recht.
Denn SharePoint ist nicht einfach eine isolierte Applikation. SharePoint ist viel mehr eine Plattform und interagiert mit zahlreichen Applikationen und Diensten.
Ein kleines Beispiel:
Wollen wir eine SharePoint Farm aufbauen, können wir nicht einfach einen SharePoint hinstellen und los geht’s. Wir brauchen im Minimum eine Server-Infrastruktur, ein Netzwerk, DNS-Einträge, eine Datenbank, Speicherplatz und ein Active Directory. Um eine SharePoint Farm realisieren zu können, brauchen wir also zahlreiche Leute aus verschiedenen Bereichen. Diese sind von Anfang an zu identifizieren und ins Boot zu holen.
Haben wir die richtigen Personen aus der Technik gefunden, brauchen wir noch Mitarbeiter aus dem Business. Personen die mit dem Endprodukt Arbeiten werden. Denn nur so können wir bestimmen – und uns darauf einigen – worauf der Fokus liegt und wie die Plattform eingesetzt wird. Denn auf die Frage: “Wozu brauchen wir SharePoint?” gibt es zahlreiche Antworten.
Anforderungen & Abklärungen
Haben wir nun also eine Gruppe aus technisch versierten Spezialisten, dem Projektteam und einer gut durchmischten Gruppe aus dem Business, dann kann es mit der Aufnahme der Anforderungen losgehen. Denn diese sind vielseitig – will man nicht den Fehler machen und den Fokus nur auf die technischen Aspekte legen.
Anforderungen beim Kunden abholen
Wichtig ist dabei immer eines: Der Kunde ist im Fokus! Anforderungen sollten deshalb nicht nur beim Projektleiter und der IT des Kunden abgeholt werden, sondern auch direkt bei einer Auswahl von End-Usern. Auch die Fachteams sind frühzeitig miteinbeziehen. Folgende Punkte stehen dabei im Vordergrund:
- Bedienbarkeit
- Dienste
- Funktionen
- Nachhaltigkeit
- Monitoring
- Performance
- Plattform
- Sicherheit
- Skalierbarkeit
- Verfügbarkeit
- Virtualisierung
- Wartbarkeit
Abklärungen bezüglich…
Nachdem die Anforderungen definiert wurden, geht es darum, diverse Abklärungen zu machen. Das geht am Besten mit einem Workshop, in welchem die Fragen offen und mit den entsprechenden Personen diskutiert werden. Wichtig ist dabei, eine offene Plattform zu bieten. Es sollen bewusst auch Personen miteinbezogen werden, die nicht zwingend auf die Themen spezialisiert sind. So stellen wir sicher, dass wir keinen Tunnelblick haben und keine wichtigen Aspekte verloren gehen. Natürlich sollte ein Workshop immer in einem vernünftigen Rahmen bleiben und nicht mehr als 6-10 Personen ansprechen. Dabei hat sich ein iteratives Vorgehen bewährt.
- Anzahl Benutzer
- Sprachen
- Plattform
- Verfügbare Infrastruktur
- Virtualisierung
- Server
- Unternehmensstandards
- Aufbau
- Eingesetzte Hardware und Software
- Unternehmensstandards
- Verfügbarkeit
- Betriebszeiten
- Maximale Dauer bis zur Wiederherstellung
- Netzwerk
- In welchen Zonen stehen die Server
- Sind Firewalls vorhanden
- Active Directory
- Domain Name
- NetBIOS Name
- AD Forest / Child Domains
- ADFS
- Externer Zugriff
- Funktionen
- Lizenzierung
- Web Applications
- Einsatzzweck
- Hostnamen
- Aufbau mit Site Collections / Subsites
- Datenmengen
- Initiale Grösse
- Jährlicher Zuwachs
- Storage
- Unternehmensstandards
- Disk Subsystem
- Datenbanken
- Unternehmensstandards
- DBAs miteinbeziehen
- Namenskonventionen
- Service Accounts
- Namenskonventionen
- User Profile Sync
- Zu synchronisierende OUs
- Zusätzliche Properties
- Search
- Zu durchsuchende Ressourcen
- Intervall
- E-Mails
- Konfiguration von eingehenden und ausgehenden E-Mails
- Hostname des Mailservers
- Clients
- OS
- Office
- Internet Explorer
- Vorhandene Policies
Architektur festlegen
Keep calm and know the SharePoint limits
Werfen Sie einen Blick auf diesen TechNet Artikel: Software boundaries and limits for SharePoint 2013
- Boundaries, Thresholds and Limits
- Boundaries: Fixe Limiten, keine Überschreitung zulässig
- Thresholds: Schwellwerte, je nach Szenario anpassbar
- Supported limits: Konfigurierbar, auf ein getestetes Limit gesetzt
Auswahl der Plattform
Kommen wir nun zu den entscheidenden Fragen, welche das Design unserer SharePoint Farm beeinflussen. Zuerst stellt sich die Frage nach der Plattform. Bauen wir die Farm On-Premise auf, Hybrid oder ganz in der Cloud? Office 365 und Azure sollten dabei immer als mögliche Alternativen geprüft werden. Denn dorthin geht über kurz oder lang die Reise.
- On Premises
- SharePoint in Office 365
- Hybrid mit Office 365
- Microsoft Azure
- Office 365 und Directory Components in Microsoft Azure
- Internet Seite und Microsoft Azure AD für Externe
- On Premises mit Disaster Recovery in Microsoft Azure
Faktoren zur Bestimmung einer Farm Topologie
Die Plattform ist gefunden. Nun müssen wir uns überlegen, wie das Design der SharePoint Farm aussehen soll. Drei Faktoren sind dabei besonders bestimmend. Die Kosten, die Performance und die Wartbarkeit der Lösung. Mit der Performance steigen auch die Kosten, jedoch steigt die Wartbarkeit nicht zwingend – eher im Gegenteil. Denn durch eine zu komplexe Architektur läuft man Gefahr, dass der reibungslose Betrieb nicht mehr gewährleistet werden kann. Also Vorsicht!
Topologie definieren
Die traditionalle Topologie besteht aus Web Front-end Servern, Application Servern und Datenbank Servern. Dabei sind die Rollen ganz klar verteilt. Die Web Front-end Server sind für das Anzeigen der Inhalte verantwortlich, während auf den Application Servern die Dienste laufen.
Mit SharePoint 2013 wird bevorzugt die Streamlined Topology verwendet.
Traditional Topology
- Web servers
- Application servers
- Database servers
- Streamlined Topology
- Front-end servers
- Batch-processing servers
- Database servers
Verteilung der Services in einer Streamlined Topology
Dienste ausserhalb von SharePoint
- Workflow Manager 1.0
- Installation auf 1, oder 3 Servern, nicht auf zwei (immer ungerade Anzahl)
- Kann auf einem Server zusammen mit SharePoint installiert werden
- Office Web Apps Server 2013
- Muss auf dedizierten Servern installiert werden
- Kommuniziert über WOPI (Web Application Open Platform Interface)
- Kann auch an andere Applikationen angebunden werden
- AppFabric
- Wird mit den SharePoint Pre-requisites installiert
- Nicht selbst installieren oder vorhandene AppFabric Installation verwenden
- Stellt den Distributed Cache Service bereit
Performance Richtwerte
Vorgaben
Vorgaben bezüglich…
Nach dem wir alle wichtigen Informationen gesammelt haben, geht es darum, diese schriftlich zusammenzufassen. Zu diesem Zweck erstellen wir ein Infrastrukturkonzept. Einerseits werden dort die Anforderungen und Abklärungen eingearbeitet, andererseits nutzen wir das Konzept auch um Vorgaben zu machen.
- Hardware
- Virtuell oder physisch
- Anzahl CPUs
- RAM
- Software
- Betriebssystem
- SharePoint
- SQL
- DNS Einträge
- Web Applications
- Apps
- Service Hosts bei Load Balancing
Diese betreffen ganz unterschiedliche Themengebiete und sollen den Fachteams dabei helfen, die Ressourcen optimal zu konfigurieren. Natürlich soll hier ein Dialog mit den Teams stattfinden.
- Storage
- Anzahl Partitionen und Diskgrössen
- Geschwindigkeit
- RAID
- IOPS
- Service Accounts
- Namenskonventionen
- Berechtigungen
- Group Policies
- Testing
- Produktions-, Pre-Production-, Test-, Entwicklungs-Umgebung
- Qualitätssicherung
Ausschlaggebend für das Design einer Farm ist die Informationsarchitektur. Meine Empfehlung lautet deshalb, die Informationsarchitektur und eine entsprechende Governance zu definieren, bevor mit dem Design oder gar dem Aufbau der Farm begonnen wird. Behalten Sie sich dabei auch immer im Hinterkopf, dass sich die Architektur über die Zeit verändern wird.
- Web Applications
- Governance
- Aufbau mit Site Collections / Subsites
- HTTP oder HTTPS
- Kerberos oder NTLM
- Custom Authentication Provider
- Application Pools
- Managed Paths
- Self Service Site Creation
- Firewall
- Load Balancing
- Zertifikate
Ein ganz wichtiger Punkt ist der Aufbau der Datenbank Server. Dabei gilt immer: Ist der SQL schnell, ist auch SharePoint schnell. Deshalb sollten Sie die DBAs schon in der Konzeptionsphase in die Verantwortung nehmen und ihr Wissen einfliessen lassen.
- Datenbanken
- Single Server, Cluster, Mirroring
- Konfiguration
- Namenskonventionen
- Maintenance Pläne
- Best Practices für SharePoint
- Backup
- Was, wie, wann, womit
- Disaster Recovery planen
- Patching, Updates, Releases
- Zyklus und Prozess festlegen
- Tests
Feinschliff
Host named oder Path based Site Collections?
Social
- User Pofile Service
- Active Directory Import ist schnell und einfach implementiert
- Forefront Identity Manager ist gleich wie in SharePoint 2010
- My Sites
- Sind ein Muss!
- Werden für Social Features, Tasks und OneDrive for Business benötigt
- DirSync
- Wird für Yammer und Office 365 benötigt
- Neu in Service Pack 1 (On-premises)
- OneDrive for Business auf Office 365
- Social Feed mit Yammer ersetzen
Zertifikate
- In produktiven Umgebungen unbedingt einsetzen
- Apps
- Workflow
- Office Web Apps Server 2013
- Exchange
- Web Applications
- Central Administration
Backup, Restore, Disaster Recovery
- Disaster Recovery Strategie planen
- Cold, warm, hot Stand-by
- Recovery Point Objective (RPO)
- Letzter Zeitpunkt, auf den Daten wiederhergestellt werden können
- Recovery Time Objective (RTO)
- Maximale Downtime
Vorsicht bei…
- Multi Tenant Farm
- Ein Einsatz ist nur in sehr seltenen Fällen nötig und sinnvoll
- Vorgesehen für grosse Hosting Szenarios
- Prüfen, ob Office 365 eine Alternative ist
- Mit sehr viel Customizing-Aufwand verbunden
- Stretched Farm Szenario
- Mehrere Farmen in verschiedenen Datacenters
- Service Application Federation stellt IT vor Herausforderungen
- Latenz <1ms
Fazit
- Anforderungen aus dem Business kommen an erster Stelle
- Klein anfangen und skalierbar bauen
- Die Farm so einfach wie möglich aufbauen
- Iteratives Vorgehen
- Zuerst das Konzept schreiben, danach mit der Umsetzung beginnen
