| Summary: | [Doc RFE] Enable sharding for VM store usecase | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | SATHEESARAN <sasundar> |
| Component: | doc-Configuring_Red_Hat_Enterprise_Virtualization_with_RHGS | Assignee: | Laura Bailey <lbailey> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | SATHEESARAN <sasundar> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rhgs-3.1 | CC: | asriram, kdhananj, lbailey, rcyriac, rhinduja, sankarshan, sasundar, ssaha |
| Target Milestone: | --- | Keywords: | Documentation, FutureFeature, ZStream |
| Target Release: | RHGS 3.1.3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-29 14:20:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1311845, 1317852 | ||
|
Description
SATHEESARAN
2016-03-21 05:56:49 UTC
Info about shard from 'volume set help' [root@ ~]# gluster volume set help | grep shard -A4 Option: features.shard-block-size Default Value: 4MB Description: The size unit used to break a file into multiple chunks Enable sharding on the volume. # gluster volume set <vol-name> features.shard enable There should be important note saying that - "When sharding feature is turned on, it doesn't shards the existing VM Images. The newly created VM Images file post enabling sharding will only be sharded. Looks good, Laura. Laura, Here are the feedback about the content 1. The point about configuring shard starts with the line - 'optional' - With RHGS 3.1.3, we are recommending sharding for the volumes backing RHEV data domain So can we remove the phrase - 'Optional: Configure sharding' as 'Configure sharding' 2. Its really a valuable thought for adding sharding related options in virt profile. Appreciate it ! Its recommended to have keys along with their namespace <snip> If you want to enable sharding for your entire virt group, you can add the following lines to the /var/lib/glusterd/groups/virt file. shard=enable shard-block-size=512MB data-self-heal-algorithm=full </snip> should be <snip> If you want to enable sharding for your entire virt group, you can add the following lines to the /var/lib/glusterd/groups/virt file. features.shard=enable features.shard-block-size=512MB cluster.data-self-heal-algorithm=full </snip> Rest of the content looks good to me @Laura - could you address the above mentioned comments ? Hi Sas, 1. Do we require sharding to be enabled in order to support this use case? If so, then yes, I agree we should remove 'Optional' entirely. However, if sharding is a recommendation rather than a requirement (which I think is the case), perhaps we can change 'Optional' to 'Recommended' here - this indicates that sharding is not a required part of the system, but it is good to have. I've made the change to 'Recommended' in the meantime. Can you confirm that this is a good decision? 2. I've updated the step to include the namespaces for these options. For consistency, I'd like to add namespaces to the list of options in groups/virt file, but some of them don't appear in our 'Configuring Volume Options' section. Can you tell me the namespaces for these, and confirm that the namespaces I do have are correct? performance.quick-read=off read-ahead=off <-- should this be readdir-ahead? neither is covered in 'Configuring Volume Options' io-cache=off <-- not covered in 'Configuring Volume Options' stat-prefetch=off <-- not covered in 'Configuring Volume Options' eager-lock=enable <-- not covered in 'Configuring Volume Options' remote-dio=on <-- not covered in 'Configuring Volume Options' cluster.quorum-type=auto cluster.server-quorum-type=server > Hi Sas,
>
> 1. Do we require sharding to be enabled in order to support this use case?
> If so, then yes, I agree we should remove 'Optional' entirely.
>
> However, if sharding is a recommendation rather than a requirement (which I
> think is the case), perhaps we can change 'Optional' to 'Recommended' here -
> this indicates that sharding is not a required part of the system, but it is
> good to have.
>
> I've made the change to 'Recommended' in the meantime.
>
> Can you confirm that this is a good decision?
As I understand, from RHGS 3.1.3, sharding will be the required part of RHEV-RHGS integration stack, as sharding provides better performance and also
faster self-heal.
@Sayan, what do you think about this ?
- Sharding should be mentioned as the requirement, isn't it ?
I am moving this bug to ASSIGNED state, as this bug requires some additional update to be done to the modified content (In reply to SATHEESARAN from comment #16) > I am moving this bug to ASSIGNED state, as this bug requires some additional > update to be done to the modified content I moved this bug to FailedQA just to accomodate the changes as mentioned in comment13. The changes are already available in the content, except for sharding mentioned as the 'recommended' practice No other changes required verified in the admin_doc and also in RHEV_RHGS guide with the doc_link available in comment20 |