Hi Tom
History with the service is one thing, but the function of it is
something different. I've tried to simulate some of the issues the
errors in the past had given EBS and the services relying on them - to
gether with Gluster. My main approach is the "Force detach" API call
you can make on a attached/mounted EBS volume.
Some bugs describing the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=852578 and
https://bugzilla.redhat.com/show_bug.cgi?id=832609
This is not Glusters fault, but the "networked"
"blockstore".
Long story short, if one EBS disk in your Gluster setup goes
unresponsive, your whole Gluster setup is unresponsive :(
My storage size need are relatively small, so I choose the right
instance size for the job, use instance storage and make sure theres a
rsync job sending data to somewhere else, just in case.
--
Rudi Meyer
Forlaget Systime
On 16 October 2012 16:09, Tom Hall <thattommyhall at gmail.com>
wrote:> Hi,
>
> Having a look at
>
http://gluster.org/community/documentation/index.php/Getting_started_setup_aws,
> there is something I disagree with from an availability standpoint,
> the recommendation to use EBS.
> I realise that you only get so much storage on an instance and it may
> be more expensive to scale out using instance store but in my
> experience (3 years in every AZ in every region of AWS) EBS is the
> most frequent thing that breaks, worse still outages span AZs. This
> lowers the attractiveness of lots of their offerings like RDS etc too
> and I think would cause problems for us as gluster users if we adopted
> EBS volumes as bricks.
>
> Please let me know if you think my reasoning is off, I'm close to
> going into production.
>
> Tom
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users