(Last Updated On: 27. Januar 2015)

Was ist ein SLD?

Eine SLD steht für System Landscape Directory. Sie dient als zentrale Qeulle für infomrationen über die SAP-Systemlandschaft. Dadurch stehen immer informationen zur Verfügung, welche Produkte auf welchen Systemen installiert wurden, sodass man diese Produkte über beispielsweise den Solution Manager warten zentralisiert warten kann.  Damit können Software-Lifecycle-Aufgaben geplant werden, beispielsweise das Update bestimmter SAP-Produkte auf den neuesten SP-Level.

Das SLD basiert dabei af einem nicht-proprietären standard der Distirbuted mangement Task Force, genannt Common Information model (CIM).

Das System Landscape Directory unterscheidet zwischen technischen Systemen – also Serverhardware, auf denen später SAP-Lösungen installiert werden können – und den Applikationen, die darauf alfuen. Diese Daten werden automatisch geupdatet – wird eine neue SAP-Kompoenten auf einem technischen System installiert oder entfernt, wird diese information von diesen Produkten an das SLD und von dort automatisch an die anderen Bestandteile der landschaft verbreitet.

Das SLd enthält zwei Warten von Informationen über die Landschaftstopolige:

• Landschaftsbeschreibung: welche Sfotwarekompoenten sind gerade in der Landschaft installiert. dazu werden detaillierte informationen über die Version, das Patch- / SP-Level, die Verbindungen zwischen den Systemen und die informationen über die Hosts (Betriebssytem, Hostname, Datenbank usw.) gespeichert.
• Komponenten information: welche softwarekompoenten können theoretisch in der Landschaft installiert werden? Hier werden die möglcihen Abhängigkeiten und Kombinationen der Lösungen beschirben. Das SLD weiß ganz genau, welches produkta uf welcher Plattform mit welcher Datenbank laufen kann, und bildet hierbei genau die Abhängigkeiten ab, die dazu erfüllt sein müssen.

Alle SAP-Komponenten – und unterstützte Drittanbietrkomponenten – haben Funktionen eingebaut, welche informationen über sich selbst an das SLD schicken und dort hinterlegen.

Das SLD ist eine Komponente von SAP NetWeaver und ist komplett mit Java-technologie implementiert. Sie wird ausgeliefert als jva-komponente auf einem Application Server java. Bei jeder installation eines NetWeaver mit Usage Type Application Server java ist das SLD autoamtisch mit installiert. Da beim SAP Solution Manager auch ein NetWEaver AS Java implementiert ist, aknn man auf dem Solution Manager auch ein lokales SLD betreiben.

Die Clients, welche Infomrationen an das SLD senden, werden Data supplier genannt. Jedes SAP-Produkt und auch unterstüzte Drittanbieterprodukte können als Data supplier für ein SLD dienen, indem man einfach den Hostnamen  und Port eingibt.

Clients können – und müssen logischerweise auch – Daten vom SLD lesen können – biespielsweise der solution Manager, wenn er wissen will, welchen SP-Level eine bestimmte SAP-Komponente gerade hat.

 

Hier ein nützliches Dokument von SAP über das SLD

SLD Topologien

Man kann ein SLD auf verschiedene Arten und Weisen betrieben. Jnede option hat verschiedene Vor- und Nachteile.

Grundsätzlich ist gleich vorweg zu sagen, dass es nicht ein SLD pro Systemlandschaft gibt, sondern mehrere. Es gibt immer ein sogenanntes Central SLD, welches alle informationen sammelt, und mehrere local SLDs.

Dafür gibt es ehrere Gründe. Stellt euch tmal ein großes Unternehmen mit vielen Niederlassungen in verschiedenen Ländern vor. Es wäre verständlich, dass die einzelnen Länder oder sogar Bundesländer ihre Systeme einzeln warten wollen und daher nur informationen über IHRE SAP-Systeme sehen wollen, und nicht auch noch über die SAP-Systeme in Indien oder sonst wo. Dafür braucht man ein dediziertes SLD werlches verschiedene Views auf die Daten des Gesamt-SLds bereitstellen kann.

In meinem post SAP: geschichte und Einführung habe ich außerdem die sogenannte Drei-Stufen-Landschaft vorgestellt. Dabei gibt es eine Landschaft zum Entwickeln neuer SAP-Systemlandschaten, eine zum Testen der zuvor entwickelten Landschaften, und eine zum produktivbetrieb. Natürlich wollen diejenigen, die ein System entwickeln oder testen, ebenfalls ein SLD haben, da die Systeme später im Produktivbetrieb ja auch mit einem SLD betrieben werden. Es wäre also schwachsinn, bie der Entwicklung und beim Test eines Systems ohne SLD zu arbeiten. ES amcht aber keinen Sinn, dafür das selbe SLd wie für den produktivbetrieb zu wählen, da dies zusätzliche Laust auf dem produktiv-SLD erzeugt, zu möglichen Fehlern führen kann, die die produktivlandschaft schädigen können, und weil die Entwickler und Tester nicht unbedingt den selben Vertrauensstatus haben wie ide Administratoren des produktivsystems. Deswegen sollte mana uch hier gesonderte SLDs haben.

