Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon Elastic File System – Production-Ready in Three Regions

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 122 posts

Re: Amazon Elastic File System – Production-Ready in Three Regions

#21

Post by Sanddancer »

merb wrote: post #18

I wonder if some can run a postgresql database on top of that. This would make it relativly easy to have a master without downtime and be way cheaper than RDS.

It claims to present itself as a full filesystem so I don't see why it wouldn't, however, you're probably going to run into pretty hardcore performance issues, because the bandwidth amazon provides in general is on the stingy side, but under a terabyte, they're downright miserly, with a 10 gig filesystem only able to provide 0.5 MB/s sustained. This product is problematic at best.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#22

Post by buremba »

takeda wrote: post #14
buremba wrote: post #3

We use a columnar database and we insert data to it periodically (30s to 90s) using Kinesis as middleware. Files are immutable and each insert creates [count of columns] * [count of tables] files. The database also periodically merges the batch files in background. Since EFS was not available, I was trying to develop a FUSE filesystem that writes data to both S3 and local filesystem (EBS) for durability and read only…

If files are immutable, isn't s3 much better fit for it? s3 main weaknesses is that you can't modify part of a file, which makes it unsuitable for a filesystem, but looks like it satisfies your use case.

Maybe but unfortunately the database doesn't support "backup store" that we can use directly S3, it just writes the data to specified directory in a filesystem. We should either fork the database or implement "S3 backed" filesystem and we picked the latter one. Unfortunately the performance FUSE is not that good for read and writing data to S3 is somehow expensive.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#23

Post by jedberg »

oconnore wrote: post #16
jedberg wrote: post #10

This is really cool but also kind of a shame. I feel like it will encourage bad behavior. I can see people using this to deploy code by deploying onto the shared volume so that all their instances get an "instant update". Which is great when it works, but lord help you when EFS goes down and every app server you have is hung on a broken NFS connection.

Isn't the whole point of AWS that you can blame AWS engineers for downtime instead of your own (in this case) code deployment thingy?

I'm not sure if you're being sarcastic or not, but no, it isn't. It's to provide building blocks for infrastructure. Down time is still on you. Only a lazy engineer blames their tools for their failures.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#24

Post by Someone »

takeda wrote: post #14
buremba wrote: post #3

We use a columnar database and we insert data to it periodically (30s to 90s) using Kinesis as middleware. Files are immutable and each insert creates [count of columns] * [count of tables] files. The database also periodically merges the batch files in background. Since EFS was not available, I was trying to develop a FUSE filesystem that writes data to both S3 and local filesystem (EBS) for durability and read only…

If files are immutable, isn't s3 much better fit for it? s3 main weaknesses is that you can't modify part of a file, which makes it unsuitable for a filesystem, but looks like it satisfies your use case.

They use S3. Their problem likely is that they write many small files to S3, and repeat it every minute or so. That's a combination S3 isn't designed/optimized for.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#25

Post by KaiserPro »

YES

Finally we can start using standard posix semantics for things.

Yes people might say its primitive, but currently all I can see is people trying to re-create shared files systems over protocols not designed for it cough cough HTTP

Finally I can have a shared home, with a shared environment.

A single readonly binary source (great for docker by the way.) also great for ensuring one version of scripts, without having to ansible everything.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#26

Post by Someone »

Sanddancer wrote: post #21
merb wrote: post #18

I wonder if some can run a postgresql database on top of that. This would make it relativly easy to have a master without downtime and be way cheaper than RDS.

It claims to present itself as a full filesystem so I don't see why it wouldn't, however, you're probably going to run into pretty hardcore performance issues, because the bandwidth amazon provides in general is on the stingy side, but under a terabyte, they're downright miserly, with a 10 gig filesystem only able to provide 0.5 MB/s sustained. This product is problematic at best.

Also, it is a full-fledged NFS-mounted file system.

I would be very wary of running a database from that.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#27

Post by dunkelheit »

jedberg wrote: post #23
oconnore wrote: post #16

Earlier quoted context omitted.

Isn't the whole point of AWS that you can blame AWS engineers for downtime instead of your own (in this case) code deployment thingy?

I'm not sure if you're being sarcastic or not, but no, it isn't. It's to provide building blocks for infrastructure. Down time is still on you. Only a lazy engineer blames their tools for their failures.

"Down time is still on you" - well put. And it is actually great when you can only blame yourself because then you can fix the issue right away. If someone other is to blame, you need to a) convince that person that there is a problem and b) wait for the issue to rise to the top of their queue. Which can be painful.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#28

Post by hdra »

jedberg wrote: post #10

This is really cool but also kind of a shame. I feel like it will encourage bad behavior. I can see people using this to deploy code by deploying onto the shared volume so that all their instances get an "instant update". Which is great when it works, but lord help you when EFS goes down and every app server you have is hung on a broken NFS connection.

I have to admit that is the first use case that I thought of when I read this. No more messing around with AMIs and launch config whenever an update is deployed.

You bring up a good point on the EFS being a point of failure though. What use case do you think the EFS is good for? It seems like even worse for data storage since IO can easily become a bottleneck.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#29

Post by KaiserPro »

jedberg wrote: post #10

This is really cool but also kind of a shame. I feel like it will encourage bad behavior. I can see people using this to deploy code by deploying onto the shared volume so that all their instances get an "instant update". Which is great when it works, but lord help you when EFS goes down and every app server you have is hung on a broken NFS connection.

but thats the same with any component. how is that different to SNS et al?

NFS is actually multi homed, so there is no real reason why it can't be HA/clustered, apart from the block store and the underlying file system.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#30

Post by ak4g »

buremba wrote: post #22
takeda wrote: post #14

Earlier quoted context omitted.

If files are immutable, isn't s3 much better fit for it? s3 main weaknesses is that you can't modify part of a file, which makes it unsuitable for a filesystem, but looks like it satisfies your use case.

Maybe but unfortunately the database doesn't support "backup store" that we can use directly S3, it just writes the data to specified directory in a filesystem. We should either fork the database or implement "S3 backed" filesystem and we picked the latter one. Unfortunately the performance FUSE is not that good for read and writing data to S3 is somehow expensive.

If you don't mind me asking, what DB is this?
Post reply on HN