Very good points. I hope you will put up more substantial information on your web site.
Consider that we are supposed to trust you with our customer's credit card information, their and our money. Currently I'm thinking: Who are you and why should I trust you? There is no information on your site which would give me any confidence. I'm sure you have all the info, but please share it with us.
I'll say "thank you" after I know more about the pricing and fees and how long it will take before my money appears in my bank account. It's great that you are setting up something like this and I really hope for the best. Would love to use it, but as others have commented, down here we are used to being ripped off, so when I see "monthly charges", I'm already a bit weary. Still hopeful, but a bit concerned.
Also, I really hope this will work for Kiwis as well?
I wouldn't exactly say the title is misleading, because it still is an address failover between cloud networks. But your points about the public addresses is of course correct.
The key application here is for those who wish to establish hybrid clouds, want to "cloud burst" their enterprise capabilities, or - as the opening sentence of the article explains - about "[organizations] moving part of [their] network and server infrastructure into the cloud".
And especially for those internal enterprise applications, running an HTTP proxy is not always possible.
In this simple example, you would have a single point of failure for the enterprise machines. But not any more than your enterprise's routers or Internet connection represent single points of failure.
However, you can have multiple gateways (and thus alternative routes). Furthermore, the IP address failover will instantly be noticeable to any other machine you have in the virtual network.
This is independent of nginx/Varnish. Actually, vCider gives you a virtual network and you can run any traffic you want over it, even non-IP protocols, since it's a virtual network switch.
As you can see, after publishing this article I received some feedback and questions about the comparison, including from the author of stunnel himself, Michal Trojnara. Even though the stunnel website itself states that the default is ‘no compression’, this apparently is not so. It appears iperf’s default data seems to be highly compressible, thus heavily skewing the performance numbers: stunnel was performing very different work than native networking or vCider. To arrive at more realistic numbers, I used a large image transfer (a JPEG) instead, which by its nature is not much more compressible. I transferred this file with iperf (which can use file input) as well as wget, The results? stunnel is much more comparable with both the native and the vCider networking speeds.
Interrupts and context switches are now roughly the same for all three solutions. stunnel still exhibits a significantly higher CPU load (20%), but certainly does not max out the CPU anymore. I suspect that the higher numbers of context switches and interrupts result from iperf’s default behavior of sending as much data as it can in a given time interval. And since stunnel can easily compress iperf’s default data, iperf was able to send a lot of this, which also explains the results reported by iperf.
While I maintain that a setup consisting of multiple nodes is much easier to maintain with vCider – which also provides a number of other interesting features – it must be noted that stunnel does indeed perform very well for point to point connections. Note to self: Be sure not to use synthetic data for performance tests like this.
1. Sorry you thought a comparison in which your program doesn't come out on top is a flame. It wasn't. Don't know what's unfair about comparing out of the box, default install performance of two systems.
2. Yes, I sent it, sorry you didn't receive it.
3. I did a standard apt-get install for stunnel on the Ubuntu Oneric system.
4. Sigh. I'm not going to comment on that one.
5. Really don't know where you would get this idea. Also don't understand why you get so upset. As I said, I was more than happy to discuss this with you ahead of time. Let me try to explain this again: I suggested that most real-world data is already compressed, thus the benefits you could derive by doing compression on the wire are lessened to the point where compression won't get you anything. For any compressable data, compressing it before sending is great and beneficial and I never stated otherwise.
Well, I contacted you privately to discuss this so that we may both enlighten each other on what's going on, but you did not respond to my email and instead went out publicly. Oh well.
But let's look at it. The physical link was capable of carrying something like 18 Mbit/s. When running iperf through stunnel, it reported more than 400 Mbit/s. But if you look at the actual bandwidth that was used during the transfer, it was indeed just 4.8 Mbit/s.
So, the 400 Mbit/s is clearly an illusion caused by the compression. Compressing a stream is a worth while goal, for sure. And it can be helpful in many cases. But I guess iperf's data is highly compressable. Considering that much of what's transferred these days is already compressed (multi-media files), I doubt that in the real world you will see any sort of speedup even remotely like this.
The fact is this: If it comes to actually transferring data over the wire, stunnel is very slow and there are just no two ways around it. It attempts compression at very high cost in CPU cycles and in the end is still going to be bound by context switches and interrupts.
I'm going to repeat the tests with compression disabled and update the blog post accordingly.
Indeed, the keys are centrally created and (briefly) stored. However, they are also changed frequently and historic (older) keys are not kept on record. So, if someone intercepts a bunch of your traffic and then wants to hack or demand our database, they would have to hurry since the older keys are not kept around.
However, I understand your concern. We are thinking of ways to address this in an even more comprehensive way.
vCider does not use larger packets. It can't, since they still have to be routed over the same public Internet.
stunnel tries to compress traffic as well, which works if you send a lot of stuff that isn't already compressed. But most of what's sent these days (multi-media?) already is encrypted, so this will be a wasted effort.
Considering the huge difference in context switches and interrupts, I don't think that encryption induced CPU load is the only issue here.
Kernel stuff on its own doesn't just magically run faster, of course. But in this case, I think it's the constant interaction between user-space and kernel-space, which causes the problem. That's an issue that will impact any user-space solution to a networking problem.
I'm not pretending this. But consider that IPSec doesn't exactly have a reputation for being easy to set up or even is particularly well supported across IaaS provider networks.
People revert to stunnel (and OpenVPN), exactly because they may not have the knowledge or inclination to get a fully featured IPSec setup going.
The standard ways to secure connections across public links (even for applications that don't support encryption themselves) has been to use stunnel or OpenVPN. But those solutions come with a significant performance hit. This article presents measurements and comparisons to illustrate this and presents a more modern solution with much better performance characteristics.
Engineering is always about making the right compromises. Why does it have to be 100% dedicated or 100% cloud? What most people don't realize is that it really is a continuum.
For example, why not run the disk performance sensitive DB server on a dedicated machine, while fronting the whole arrangement with proxies and app-servers hosted in the cloud? Ok, so there are latency considerations to be made, but you can see that mixed architectures can make sense.
I think what's stopping people from considering this is that there haven't been good cross-provider network virtualization solutions available. But if you could create your own network topology and your own layer 2 broadcast domains, no matter where your machines are located, things are starting to look up.
There are a number of network virtualization providers out there now, which you might want to look at to see what's possible. Disclaimer: I work for vCider ( http://vcider.com ), which provides solutions for on-demand virtualized networks, which can span providers and data centers.
How can you use contractors for system administration tasks, without having to hand them root passwords to your servers? The better solution is to let them work on the automation (scripting) of system administration tasks instead, the article explains.