BIG-IP

IBM Rational AppScan

Nojan Moshiri — Wed, 28 Dec 2011 21:55:00 GMT

In my last post, I introduced my role as Solution Engineer for our IBM partnership and how many exciting solutions we have coming out in our partnership. Today I’m going to briefly cover one of our latest releases, the IBM Rational AppScan parser.

AppScan

IBM’s Rational AppScan implements the latest scanning technology to test your web applications for vulnerabilities. I’ve run this scanner many times and the complexity and depth of its scans is mind boggling. There are something like 30,000 tests that it can run in comprehensive mode, looking for all types of attacks against a website. When launching a new application or reviewing your security on an existing site, an investment like Rational AppScan may save your entire organization enormous amounts of pain and expense.

So how does AppScan work? You simply point it at your website and go. During a recent test, I tested a sample ecommerce site (designed to have flaws) and found over 129 problems, 37 of them critical exploits such as SQL injection and cross-site scripting. The beautiful thing with AppScan is that you simply see exactly where the exploit took place, how to repeat it and how to mitigate it. It’s an amazing tool and you should definitely check out the trial.

Once you have your scan, the next step is to fix the issues. In the example above, the 37 vulnerabilities might take days or weeks to solve. And that doesn’t even address the four dozen other medium and low priority issues. So how do you help speed this along? This is where BIG-IP ASM enters the picture. As of version 11.1, our IBM AppScan integration allows you to export your reports from AppScan, import them into ASM and immediately remediate the critical problems. In my test, I was able to remediate 21 out of the 37 critical vulnerabilities, leaving just a small handful to be worked on by the developers.

Distributing SAP Load using BIG-IP Advanced Monitoring

Nojan Moshiri — Thu, 10 Mar 2011 01:49:33 GMT

Several recent forum posts on DevCentral forums have commented on the fact that SAP Landscapes often have asynchronous batch jobs that cause higher CPU loads on certain servers. This causes problems for application delivery controllers because load balancing methods are typically based on connection counts. Picture the scenario where one connection causes a big CPU or memory spike and then goes away. Now you have the same number of new connections coming into the server while one is slammed.

The solution to this problem is relatively straightforward and I recently documented this for everyone in our “Deploying F5 Networks with SAP NetWeaver” deployment guide, located here: SAP NetWeaver and Enterprise SOA: Enterprise Portal (BIG-IP v10.1, WOM, Edge, WA). The solution is based around using SNMP in conjunction with application based monitors. The BIG-IP SNMP monitor provides the ability to perform dynamic load balancing based on CPU, memory or disk utilization while the advanced monitors test the J2EE stack, the authentication system and the database. With this combination, SAP administrators should be able to sleep better at night knowing that their customers and users are getting to a live system that best prepared to service the request.

So, how does layer monitoring work? If you are not aware, it’s possible to have two monitors for a particular pool or node. In the UI, it looks like this:

In this example there are two monitors, SAP-CPU and ICMP. In the real world, ICMP would be replaced with the advanced application monitor. So, what does the SNMP monitor configuration look like:

Here we have an SNMP setup that is set at a CPU Threshold of 80%, a memory Threshold of 0% and a Disk Threshold of 10%. Obviously this is from my testing to insure the monitor is working properly. What this defines is that if the disk is more than 10% full, or the memory is being utilized at 0% or the CPU is being utilized at over 80%, then de-weight the amount of new connections that get sent to this node(server). The coefficients allow further granular control over the traffic weighting determination. This is not a config you would probably run in production, but it’s great for testing!

By logging into the BIG-IP advanced shell and enabling logging, I can see exactly what weight is being assigned. This is accomplished through the command:

bigpipe db Snmp.SNMPDCA.Log true and then by tailing the snmpdca.log located in /var/tmp :

tail -f /var/tmp/snmpdca.log

There you have it. Now all we have to do is change the load balancing mechanism for the pool to be based on dynamic, apply the advanced application monitor, and we have a fully dynamic decision making system. You can play with the Thresholds and Coefficients until you have a desired mix. The SNMP monitor will not mark a host down, but it will set the weight (between 1 and 100) in a manner that very few connections will get to a node that has exceeded all tresholds.

A quick note on the advanced health monitor. I can’t stress how important it is to have layered monitoring in this and other dynamic load balancing scenarios. Especially in an SAP NetWeaver J2EE stack installation (or even a dual stack implementation) many things can go wrong. Just because the CPU, memory and disk are normal, doesn’t mean that your J2EE stack hasn’t crashed, or that your authentication system has gone down. By layering monitors, you cover all BASIS. :-)

