Today’s post brought to you by the logical fallacies “Begging the Question” and “False Dilemma”
Generally speaking we don't respond to competitive commentary that's purposefully antagonistic. The reasons for that vary from corporate culture to the annoying reality that responding confers upon the claims some measure of veracity that it generally does not deserve.
But even technical agitprop can raise points that need to be addressed with respect to the underlying premises upon which the arguments are made. Of late, certain claims coming from Citrix has brought these premises to the fore, and those premises deserve to be addressed.
Issue: SQL Load Balancing
Of the three application tiers, the data layer remains the most problematic. Whenever data is separated – for failover or availability – across locations, problems arise. When it comes to capacity and load, which directly impact performance, many turn to load balancing as a natural solution. After all, it worked for the presentation and application tiers, why not data, too?
Database load balancing is not nearly as cut and dried, however. Because of the peculiarities and sensitivity of application logic to the location of data, most scalable load balancing solutions involve one of several architectural approaches that boil down to the use of some form of sharding, either at the application logic or the application delivery tier.
This is the approach used by Facebook and undoubtedly many large-scale application providers. Facebook calls it “page routing”, but in the application delivery realm we call it “application” or “content” switching. The application delivery controller examines requests and based on the SQL transaction type (select, drop, insert, update, etc…) it makes a routing decision. “Read” transactions go here, “write” transactions go there. It’s the simplest form of sharding; organizations like e-Bay use of far more complex sharding techniques, segregating not only by type but by user across a bank of databases rather than merely one or two.
Citrix says, “F5, for example, cannot intelligently manage or load balance database traffic since its BIG-IP devices lack the requisite ability to understand SQL-based traffic flows and make routing decisions based on SQL-specific commands and syntax.”
Where to start with this one... First we see a classic False Dilemma fallacy, in which only two options are presented. Such logical fallacies ignore there may be three, four, or more options. SQL fluency is one option, which is the route Citrix has taken. Understanding SQL – which is just another application in the big scheme of things – can also be accomplished by a solution if (1) there is a means to examine the data payload in which the SQL is embedded and (2) there is a means to extract and act upon that data. This can be – and is – accomplished by F5’s application fluency and network-side scripting capabilities of iRules. F5 BIG-IP load balances databases and it does so every day for customers across a variety of vertical industries. Contrary to statements made by Citrix, customers find that the techniques F5 uses are sufficient for their needs. If you’re interested in what that entails, you can find both an iRule and an iApp on DevCentral, along with plenty of community-based and F5 support for customization.
Citrix, after expounding on its native SQL capabilities, says, “The absence of essential SQL-based intelligence has not stopped F5, however, from marketing a database load balancing solution that uses rudimentary TCP-level load balancing algorithms and health checks.”
One of these “essential” functions Citrix claims F5 solutions cannot perform is: “Monitor the health of database servers with SQL-specific health checks.”
This is not even a logical fallacy, it’s outright false. For example, from page 3 of the “Deploying the BIG-IP LTM for Oracle Database and RAC” deployment guide:
You will note in step 8 the configuration of an SQL-specific health check string used to verify the health of an Oracle RAC database node. If you peruse the code behind the aforementioned MySQL proxy iApp, you’ll note the use of SQL specific commands like “SHOW MASTER STATUS” and “SHOW SLAVE STATUS” as part of the health monitoring configuration.
But Lori, MSSQL is not supported anywhere! Yes, I know. We’re working on that one, based largely on our existing support for Oracle and MySQL.
The second logical fallacy in less than two paragraphs concerns the “essential” nature of SQL-based intelligence. It Begs the Question (one should prove it is essential before claiming it is essential). Given that F5 can, and does, load balance SQL traffic for customers without supporting all the capabilities spelled out by Citrix, their “essential” nature is apparently not so essential after all. In fact, there are some issues that arise from some of these capabilities that make them less than desirable in many situations.
SQL CONNECTION MULTIPLEXING
For example, Citrix touts a feature known as SQL Connection Multiplexing (which is very similar to what both Citrix and F5 provide in terms of TCP multiplexing). Potential issues with this approach include the reality that SQL processing on the ADC may actually be more expensive in terms of processing power (unlike SSL and compression, there’s no hardware-assist for SQL on application delivery controllers). The more significant issue relates to security in the form of credentials. One of the worst practices employed by developers with respect to data and application security is to use the same credentials for every database connection. This eliminates the ability of the database to not only enforce user-based access to data but also row and/or column based security by role or user. An application delivery controller configured to perform SQL connection multiplexing must either use this single credential technique or must maintain duplicate credentials on the device (doubling management and potential to create orphan accounts that might later be compromised) to ensure the database can apply its own security policies.
Citrix points out that “NetScaler can apply granular user access policies to each database user. It also provides a consolidated log of all SQL transactions and user accesses for complete visibility, without taxing the database server. SQL protocol validation is also available with advanced Policy Infrastructure (PI) regular expressions.” While DataStream can understand SQL transactions and security policies can be written, no policies are included or offered by Citrix to aid in implementing this “essential” security feature.
Both Netscaler and F5 (as I’ve just established above) support SQL-based content/application switching. When properly designed into an application, this capability is extremely useful for a number of business and operational requirements with respect primarily to performance. Though we certainly support this type of architecture, we also recognize that it is a more complex design than traditional single-database systems, which introduces difficulties in troubleshooting (reads and writes of a single user are spread across multiple connections and locations and must be merged before diagnostic procedures can begin).
To sum up today’s post, F5 does in fact load balance databases and does in fact have more than “rudimentary TCP-level” health checks, and is in fact capable of participating in a collaborative SQL load balancing architecture. Claims to the contrary are (more than) greatly exaggerated.
Latest F5 Information