Monitoring/Management

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:

Connect with Lori:	Connect with F5:

Related blogs & articles:

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

F5 Friday: Creating a DNS Blackhole. On Purpose

Lori MacVittie — Fri, 06 Jan 2012 12:32:00 GMT

#infosec #DNS #v11 DNS is like your mom, remember? Sometimes she knows better.

Generally speaking, blackhole routing is a problem, not a solution. A route to nowhere is not exactly a good thing, after all. But in some cases it’s an approved and even recommended solution, usually implemented as a means to filter out bad packets at the routing level that might be malformed or are otherwise dangerous to pass around inside the data center.

This technique is also used at the DNS layer as a means to prevent responding to queries with known infected or otherwise malicious sites. Generally speaking, DNS does nothing more than act like a phone book; you ask for an address, it gives it to you. That may have been acceptable through the last decade, but it is increasingly undesirable as it often unwittingly serves as part of the distribution network for malware and other malicious intent.

In networking, black holes refer to places in the network where incoming traffic is silently discarded (or "dropped"), without informing the source that the data did not reach its intended recipient.

When examining the topology of the network, the black holes themselves are invisible, and can only be detected by monitoring the lost traffic; hence the name.

(http://en.wikipedia.org/wiki/Black_hole_(networking))

What we’d like to do is prevent DNS servers from returning addresses for sites which we know – or are at least pretty darn sure – are infected. While we can’t provide such safeguards for everyone (unless you’re the authoritative server for such sites) we can at least better protect the corporate network and users from such sites by ensuring such queries are not answered with the infected addresses.

Such a solution requires the implementation of a DNS blackhole – a filtering of queries at the DNS level. This can be done using F5 iRules to inspect queries against a list of known bad sites and returning an internal address for those that match. What’s cool about using iRules to perform this function is the ability to leverage external lookups to perform the inspection. Sideband connections were introduced in BIG-IP v11 and these connections allow external, i.e. off device, lookups for solutions like this. Such a solution is similar to the way in which you’d want to look up the IP address and/or domain of the sender during an e-mail exchange, to validate the sender is not on the “bad spammer” lists maintained by a variety of organizations and offered as a service.

Jason Rahm recently detailed this solution as architected by Hugh O’Donnel, complete with iRules, in a DevCentral Tech Tip. You can find a more comprehensive description of the solution as well as the iRules to implement in the tech tip.

v11.1: DNS Blackhole with iRules

Happy (DNS) Routing!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,DNS,routing,blackhole,network,iRules,architecture,security,context-aware,blog

The Three Axioms of Application Delivery

Lori MacVittie — Wed, 04 Jan 2012 12:04:00 GMT

#fasterapp If you know these three axioms, then you’ll know application delivery when you see it.

Like most technology jargon, there are certain terms and phrases that end up mangled, conflated, and generally misapplied as they gain traction in the wider market. Cloud is merely the latest incarnation of this phenomenon, and there will be others in the future. Guaranteed.

Of late the term “application delivery” has been creeping up into the vernacular. That could be because cloud has pushed it to the fore, necessarily. Cloud purports to eliminate the “concern” of infrastructure and allows IT to focus on … you guessed it, the application. Which in turn means the delivery of applications is becoming more and more pervasive in the strategic vocabulary of the market.

But like cloud and its predecessors, the term application delivery is somewhat vague and without definition. I am not going to define it, in case you were wondering, because quite frankly I’ve watched its expansion and transformation over the past decade and understand that application delivery is not static. As new technology and deployment models arise, new techniques and architectures must also arise to meet the challenges that naturally arise along with those applications.

But how, then, do you know what is and is not application delivery? If it can morph and grow and transform with time and technology, then anything can be considered application delivery, right?

Not entirely. Application delivery, after all, is about an end-to-end process. It’s about a request that is sent to an application and subsequently fulfilled and returned to the originator of the request. Depending on the application this process may be simple or exceedingly complex, requiring authentication, logging, verification, interaction of multiple services and, one hopes, a wealth of security services ensuring that what is delivered is what was intended and desired, and is not carrying along something malicious.

A definition comprising these concepts would be either be far too broad so as to be meaningless, or so narrow that it left no room to adapt to future technologies. Neither is acceptable, in my opinion. A much better way to understand what is (and conversely what is not) application delivery is to learn three simple axioms that define the core concepts upon which application delivery is based.

APPLICATION-CENTRIC

“Applications are not servers, hypervisors, or operating systems.”

Applications are not servers. They are not the physical or virtual server upon which they are deployed and from where they draw core resources. They are not the web and application servers on which they rely for application-layer protocol support. They are not the network stack from which they derive their IP address or TCP connection characteristics. They are uniquely separate entities that must be managed individually.

The concrete example of this axiom in action is health-monitoring of applications. Too many times we see load balancing services configured with health-checking options that are focused on IP or TCP or HTTP parameters. Ping checks, TCP half-open checks, HTTP status checks. None of these options are relevant to whether or not the application is available and executing correctly. A ping check assures us the network is operating and the OS is responding. A TCP half-open check tells us network stack is operating properly. An HTTP status check tells us the web or application server is running and accepting requests. But none of these even touches on whether or not the application is executing and responding correctly.

Similarly, applications are not ports, and security services must be able to secure the application, not merely its operating environment. Applications are not – or should not – be defined by their network characteristics, and neither should they be secured based on these parameters.

Applications are not servers, hypervisors, or operating systems. They are individual entities that must be managed individually, from a performance, availability, and security perspective.

MITIGATE OPERATIONAL RISK

“Availability, performance, and security are not separate operational challenges.”

In most IT organizations the people responsible for security are not responsible for performance or availability, and vice-versa. While devops tries to bridge the gap between applications and operations-focused professionals, we may need to intervene first and unify operations. These three operational concerns are intertwined, they are interrelated, they are paternal triplets. A DDoS attack is security, but it has – or likely will have – a profound impact on both performance and availability. Availability has an impact on performance, both positive and negative. And too often performance concerns result in the avoidance of security that can ultimately return to bite availability in the derriere.

Application delivery recognizes that all three components of operational risk are inseparable, and they must be viewed as a holistic concern. Each challenge should be addressed with the others in mind, and with the understanding that changes in one will impact the others.

OPERATE WITHIN CONTEXT

“Application delivery decisions cannot be made efficiently or effectively in a vacuum.”

Finally, application delivery recognizes that decisions regarding application performance, security, and availability cannot be made within a vacuum. What may improve performance for a mobile client accessing an application over the Internet may actually impair performance for a mobile client accessing the application over the internal data center network. What is appropriate authentication methods for a remote PC desktop are unlikely to be applicable to the same user requesting access over a smartphone. The various components of context provide the means by which the appropriate policies are enforced and applied at the right time to the right client for the right application.

It is context that provides the unique set of parameters that enfolds any given request. We cannot base decisions solely on user, because user may migrate during the day from one client device to another, and one location to another. We cannot base decisions solely on device, because network conditions and type may change as the user roams from home to the office and out to lunch, moving seamlessly between mobile carrier network and WiFi. We cannot base decisions solely on application, because the means and location of the client may change its behavior and impact delivery in a negative way.

When you put these axioms into action, the result is application delivery. A comprehensive, holistic and highly strategic approach to delivering applications. It is impossible to say application delivery is these five products delivered as a solution because whether or not those products actually comprise an application delivery network depends on whether or not they are able to deliver on the promise of these three axioms of application delivery.

Connect with Lori: Connect with F5:

Related blogs & articles:

The Pythagorean Theorem of Operational Risk

DevOps. It’s in the Culture, Not Tech.

Ecosystems are Always in Flux

The Impossibility of CAP and Cloud

Who In The World Are You?

Operational Risk Comprises More Than Just Security

At the Intersection of Cloud and Control…

IT Services: Creating Commodities out of Complexity

What is a Strategic Point of Control Anyway?

Technorati Tags: F5,MacVittie,application delivery,application delivery axioms,performance,security,availability,operational risk,architecture,platform,context-aware,blog

Ecosystems are Always in Flux

Lori MacVittie — Mon, 28 Nov 2011 12:27:00 GMT

#devops An ecosystem-based data center approach means accepting the constancy of change…

It is an interesting fact of life for aquarists that the term “stable” does not actually mean a lack of change. On the contrary, it means that the core system is maintaining equilibrium at a constant rate. That is, the change is controlled and managed automatically either by the system itself or through the use of mechanical and chemical assistance.

Sometimes, those systems need modifications or break (usually when you’re away from home and don’t know it and couldn’t do anything about it if you did anyway but when you come back, whoa, you’re in a state of panic about it) and must be repaired or replaced and then reinserted into the system. The removal and subsequent replacement introduces more change as the system attempts to realign itself to the temporary measures put into place and then again when the permanent solution is again reintroduced.

A recent automatic top-off system failure reminded me of this valuable lesson as I tried to compensate for the loss while waiting for a replacement. This 150 gallon tank is its own ecosystem and it tried to compensate itself for the fluctuations in salinity (salt-to-water ratio) caused by a less-than-perfect stop-gap measure I used while waiting a more permanent solution. As I was checking things out after the replacement pump had been put in place, it occurred to me that the data center is in a similar position as an ecosystem constantly in flux and the need for devops to be able to automate as much as possible in a repeatable fashion as a means to avoid incurring operational risk.

PROCESS is KEY

The reason my temporary, stop-gap measure was less than perfect was that the pump I used to simulate the same auto-top off process was not the same as the one used by the failed pump. The two systems were operationally incompatible. One monitored the water level and automatically pumped fresh water into the tank as a means to keep the water level stable while the other required an interval based cycle that pumped fresh water for a specified period of time and then shut off. To correctly configure it meant determining the actual flow rate (as opposed to the stated maximum flow rate) and doing some math to figure out how much water was actually lost on daily basis (which is variable) and how long to run the pumps to replace that loss over a 24 hour period.

Needless to say I did not get this right and it had unintended consequences. Because the water level increased too far it caused a siphon break to fail which resulted in even more water being pumped into the system, effectively driving it close to hypo-salinity (not enough salt in the water) and threatening the existence of those creatures sensitive to salinity levels (many corals and some invertebrates are particularly sensitive to fluctuations in salinity, among other variables).

The end result? By not nailing down the process I’d opened a potential hole through which the stability of the ecosystem could be compromised. Luckily, I discovered it quickly because I monitor the system on a daily basis, but if I’d been away, well, disaster may have greeted me on return.

The process in this tale of near-disaster was key; it was the poor automation of (what should be) a simple process.

This is not peculiar to the ecosystem of an aquarium, a fact of which Tufin Technologies recently reminded us when it published the results of a survey focused on change management. The survey found that organizations are acutely aware of the impact of poorly implemented processes and the (often negative) impact of manual processes in the realm of security:

66% of the sample felt their change management processes do or could place the organization at risk of a breach. The main reasons cited were lack of formal processes (56%), followed by manual processes with too many steps or people in the process (29%).

-- Tufin Technologies Survey Reveals Most Organizations Believe Their Change Management Processes Could Lead to a Network Security Breach

DEVOPS is CRITICAL to MAINTAINING a HEALTHY DATA CENTER ECOSYSTEM

The Tufin survey focused on security change management (it is a security focused organization, so no surprise there) but as security, performance, and availability are intimately related it seems logical to extrapolate that similar results might be exposed if we were to survey folks with respect to whether or not their change management processes might incur some form of operational risk.

One of the goals of devops is to enable successful and repeatable application deployments through automation of the operational processes associated with a deployment. That means provisioning of the appropriate security, performance, and availability services and policies required to support the delivery of the application. Change management processes are a part of the deployment process – or if they aren’t, they should be to ensure success and avoid the risks associated with lack of formal processes or too many cooks in the kitchen with highly complex manually followed recipes. Automation of configuration and policy-related tasks as well as orchestration of accepted processes is critical to maintaining a healthy data center ecosystem in the face of application updates, changes in security and access policies, as well as adjustments necessary to combat attacks as well as legitimate sudden spikes in demand.

More focus on services and policy as a means to not only deploy but maintain application deployments is necessary to enable IT to continue transforming from its traditional static, manual environment to a dynamic and more fluid ecosystem able to adapt to the natural fluctuations that occur in any ecosystem, including that of the data center.

Connect with Lori: Connect with F5:



Related blogs & articles:

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

The Future of Cloud: Infrastructure as a Platform

The Secret to Doing Cloud Scalability Right

Operational Risk Comprises More Than Just Security

Technorati Tags: F5,MacVittie,ecosystem,architecture,devops,security,performance,availability,automation,cloud,virtualization,orchestration,services,Tufin,blog

The Pythagorean Theorem of Operational Risk

Lori MacVittie — Wed, 23 Nov 2011 13:49:00 GMT

#devops It’s a simple equation, but one that is easily overlooked.

Most folks recall, I’m sure, the Pythagorean Theorem. If you don’t, what’s really important about the theorem is that any side of a right triangle can be computed if you know the other sides by using the simple formula a² + b² = c². The really important thing about the theorem is that it clearly illustrates the relationship between three different pieces of a single entity. The lengths of the legs and hypotenuse of a triangle are intimately related; variations in one impact the others.

Operational risk – security, availability, performance – are interrelated in very much the same way. Changes to one impact the others. They cannot be completely separated. Much in the same way unraveling a braided rope will impact its strength, so too does unraveling the relationship between the three components of operational risk impact its overall success.

The OPERATIONAL RISK EQUATION

It is true that the theorem is not an exact match, primarily because concepts like performance and security are not easily encapsulated as concrete numerical values even if we apply mathematical concepts like Gödel numbering to it. While certainly we could use traditional metrics for availability and even performance (in terms of success at meeting specified business SLAs), still it would be difficult to nail these down in a way that makes the math make sense.

But the underlying concept - that it is always true* that the sides of a right triangle are interrelated is equally applicable to operational risk.

Consider that changes in performance impact what is defined as “availability” to end-users. Unacceptably slow applications are often defined as “unavailable” because they render it nearly impossible for end-users to work productively. Conversely, availability issues can negatively impact performance as fewer resources attempt to serve the same or more users. Security, too, is connected to both concepts, though it is more directly an enabler (or disabler) of availability and performance than vice-versa. Security solutions are not known for improving performance, after all, and the number of attacks directly attempting to negate availability is a growing concern for security. So, too, is the impact of attacks relevant to performance, as increasingly application-layer attacks are able to slip by security solutions and directly consume resources on web/application servers, degrading performance and ultimately resulting in a loss of availability.

But that is not to say that performance and availability have no impact on security at all. In fact the claim could be easily made that performance has a huge impact on security, as end-users demand more of the former and that often results in less of the latter because of the nature of traditional security solutions impact on performance.

Thus we are able to come back to the theorem in which the three sides of the data center triangle known as operational risk are, in fact, intimately linked. Changes in one impact the other, often negatively, and all three must be balanced properly in a way that maximizes them all.

WHAT DEVOPS CAN DO

Devops plays (or could and definitely should play) a unique role in organizations transforming from their traditional, static architectures toward the agile, dynamic architectures necessary to successfully execute on cloud and virtualization strategies. The role of devops focuses on automation and integration of the various delivery concerns that support the availability, performance, and security of applications. While they may not be the ones that define and implement security policies, they are the ones that should be responsible for assuring they are deployed and applied to applications as they move into the production environment. Similarly, devops may not be directly responsible for defining availability and performance requirements, but they are the ones that must configure and implement the appropriate health monitoring and related policies to ensure that all systems involved have the data they need to make the decisions required to meet operational requirements. Devops should be responsible for provisioning the appropriate services related to performance, security, and availability based on their unique role in the emerging data center model.

Devops isn’t just scripts and automation; it’s a role requiring unique skillset spanning networking, development, application delivery, and infrastructure integration. Devops must balance availability, performance, and security concerns and understand how the three are interrelated and impact each other. The devops team should be the ones that recognize gaps or failures in policies and are able to point them out, quickly.

The interrelationship between all three components of operational risk puts devops front and center when it comes to maintaining application deployments. Treating security, performance, and availability as separate and isolated concerns leads to higher risks that one will negatively impact the other. Devops is the logical point at which these three concerns converge, much in the same way application delivery is the logical data center tier at which all three concerns converge from a services and implementation point of view. Devops, like application delivery, has the visibility and control necessary to ensure that the three sides of the operational risk triangle are balanced properly.

* In Euclidian geometry, at least. Yes, other systems exist in which this may not be true, but c’mon, we’re essentially applying Gödel numbers to very abstract metrics and assuming axioms that have never been defined let alone proven so I think we can just agree to accept that this is always true in this version of reality.

Connect with Lori: Connect with F5:



Related blogs & articles:

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

The Future of Cloud: Infrastructure as a Platform

The Secret to Doing Cloud Scalability Right

Operational Risk Comprises More Than Just Security

Technorati Tags: F5,MacVittie,operational risk,security,performance,availability,devops,application delivery,architecture,blog

The Secret to Doing Cloud Scalability Right

Lori MacVittie — Wed, 09 Nov 2011 12:40:00 GMT

Hint: The answer lies in being aware of the entire application context and a little pre-planning

Thanks to the maturity of load balancing services and technology, dynamically scaling applications in pre-cloud and cloud computing environments is a fairly simple task. But doing it right – in a way that maintains performance while maximizing resources and minimizing costs well, that is not so trivial a task unless you have the right tools.

SCALABILITY RECAP

Before we can explain how to do it right, we have to dig into the basics of how scalability (and more precisely auto-scalability) works and what’s required to scale not only dynamically.

A key characteristic of cloud computing is scalability, or more precisely the ease with which scalability can be achieved.

Scalability and Elasticity via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads.

-- Wikipedia, “Cloud Computing”

When you take this goal apart, what folks are really after is the ability to transparently add and/or remove resources to an “application” as needed to meet demand. Interestingly enough, both in pre-cloud and cloud computing environments this happens due to two key components: load balancing and automation.

Load balancing has always been used to scale applications transparently. The load balancing service provides a layer of virtualization in the network that abstracts the “real” resources providing the application and makes many instances of that application appear to be a single, holistic entity. This layer of abstraction has the added benefit of allowing the load balancing service to see both the overall demand on the “application” as well as each individual instance. This is important to cloud scalability because a single application instance does not have the visibility necessary to see load at the “application” layer, it sees only load at the application instance layer, i.e. itself.

Visibility is paramount to scalability to maintain efficiency of scale. That means measuring CAP (capacity, availability, and performance) both at the “virtual” application and application instance layers. These measurements are generally tied to business and operational goals – the goals upon which IT is measured by its consumers. The three are inseparable and impact each other in very real ways. High capacity utilization often results in degrading performance, availability impacts both capacity and performance, and poor performance can in turn degrade capacity. Measuring only one or two is insufficient; all three variables must be monitored and, ultimately, acted upon to achieve not only scalability but efficiency of scale. Just as important is flexibility in determining what defines “capacity” for an application. In some cases it may be connections, in other CPU and/or memory load, and in still others it may be some other measurement. It may be (should be) a combination of both capacity and performance, and any load balancing service ought to be able to balance all three variables dynamically to achieve maximum results with minimum resources (and therefore in a cloud environment, costs).

WHAT YOU NEED TO KNOW BEFORE YOU CONFIGURE

There are three things you must do in order to ensure cloud scalability is efficient:

1. Determine what “capacity” means for your application. This will likely require load testing of a single instance to understand resource consumption and determine an appropriate set of thresholds based on connections, memory and CPU utilization. Depending on what load balancing service you will ultimately use, you may be limited to only viewing capacity in terms of concurrent connections. If this is the case – as is generally true in an off-premise cloud environment where services are limited – then ramp up connections while measuring performance (be sure to read #3 before you measure “performance”). Do this multiple times until you’re sure you have a good average connection limit at which performance becomes an issue.

2. Determine what “available” means for an application instance. Try not to think in simple terms such as “responds to a ping” or “returns an HTTP response”. Such health checks are not valid when measuring application availability as they only determine whether the network and web server stack are available and responding properly. Both can be true yet the application may be experiencing troubles and returning error codes or bad data (or no data). In any dynamic environment, availability must focus on the core unit of scalability – the application. If that’s all you’ve got in an off-premise cloud load balancing service, however, be aware of the risk to availability and pass on the warning to the business side of the house.

3. Determine “performance” threshold limitations for application instances. This value directly impacts the performance of the virtual application. Remember to factor in that application responses times are the sum of the time it takes to traverse from the client to the application and back. That means the application instance response time is only a portion, albeit likely the largest portion, of the overall performance threshold. Determine the RTT (round trip time) for an average request/response and factor that into the performance thresholds for the application instances.

WHY IS THIS ALL IMPORTANT

If you’re thinking at this point that it’s not supposed to require so much work to “auto-scale” in cloud computing environments, well, it doesn’t have to. As long as you’re willing to trade a higher risk of unnoticed failure with performance degradation as well as potentially higher-costs in inefficient scaling strategies, then you need do nothing more than just “let go, let cloud” (to shamelessly quote the 451 Group’s Wendy Nather ).

The reason that ignoring all the factors that impact when to scale out and back down is so perilous is because of the limitations in load balancing algorithms and, in particular in off-premise cloud environments – inability to leverage layer 7 load balancing (application switching, page routing, et al) to architect scalability domains. You are left with a few simple and often inefficient algorithms from which to choose, which impedes efficiency by making it more difficult to actually scale in response to actual demand and its impact on the application. You are instead reacting (and often too late) to individual pieces of data that alone do not provide a holistic view of the application, but rather only limited views into application instances.

Cloud scalability – whether on-premise or off – should be a balancing (pun only somewhat intended) act that maximizes performance and efficiency while minimizing costs. While allowing “the cloud” to auto-scale encourages operational efficiency, it often does so at the expense of performance and higher costs.

An ounce of prevention is worth a pound of cure, and in the case of scalability a few hours of testing is worth a month of additional uptime.

Connect with Lori: Connect with F5:



Related blogs & articles:

Architecturally, Is There Such A Thing As Too Scalable?

Choosing a Load Balancing Algorithm Requires DevOps Fu

It's 2am: Do You Know What Algorithm Your Load Balancer is Using?

Infrastructure Matters: Challenges of Cloud-based Testing

To Boldly Go Where No Production Application Has Gone Before

Load Testing as a Service: A Look at Load Impact (beta)

Layer 7 Switching + Load Balancing = Layer 7 Load Balancing

Cloud Testing: The Next Generation

F5 Application Designer: Health Based Load Balancing

Impact of Load Balancing on SOAPy and RESTful Applications

Load Balancing in a Cloud

Technorati Tags: F5,MacVittie,scalability,cloud computing,performance,availability,efficiency,operations,load testing,application switching,load balancing

F5 Friday: Secure Remote Access versus En Masse Migration to the Cloud

Lori MacVittie — Fri, 04 Nov 2011 12:16:00 GMT

Being too quick to shout “cloud” when the solution may be found elsewhere can lead to unintended consequences.

As with all technology caught up in the hype cycle, cloud computing is often attributed with being “the solution” to problems irrespective of reality. Cloud is suddenly endowed with supernatural powers, able to solve every business and operational challenge merely by being what it is.

Take, for example, the attribution of cloud as being “the solution” to the very real issue of severe snow in the UK.

Cloud solutions can help businesses to overcome severe weather issues – with your business’ IT in the cloud, 100 percent of your staffs could work from home. Moreover, working in the cloud – anywhere, anytime – is good for your employees’ morale: 76 percent said that off-premise working is great.

http://www.thecloudinfographic.com/2011/10/27/cloud-computing-solves-severe-snow-problem.html

Now, the premise of this “solution” is that severe snow often prevents employees from working because they can’t get to work or because they lack the means to do so. Given. The claim is that putting IT in “the cloud” (narrowly defined as Software as a Service only) eliminates these issues because employees can access the cloud from anywhere, including their homes during periods of severe weather.

One wonders why employees cannot simply access the same applications and resources at their corporate location. Has the business no Internet connectivity? Have they no web applications? Are they, perhaps, the last holdouts against the electronic age? The real solution here has nothing to do with cloud, it is enabling remote access. Cloud computing as part of the strategy to enable that solution is certainly valid, but it isn’t the solution, it’s part of a strategy – a remote access strategy.

OPERATIONAL CONSISTENCY

The reason touting “cloud” as a the “solution” to snow-bound employee access is somewhat misguided is twofold. First, it completely ignores the need for enterprise-grade security. Simply put “IT” (as if one can move an enterprise-grade data center wholesale) in the cloud and voila! Instant, ubiquitous, access. Granted, the purported solution is SaaS, which implies some level of credentials are required for access, but in doing so it completely ignores the second issue: it assumes all IT functions are commoditized to the point they are offered “as a service” in the first place, which is utterly untrue at this point in the evolution of any kind of cloud.

This conflation further dismisses the costs and importance of integration to those systems being “moved” en masse to the cloud, and seems not at all concerned with the operational management costs of now needing to manage not one but perhaps multiple cloud environments. As my toddler would say, “Are you seriously?”

Interestingly, before cloud computing came along and became the answer to life, the universe and everything, there was a less disruptive solution to the problem of remote access and business continuity: secure remote access.

One of the foremost capabilities provided by secure remote access solutions, like BIG-IP Access Policy Manager (APM), is that of supporting telecommuting. Having been a telecommuter for over a decade now I’ve never had access to corporate resources without the assistance of some kind of remote access (VPN) solution.

There are simply too many pieces and parts (resources and applications and services) that are too sensitive to leave unprotected “in the cloud.” Now that’s not saying a cloud isn’t secure, it’s saying that it’s not (currently) enabled with the same level of security and support for secure access best practices required by both operational and business stakeholders.

I absolutely agree with the premise that severe weather and other mitigating factors that prevent employees from getting to work is costly to the business. But the solution is not likely to be a wholesale migration of its data center to a cloud, it’s to enable remote access without disrupting existing security and access policies. The bonus is that using BIG-IP APM can actually enable a migration of applications or services to a cloud environment without sacrificing the control necessary to consistently replicate and enforce access policies.

CLOUD is FOR EVERYONE but NOT for EVERYTHING

“Cloud is for everyone, but not for everything.” (Rackspace ) That is especially true in this case, but even more so when folks are conflating a solution with its model and location because it fails to address the root cause and instead tries to force fit “cloud” as being an integral part of every solution to every IT challenge.

Cloud is not a solution, but a deployment option that has both advantages and disadvantages over traditional data center-based deployments. While the issue with severe weather is certainly real, claiming “cloud” is a solution is shortsighted and fails to recognize the difficulties inherent in such an “en masse” migration. Unfortunately the reply of “cloud” as though it’s answer D (all of the above) to every operational and business challenge we encounter will continue to be an issue until the hype cycle finally tires of hearing itself talk and we can get down to the real business of exploiting “the cloud” in ways that are not only meaningful but that do not introduce myriad other (costly and potentially risk inducing) challenges.

In this case, a secure remote access solution – BIG-IP Access Policy Manager – is a much better option for folks who are annually plagued by productivity and cost woes due to severe weather. Rather than transplant applications from the data center to a cloud, and likely losing in the process the control and enforcement of security and access policies necessary to comply with regulations and business requirements, enable secure remote access. Keep the control, leverage the flexibility, maximize the benefits.

Happy Working from Home!

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: Mitigating the THC SSL DoS Threat

F5 Friday: The Art of Efficient Defense

F5 Friday: How Can I Manage Thee? Let Me Count the Ways…

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

F5 Friday: The Gap That become a Chasm

This is Why We Can’t Have Nice Things

All F5 Friday Posts on DevCentral

Technorati Tags: F5,MacVittie,F5 Friday,secure remote access,cloud,telecommuting,BIG-IP,APM,Access Policy Manager,operational consistency,architecture,security

F5 Friday: Cookie Cutter vApps Realized

Lori MacVittie — Fri, 21 Oct 2011 12:34:00 GMT

An architectural solution to the challenge of IP-address dependency.

A rarely mentioned obstacle when attempting to duplicate or migrate enterprise-class applications is IP-dependency. Not just topological dependencies that are easily addressed with dynamic routing and switching protocols in conjunction with a boot script, but internal dependencies – the ones so deeply embedded in the application’s “identity” that to change the IP address is to break the installation and render it useless.

These are the applications that, upon asking for an exported image for testing purposes, virtualization experts will tell you is far more efficient to start from scratch, because the IP dependency issue will cause more trouble in the long term than simply starting over. Moving such an application to a public cloud is nearly impossible due to this restriction, and any bursting or data center extension model is out of the question. This is also a problem locally, when attempting to build out a private cloud and IT services. particularly in production environments in which a multi-tenant model is employed by launching multiple instances of the same application with each designated for use by a specific logical group, i.e. a department, project, or business unit.

Ultimately what we want is the ability to create cookie cutter applications as a foundational element for IT as a Service. This requires network, security, and application policies – as well as the application – be encapsulated as templates, associated with the application, and applied on a per instance. This ultimately enables application instance sizing and chargeback per logical group, and lays the foundation for push-button IT services in which a department can be one click away from an automated deployment of an application.

What’s standing in the way in many cases is the IP address dependency. Applications can’t be packaged up neatly into a holistic service along with its requisite network, security, and delivery policies because all of these services are tightly bound to the IP address of the application – and vice-versa. When an application is deployed if it is reassigned a new IP address, every policy will also need to be updated, making the process not only lengthy but fraught with potential for misconfiguration due to stalls or human error.

The dependency on IP addresses within these applications is not going away. To achieve the goal of a more mobile and service-focused data center then, we need is a way to work around the problem. Many see VMware vApps as the solution. But while vApps were designed with mobility and portability in mind, it does not address the IP address dependency obstacle.

A solution to this seemingly unsolvable problem can be found in a collaborative architecture incorporating both global and local application delivery services.

A COLLABORATIVE F5–VMWARE ARCHITECTURAL SOLUTION

To avoid complexity in multi-DC topologies (and ultimately inter-cloud deployments), it is necessary to reduce the need for coordination between different teams by abstracting network addressing, rules and service names. Bridging networks is not enough – an application and protocol specific approach is needed. VLAN stretching approaches do not differentiate traffic ingress and egress for each datacenter. This means that application traffic can enter one datacenter, traverse the bridged network to the application in the other datacenter, and then return following the same path. As the distance between data centers increases (as is desired for disaster recovery purposes), this “trombone routing” incurs heavy performance penalties due to latency. What we want is not single valid addresses for applications across datacenters, but rather, portable addresses which can then be selected by a global abstraction based on best-path and best-performance for a given client in the context of their locality and the available resources in each datacenter.

Such an architecture is made possible by a rarely mentioned but very powerful feature of BIG-IP systems: route domains.

Route domains give you the ability to segment (isolate) network traffic for different applications on the network. The BIG-IP system can process traffic for each application within its own route domain. Because route domains segment network traffic they can also be used to assign the same IP address or subnet to more than one node on a network. Two nodes on the network can have the same IP address as long as each instance of the IP address resides in a separate routing domain.

The ability to essentially duplicate IP address space in the same environment opens up the ability to create cookie cutter vApps complete with the appropriate network, security, and delivery policies required – an isolated operationally consistent deployment. The problem then becomes ensuring that the right users are routed to the right application instance at the right time.

Using a phased implementation, IT organizations can resolve the issues that prevent the repeatable deployment of enterprise applications locally and globally.

PHASE 1

The focus of phase 1 is the elimination of re-addressing applications at the IP layer in multi-site deployments. This phase relies on BIG-IP Local Traffic Manager (LTM) and in particular route domains to allow the co-existence of architectures utilizing the same IP address space, and BIG-IP Global Traffic Manager (GTM) to determine which site is currently in use as the primary data center.

In an active-standby deployment, this provides site-resilience by ensuring a secondary site is available to assume responsibility for delivering applications in the event of an outage at the primary site. In an active-active deployment, BIG-GTM leverages context shared by the local application delivery controller, BIG-IP LTM, to ensure better performance and availability without sacrificing fault tolerance.

This deployment pattern is based on existing, proven global architectures providing site-resilience and location-based global load balancing.

PHASE 2

This phase also relies on BIG-IP Local Traffic Manager (LTM) and route domains to allow the co-existence of architectures utilizing the same IP address space. Context-awareness is leveraged as a means to properly route users to their designated application deployment. The context can be extracted from the URI or from other variables associated with the user, such as credentials or cookies.

Multiple instances of the application architecture can be launched and co-exist within the data center, each serving a particular logical group. Each group can size applications based on usage needs, and chargeback per department becomes a less complex accounting process as it is based on the instance and its supporting architectural components. Application architectures can be successfully repeated at the logical group level, enabling a smoother transition to IT as a Service and preserving the IP-address dependencies on which many applications rely.

ARCHITECTURE is KEY

As is increasingly the case, the solution to many of the challenges arising from multi-site, cloud computing , and highly virtualized data centers is architectural. Because the challenges often span data center domains – security, networking, storage, compute, and applications – the solution requires cross-domain collaboration, not just of teams but of infrastructure.

Cloud computing really is an exercise in infrastructure integration. By leveraging the strengths and capabilities of various data center components across various domains, solutions can be architected to address even the seemingly unsolvable problems that will continue to frustrate IT as it moves toward a more distributed and highly dynamic data center.

Connect with Lori: Connect with F5:



Related blogs & articles:

All F5 Friday Posts on DevCentral

F5 Friday: A Single Namespace to Rule Them All

F5 Friday: Secure, Scalable and Fast VMware View Deployment

WILS: The Importance of DTLS to Successful VDI

Simplify VMware View Deployments

F5 Friday: The Dynamic VDI Security Game

Enable Single Namespace for VMware View Deployments

Simplify VMware View Deployments with BIG-IP APM for LTM VE

F5 and VMware Solution Guide

Virtualization and Cloud Computing Group on DevCentral

Technorati Tags: F5,F5 Friday,MacVittie,route domains,networking,GSLB,BIG-IP GTM,BIG-IP LTM,load balancing,disaster recovery,IT as a Service,VMware,vApps

F5 Friday: Engineering, Experience, and Bacon?

Lori MacVittie — Fri, 07 Oct 2011 11:16:00 GMT

#iApp #v11 If you were wondering what these three things have to do with F5, read on …

What has a strange sense of humor, an unhealthy love of bacon and donuts, and has held a wide variety IT roles and responsibilities for a whole lot of years?

If you were said “the F5 Product Management Engineering team” give yourself a cookie (or better yet some bacon).

The question is, why should you care?

To understand that, you first have to understand the role that “PME” has within F5. Many of the solutions F5 offers are based not only on the group’s effort and experiences, but many are the product of that effort and those experiences. If you ever wondered who was beyond our Application Ready Solutions (detailed, step-by-step application-focused deployment guides) now you have your answer: it’s PME. Our most recent release of BIG-IP, v11, also brought with it iApp. A key facet of iApp is the portability of iApp templates and scripts, especially with respect to the ability of F5 and its customers to share existing iApp implementations. The iApp packages that come from F5 after many months of development, collaboration with partners, and lots of testing are almost unilaterally created by? You got it, PME.

That’s why it was particularly exciting to see Karen Jester, who manages the Product Management Engineering team, begin blogging. If you were looking for insight and an expert voice on iApp – from technical details to business benefits – then Karen’s recently launched blog will definitely be right up your alley.

She’s kicked off a series of blog posts on iApp that are definitely worth a read. What’s also helpful is that she’s putting iApp into the context of the BIG-IP system as a whole. After all, iApp isn’t a disconnected technology – it’s part of a larger ecosystem that makes up the F5 control plane comprising application, data, and management. These interconnects and integrations are an important aspect of BIG-IP in general, as it offers operational consistency across a multitude of architectures and environments, ultimately enabling the dynamic data center and IT as a Service.

Give Karen’s posts a read, bookmark her blog or subscribe to the feed. You won’t be disappointed with the insight and information that someone who’s inside – both the technology and the organization – can provide.

Karen Jester’s iApp Blog Series:

iApp – What is it?

iApp–How they help business

iApp–Benefits

iApp–Full Application Lifecycle Management

Connect with Lori: Connect with F5:



Related blogs & articles:

All iApp related posts

All v11 related posts

All F5 Friday posts

iApp Wiki

iApp Codeshare

F5 iApp: Moving Application Delivery Beyond the Network

iApp Information

Technorati Tags: F5,MacVittie,F5 Friday,iApp,v11,Karen Jester,PME,BIG-IP,automation,IT as a Service,dynamic data center

Live Migration versus Pre-Positioning in the Cloud

Lori MacVittie — Mon, 03 Oct 2011 12:22:00 GMT

The secret to live migration isn’t just a fat, fast pipe – it’s a dynamic infrastructure

Very early on in the cloud computing hype cycle we posited about different use cases for the “cloud”. One that remains intriguing and increasingly possible thanks to a better understanding of the challenges associated with the process is cloud bursting. The first time I wrote about cloud bursting and detailed the high-level process the inevitable question that remained was, “Well, sure, but how did the application get into the cloud in the first place?”

Back then there was no good answer because no one had really figured it out yet.

Since that time, however, there have grown up many niche solutions that provide just that functionality in addition to the ability to achieve such a “migration” using virtualization technologies. You just choose a cloud and click a button and voila!

Yeah. Right. It may look that easy, but under the covers there’s a lot more details required than might at first meet the eye. Especially when we’re talking about live migration.

LIVE MIGRATION versus PRE-POSITIONING

Many architectural-based cloud bursting solutions require pre-positioning of the application. In other words, the application must have been transferred into the cloud before it was needed to fulfill additional capacity demands on applications experiencing suddenly high volume. It assumed, in a way, that operators were prescient and budgets were infinite. While it’s true you only pay when an image is active in the cloud, there can be storage costs associated with pre-positioning as well as the inevitable wait time between seeing the need and filling the need for additional capacity. That’s because launching an instance in a cloud computing environment is never immediate. It takes time, sometimes as long as ten minutes or more. So either your operators must be able to see ten minutes into the future or it’s possible that the challenge for which you’re implementing a cloud bursting strategy (handle overflow) won’t be addressed by such a challenge.

Enter live migration. Live migration of applications attempts to remove the issues inherent with pre-positioning (or no positioning at all) by migrating on-demand to a cloud computing environment and maintaining at the same time availability of the application. What that means is the architecture must be capable of:

Transferring a very large virtual image across a constrained WAN connection in a relatively short period of time

Launch the cloud-hosted application

Recognize the availability of the cloud-hosted application and somehow direct users to it

When demand decreases you must siphon users off (quiesce) the cloud-hosted application instance

When no more users are connected to the cloud-hosted application, take it down

Reading between the lines you should see a common theme: collaboration. The ability to recognize and act on what are essentially “events” occurring in the process require awareness of the process and a level of collaboration traditionally not found in infrastructure solutions.

CLOUD is an EXERCISE in INFRASTRUCTURE INTEGRATION

Sound familiar? It should. Live migration, and even the ability to leverage pre-positioned content in a cloud computing environment, is at its core an exercise in infrastructure integration. There must be collaboration and sharing of context, automation as well as orchestration of processes to realize the benefits of applications deployed in “the cloud.” Global application delivery services must be able to monitor and infer the health at the site level, and in turn local application delivery services must monitor and infer the health and capacity of the application if cloud bursting is to successfully support the resiliency and performance requirements of application stakeholders, i.e. the business.

The relationship between capacity, location, and performance of applications is well-known. The problem is pulling all the disparate variables together from the client, application, and network components which individually hold some of the necessary information – but not all. These variables comprise context, and it requires collaboration across all three “tiers” of an application interaction to determine on-demand where any given request should be directed in order to meet service level expectations. That sharing, that collaboration, requires integration of the infrastructure components responsible for directing, routing, and delivering application data between clients and servers, especially when they may be located in physically diverse locations.

As customers begin to really explore how to integrate and leverage cloud computing resources and services with their existing architectures, it will become more and more apparent that at the heart of cloud computing is a collaborative and much more dynamic data center architecture. That without the ability not just to automate and orchestrate, but integrate and collaborate infrastructure across highly diverse environments, cloud computing – aside from SaaS - will not achieve the successes it is predicted.

Connect with Lori: Connect with F5:



Related blogs & articles:

Cloud is an Exercise in Infrastructure Integration

IT as a Service: A Stateless Infrastructure Architecture Model

Cloud is the How not the What

Cloud-Tiered Architectural Models are Bad Except When They Aren’t

Cloud Chemistry 101

You Can’t Have IT as a Service Until IT Has Infrastructure as a Service

Cloud Computing Making Waves

All Cloud Computing Posts on DevCentral

Technorati Tags: F5,MacVittie,cloud computing,integration,cloud bursting,architecture,dynamic data center,live migration,virtualization,infrastructure 2.0