Lori MacVittie

The Conflation of Pay-as-you-Grow Hardware with On-Demand

Lori MacVittie — Wed, 22 Feb 2012 12:36:00 GMT

#cloud Today’s post is brought to you by the Law of Diminishing Returns

The conflation of “pay-as-you-grow” with “on-demand” tends to cause confusion in the realm of networking and hardware. This is because of the way in which networking vendors have attempted to address the demand of organizations to pay only for what you use and to expand on-demand. The premise is that costs grow proportionally with capacity. In cloud computing organizations achieve this. As more capacity (resources from hardware) are necessary, they are provisioned an paid for. On-demand scale. The costs per transaction (or user) remain consistent with growth because there is a direct relationship between an increase in capacity (hardware resources such as memory and CPU) and capacity.

Networking vendors have attempted to simulate this capability through licensing based restrictions, allowing customers to initially provision resources at a much lower cost per transaction. The fallacy in this scheme is that, unlike cloud computing, no additional capacity (hardware resources) are ever provisioned. It is only the artificial limitation on the use of that capacity that is lifted at a price during the “growth” stage. Regardless of form-factor, this has a profound impact on the cost-per-transaction (or user) and, it turns out, on the scalability of performance.

The difference between the two models is significant. A “pay-as-you-grow” licensing-based model is like having a great kitchen that is segmented. You can only use a portion of it initially. If you need to use more because you’re giving a dinner party, you can pay for anther segment. The capabilities of the kitchen don’t change, just how much of you can use. Conversely, an on-demand model such as is offered by cloud lets you start out with a standard-sized kitchen, and if you need more room you tack on another kitchen, increasing not only size, but capability. If you’ve ever cooked for a large number of people, you know that one oven is likely not enough, but that’s what you get with “pay-as-you-grow” – one oven with initially limited access to it. The on-demand model gives you two. Or three, or as many as you need to make dinner for your guests.

SCALE of PERFORMANCE

While appearing more cost effective at the outset, “pay-as-you-grow” strategies do not always provide for the scalability of all performance metrics.

This is because licensing restrictions do not impact the underlying hardware capacity, and it is the hardware capacity and load that is always the most constraining factor for performance. As utilization of hardware increases, capacity degrades, albeit in some cases more slowly than others. The end result is that scale-by-license produces increasingly diminishing returns on performance. This is true whether we’re considering layer 4 throughput or layer 7 requests per second, two common key performance metrics for application delivery solutions.

The reason for this is simple – you aren’t increasing the underlying speed or capacity, you’re only the load that can be handled by the device. That means the overall utilization is higher, and it is nearly a priori knowledge in networking that as utilization (load) increases, performance and capacity degrade. The result is uneven scalability as you progress through the “upgrade” of licenses. You’re still paying the same amount per increase, but each increase nets you less capacity and slower performance than the upgrade before.

Conversely, a true on-demand model, based on the same premises as cloud computing, scales more linearly. Upgrading four times nets you four times the performance at four times the cost, because the resources available also increase four times. Cost and performance scale equally with a platform-based model. Licensing-based models do not, nay they cannot, because they aren’t scaling out resources, they’re only scaling out what portion of the resources you have access to.

It’s a subtle difference but one that has a significant impact on capacity and performance.

ECONOMY of SCALE

As has been noted, as utilization of hardware increases, capacity degrades.

When we start looking at the total costs when compared to the scaling value received, it becomes apparent that the pay-as-you-grow model produces increasing costs per transaction while the platform-based model produces decreasing costs per transaction. This is simply a matter of math. If each upgrade in a pay-as-you-grow model increases the overall cost by 1/4, but returns increasingly smaller performance and capacity gains, you end up with a higher cost per transaction. Conversely, a more linear on-demand approach actually ends up producing slightly lower or consistent costs per transaction.

The economy of scale is important as it’s a fairly common financial metric used to evaluate infrastructure as it directly translates into business costs and can be used to adjust pricing and facilitate estimated expenses.

This disparity is not one that is often considered up front, as it is usually the up-front, capital investment that is most important to the initial decision. This oversight, however, almost always proves to be problematic as it is rarely the case that an organization does not need additional capacity and performance, and thus the long-term costs of Pay-as-you-Grow result in a much poorer return on investment in terms of performance than a Platform-based scalability model.

DISRUPTION and CapEx

The arguments against a platform-based model generally consist of disruptiveness of upgrades and initial costs.

Disruption is a valid concern and it is almost always true that hardware-based devices require a certain amount of disruption to upgrade. The lifting of an artificially imposed limitation on the amount of existing hardware that can be utilized, conversely, does not. This is where the cloud computing on-demand (i.e. throw more (virtual) hardware at the problem) usually diverges from the on-demand model used to scale out networking hardware, such as an application delivery controller.

The introduction of virtual application delivery controllers and the ability to seamlessly scale out in a model similar to cloud computing eliminates the disruption-based argument. There do exist models and technology which closely models a cloud computing on-demand scalability strategy that are as non-disruptive as scaling out via a licensing-based model.

This leaves the initial cost argument, which generally boils down to a CapEx versus OpEx argument. You are going to pay over the long run, the question is whether you pay up front or over time and what the return on those investments will ultimately be.

Just don’t let the conflation of cloud computing’s on-demand with pay-as-you-grow licensing-based models obscure what those real costs will be.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,cloud computing,scalability,pay-as-you-grow,on-demand,load balancing,virtualization,performance,network,blog

F5 and Traffix: When Worlds Collide

Lori MacVittie — Tue, 21 Feb 2012 16:16:35 GMT

#mwc12 #traffix #mobile Strategic points of control are critical to managing the convergence of technology in any network - enterprise or carrier

What happens when technology converges? When old meets new?

A fine example of what might happen is what has happened in the carrier space as voice and data services increasingly meet on the same network, each carrying unique characteristics forward from the older technology from which they sprung. In the carrier space having moved away from older communications technology does not mean having left behind core technology concepts. Though voice may be moving to IP with the advent of LTE/4G, it still carries with it the notion of signaling as a means to manage communication and users, and the impact on networks from that requisite signaling mechanism is significant.

Along with the well-discussed and often-noted explosive growth of mobile and its impact on the enterprise comes a less-discussed and rarely noted explosive growth of signaling traffic and its impact on service providers. Enterprise experience with voice and signaling remains largely confined to SIP-focused deployments and are on a scale much smaller than that of the service provider. Hence the term “carrier-grade” to indicate the much more demanding environment. The number of signaling messages in 4G networks, for example, associated with a 3 minute IP voice call with data is 520. The same voice call today requires only 3. That exponential growth will put increasing pressure on carriers and require massive scale of infrastructure to support.

All that signaling traffic in carrier networks occurs via Diameter, the standard agreed upon by 3GPP (3^rd Generation Partner Project) for network signaling in all 4G/LTE networks. Diameter is to carrier networks what HTTP is to web applications today: it’s the glue that makes it all happen. As the preeminent Diameter routing agent (DRA) for for 3G, 4G / LTE and IMS environments, Traffix’ solutions are fluent in the signaling language used by carriers across the globe to identify users, manage provisioning, and authorize access to services and networks. One could reasonably describe Diameter as the Identity and Access Management (IAM) technology of choice for service providers. When a user does anything on a 4G network, Diameter is involved somehow.

What Traffix Signaling Delivery Controller (which is both a highly capable DRA as well as Diameter Edge Agent (DEA)) offers is a strategic point of control in the service providers network, serving as an intelligent tier in that network that enables interoperability, security, scale, and flexibility in how signaling traffic is managed and optimized. That should sound familiar, as F5 is no stranger to similar responsibilities in enterprise and web-class data centers today. F5 with its application and control plane technologies serves as an intelligent tier in the network that ensures interoperability, security, scale, and flexibility for how applications and services are delivered, secured, and optimized. What service providers do with Diameter – user identification, permission to roam, authorization to use certain networks, basically anything a user does on a 4G network – is akin to what F5 does with application delivery technology in the data center.

F5’s vision has been to create a converged carrier architecture that unifies IP services end-to-end across the application, data, and control plane. Diameter is a foundational piece of that puzzle, just as any-IP support is critical to providing that same converged application services approach in the data center, a data center routing agent, if you will.

Both approaches are ultimately about context, control, and collaboration.

CONVERGENCE BREEDS FRAGMENTATION

These three characteristics (context, control, collaboration) are required for a dynamic data center to handle the volatility inherent in emerging data center models as well as the convergence in service provider networks of voice and data. But as technologies converge, supporting infrastructure tends to fragment. This dichotomy is clearly present even in the enterprise, where unified communications (UC) implementations are creating chaos. In its early days, Diameter deployments in service provider networks experienced similar trends, and it was the development of the DRA that resolved the issue, bringing order out of chaos and providing a strategic point of control through which subscriber activity could be more efficiently managed. Out of chaos, order. That’s the value Traffix brings to carrier networks with its Signaling Delivery Controller (SDC). Traffix solutions optimize signaling traffic, offering service provider operators scalability, availability, visibility, interoperability, and more in an operationally consistent solution. With the number of mobile devices predicted to exceed the world population in the next year, and the advanced services those devices provide driving exponential growth in signaling traffic, the need to optimize signaling traffic is top of mind for most service providers today.

