Draft Document for Review November 15, 2007 3:27 pm | 4372ch06.fm |
the different warehouse and store locations that the master sychronizes with to allow for distribution of images across the enterprise.
6.1.2 Expanding from one to multiple servers
The general architecture for Tivoli Provisioning Manager for OS Deployment is a
In the first approach, a central multiuser database like DB2® is created on a server that the master and slave Tivoli Provisioning Manager for OS Deployment servers have access to. Once the database server is setup then an ODBC/JDBC connection is configured prior to installation of the Tivoli Provisioning Manager for OS Deployment product is installed, using the same name that would normally be created during installation. Once the ODBC/JDBC connection is created on each server that will be either a master or a slave then install the server product. Once the product is installed go into the server → server parameters → server synchronization panel to assign the roles of master and slave to each Tivoli Provisioning Manager for OS Deployment server.
In the second approach, each Tivoli Provisioning Manager for OS Deployment server is installed as a standalone server with an independent database. In order for the slaves to synchronize their data with the master the netclnt command must be scheduled on each slave which establishes a connection to the master’s database. In this scenario, the relationship between master and slave are not visualized in the GUI as in the first approach.
In both scenarios, a Tivoli Provisioning Manager for OS Deployment server can be both a master and a slave depending on how they are configured.
6.2 Replicating software and configurations
There are three methods you can use to replicate images between Tivoli
Provisioning Manager for OS Deployment servers:
Automated, using
Manual, using the command line tool
Chapter 6. Real world deployment scenarios | 127 |