I hope this post has been helpful, and as always, please email me if you have any questions. Remember that detailed installation instructions including step-by-step configuration is in the deployment guide linked at the top, or through f5.com ---> Resources -- > Deployment Guides ---> SAP NetWeaver and Enterprise SOA: Enterprise Portal (BIG-IP v10.1, WOM, Edge, WA)

To all my SysAdmin friends I say - Run your databases through BIG-IP and sleep better at night

Nojan Moshiri — Fri, 30 Jul 2010 20:36:17 GMT

When I was an “Internet Architect” (lofty title alert!) I used to hear this question fairly often in design meetings, whether to run the database (DB) through the load balancer or not. I would almost always come down on the side of “no there’s no point” because the DBs have their own high availability solutions, they don’t benefit from load balancing and there are usually no multi-master solutions. Also, load balancers are expensive and resources are finite on them.

Over the last few years a number of factors have changed, and today the answer is a solid maybe. There are a lot of compelling features and the crafty engineers that see the light may be able to solve some sticky architectural problems and even sleep better at night.

Change in viewpoint

Enter 2010, things have changed a lot and so has my viewpoint. More often now I’m finding that there are reasonable cases to be made for running the DB through the Application Delivery Controller (ADC). Resources are not as finite anymore, especially on BIG-IPs, and the added benefits include monitoring, flexibility, scaling and control. As an architect I always want more options and as a sydadmin I was stable solutions that let me sleep at night. The ADC has come of age and the benefits outweigh the main negative which is one more potential point of failure for a critical infrastructure component.

The changes that have made me change my mind is first, the resource issue on the ADC. Even from our BIG-IP 1600 series, our so-called “entry-level” point, our 10.2 release allows for passing of 1 Gigabit per second. On the SSL side, we’re talking about 5000 transactions per second of encrypted traffic. Many of the ADCs I’ve used in production spend a large amount of their time mostly idle, just serving front-end traffic and could easily handle the additional load of database connections. I’ve seen these boxes pushed to the limits and it doesn’t worry me nearly as much as it did even five years ago to run database connections through them for fear of overload.

But question still exists why bother?

Once we rule out the “hardware can’t handle it” argument, the second benefit is the ability to monitor the databases, built into our ADC. As Ryan Corder demonstrates in his entry Monitoring Open Source databases with BIG-IP, monitoring Postgres and MySQL is a snap with BIG-IP. This only makes me sleep better at night. I can setup replication to another local instance and create my own high-availability hot/standby cluster without all the overhead of a software clustered solution. Or, I can have the ability to instantly recognize outages and using iRules make intelligent traffic flow changes on the fly, without having to include my monitoring system. We all know how it works today, the monitoring system finds a problem, sends out a page to a system administrator (happy sys-admin day by the way guys and gals!) and meanwhile traffic is down until the problem can be resolved. How about this: the ADC finds the problem beginning with the very first request that has an issue and makes a decision to route traffic around the problem, and the sysadmin doesn’t have to run a fire-drill at that instant.

I’m already a long way towards sold on this now. But finally there’s the idea hinted at above, the flexibility of having the ADC in the way. This is the flexibility of making routing decisions based on layer-7 content. This is the flexibility of putting the databases where you need them and relying on the ADC to optimize TCP, or perhaps even to accelerate connections using BIG-IP WAN optimization. This is the flexibility of opening long-distance VMotion and having your database follow, all made possible by having an ADC in the architecture.

So, should I run my database through BIG-IP?

So, should you? It depends of course, if you’re a mom-and-pop shop with one site and no growth, probably not! But if you’re larger:

* Could you benefit from having more fine-grained control over the uptime and availability of your DB?

* Are you running MySQL or PostgreSQL? If you’re running Oracle, Sybase or MS-SQL, what kind of applications connect to your DBs?

* Is there a better connection manager solution available?

* Would the ADC conflict with your other high availability solution?

* Do you have a fairly complex architecture that could require multiple sites?

* Do you have an architecture that can change rapidly based on business needs?

Hopefully this will be another arrow in the quiver of the lofty Internet Architects ( :-) ) out there enabling them to successfully nail down another great infrastructure design.

Until later, I give all of the System Administrators out there the rest of the day off! May your pager be quiet and your systems remain up!