I am a new user to gluster and have found it ridiculously easy to set up a basic, working test example. Now, I want to begin to work toward consolidating storage from a number of machines that make up our compute cluster. We have bought these machines over time and some have a fair bit of storage (3-10TB). So, what is the recommended way of configuring gluster when the storage sizes (and performance) are different among bricks? We would plan on this type of storage scavenging just as an "archival" storage where high performance is not really necessary. I think we will be able to arrange backups for these data, also, outside of gluster afr. Any suggestions or links? Thanks, Sean
At 06:47 PM 12/9/2008, Sean Davis wrote:>I am a new user to gluster and have found it ridiculously easy to set >up a basic, working test example. Now, I want to begin to work toward >consolidating storage from a number of machines that make up our >compute cluster. We have bought these machines over time and some >have a fair bit of storage (3-10TB). So, what is the recommended way >of configuring gluster when the storage sizes (and performance) are >different among bricks? We would plan on this type of storage >scavenging just as an "archival" storage where high performance is not >really necessary. I think we will be able to arrange backups for >these data, also, outside of gluster afr. Any suggestions or links?I believe the answer is to use unify (I believe there are some changes in 1.4 for this, so hopefully someone more adept at that will chime in), but anyway "unify" the bits from all your machines into one logical larger volume. you can then AFR this entire logical volume to somewhere else for archiving and availability. your other AFR volume can also be a unified group of other storage. AFR will use the size of the smallest brick that it''s replicating to, so if you unify 3TB+ 7TB + 2TB and AFR that to a unify of a 2TB + 8TB + 5TB volume, the AFR volume size will be 10TB since that''s the most you can put in before filling up one of the bricks.>Thanks, >Sean > >_______________________________________________ >Gluster-users mailing list >Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
At 06:47 PM 12/9/2008, Sean Davis wrote:>I am a new user to gluster and have found it ridiculously easy to set >up a basic, working test example. Now, I want to begin to work toward >consolidating storage from a number of machines that make up our >compute cluster. We have bought these machines over time and some >have a fair bit of storage (3-10TB). So, what is the recommended way >of configuring gluster when the storage sizes (and performance) are >different among bricks? We would plan on this type of storage >scavenging just as an "archival" storage where high performance is not >really necessary. I think we will be able to arrange backups for >these data, also, outside of gluster afr. Any suggestions or links?I believe the answer is to use unify (I believe there are some changes in 1.4 for this, so hopefully someone more adept at that will chime in), but anyway "unify" the bits from all your machines into one logical larger volume. you can then AFR this entire logical volume to somewhere else for archiving and availability. your other AFR volume can also be a unified group of other storage. AFR will use the size of the smallest brick that it's replicating to, so if you unify 3TB+ 7TB + 2TB and AFR that to a unify of a 2TB + 8TB + 5TB volume, the AFR volume size will be 10TB since that's the most you can put in before filling up one of the bricks.>Thanks, >Sean > >_______________________________________________ >Gluster-users mailing list >Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
At 06:47 PM 12/9/2008, Sean Davis wrote:>I am a new user to gluster and have found it ridiculously easy to set >up a basic, working test example. Now, I want to begin to work toward >consolidating storage from a number of machines that make up our >compute cluster. We have bought these machines over time and some >have a fair bit of storage (3-10TB). So, what is the recommended way >of configuring gluster when the storage sizes (and performance) are >different among bricks? We would plan on this type of storage >scavenging just as an "archival" storage where high performance is not >really necessary. I think we will be able to arrange backups for >these data, also, outside of gluster afr. Any suggestions or links?I believe the answer is to use unify (I believe there are some changes in 1.4 for this, so hopefully someone more adept at that will chime in), but anyway "unify" the bits from all your machines into one logical larger volume. you can then AFR this entire logical volume to somewhere else for archiving and availability. your other AFR volume can also be a unified group of other storage. AFR will use the size of the smallest brick that it''s replicating to, so if you unify 3TB+ 7TB + 2TB and AFR that to a unify of a 2TB + 8TB + 5TB volume, the AFR volume size will be 10TB since that''s the most you can put in before filling up one of the bricks.>Thanks, >Sean > >_______________________________________________ >Gluster-users mailing list >Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
At 06:47 PM 12/9/2008, Sean Davis wrote:>I am a new user to gluster and have found it ridiculously easy to set >up a basic, working test example. Now, I want to begin to work toward >consolidating storage from a number of machines that make up our >compute cluster. We have bought these machines over time and some >have a fair bit of storage (3-10TB). So, what is the recommended way >of configuring gluster when the storage sizes (and performance) are >different among bricks? We would plan on this type of storage >scavenging just as an "archival" storage where high performance is not >really necessary. I think we will be able to arrange backups for >these data, also, outside of gluster afr. Any suggestions or links?I believe the answer is to use unify (I believe there are some changes in 1.4 for this, so hopefully someone more adept at that will chime in), but anyway "unify" the bits from all your machines into one logical larger volume. you can then AFR this entire logical volume to somewhere else for archiving and availability. your other AFR volume can also be a unified group of other storage. AFR will use the size of the smallest brick that it''s replicating to, so if you unify 3TB+ 7TB + 2TB and AFR that to a unify of a 2TB + 8TB + 5TB volume, the AFR volume size will be 10TB since that''s the most you can put in before filling up one of the bricks.>Thanks, >Sean > >_______________________________________________ >Gluster-users mailing list >Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users