Und desweiteren möchte man natürlich die Verfügbanrkiet des SLDs erhöhen, indem man mehrere SLDs aufsetzt, falls eines mal ausfällt.

Wenn es aber nun mehrere SLDs in einer Systemlandschaft gibt, muss es möglich sein, SLD-Daten zwischen diesen SLDs auszutauschen – denn wenn sie sich nicht unterhalten, hat jeder nur einen Teil der Gesamtinformationen über eine Systemalndschaft.

Deswegen gibt es verschiedene Methoden, SLD-Daten zwischen den SLDs auszustauschen:

• Vollautomatische Synchronisation. Wenn in einem SLD Daten geändert werden, werden diese änderungen autoamtisch an die anderen SLds weitergelietet. Die Synchronisation kann uni- oder bidirektional erfolgen. Sinn macht in den meisten Fällen bidirektional, das heißt immer das SLD, bei dem sich etwas an den SLD-Daten änder,t gibt diese an ein anderes SLD weiter. Bei unidirektional würden infomrationen nur weitergegeben werden, wenn sich bei dem SLD etwas ändert, welches als Data supplier definiert würde. Ändert sich was beim empfangenden SLD, sendet diese die informationen nicht weiter. Ausnahme: Man hat eine Art ring-Topologie gebaut, bei welchem im Stille-post-Prinzip ein SLD unidirektional seine Änderungen immer an einen Nachbarn weitergibt, dieser an den nächsten, usw. – bis ein _Kreis geschlossen wird. Die Synchornisation kann asynchron stattfinden. Ist ein SLD also beispielsweise mal down oder wird neugestartet, kann es sich währenddessen stattfindende Änderungen nachträglich von einem Partner-SLD abholen. Diese Synchronisation ist sehr wichtig, wenn man die Verfügbanrkit des SLDs erhöhen will, indem man zusätzliche SLDs hinzufügt, da somit ein automatisches Backup stattfindet. Desweiteren wird diese Synchronisation oft genutzt, wenn man ein SLD mit neuerem Release in die Landschaft integrieren will – man hotl sich die Daten vom alten SLD – ist das abgeschlossen, kann man das alte SLD ebenfalls upgraden oder ausschalten.Wichtig bie der automatischen Synchronisation ist, dass das unique path principle nicht verletzt wird. DAs bedeutet: Daten können immer nur auf einem Weg von einem SLD zum anderen gesendet werden.
• Automatische Weiterleitung von Data Suppliers (Birdge Forwarding). Funktioniert leider nur für bestimmte Daten. Manuell vorgenommene Äönderungen am SLD, etwa Businesssysteme, die für NetWeaver PI gebruacht werden), können nicht weitergeleitet werden. Diese option wird deshalb oft nur dann genutzt, wenn die  vollautomatische Snychronisation nicht geht.
• Manueller Datenexport und Datenimport, kombiniert mit dem Transport von SLD objekten mit dem Change and Transport System (CTS+). Eines der SLDs wird als Master SLD ausgewählt – von diesem aus kann man die anderen SLD Instanzen updaten.

in der Praxis werden immer mehrere dieser Mechanismen zur Synchronisation in kobmination genutzt. Dabei darf man aber nicht mehrere Mechanismen für die selben SLD Daten auf dem selben synchornisationspfad nehmen. Man synchronisiert also nicht von SLD A nach SLD B einmal vollautoamtisch und einmal mit automatischer Weiterleitung. Das macht ja schließlich auch keinen Sinn und erzeugt nur unnötigen Datenoverhaead. Es macht aber beispielsweise sinn, mit automatischer Weiterleitung zu synchroniisieren, und manuelle Än derungen, die so nicht wietergeleitet werden könnten, mit Import/Export zu synchronsiieren.

Nun gibt es einige Entscheidungen zu treffen

• wie viele SLD instanzen wollen wir in unserer SLD Landschaft haben
• Wo sollen wir diese SLD Instanzen laufen haben – entweder als dedizierte SLD Systems, die nur idese eine Aufgabe haben, oder verwaltete Systeme wie beim Solution Manager, oder eine Application Systeme, also einem NetWeaver, wo Applikationen drauf laufen

eine sehr wichtige Basis abhängig davon, wie man seine SLD-landschaft pülant, ist die Tatsache, ob man in seiner SAP-Gesamtsystemlandschaft die beiden Lösungen SAP NetWeaver PI und/oder Web Dynpro java applications nutzen möchte.