When diverse systems converge, their infrastructure must also converge in terms of support for the resulting unified system. This is particularly true as mobile and virtual desktops become more prevalent and bring with them their own unique delivery challenges to both the service provider and data center networks.

The two worlds are colliding, out there on the Internets and inside data centers, with more and more IP-related traffic requiring management within the carrier networks, and more and more traditionally carrier network traffic such as voice being seen inside the data center. What both worlds need is a fully end-to-end IP core infrastructure solution – one that can support IP and Diameter and scale regardless of whether the need is enterprise-class or carrier-grade. One that maintains context and manages access to resources across both voice and data and does so both seamlessly and transparently.

Bringing together F5’s control plane with that of Traffix brings a holistic approach to controlling a converged voice-data network that enhances critical network functions across the application, control, and data planes.

Traffix aligns well with F5’s overall vision of enabling intelligence in the network and providing context and control for all types of network services – whether carrier or enterprise.

Additional Resources:

F5 Networks Acquires Traffix Systems

The LTE signaling challenge

F5 Circles The Wagons and Adds Diameter to its Portfolio

Traffix Systems

F5 Sends LTE Signal With Acquisition

F5 Friday: The Dynamic Control Plane

Connect with Lori: Connect with F5:

Related blogs & articles:

What Does Mobile Mean, Anyway?

What is a Strategic Point of Control Anyway?

Force Multipliers and Strategic Points of Control Revisited

What CIOs Can Learn from the Spartans

The Three Axioms of Application Delivery

At the Intersection of Cloud and Control…

Carrier Grade DNS: Not your Parents DNS

The New Data Center Firewall Paradigm

Traffix Systems’ Blog

Technorati Tags: F5,MacVittie,Traffix Systems,Diameter,service provider,network,strategic point of control,AAA,security,availability,performance,blog

Moore’s (Traffic) Law

Lori MacVittie — Mon, 20 Feb 2012 13:10:00 GMT

#centaur #40gbe Pop quiz time – and you get +100 geek points if you get this one right.

What was the main difference between a 386SX and a 386DX?

If you answered (without using Google) the data bus (16-bit for an SX and 32-bit for a DX) then award yourself 100 geek points and a pat on the back.

How, you are asking, is this relevant to Moore’s Law? Well, if you recall, Moore’s law is, in layman’s terms, that processing power doubles approximately every two years. A little known corollary (little known because I just made it up) should be that along with processing power, traffic – data – on the network always significantly increases along with with processing power. Call it Moore’s Traffic Law.

A variety of industry analysts and experts have been predicting such growth for years now.

"We expect the Ethernet Switch market to experience two significant years of market growth in 2013 and 2014 from the migration of servers towards 10 Gigabit Ethernet," said Alan Weckel, Senior Director of Dell'Oro Group. "We believe that in 2013, most large enterprises will upgrade to 10 Gigabit Ethernet for server access through a mix of connectivity options ranging from blade servers, SFP+ direct attach and 10G Base-T.

-- Data Center to Drive Ethernet Switch Revenue Growth through 2016, According to Dell'Oro Group Forecast

Back in 2007, an IEEE presentation also described this growth, attributing it in part to, you guessed it, Moore’s Law:

Global IP traffic has increased eightfold over the past 5 years, and will increase fourfold over the next 5 years. Overall, IP traffic will grow at a compound annual growth rate (CAGR) of 32 percent from 2010 to 2015.

Server I/O bandwidth generators

Moore’s Law processing improvements

Data center virtualization

Networked storage

Clustered servers

Internet applications (e.g. IPTV, VoIP, Web2.0, Finance)

-- IEEE April 2007 from http://www.ieee802.org/3/hssg/public/apr07/hays_01_0407.pdf

Interestingly, the rate at which core networking doubled is faster than Moore’s Law’s interval of 24 months, according to one industry expert:

The presenters at the conference made a compelling case that server IO doubled every 24 months, while core networking doubled every 18 months. Server bus architectures must also mature to take advantage of the high bandwidth interconnect. This led to the idea to create 100Gb for the core (between switches) and 40Gb for the distribution/aggregation (pedestal/rack/blade servers to switches). As for the uses for these speeds, it is the next generation of servers which are characterized by dense computing and high utilization through virtualization which will use 40Gb and 100Gb will enable the success of 10Gb servers.

-- 40Gb and 100Gb Ethernet status and outlook (March 2010), Stuart Miniman

So how does this all relate again to the difference between a 386SX and 386DX? Well, if you were a geek back when these models were popular, you generally built your own desktop. And when you built that desktop you had to choose a motherboard. If you could afford it, you got the DX because the bus speed difference was noticeable; it was important to the performance of applications because one of the primary bottlenecks in a computer is – you guessed it – the data bus speed. It’s equivalent to having a very fast car, but being on the 101 at rush hour. This is relevant to today’s data center networks because one of the primary data center bottlenecks is the “data bus” speed: the network.

WHAT THIS MEANS for the NETWORK

With the growth of both server and desktop virtualization, demand for high-performance applications, increasing consumption of video, consumerization, and increasing connectivity, we’re seeing challenges in the core data center network related to bandwidth. Where 1GB between services in the data center used to suffice, we’re now seeing a need for 10GB. And when we start seeing servers and desktops leveraging fatter pipes, we start seeing a demand for fatter pipes and greater capacity at aggregation points throughout the network, like in the application delivery tier.

Adding pressure to legitimate traffic growth is the need for higher capacity protection. With Internet data center firewalls failing to withstand the load of massive and increasingly diverse attacks, scalable and higher performance security platforms are necessary to provide more comprehensive coverage. Without increased network capacity, data centers must manage the multitude of attacks through several point products, which increases the complexity, latency, and points of failure in the data center architecture.

This is unacceptable at a time when operational efficiency is required to manage constrained budgets and resources.

Switching, routing, application delivery. These critical data center components will need to increase their bandwidth capacity sooner rather than later to keep up with the growth of internet traffic (expected to quadruple by 2015¹) and the growing density of server virtualization within the data center (anticipated growth by a factor of five between 2010 and 2015²). Critical network infrastructure will need to consider Moore’s (Traffic) Law and increase dramatically its capacity to manage larger volumes of traffic – and soon.

The adoption of 40GBE is ramping up as costs decline, and that means infrastructure must also step up and meet that demand – and comply with Moore’s (Traffic) Law.

¹ Top Ten Trends and How they will affect the Data Center, Gartner, Inc, David Cappuccio December 2011

² Gartner, From Virtual Machines to cloud computing , Tom Bittman, December 2011

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

The Three Axioms of Application Delivery

The Fundamental Problem with Traditional Inbound Protection

Desktop VDI May Be Ready for Prime Time but Is the Network?

Performance in the Cloud: Business Jitter is Bad

The API is the Center of the Application (Integration) Universe

Virtualization and Cloud Computing: A Technological El Niño

Technorati Tags: F5,MacVittie,performance,40gbe,scalability,availability,hardware,network,aplication delivery,Moore's Law,DDoS,security,blog

F5 Friday: Doing VDI, Only Better

Lori MacVittie — Fri, 17 Feb 2012 13:31:00 GMT

#F5 does #VDI, and it does it better.

There are three core vendors and protocols supporting VDI today. Microsoft with RDP, Citrix with ICA, and VMware with PCoIP. For most organizations a single vendor approach has been necessary, primarily because the costs associated with the supporting network and application delivery network infrastructure required to deliver VDI with the appropriate levels of security while meeting performance expectations of users and the need to maintain high availability.

It’s a tall order that’s getting taller with every mobile client introduced, especially when you toss in a liberal dose of enforcing policies regarding access to virtual desktops.

Most folks are well aware of F5’s long history of deep integration with its partners Microsoft and VMware. Whether it’s integrating with management systems or designing, testing, and documenting the often times complex joint architectures required to deliver enterprise-class applications like SharePoint and Exchange or building out a dynamic data center model to support cloud computing , F5 works in tandem with its partners to ensure the best experience possible not only for the ultimate consumers but for the IT operations folks who must deploy the solutions.

But what most folks aren’t likely as aware of is F5’s commitment and expertise to delivering Citrix VDI as well. That’s natural. After all, Citrix competes with F5 at the application delivery tier and it might seem natural to assume that Citrix could deliver its own technology better than any competitor.

But that assumption ignores that F5’s core focus has been and continues to be unified application delivery rather than applications – like VDI - themselves. That unified is in bold because it’s a key factor in why F5 is able to deliver all VDI solutions better, faster, and more efficiently than any other solution today.

See, F5’s approach since introducing v9 and its platform has been about the integration of application delivery services. Whether those services reside on the same physical (or virtual) platform is not as important as the integration and collaboration between those services that is made possible by being designed, developed, and ultimately deployed on a common, high-speed, high-security application delivery platform.

Consider, for example, the case of a comprehensive Citrix VDI delivery solution:

That’s a lot of components, each of which adversely impacts performance and increases operational risk by adding additional complexity and components to the architecture. That’s ignoring the cost, as well, added by not only the need to deploy these solutions but to power them, manage them, and maintain them over time. It’s costly, it’s complex, and it’s ultimately not very extensible.

Authentication, for example, must be managed in multiple locations, which increases the risk of misconfiguration or human error, and makes it more likely that orphaned identities will be left behind, always a concern as it creates an opportunity for a breach. This solution also requires manual scripting to integrate the disparate authentication sources, yet another tedious, manual and error-prone process.

