You are not logged in.

#1 2022-10-12 11:30:00

cameo
Member
Registered: 2012-08-18
Posts: 122

Getting into grips with iSCSI and stuff

So I recently owned a new 2-bay WD MyCloud-NAS, which I run in RAID1 mode, but yet doesn't contain any partitions or particular data.

Besides at least this box appears to be ratehr old as its BIOS originates from 2013(!), and since it is supposingly made for running 24/7 – it has no power button! Anyway – I am going to use it simply in my home LAN for data storage, without any remote connectivity as well as often, but not permanently. Say, when shutting down my computer sessions, I also want to poweroff the NAS box properly, before disconnecting it from the fuse.

For the latter though there is a browser button in the graphical backend (dashboard); yet I'd prefer to initialise a script or something. – Vice versa, I want to have it mounted automatically when it's on-line, via sudo and/or fstab. Or at least open it in a file manager.


And for making things more compl...ex, as with all of my block devices, I want to have all data encrypted like in 1+ partition/s either with dmcrypt/LUKS or veracrypt around ext4. So it seems using iSCSI is more suitable for this task than e g. NFS.

Before wanting iSCSI, I managed to create another user in the WD dashboard and folder-like areas with public and user's permissions for NFS and FTP, which I can open in my file manager (i. e. dolphin); their owner is still root, though I can create folders or move files.


However, I am currently stuck at a basic level dealing with iSCSI stuff, mixing up terms and disk layout and the ways how things work.

Secondly, I already started setting up the disks with WD on-board means in its dashboard – such as creating an iSCSI target w/ CHAP, so I got an <iqn>. And there're further options to also create "virtual volumes" which are the same as LUNs, I suppose. –

Then I read about LIO, targetcli etc., and that's where my confusion get's worse – and I now am worrying about the risk of misconfiguration, performance and data loss due to mixing up WD tools with targetcli, while I think the latter is even necessary to make the whole thing smoothly with Linux.

When initiating targetcli, it seems not to find the target made by WD tools...

# targetcli ls
o- / .................................................................. [...]
  o- backstores ....................................................... [...]
  | o- block ........................................... [Storage Objects: 0]
  | o- fileio .......................................... [Storage Objects: 0]
  | o- pscsi ........................................... [Storage Objects: 0]
  | o- ramdisk ......................................... [Storage Objects: 0]
  o- iscsi ..................................................... [Targets: 0]
  o- loopback .................................................. [Targets: 0]
  o- vhost ..................................................... [Targets: 0]
  o- xen-pvscsi ................................................ [Targets: 0]

Or is this normal? – And would the WD BIOS/tools/dash board detect and respect an iSCSI target created by targetcli (and not try to 'repair' it)? If not, I'd rather stick to the Linux tools only, of course.
So what do you guys recommend? Does it harm creating iSCSI things with such different tools? And how to make targetcli detect a former existing target?

Further, can I savely use maximum disk space for the target/s, or is it better the safe some more percent of empty/NFS disk space for performance? – I mean, yesterday I created 1 iSCSI target at a size of 3.89 TB  (empty, no partition or data) w/ 3.3 GB of remaining disk space. Since then I got a warning in the dash board because of the disk space consumption, and also 1 LED turned into red.


The Arch wiki is a bit sparingly about targetcli.
So I'm also trying to deal with resources such as:
* RedHat docs
* linux-iscsi.org/wiki/Targetcli
It's much stuff anyway.


Next, I don't really get the purpose of these LUNs. Sure I understand it to be something like an lvm-container. – But where would these come in here, and will I need them at all? Are they optional or obligatory?

I just thought an iSCSI target can contain several LUNs – but when looking at this figure:
iSCSI + luns
it rather seems many iSCSI targets can be combined to a LUN.

So if I created a single iSCSI target would I need any LUNs at all? What are possible use cases?
Where would I begin creating partitions? Is lun0 = 'partition0'?
And do I need a LUN at all to create a(n encrypted) partition, such as only a LUN be encrypted, formatted and mounted, or is it just an optional layer?

So how to proceed with this iSCSI setup?
Thanks in advance!

Offline

Board footer

Powered by FluxBB