Hochverfügbarkeit in System Center 2012 Configuration Manager

Keine Kommentare zu Hochverfügbarkeit in System Center 2012 Configuration Manager

Wer en System Center 2012 Configuration Manager einsetzt, oder plant einzusetzen, steht irgendwann vor der Frage, wie Ausfallsicher die geplante Lösung ist, bzw. was man tun kann um die bestehende Umgebung ausfallsicher zu machen. Leider gibt es hier keine einheitliche Antwort. Die Lösung findet sich in den individuellen Anforderungen, der Struktur und der Priorisierung der entsprechenden Umgebung.

Zunächst ist einem, wie in den meisten Fällen, das Technet ein guter Freund und Helfer: Technet – Planning for High Availability with Configuration Manager

Zunächst sollte man sich Gedanken machen wie kritisch die Umgebung ist. In der Regel erfüllt der SCCM folgende Aufgaben:
– Update-Verteilung
– Software-Verteilung
– OS-Deployment
– Inventarisierung
– …

Man sollte also hinterfragen:
Ist es kritisch, wenn das anstehende Firefox-Update zwei Tage später ausgerollt wird?
Was passiert wenn die Inventarisierung einen Tag zu spät ausgeführt wird?
Ist es dem Nutzer zuzumuten, dass er eine Applikation, die er bisher nicht hatte, nich heute, sondern morgen bekommt?

Hier zeigt sich schnell, dass der SCCM etwas weniger kritisch eingestuft werden kann als beispielsweise der Exchange-Server.

Doch ab einer gewissen Anzahl an Clients nimmt die Häufigkeit der Konfigurationsänderungen zu und somit steigt auch der Anspruch an die Verfügbarkeit.

Wo kann man aber dann ansetzen…?

1. SQL-Datenbank
Eine der wichtigsten Komponenten des SCCM ist die Datenbank. Neben einem recht hohen Anspruch an Performance und Ressourcen, sollte diese bei der Betrachtung der Hochverfügbarkeit vorne an stehen. Es gibt mehrere Möglichkeiten die SQL-Datenbank zu schützen. Der beste und sicherste Weg ist es, die SCCM-DB in einem SQL-Cluster zu betreiben. Damit ist die Datenbank durch die Failover-Funktion der SQL-Instanz geschützt. Dies erfordert jedoch das Vorhandensein eines gemeinsamen Storages. Dies kann gerade in verteilten Szenarien der Hinderungsgrund sein.

Ein weiterer Weg ist es mit Datenbankreplikaten zu arbeiten. Hierbei wird die Datenbank der Site (nicht von Secondary Sites) auf einen separaten SQL-Server repliziert. Es ist hierbei nicht notwendig, über ein shared storage zu verfügen. Bei der Replikation wird keine direkte Ausfallsicherheit der Datenbank erzeugt. Jedoch ist möglich durch den Einsatz mehrerer Verwaltungspunkte die Clients weiterhin mit Software, Updates, etc. zu versorgen, da die Verwalungspunkte das SQL-DB Replikat nutzen können um weiterhin Informatonen bereitzustellen. Es ist jedoch ncotwendig separate Server für die Verwaltungspunkte vorzusehen
Näheres findet sich wir immer im Technet – Configure Database Replicas for Management Points

Als letzter und in jedem Fall notwendiger Schritt gilt die regelmäßige Sicherung der Datenbank des SCCM.

2. Verwaltungs- und Verteilungspunkte
Wie bereits erwähnt ist es möglich in einer Site zusätzliche Verwaltungspunkte zu installieren. Diese verweisen auf ein Replikat der SCCM-DB. Dadurch ist es möglich, zum Einen die Last auf den Datenbankservern zu verteilen, und zum Anderen im Falle eines Ausfalls den Clients weiterhin aktuell anstehende Aktionen zu übermitteln.

Ähnlich verhält es sich mit den Verteilungspunkten. Um die Last der anfragenden Clients zu verteilen und im Falle eines Serverausfalls dennoch alle Clients versorgen zu können, empfiehlt es sich zusätzliche Verteilungspunkte zu konfigurieren. Je nach Umgebung sind Verteilungspunkte für zusätzliche Standorte, Gebäudeteile oder Abteilungen sinnvoll. Zu bedenken gilt hier die Bandbreite zwischen der Punkten, die Kapazität der Server und die sinvolle Verteilung.

3. SMS Provider und Management-Konsole
Alle Verfügbarkeit der Site-Systeme und Rollen nützt nichts, wenn die Verwaltung des SCCM nicht mehr möglich ist. Also gilt es auch hier vorzusorgen. Hilfe bringt erneut das Technet – Planning for the SMS Provider in Configuration Manager
Der SMS Provider steuert den Zugriff auf die SCCM Datenbank. Ist also der Server der den SMS Provider hält nicht verfügbar, so kann die Management-Konsole sich nicht mit der SIte verbinden. Das bedeutet, dass bis zur Wiederherstellung des Server keine Konfigurationsänderungen am SCCM vorgenommen werden können. In vielen Fällen ist dies hinnehmbar. Greifen jedoch viele Nutzer auf die SCCM-Konsole zu, so ist es wichtig diese ebenfalls verfügbar zu halten. Außerdem sollte darauf geachtet werden, dass die Last auf dem SMS Provider nicht zu hoch wird, um eine performantes Arbeiten zu ermöglichen.

Mit dem SCCM 2012 ist es nun möglich den SMS Provider auf mehreren Servern zu installieren. Hierdurch kann im Falle eines Ausfalls des Site Servers weiter auf die Management-Konsole zugegriffen werden. Voraussetzung ist jedoch, dass die SCCM-Datenbank (kein Replikat) verfügbar ist, das der SMS Provider nur mit der original DB arbeitet.

Versucht man sich mit einer Management Konsole zu verbinden, so wird wahlfrei ein vorhandener SMS Provider verwendet. Es ist dabei nicht möglich zu steuern über welchen Provider man sich verbindet.

4. Weitere Rollen
Es gibt noch eine Reihe weiterer Rollen, die hoch verfügbar gemacht werden können. Alles weitere dazu findet sich im Technet

Eine wichtige Neuerung ist beispielsweise die Möglichkeit mehrere Softwafreupdatepunkte innerhalb einer Site zu betreiben…

Fazit
Viele Wege führen nach Rom. Man sollte genau betrachten, wie kritisch der SCCM für das eigene Unternehmen ist, welche Auswirkungen die einzelnen Optionen haben und welche Einstellungen sinvoll sind. Also viel Spaß mit dem SCCM…

Related Posts

Leave a comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Back to Top