Gestire più requisiti di pianificazione su un unico sistema

Normalmente, è possibile eseguire questa operazione associando un nodo a più di una definizione di pianificazione. Questo è il metodo di esecuzione standard di più pianificazioni su un sistema.

È necessario assicurarsi che la finestra di pianificazione per ogni pianificazione non si sovrapponga. Un singolo processo del programma di pianificazione client non è in grado di eseguire più azioni pianificate contemporaneamente, quindi se si verifica una sovrapposizione, la seconda pianificazione da avviare non viene eseguita se la prima pianificazione non viene completata prima della fine della finestra di avvio della seconda pianificazione.

Supponiamo che la maggior parte dei file system presenti sul sistema client debba essere sottoposta a backup giornaliero e che un file system contenente dati critici debba essere sottoposto a backup ogni ora. In questo caso, è necessario definire due pianificazioni per gestire questo requisito. Per evitare conflitti tra la pianificazione del backup orario e giornaliero, è necessario variare l' ora di inizio di ogni pianificazione.

Supponiamo che la maggior parte delle unità del sistema del cliente debba essere sottoposta a backup giornaliero e che un'unità contenente dati critici debba essere sottoposta a backup ogni ora. In questo caso, è necessario definire due pianificazioni per gestire questo requisito. Per evitare conflitti tra la pianificazione del backup orario e giornaliero, è necessario variare l' ora di inizio di ogni pianificazione.

In alcuni casi, è necessario eseguire più di un processo del programma di pianificazione su un sistema. Più processi richiedono un file di opzioni separato per ogni processo e devono contenere le seguenti informazioni:

• Definire un nome nodo univoco per ogni processo
• Specificare log di errori e pianificazioni univoci per ciascun processo
• Quando l'esecuzione avviene in modalità richiesta, è necessario utilizzare l'opzione tcpclientport per specificare una porta univoca per ciascun processo.

Nota: quando lo scheduler viene eseguito come servizio, le opzioni di elaborazione specificate nel Registro di sistema di Windows hanno la precedenza sulle stesse opzioni specificate nel file delle opzioni del client.

I vantaggi dell'utilizzo di più processi di pianificazione:

• È possibile eseguire più di un backup pianificato contemporaneamente.
• È possibile specificare diversi criteri di backup per ogni pianificazione avviata, con il file di opzioni client o le opzioni di sovrascrittura del server IBM® Storage Protect .

Gli svantaggi dell'utilizzo di più processi di pianificazione:

• Viene creato uno spazio file univoco per ogni nome nodo sul server IBM Storage Protect .
• Quando si ripristinano i dati, è necessario utilizzare lo stesso nome nodo associato al backup.

Sulle piattaforme UNIX e Linux® è possibile eseguire più processi di schedulazione sia tramite il metodo gestito dal demone di accettazione client, sia tramite il metodo tradizionale di esecuzione dello scheduler. In entrambi i casi, esistono alcuni requisiti di configurazione:

• Ogni processo deve essere eseguito utilizzando un nome nodo diverso.
• È necessario creare più stanze nel file dsm.sys per ogni processo dello scheduler. In ogni stanza, è necessario definire un nome nodo univoco, insieme ai valori univoci per le opzioni errorlogname e schedlogname. È anche possibile scegliere di definire istruzioni domain, includee exclude personalizzate per ciascuna stanza.
• Nel proprio file dsm.sys , impostare l'opzione passwordaccess da generare in ciascuna stanza. La password deve essere generata per ogni nome nodo che sta eseguendo un processo scheduler, eseguendo un comando come dsmc query sess.
• Se l'esecuzione avviene con l'opzione schedmode impostata su prompt, è necessario impostare un valore tcpclientport univoco per ogni stanza.

È necessario iniziare ogni dsmc sched comando o istanza con l'opzione -servername per fare riferimento al nome univoco della stanza corrispondente in dsm.sys. Per dsmcad, è necessario definire la variabile di ambiente DSM_CONFIG per ciascuna istanza di dsmcad per fare riferimento al relativo file di opzioni univoco.

