I wonder if there are any situations where one would prefer software load balancer over hardware load balancer or vice-versa. I've played around with f5, A10, Nginx, and HAproxy briefly, and the only marginal difference I was able to notice was the price, apart from slightly better API documentation etc. So my question is:
Are there any particular use cases where one would prefer Software load balancers over hardware load balancers or vice-versa?
Feel free to quote your experience, where you preferred one over the other and, rationale you used to make that decision.
PS: I have read 5 reasons to prefer S/W load balancers over H/W load balancers and didn't find explanations there very propelling.
EDIT: Regarding my use case, I'll be needing lot of load balancers to secure/load-balance tons of apps. Therefore the design decision should be such, as to cope up with exponentially increasing number of apps behind it (Should be easily scalable). I'm not looking for 10 or 50 app load balancer but at tons of thousands of apps behind load balancers solution. Also it would be great if you can specifically point out at features which outweigh in H/W over S/W or vice-versa. For example with H/W load balancer FPGA services one can do SSL offloading and can acheive an order of X performance gain given that one has more than Y number of apps behind it etc.
There isn't going to be a single answer to this question as it will always depend on your application requirements and your compliance obligations. Companies like F5, A10, Citrix offer services that expand well past basic load balancing and offer features lb just cannot touch.
If you're JUST looking for lb services and maybe some SSL bridging or offloading here are some benefits:
Hardware: Offer hardware accelerated SSL offloading and bulk encryption due to the use of FPGA services. This is also dependent on what cipher suites you plan to use. With hardware you're usually placing them in front of 100's of applications or you're using it because they may be certified firewalls and you need additional requirements for compliancy.
Software: If you just need basic LB, HAProxy/Nginx are an easy choice for basic lb services and even some SSL services. Support is mixed if you're not paying for it, having to rely only on community examples.
However, if you have mixed environments and maybe already have 1 vendor in play, that can help decide. All of the hardware vendors offer virtual appliances and have automation tools to help with elastic environments so really it ends up being "Will you only ever need LB services or will you end up having to tack on more later"?
The F5/A10/Citrix ADC's in cloud still offer more features in a single platform than having to spin up segregated services (think firewall/load balancing/Web firewall/global load balancing/fraud prevention/analytics/access management).
Updated 6/21/2017:
Hardware: People are buying hardware solutions not to proxy 1 or 2 applications but 100 or 200, or even 1000 or 2000 applications in their data centers (on site or collocated). For these cases it's about performance and services beyond lb. It includes security needs and app protection that are not baked into HAproxy and Nginx.
ADC Vendors Software Solutions: You have 3 options because F5/A10/Citrix also sell virtual appliances allowing you to run the same software in Azure/AWS/Google or in VMWare.... you get the idea. This becomes unique because you can have hardware in your co-location and virtual appliances in your cloud solution and its the same vendor and the bonus for your admins, the same support escalation point.
HAproxy/Nginx Softare: This goes back to the original statement, if you're talking LB solution only and price is a concern, this is your way to go. The feature sets are more limited than the ADC/Security solutions above, but they do LB justfine. It can become a bit cumbersome managing 100's of apps so you'll have to rely on your dev team a bit more to make sure they're isolating environments OR are REALLY good at automation.
The decision comes down to will you only need load balancers? If yes, then HAproxy/Nginx. If you need more features to load balance AND protect your app, then ADC software solutions are the way to go.
If you need reliable performance and cannot justify dedicating one vm per host to achieve it, then hardware ADC's are the way to go.
For transparency, I work on the DevCentral team at F5 so I would love to say go hardware, but if you don't need it don't do it. But its going to come down to your application requirements.
The follow up question is what is your application and requirements for a load-balancer?
Generally hardware LB's have a fixed performance and hardware acceleration to assist with SSL offload. Software or virtual performance can fluctuate with an increased load and then you can run into bugs with performance, but it's easier to deploy and scale.
Other questions to look into is, will you need to modify or redirect traffic based on content? For example, rewriting or filtering traffic? If yes, then you may need a full proxy LB.
Related
Requirement
I want to secure my production VMs on AWS, these VMs host critical web applications and can see around 500 Mbps traffic during peak hours. I already using mod_security WAF but I am not very happy with it.
Here is what I am thinking:
What if I can use snort in a lightweight configuration to monitor only HTTP traffic (this would be behind SSL termination) and use opensource XSS and SQLi rules to add an additional layer of protection ? The number of rules will be > 100.
By the time traffic hits my VMs it will be unencrypted. Moreover as I am using snort as on the same host, there wont be much of a semantic gap ( WAF has an edge over IPS since it builds richer app layer context and can detect layer 7 attacks more accurately). Is this understanding correct ?
I can spare around 200Mb of memory and can take 10% overhead on CPU performance.
Is snort the best bet here ? I looked at Suricata which seems to be easier on CPU but hard on memory. Please let me know if this makes sense at all. I want to stick to open source solutions.
"Commercial software routers from companies such as Vyatta can typically only attain transfer data at speeds of up to three gigabits per second. That isn’t fast enough to take advantage of the full speed of a typical network card, which operates at 10 gigabits per second." [1]
How is the speed of the network interface card relevant in this scenario? Aren't software routers connecting multiple Virtual Machines running on the same physical host? [2] Unless a PC has multiple network interface cards, it is unlikely that it functions as a packet switch between different physical hosts.
My interpretation suggests that there seem to exist two different kinds of software routing: (1) Embedding a real time operating system on an actual router. (2) Writing application layer code on a PC that can handle packets being transmitted between different virtual machines running on that very PC. Is this correct?
It depends on what your router is doing. If it's literally just looking at a static route table and forwarding packets out another interface, there isn't much hit in performance.
It's when you get into things like NAT, Crypto, QoS, SPI... that you will see performance degradation. Hardware vendors are usually using custom silicon to process the more advanced features, this allows for higher throughput packet forwarding.
Now that merchant silicon is fast enough and the open source applications are getting better, the performance gap is closing.
It really depends on your use case as far as what you want to use. I've gone with both and not seen performance hits, but the software versions weren't handling high throughput workloads.
Performance of the link from the virtual network to the physical eventually becomes important at any reasonable scale. You're right that, within the same physical host, things can be pretty quick, but that requires that one can get everything needed in one box.
While merchant silicon has come a long way in improving the performance of networking equipment, greater gains are taking place getting CPU's to handle networking tasks better. Both AMD and Intel have improved their architectures to the point where 10 Gbps forwarding is a reality. Intel has developed a specialized library (DPDK Wiki Page) that takes care of a lot of low-level networking functions at high performance.
I'm researching about SDN and NFV.
In the concept of NFV on Wikipedia , it says : "Network Functions Virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies, to virtualize entire classes of network node functions into building blocks that may be connected, or chained, together to create communication services."==> first thing to consider that it will reduce the cost of facilities.
So in real life implementation, for example, how can we virtualize a network nodes like a router?
NFV was created for the networks to be capable to extend in a dynamically way(virtualize the router) , not a static way(buy a new router), that is we must implement the router functions in the server or a computer instead of buying and then adapting the new router to the current nextwork , in this case I don't see any different in this implementation , because buying a server to implement a virtualized router is not cheaper than buying a new router.
Can anyone explain this for me , or Am i wrong understanding the NFV concept?
Thanks.
SDN is just that, software defined networking. In a Hybrid SDN model SDN decouples the logic from the physical box, rendering the physical box a simple "forwarding" box. The logic rests with the SDN controller where developers create APIs that manage these forwarding boxes (we call them network elements now) with flow tables that get pushed to them. The benefit here is that the devices can now be configured and provisioned through this controller, as opposed to having to log into each and every box.
Then you have the cloud. A small office can literally get away with porting all of their apps and services into the cloud, doing away with most of their physical boxes. Of course you still need a LAN in the office and a way to get out to the Internet and eventually the cloud. You can even ask the cloud provider to provision load-balancing on specific applications, firewalls and content delivery services. So basically your office applications and most of the supporting LAN and databases can be safely ported to cloud providers.
When you said "...because buying a server to implement a virtualized router is not cheaper than buying a new router", it depends: As it's a virtualized resource, you can use this new server to run your router and another resource from your infrastructure, if the machine has more hardware capacity than you need for a single router.
In fact, you might not even need to buy a new machine, if you have your resources in a cloud like AWS (or your own private cloud), when you have need for more routers, you can just flexibly allocate more hardware resources and spawn a new router instance (scale out) and, whenever your router demand is lower than what you have allocated, you can reduce your number of routers (scale in) and stop losing money with an infrastructure that you are not using at the moment.
Consider that a really high level explanation, if you want to know the details about how a Virtual Network Function scales in and out in a NFV implementation, I recommend you to read the ETSI specification about how it should work: http://www.etsi.org/standards-search#page=1&search=&title=1&etsiNumber=1&content=0&version=1&onApproval=1&published=1&historical=0&startDate=1988-01-15&endDate=2017-04-13&harmonized=0&keyword=&TB=789,,832,,831,,795,,796,,800,,798,,799,,797,,828&stdType=&frequency=&mandate=&collection=&sort=3
Let me continue with your example of the router. Traditionally, these routers are vendor specific. For example, the major sellers are companies like Cisco, Juniper, etc. They are implemented on proprietary hardware and therefore if you want to buy a new router you need to buy from them only. Further, when they go into some problems, you need a dedicated engineer to repair them. Therefore, the telecommunication has to take care of high Capital Expenditure (COPEX) and Operational Expenditure (OPEX).
With NFV, the entire router function is implemented as a software and deployed on a general purpose servers (GPP) or cloud. These GPPs are relatively very cheap when compared to proprietary hardware. Thanks to cloud computing, even small companies can afford servers on Amazon and Google clouds. Because of cheap availability, COPEX is now relatively cheaper. Further, you don't need a dedicated engineer when the hardware goes into a problem, the same engineer who works for GPP server maintenance is enough. This way OPEX is reduced.
Now imagine, like routers there are many networking elements present in Telecommunication. If every networking element requires a dedicated engineer, how much a Teleco operator will be spending money. Apart from this, due to software implementation, suppose, when you have very high traffic than expected, you can just roll out a new router (software network function) on GPP or Cloud instead of completely buying a new router, which is very costly. As you already know, in the cloud you pay based on usage.
There are many more uses. To know more you need to read research papers.
It appears that cheap consumer routers are fairly easy to crash: hanging around in various backup/sync software forums, I see this mentioned from time to time. Developers seem to be putting a fair amount of effort into making sure they don't crash the routers.
What are the "do"s and "don't"s for my network-heavy application to ensure that it doesn't cause issues with badly designed routers? Especially one that intends to connect to a number of peers?
IMO trying to workaround bad hardware is the road to nowhere, because every router fails in its own remarkable way :).
What you can do in the network-heavy application is assume that network is not stable media (routers can crash, etc) and design application network operations accordingly.
For instance, provide reconnect logic, connection timeouts, some sort of state caching to allow users work with app even if network connectivity is gone.
Concerning faulty routers - they usually crash because of great number of simultaneous connections (e.g. downloading via bittorrent or other p2p protocol). So, maintaining minimum number of connections can help.
My Company is running several international websites for selling insurance products.
Our current setup is a Webfarm with multiple Loadbalanced Webservers hosting our ASP.NET applications. The backend is a single - yet powerful - SQL Server. (all in one data center)
Our network admins want to move to virtual servers running on VMWare.
Scenarios could be
Webfarm: Multiple standard webservers, Loadbalanced (current setup), Session state on SQL Server
Virtual Webfarm: Multiple virtual servers, loadbalanced on one physical VMWare Host, Session state on SQL Server
2.a same as above but with multiple physical hosts
Single Virtual Webserver: One big powerful virtual webserver, no loadbalancing required, session state can be kept in process
There is a big hype around virtualization and I can see the benefits, but have no experience with this. I cannot tell what issues we will face and to what we should pay special attention.
Does anyone have experience with such a virtual setup?
What are general recommendations?
I tend towards 2a. I am afraid of having all webservers on one single physical machine.
Many thanks in advance to share your thoughts.
There are three reasons to use more than one webserver for an application:
Scaling - More grunt is required than one machine can provide
Reliability - Website should keep running in case of failure (a. hardware b. software)
Prioritization - One of the webservers takes on heavy work (perhaps scheduled tasks) leaving the other to respond to client requests quickly.
Marrying that up to you scenarios:
Scenario 1 provides 1, 2, 3
Scenario 2 provides 2b (perhaps 2a if it is fully hardware redundant (doubt it))
Scenario 2a provides 1, 2
Scenario 3 provides none of the above
Advantages of Virtual Hosting:
Lower Total Cost of Ownership (TCO) on big cluster serving multiple purposes is cost effective
New servers can be created quickly if needed
Redundant hardware is easier to justify if the cost is shared among many applications
Disadvantages:
Other virtual machines may suck away your CPU/Disk IO capacity
IMHO there is little point to load balancing multiple virtual machines on the same virtual server.
Robert's pretty much covered it all, I'm mostly just adding a note to say that at least one of our clients is currently running with option 2a.
So we have multiple loadbalanced web servers running on a couple of VM hosts, talking to a non-virtualised SQL cluster - this works quite well for them.
One other advantage of virtualisation is that it allows you to more fully utilise your hardware - however, you need to be aware that if you're running your virtual host at around 90% capacity with multiple VMs, you've not got a lot of spare capacity for any traffic spikes - if you're not expecting any, then great, but if you are, you'll need to have something in place to cope.
I agree with all of the above answers, and I actually work at a webhost. :-) If you're using multiple load-balanced webservers now then I can only assume the reason for it is either
Hardware Redundancy: If a single app server fails then those sessions are lost, but the app keeps running on the other servers and users can immediately re-connect.
or
Application Load Distribution (it's late so I can't think of a better name): Your traffic dictates that you have multiple app servers since all of your users would crash a single app server.
If #1 is the reason, then going to VMWare defeats the purpose since you only have one server supporting everything, and in case of hard drive crash, etc, you are down while it is repaired. If #2 is the reason then a VMWare based solution MAY work, however keep in mind that the hardware you'd use would almost necessarily be of a higher caliber than what you're currently using. So you maybe get more bang for your buck, but you STLL lose the redundancy that multiple physical machines gave you.
Now, you could always combine the two by having multiple physical machines all running VMWare, but that adds a level of complexity to things that you may not necessarily want either.
It doesn't sound like there would be any tangible benefit from running multiple virtual servers on the same physical host, you're just adding overhead. Unless I'm missing something with the way you've described the setup, there wouldn't be any benefit at all from moving to VMware - unless you're looking at taking advantage of features such as VMotion
VMware is most useful for consolidating underutilized hardware. If your hardware is running at near-capacity during peak periods then you don't want to run multiple VMs on the one machine.
There are benefits to Virtualization but your network admins need to prove that there is a benefit for your company before you even consider switching. I would say if you have multiple apps running on dedicated servers with low traffic (i.e. each app has it's own physical server) then sure, Virtualize. If you have one app over many servers, then don't.
You should be able to use virtual machine hosts with multiple vm per host and load balance across all of them.
Microsoft is doing this with msdn and technet http://virtualization.info/en/news/2008/05/microsoft-migrates-msdn-and-technet-on.html.