Forums

Home / Forums

You need to log in to create posts and topics. Login · Register

Question about PetaSAN iSCSI options

Hi!

I'm heard about PeataSAN use LIO Target for iSCSI service for client host.

Here is a 2 questions.

Q01. How to change iSCSI LUN number?
I can't find any option on iSCSI disk creation page.

Targetcli have a option to change LUN No.

Targetcli also have a option to assign manual LUN No. when create new LUN creation time.

Some old Unix like OS always need LUN No. zero, but almost vSphere & Hyper-V admins need manual assign LUN NO. to their LUNs.

 

Q02.How to change iSCSI disk type from flash to hdd

Targetcli have a option for default disk type from flash to hdd

 

Is there any solution or new feature update roadmap?

Regards.

PetaSAN configures 1 lun per target, each iSCSI target is 1 lun, it is LUN 0

Some old Unix like OS always need LUN No. zero, but almost vSphere & Hyper-V admins need manual assign LUN NO. to their LUNs.

I'm not sure what you mean by manual settings for vSphere and Hyper-V,  but in both cases you can just connect to the target from the ui and it will automatically connect to the disk.

Targetcli have a option to change LUN No.

Again not sure why you would want to do this, but you can use targetcli together with PetaSAN to perform any changes to the configuration created by PetaSAN if you want.

Q02.How to change iSCSI disk type from flash to hdd

Targetcli have a option for default disk type from flash to hdd

You can use targetcli to adjust any custom settings created by PetaSAN. You can also take control on settings that PetaSAN uses during disk creation in file /opt/petasan/config/tuning/current/lio_tunings, you can add attributes as used in targetcli
{
"storage_objects": [
{
"attributes": {
"block_size": 512,
"emulate_3pc": 1,
"emulate_caw": 1,
"emulate_tpu": 1,
"queue_depth": 128
}
}
],

"targets": [
{

"tpgs": [
{
"attributes": {
"default_cmdsn_depth": 128
},

"parameters": {
"DefaultTime2Retain": "20",
"DefaultTime2Wait": "2",
"FirstBurstLength": "1048576",
"ImmediateData": "Yes",
"InitialR2T": "No",
"MaxBurstLength": "1048576",
"MaxOutstandingR2T": "16",
"MaxRecvDataSegmentLength": "1048576",
"MaxXmitDataSegmentLength": "1048576"
}
}

]
}
]
}

I can understand what do you said about PetaSAN iSCSI configuration features.

PetaSAN use one iscsi target have a one LUN with LUN Number 0.

But whenever create a VMware ESXi VMFS volume in multiple iSCSI disks provide to ESXi host, vSphere WebUI only show a LUN ID, not iSCSI target ID.

Hence vSphere admins can't detect what iSCSI disk use for VMFS creation.

Almost enterprise SAN solution like Dell EMC Compellent using a sequence LUN ID assgin method to newly created LUN, but also have a manual LUN ID assign option.

Regards.

From the vmware ui you enter any ip of the PetaSAN disk to connect to, vmware will automatically discover the iqn target name and scan all the paths (all ips) and discover the luns (in our case lun 0) and discover other parameters like disk vendor ( PETASAN) size...and a globally unique disk id  referred naa or wwn

When you add a VMFS datastore, you identify the disk by its naa or via a combination of both iqn name and lun id. The lun id is not enough by itself. The iqn name should be displayed as "Path ID", but if not then use the naa for identification as it is accepted for any command lines..etc.

https://kb.vmware.com/s/article/1014953

NAA stands for Network Addressing Authority identifier. EUI stands for Extended Unique Identifier. The number is guaranteed to be unique to that LUN. The NAA or EUI identifier is the preferred method of identifying LUNs and the number is generated by the storage device

PetaSAN generates a global unique identifier based on some section of the Ceph cluster uuid as well as the rbd image name like 00001, 00002 etc.

Yes, absolutely there is a UUID exists.

But whenever create VMFS volumes, every check massive amounts of iSCSI's naa ID is very time consumed work for vSphere admins...:(

For example, TrueNAS give a select options (iSCSI Target, LUN ID) whenever export iSCSI extent to iSCSI Target.

When using BFS(Boot From SAN), unique iSCSI Target to iSCSI NIC firmware were needed, too.

Because of reduce management overhead and remove misconfiguration that cause LUN  corruption.

Regards.

But there is no other way around it.

It may be in some simple case you only have 1 target iqn from 1 SAN with a few luns identified with ids 0, 1 ,2 in such case yes you do not have to worry about different naa or iqn+lun . Otherwise life is not as simple..this is why we earn the big bucks 🙂

Actually the naa number generated by PetaSAN does have 00001, 00002 as part of it which makes it easy to identify, these correspond to the PetaSAN disk number and ultimately the Ceph rbd image name. We have users who user VMWare to talk to more than 1 PetaSAN cluster, in such case they also need to spot the cluster ids in the naa.

In VMWare version 6 you could see both the naa and iqn/lun when adding a new datastore, in 7 i believe the iqn is not displayed but again as per the earlier link, naa is the preferred identification method by VMWare, you will need it for any cli commands such as setting iops load balancing (see our VMWare guide).

Yes, ESXi host detect a LUN with Unique IDs like naa, eui and so on...:)

But this is a hypervisor's world, not human being's one.

All admins were human being, not a hypervisor and machine, too.

I just suggestions for human beings that focus to admin's convenience to avoid faulty configuration when massive VMFS volume creations.

Thank you for your quick and exact reply...:)

Best Regards.

beside the above, the main reason we choose 1 lun per target is performance and load balancing. In PetaSAN 1 lun gets served by many paths on multiple host gateways in active/active way. Each lun is served by many ips, rather than 1 ip serving many luns. it is also better in HA failover, giving better load distribution.

In terms of performance, your opinion is correct and I agree with you.
I just want to change the LUN ID 0 to the desired LUN ID, which will help the hypervisor admins who create a VMFS volume.
And ...
When iSCSI disk creation page provide a iSCSI Target (that based IQN base prefix) and admin can modify like iqn.2016-05.com.psc.bfs011 that will be good for BFS configuration.
Examples
===========================================================================================
01.BFS (Boot From SAN with iSCSI protocol)
host01 - iqn.2016-05.com.psc.bfs01 + LUN ID 0 <--> Client ACL to IQN iqn.1998-01.com.vmware.host01 only
host02 - iqn.2016-05.com.psc.bfs01 + LUN ID 0 <--> Client ACL to IQN iqn.1998-01.com.vmware.host02 only
02.All shared volume
 iqn.2016-05.com.psc.000x + LUN ID 021 (Exchange Server) <--> Client ACL to All
 iqn.2016-05.com.psc.000x + LUN ID 031 (SQL Server) <--> Client ACL to All
and so on
===========================================================================================
Thank you again for your detailed and kind explanation...:)
Regards.

I believe in VMWare 7 when adding new iSCSI data store you can only identify it by naa. In version 6, in addition to the naa both the iqn and lun were also shown, in 6.5 the naa and lun are shown.

https://www.youtube.com/watch?v=WvEU9WW6H9Y&t=800s

Again in PetaSAN the naa contains the disk numbers 00001,00002 etc