Di seguito è riportato un esempio di configurazione di due processi pianificati gestiti dal demone di accettazione client nel file ` dsm.sys `. Si noti che è necessario utilizzare percorsi completi per i nomi dei file di log per evitare che i file vengano scritti nella directory root):

servername tsm1_sched1
	nodename        aixsvt01_sched1
	tcpserv         firebat
	tcpclientport   1507
	passwordaccess  generate
	domain          /svt1
	schedmode       prompted
	schedlogname    /tsm/dsmsched1.log
	errorlogname    /tsm/dsmerror1.log
	managedservices schedule

servername tsm1_sched2
  nodename        aixsvt01_sched2
  tcpserv         firebat
  tcpclientport   1508
  passwordaccess  generate
  domain          /svt1
  schedmode       prompted
  schedlogname    /tsm/dsmsched2.log
  errorlogname    /tsm/dsmerror2.log
  managedservices schedule

Contenuti di “ /test/dsm.opt1: ”

servername tsm1_sched1

Contenuti di “ /test/dsm.opt2: ”

servername tsm1_sched2

Apri due finestre di comando della shell:

• Nella finestra dei comandi shell 1, immettere:

  export DSM_CONFIG=/test/dsm.opt1
  sudo dsmcad
  

• Nella finestra comandi shell 2, immettere:

  export DSM_CONFIG=/test/dsm.opt2
  sudo dsmcad
  

Nota: è consigliabile inserire questi comandi in uno script di shell se si intende avviare i processi dsmcad direttamente da /etc/inittab, in modo che la variabile DSM_CONFIG possa essere impostata correttamente prima dell'avvio di dsmcad.

È necessario creare un servizio separato per ogni processo di pianificazione. Se si sta utilizzando il CAD (client acceptor daemon) per gestire lo scheduler, sono richiesti un servizio CAD (client acceptor daemon) e un servizio di pianificazione per ogni pianificazione. Di seguito viene riportato un esempio di impostazione di due processi di pianificazione che devono essere gestiti dal CAD (client acceptor daemon):

dsmcutil inst /name:"TSM Client Scheduler1" 
/optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt1"
/node:tsmcli_sched1 /password:secret /autostart:no /startnow:no

dsmcutil inst CAD /name:"TSM Client Acceptor1" 
/optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt1" 
/cadschedname:"TSM Client Scheduler1" /node:tsmcli_sched1 /password:secret
/autostart:yes 

dsmcutil inst /name:"TSM Client Scheduler2" 
/optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt2"
/node:tsmcli_sched2 /password:secret /autostart:no /startnow:no

dsmcutil inst CAD /name:"TSM Client Acceptor2" 
/optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt2" 
/cadschedname:"TSM Client Scheduler2" /node:tsmcli_sched2 /password:secret
/autostart:yes 

Per ogni istanza di pianificazione sono richiesti file di opzioni univoci, che devono essere identificati al momento della creazione del servizio:

File delle opzioni #1 (c:\program files\tivoli\tsm\baclient\dsm.opt1)

tcps             tsmserv1.example.com
nodename         tsmcli_sched1
passwordaccess   generate
schedlogname     "c:\program files\tivoli\tsm\baclient\dsmsched1.log"
errorlogname     "c:\program files\tivoli\tsm\baclient\dsmerror1.log"
schedmode        prompted
tcpclientport    1507
domain           h:
managedservices  schedule

File delle opzioni #2 (c:\program files\tivoli\tsm\baclient\dsm.opt2)

tcps             tsmserv1.example.com
nodename         tsmcli_sched2
passwordaccess   generate
schedlogname     "c:\program files\tivoli\tsm\baclient\dsmsched2.log"
errorlogname     "c:\program files\tivoli\tsm\baclient\dsmerror2.log"
schedmode        prompted
tcpclientport    1508
domain           i:
managedservices  schedule