Self Hosted Engine and iSCSI doubt
Hello, a doubt for 4.1 related to LUNs / storage domains to dedicate to hosted engine storage and normal data domain storage. In oVirt docs here: https://ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engin... doesn't say anything special to differentiate iSCSI based and FC-SAN based storage for hosted engine. Inside the docs of Self-Hosted Engine Guide for RHV (bot 4.1 final and 4.2beta ones) there is this general statement: " You must have prepared storage for your self-hosted engine environment. At least two storage domains are required: - A shared storage domain dedicated to the Manager virtual machine. This domain is created during the self-hosted engine deployment, and must be at least 60 GB. - A data storage domain for regular virtual machine data. This domain must be added to the self-hosted engine environment after the deployment is complete. " So far so good. But a bit below there is a particular note for iSCSI that I don't understand quite well " IMPORTANT If you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain. " Does it simply remark that the LUN for the hosted engine storage (shared storage domain) should be different from the LUN(s) used then for normal VMs (data storage domain), or what? I think it doesn't refer to the portal that for some reason needs to be different, correct? Any clarification about this restrictions? Thanks, Gianluca
2018-05-09 11:07 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
" IMPORTANT If you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain. "
Does it simply remark that the LUN for the hosted engine storage (shared storage domain) should be different from the LUN(s) used then for normal VMs (data storage domain), or what?
I think it doesn't refer to the portal that for some reason needs to be different, correct?
Any clarification about this restrictions?
I do not know. But I would guess it might be to avoid errors during mounting/unmounting those two logically separate storage domains if they are on the same physical resource. Veiko
On Wed, May 9, 2018 at 10:23 AM, Veiko Kukk <veiko@linux.ee> wrote:
2018-05-09 11:07 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
" IMPORTANT If you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain. "
Does it simply remark that the LUN for the hosted engine storage (shared storage domain) should be different from the LUN(s) used then for normal VMs (data storage domain), or what?
I think it doesn't refer to the portal that for some reason needs to be different, correct?
Any clarification about this restrictions?
I do not know. But I would guess it might be to avoid errors during mounting/unmounting those two logically separate storage domains if they are on the same physical resource.
Veiko
Actually I don't understand the meaning of the limitation itself... what target stands for in this context? Eg if I configure an iSCSI server using RHEL/CentOS 7.x OS and using targetcli and follow this: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... I have the hierarchy ../target/tpg/luns/[lun0,lun1,lun2] so it seems I have to create two different targets and put the hosted engine lun under target1/tpg1 and then the data domain luns under target2/tpg2 Normally if I connect to Enterrise Storage Arrays that offers iSCSI as a connection type (eg EQL or 3PAR) I simply put the portal ip and then I see the mapped LUNs granted to me, so in this case how can I differentiate "target", to be in the "safe/recommended" condition? Gianluca
2018-05-09 11:37 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
I have the hierarchy ../target/tpg/luns/[lun0,lun1,lun2]
so it seems I have to create two different targets and put the hosted engine lun under target1/tpg1 and then the data domain luns under target2/tpg2
No. You are missing the logic here. Path /target meants that following is a iSCSI target. Each LUN is different target. You can see more here https://www.thomas-krenn.com/en/wiki/ISCSI_Basics#iSCSI_Target Veiko
On Wed, May 9, 2018 at 10:52 AM, Veiko Kukk <veiko@linux.ee> wrote:
2018-05-09 11:37 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
I have the hierarchy ../target/tpg/luns/[lun0,lun1,lun2]
so it seems I have to create two different targets and put the hosted engine lun under target1/tpg1 and then the data domain luns under target2/tpg2
No. You are missing the logic here. Path /target meants that following is a iSCSI target. Each LUN is different target. You can see more here https://www.thomas-krenn.com/en/wiki/ISCSI_Basics# iSCSI_Target
Not really: a target can expose multiple LUNs and you can expose the same LUN over different targets.
Veiko
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
On Wed, May 9, 2018 at 11:22 AM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Wed, May 9, 2018 at 10:52 AM, Veiko Kukk <veiko@linux.ee> wrote:
2018-05-09 11:37 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
I have the hierarchy ../target/tpg/luns/[lun0,lun1,lun2]
so it seems I have to create two different targets and put the hosted engine lun under target1/tpg1 and then the data domain luns under target2/tpg2
No. You are missing the logic here. Path /target meants that following is a iSCSI target. Each LUN is different target. You can see more here https://www.thomas-krenn. com/en/wiki/ISCSI_Basics#iSCSI_Target
Not really: a target can expose multiple LUNs and you can expose the same LUN over different targets.
Indeed. In my opinion the link provided confirms that probably the generic term "do not use the same iSCSI target" could be improved/clarified. I can open a documentation bug and see what Red Hat Documentation team thinks about it, but first I would like to understand the use case, eg describing a scenario where problems could arise using a particular configuration. Gianluca
On Wed, May 9, 2018 at 10:37 AM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, May 9, 2018 at 10:23 AM, Veiko Kukk <veiko@linux.ee> wrote:
2018-05-09 11:07 GMT+03:00 Gianluca Cecchi <gianluca.cecchi@gmail.com>:
" IMPORTANT If you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain. "
Does it simply remark that the LUN for the hosted engine storage (shared storage domain) should be different from the LUN(s) used then for normal VMs (data storage domain), or what?
I think it doesn't refer to the portal that for some reason needs to be different, correct?
Any clarification about this restrictions?
I do not know. But I would guess it might be to avoid errors during mounting/unmounting those two logically separate storage domains if they are on the same physical resource.
Veiko
Actually I don't understand the meaning of the limitation itself... what target stands for in this context?
That limitation was due to this one: https://bugzilla.redhat.com/show_bug.cgi?id=1351213 The root issue is clearly explained here: https://bugzilla.redhat.com/show_bug.cgi?id=1351213#c4 The issue was mainly related to the auto import process and now in node-0 deployment flow we are not relying on that anymore (the hosted-engine storage domain is directly created by the engine running on the bootstrap local VM and so it's known by the engine by design) so probably we can just ignore that limitation but honestly I'm not 100% you will not encounter other minor gaps so I'd suggest to still keep two distinct storage domains over two distinct iSCSI targets for production systems. We are still working to handle the HE storage domain exactly as a regular storage domain but we still have some gaps so it's targeted to 4.3: https://bugzilla.redhat.com/show_bug.cgi?id=1451653
Eg if I configure an iSCSI server using RHEL/CentOS 7.x OS and using targetcli and follow this: https://access.redhat.com/documentation/en-us/red_hat_ enterprise_linux/7/html/storage_administration_guide/ online-storage-management#osm-target-setup
I have the hierarchy ../target/tpg/luns/[lun0,lun1,lun2]
so it seems I have to create two different targets and put the hosted engine lun under target1/tpg1 and then the data domain luns under target2/tpg2
You can use a single target portal group (by the way now hosted-engine is able to connect all the portals in the same portal group) but I'd recommend to expose two distinct targets so, as an example with targetcli: /> iscsi/ create iqn.2018-05.com.example:target1 /> iscsi/ create iqn.2018-05.com.example:target2
Normally if I connect to Enterrise Storage Arrays that offers iSCSI as a connection type (eg EQL or 3PAR) I simply put the portal ip and then I see the mapped LUNs granted to me, so in this case how can I differentiate "target", to be in the "safe/recommended" condition?
Gianluca
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
participants (3)
-
Gianluca Cecchi -
Simone Tiraboschi -
Veiko Kukk