Live data from Hacker News

Weave is kinda slow

generictestdomain.net

131–140 of 164 posts

Re: Weave is kinda slow

#131
post #130

Earlier quoted context omitted.

I REALLY wish that Clocker would support (and document how to use) something besides Weave - weave is intolerably slow for anything that requires some kind of more serious throughput between nodes. It is very, very unfortunate Clocker doesn't document how to not use Weave (for example, simply use whatever is already in place) as the rest of Clocker rocks, and the seemingly hard dependency on Weave makes it un-deploya…

The latest version of Clocker does support Calico as well, now! But I agree there isn't much in the way of documentation on how to change this. I updated the README and the main page at http://clocker.io/ to reflect the changes in Clocker 0.8.1 but it's not immediately obvious. Try this: ./bin/clocker.sh jclouds:provider:region calico

that's great, thanks for answering! I have not yet looked at Calico - I have OVS-VXLAN between my worker nodes, which is a simple solution that works great. Is it possible to say "use whatever is already in place"?

Re: Weave is kinda slow

#132

Earlier quoted context omitted.

I REALLY wish that Clocker would support (and document how to use) something besides Weave - weave is intolerably slow for anything that requires some kind of more serious throughput between nodes. It is very, very unfortunate Clocker doesn't document how to not use Weave (for example, simply use whatever is already in place) as the rest of Clocker rocks, and the seemingly hard dependency on Weave makes it un-deploya…

What throughput do you need, on a per-host basis?

about 8Gbits/sec

Re: Weave is kinda slow

#133
post #130

Earlier quoted context omitted.

The latest version of Clocker does support Calico as well, now! But I agree there isn't much in the way of documentation on how to change this. I updated the README and the main page at http://clocker.io/ to reflect the changes in Clocker 0.8.1 but it's not immediately obvious. Try this: ./bin/clocker.sh jclouds:provider:region calico

that's great, thanks for answering! I have not yet looked at Calico - I have OVS-VXLAN between my worker nodes, which is a simple solution that works great. Is it possible to say "use whatever is already in place"?

It may be possible by writing a slightly modified YAML file for the Clocker blueprint itself. To avoid dragging this thread further off-topic, please drop me a line at the email address in my profile, and I can probably help you.

Re: Weave is kinda slow

#134

Earlier quoted context omitted.

What throughput do you need, on a per-host basis?

about 8Gbits/sec

cripes.

on each host? what kind of physical network are you using, and how many containers per host? how many hosts? let me know if I should email about this instead.

Re: Weave is kinda slow

#135
post #9

Networking is a disaster. Kernel level networking is nice, but that requires access to the kernel which you can't provide in a container. Doing so means containers no longer contain. IPV6 was supposed to solve a lot of this by having an address space so huge you could easily give every vm host a few billion IPs. But nobody uses it.

Hey some of us believe that ipv6 is a good solution for containers. There are even products that support it (like Calico http://calicoproject.org/ ) and even a few cloud providers (not digital ocean who think that 16 ipv6 addresses is ipv6). If you want a real ip/ipv6 stack for your container, try unikernels.

Justin, I think/hope you meant http://projectcalico.org/!

Re: Weave is kinda slow

#136

Earlier quoted context omitted.

What throughput do you need, on a per-host basis?

about 8Gbits/sec

Wow. Is that a full 8Gbit/sec of data per host or a logical 8Gbit/sec of raw frames?

Either way, you're an ideal candidate for closed beta access to the performance focused container networking tools my startup is developing. I can contact you via email if you're interested.

Re: Weave is kinda slow

#137
post #11
post #4

Earlier quoted context omitted.

Is there any solution based on openvswitch ? If using vxlan to encapsulate containers L2 frames, the openvswitch kernel module should be able to route packets very well with much lower overhead than any userspace solution that do not access the nic memory directly.

SocketPlane or OVN.

OVN is 0.1 fairy dust and unicorn horns at the moment, looks very promising but you're most likely going to be waiting another 12 months before its solving your problems.

SocketPlane was bought by Docker and is now DEAD, to become whatever Docker decides is good enough to silence their critics. "See we bought these network guys, we swear we're taking networking and plugins seriously!"

Re: Weave is kinda slow

#138

Earlier quoted context omitted.

Because it represents a loose consensus mechanism, as I explained. That's fine for marketing, but not technical rebuttal to a claim.

Using an account that I share with other people in the same team is not the same as 'marketing'. I am sorry if this somehow offends, but think of the handle as just one poster.

Just a casual observation, but you don't appear to be listening to me. You are making rationalizations of my statements instead of trying to see my point. For example, I didn't say it was the same as marketing, I said that it's 'fine for marketing', i.e. posting in union when trying to spread interest would be a fine thing for a group account.

What I may be failing to communicate here is how trust is established between entities like companies and entities like individuals. When there is a issue with trust with individuals, like in the OPs post, it's best to establish 'point-to-point' communications with people you know so you can build up the trusted relationship. Doing that as a company doesn't really work well for that.

BTW, comments like "weave has lots of very happy users who find that weave is plenty fast enough for their purposes" are implicit trust statements based on bandwagon bias. What you are actually saying is there exist a group of people who don't feel the way the poster feels and are happy with the product's current state. The implication of your statement is that others should feel this way, but there's really no way to establish that unless we heard from all those people directly. This is yet another example of why consensus sucks when trying to establish the truth for an individual. (Bitcoin has figured this out, however.)

I think about trust a lot for work, so take my comments with a grain of salt. Nobody died here. :)

Re: Weave is kinda slow

#139
post #31
post #16

Earlier quoted context omitted.

"the least amount of encapsulation possible" doesn't sound like much of a solution if what you are looking for is networking with strong encapsulation.

>strong encapsulation What does that term even mean? Are you talking about encryption? If not, there is no 'strength' to encapsulation. Something is either encapsulated efficiently or it's not.

That's silly. There are definitely degrees of encapsulation.
Post reply on HN