It is still recommended that you use physical servers for BL infrastructure whenever possible. That being said, we do have customer's that are on completely virtualized environments. One of the main issues is the fact that a large portion of the IT community do not do consult a capacity planning or P2V expert and do not completely understand everything that goes into that decision. So, in short, we get servers that are under performing or ESX hosts that over allocated. ESPECIALLY when you virtualize databases. We have a document that makes a few general recommendations as it concerns BL and VMWare, but the main items things are the best practices from an expert trained in that virtualization technology. I would submit a ticket and request the latest version of this document to help aid you in your setup.
our environment is totally virtualized (multiple appserves + db server)
BL itself works on vmware without problems, but keep in mind that appservers eat a lot of cpu so you'll want to be really sure that your virtualization infrastructure is not overcommitted, or else be prepared for a lot of slowdowns...
1 of 1 people found this helpful
I agree completely with the BMC folks on this one. While we have a corporate direction to virtualize as much as possible (and a large portion of our target server population is virtual), I'd fight tooth and nail to avoid virtualizing my BL implementation.
It really boils down to the workload in your environment. We have about 2600 target servers, and to handle that (currently running BL 8.0 SP5 Patch 1), we have one appserver dedicated as a configuration server/NSH proxy, 3 job-only appservers and a dedicated fileserver host. All of these machines are logical domains (slices of dedicated hardware) on a Sun T5220 running Solaris 10 which has 64 CPU and 64 GB RAM. The database is on a large AIX LPAR with 4 Power6 CPU (I think) and 32 GB RAM.
We run around 4000+ jobs per week, with the target mix ranging from singles up to the full set of managed servers. There are times when we are CPU bound on the individual job appservers, there are times when we are CPU bound on the fileserver (during heavy deployments), there are times when we have jobs waiting for availability of job threads on the job appservers, and there are times when the job appservers have memory issues (only a single JVM running on each machine).
It can be quite difficult to track down a performance issue, even in our environment which is nearly all dedicated physical equipment.
So, the bottom line questions really are "what is your tolerance for tracking down issues?" and "what's your workload and target mix like?". We use most of the features of BL 8.0 except patching, so it's a diverse set of problems in my environment, with about 30-40 regular, every day users, and another 100 occasional users.
Scott – you should look at upgrading to sp7. There were a bunch of performance fixes in sp6 (and a couple more in sp7) that might speed up the gui for you if you are having issues.
And it sounds like you need more appservers ☺
Actually, we're waiting for SP8, since we can't upgrade more often than every 3-4 months, and we last upgraded in October (SP6 actually was released between our upgrade to SP5 Patch1 of DEV and PROD). So, that will give us fixes for about a half-dozen tickets spread across SP6, SP7 and SP8, not to mention the continuing basic performance improvements.
As for the appservers, most times of the day, we don't need more, it's just during peak hours we are occasionally crunched.
Our bigger issue is that our BL infrastructure is entirely in a single datacenter, so we'll get the additional appservers by building out some HA capabilities as well, maybe later this year.