5 Replies Latest reply on Feb 7, 2008 5:52 PM by Bill Robinson

    Best Practices for Provisioning a Remote Server

      I have two data centers in two states.

      The majority of my BL infrastructure is in one state at the moment.

       

      What would be the best practice for provisioning in the other state?

       

      I'm certain that I'll need a repeater, in order to push BLPackages as part of the post-OS-install-batch job.

       

      But won't I need an app server also, since BMI would have to connect over the WAN otherwise?

       

      Or are the BMI calls lightweight enough that WAN latency won't be a big issue?

       

      And if I do install an app server in the other state, will I need to configure app server profiles so that jobs in the one state don't "land" on the out-of-state app server?

        • 1. Re: Best Practices for Provisioning a Remote Server
          Bill Robinson

          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.

          • 2. Re: Best Practices for Provisioning a Remote Server

            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?

            • 3. Re: Best Practices for Provisioning a Remote Server
              Bill Robinson

              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

              • 4. Re: Best Practices for Provisioning a Remote Server

                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:

                 

                D:\Program Files\BladeLogic\PXE\br>type tftp.conf

                --

                -- TftpServer preferences file

                --

                 

                -- file_path points to directory where files are read from and written to.

                file_path=D:/Program Files/BladeLogic/PXE/tftproot

                 

                -- Set this value to "enabled" to turn logging on, or "disabled" to turn it off

                logging=enabled

                 

                -- 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.

                log_file=D:/Program Files/BladeLogic/PXE/br/tftp.log

                 

                -- 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.

                timeout=60

                 

                -- This value specifies how many times to resend a timed out packet.

                retries=5

                 

                -- 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.

                tftp_write=enabled

                 

                -- Although it's seldom necessary, you may also set whether you want

                -- the server to honor read requests.

                tftp_read=enabled

                 

                -- 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.

                tftp_overwrite=disabled

                 

                -- 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.

                -- 192.168.11.1.timeout=60

                -- 192.168.11.1.tftp_read=disabled

                -- 192.168.25.2.retries=30[/I]

                • 5. Re: Best Practices for Provisioning a Remote Server
                  Bill Robinson

                  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.