1 of 1 people found this helpful
You are constrained by the performance of the appserver. If you are managing 1000 agents w/ your 1 appserver and everything is performing acceptablly, there's really no need to change. if you need things to run faster, or need some level of redundency, then you should add more appservers.
generally you need to work out how fast the longest, most intensive job needs to run and scale to that.
Thanks, I already started looking into performance.
I tried executing a batch job from a BL AppServer in the R&D datacenter, to a target server in the production datacenter. It takes x6 the time - instead of 8 minutes in the same datacenter, a little more than an hour over the communication line.
I'll start playing with adding an AppServer and repeaters in the production datacenter to get a clue of the needed scale.
Can you give me some numbers? If BMC has experience with globally distributed customers, I'd love to learn from their BL infrastructure.
When you say add an appserver in the other datacenters do you mean a new bladelogic install? because having the database and appserver separated by a wan will perform worse then you current situation.
What did the batch job do?
Splendid, I missed this important aspect.
No splitting the AppServer (or AppServers) and the database over WAN - checked.
That means I want to have only Repeater Server (or Repeaters) in the production datacenter.
However, I will probably need to provide computers with Blade Logic consoles for users in the production datacenter. These users mainly execute jobs, the Depot items are created by the R&D in the same datacenter as the AppServer.
Consequently, I'll have a computer with Blade Logic Console, communicating with AppServer and database over the WAN 40MBps line.
I'll try increasing the specs of the AppServer and database, as well as the computer running the console, until the communication line limit is reached.
If I get to this limit and the performance is not good enough, I'll consider using two separate Blade Logic infrastructures - and import/export to pass the content between them.
Sounds right? Am I missing something?
The batch job I tested deploys a Silverlight web application on a target server.
Namely, drop a BLPackage with the files (~50MB), change values in web.config configuration files, and run an NSH script to modify parameters in a zip file.
(the NSH script is here https://communities.bmc.com/communities/message/180968 )
If the issue is the distance between the Appserver and the BL console for users.
Another alternative might be to install the console locally at the Appserver location on a server/PC/VDI and us RDP/Citrix (or some other remote connect solution) to connect to the console server/PC/VDI from the remote site.
Also any real test of a deployment to your Production site should be based on the 2nd or 3rd tries, as the first deployment will always be much longer (the first deployment caches the package on the repeater).
Last I heard there is no way to have BladeLogic populate a repeater except by actually deploying the package.
It might be a nice feature if there was some way to be able to stage a package/s to a repeater, thereby removing the delays in inital deployment (caching) of a package.
Good idea about connecting remotely to R&D AppServer, I'll look into doing that instead.
I think I'll create a dummy server and run the job against it to cache the packages on the repeater.
If this proves to be a problem - I'll open an RFE to add this feature.
if you use the 'agent mount at staging' you could have remote file shares that serve up the package contents and perform some kind of background sync w/ a fdj.
but i think it's a good RFE to have some kind of sync of the file server, and then have the deploy payload come from the local mirror of the file server.
I think we can live with a "dummy execution" to store the payload on the repeater server.
(keeping the KISS principal)
I have a conference call with Paul Beaver tomorrow, I'll push the idea to open RFE for this feature.
Thanks for the great assistance!