Now consider the same solution, but leveraging F5 and its platform with BIG-IP Local Traffic Manager and BIG-IP Access Policy Manager deployed:

Consolidated (and integrated) authentication. Highly extensible policy management and enforcement, and we’ve eliminated the Web Interface Servers (and NetScalers, but as we’ve replaced them with BIG-IP that’s more of a wash than a win).

But it’s not just about reducing the complexity (and ultimately the cost) of such a deployment. BIG-IP LTM and APM can simultaneously support Microsoft and VMware VDI while delivering Citrix VDI – as well as a host of other applications. F5’s solution isn’t a VDI delivery solution, it’s an application delivery solution with support for all VDI implementations and protocols. That includes Citrix Session Reliability to session roaming and reconnection as well as SmartAccess filters. F5 BIG-IP APM can populate SmartAccess filter values based upon any information discovered using VPE(source IP address, AV presence, client certificate presence, etc.) and pass them to the XML broker for evaluation.

And let’s not forget about Citrix Multi-Streaming, which to give Citrix credit where due is an innovative solution to the problem of traffic prioritization in VDI delivery. If you aren’t familiar with Multi-streaming, it was introduced in XenDesktop 5.5 & XenApp 6.5 and uses multiple TCP connections (aka Multi-Stream ICA) to carry the ICA traffic between the client and the server. Each of the connections is associated with a different class of service, which allows the network administrator to prioritize each class of service, independently from each other, based on the TCP port number used for the connection. F5 supports Multi-Streaming and has for some time now. No worries.

Then there’s VMware PCoIP – which can be challenging, especially when paired with DTLS for security. F5 has that covered, too, as well as its long-term support for optimal delivery of Microsoft-based solutions including its broad set of VDI solutions .

I know, you’ve heard configuring F5 BIG-IP is hard and cumbersome. Well, in the past that may have been true but the introduction of iApp with BIG-IP v11 has changed that tune from a dirge to a delightful melody. iApp deployment templates and accompanying deployment guides for XenApp and XenDesktop make deploying BIG-IP painless and far less error-prone than manual processes.

One of the drawbacks of VDI architectural complexity is it often presents itself as a single-vendor solution – and a reason for a single vendor virtualization strategy. If your application delivery and access management solution is capable of unifying access while delivering secure, highly performing, very available <virtual, physical> <desktops, applications, solutions> of any flavor, you’d have more of a choice in what your overall architecture would look like. That kind of choice is enabled through flexibility of the underlying application delivery network infrastructure, which is exactly the role F5 plays in your data center.

If your application delivery solution is a flexible platform and not a product, then your network becomes an enabler of architecture and choice rather than being the limiting factor.

VDI Resources:

Updated Citrix XenApp/XenDesktop APM Template

Citrix XenApp/XenDesktop Combined Load-balancing iApp

VMware View 5 iApp Template

Delivering Virtual Desktop Infrastructure with a Joint F5-Microsoft Solution

Optimizing VMware View VDI Deployments

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: A Single Namespace to Rule Them All (Overcoming VMware Pod Limitations)

F5 Friday: Cookie Cutter vApps Realized (Overcoming IP address dependencies to enable application mobility)

More Users, More Access, More Clients, Less Control

WILS: The Importance of DTLS to Successful VDI

From a Network Perspective, What Is VDI, Really?

Scaling VDI Architectures

VMworld 2011: F5 BIG-IP v11 iApps for Citrix

Technorati Tags: F5,F5 Friday,MacVittie,blog,VDI,Citrix,XenApp,XenDesktop,v11,iApp,BIG-IP,BIG-IP APM,VMware,Microsoft,VMware View,virtualization,application delivery

SuperSizing the Data Center: Big Data and Jumbo Frames

Lori MacVittie — Thu, 16 Feb 2012 13:10:00 GMT

#centaur #40GBE Data center transformation discussions too often overlook the impact on the network – and its necessary transformation.

For many of the same reasons IPv6 migration is moving slower than perhaps it should given the urgent need for more IP addresses (to support all those cows connecting to the Internet) is the sheer magnitude of such an effort. Without the ability for IPv6-only nodes to talk to IPv4-only nodes, there’s a lot of careful planning that has to happen around the globe to ensure success and continued communication between the two incompatible protocols.

In many ways, Jumbo Frames – despite performance advantages – suffer from the same technological incompatibility. Remember that Jumbo Frames – 9000 bytes – are incompatible with regular old sized Ethernet frames (1500 bytes). It makes sense for much the same reasons – you simply can’t stuff 9000 bytes into a frame designed to hold 1500. And one of the basic rules of Ethernet is that the smallest MTU (maximum transmission unit) used by any component in a network path determines the maximum MTU for all traffic that flows along that path.

And yet the benefits of Jumbo Frames have been demonstrated many times. It reduces fragmentation overhead (the process of splitting data into chunks small enough to fit into a 1500 byte frame) which translates into lower CPU overhead on hosts. It also allows for more aggressive TCP dynamics, which results in greater throughput and better responses to some kinds of loss. But even though Jumbo Frames can deliver an increase in throughput along with a simultaneous decrease in CPU utilization they are rarely, if ever, used in a data center network.

That, however, is changing.

You might recall some predictions with respect to 10GB adoption in the data center:

"We expect the Ethernet Switch market to experience two significant years of market growth in 2013 and 2014 from the migration of servers towards 10 Gigabit Ethernet," said Alan Weckel, Senior Director of Dell'Oro Group. "We believe that in 2013, most large enterprises will upgrade to 10 Gigabit Ethernet for server access through a mix of connectivity options ranging from blade servers, SFP+ direct attach and 10G Base-T.

-- Data Center to Drive Ethernet Switch Revenue Growth through 2016, According to Dell'Oro Group Forecast

Historically in the switching market the deployment of 10G in the core networks and the use of Jumbo Frames went pretty much hand-in-hand. Until recently, however, 10GB just wasn’t making its way into the data center (costs were too high) and the only place Jumbo Frames were really seen was within storage networks, particularly in conjunction with FCIP implementations.

For the most part, a lack of support within the data center infrastructure and no real urgency for the efficiency gains that come from Jumbo Frames (and the fact that the Internet is not using Jumbo Frames from end-to-end, which pretty much kills the value proposition) meant enterprise organizations looked at Jumbo Frames with a “someday, but not right now” attitude. But with the increasing adoption of virtualization and movement of 10G networks into datacenters (in part driven by virtualization), Jumbo Frames are becoming more of a reality for a larger population of organizations.

Consider the following support and recommendations for jumbo frames within VMware’s documentation:

TCP Segmentation Offload and Jumbo Frames:
Jumbo frames must be enabled at the host level using the command-line interface to configure the MTU size for each vSwitch. TCP Segmentation Offload (TSO) is enabled on the VMkernel interface by default, but must be enabled at the virtual machine level.
-- ESX 4.0 Config Guide, page 57

Optimizing vMotion Performance
Use of Jumbo Frames is recommend for best vMotion performance.
-- Page 188 vSphere 4.0 System Admin Guide

vSphere 4 Performance
Jumbo Frames is one of the suggested means of improving CPU performance with respect to vSphere
-- CPU Performance Enhancement Advice (Table 22-6, page 278)

Add in cloud computing and a desire to more quickly move big data (virtual machines) over the WAN to cloud providers for a variety of business initiatives – a process in which the number of frames sent and low latency is key to success - and Jumbo Frames suddenly start looking a lot more like a requirement than a “Yeah, yeah, we’ll get to that eventually. Maybe.”

Virtualization and cloud computing are transformative technologies. As some have often – and loudly – reminded us, the network is part of the data center, and indeed an integral part of the data center. While we tend to focus on the management and provisioning and automation of the data center and its cultural impact, we should not overlook the impact that these technologies and the changes they bring are having – and will have – on the network.

If cloud and virtualization and consumerization and emerging technologies like HTML5 are going to transform the data center, that’s going to necessarily include the network. Ultimately, support for Jumbo Frames will be a requirement – a checkbox item – for every component in the data center.

Connect with Lori: Connect with F5:



Related blogs & articles:

Sometimes It Is About the Hardware

Live Migration versus Pre-Positioning in the Cloud

F5 and VMware–One Step Closer to the Cloud as a Seamless Data Center Extension

Cloud is an Exercise in Infrastructure Integration

Performance in the Cloud: Business Jitter is Bad

Like Cars on a Highway.

Technorati Tags: F5,MacVittie,Jumbo Frames,Vmware,vmotion,live migration,network,MTU,ethernet,performance,40GBE,blog

Oops! HTML5 Does It Again

Lori MacVittie — Wed, 15 Feb 2012 12:28:00 GMT

#HTML5 #infosec A multitude of security-related solutions rely upon the ability to extract and examine mime-objects from web-content. HTML5 may significantly impair their ability to do so.

The trade off between security and performance has long been a known issue across IT organizations. One of the first things to go when performance is unacceptable is a security solution. This isn’t just an IT phenomenon either; consider how many of us have disabled endpoint security solutions like anti-virus scanners to improve performance?

Our refusal to be slowed down by what may seem to some as extraneous security is what eventually led IT security professionals to revise their strategies and enforce such scans on inbound content in the network. Network-attached security scanning solutions have long been a staple of inbound e-mail and has found increasing use as a means to scan inbound web-content, as well, as an attempt to eliminate potential malware from having access to the corporate network.

