[Gluster-users] Asymmetrical storage capacity on Glusterfs bricks
Craig Carl
craig at gluster.com
Mon Nov 15 22:19:56 UTC 2010
On 11/15/2010 12:55 PM, Burnash, James wrote:
> Has anybody tried asymmetrical storage capacity on Glusterfs bricks?
>
> For example, I have my 6 servers configured as mirrored and distributed.
>
> Could I add storage to just one mirror pair and make it part of the backend storage for just those servers?
>
> I thought I read about this somewhere before on the list, but I can't seem to find it.
>
> Thanks,
>
> James Burnash, Unix Engineering
>
> DISCLAIMER:
> This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.
> NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at its discretion, monitor and review the content of all e-mail communications. http://www.knight.com
>
>
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
James -
It works out of the box. We do have a best practice around
asymmetrical storage servers that will improve performance over just
expanding the mount -
Ideally each storage brick [1] in a Gluster cluster will be the same
size. If bricks differ in size Gluster uses stub files to maintain the
Elastic Hashing Algorithm model, the use of stub files [2] for
redirection will negatively impact performance. LVM2 is the easiest way
to create bricks that don't occupy an entire device. Using LVM2 offers
several advantages, by creating more smaller LVs if a file system needs
to be fsck'ed the process is faster. Snapshots and clones are also
compatible with Gluster.
[1] A brick is the combination of a server and a filesystem, ie
server1:/dev/vg1/lv1 and server1:/dev/vg1/lv2 are both bricks.
[2] http://en.wikipedia.org/wiki/Stub_file
Please let me know if you have any other questions.
Thanks,
Craig
-->
Craig Carl
Senior Systems Engineer
Gluster
More information about the Gluster-users
mailing list