Live data from Hacker News

Etcd Clustering in AWS

engineering.monsanto.com

21–30 of 31 posts

Re: Etcd Clustering in AWS

#21
post #7

Earlier quoted context omitted.

Have you tried using Mesos? We're doing a POC but ran into some issues that we're going to wait out. Also, I've spoken to Mesos and they stated that they had no intentions to make deployments easier/more stable, in favour of pushing their commercial offering.

> Also, I've spoken to Mesos Mesos is an Apache project, did you mean Mesosphere?

The context makes that a silly question.

Re: Etcd Clustering in AWS

#22
post #7

Earlier quoted context omitted.

Have you tried using Mesos? We're doing a POC but ran into some issues that we're going to wait out. Also, I've spoken to Mesos and they stated that they had no intentions to make deployments easier/more stable, in favour of pushing their commercial offering.

I pointed at an open-source project by Cisco that pretty much sidesteps them entirely. Obviously, CoreOS is going to start wanting your money pretty soon, as well. Having worked for one of the earliest commercial linux distributors, I have little faith in such an effort to get anywhere. Red Hat and Canonical can barely make a dime. Mesosphere isn't really an alternative to etcd, though. It relies on Zookeeper, which…

> Red Hat and Canonical can barely make a dime.

Redhat Fiscal 2015 revenue: $1.79 billion. Net income: $180 million.

Their fastest growing business areas are incidentally exactly in this space: OpenShift, OpenStack and Ceph.

Re: Etcd Clustering in AWS

#23
post #6

"If this happened our cluster would become unavailable and may have trouble re-clustering." This was basically the repeated experience I had which caused me to abandon etcd for the time being. If it can barely ever heal, what the fuck good is it? And I found that it could barely ever heal. A 3-node CoreOS cluster I ran _always_ crashed when it attempted a coordinated update, and rarely could be repaired with the help…

I have to second this. Both etcd 0.4.x and etcd 2 can get seriously wonky. Part of it is definitely that it's a lowish-level tool (as is fleet) and so it's up to you to make sure that you've got everything configured as it should be... but even so, sometimes shit just goes horribly wrong. I've put everything on a "No Reboot" schedule for now.

I really want to like the CoreOS ecosystem, but IMO it's still beta-quality software.

Re: Etcd Clustering in AWS

#24
post #21

Earlier quoted context omitted.

> Also, I've spoken to Mesos Mesos is an Apache project, did you mean Mesosphere?

The context makes that a silly question.

Only if you alraedy know Mesos and that there's a company called Mesosphere.

Re: Etcd Clustering in AWS

#25
post #2

... thanks Monsanto? In all seriousness, this is really interesting. They solved some of the problems associated with persisting a cluster and we're likely going to use that. Feels weird thanking them for anything though. Edit: Is anyone using CoreOS in a physical DC? We're using AWS with ~1.5k VMs but have another 5-6k hosts in physical DCs. Trying to move us towards containers but struggling.

I'm using coeros to operate a deis cluster. We deploy to our own data center using openstack.

Re: Etcd Clustering in AWS

#26
We solve the bootstrapping problem with an internal ELB instead.

Autoscaling Groups can be configured to have instances join multiple ELBs. We have one be the regular ELB to access the instances with, and the other is an internal ELB that only allows connections from instances in the cluster to other instances in the cluster on the etcd port (controlled via security groups).

When an instance comes up, it adds itself to the cluster via the internal ELB's hostname. The hostname is set in Route 53.

The biggest issues we've been having with etcd continue to be simultaneous reboots and/or joins to the cluster. It would also be great if the membership timeout feature that used to exist in 0.4 made its way back in. Right now, each member has to be explicitly removed rather than eventually timing out if it hasn't joined back in.

Looking forward to hear any other approaches folks have taken.

Re: Etcd Clustering in AWS

#27
post #7

Earlier quoted context omitted.

Have you tried using Mesos? We're doing a POC but ran into some issues that we're going to wait out. Also, I've spoken to Mesos and they stated that they had no intentions to make deployments easier/more stable, in favour of pushing their commercial offering.

I pointed at an open-source project by Cisco that pretty much sidesteps them entirely. Obviously, CoreOS is going to start wanting your money pretty soon, as well. Having worked for one of the earliest commercial linux distributors, I have little faith in such an effort to get anywhere. Red Hat and Canonical can barely make a dime. Mesosphere isn't really an alternative to etcd, though. It relies on Zookeeper, which…

what's your issue with Zk. It might be overweight but so far in ourdeployments it behaves a lot better than etcd. But if you're interested there's a lot being done with etcd and consul. I haven't seen etcd handling the kind of mixed data-web services that zookeeper was built for.

Re: Etcd Clustering in AWS

#28
post #7
post #6

"If this happened our cluster would become unavailable and may have trouble re-clustering." This was basically the repeated experience I had which caused me to abandon etcd for the time being. If it can barely ever heal, what the fuck good is it? And I found that it could barely ever heal. A 3-node CoreOS cluster I ran _always_ crashed when it attempted a coordinated update, and rarely could be repaired with the help…

Have you tried using Mesos? We're doing a POC but ran into some issues that we're going to wait out. Also, I've spoken to Mesos and they stated that they had no intentions to make deployments easier/more stable, in favour of pushing their commercial offering.

We are using Mesos/Marathon/Chronos/Docker/Bamboo on 200+ nodes on Google compute. Both for Data processing workloads and web applications (intensives advertising real time bidding servers). Using Mesosphere Packages, Salt, it was quite easy. Of course some services and some ssl stuff were a bit hairy but it's been working very great. Now I'm waiting for the availability of Mesosphere DCOS to come to GCP. Tried it on AWS and, god it's awesome. Makes spinning services like a breeze and deploying new product instantly.

Re: Etcd Clustering in AWS

#29
post #6

"If this happened our cluster would become unavailable and may have trouble re-clustering." This was basically the repeated experience I had which caused me to abandon etcd for the time being. If it can barely ever heal, what the fuck good is it? And I found that it could barely ever heal. A 3-node CoreOS cluster I ran _always_ crashed when it attempted a coordinated update, and rarely could be repaired with the help…

> Add this to the fact that the CEO of CoreOS told me in person that he expected them to be the _only_ Operating System on the internet, and I'm generally not along for the ride with CoreOS any longer.

That's the part that would concern me the most. The guy sounds delusional at best.

Re: Etcd Clustering in AWS

#30

Running docker clusters on AWS seems a little foolish to me unless your trying to save money. Instead of manage containers why not just manage instances?

boot time is one reason. another reason is integration with the aws ecosystem of services - it's not just ec2 these days.
Post reply on HN