IT Organizations That Trade Security for Performance Deserve Neither

A new [at the time of publication, July 2011] survey of 487 IT professionals that was conducted by Crossbeam, a provider of high-performance security gateways, finds that while 91 percent of the respondents were not only making tradeoffs between security and performance, a full 81 percent were actually disabling security features.

HTML and soon, if we believe the predictions HTML5, is the lingua franca of Internet communication. Oh, applications may speak JSON under the covers, but in the end it’s just data to be displayed to the user which means HTML(5).

What does that mean for anti-virus and malware web scanners? Well, if one of the features of HTML5 being leveraged is WebSockets, a lot. Otherwise, not much. At least not yet.

You see, WebSockets accidentally trades performance for security.

OOPS

One of the things WebSockets does to dramatically improve performance is eliminate all those pesky HTTP headers. You know, things like CONTENT-TYPE. You know, the header that tells the endpoint what kind of content is being transferred, such as text/html and video/avi. One of the things anti-virus and malware scanning solutions are very good at is detecting anomalies in specific types of content. The problem is that without a MIME type, the ability to correctly identify a given object gets a bit iffy. Bits and bytes are bytes and bytes, and while you could certainly infer the type based on format “tells” within the actual data, how would you really know? Sure, the HTTP headers could by lying, but generally speaking the application serving the object doesn’t lie about the type of data and it is a rare vulnerability that attempts to manipulate that value. After all, you want a malicious payload delivered via a specific medium, because that’s the cornerstone upon which many exploits are based – execution of a specific operation against a specific manipulated payload. That means you really need the endpoint to believe the content is of the type it thinks it is.

But couldn’t you just use the URL? Nope – there is no URL associated with objects via a WebSocket. There is also no standard application information that next-generation firewalls can use to differentiate the content; developers are free to innovate and create their own formats and micro-formats, and undoubtedly will. And trying to prevent its use is nigh-unto impossible because of the way in which the upgrade handshake is performed – it’s all over HTTP, and stays HTTP. One minute the session is talking understandable HTTP, the next they’re whispering in Lakota, a traditionally oral-only language which neatly illustrates the overarching point of this post thus far: there’s no way to confidently know what is being passed over a WebSocket unless you “speak” the language used, which you may or may not have access to.

The result of all this confusion is that security software designed to scan for specific signatures or anomalies within specific types of content can’t. They can’t extract the object flowing through a WebSocket because there’s no indication of where it begins or ends, or even what it is. The loss of HTTP headers that indicate not only type but length is problematic for any software – or hardware for that matter – that uses the information contained within to extract and process the data.

WEDGE NETWORKS

Wedge Networks, whose name you may never before heard even though you might have had content scrubbed by their devices and not known it, has a solution to the problem of disaggregating web objects without requiring specific identification by HTTP headers, thus solving this problem and several other similar ones where protocols lack the means to definitively identify specific content by type.

WedgeOS - Network Data Processor Architecture

The WedgeOS Network Data Processor ("NDP") is the proprietary architecture that allows content inspection at Gigabit speeds without impacting network performance. The WedgeOS NDP architecture revolutionized Web Security Appliances with the introduction of BeSecure. BeSecure is capable of intercepting and actively scanning all internet traffic for malicious content as it enters the network.

What they meant to say was “we do deep content inspection on streaming traffic and are able to accurately identify – and subsequently extract – MIME objects at line rate and then scan them for bad stuff you don’t want on your network.” Content comes into their device (and it’s off-the shelf hardware, I’m told), MIME objects are disaggregated regardless of transport or application protocol, shoved down a high-speed internal bus into which are plugged a variety of security scanning functions, and then shoved back out the other side, assuming all was well. Policies enable the ability to determine exactly what happens if there are anomalies or malicious code discovered.

Wedge Networks has partnered with a number of well-known and industry leading security scanning solutions and brought them together into a single device. Applying the old “crack the packet only once” doctrine, the device is able to perform its scans as fast as objects can traverse its internal bus.

The devices deploys in either proxy or transparent mode, with the latter being most popular simply due to the mitigation of disruption that can come with inserting a proxy-based solution into an established network.

Let’s assume for a moment that a Wedge Networks device really does accomplish all this – at line rate. I can’t know, I don’t evaluate products in lab environments any more, so I can take their word for it. But let’s assume it does. That opens a wide variety of possibilities – both inbound and outbound – for protecting web applications and customers alike, and not just for HTML5.

Assuming no degradation of overall performance, the ability to detect and prevent delivery of malware that may have been surgically inserted into your database or CMS via XSS or SQLi would be a boon, if only to let you know it happened much sooner and provide the time necessary to redress the infection. Nearly every rational organization scans inbound e-mail for potential risks, but very few (if any) scan outbound. We all know why – the belief that performance is more important than security, especially when consumer dollars are on the line. If Wedge Networks can do as it promises and not impede performance while still providing a valuable security service, well, that might be something to think about.

Connect with Lori: Connect with F5:



Related blogs & articles:

IT Organizations That Trade Security for Performance Deserve Neither

Performance in the Cloud: Business Jitter is Bad

The Ascendancy of the Application Layer Threat

HTML5 Web Sockets Changes the Scalability Game

HTML5 Going Like Gangbusters But Will Anyone Notice?

Fire and Ice, Silk and Chrome, SPDY and HTTP

Technorati Tags: F5,MacVittie,Wedge Networks,network,security,HTML5,WebSockets,malware,anti-virus,performance,application security,blog

What Does Mobile Mean, Anyway?

Lori MacVittie — Mon, 13 Feb 2012 15:18:00 GMT

We tend to assume characteristics upon hearing the term #mobile. We probably shouldn’t…

There are – according to about a bazillion studies - 4 billion mobile devices in use around the globe.

It is interesting to note that nearly everyone who notes this statistic and then attempts to break it down into useful data (usually for marketing) that they almost always do so based on OS or device type – but never, ever, ever based on connectivity.

Consider the breakdown offered by W3C for October 2011. Device type is the chosen taxonomy, with operating system being the alternative view. Unfortunately, aside from providing useful trending on device type for application developers and organizations, this data does not provide the full range of information necessary to actually make these devices, well, useful.

Consider that my Blackberry can either connect to the Internet via 3G or WiFi. When using WiFi my user experience is infinitely better than via 3G and, if one believes the hype, will be even better once 4G is fully deployed.

Also not accounted for is the ability to pair my Blackberry Playbook to my Blackberry phone and connect to the Internet via that (admittedly convoluted) chain of connectivity. Bluetooth to 3G or WiFi (which in my house has an additional chain on the LAN and then back out through a fairly unimpressive so-called broadband connection). But I could also be using the Playbook’s built-in WiFi (after trying both this is the preferred method, but in a pinch…)

You also have to wonder how long it will be before “mobile” is the GPS in your car, integrated with services via Google Map or Bing to “find nearby” while you’re driving? Or, for some of us an even better option, find the nearest restroom off this highway because the four-year old has to use it – NOW.

Trying to squash “mobile” into a little box is about as useful as trying to squash “cloud” into a bigger box. It doesn’t work. The variations in actual implementation in communication channels across everything that is “mobile” require different approaches to mitigating operational risk, just as you approach SaaS differently than IaaS differently than PaaS.

Defining “mobile” by its device characteristics is only helpful when you’re designing applications or access management policies. In order to address real user-experience issues you have to know more about the type of connection over which the user is connecting – and more.

CONTEXT is the NEW BLACK in MOBILE

This is not to say that device type is not important. It is, and luckily device type (as well as browser and often operating system), are an integral part of the formula we all “context.”

Context is the combined set of variables that make it possible to interpret any given connection with respect to its unique client, server, network, and application needs.

It’s what allows organizations to localize, to hyperlocalize, and to provide content based on location. It’s what enables the ability to ensure performance whether over 3G, 4G, LAN, or congested WAN connections. It’s the agility to route application requests to the best server-side location based on a combination of client location, connection type, and current capacity across multiple sites – whether cloud, managed hosting, or secondary data centers.

Context is the ‘secret sauce’ to successful application delivery. It’s the ingredient that makes it possible to make the right decisions at the right time based on current conditions that address operational risk – performance, security, and availability. Context is what makes the application delivery tier of the modern data center able to adapt dynamically. It’s the shared data that forms the foundation for the collaboration between application delivery network infrastructure and provisioning systems both local and in the cloud, enabling on-demand scalability and at some point, instant mobility in an inter-cloud architecture.

Context is a key component to an agile data center, because it is only be inspecting all the variables that you can interpret them in a way that leads to optimal decisions with respect to the delivery of an application, which includes choosing the right application instance whether it’s deployed remotely in a cloud computing environment or locally on an old-fashioned piece of hardware. Knowing what device a given request is coming from is not enough, especially when the connection type and conditions cannot be assumed. The same user on the same device may connect via two completely different networking methods within the same day – or even same hour. It is the network connection which becomes a critical decision point around which to apply proper security and performance-related policies, as different networks vary in their conditions.

So while we all like to believe that our love of our chosen mobile platform is vindicated by statistics, we need to dig deeper when we talk about mobile strategies within the walls of IT. The device type is only one small piece of a much larger puzzle called context.

