BMC BPPM Architecture v9.5: Savings and Simplification
Paraphrasing Buckminster Fuller (and Wikipedia), each ephemeralizing release of BPPM brings you closer and closer to doing everything with nothing.
Previously, we posted about the increased capacity of the BMC Proactive Net Performance Management (BPPM) 9.5 release: the hardware requirements for this release are actually lower than before, and the capacity is greater than ever. With this increased capacity you can do more with fewer servers, saving you money.
This post goes a little further to illustrate this in more depth. We’ll compare the 8.6 and 9.5 benchmarks using a hypothetical enterprise so that you can see what hardware was previously required compared to now. Spoilers: the difference is huge. Think caveman standing next to a T-Rex huge. You’ll see the same size difference in your old 8.6 infrastructure compared to 9.5. The only question is what you’re going to do with the extra capital savings and decreased data center rack space…
While you contemplate that, let’s talk about our hypothetical monitoring infrastructure. Instead of showing all the hardware components associated with a hybrid infrastructure, we will focus just on the system architecture that would have been required with 8.6 to handle the measurement data, and compare that, apples-to-apples, with the equivalent system architecture with 9.5.
Our hypothetical enterprise will consist of 15,000 devices, each with 100 tracked metrics, for a total of 1.5 million parameters (also known as attributes). The monitoring will be spread across three data centers, with 5,000 virtual and physical devices and for a total of 50,000 parameters in each data center feeding up into the BPPM management server structure for the analytics processing. This should really drive the point home about how much capacity now sits within this BPPM suite compared to just a few short years ago.
Out With The Old: BPPM 8.6
Let’s take a look at 8.6 and design an infrastructure based on our hypothetical enterprise. First, we’ll address the number of devices. The capacity limits for a single 8.6 BPPM server were 10,000 devices per server, so to cover the extra 5,000 devices, you would have needed a minimum of two separate BPPM servers. However, once you cross over one BPPM server, you actually had to go directly to three because the architecture calls for an “Enterprise” BPPM server to serve as the presentation layer. So, just to drive it home, two BPPM servers wasn’t an option – you needed at least three.
Next, we need to address the number of tracked metrics. This example uses a total parameter count of 1.5 million, which is an easy number to exceed for a large infrastructure, so you can use it as a good yardstick for your business. The limit for a single BPPM server in 8.6 is only 500,000 parameters, so to accommodate 1.5 million parameters you would need at least three BPPM servers to cover the data collection, plus one Enterprise BPPM Server. Now we’re up to at least four BPPM servers, and an Oracle database server.
Now let’s go down one more layer into a set of systems which the previous sizing webinar and post didn’t get into: the Integration Servers. The function of an Integration Server is to pass information in the form of data and/or events into the BPPM Server and its analytic processing engine. These Integration Servers are the central point for collecting the remote data and event information. A single 8.6 Integration Server could only support a maximum of 125,000 parameters.
So to cover an enterprise the size of this one with 8.6 with a little breathing room, you would need five integration servers per data center.
So, we’re sitting at 20 servers so far to analyze the data from this infrastructure: 15 Integration Servers, four BPPM Servers, and the optional Oracle database (which would be recommended for an enterprise of this size). Without factoring in virtualization, we’re talking about half a rack just dedicated to BPPM infrastructure.
In With The New: BPPM 9.5
Now lets look at the 9.5 capacity and scalability numbers, and compare the hardware footprints.
One BPPM 9.5 server can now handle 1.7 million parameters, a 300% increase over the limits of 500,000 associated with 8.6. It can cover 20,000 devices, a 100% increase over the 10,000 device limit of 8.6. That added capacity brings the BPPM server count down to a single server from the four required under 8.6 – but let’s not forget our old friend, the optional Oracle server. This is a dramatic difference, and if you wanted to eliminate the Oracle database in either 8.5 or 9.5, you could use the BMC embedded Sybase database.
The 9.5 upgrade now increases the Integration Server limitation from 125,000 parameters to 1.7 million, an over 1300% increase per Integration Server. With more and more virtual infrastructures, one agent can now collect thousands of data points from a large number of remote systems and feed them up to the Integration Server. With virtualization becoming more and more the norm within today’s infrastructures, monitoring more systems with fewer agents, the monitoring bottleneck becomes the parameter limit. This is why the 1.7 million parameter benchmark is now the key focal point most of the time, rather than the number of agents. The bottom line here is that more capacity per Integration Service means fewer Integration Server systems.
All other factors being in line, you could use one Integration Server and still have the room for 200,000 additional parameters before a single 9.5 integration server would be maxed out. Now to be clear here, there are many many factors involved with how many actual BPPM and integration servers any enterprise would need; this is just an example to illustrate the radical capacity differences between BPPM 8.6 and BPPM 9.5.
Just to sum it up so far: we’ve taken 20 servers running 8.6, down to three on 9.5, or from half a rack of data center space down to 3U. An incredible reduction in hardware, while achieving the same amount of coverage. We’re sure you’ll think of something to do with the 17 servers you just eliminated, and the capital savings. The savings don’t stop here.
[contentblock id=2 img=html.png]
One quick mention of another 9.5 enhancement at the integration server level: 9.5 integration servers now handle both data and events in one stream, over one port. In the 8.6 release, there was a need to have separate software components on these integration systems to handle the event streams. Data and events traveled over two separate paths in 8.6. As a result, you had the need for this extra software component on every integration server. Using this example enterprise, that would have been 15 additional software installs, and extra administrative overhead to support each install. That extra software component is now gone, and with it, the administrative overhead tied to its port usage, firewall rules, software installation, and point of failure.
Additionally, the integration servers have some other very nice enhancements which will be covered in more depth in later webinars and posts. Keep an eye out for those.
The Bottom Line: Saving Time and Money
A final advantage brought by this reduction in hardware and software is the huge decrease in the administrative overhead. After all, these systems aren’t self-aware and auto-correcting (yet). They require people to administer and support them. Your support staff will gain more time as they spend less of it administering to 20+ servers, and will appreciate the new, streamlined system.
With every piece of hardware and software removed, you decrease administrative complexity. By doing that, you start introducing operational efficiencies: your support staff will gain time thanks to the smaller, more streamlined architecture. The amount of time needed to maintain and support 20 servers, compared to the amount of time needed to support 5, is night and day. Your company saves a large amount of money not having to purchase servers, which are no longer necessary to support the Enterprise Systems Management. This helps the budget go farther by doing more with less, and the Enterprise management team saves administering and supporting a smaller footprint. Keeping it simple keeps everyone happy and budgets in the black. There are no downsides to the new 9.5 system, which leads to savings all around with BPPM 9.5 capacity increases.
If you have any questions about functional designs, we can help you with that. Contact us and we’ll talk to you and workshop to figure out the needs of your enterprise. We’re also happy to help answer any questions or clarify anything that wasn’t clear to you after reading this post.