ohne NetWeaver PI und Webdynpro Java applications

Generell ist es empfohlen, ein SLD für die Entwicklungs- und Testlandschaft (Desing-time-SLD) zu haben, und ein SLD auf dem SAP Solution Manager, welches für die proudktivlandschaft zuständig ist.

Solltet ihr – aus welchem Grund auch immer, eure bestehende SLD-Topologie irgendwann einmal ändern müssen, liefern folgende SAP-notes Infos darüber, wie man bestimmte änderungen an der SLD-landschaft durchführt.

Die SLD data suppliers aller Systeme – also die Komponenten der vom SLD verwalteten Systeme sowohl in der entwicklungs-, Test- als auch in der Produktivumgebung, die ihre Daten an das SLD schicken, schicken diese na das SLD vom Soltuion manager.  Somit können bestimmte operationen für alle Komponetnen sämtlicher Landschaften durchgeführt werden. Und desweiteren kann man die Daten ssämtlicher Landschaften von einem einzigen SLD aus administrieren.

Bisher ist das Desing-Time-SLD noch nicht genutzt worden. Wir haben bisher die Data supplier so konfiguriert, dass sie alle das SLD auf dem Solution manager nutzen, egal ob die systeme in einer Produktivumgebung sind oder nicht.

Die SLD-Clients werden so konfiguriert: Die SLD-cleitns aller produktivsteme nutzen das SLD auf dem Solution Manager.

Die SLD-Cleitns der QA- und Entwicklungssysteme nutzen das Design-time-SLD.

Jetzt werdne sich einige von euch vielleicht denken: Ok…. wait what?

Also: Zurzeit ist es so: die Data suppliers aller Systeme senden technische informationen (beispielsweise überinstallierte SAP-Produkte und Drittanbieterprodukte auf dem System, installierte datenbankinstanzen auf dem System, Datenbankparameter usw.) nur an das SLD des SAP Solution Managers. Nur das SLD des SAP Solution managers verfügt also zurzeit über Landschaftsinformationen. Und derzeit sind auch nur die SLD-Clients der proudktivsyteme dazu in der Lage, Daten vom SLD des solution managers zu lesen, da nur sie auf das SLD des SolMan zugreifen. Die Qa- und Entwicklungssysteme greifne auf das noch leere SLD in der Design-Time zu.

Damit die QA- und Entwicklungssysteme mit dem Design-Time-SLD nun was anfangen können, müssen wir eine Art Synchronisation zwischen dem SolMan-Central-SLd und dem Design-Time-SLD hinkriegen. Dazu nutzen wir eine unidirektionale vollautomatische Synchronisation vom Central-SLD des SolMan zum Desing-Time-SLD. Das heißt: Alle Informationen und Änderungne im Solman SLD werden in das Design-Time-SLD übernommen.

Der Grund dafür, dass man die QA- und Entwicklungssysteme nun nicht direkt auf das Central-SLD zurgeifen lässt, ist der, weil es dadurch zu Problemen auf dem produktiven Central-SLD kommen könnte. So werden alle kritischen Prozeduren und Transaktionen der QA- und Entwicklungssysteme praktisch nur auf dem Design-Time-SLD durchgeführt und das Central-SLD ist sicher.

Mit NetWeaver PI und webdynpro Java applications

Die nutzung von NetWeaver PI und Webdynpro Java Applications verändern das Design ein wenig. Wir haben auch hier ein Design-Time-SLd für Entiwkclungs- und WA-Systeme. Wir hjaben auch hier ein SLD auf dem SAP Solution Manager. Was neu hinzukommt ist, dass wir nun zusätzlich ein SLD für unsere produktivsysteme haben.

in diesem Szenario ist das Central SLD nicht das SLD auf dem SolMan, sondern das SLD für die Produktivumgebungen. Alle Systeme in der Landschaft schicken mit ihren data supplieren ihre informationen an das Central-SLd. Auch die Data supplier des SLD auf dem Solution Manager schicken ihre Daten an das Central SLD der produktivumgebung.

Die SLD-Cleints werden dann wie folgt konfiuguriert: der SAP Solution manager nutzt sein eigenes SLD. die produktivsystem holen sich ihre SLD-Daten vom Central-SLD, und die Test- und QA-Systeme nutzen das Desing-time SLD.

damit das ganze funktioniert, müsen auch hier die Daten aus dem Central-SLd an die bieden anderen SLDs weitergegeben werden.  Das geschieht auch hier meist über eine undirektionale vollautomatishce Snchronisation. Das Central-SLd braucht aber manchjaml zusätzlich informationen über Business Syteme, Produkte und Softwarekompontenen aus der Testumgebung, weil diese Daten von NetWeaver PI gebraucht werden. Dazu exportiert man die Daten aus dem Design-Time-SLD auf das Central-SLD ü+ber das CTS+.

