the bmi calls should be light weight, better then trying to have the appserver connect back to the db over a WAN. make sure 9831 is open from the target network to the appserver.
another customer did this, and they had to setup local appservers at each site, but the latency over the wan back to the db was pretty bad, and the appservers weren't performing that well.
put the pxe/dhcp/tftp servers at each site, the datastore at each site, setup the property instances for each site. i'm not sure if you have to have some local config (like in the tftp.conf file) for the pxe/tftp servers so they will bind to the right addresses (in the PM config you can only set 1 address for tftp to bind to).
that should be it i think.
Thanks for the quick reply.
I have a few more questions.
1: As I understand it, the server property itself determines which repeater it uses, correct? Because of this, it would be wise to have seperate system packages which are associated with the repeater. For instance I could have one set of system packages for my local state, and another set of system packages for the other state.
2: When my bare metal servers are being provisioned, they are on a "private build network." This complicates things quite a bit. For instance, the provisioning server is dual homed. The primary interface can talk to the database. The secondary interface, which is used for provisioning, cannot.
In my local data center I have an app server on the box that provisions, so I don't need to route port 9831. In the remote data center, I'll have to route port 9831 traffic from the "build network" to the app servers in the local data center. It's true this is confusing, but I'm certain most customers also provision their servers on a private network. Would you agree that routing port 9831 will be required to reach the app server?
1 - the repeater is only going to get the post-install packages, not the system package payloads. you need to have a cifs share or http server (windows/linux) at each site. this can be located on the repeater box, but it's not going to be a function of the repeater.
2 - the provisioning target needs to talk to 9831 on the appserver - that's it. i don't know about routing, might just be firewall rules. ideally you just have a separate vlan for provisioning, not all this dual-homed stuff. there is really no need to dual home anything w/ the right vlan/firewall setup. just make sure from a server that is on the provisioning wire, that it can telnet to :9831
put the pxe/dhcp/tftp servers at each site, the
datastore at each site, setup the property instances
for each site. i'm not sure if you have to have some
local config (like in the tftp.conf file) for the
pxe/tftp servers so they will bind to the right
addresses (in the PM config you can only set 1
address for tftp to bind to).
That's true, you can't set up two seperate TFTP servers in the GUI.
It appears to be possible to override the PXE settings in pxe.conf.
But how do you get around the TFTP issue?
Here's the contents of tftp.conf:
-- TftpServer preferences file
-- file_path points to directory where files are read from and written to.
-- Set this value to "enabled" to turn logging on, or "disabled" to turn it off
-- log_file is the path to the file where logging information is written to
-- In the example case, since no directory is specified, the log file is
-- written to the working directory, which is the directory where
-- TftpServer.exe lives.
-- Set this value to the timeout (in seconds) between packet exchanges. 5
-- seconds is sufficient for most networks, but if you are going over a
-- slow link, you might want to bump this up some.
-- This value specifies how many times to resend a timed out packet.
-- By default, the tftp server will operate in read only mode. That is,
-- read requests will be honored but write requests will be rejected.
-- This is a security feature to prevent people from writing spurious
-- files to your system.
-- Set this value to "enabled" to allow write requests to this tftp server.
-- Although it's seldom necessary, you may also set whether you want
-- the server to honor read requests.
-- By default, the tftp server doesn't allow you to overwrite files
-- that already exist in your tftp server directory. Set this option
-- to enabled to allow overwrites.
-- You may further set timeout, retries, and read/write permissions
-- on a per client basis. In the examples below, any requests coming
-- from 192.168.11.1 will get a larger timeout period, more retries,
-- and will only allow write requests, while 192.168.25.2 will
-- allow 30 retries before giving up.
can you use a regular tftp server? i mean, its just tftp... i think it just has have to have all the bl files in its root i think.