|
|
|
 |
|
 |
 |
|
|
|
Scaling applications that include AJAX and non-AJAX components may require more than just tuning your web server A common problem after deploying a Web 2.0 AJAX-based application shows itself through poor performance or lower capacity on the server, often both. Web serving tuning is almost always the first step in improving performance and capacity, but the inherently competing behavior of AJAX-requests and “normal” HTTP requests quickly becomes problematic as well. Tune for the AJAX requests and performance of regular old HTTP requests suffers. Tune for regular old HTTP requests, and performance of AJAX-requests suffer. This is primarily because of the way in which the client-side application, the browser, interacts with the server. “Regular old HTTP requests” are typically those that GET a piece of content, static or dynamic, and that’s it. There may be many of these requests whenever a page (URI) is requested – all the images, client-side scripting files, style sheets, etc… – but they are not interactive. The browser requests them, receives them, and that’s it. AJAX-based requests, however, are inherently interactive. They are often automatically refreshed on an ongoing basis, on a prescheduled interval, or invoked by the user as they interact with the application. These requests are not “load and forget” like their traditional staticesque counterparts, but rather they are expected to be made often. The overhead associated with opening and closing connections is well understood, and it is often the case that the web server configuration will be adjusted to meet the more demanding nature of the AJAX-based requests in an application. This is often accomplished by ensuring the KeepAlive setting (in Apache) is “on” and that the KeepAliveTimeout (in Apache) is high enough that AJAX-based requests occur before the timeout closes the connection. This allows the continued reuse of an existing connection between the browser and the server and improves performance. But it also ties up resources on the server keeping that connection open, which reduces the overall capacity of the server in terms of its ability to serve users. Optimally a short KeepAliveTimeout, if any, is best for non-interactive requests and often disabling KeepAlive actually improves performance for non-interactive applications. Obviously these two behaviors are completely at odds with one another.
SOLUTIONS
There are a number of ways in which the competing needs and interests of the interactive (AJAX) and non-interactive portions of your web application can be addressed.  1. Configure two different servers: one to serve interactive content, i.e. AJAX-based requests, and one to serve non-interactive requests, i.e. everything else. This way, each server can be specifically tuned (and sized) according to the application behavior. This is beneficial for several reasons, including the ability to “scale out/up” only the interactive-serving functions when or if it becomes necessary. This can be achieved simply by using specific host names for specific requests. If you do not have a public IP address that can be assigned to each host, however, you’ll need a proxy, like a Load balancer, to sit in front of the servers and handle the direction of requests appropriately or you could use mod_rewrite to achieve a similar architecture. When a mediating solution like a load balancer is used to implement this solution, there are a several ways to achieve the behavior. One method is to rewrite requests directed at a specific URI, for example: http://www.example.com/ajax/request1.php would be redirected to the server designated as the “interactive” server while other requests would be forwarded to the non-interactive server. An application aware load balancer, i.e. application delivery controller, can examine the request itself and base the same decision on the actual data being exchanged. For example, many AJAX frameworks (XAJAX, SAJAX, Prototype, etc…) often use the HTTP POST method to send a request and use specific parameters such as “xjxfun” to indicate which function is being invoked on the server side. By examining the data being exchanged an application aware proxy (load balancer) can use that information to send the request to the appropriate server.
2. A second means of addressing the problem of resource depletion and performance with AJAX-based applications is to use a load balancing solution to mediate for the clients and employ the use of TCP multiplexing on the server-side to optimize resources. Because a load balancer is almost certainly capable of simultaneously handling a significantly higher  volume of connections than a single web server, the competing behavior of interactive and non-interactive HTTP requests in a web application do not impede performance or impact its capacity. By allowing a load balancer to mediate for those requests, it can better manage the resources on the server and ensure that both capacity and performance are maintained. For every X client connections, the load balancer maintains only a fraction of X connections to the server and reuses them as the means to optimizing the server-side resources. This method is actually likely to increase overall capacity because it will reduce the number of connections required to be in use at any given time on the server(s) and eliminates the performance overhead associated with opening and closing TCP connections. 3. A third solution might be found in scaling up (beefier hardware) and leveraging virtualization. For web applications, specifically, it may be the case that virtualization of the application will actually improve performance. This is particularly true of I/O intensive web applications, but is also likely true of high-connection oriented applications as well. This is because as a web server begins to reach its capacity in terms of connections it requires more processing to “find” a given connection. Nearly all TCP-based applications exhibit similar performance characteristics and, upon reaching a certain threshold of connections, performance degrades. By finding the “sweet spot” ,i.e. the highest number of connections that retains acceptable user response time, and deploying multiple instances of that application, each tuned for that upper bound, it may be possible to squeeze out better performance and higher capacity of your web applications. Multiple instances will require a proxy, i.e. load balancing, solution as well, but this would allow for a “scale up” solution that takes advantage of a single, beefy physical server that eliminates the IT management and maintenance overhead of additional hardware in the data center.
IT’S THE ARCHITECTURE
In all three cases the solution to the problem of competing resource utilization between interactive and non-interactive components of a web application involve architecture. Some might believe that simply moving the application to “the cloud” would address the problems and, in some ways, it will. Cloud computing environments can indeed be managed such that applications are automatically scaled out to maintain performance and increase capacity, but the interesting thing about that is the environments are essentially implementing a combination of the three solutions heretofore presented. The bad news is that such a solution does not optimize resource utilization, and thus the costs associated with a cloud computing solution to the problem may be surprising and even prohibitive depending on your IT budget. And the cloud computing solution, of course, is ultimately also about architecture, as it is the architecture that allows for automated scalability. In most cases involving web applications the answer to scalability challenges is going to end up being architecture, and that architecture is increasingly requiring the use of application network components such as load balancers to implement. This is why it is often advised that applications are architected to take advantage of application networking components from the beginning, even if such solutions will not be necessary to address capacity and optimization on day one. By architecting a solution that includes application networking as part of its design and deployment model, there is far less disruption later when such a solution does become necessary.       
 
