Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:services:storage_services:backup:tsm:anleitungen:scheduler_konfiguration [2020/05/11 15:36] – [Linux] bnachtwde:services:storage_services:backup:tsm:anleitungen:scheduler_konfiguration [2021/04/29 14:48] (aktuell) – [Umsetzung -- Systemd] bnachtw
Zeile 1: Zeile 1:
 +====== Konfiguration Scheduler ======
 +===== Standard-Konfiguration  für alle Betriebssysteme =====
 +Für die Nutzung des Scheduler-Diensten ist in der Standard-Konfiguration keine explizite Anpassung notwendig.
 +
 +Falls der Scheduler über den //dsm Client Acceptor Daemon (dsmcad)// gestartet werden soll, muss dies in der ''dsm.sys'' / ''dsm.opt'' durch die folgende Option eingestellt werden:
 +  MANAGEDService SCHEDULE
 +<file></file>
 +<WRAP center round tip 90%>
 +Der //dsmcad// wurde für Windows-Rechner empfohlen, weil er weniger Speicherressourcen benötigt, während das Backup //nicht// läuft. In Anbetracht der aktuellen RAM-Ausstattung von Servern und auch Endgeräten, fällt der Mehrverbrauch durch einen dauerhaft laufenden Scheduler nicht wirklich ins Gewicht. Es ist damit einfacher, direkt den Scheduler als Windows-Dienst zu konfigurieren.
 +Unter Linux hingegen lässt sich der //dsmcad// direkt über //init.d// bzw. den //systemd// starten und während für den Schedulers entsprechene Routinen erstellt werden müssen. Für Linux/BSD wird daher der //dsmcad// empfohlen.
 +</WRAP>
 +
 +Darüber hinaus sollten Sie überlegen, die beiden folgenden Optionen zu nutzen:
 +  * ''SCHEDLOGMAX <MB>''
 +  * ''SCHEDLOGRetention <days>[D,S]''
 +Über **einen** der beiden Parameter wird die maximale Größe des Scheduler-Logs festgelegt, entweder über die Dateigröße in MegaByte (//ERRORLOGMAX <MB>//) oder die Aufbewahrungszeit in Tagen (//SCHEDLOGRentenion <days>[D,S]//), die zusätzlichen bei Angaben bei der Option //ERRORLOGRentenion// legen den Umgang mit älteren Logeinträgen fest: 
 +    * ''D'' -- Löschen der Daten, (Voreinstellung)
 +    * ''S'' -- Sichern der Daten in einer weiteren Datei //dsmschedlog.pru//.
 +  
 +===== Konfiguration bei mehreren Knoten auf einer Maschine =====
 +==== Windows ====
 +Die Konfiguration mehrerer Scheduler ist unter Windows ziemlich einfach:
 +  - Erstellen Sie für jeden Scheduler eine eigene ''dsm.opt''-Datei.
 +  - Weisen Sie bei der Konfiguration des Scheduler-Services die passenden ''dsm.opt''-Datei dem Service zu.
 +
 +Fertig!
 +==== Linux ====
 +
 +
 +Die Steuerung erfolgt über die Optionsdatei, der Start der Scheduler durch den DSMcad:
 +
 +Soll ein Rechner über mehrere Scheduler gesichert werden, so sind für diesen mehrere Knotennamen oder mehrere Server definiert. In beiden Fällen gibt es mehrere //SErvername <NAME>//-Einträge und Serverdefinitionen in der Konfigurtaionsdatei //dsm.sys//.
 +Meist gibt es auch mehrere Optionsdatein //dsm.opt// in unterschiedlichen Ordnern oder mit abweichenden Namen.
 +
 +Die zu nutzenden Optionsdatei kann entweder im Aufruf der CLI (//dsmc -optfile=<NAME>//) oder GUI (//dsmj -optfile=<NAME>//) angegeben werden, alternativ kann die Umgebungsvariable //DSM_CONFIG// mit dem Namen der passenden Optionsdatei besetzt werden.
 +
 +Dieser letztgenannte Weg kann genutzt werden, um mehrere Scheduler über den DSMcad auf einem Knoten laufen zu lassen.
 +=== Umsetzung -- Systemd ===
 +Services werden bei //systemd//-Linuxen über entsprechende //service//-Dateien beschrieben. Im Rahmen der Installation des SP-Clients wird eine ''dsmcad.service''-Datei erzeugt und im Konfigurations-Pfad des Clients (i.d.R. ''/opt/tivoli/tsm/client/ba/bin/'') abgelegt. Der 
 +
 +== Vorbereiten ==
 +Ansatz für mehrere Client-Instanzen besteht nun darin, diese Datei als Vorlage zu nehmen, zu kopieren und anzupassen und anschließend in das systemd-Verzeichnis zu 
 +  * .. kopieren / verschieben:
 +<code>
 +cp /opt/tivoli/tsm/client/ba/bin/dsmcad.service /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1.service
 +</code>
 +  * .. Editieren
 +<code>
 +ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1.service /usr/lib/systemd/system/
 +</code>
 +<WRAP center round important 100%>
 +Nach jeder Änderung an einer Datei im ''/usr/lib/systemd/system''-Verzeichnis muss das Verzeichnis neu eingeladen werden (''systemctl daemon-reload''). 
 +</WRAP>
 +
 +Die Anpassung der //.service//-Datei umfasst dabei:
 +  - Es ist eine Zeile hinzufügen, die auf das jeweilige //opt//-File verweist, z.B. <code>Environment="DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/instance1.opt</code>
 +  - Das Binary für die Option //ExecStart// ist auf die Kopie des //dsmcad// zu ändern, z.B. <code>ExecStart=/usr/bin/dsmcad.instance1</code> 
 + 
 +Außerdem muss das //dsmcad//-Binary kopiert werden, es bietet sich an den Knotennanmen anhängen:
 +<code>cp /opt/tivoli/tsm/client/ba/bin/dsmcad cp /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1</code>
 +<WRAP center round important 100%>
 +  * Da //ExecStart// in das Verzeichnis ''/usr/bin'' zeigt, muss das Binary vom ''dsmcad.instance1'' auch dorthin kopiert / verlinkt werden:\\ ''ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1 /usr/bin/''
 +  * Das Startskript funktioiniert offensichtlich nicht, wenn bei ''ExecStart'' direkt auf das Binary im Pfad \\ ''/opt/tivoli/tsm/client/ba/bin/'' verwiesen wird -- warum es dann aber ein Symlink tut? 8-o
 +</WRAP>
 +== Ausführen ==
 +  - Der Start erfolgt "ganz normal" über das //systemctl//-Kommando, z.B. <code> systemctl start dsmcad.instance1</code>
 +  - Ebenso die Etablierung als Dienst beim Systemstart, z.B.:<code> systemctl enable dsmcad.instance1</code>
 +=== Umsetzung -- Init-V--Ansatz ===
 +  * Der Start des //dsmcad// erfolgt über das Skript //rc.dsmcad//, dieses liegt in der Regel unter ///etc/init.d/dsmcad// als symbolischer Link zu ///opt/tivoli/tsm/client/ba/bin/rc.dsmcad//). Für mehrere Knoten auf einem Host, muss dieses kopieren und umbenannt werden, z.B. <code>cd /etc/init.d/ && cp rc.dsmcad rc.dsmcad.knoten_1</code>
 +  * Um die verschiedenen Prozesse unterscheiden zu können (z.B auch für das ''service <Name> [start|stop]''), sollte auch das benutzte Binary (//dsmcad//) kopiert werden, z.B. <code>cp /opt/tivoli/tsm/client/ba/bin/dsmcad /opt/tivoli/tsm/client/ba/bin/dsmcad.knoten_1</code>Es kann dann eindeutig identifiziert werden.
 +  * Im kopierten Skript (//rc.dsmcad.knoten_1//)<WRAP center round important 90%>
 +Achtung: Die Datei ist  per default auch für ''root'' nur lesbar!
 +</WRAP>
 +    *  eine Zeile ergänzen, die die Variable //DSM_CONFIG// auf die passenden Optionsdatei verweisen lässt, z.B.:<code>export DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/dsm-node1.opt</code>
 +    * Den Namen des Binaries im Skript (Zeile //DSMCAD_BIN=...//) anpassen, z.B.<code>DSMCAD_BIN=$DSMCAD_DIR/dsmcad.node1</code>
 +  * Das geänderte Skript kann nun wie das Original-Skript mittels der Parameter //start//, //stop// //restart// und //status// benutzt werden.
 +<WRAP center round tip 90%>
 +Liegt das neue Skript im Verzeichnis //etc/init.d// (bzw. liegt dort ein symbolischer Link zum geänderten Skript) kann auch der geänderte DSMcad über die üblichen Wege als Dienst gestartet werden.
 +
 +z.B.
 +  * SuSE: <code>chkconfig dsmcad-Server_1 on</code> \\ bzw. zum Start in Runlevel 3 und 5:\\ <code>chkconfig dsmcad-Server_1 35 </code>
 +  * generisch:
 +  * <code>
 +cd /etc/init.d/
 +for i in $(ls rc.dsmcad*); 
 +do 
 +  ln -s /etc/init.d/$i /etc/init.d/rc3.d/K01$i
 +  ln -s /etc/init.d/$i /etc/init.d/rc3.d/S15$i
 +done
 +</code>
 +</WRAP>
 +==== OSX ====
 +sollte wie bei Linux funktionieren (nicht getestet).