Configuring iSCSI Logical Units
An iSCSI Logical Unit (LU) is a block of storage that can be accessed by iSCSI initiators as a locally attached hard disk. An LU is stored as a file on the server file system. Like any other data set on the file system, iSCSI LUs can be bound in size using the server's size management tools, including virtual volumes and quotas. LUs are created with a specific initial size but can be expanded over time, as demand requires.
After an LU has been created and the iSCSI domain name has been set, an iSCSI Target must be created to allow access to the LU. A maximum of 32 LUs can be configured for each iSCSI Target.
Logical unit management
An iSCSI LU is a file within one of the server's file systems. Such a file must have an .iscsi extension to identify it as an iSCSI LU. However, apart from this extension there is no other way to determine that a file does indeed represent an LU.
Logical unit security
As LUs are files, they can be accessed over other protocols, such as CIFS and NFS. This renders LUs vulnerable to malicious users who can modify, rename, delete or otherwise affect them.
Concurrent access to logical units
The server's iSCSI implementation allows multiple initiators to connect to a single LU, which is necessary for applications and operating systems that support, or rely upon, concurrent file system access. However, concurrent access can be detrimental to a client machine when the client is unaware of other clients accessing the file system. For example:
- Simultaneous independent updates to the same files. Scenario: Two independent Microsoft Windows clients can connect to the same LU, containing an NTFS file system. Result: If allowed to simultaneously and independently modify data, metadata, and system files, conflicting disk updates will quickly corrupt the file system.
- Simultaneous access to separate partitions. Scenario: An LU contains two distinct NTFS partitions, with one Microsoft Windows client connected only to the first partition, and another connected only to the second partition. Result: Because a Microsoft iSCSI client will attempt to mount each partition it encounters on the LU, a Microsoft Windows client mounting an NTFS partition updates system files on all partitions; therefore, even though the two clients are accessing separate partitions within the LU, both will update system files on both partitions, causing conflicting system file updates, causing one or both of the clients to fail.
Taking snapshots of logical units
The contents of an iSCSI LU are controlled entirely by the client accessing it. The server cannot interpret the file systems or other data contained within an LU in any way. Therefore, the server has no knowledge of whether the data held within an iSCSI LU is in a consistent state. This introduces a potential problem when taking a snapshot of an LU.
For example, when a client creates a file, it must also insert the file name to the host directory. This means that more than one write is required to complete the operation. If the server takes a snapshot after the file object has been created, but before its name has been inserted into the directory, the file system contained within the snapshot will be inconsistent. If another client were to view the snapshot copy of the file system, it would see a file object without a name in a directory. This example provides only one possible scenario for snapshot inconsistency.
Volume full conditions
Unexpected volume full conditions can occur with iSCSI LUs, as illustrated by the following two examples:
- Directly Attached Disks. When a client uses a directly attached disk, it can monitor the amount of available free space. If a partition contains no free space, the client can return a Volume Full condition. In this way, the client can ensure against file system corruption due to running out of disk space part way through an operation.
- iSCSI LU. By way of background, on iSCSI LUs with snapshots enabled, old data is preserved, not overwritten. Therefore, overwriting an area of an LU causes the server to allocate extra disk space, while using no extra disk space within the client's partition, causing a Volume Full condition to occur, even when partitions within the LU contain free space.
Under this scenario, a client may receive a Volume Full condition part-way through an operation, causing file system corruption. Although this corruption should be fixable, this situation should be avoided. Notecustomer support recommends allocating sufficient disk space on the server to contain all iSCSI LUs and snapshots, as well as careful monitoring of free disk space.