How do you handle persistent storage in a fault-tolerant way?
You could technically pin your MySQL container to one host, but that seems to defeat the point of fleet. I considered trying to mount an iSCSI target to run the database from, but CoreOS doesn't have a working iSCSI initiator.
I guess I could just run all the persistent stuff on a more traditional OS, but then why mess with CoreOS at all?
- one to attach the EBS volume (wrapping the above container)
- one to mount the device to a directory on the host
- one to run the DB container, with a bind mount to the host directory
If the CoreOS host terminates, the cluster will reschedule the units to another host.
CoreOS seems to do a decent job as the application layer for something operating in a larger cloud that provides database and file storage as services, like Amazon or OpenStack. However, I think Docker has the potential to eliminate the need for infrastructure-level "clouds" to be so complex. The basic unit can be the container instead of the instance, so you don't need fancy automated instance management and all that. It'd be nice if you could also obviate the need for the other external services, and just run everything in containers on metal.
I was really excited by CoreOS as a way to do this, but it seems to fighting me at every turn. It seems much easer to just wire together the REST APIs of several Ubuntu/CentOS nodes running Docker.
That explains how they chose to minimize deadlocks.
Yes, if you use it incorrectly and/or for the wrong problem space, you will have issues. It isn't a magical solution to all problems. It is, however, an effective solution for a specific problem space.
I've been using it in our development environment. It locks like crazy.
This is after configuring HAProxy to have a primary node which all connections go to.
OpenStack seems to be OK with it though, it chugs along without fully breaking down. I'm sure I would see a pretty big performance delta if I ran a benchmark against it with and without Galera.
Comments
How do you handle persistent storage in a fault-tolerant way?
You could technically pin your MySQL container to one host, but that seems to defeat the point of fleet. I considered trying to mount an iSCSI target to run the database from, but CoreOS doesn't have a working iSCSI initiator.
I guess I could just run all the persistent stuff on a more traditional OS, but then why mess with CoreOS at all?
The persistence can follow the DB container:
https://github.com/leg100/docker-ebs-attach
You'll need three fleet units in total:
If the CoreOS host terminates, the cluster will reschedule the units to another host.We use Amazon RDS and S3. Only applications are run in the cluster.
Yeah, this seems to be common.
CoreOS seems to do a decent job as the application layer for something operating in a larger cloud that provides database and file storage as services, like Amazon or OpenStack. However, I think Docker has the potential to eliminate the need for infrastructure-level "clouds" to be so complex. The basic unit can be the container instead of the instance, so you don't need fancy automated instance management and all that. It'd be nice if you could also obviate the need for the other external services, and just run everything in containers on metal.
I was really excited by CoreOS as a way to do this, but it seems to fighting me at every turn. It seems much easer to just wire together the REST APIs of several Ubuntu/CentOS nodes running Docker.
I haven't used CoreOS, mainly just watched, but have you tried deploying a Galera cluster at a scale of 5 containers?
That is more likely what they'd have in mind than a single MySQL master container.
Who uses Galera successfully? Every DBA I've ever spoken to about it has advised me to avoid it because it's incredibly deadlock-prone.
http://blog.scoutapp.com/articles/2013/09/24/from-mysql-mmm-...
That explains how they chose to minimize deadlocks.
Yes, if you use it incorrectly and/or for the wrong problem space, you will have issues. It isn't a magical solution to all problems. It is, however, an effective solution for a specific problem space.
I've been using it in our development environment. It locks like crazy.
This is after configuring HAProxy to have a primary node which all connections go to.
OpenStack seems to be OK with it though, it chugs along without fully breaking down. I'm sure I would see a pretty big performance delta if I ran a benchmark against it with and without Galera.
I'd like an answer to this as well. Openstack installation guides recommend it for HA.