“Mobile” is as much about the means of connectivity as it is the actual physical characteristic of a small untethered device. We need to recognize that, and incorporate it into our mobile delivery strategies sooner rather than later.

[Updated: This post was updated 2/17/2012 - the graphic was updated to reflect the proper source of the statistics, w3schools ]

Connect with Lori: Connect with F5:



Related blogs & articles:

Long-distance live migration moves within reach

HTML5 Web Sockets Changes the Scalability Game

At the Intersection of Cloud and Control…

F5 Friday: The Mobile Road is Uphill. Both Ways

More Users, More Access, More Clients, Less Control

Cloud Needs Context-Aware Provisioning

Call Me Crazy but Application-Awareness Should Be About the Application

The IP Address – Identity Disconnect

The Context-Aware Cloud

Technorati Tags: F5,MacVittie,mobile,context-aware,network,security,performance,availability,quasar,blog

F5 Friday: What’s Inside an F5?

Lori MacVittie — Fri, 10 Feb 2012 12:00:00 GMT

Is it Linux? Is it third-party? Is it proprietary? Isn’t #vcmp just a #virtualization platform? Just what is inside an F5 BIG-IP that makes it go vroom?

Over the years I’ve seen some pretty wild claims about what, exactly, is “inside” a BIG-IP that makes it go. I’ve read articles that claim it’s Linux, that it’s based on Linux, that it’s voodoo magic. I’ve heard competitors make up information about just about every F5 technology – TMOS, vCMP, iRules – that enables a BIG-IP to do what it does.

There are two sources of the confusion with respect to what’s really inside an F5 BIG-IP. The first stems, I think, from the evolution of the BIG-IP. Once upon a time, BIG-IP was a true appliance – a pure software solution delivered pre-deployed on pretty standard hardware. But it’s been many, many years since that was true, since before v9 was introduced back in 2004. BIG-IP version 9 was the beginning of BIG-IP as not a true appliance, but a purpose-built networking device. Appliances deployed on off the shelf hardware generally leverage existing operating systems to manage operating system and even networking tasks – CPU scheduling, I/O, switching, etc… but BIG-IP does not because with version 9 the internal architecture of BIG-IP was redesigned from the ground up to include a variety of not-so-off-the-shelf components. Switch backplanes aren’t commonly found in your white-box x86 server, after all, and a bladed chassis isn’t something common operating systems handle.

TMOS – the core of the BIG-IP system – is custom built from the ground up. It had to be to support the variety of hardware components included in the system – the FPGAs, the ASICs, the acceleration cards, the switching backplane. It had to be custom built to enable advances in BIG-IP to support the non-disruptive scale of itself when it became available on a chassis-based hardware platform. It had to be custom built so that advances in internal architectures to support virtualization of its compute and network resources, a la vCMP, could come to fruition.

The second source of confusion with respect to the internal architecture of BIG-IP comes from the separation of the operational and traffic management responsibilities. Operational management – administration, configuration, CLI and GUI – resides in its own internal container using off-the-shelf components and software. It’s a box in a box, if you will. It doesn’t make sense for us – or any vendor, really – to recreate the environment necessary to support a web-based GUI or network access (SSH, etc…) for management purposes. That side of BIG-IP starts with a standard Linux core operating system and is tweaked and modified as necessary to support things like TMSH (TMOS Shell).

That’s all it does. Monitoring, management. It generates pretty charts and collects statistics. It’s the interface to the configuration of the BIG-IP. It’s lights out management. This “side” of BIG-IP has nothing to do with the actual flow of traffic through a BIG-IP aside from configuration. At run time, when traffic flows through a BIG-IP, it’s all going through TMOS – through the purpose and very custom built system designed specifically to support application delivery services.

This very purposeful design and development of technology is too often mischaracterized – intentionally or unintentionally – as third-party or just a modified existing kernel/virtualization platform. That’s troubling because it hampers the understanding of just what such technologies do and why they’re so good at doing it.

Take vCMP, which has sometimes been maligned as little more than third-party virtualization. That’s somewhat amusing because vCMP isn’t really virtualization in the sense we think about virtualization today. vCMP is designed to allow the resources for a guest instance to span one or multiple blades. It’s an extension of multi-processing concepts as applied to virtual machines. If we analogized the technology to server virtualization, vCMP would be the ability to assign compute and network resources from server A to a virtual machine running on server B. Cloud computing providers cannot do this (today) and it’s not something that’s associated with today’s cloud computing models; only grid computing comes close, and it still takes a workload-distributed view rather than a resource-distributed view.

vCMP stands for virtual CMP – clustered multi-processing. CMP was the foundational technology introduced in BIG-IP version 9.4 that allowed TMOS to take advantage of multiple multi-core processors by instantiating one TMM (Traffic Management Microkernel) per core, and then aggregating them – regardless of physical location on BIG-IP – to appear as a single pool of resources. This allowed BIG-IP to scale much more effectively. Basically we applied many of the same high-availability and load distribution techniques we use to ensure applications are fast and available to our internal architecture. This allowed us to scale across blades and is the reason adding (or removing) blades in a VIPRION is non-disruptive.

Along comes a demand for multi-tenancy, resulting in virtual CMP. vCMP isn’t the virtual machine, it’s the technology that manages and provisions BIG-IP hardware resources across multiple instances of BIG-IP virtual machines; the vCMP guests, as we generally call them. What we do under the covers is more akin to an application (a vCMP guest) being comprised of multiple virtual machines (cores), with load balancing providing the mechanism by which resources are assigned (vCMP) than it is simple virtualization.

So now you know a lot more about what’s inside a BIG-IP and why we’re able to do things with applications and traffic that no one else in the industry can. Because we aren’t relying on “standard” virtualization or operating systems. We purposefully design and develop the internal technology specifically for the task at hand, with an eye toward how best to provide a platform on which we can continue to develop technologies that are more efficient and adaptable.

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: Sync, Share, and Scale

F5 Monday? The Evolution To IT as a Service Continues … in the Network

F5 Friday: Speeds, Feeds and Boats

If a Network Can’t Go Virtual Then Virtual Must Come to the Network

Architecturally, Is There Such A Thing As Too Scalable?

Sometimes It Is About the Hardware

Medium is the New Large in Enterprise

Technorati Tags: F5,MacVittie,F5 Friday,vCMP,virtualization,BIG-IP,scalability,network,hardware,blog

The Potential Ramifications of Platform-Based Vulnerabilities on Cloud Computing

Lori MacVittie — Wed, 08 Feb 2012 13:26:00 GMT

#infosec #adcfw #cloud Alternate title: How to take out an entire PaaS cloud with one vulnerability

Apache Killer.

Post of Doom.

What do these two vulnerabilities have in common? Right, they’re platform-based vulnerabilities. Meaning they are vulnerabilities peculiar to the web or application server platform upon which applications are deployed. Mitigations for such vulnerabilities generally point to changes in configuration of the platform – limit post size, header value sizes, turn off some value in the associated configuration.

But they also have something else in common – risk. And not just risk in general, but risk to cloud providers whose primary value is in offering not just a virtual server but an entire, pre-integrated and pre-configured application deployment stack. Think LAMP, as an example, and providers like Microsoft (Azure) and VMware (CloudFoundry), more commonly adopting the moniker of PaaS. It’s an operational dream to have a virtual server pre-configured and ready to go with the exact application deployment stack needed and offers a great deal of value in terms of efficiency and overall operational investment, but it is – or should be – a security professional’s nightmare. It’s not unlike the recent recall of Chevy Volts – a defect in the platform needs to be mitigated. The only way to do it, for car owners, is to effectively shut down their ability to drive while a patch is applied. It’s disruptive, it’s expensive (you still have to get to work, after all), and it’s frustrating for the consumer. For the provider, it’s bad PR and negatively impacts the brand. Neither of which is appealing.

A vulnerability in the application stack, in the web or application server, can be operationally devastating to the provider – and potentially disruptive to the consumer whether the vulnerability is exploited or not.

STANDARDIZATION is a DOUBLE-EDGED SWORD

Assume a homogeneous cloud environment offering an application stack based on Microsoft ASP. Assume now an exploit, oh say like Post of Doom, is discovered whose primary mitigation lies in modifying the configuration of each and every instance. Virtualization of any kind provides a solution, of course, but introduces the possibility of disruption in the impact to consumer applications from the configuration change. A primary mitigation for the Post of Doom is to limit the size of data in a POST to under 8MB. Depending on the application, this has to potential to “break” application functionality, particularly those for which uploading big data is a focus. Images, video, documents, etc… These all may be impacted negatively, disrupting applications and angering consumers.

Patching, of course, is preferred, as it eliminates the underlying vulnerability without potentially breaking applications. But patching takes time – time to develop, time to test, time to deploy. The actual delivery of such patches in a PaaS environment is a delicate operation. You can’t just shut the whole cloud down and restart it after the patches are applied to the base images, can you? Do you wait, quiesce the vulnerable images and only force the patched ones when new instances are provisioned? A configuration-based mitigation, too, has these same issues. You can’t just shut down the whole cloud, apply the change, and reboot.

It’s a delicate balance of security versus availability that must struck for the provider, and certainly their position in such cases is one not to be envied. Damned if they do, damned if they don’t.

