Blog Detail


High Profit, Low TCO: How to Guarantee Customer Application Performance
Don Wake|Wednesday, February 04, 2015
Technical Marketing Manager

In Part 1 of this series we defined "What is QLogic Switch Independent NIC Partitioning", and why it is important to IT administrators and their customers. We discussed the physical functions and contrasted those to SR-IOV based Virtual Functions. We described how QLogic NPAR allows the user to partition a 10GbE port into multiple Physical Functions. In this blog we construct a multiple application example that illustrates how each Physical Function could be mapped to a given application or VM, and how this partitioning can provide a dynamic bandwidth guarantee and ensure that your customers Service Level Agreements are always met.

Service Level Agreement Assurance
How do we ensure that the most important applications ALWAYS get their Service Level Agreement (SLA) required access to that 10GbE pipe? The customer doesn't ask for bandwidth, they want their Email to come through without delay. Customers want more file downloads from the cloud as fast as possible. Customers know time is money. The IT administrator translates this request into a percentage of bandwidth needed to ensure "Customer 1 has fast Email". In our example this is what we mean by meeting an SLA. We put SLA requirements into terms relative to the network. In this example, fast Email means that "Customer 1" needs 60% of the 10GbE pipe when 10,000 users are logged in.

IT administrators need a way to configure the network so that customer applications not only get the access to the network they paid for, but also that the hardware they have in the datacenter isn't radically over provisioned. When it is slow then yield bandwidth. When network traffic is high, ensure SLAs are met. To solve this problem, QLogic NPAR was created and at the heart of the design are two user configurable bandwidth settings: Maximum Bandwidth and Relative Bandwidth Weight.

Dynamic Parameters – Maximum Bandwidth and Relative Bandwidth Weight
To illustrate how these settings work we will build an example server with four applications. These could be applications running on VMs or just applications running on a non-virtualized server. Application 1 must always run fast. If the network is congested, Application 1 always get the most out of that 10GbE connection. Application 2 is something that you don't want slowing down the customer experience delivered by Application 1, but you know it can be a bandwidth hog and it would be good to give that application all that is available. Applications 3 and 4 can fight over whatever bandwidth is available but again, if it is ALL available let them have also.

The QLogic NPAR Maximum Bandwidth setting is a number representing how much of the 10 gigs of bandwidth a partition is limited to. This means we do not put a maximum bandwidth limit on any PF. So we will set all four PFs to have the potential to access all 10Gbps. If a backup needs to run at 10Gbps and the customer traffic that normally runs on Application 1 is zero, then the backup application gets all 10 Gbps.

The Relative Bandwidth Weight is used to determine the relative bandwidth a partition will get with regard to the other partitions when they compete for the same available bandwidth. A partition will get its Relative Bandwidth Weight out of the available bandwidth but never more than its configured Maximum Bandwidth. If a partition is not using its Relative Bandwidth Weight, its bandwidth will be available for other partitions to use. In other words the applications running on your servers will have dynamic access to the network. The QLogic 3400 and 8400 Series adapters do all the work of "directing traffic" so you don't have to.

Application Bandwidth Guarantee Example with QLogic NPAR
So far in our example we put no maximum bandwidth limit on any of our Applications. If every application wants all of the bandwidth, we can use the Relative Bandwidth Maximum to settle the fight. If, for example we want Application 1 to get the most bandwidth when everyone is fighting, we would set PF1 to a Relative Bandwidth Weight of say 60%. This would ensure 6 Gbps out of 10Gbps available would be reserved for PF1 and Application 1 if and when they require it.

We could then set PF2 to a Relative Bandwidth Weight of 20% for the backup application. This would ensure that 2Gbps is reserved for the backups, while Application 1 is using 6Gbps. This leaves another 2Gbps of bandwidth remaining.

We set PF3 and PF4 to a Relative Bandwidth Weight of 10% each so they end up getting 1Gbps each during a bandwidth fight. 60% + 20% + 10% + 10% = 100% of the 10GbE bandwidth is now configured and our Service Level Agreement is met.

On Monday morning when everything is running at full throttle the primary application is getting 6Gbps. The backup application is running at 2Gbps and the two other applications using PF3 and PF4 are each running at 1Gbps.

Now it is Sunday. The primary application is idle, the backups have completed. Suddenly the application on PF3 needs to process a huge transaction. Since the other applications are idle it is able to use all 10Gbps because it has a Maximum Bandwidth setting of 10Gbps and the Relative Bandwidth Weight is meaningless because the application using PF3 is the only application consuming bandwidth, in this case PF3 gets the full 10Gbps.

QLogic NPAR offers a dynamic solution to the problem of ensuring Quality of Service for all of the applications running on your servers when network utilization is constantly fluctuating. Every application can get as much bandwidth as is available. During a bandwidth fight the critical applications get what they are supposed to get to meet their respective SLAs. That is what makes QLogic NPAR dynamic and hands free and superior to SR-IOV alone. In Part 3 of this series "Dynamic application performance guarantee versus a static, manual approach" we will compare this dynamic bandwidth allocation to a more static algorithm that is based on SR-IOV Rate Limiting limited to the Linux Operating System.

For More Information
Please see these links for more information on these innovative 10GbE Intelligent Ethernet and Converged Network adapters. An excellent use case discussion for VMware and QLogic NPAR can be found in our Solution Sheet: Switch Independent NIC Partitioning and VMware Virtual Environments. A handy list of Frequently Asked Questions is detailed in our Switch Independent NIC Partitioning document.

Blog Series Links

Click here to follow
QLogic on our social
media channels.