51–58 of 58 posts
Why mention an SLA if it's 99%? To me, "SLA" is an enterprise oriented term, which a lot of folks (us) don't care about because we're scaling horizontally and architect with failure in mind. 99% for a typical non-scaling enterprise app is crap.
Earlier quoted context omitted.
We (rsync.net) maintain 's3cmd' and 'gsutil' in our environment, so you can do direct cloud cloud transfers from either amazon or google to and from rsync.net. We don't have a cold storage product, so perhaps not relevant for nearline ... but it is relevant for their online options. You do have the ability to migrate to another provider. Two random notes: - we're announcing zfs send/recv[1] as a transport in the next…
If you have tons of TBs, you don't want to care about random failure with some third party. Amazon S3 has the reputation that they never lost a file, AFAIK. On their scale that provides an argument to just fork over the cash and forget about it. While I think ZFS is great, it's just not a solution for really large storage. Also, if you are still using s3cmd, that only tells me how inexperienced you are.
I'm not sure you understand how s3cmd is being used in the above context ... the idea is this:
ssh user@rsync.net s3cmd get s3://rsynctest/mscdex.exe
Earlier quoted context omitted.
We (rsync.net) maintain 's3cmd' and 'gsutil' in our environment, so you can do direct cloud cloud transfers from either amazon or google to and from rsync.net. We don't have a cold storage product, so perhaps not relevant for nearline ... but it is relevant for their online options. You do have the ability to migrate to another provider. Two random notes: - we're announcing zfs send/recv[1] as a transport in the next…
If you have tons of TBs, you don't want to care about random failure with some third party. Amazon S3 has the reputation that they never lost a file, AFAIK. On their scale that provides an argument to just fork over the cash and forget about it. While I think ZFS is great, it's just not a solution for really large storage. Also, if you are still using s3cmd, that only tells me how inexperienced you are.
Can we have a brief (one or two sentence) summary of what people should be using instead?
Earlier quoted context omitted.
If you have tons of TBs, you don't want to care about random failure with some third party. Amazon S3 has the reputation that they never lost a file, AFAIK. On their scale that provides an argument to just fork over the cash and forget about it. While I think ZFS is great, it's just not a solution for really large storage. Also, if you are still using s3cmd, that only tells me how inexperienced you are.
if you are still using s3cmd, that only tells me how inexperienced you are Can we have a brief (one or two sentence) summary of what people should be using instead?
Any tips for getting a fairly significant amount of data (50TB) from a local NAS to Google quicker than a 5mbps upstream will allow? Amazon has Import/Export which lets you ship drives, is this the best option?
Earlier quoted context omitted.
Only hard to fill if you're dealing with text only. Say you're building a video copyright detection crawler and you want to store videos from all over the internet.
An HD video stream from Netflix uses about 3GB per hour. So 100PB gives you about 4000 years of content.
Any tips for getting a fairly significant amount of data (50TB) from a local NAS to Google quicker than a 5mbps upstream will allow? Amazon has Import/Export which lets you ship drives, is this the best option?