Then there is the risk of exploitation before any mitigation is applied. If I want to wreak havoc on a PaaS, I may be able to accomplish simply by finding one with the appropriate platform vulnerable to a given exploit, and attack. Cycling through applications deployed in that environment (easily identified at the network layer by the IP ranges assigned to the provider) should result in a wealth of chaos being wrought. The right vulnerability could take out a significant enough portion of the environment to garner attention from the outages caused.

Enterprise organizations that think they are immune from such issues should think again, as even a cloud provider is often not as standardized on a single application platform as an enterprise is, and it is that standardization that is at the root of the potential risk from platform-based vulnerabilities. Standardization, commoditization, these are good things in terms of many financial and operational benefits, but they can also cause operational risk to increase.

MITIGATE in the MIDDLE

There is a better solution, a better strategy, a better operational means of mitigating platform-based risks.

This is where the role of a flexible, broad-spectrum layer of security applies. One that enables security professionals to broadly apply security policies to quickly mitigate potentially disastrous vulnerabilities. Without disrupting a single running instance, an organization can deploy a mitigating solution that detects and prevents the effects of such vulnerabilities. Applying security policies that mitigate such vulnerabilities before they reach the platform is critical to preventing a disaster of epic (and newsworthy) proportions.

Whether stop gap or a permanent solution, by leveraging the application delivery tier of any data center – enterprise or cloud provider – such vulnerabilities can be addressed without imposing harsh penalties on applications and application owners, such as requiring complete shutdown and reboots.

Leveraging such a flexible data center tier insulates the platform from exploitation while insulating customers from the disruption required to mitigate immediately on the platform layer, allowing time to redress through patches or, at least, understand the potential implication to the application from the platform configuration changes required to mitigate the vulnerability.

In today’s data center, time is perhaps the biggest benefit afforded to IT by any solution, and yet the one least likely to be provided. A flexible application delivery tier capable of mitigating threats across the network and application stack without disruption is one of the few solutions available that offers the elusive and very valuable benefit of time. Providers and enterprises alike need to consider their current data center architecture and whether it supports the notion of such a dynamic tier. If not, it’s time to re-evaluate and determine whether a strategic change of direction is necessary to ensure the ability of operations and security teams to address operational risk as quickly and efficiently as possible.

Connect with Lori: Connect with F5:



Related blogs & articles:

At the Intersection of Cloud and Control…

The Full-Proxy Data Center Architecture

The Pythagorean Theorem of Operational Risk

The Future of Cloud: Infrastructure as a Platform

Infrastructure Architecture: Whitelisting with JSON and API Keys

If Security in the Cloud Were Handled Like Car Accidents

VU#903934 – Post of Doom

F5 Friday: Zero-Day Apache Exploit? Zero-Problem

Technorati Tags: F5,MacVittie,security,architecture,availability,cloud computing,virtualization,devops,threat mitigation,application delivery,blog

1024 Words: Honey IT Badger Don’t Care

Lori MacVittie — Tue, 07 Feb 2012 18:24:05 GMT

The reaction in IT when there’s something wrong with a core router is to avoid disruption and its associated costs to the business.

The reaction in IT when a user has problems is to embrace disruption and its associated costs to the business.

There’s something wrong with this model.

Thanks, I know VMware tote a 3:1 Desktop/Thin Client ratio in terms of support burden, i.e. one engineer can service 100 fat clients or 300 thin clients (in user terms). Would you say that this is realistic?

I have a school district with 3 tech's who support 5k devices. Its powerful. 90% of problems can be finished with "log out, login get a new desktop".

-- SpiceWorks, Virtualization Adoption Thread

Connect with Lori: Connect with F5:



Technorati Tags: 1024 Words,MacVittie,honey badger,IT,VDI,reboot,productivity,blog

Desktop VDI May Be Ready for Prime Time but Is the Network?

Lori MacVittie — Mon, 06 Feb 2012 12:20:00 GMT

#VDI #quasar #mobile The proliferation of mobile devices is pushing VDI closer to being “the solution” of the year to resolve the increasing complexity – and costs – associated with consumerization.

Considering the innate differences between just the two most popular mobile operating systems – Android and iOS – gives rise to understanding how costly and complex an infrastructure might need to be to support both. It’s not at all unlike the issues with server virtualization. Management and delivery architectures require different solutions depending on the platform, so despite potentially costly investments to scale, organizations are often staying single-vendor with respect to its virtualization platform strategy.

Organizations had taken that approach – standardized on a single mobile platform – only to discover that employees blatantly ignored such mandates and began using whatever they brought from home. Worse, they expected support when applications didn’t work quite right.

Thus IT is stuck trying to figure out how to efficiently deliver, secure, and manage applications to multiple operating systems right now. Not tomorrow, not next week. Today.

VDI is thus rearing its head as a viable solution; one that promises consistency regardless of platform, without worry about Bob wanting to access corporate resources via his Internet-enabled HDTV. For the most part, experts and implementers deem VDI ready to meet the challenge. But what they haven’t asked, nor considered, is whether the network is ready for VDI.

Desktop Virtualization Ready for Prime Time

The appeal of VDI remains the same: it improves flexibility, simplifies administration and boosts security. What has changed are ongoing price drops and a growing need to seamlessly manage an IT infrastructure that includes desktops running Windows, Mac laptops using Apple OS X and mobiles devices using iOS and Android. In many cases, VDI streamlines data exchange and accessibility in an increasingly bring-your-own device (BYOD) IT world.

VDI OFFLOADS the PROBLEMS to the INFRASTRUCTURE

Interestingly enough, the problems with delivering applications to multi-endpoint environments do not actually disappear with the introduction of VDI. Oh, the problem of supporting every device under the sun is neatly resolved, but other problems quickly arise, and these are not necessarily easy problems to solve.

Roaming

The issue with roaming isn’t just that of a device roaming across service boundaries or WiFi networks, it’s roaming geographically. VDI deployments carry with them some strict and often constraining infrastructure requirements that are not easily overcome without the assistance of infrastructure. Typical network environments are ill-prepared to deal with not just the basic constraints but the resolution to those constraints. They lack the flexibility of an application delivery tier to mediate between roaming users and virtual desktop infrastructure.

A user that roams between two completely different network types may in fact appear to be two different network users from an IP perspective. While we know we must one day eliminate our dependency on IP addressees, today it remains a factor that must be addressed. Users who suddenly move from one network to another may cause undue stress along the entire infrastructure – but especially on VDI servers that maintain their understanding of users based on connections, which base their identification on IP addresses. A mediating connectivity layer such as an application delivery tier eliminates not the dependency, but the impact on the actual VDI servers and applications by becoming the endpoint and handling the possible volatility in device identification on behalf of the services, mitigating the impact by absorbing and managing it itself.

Network Impact on Performance

What, exactly, is the network over which the mobile device is connecting? Is it WiFi? Is it the mobile network? The network over which a device is connecting has a significant impact on performance, particularly from the perspective of the end-user. It isn’t so much a question of whether or not the network is fat enough, it’s whether or not the external (read: out of IT control) network is fat enough, or fast enough.

Latency is the biggest concern among networking pros considering a VDI deployment, according to an informal survey of 1,197 VMworld 2010 attendees conducted by storage vendor Xiotech and WAN optimization vendor Silver Peak. The vendors say 62% of respondents named latency as their top VDI network consideration.
A minority named other WAN-related issues as concerns, such as the ability to shape or prioritize traffic (7%) and bandwidth (6%).

-- VDI over the WAN: How latency affects virtual desktop performance

While WAN Optimization and similar technologies can certainly address issues when a WAN is involved, it won’t necessarily be of assistance when mobile devices experience issues over WiFi or mobile networks or any configuration in which there is no control over both endpoints. Yet the same network problems will plague these devices, and likely with more frequency than remote desktops over IT controlled WAN channels.

Scale of Dependent and Primary Services

Likely the most overlooked of all is the scalability of dependent network services. Simple things like NAT, like application access control, like network security infrastructure that must deal with the possibility that users will be logged in from several places at the same time, trying to access different resources. It’s the scalability of network security devices that suddenly must contend with connections coming from a wide variety of networks and locations, and must decide – quickly – which of those connections will be allowed, and which should – and must – be denied.

It’s also about the ability of applications themselves to scale when faced with suddenly very different network profiles that significantly impact the capacity and load on existing services. Applications that have performed well with capacity X suddenly perform poorly even though concurrent user counts have not changed. This is because the network characteristics may have changed in such a way as to change the way in which the applications are served. Users connecting over the LAN are able to receive content quickly and thus reduce the overall burden on server infrastructure by clearing queues and releasing connections that can be used by other users. Users connecting over mobile networks are not able to receive content as quickly and thus increase the burden on server infrastructure by receiving content more slowing and taking more time to complete a session. This reduces the capacity of server infrastructure and may require additional scaling to ensure consistent, acceptable performance levels across all device types and users.

Thus, while VDI may be ready for prime-time, and is certainly a valid solution to the problem of consumerization with respect to mobile device proliferation in the enterprise, the network may not be ready for VDI – regardless of endpoint form factor.

VDI, like server virtualization and cloud computing , will necessarily change the way in which we architect and ultimately view the network because of the very characteristics that make these technologies appealing – abstraction, elasticity, dynamism. These characteristics make it more difficult to deliver applications and services like VDI because of the volatility and diversity they introduce into the data center and impose on the network.