Related blogs & articles: Technorati Tags: MacVittie, F5, architecture, web 2.0, virtualization, load balancer, AJAX, apache, mod_rewrite, cloud computing, application delivery, performance, scalability, optimization |
| 0 Comments | Email This | Read More... |
|
|
 |
|
|
|
|
Well, over the weekend one of our NAS boxes – the NetGear – started throwing SMART errors. Yeah, it was telling me that more and more blocks are going bad and we need to do something about it. After due consideration (more below) Lori and I decided to replace it with a lower-end enterprise-class NAS. Now this may sound like odd timing to you, but there’s something I haven’t told you. The NetGear was our tier two because it has a bad channel. It’s been running one disk shy for quite a while, and the problem is with the controller, not the disk – we tried replacing the disk right-off, only to discover that pre-NetGear versions of this box and issues with the first channel on the card. Lose another disk and POOF! No more tier two. So we’re going to make the Seagate BlackArmor our tier two and place a shiny new Dell PowerVault NX3000 into our network. We picked the lowest end model they had that included CIFs, NFS, and ADS support in one box. Funny thing, neither Lori nor I has touched a PowerVault since we had a prototype in the NWC lab back when they were just starting the line up. Should be fun. This is a “for us” thing, F5 isn’t subsidizing it in any way, and really shouldn’t be. Our NAS devices hold our stuff – our written works, pictures, PDFs we’ve purchased, even rips of our CD collection. This box is pretty, and we’re stoked, but with this box there is both good news and bad news… You see, the Dell is a Dell, and it’s an enterprise product, so they don’t have one laying around that they can just ship to us, they have to put the disks in, test, etc. So it’s going to put this series off by another week. The good news is that once the box is here, I can sidetrack writing about configuring it and moving our network around, then we’ll be all set to actually talk about the cool things we hope to achieve with the ARX. Until then though, I won’t be saying much. Let’s face it, I could play with the ARX for the week and tell you about all the switches I toggled, but you’re not going to use the box to play with, you’re going to put it in and tell it to manage your storage. So until I have the environment set such that I can do the same, it makes no sense to write about stuff that is fluff. In short, I’m not going to blog about stuff that doesn’t matter to you just so I can say I’m blogging. So I’ll focus on other topics this week, and then you’ll get a flurry of updates when the new device arrives. The only thing I plan to do between now and then is rip down the ADS server (as in shut it off again), and make sure our Seagate plays nice via NFS, so all is set for this box to take the lead. Oh yeah, and back up both NAS boxes, so I can move the Seagate stuff onto the PowerVault, and the Netgear stuff onto the Seagate. So I guess I’ll be doing routine admin stuff, but nothing worthy of a blog unless something goes wrong and I think I can make you smile by blogging about it. Until then, don’t get NAS-ty, be patient, we’ll be back. Don.  |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
After a week of presentations throughout the Middle East and Europe by Joe & Jeff, I took my turn on the tour, beginning with a  couple days in Johannesburg, South Africa, and finishing up the week with a few stops in Europe as well. Today’s session in Antwerp, Belgium, also featured the iRules Contest grand prize winner in the partner division, Sake Blok, with a fine presentation on writing clean iRules and a walk through of his winning iRule. Oh, and he delivered his presentation from his brand new 17” MacBook Pro—won in the content—just to rub in the fact that I do in fact not have one. Just kidding, Sake. It’s a really nice toy, by the way. Anyway, I believe the presentations were well received (If I’m wrong about that, don’t tell Jeff!) The agenda was fairly broad spread, covering in part: - iRules & iControl basics
- Advanced iRules tips & tricks
- Case studies on iRules from some of this year’s iRules Contest winners
- Case study on a similarly functional iControl script written both in Powershell & Python for comparison
- New v10.1 features, including geolocation, tmsh scripting, the table command, etc.
Among Joe, Jeff, myself, and the hundreds of partners and end-users we met with these past two weeks, we have great feedback on product specific things as well as some constructive commentary on how DevCentral can be improved. To that end, we’re working feverishly in the shadows on deliver some improvements and new functionality to the DevCentral community. Stay tuned…  |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
We worry about VM sprawl but what about device sprawl? Management of a multitude of network-deployed solutions can be as operationally inefficient as managing hundreds of virtual machines, and far more detrimental to the health and performance of your applications. Turning them all into virtual network appliances that might need scaling themselves? That’s even badder. But all you hardware fanbois best not smirk too much because the proliferation of hardware network devices is only slightly less badder than the potential problems arising from virtual network appliance sprawl.
WAIT, WHY IS DEVICE SPRAWL BAD AGAIN?
All the same reasons cited by various pundits since the virtualization craze began regarding the difficulties associated with virtual machine sprawl can be applied to virtual network appliance sprawl. For the most part it applies to hardware network device sprawl, too, for that matter. 1. Cost of IPAM (IP Address Management) This is probably even worse than is often described by Greg Ness when it’s applied to network solutions as compared to virtual machines simply because most network solutions have at least two IP addresses assigned to them – one for management and one to do its job – if not more. There are exceptions, of course, as some solutions are deployed inline and transparently, but there are other challenges associated with such configurations as they often require port mirroring which effectively ties the solution to a specific port on a specific switch. Obviously moving it or scaling it out horizontally as a virtual machine would prove problematic for these solutions. So let’s just ignore those for the purposes of this discussion, shall we? 2. The impact on performance Ignoring scalability – let’s assume a virtual network appliance is equal to the task for this post – the more points at which requests/traffic must stop and be processed the more latency is incurred. If you string together enough devices – regardless of the physical implementation – you are going to degrade performance. In some cases by a few milliseconds, in others perhaps by seconds. The amount of degradation relies heavily on the volume of requests, the type of processing being performed, and the capacity of each network device. Remember that the network is only as fast as its slowest hop, and that one poorly performing network device can destroy network and application performance. 3. Cost of management, power, and training If you deploy five different network devices to address five different needs, you incur the cost of management, power, and training for each of them. This is true regardless of physical implementation as moving a solution from hardware to a virtual appliance doesn’t change the fact that it (1) needs to be managed, (2) has an interface/commands/quirks that need to be learned, and (3) consumes power. 4. Trouble with Troubleshooting (a.k.a. Lack of Visibility) Even if every one of the X network solutions you have deployed individually has great visibility you’re still going to run into trouble troubleshooting. That’s because what one device may or may not do to a request/traffic isn’t easy to correlate by the time it’s passed through the fifth or sixth network device. It’s not as if all these devices add metadata that describes what they did to the traffic, they just do it and pass it along. The more devices, the more complicated this process becomes. 5. Special Issue with Virtual Network Appliances: Distributed Management Remember how you didn’t want to shell out the extra cash for the vendor-specific distributed management solution? If you’re scaling out a network solution via multiple virtual network appliances you may want to reconsider that decision. Once you get past a couple of instances you’re going to need something to help you manage them and keep their configurations in synch or you’re asking for trouble. And don’t forget about the hypervisor management system, too. You’ll need that, I’m sure. Sprawl of any kind incurs costs per node at a fairly consistent rate. Every instance – physical or virtual – adds to the combined total cost of ownership and investment in time. Every device through which traffic must flow also incurs a performance penalty, which to the business stakeholder is probably more dangerous than the hit on your budget.
UNIFIED APPLICATION DELIVERY INFRASTRUCTURE
Unified application delivery infrastructure can’t completely eliminate every other network device because generally speaking some network devices aren’t focused on application delivery but are instead wholly focused on network security or compliance or business functions that really have very little to do with managing networks or delivering applications. Yeah, I know. Surprised me too when I found that out. There are actually solutions that aren’t focused on network or application networks. Whodda thunk it?  But for application delivery focused solutions – acceleration, optimization, caching, application security, load balancing – the solution to the problems of network device sprawl are unification onto a single, extensible (modular) platform. And while many network folks hear “modular” and think “chassis” (and that can be one approach) I’m talking about the core system itself. The solution, not the container.
By sharing a common core networking platform, a unified application delivery infrastructure mitigates the problems associated with extra hops/stops in the flow of requests/traffic by eliminating them. Requests that need to be passed through a web application firewall before being passed to a Load balancer do so, but because the common core networking platform is shared there’s no network or network stack overhead incurred by the passing of the data. Network sprawl really is badder than VM sprawl because it not only increases the overall cost to deliver and secure applications but it can also negatively impact the performance and reliability of applications. A unified platform affords choice in the ability to add functionality as needed, to try out functionality to see if it’s worth it, and to scale out in a more efficient way on an as-needed (on-demand) basis. One of the reasons virtualization is so appealing is it addresses nicely the “lots of little boxes” problem that causes management headaches throughout the data center. Consolidation through virtualization was the answer to that one, at least in terms of the sprawl associated with the physical devices. Unified infrastructure addresses the same “lots of little network boxes” problem that causes similar headaches on the network and application network side of the data center by consolidating many of the application delivery focused functions onto a single, shared and extensible application networking platform. Related blogs & articles: Technorati Tags: MacVittie, F5, application delivery, unified application delivery and data services, infrastructure, unfiied infrastructure, application security, caching, acceleration, optimization, load balancing, web, internet, blog, virtualization |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
Well, I’ll bet you’re wondering how it’s going? First, the reasons for my silence that you haven’t heard. Last Thursday my wonderful Dell Latitude D820 died. I loved this machine, thought so much of it that last time I updated my home machine I got a D830. But sadly, it was over three years old, and I spend 8+ hours a day abusing it, so no surprise. The warranty ran out in December, so that left me (IT actually) no option but to replace it. The real reason to include this is to point out to you that F5 IT rocks, and many IT departments could learn from them. I’m a remote worker, I was limping by working on my home machine which had most of what I needed, but some key software like MS Project wasn’t installed, and webmail is… painful in any situation. I told IT the machine was definitely dead late on Tuesday, on Wednesday I had a new machine. With my login info and the licensed corporate software installed. You don’t do any better than that. So they sent me a Latitude E6400, and honestly, I’m pleased as can be. The only little problem I’ve had with it was (so far) not work related. I listen to DVD lectures from The Teaching Company in the evenings while working or painting or writing for non-work, and for some reason my newest set of DVDs plays fine on the machine but doesn’t have sound. Local WMV files play and have sound, the DVDs work on my home machine… So I don’t exactly know what’s going on there, but everything else works perfectly, so I’m happy. I’ll figure out what oddity makes them work on other Dell Machines and not on this one. And I was complaining that I was out of space for VMs… No more! Much larger hard disk. Anyway, you can imagine that getting the machine, pulling the hard disk from my old one (don’t tell IT, I’m not certain they’d approve), hooking up the disk via USB and dumping all the important stuff, reconfiguring just about everything – from bookmarks to networking settings – to work well in my environment sucked up just a bit of my time. On the bright side, the days that I had no machine (it was nearly a week because we’d hoped we could fix the old one, but alas, Dell said “motherboard, fixing is a bad choice”) gave me a chance to get my storage house in order. What did I do? Well I wiped the box running ADS and started over. It had ADS and DNS installed from who-knows-how-long-ago, but it was shut down… So I tried with the installed copies, but wasn’t real confident and it wasn’t working the best. So I wiped the server and reinstalled, set ADS up again, joined my home laptop to the ADS domain, then worked at getting the storage into the domain. One required using the WINS name instead of the domain name to get it to work, the other required that I add it by had to ADS and DNS, and THEN tell the storage to join the domain. And as usually happens in that case, all went well. Finally a chance to join the ARX to the domain. This is something I had not attempted up to that point because I wanted to have the things an ARX requires – storage and users – in ADS so that once it was joined I could get rolling. So I went to join the ARX into the domain… And realized I did not have the faintest idea how to do so.  AD Forest/domain list. RTFM time, so I went and looked. The help on the system I have is very nice, and coworkers tell me that the help on DMOS 5.X is indeed very nice overall. That helped me get rolling, as did the logs, which are very verbose and I cannot recommend enough. In fact, all the oddities I’ve encountered to date – failure to access disks for metadata, failure to connect to shares, failure to negotiate NFS versions… All were ultimately the fault of my storage, and all we ultimately made clear to me via the ARX logs. Lots of logs – and this does not count the automatically generated reports for lots of common activities. 
The Managed Volume created under ADS. One really odd thing I ran into that I am working around by ignoring it – because I can – is that I have a Namespace whose drive mountings failed – a leftover from the work I was doing in NFS and CIFS without Active Directory. It is stuck in the “starting” state, and I can’t get it out. Since the ARX won’t let me delete it, I’m ignoring it for now, and need to look up how to point out to the ARX that it will never finish starting since it has no volumes allocated to it. I’m pretty certain that this is a user error, so don’t judge the ARX poorly, even if it is an ARX error, you can ignore a single Namespace easily enough. Or better, don’t use SMB class storage so you’re not jerking the poor ARX around for three weeks ;-). 
A Virtual defined on the ADS domain Internal. Everything before that last picture that I’ve talked about has been the backend. Now that all the backend pieces were working together, it was time for me to set up the user-facing bit… The Virtual Service. This is the presentation “volume” – where the device advertises the Virtual Directory Tree to the network. It went easy enough on creation and making CIFS exports, and it’s up and running now. The problem I’m stopped at now is another RTFM – I need to join the Virtual to the domain, but haven’t read how – it told me that I needed to and how to do so when I created the exports on the Virtual Service, but it was 3am and I thought “I’ll figure that out later…” And indeed I will, for this blog is long enough, and that’s where I’ll pick up the next installment. Until then, enjoying my new laptop and seeing this all working together. Oh yeah, and I have to make my regular everyday user not be SuperADSMan. I toggled him up to Enterprise ne’er-do-well while testing, and don’t want to forget to make him normal, and create the storage background users I need. More on that next time, when I’m sure what storage background users I want/need. Don.  |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
We seem on the verge of repeating the mistakes associated with failed SOA implementations: ignoring the larger issue of architecture. Everyone – from pundit to public – is asking the same question: “Where are the network virtual appliances?” But fewer people seem to be asking a question that needs to go hand-in-hand with that one: “Where are the architectural guidelines to support deployment of network virtual appliances?” SOA has been deemed by many to be a failure in part because it lacked true architectural guidance. Architects were simply unable – whether by lack of skills or training or lack of support from the rest of the organization – to design an architecture that took advantage of services and thus the result was often little more than “service sprawl.” Services did not scale well, they were not so easy to integrate, and no one really had a good handle on what services were available, and where. Lack of an architectural strategy to accompany a network virtual appliance will likely lead to the same end: network sprawl and a lack of scalability or worse – scalability that’s costly in terms of expenses and resources. Rich Miller, who’ll be joining a panel of other industry notables at Cloud Connect to discuss Infrastructure 2.0 and what’s necessary to successfully move forward with these “new” infrastructures, may have inadvertently pointed out the lack of architectural guidance related to virtual network appliances when he said: If a vendor is going to sell network virtual appliances, the nva's should be designed from the get-go to be scalable (both 'up' and 'out'), and designed with the notion that the 'appliance' is not just a physical appliance without the box. That is 'horseless carriage' product design, which casts new technologies in exactly the same roles as their precursors. What Allan doesn't say is that this may require the wider deployment of network infrastructure designed specifically for virtualized appliances and converged IO. It's not just whitebox, commodity x86 hardware running general purpose virtual machine environments for server virtualization. -- Rich Miller in “Where ARE the Network Virtual Appliances?” Rich is focusing more on internal design in general, but any such “design” must also necessarily include how the VNA scales in the target environment. Scalability is at the heart of all definitions of cloud computing and without the ability to scale solutions – whether application, network, storage, or application network – any such implementation will almost certainly be deemed a failure.
SCALING UP
Scaling up, i.e. vertical scalability, in a cloud computing or virtualized environment is in essence little more than “throwing more hardware” at the problem. Scaling “up” adds more compute resources, yes, but it is not “on-demand” today because it effectively requires re-provisioning of large chunks of resources. Cloud computing and virtualization in particular today are not capable of simply “adding on” more CPU or RAM to a virtual machine and even if it were there are hard, physical limitations imposed by the underlying hardware on the upper bounds of such a strategy. Scaling “up” a virtual network appliance in practice is really no different than scaling up hardware. It leads to over-provisioning by necessity and in the event that capacity and physical constraints are reached, requires provisioning a new, higher capacity instance which while easier than upgrading hardware counterparts still requires much the same process in terms of deployment. While I agree with Rich’s assessment that virtual network appliances should be designed to scale up as efficiently as possible, that doesn’t change the challenges associated with actually scaling up the solution in a dynamic environment or that it’s not all that much different than what we do today to try to future-proof the sizing of solutions.
SCALING OUT
Scaling out, i.e. horizontal scalability, is usually the more desirable choice in these discussions. This makes a great deal more sense even though scaling “out” is still essentially a “throw more hardware at the problem” solution, it’s a more temporary “toss” and is more flexible in terms of growing capacity on-demand. It’s certainly more efficient and agile to deploy another virtual network appliance than it is to acquire and deploy another physical network appliance. The problem with this approach is not in the details. It’s in the broader architectural strategy applied to the process, which today is virtually non-existent. Scaling out is a proven method of addressing capacity constraints. We do it all the time with web and application servers, with firewalls, with XML gateways. load balancing as a method of implementing a  horizontally scalable application and network infrastructure is nothing new and it is indeed efficient, scalable, and architecturally sound. The issue is with how one scales out, and what. The call for “virtual network appliances” in general ignores the architectural implications in favor of some perception of increased flexibility and scalability. There are simply some functions within the data center that would not benefit from being “virtualized” and others that will not benefit without a strong set of architectural guidelines. Some functions should never be virtualized because such an architecture would not be feasible to implement and would do more harm than good to both network and application performance. Let’s take core routing, for example. One of the reasons you’d want to “scale out” a core router is because it has hit an upper constraint on bandwidth. Perhaps it’s only capable of handling 10Gb of aggregate bandwidth entering the data center/cloud computing environment but you need to handle 20 or 30Gb of bandwidth. In a completely virtualized architecture you’d just scale “out” by adding another another virtual router, right? That will certainly increase aggregate bandwidth capacity, but fails to address a very important question: how is traffic directed to one instance or another? Do we have to scale the scalability? And if so, how does that work? Do the core routers deploy in an active-active configuration, both masquerading as the entry point into the data center? Sharing of “bogus” MAC addresses across active-active-n scaling architectures is the most common solution to this problem, but introduces others related to failover and network utilization. That latter piece is due to the natural behavior of switches and reliance on MAC address/port affinity; essentially this solution turns a switch into a giant hub, replicating data/traffic across all possible ports on which the “bogus” MAC address might be. As you scale out, more and more bandwidth will be consumed by this broadcasting behavior and can make troubleshooting more difficult, especially in environments where visibility is already limited such as cloud computing providers.
RIGHT BACK WHERE WE STARTED
Is it the case that every virtual network appliance capable of being “scaled out” will essentially need to be capable of acting like a Load balancer? Because that’s how it looks from here. Horizontal scalability is based on the premise that something – some device, some solution – is load balancing requests/data/traffic across the multiple instances. Without the load balancing solution, such implementations are nearly impossible to achieve. So imagine the potential issue when the load balancer is virtualized, too. It, also, must scale “out” and thus must be “scaled” itself by … a load balancing solution. Such an implementation is certainly achievable, but also requires that the “primary” load balancing solution is scaled “up” in order to handle the aggregate request/data/traffic being directed at the infrastructure. Limitations on vertical scalability return us right back to a solution based on horizontal scalability, which puts us right back here where we are: how do we scale out the “more scalable” virtual network appliances that are so highly in demand?  We haven’t even touched the large problem of sprawl in a virtual network infrastructure. Management systems aren’t quite ready for such an implementation, and ironically part of the reason cloud computing, virtualization, and infrastructure 2.0 are coming of age now is because we have issues with managing an increasing volume of servers, applications, devices, and IP addresses across the data center. Deploying an infrastructure comprised of virtual network appliances without a strong architectural strategy and a supporting management strategy is sheer folly, and puts us no better off than we are today.
We should be very careful to ask ourselves why we want a particular solution in a network virtual appliance and how it might impact the network and management of the network before we blithely toss it into our critical network and application network infrastructure. Architecture is inherently as important when designing any type of distributed system, and when moving from hardware to distributed software as a means to achieve scalability there needs to be more a lot more thought and strategy put into the process. While there are certainly going to evolve architectures that take advantage of virtual network appliances, and traditional hardware appliances, and combinations thereof, we need to tread carefully forward and ensure that our driving desire for what appears to be flexibility doesn’t end up breaking the backbone of the data center: the network. A well-thought planned architectural strategy for integrating virtual network appliances with traditional data center components will go a long way toward ensuring maximum flexibility without stretching the network so tightly that it breaks. Related blogs & articles:  |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
Whether it be due to cloud computing, last year’s economic mess, or just the general cyclical nature of the Tech Industry, Consolidation has been a huge focus of IT departments of late. Data Center consolidation, hardware consolidation, staff consolidation and tech sector consolidation to name a few. I remember the days of single purpose boxes that did one thing well. In fact, a decade ago at Exodus, that was one of my positioning points for BIG-IP over such LB units as Alteon, ArrowPoint and LocalDirector since they were switched/hardware-based appliances. I’d say something like, ‘It’s a Floor Wax and a Dessert Topping while the BIG-IP is software based, focused only on Load Balancing.’ Boy, times have changed. Single purpose appliances, while still big business for their particular specialty, are becoming fewer and fewer – just look at the handheld your using. The printer was one of the first to go that route becoming printer/copier/fax/scanner in an effort to make them more useful and appealing to the customer. Ads tout, ‘No more bulky equipment to buy – it’s all here in this great new thing that you must have!! All for the incredibly low price of…..’ IDS graduated to IPS and now we have IDPS units and UTM (Unified Threat Management) systems or the Next-Gen Firewalls. They have firewall, anti-virus, spam controls, web filter, IDS and more. We are in a multi-task society and expect our devices to behave the same. For a while, adding more and more functionality to a piece of IT equipment would either slow it to a crawl or make it very difficult to troubleshoot. The processing power available today allows multi-function appliances to dedicate resources to ensure all the functions run smoothly.  Having multiple point solutions, interfaces and GUIs also makes it difficult to manage the various entities, especially if it’s a security device. Managing multiple points of entry and enforcing a consistent security policy across the board can be challenging. You got users connecting and requesting application access via VPN, some over the air on Wireless and others hooked right to the LAN. They also are probably using various types of computing devices; from IT issued laptops, to home/personal machines to mobile devices. You might have a specific policy for each type of access method/device or you enforce the same security, no matter what the connection. Why wouldn’t you do a host check on LAN users similar to the scrutiny your remote users must pass? In many cases, that might involve a NAC type controller and I thought we were trying to reduce the number of power suckers in the data center. Today, IT needs a single management interface and policy enforcement point that’s easy to navigate and quick to deploy. During a crisis, like a potential intrusion or breach, you can waste precious time trying to get to all the different appliances to assess the situation.
As consolidation continues, and more functionality is added to these multi-dedicated appliances, management of such an infrastructure especially if it’s part of a cloud, will continue to be an important driver for IT. So, as you consolidate and are able to dedicate, that will enable you to eradicate costs, multiple management interfaces, multiple point products and with the right device, eradicate many of the threats that appear every day, the CDE way! ps Related resources: External articles: Technorati Tags: F5,BIG-IP,v10.1,Edge Gateway,WOM,application delivery,Pete Silva,F5,security,application security,network security  |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
The difference between these two performance metrics is significant so be sure you know which one you’re measuring, and which one you wanted to be measuring. 
It may be the case that you’ve decided that SSL is, in fact, a good idea for securing data in transit. Excellent. Now you’re trying to figure out how to implement support and you’re testing solutions or perhaps trying to peruse reports someone else generated from testing. Excellent. I’m a huge testing fan and it really is one of the best ways to size a solution specifically for your environment. Some of the terminology used to describe specific performance metrics in application delivery, however, can be misleading. The difference between SSL TPS (Transactions per second) and HTTP TPS over SSL, for example, are significant and therefore should not be used interchangeably when comparing performance and capacity of any solution – that goes for software, hardware, or some yet-to-be-defined combination thereof. The reasons why interpreting claims of SSL TPS are so difficult is due to the ambiguity that comes from SSL itself. SSL “transactions” are, by general industry agreement (unenforceable, of course) a single transaction that is “wrapped” in an SSL session. Generally speaking one SSL transaction is considered: 1. Session establishment (authentication, key exchange) 2. Exchange of data over SSL, often a 1KB file over HTTP 3. Session closure Seems logical, but technically speaking a single SSL transaction could be interpreted as any single transaction conducted over an SSL encrypted session because the very act of transmitting data over the SSL session necessarily requires SSL-related operations. SSL session establishment requires a handshake and an exchange of keys, and the transfer of data within such a session requires the invocation of encryption and decryption operations (often referred to as bulk encryption). Therefore it is technically accurate for SSL capacity/performance metrics to use the term “SSL TPS” and be referring to two completely different things. This means it is important that whomever is interested in such data must do a little research to determine exactly what is meant by SSL TPS when presented with such data. Based on the definition the actual results mean different things. When used to refer to HTTP TPS over SSL the constraint is actually on the bulk encryption rate (related more to response time, latency, and throughput measurements), while SSL TPS measures the number of SSL sessions that can be created per second and is more related to capacity than response time metrics. It can be difficult to determine which method was utilized, but if you see the term “SSL ID re-use” anywhere, you can be relatively certain the test results refer to HTTP TPS over SSL rather than SSL TPS. When SSL session IDs are reused, the handshaking and key exchange steps are skipped, which reduces the number of computationally expensive RSA operations that must be performed and artificially increases the results. As always, if you aren’t sure what a performance metric really means, ask. If you don’t get a straight answer, ask again, or take advantage of all that great social networking you’re doing and find someone you trust to help you determine what was really tested. Basing architectural decisions on misleading or misunderstood data can cause grief and be expensive later when you have to purchase additional licenses or solutions to bring your capacity up to what was originally expected. WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND. Related blogs & articles:  |
| 1 Comment | Email This | Read More... |
|
|
|
|
|
|
|
It seems like I blinked and 2009 went by, but in that time I've been working on so many interesting projects at F5, I have a backlog of information to share with the community. The first post this year is about the long distance VMotion with VMWare's ESX system. This is a solution that enables the movement of live running virtual machine hosts from one data center to another. The main problems in routing VMotion between data centers are latency, bandwidth, client traffic and security. In BIG-IP 10.1 we have a solution that compresses, encrypts and shields the ESX servers from prevailing WAN conditions, to enable long distance motion of running hosts. Take a look at the following screencast to see how this works:  In the chart below are some of the typical improvement times we see with long distance VMotion with BIG-IP. When latency goes up, VMotion is often not possible without BIG-IP in place. For example, with 100 ms of round-trip latency, on an OC3, a virtual machine that has one gigabyte of active RAM memory, takes roughly three and a half minutes to migrate across the WAN. If you were to try the same VMotion without BIG-IP in place, it would take more than 13 minutes and only succeed about half the time. I'm excited about the types of architectures that can be enabled with this kind of solution in place. F5 is laying the ground work to make some exciting infrastructures possible Have a look at the F5 deployment guide which describes how to set this solution up and how to architect new solutions across your data centers: http://www.f5.com/pdf/deployment-guides/vmware-vmotion-dg.pdff  |
| 4 Comments | Email This | Read More... |
|
|
|
|
|
|
|
Emerging architectures are conflating responsibilities up and down the application stack. Who is responsible for integration when services reside in the network? While preparing for an upcoming panel I’m moderating at Cloud Connect (in the “New Infrastructure” track), the panelists and I had a great discussion on the topics we wanted to discuss in the session. During that discussion it became increasingly clear that an interesting phenomenon has been occurring: the conflation of network and application  responsibilities in the traditional “stack.” Much of this inversion is absolutely necessary for emerging models of networking and computing to be successful. Traditional methods of handling QoS (Quality of Service) and identity management, for example, are no longer adequate in the inherently volatile world of cloud computing and dynamic networks. Interestingly, the driver behind the inversion appears to be based largely on the ability of specific layers access to context, which is necessarily replacing IP addresses as a method of client – and server – identification.
CLIMBING UP the RABBIT HOLE
Back in the day, QoS was a class of problem unto itself, with an entire market of products and solutions developed specifically to address the challenge of prioritizing traffic. Initially it was thought that the ToS (Terms of Service) bits in the IP header would suffice, but it quickly became obvious that this required every organization and provider to honor those bits as traffic flowed through and across the Internet. Didn’t happen. A market emerged that moved QoS “up the stack” to Layer 4 (transport protocol). A class of devices were deployed that employed either TCP rate shaping or packet queuing technologies to control the amount of bandwidth a given “application” could consume. It quickly became apparent that this method was not robust enough as more and more “applications” began to use the same protocol: TCP. The devices again moved “up the stack” to Layer 7 (application) and began to apply QoS policies based on actually identifying applications based on layer 7 protocols and data characteristics. In recent years even this has become inadequate because these techniques were all focused on limiting, in some way, total bandwidth for an application. While these solutions were also able to, albeit rudimentarily, accomplish rate shaping on a per-user basis, they still focused on bandwidth as their metric of choice to control. Hence a single user could be limited to X Kbps for all HTTP traffic, and further limited to Y percent for application A and Z percent for application B, but bandwidth as a meter of usage for applications today is not an appropriate measurement. Hence, QoS has again moved up the stack and is more granular than ever. Rather than worrying about bandwidth, which has grown increasingly cheap and available for both organizations and users, QoS now concerns itself with limiting requests on a per-user basis and, in some cases, a per-client-type basis. Consider Twitter’s rate limiting implementation for its API. This is a modern implementation of QoS that attempts to equalize access to its services for all users, effectively ensuring a consistent quality of service for everyone. Bandwidth is not a factor, because the amount of bandwidth consumed by any given client is highly variable and based on what data is being requested. Similarly we often see requests for ways in which application usage can be limited based on application layer variables, with nary a mention of bandwidth. It’s always about users and usage patterns of a specific application. What was once a “network” function, QoS, has moved “up the stack” and is now primarily the responsibility of the “application.”
SLIDING DOWN the RABBIT HOLE
It wouldn’t be an inversion of responsibility if traditionally “application” layer responsibilities weren’t being similarly pushed “down the stack.” A good example of how this is occurring today is in the area of “identity”, which traditionally includes authentication and authorization. In the early days of web applications, identification was based on a user name and password (sometimes IP address, sometimes a combination thereof) and was expected to be handled by the application. After all, the application knew what users should be allowed and thus is was the demesne of the application to provide those mechanisms. The use of .htaccess files was widespread as a means to achieve this functionality. But as technology began to merge the world of the web with the internal world of IT, it became increasingly common to leverage external applications as an identity store and the means by which users were authenticated and authorized to access applications. LDAP, Active Directory, RADIUS, DIAMETER. These protocols resided somewhere between the application layer and the transport layer and provide the data necessary for applications to make access decisions. But again, this method has run into obstacles in adapting to volatile and large environments. Scalability and the need to execute complementary access policies the network layer in authentication and authorization decisions has continued to drive identity and authentication and authorization “down the stack” and into the “network”. In a highly scaled environment, for example, it is often preferable that an intermediary Load balancer authenticate users to an application because it is increasingly painful for developers to tightly integrate application access and security policies into the application. Traditional methods are brittle, static designs that are increasingly tossed out in favor of more policy-based access that resides somewhere “in the network” rather than tightly-coupled with the application. What was once an “application” function has moved “down the stack” and is now increasingly the responsibility of the “network.”
WHAT DOES IT PORTEND?
The conflation of responsibilities up and down the “stack” point to either an increasingly flattened application architecture comprised of services; services that may reside in the application layer or the network layer, but are leveraged by both in approximately the same way. This is actually much of the brouhaha behind Infrastructure 2.0; behind the evolution of the network to become “smarter” and more “integrated” with the rest of the infrastructure. As the network takes on more and more responsibility from the applications, especially as is the case in an increasingly cloudy environment, the components in the network must be able to consume services provided by other components and collaborate as a means to ensure the fast and secure delivery of applications to their ultimate consumers. One of the side-effects is that it will cause some amount of confusion in the organization, at “layer 9”, as it were, regarding what role is responsible for developing and ultimately deploying those policies. Will developers become more network-aware? Will administrators and operators begin to take on a more development-oriented role in order to integrate and orchestrate the data center using the collaborative capabilities of Infrastructure 2.0 services? Maybe the answer to that depends on where you are, who you are, and whether you’ve drank from the bottle or not. Related blogs & articles: Technorati Tags: MacVittie, F5, cloud computing, virtualization, infrastructure 2.0, load balancing, QoS, rate shaping, API, integration, network, development |
| 0 Comments | Email This | Read More... |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
