Hacker News Reader

Comment by copergi | Hacker News Reader

How do you even do anything without using EBS?

Well, you break your services out onto stateless and stateful machines. After that, you make sure that each of your stateful services is resilient to individual node failure. I prefer to believe that if you can't roll your entire infrastructure over to new nodes monthly then you're unprepared for the eventual outage of a stateful service.

Most databases have replication but you need to make sure that the characteristics of how the database handles a node failure are well understood. Worst case you use EBS, put your state on it, snapshot it regularly, and ship those snapshots to another region because when EBS fails it fails hard.

Also, logs make every machine stateful. Use something like logstash to centralize that state.

And you do what for loadbalancing?

IIRC, Amazon has been working on removing the ELB dependence on EBS. I haven't seen an announcement of them being done, though.

If ELB is down in a given region then DNS failover to another region. Assuming you feel comfortable rolling your entire infrastructure monthly, have good images / configuration management, and have the state replicated in the backup region.

That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.

Exactly - how can I run a database server without EBS?

I think Cassandra is what all the big guys use. Apple, Netflix, etc.

We use RDS (they now support Postgres) and Elasticache.

The pricing seems reasonable for the performance (I've not done benchmarks if I'm being honest), and you get to treat all your EC2 instances as expendable.

Sure - but I'm assuming RDS uses EBS under the covers...

I meant rather that is there any other option for persistent data on AWS?

If you're eschewing EBS because of past problems (like the Oct 2012 outage), you should be aware that RDS is EBS-backed [1].

Also, on EC2, EBS-backed instances boot faster [2]. Of course, you can (and should) still treat EBS-backed instances as expendable.

[1] http://aws.amazon.com/rds/faqs/#hardware-scaling

[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Component...

Just to clarify: I don't eschew RDS because of outage issues, I use RDS because it's much easier to set up and manage compared to doing it yourself.

To be honest, I didn't know RDS was backed by EBS but it makes little real difference to me as long as the backup procedures are rock-solid and the performance is acceptable.

As others pointed out, you use EBS then.

By having good replication, either hand rolled or built in.

At Netflix we use Cassandra and store all data on local instance storage. We don't use EBS for databases.

Jedberg... this single post blew my mind. :)

It's one of those "huh, never ever thought of it from that angle" sort of ideas. The very idea of putting your absolutely valuable data on ephemeral storage and just duplicating it.

Thanks for that.

Run multiple replicas with synchronous replication. For Postgres see:

https://wiki.postgresql.org/wiki/Synchronous_replication

This way you should be able to tolerate failure of a single instance without losing data.

we do async replication with good monitoring of the slaves to make sure the slaves don't get too far behind. couple that with wal-e.

of course, if a comet hits the master db server, you might lose a tiny bit data (typically 0.1 seconds) if not using sync replication.

you can use sync replication for the important things that you absolutely can't lose, and async replication for everything else.

But the thing people are needlessly concerned about with EBS is full datacenter failure. Which is just as much a problem for those EC2 instances. Synchronous replication to another data center is a massive performance killer.

Reply on news.ycombinator.com