New architectural and technological solutions will be required in the network to manage such issues as they arise.

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: A Single Namespace to Rule Them All

WILS: The Importance of DTLS to Successful VDI

F5 Friday: The Dynamic VDI Security Game

Mobile versus Mobile: An Identity Crisis

WILS: WPO versus FEO

The Magic of Mobile Cloud

Fire and Ice, Silk and Chrome, SPDY and HTTP

The Mobile Chimera

Technorati Tags: F5,MacVittie,mobile,VDI,virtualization,scalability,performance,network,optimization,blog

F5 Friday: New Services from F5 Ease Migration and Upgrades

Lori MacVittie — Fri, 03 Feb 2012 13:14:00 GMT

I get by with a little help from my friends…

While cloud and virtualization primarily focus on improving the provisioning process, there is a lot more to managing a data center and its critical components than just deployment. There’s upgrades – both software and hardware – and migration to new solutions as well as tweaking knobs and buttons to optimize and troubleshoot issues. While public cloud computing may alleviate much of the pain associated with forward movement, private and hybrid environments as well as traditional data center models must face the reality of dealing with these admittedly often tedious tasks.

It’s a foregone conclusion that new technology and devices like mobile, tablets, unified application delivery and cloud computing as well as an evolving threat spectrum put pressure on IT to maintain a healthy and modern set of services to ensure availability, performance, and security. As pressures increase on infrastructure services, vendors respond with new and or updated solutions to help IT combat the growing complexity of data center architectures.

But sometimes, IT needs a little help from its friends to get there, and that’s where professional service organizations enter into the picture.

One of F5’s top priorities is a world-class service organization. From implementation and ongoing support to migration and upgrades, our professional services organization continues to evaluate the technology landscape and address the most pressing issues facing IT through new offerings designed to ease those pain points introduced by a need to upgrade or migrate to new platforms.

New Services Offerings from F5

F5 is introducing three new services offerings that address many of these issues. Each assessment covers four phases: planning, analysis, a detailed report, and review with recommendations.

BIG-IP Local Traffic Manager (LTM) Upgrade Assessment

Understand Your Infrastructure’s Readiness for Change

The flexible infrastructures made possible by BIG-IP LTM can drive efficiencies, support business growth, and optimize new capabilities that become available as the infrastructure devices evolve. Nonetheless, version upgrades require planning and analytical validation that new functionality will align with the organization’s infrastructure vision.

The BIG-IP LTM configuration is assessed in four broad categories:

Platform, including current TMOS release level, device health, network configuration, and system monitoring and management

Availability, including HA configuration, active/standby preferences, network redundancy, connection mirroring, and persistence settings

Performance, including optimized service profiles, CPU throughput, simple F5 iRules scripting, virtual server types, and health monitors

Security, including secure socket layer (SSL) cipher strengths, port lockdown settings, and administrative access configurations

Firepass to BIG-IP Access Policy Manager (APM) Migration Assessment

Migrate to BIG-IP APM for Faster, Flexible Access

The rapid proliferation of mobile devices, an increasingly dispersed workforce, and the need to secure and optimize content delivery combine to make high-performance, high-concurrency remote access solutions crucial to organizations. Migrating now from a FirePass device to BIG-IP APM ensures your applications remain fast, secure, and available. BIG-IP APM provides a flexible, high-performance access and security solution within an agile infrastructure that will position your organization to effectively support today’s mobile workforce.

The F5 Professional Services consultant reviews your current FirePass configuration and conducts a high-level design discussion to understand the target architecture requirements for meeting your organization’s remote access needs. The configuration review includes analysis of web services, landing URIs, authentication method, certificates, master and resource groups, and network, portal, and application access.

Proactive Assessment

Assess Your F5 Infrastructure Agility

An F5 Proactive Assessment Service audits your F5® BIG-IP® products to ensure optimal configuration. Specifically, the Proactive Assessment Service reviews your current environment to uncover potential issues or areas for improvement and makes recommendations that help optimize F5 technologies. The result is an action plan designed to boost your BIG-IP platform performance, strengthen security, and increase availability.

Network configuration is assessed with a comprehensive review of infrastructure characteristics in five categories:

Operating system, including hotfix level and consistency within products and across BIG-IP device high-availability (HA) pairs

Architecture, including virtual servers, pools, network address translation, and address resolution protocol (ARP) settings

Security, including password policy, authentication methods, and network forwarding

Availability, including fail-over, mirroring, HA configuration, health monitors, and backup policies

Performance, including CPU performance graphs, memory consumption, and throughput

Another great self-service resource can be found in iHealth, which enables you to verify the proper operation of your BIG-IP system and ensure your hardware and software function at peak efficiency. New to iHealth is a comparison feature that can assist with assessments as well as troubleshooting. iHealth requires registration, but is a free service from F5 designed to ease the support process as well as providing organizations with the means to self-support when desired.

Additional Resources:

F5 Professional Services

F5 Professional Services Data Sheet

iHealth Overview

BIG-IP iHealth Data Sheet

F5 Security Vignette: iHealth

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Security Vignette: iHealth

And Now, A Word About iHealth

Need a Little Help Deploying IPv6? We’ve Got Your Back

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

F5 Friday: Platform versus Product

F5 Friday: Engineering, Experience, and Bacon?

Technorati Tags: F5,F5 Friday,MacVittie,professional Services,BIG-IP,LTM,APM,iRules,iHealth,blog

The Cloud API is Pseudo-Consolidation of Infrastructure

Lori MacVittie — Wed, 01 Feb 2012 13:00:00 GMT

It’s about operational efficiency and consistency, emulated in the cloud by an API to create the appearance of a converged platform

In most cases, the use of the term “consolidation” implies the aggregation (and subsequently elimination) of like devices. Application delivery consolidation, for example, is used to describe a process of scaling up infrastructure that often occurs during upgrade cycles. Many little boxes are exchanged for a few larger ones as a means to simplify the architecture and reduce the overall costs (hard and soft) associated with delivering applications. Consolidation.

But cloud has opened (or should have opened) our eyes to a type of consolidation in which like services are aggregated; a consolidation strategy in which we layer a thin veneer over a set of adjacent functionalities in order to provide a scalable and ultimately operationally consistent experience: an API. A cloud API consolidates infrastructure from an operational perspective. It is the bringing together of adjacent functionalities into a single “entity.” Through a single API, many infrastructure functions and services can be controlled – provisioning, monitoring, security, and load balancing (one part of application delivery) are all available through the same API. Certainly the organization of an API’s documentation segments services into similar containers of functionality, but if you’ve looked at a cloud API you’ll note that it’s all the same API; only the organization of the documentation makes it appear otherwise.

This service-oriented approach allows for many of the same benefits as consolidation, without actually physically consolidating the infrastructure. Operational consistency is one of the biggest benefits.

OPERATIONAL CONSISTENCY

The ability to consistently manage and monitor infrastructure through the same interface – whether API or GUI or script – is an important factor in data center efficiency. One of the reasons enterprises demand overarching data center-level monitoring and management systems like HP OpenView and CA and IBM Tivoli is consistency and an aggregated view of the entire data center.

It is no different in the consumer world, where the consistency of the same interface greatly enhances the ability of the consumer to take advantage of underlying services. Convenience, too, plays a role here, as a single device (or API) is ultimately more manageable than the requirement to use several devices to accomplish the same thing. Back in the day I carried a Blackberry, a mobile phone, and a PDA – each had a specific function and there was very little overlap between the two. Today, a single “smart”phone provides the functions of all three – and then some. The consistency of a single interface, a single foundation, is paramount to the success of such consumer devices. It is the platform, whether consumers realize it or not, that enables their highly integrated and operationally consistent experience.

The same is true in the cloud, and ultimately in the data center. Cloud (pseudo) consolidates infrastructure the only way it can – through an API that ultimately becomes the platform analogous to an iPhone or Android-based device.

Cloud does not eliminate infrastructure, it merely abstracts it into a consolidated API such that the costs to manage it are greatly reduced due to the multi-tenant nature of the platform. Infrastructure is still managed, it’s just managed through an API that simplifies and unifies the processes to provide a more consistent approach that is beneficial to the organization in terms of hard (hardware, software) and soft (time, administration) costs.

The cloud and its requisite API provide the consolidation of infrastructure necessary to achieve greater cost savings and higher levels of consistency, both of which are necessary to scale operations in a way that makes IT able to meet the growing demand on its limited resources.

Connect with Lori: Connect with F5:



Related blogs & articles:

BFF: Complexity and Operational Risk

The Pythagorean Theorem of Operational Risk

At the Intersection of Cloud and Control…

Cloud Computing and the Truth About SLAs

IT Services: Creating Commodities out of Complexity

What is a Strategic Point of Control Anyway?

The Battle of Economy of Scale versus Control and Flexibility

Technorati Tags: F5,MacVittie,cloud,cloud computing,API,architecture,mobile,operational consistency,blog

Performance in the Cloud: Business Jitter is Bad

Lori MacVittie — Mon, 30 Jan 2012 12:46:00 GMT

#fasterapp #ccevent While web applications aren’t sensitive to jitter, business processes are.