Landschaften in der Praxis

Die beiden oben gezeigten Szenarien zeigen uns also, dass wir mehrere SLDs brauchen. DAbei müssen diese SLds aber nicht extra auf einem besonderen Serverhost installier sein. die SLDs sind hierbi als logische Systeme zu sehen. Diese logischen Systeme können auch mit anderen logischen Systemen auf einem einzigen physikalischen Server laufen. Beispielsweise wäre es im Szenario mit NetWeaver PI und/oder Web/Dynrpo-applikationen möglich, dass das Design-time-SLD auf dem selben Host läuft, der NetWeaver PI zur Verfügung stellt.

Meistens wird zusätzlich zu den hier aufgezeigten SLDs ein sogenanntes Backup-SLD eingerichtet. dieses Basckup-SLD erhält die Datena us dem jeweiligen Central-SLD per unidirektionalem vollautomatischen Backup. Unter zuHilfenahme von virtuellen IP-Adressen (VIPA) ist es möglich, bei Bedarf sofort auf das Backup-SLD zu wechseln, wenn das Central-SLD mal Probleme hat.

die oben dargestellten Szenarien sind natürlich immer nur eine Stndardempfehlung. Man kann diese Szenarien jeweils nach eigenen Bedürfnissen customizen. Beispielsweise könnte es sinnvoll sein, dass eine Web Dynpro Anwendung ihr eigenes SLD nutzt und dazu Daten vom Central-SLD eingespeist bekommt.

Desiweteren kann es ja möglich sein, dass ein Beratungshaus oder ein Hosting Provider die SAP-Systemlandschaften mehrerer Kunden betreut. Hier könnte es beispielsweise sinnvoll sein, für jeden Kunden eines der besprochenen szenarien zu installieren, und von diesen Central-SLDs die Daten an ein Master-SLD ´weiterzuleiten, welches die SLD-.Daten aller Kunden enthält.

Daten in einem SLD, welche manuell erstellt wurden, werden nicht automatisch synchronisiert. diese müssen über die import-/Exportfunktion verteilt werden.

SAP-Note-Nummer	Titel	Beschreibung
9355474	Grupieren von SLD INstanzen	Diese Note beschreibt das zusammenführen von zwei SLD instanzen indem man den inahtl von einem in ein anderes SLD importiert
936318	Teilen von SLD instanzen	Diese Note beschreibt wie man eine SLD Instanz in zwei oder mehrere aufteilt
935245	Bedeutung des Object Server SLD PAramters	diese Note beschreibt die konsequenzen von Änderungen an einem SLD Server, die notwendig sein köntnen, wenn man ein SLD teilt
720717	Reduzieren der Anzahl von SLDs	Diese Note beschreibt was man in netWeaver PI machen muss, wenn man mehrere SLDs zusammenführt

 

Was ist die LMDB?

Die LMDB ist eine Komponenten vom SAP Solution M;anager, die mit dem Release 7.1 eingeführt wurde. die LMDB ist das Tool zur zentralisierten Verwlatung von Landschaftsdaten im SAP Solution Manager. die LMDB holt sich die informationen aus dem SLD durhc vollautoamtische Synchronisation. Der dadurch erworbene Inhalt enthält sowohl (technische Systeme, Business Systeme, manuell erstelle Produkte, Softwarekomponenten usw.)

Statt also auf dem Solution manager ein eigenes SLD zu haben, löäuft auf diesem die LMDB.

Für die Empfehlungen des Szenarios ohne NetWeaver PI und ohne Web Dynpro Anwendungen ändert isch nichts – hier sollte man weiterhin das oben beschriebene Szenario mit SLD anwenden.

Wenn man jedoch NetWeaver PI bzw. web Dynpro Anwendungen nutzen möchte, sollte man im unteren Szenario etwas ändern. statt einem SLD läuft auf dem Solution Manager die LMDB, welche sich die Daten vom Central SLD holt. Das Central Runtime SLD schickt seine Daten an die LMDB des SolMan durhc vollatuatomsiche Synchronisation.

Ein Hosting Provider hätte hier wieder die Central SLDs von zwei verschiedenen Kundenlandchaften. Anstelle eines Master SLDs kann er sich die daten an das LMDB einex zentralen SolMans schicken lassen.

Dabei muss aber auch hier das unique path principle erfüllt werden. Wenn sich die beiden SLDs untereinander bereits synchronisieren, dann darf nur eines der beiden SLDs mit dem LMDB verbunden sein, weil sonst die Daten der beiden SLDs auf zwei verschiedenen Wegen zum LMBD laufen können.

Der umgekehrte Weg: meherere LMDBs von einem einzigen central SLD speisen zu lassen, ist hingegen zulässig.

 

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!