One of the benefits of web applications is that they are generally transported via TCP, which is a connection-oriented protocol designed to assure delivery. TCP has a variety of native mechanisms through which delivery issues can be addressed – from window sizes to selective acks to idle time specification to ramp up parameters. All these technical knobs and buttons serve as a way for operators and administrators to tweak the protocol, often at run time, to ensure the exchange of requests and responses upon which web applications rely. This is unlike UDP, which is more of a “fire and forget” protocol in which the server doesn’t really care if you receive the data or not.

Now, voice and streaming video and audio over the web has always leveraged UDP and thus it has always been highly sensitive to jitter. Jitter is, without getting into layer one (physical) jargon, an undesirable delay in the otherwise consistent delivery of packets. It causes the delay of and sometimes outright loss of packets that are experienced by users as pauses, skips, or jumps in multi-media content.

While the same root causes of delay – network congestion, routing changes, time out intervals – have an impact on TCP, it generally only delays the communication and other than an uncomfortable wait for the user, does not negatively impact the content itself. The content is eventually delivered because TCP guarantees that, UDP does not.

However, this does not mean that there are no negative impacts (other than trying the patience of users) from the performance issues that may plague web applications and particularly those that are more and more often out there, in the nebulous “cloud”. Delays are effectively business jitter and have a real impact on the ability of the business to perform its critical functions – and that includes generating revenue.

BUSINESS JITTER and the CLOUD

David Linthicum summed up the issue with performance of cloud-based applications well and actually used the terminology “jitter” to describe the unpredictable pattern of delay:

Are cloud services slow? Or fast? Both, it turns out -- and that reality could cause unexpected problems if you rely on public clouds for part of your IT services and infrastructure.

When I log performance on cloud-based processes -- some that are I/O intensive, some that are not -- I get results that vary randomly throughout the day. In fact, they appear to have the pattern of a very jittery process. Clearly, the program or system is struggling to obtain virtual resources that, in turn, struggle to obtain physical resources. Also, I suspect this "jitter" is not at all random, but based on the number of other processes or users sharing the same resources at that time.

-- David Linthicum, “Face the facts: Cloud performance isn't always stable”

But what the multitude of articles coming out over the past year or so with respect to performance of cloud services has largely ignored is the very real and often measurable impact on business processes. That jitter that occurs at the protocol and application layers trickles up to become jitter in the business process; a process that may be critical to servicing customers (and thus impacts satisfaction and brand) as well as on the bottom line. Unhappy customers forced to wait for “slow computers”, as it is so often called by the technically less adept customer service representatives employed by many organizations, may take to the social media airwaves to express displeasure, or cancel an order, or simply refuse to do business in the future with the organization based on delays experienced because of unpredictable cloud performance.

Business jitter can also manifest as decreased business productivity measures, which it turns out can be measured mathematically if you put your mind to it.

Understanding the variability of cloud performance is important for two reasons:

You need to understand the impact on the business and quantify it before embarking on any cloud initiative so it can be factored in to the overall cost-benefit analysis. It may be that the cost savings from public cloud are much greater than the potential loss of revenue and/or productivity, and thus the benefits of a cloud-based solution outweigh the risks.

Understanding the variability and from where it comes will have an impact and help guide you to choosing not only the right provider, but the right solutions that may be able to normalize or mitigate the variability. If the primary source of business jitter is your WAN, for example, then it may be that choosing a provider that supports your ability to deploy WAN optimization solutions would be an appropriate strategy. Similarly, if the variability in performance stems from capacity issues, then choosing a provider that allows greater latitude in load balancing algorithms or the deployment of a virtual (soft) ADC would likely be the best strategy.

It seems clear from testing and empirical (as well as anecdotal) evidence that cloud performance is highly variable and, as David puts it, unstable. This should not necessarily be seen as a deterrent to adopting cloud services – unless your business is so highly sensitive to latency that even milliseconds can be financially damaging – but rather it should be a reality that factors into your decision making process with respect to your choice of provider and the architecture of the solution you’ll be deploying (or subscribing to, in the case of SaaS) in the cloud.

Knowing is half the battle to leveraging cloud successfully. The other half is strategy and architecture.

I’ll be at CloudConnect 2012 and we’ll discuss the subject of cloud and performance a whole lot more at the show!

Sessions

Connect with Lori: Connect with F5:



Related blogs & articles:

Is Features vs. Performance the New Cloud Battle Line?

On the performance of clouds

Face the facts: Cloud performance isn't always stable

Data Center Feng Shui: Architecting for Predictable Performance

A Formula for Quantifying Productivity of Web Applications

Enterprise Apps are Not Written for Speed

The Three Axioms of Application Delivery

Virtualization and Cloud Computing: A Technological El Niño

Technorati Tags: F5,MacVittie,jitter,cloud,performance,latency,WAN optimization,application delivery,cloud computing,blog

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

Lori MacVittie — Fri, 27 Jan 2012 12:45:00 GMT

#adcfw #infosec F5 is changing the game on security by unifying it at the application and service delivery layer.

Over the past few years we’ve seen firewalls fail repeatedly. We’ve seen business disrupted, security thwarted, and reputations damaged by the failure of the very devices meant to prevent such catastrophes from happening. These failures have been caused by a change in tactics from invaders who seek no longer to find away through or over the walls, but who simply batter it down instead. A combination of traditional attacks – network-layer – and modern attacks – application-layer – have become a force to be reckoned with; one that traditional stateful firewalls are often not equipped to handle. Encrypted traffic flowing into and out of the data center often bypasses security solutions entirely, leaving another potential source of a breach unaddressed. And performance is being impeded by the increasing number of devices that must “crack the packet” as it were and examine it, often times duplicating functionality with varying degrees of success. This is problematic because the resolution to this issue can be as disconcerting as the problem itself: disable security. Seriously. Security functions have been disabled, intentionally, in the name of performance.

IT security personnel within large corporations are shutting off critical functionality in security applications to meet network performance demands for business applications.

SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE

What the company [NSS Labs] found would likely startle any existing or potential customers: three of the six firewalls failed to stay operational when subjected to stability tests, five out of six didn't handle what is known as the "Sneak ACK attack," that would enable attackers to side-step the firewall itself. Finally, according to NSS Labs, the performance claims presented in the vendor datasheets "are generally grossly overstated."

Independent lab tests find firewalls fall down on the job

Add in the complexity from the sheer number of devices required to implement all the different layers of security needed, which increases costs while impairing performance, and you’ve got a broken model in need of repair. This is a failure of the defense in depth strategy; the layered, multi-device (silo) approach to operational security. Most importantly, it’s one that’s failing to withstand attacks.

What we need is defense in breadth – the height of the stack –to assure availability and security using a more intelligent, unified security strategy.

DEFENSE in BREADTH

While it’s really not as catchy as “defense in the depth” the concept behind the admittedly awkward sounding phrase is sound: to assure availability and security simultaneously requires a strong security strategy from the bottom to the top of the networking stack, i.e. the application layer. The ability of the F5 BIG-IP platform to provide security up and down the stack has existed for many years, and its capabilities to detect, prevent, and withstand concerted attacks has been appreciated by its customers (quietly) for some time. While basic firewalling functions have been a part of BIG-IP for years, there are certain capabilities required of a firewall – specifically an ICSA certified firewall – that it didn’t have. So we decided to do something about that.

The result is the ICSA certification of the BIG-IP platform as a network firewall. Combined with its existing

ICSA certification for web application firewall (BIG-IP Application Security Manager) and SSL-TLS VPN 3.0 (BIG-IP Edge Gateway), the BIG-IP platform now supports a full-spectrum security solution in a single, unified system. What is unique about F5’s approach is that the security capabilities noted above can be deployed on BIG-IP Application Delivery Controllers (ADCs)—best known for providing industry-leading intelligent traffic management and optimization capabilities. This firewall solution is part of F5’s comprehensive security architecture that enables customers to apply a unified security strategy. For the first time in the industry, organizations can secure their networks, data, protocols, applications, and users on a single, flexible, and extensible platform: BIG-IP.

Combining network-firewall services with the ability to plug the hole in modern security implementations (the application layer) with a platform-based solution provides the opportunity to consolidate security services and leverage a shared infrastructure platform resulting in a more comprehensive, strategic deployment that is not only more secure, but more cost effective.

Resources:

The Fundamental Problem with Traditional Inbound Protection

The Ascendancy of the Application Layer Threat

ISCA Certified Network Firewall for Data Centers

Mature Security Organizations Align Security with Service Delivery

BIG-IP Data Center Firewall Solution – SlideShare Presentation

The New Data Center Firewall Paradigm – White Paper

Connect with Lori: Connect with F5:



Related blogs & articles:

Independent lab tests find firewalls fall down on the job

SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE

F5 Friday: When Firewalls Fail…

Challenging the Firewall Data Center Dogma

What We Learned from Anonymous: DDoS is now 3DoS

The Many Faces of DDoS: Variations on a Theme or Two

F5 Friday: Eliminating the Blind Spot in Your Data Center Security Strategy

F5 Friday: Multi-Layer Security for Multi-Layer Attacks

Technorati Tags: MacVittie,F5,F5 Friday,firewall,ICSA,security,BIG-IP,network,application security,DDoS,threat mitigation,blog

The reaction in IT when there’s something wrong with a core router is to avoid disruption and its associated costs to the business.	The reaction in IT when a user has problems is to embrace disruption and its associated costs to the business.