The NAS supports the built-in Internet Small Computer System Interface (iSCSI) service for use in server clusters and virtualized environments.

From this page, users can enable / disable iSCSI service, change iSCSI portal port, enable / disable iSNS service, and list and manage all iSCSI targets and LUNs. The NAS supports multiple iSCSI targets and multiple LUNs for a single target. You can mount and unmount iSCSI LUNs for a specific purpose. This chapter contains the following sections.

The following table summarizes the features supported by block LUNs and file LUNs.

		File LUN (old type)
Full copy by VAAI	Supported	Supported
Zeroing blocks according to VAAI	Supported	Supported
VAAI hardware lock	Supported	Supported
Thin configuration and space reclamation according to VAAI	Supported	Not supported
Thin provisioning of capacity	Supported	Supported
Freeing up space	Supported (by VAAI or Windows 2012 / Windows 8)	Not supported
Microsoft ODX	Supported	Not supported
LUN backup		Supported
LUN Snapshot	Supported	1 Snapshot

Note that block LUNs generally provide better system performance and therefore it is recommended to use block LUNs where possible.

There are two ways to allocate LUNs: thin provisioning and flash provisioning.

Up to 256 iSCSI targets and LUNs can be created. For example, if 100 targets are created on the NAS, then the maximum number of LUNs available for creation is 156. Multiple LUNs can be created for each target. However, the maximum number of concurrent connections to iSCSI targets supported by the NAS differs depending on the network infrastructure and application performance. Too many concurrent connections can impact NAS performance.

ISCSI Quick Setup Wizard

To configure the iSCSI target service on the NAS, follow these steps.

6.

Specify the authentication options and click Next. If you enable the Use CHAP Authentication option, the iSCSI target will only authenticate to the initiator and will be prompted for the username and password specified here to access the target. Enabling the Shared CHAP option enables two-way authentication between the target and the iSCSI initiator. The target authenticates the initiator using the first set of username and password. The initiator authenticates the target using the options specified in the Shared CHAP section. The username and password in both fields have the following restrictions.

Creating iSCSI Targets

Follow these steps to create an iSCSI target.

5.

Provide a username and password for the Use CHAP Authentication and / or Shared CHAP option and click Next. If you enable the Use CHAP Authentication option, the iSCSI target will only authenticate to the initiator and will be prompted for the username and password specified here to access the target. Enabling the Shared CHAP option enables two-way authentication between the target and the iSCSI initiator. The target authenticates the initiator using the first set of username and password. The initiator authenticates the target using the options specified in the Shared CHAP section.

Create iSCSI LUN

Follow these steps to create a LUN for an iSCSI target.

To create an unmapped iSCSI LUN, select the Do Not Assign To Target option in step 4.

An unbound LUN will be created and displayed in the unbound iSCSI LUN list.

The table below provides a description of all iSCSI targets and LUN states.

Position	State	Description
ISCSI target	Ready	The iSCSI target is ready, but no initiator is connected to it.
	Connected	An initiator is attached to the iSCSI target.
	Disabled	Connections to the iSCSI target have been dropped.
	Offline	The iSCSI target is disabled, connections from initiators are not possible.
	Included	The LUN is enabled for connection and is visible to authorized initiators.
	Turned off	LUN is deactivated and not visible to initiators.

The following table describes the actions available to manage iSCSI targets and LUNs (Action button).

Action	Description
Disable	Disable a target that is in the Ready or Connected state. Please note that all connections from initiators will be dropped.
Activate	Activation of a target that is offline.
Change	Change target settings: target alias, CHAP information, and checksum settings. Change LUN settings: LUN allocation, name, disk volume directory, etc.
Delete	Removing an iSCSI target. All connections will be dropped.
Disable	Disable LUN. All connections will be dropped.
Turn on	Enabling LUN.
Untie	Unbinding a LUN to a target. Note that you must disable the LUN first before unbinding the LUN. Clicking this button will move the LUN to the list of unassociated iSCSI virtual LUNs.
Bind	LUN binding to iSCSI target. This feature is only available for the list of unassociated iSCSI LUNs.
Show connections	View the connection status of the iSCSI target.

Switching iSCSI LUNs Between Targets

Follow these steps to switch iSCSI LUNs between targets.

After creating iSCSI targets and LUNs on the NAS, you can use the iSCSI initiator installed on the computer (Windows PC, Mac, or Linux) to connect to the iSCSI target and LUNs and use disk volumes as virtual disks on the computer.

Expanding iSCSI LUNs

The NAS supports iSCSI LUN expansion. To do this, follow these steps.

Abstract: how open-iscsi (ISCSI initiator in linux) works, how to configure it, and a little about the ISCSI protocol itself.

Lyrics: There are many articles on the Internet that explain quite well how to set up an ISCSI target, however, for some reason, there are practically no articles about working with an initiator. Despite the fact that target is technically more complicated, there is more administrative fuss with the initiator - there are more confusing concepts and not very obvious principles of work.

ISCSI

Before talking about ISCSI - a few words about different types of remote access to information in modern networks.

NAS vs SAN

There are two methods of accessing data located on another computer: file (when a file is requested from a remote computer, and no one cares about which file systems it is done), typical representatives of NFS, CIFS (SMB); and block - when blocks are requested from a remote computer from disk media (similar to how they are read from a hard disk). In this case, the requesting party makes a file system on the block device on its own, and the server giving the block device does not know about the file systems on it. The first method is called NAS (network attached storage), and the second is called SAN (storage area network). The names generally indicate other signs (SAN means a dedicated network before storage), but it so happened that NAS are files and SANs are block devices over the network. And although everyone (?) Understands that these are incorrect names, the further, the more they become fixed.

scsi over tcp

One of the protocols for accessing block devices is iscsi. The letter "i" in the title does not refer to Apple products, but to Internet Explorer. At its core, it is "scsi over tcp". The SCSI protocol itself (without the letter "i") is a very complex design, since it can work through different physical media (for example, UWSCSI is a parallel bus, SAS is a serial bus - but they have the same protocol). This protocol allows you to do much more than just "plug disks into the computer" (as invented in SATA), for example, it supports device names, the presence of several links between the block device and the consumer, support for switching (yeah, a SAS switch, such is in nature), connecting several consumers to one block device, etc. In other words, this protocol was simply asking for as the basis for a network block device.

Terminology

The following terms are adopted in the SCSI world:
target is the one who provides the block device. The closest analogue from the ordinary computer world is a server.
initiator- the client, the one who uses the block device. Analogue of the client.
WWID- unique identifier of the device, its name. An analogue of a DNS name.
LUN- number of the "piece" of the disk, which is being accessed. The closest analogue is a partition on a hard disk.

ISCSI brings the following changes: WWID disappears, in its place comes the concept of IQN (iSCSI Qualified Name) - that is, a pure name that is confusingly similar to DNS (with minor differences). Here is an example IQN: iqn.2011-09.test: name.

The IETD and open-iscsi (Linux server and client) bring another very important concept that is most often not written about in the iscsi manuals - portal. Portal is, roughly speaking, several targets that are advertised by one server. There is no analogy with www, but if a web server could be asked to list all of its virtualhosts, that would be it. Portal specifies a list of targets and available IPs that can be accessed (yes, iscsi supports multiple routes from initiator to target).

target

This article is not about target, so I give a very brief description of what target does. He takes a block device, slips the name and LUN to it and publishes it on his portal, after which he allows everyone (authorization to taste) to access it.

Here is an example of a simple configuration file, I think it will be clear from it what target does (a configuration file using the IET example):

Target iqn.2011-09.example: data IncomingUser username Pa $$ w0rd Lun 0 Path = / dev / md1

(complex differs from simple only in export options). Thus, if we have a target, then we want to connect it. And this is where the tricky part begins, because the initiator has its own logic, it does not at all look like a trivial mount for nfs.

Initiator

Open-iscsi is used as the initiator. So, the most important thing is that he has operating modes and condition... If we issue a command in the wrong mode or ignore the state, the result will be extremely discouraging.

So, the operating modes:

• Search target "s (discovery)
• Connect to target "y
• Working with a connected target

From this list, the life cycle is quite understandable - first find, then connect, then disconnect, then reconnect. Open-iscsi keeps the session open even when the block device is not in use. Moreover, it keeps the session open (up to certain limits, of course), even if the server goes into reboot. An iscsi session is not the same as an open TCP connection, iscsi can transparently reconnect to the target. Disconnect / Connect are operations that are controlled externally (either from other software or by hand).

A little about the state. After discovery open-iscsi remembers all found targets (they are stored in / etc / iscsi /), in other words, discovery is a permanent operation, NOT at all appropriate, for example, dns resolving). Found targets can be deleted by hand (by the way, a common mistake is when open-iscsi , as a result of experiments and settings, a bunch of found target "s, when trying to login into which a lot of errors creep out due to the fact that half of the target" s are old config lines that have not existed on the server for a long time, but I remember open-iscsi) Moreover, open-iscsi allows you to change the settings of the memorized target "a" - and this "memory" affects further work with the target "s even after the daemon is rebooted / restarted.

Block device

The second question that torments many at first is where does it end up after connecting? open-iscsi creates, though a network, but a BLOCK SCSI class device (it’s not for nothing that it is "I say"), that is, it receives a letter in the / dev / sd family, for example, / dev / sdc. The first free letter is used, because for the rest of the system, this is a block device - a typical hard drive, no different from the one connected via usb-sata or just directly to sata.

This often causes panic "how can I find out the name of the block device?" It is printed in the verbose output of iscsiadm (# iscsiadm -m session -P 3).

Authorization

Unlike SAS / UWSCSI, iSCSI is available for anyone to connect. To protect against such, there is a login and password (chap), and their transfer to iscsiadm "y is another headache for novice users. It can be done in two ways - by changing the properties of the previously found target" and registering the login / password in the configuration file open-iscsi.
The reason for this difficulty is that the password and login process are not attributes of the user, but of the system. ISCSI is a low-cost version of the FC infrastructure, and the concept of "user" in the context of a person at the keyboard does not apply here. If your sql-base is on the iscsi block device, then of course you will want the sql-server to start itself, and not after a minute of the operator's personal attention.

configuration file

This is a very important file, because in addition to the login / password, it also describes the behavior of open-iscsi when it finds errors. It may give an error "back" not immediately, but with some pause (for example, about five minutes, which is enough to reboot the server with data). It also controls the login process (how many times to try, how long to wait between attempts) and any fine tuning of the work process itself. Note that these parameters are quite important for work and you need to understand how your iscsi will behave if you remove the power cord for 10-20s, for example.

Quick reference

I do not really like to quote easily found mana and lines, so I will give a typical scenario for using iscsi:

First, we find the target we need, for this we need to know the IP / dns name of the initiator: iscsiadm -m discovery -t st -p 192.168.0.1 -t st is the send targets command.

Iscsiadm -m node (list found for login)
iscsiadm -m node -l -T iqn.2011-09.example: data (login, that is, connect and create a block device).
iscsiadm -m session (list what connected to)
iscsiadm -m session -P3 (output it, but in more detail - at the very end of the output there will be an indication of which block device belongs to which target).
iscsiadm - m session -u -T iqn.2011-09.example: data (log out of a specific one)
iscsiadm -m node -l (log into all detected targets)
iscsiadm -m node -u (log out of all targets)
iscsiadm -m node --op delete -T iqn.2011-09.example: data (remove target from found).

mulitpath

Another issue that is important in serious decisions is the support of multiple routes to the source. The beauty of iscsi is that it uses a regular ip, which can be processed in the usual way like any other traffic (although in practice it is usually not routed, but only switched - the load is too heavy there). So, iscsi supports multipath in "no resist" mode. By itself, open-iscsi does not know how to connect to several IPs of one target "a. If it is connected to several IPs of one target" a, then this will lead to the appearance of several block devices.

However, there is a solution - this is multipathd, which finds disks with the same identifier and processes them as expected in multipath, with customizable policies. This article is not about multipath, so I will not explain the mystery of the process in detail, however, here are some important points:

1. When using multipath, set small timeouts - switching between failing paths should be fast enough
2. In conditions of a more or less fast channel (10G and higher, in many cases gigabits), load parallelism should be avoided, since the ability to use bio coalesing is lost, which in some types of load can unpleasantly hit the target.

If you have ever managed servers or a corporate computer network, then you probably faced the problem of transparently increasing the capacity of the existing infrastructure. Although such solutions do exist in principle, they usually have a high cost and low flexibility.

19 "systems usually do not have enough space to accommodate additional hard drives. As a result, there is only one alternative: connecting separate 19 ″ storages to the server via SCSI or Fiber Channel. However, we still mix server tasks and data storage functions.

And large server enclosures with additional hard drive bays are not ideal either - again, this is a mixture of tasks.

Agree that the ideal storage should be very flexible. So that it can be easily deployed, used from many parts of the network, from different operating systems and, of course, can be easily expanded. And performance shouldn't be overlooked either. The answer to all these questions can be called iSCSI - Internet SCSI. This solution packs the SCSI protocol into TCP / IP packets, giving you a universal storage interface for your entire network infrastructure. In addition, iSCSI allows you to consolidate your current storage systems.

How does iSCSI work?

The diagram shows how iSCSI works. Storage subsystems must use the existing network infrastructure, independent of the servers. The storage consolidation we mentioned above only means that the storage must be accessible from any server, ensuring that management costs are minimized. In addition, additional capacity can be added to existing systems.

The advantages of this approach are many, and they are pretty obvious. Many corporations already have efficient networking infrastructure deployed, often using proven technologies such as Ethernet. There is no need to deploy or test any new technologies to use iSCSI or other storage area networks (SANs). Of course, you can also save on expensive implementation specialists here.

In general, any network administrator can manage iSCSI clients and servers with a little training. After all, iSCSI is deployed on existing infrastructure. In addition, iSCSI is highly available because iSCSI servers can be connected to multiple switches or network segments. Finally, the architecture is inherently highly scalable thanks to Ethernet switching technologies.

In principle, an iSCSI server can be implemented in both software and hardware. But due to the high load of the software solution on the processor, it is better to stick to the latter option. The main load on an iSCSI server is encapsulating SCSI packets in TCP / IP packets, and everything must be done in real time. It is clear that in the software server all these tasks will be performed by the central processor, and in the hardware solution - by special TCP / IP and SCSI engines.

Thanks to the iSCSI client, the storage resources of the iSCSI server can be integrated into the client system as a device that is meaningfully close to the local hard drive. Here, a great advantage over the usual shared network folders (share) will be high security. After all, iSCSI emphasizes the correct authentication of iSCSI packets, and they are transmitted over the network in encrypted form.

Of course, you will get slightly less performance than local SCSI systems - the network introduces its own latency. However, modern networks with a bandwidth of up to 1 Gb / s (128 MB / s) already provide sufficient speed, but most of it is never used.

Each iSCSI host is assigned a name (up to a maximum of 255 bytes in length) and an alias (short name), which are independent of the IP address. Thus, access to the storage will be provided even after it is moved to another subnet.

iSCSI in action

Of course, apart from the network, the main requirement for iSCSI implementation is the iSCSI server. We tested several solutions, both software and hardware.

Both types of solutions meet all iSCSI requirements by providing access to storage to client computers. The client system can be equipped with an iSCSI adapter, which will reduce the load on the central processor (very convenient for workstations).

In principle, iSCSI can be used on a 100 Mbps network, but then, compared to local drives, you will get a significant slowdown. Naturally, Gigabit Ethernet is a much more efficient solution - it is unlikely that bandwidth will become a bottleneck even when using multiple RAID 5 arrays. At the same time, the same cannot be said about RAID 0 arrays, but such storage is rarely connected over the network.

If you go to the customer, an iSCSI initiator is needed here. They are released for almost all operating systems. A Google search for the combination of the words "Microsoft", "iSCSI" and "Initiator" is a good example of this.

Then, in the initiator program, you need to configure the connection to the server. The connected server drives will appear on the computer as hard drives, and they can be used like ordinary drives.

ISCSI provides IPsec-based packet encryption, although it is optional. For example, inside a corporate network, it doesn't always make sense to encrypt packets. This option will be most interesting for the WAN.

Additional applications

iSCSI is also an excellent backup tool as information can be easily copied to another hard drive. Including, even online, using the Windows shadow copy function. iSCSI can even be connected over a DSL connection, but here the line speed will already be the limiting factor. However, it all depends on the nature of the application.

The big benefit of iSCSI is that classic redundancy is no longer limited to a single location — and shouldn't be underestimated. For example, devices such as cassette tape drives can now be installed anywhere on the network. Even if the worst happens, iSCSI data can be recovered in no time.

If the iSCSI solution is implemented in software, then the network adapter will have to transfer a lot of data. Since conventional network adapters do not always use different hardware acceleration technologies, some of the load can be shifted to the central processor. SCSI is a block protocol and Ethernet is a packet protocol. That is, a lot of the workload will go into encapsulating and extracting SCSI information from TCP / IP packets. Such a task can load even a modern processor to capacity.

To solve the problem, special TOE engines (TCP / IP Offload Engines) were developed, which take over all complex iSCSI operations immediately after the network adapter. As a result, the load on the system processor is reduced and users and the system can continue to operate normally.

Hopefully now it has become a little clearer what network storages on iSCSI are and how they are arranged.

With the advent of Fiber Channel and SANs built on top of it, the storage world has relied on networked access to storage systems. Almost all unanimously declared that the future belongs to storage networks. For several years, the FC interface remained the uncontested standard for their construction, but today many understand that the time for change is coming. There are a couple of serious drawbacks in FC-based SANs - the cost and problems of access to geographically (at a distance of more than hundreds of kilometers) remote devices. Recently, a number of initiatives have emerged that are at the stage of standardization and are designed to solve or bypass these problems. The most interesting of them is iSCSI.

The iSCSI letter combination is increasingly making its way onto the pages of newspapers and brochures from leading storage vendors. Take a look at the resources dedicated to storage, and you will definitely see it. But after looking at articles and news, you will most likely find a lot of completely opposite statements: some present iSCSI as the undeniable leader for storage networks in the not too distant future, others have given up on it even before its birth.

Sun Opposed IP Storage

Sun has opposed IP Storage. Sun Microsystems will not release over IP storage systems. Mark Kanepa, Sun's VP of All Storage Manufacturing, said the other day that IP Storage was just a "dream", Byte and Switch reports.

Kanepa said that “ it is impractical to use TCP / IP for SAN organization due to the higher latency in such networks. Even if IP-based storage networking has a future, it will come in three to five years, and it may never come. A stream from storage systems cannot run on top of a general-purpose protocol stack, it has special needs. The technological challenges of implementing TCP / IP are much greater than most people think. That's why we at Sun are betting on Fiber Channel", he said. Until now, no storage vendor has taken such a clear position against IP Storage. Sun's competitors, Hewlett-Packard and IBM, are more or less actively supporting these technologies.

HP promises iSCSI support

« The final version of the new technology is expected to appear in the first quarter of 2002, ”said Mark Thompson, head of networked storage systems at HP. The corporation intends to introduce a wide range of products that support the iSCSI standard, designed to integrate storage systems over IP networks ...»

HP acknowledges that Fiber Channel customers are comfortable with the upgraded FCIP technology rather than iSCSI. But at the same time, HP believes that experience with IP-based solutions, and especially Ethernet, will make iSCSI products attractive to many customers.

Computerworld, # 35/2001: "Federated Storage Systems"

IBM launches iSCSI-based product

IBM TotalStorage IP Storage 200i provides direct connection of Ethernet LAN drives. This high-speed storage system supports the new industry standard iSCSI, which enables the transfer of SCSI protocol over IP.

Well, such contradictory messages leave us no choice but to figure it out ourselves and independently weigh all the "FOR" or "AGAINST".

iSCSI

« iSCSI (Internet Small Computer System Interface) is a TCP / IP-based protocol designed to communicate and manage storage systems, servers and clients».

iSCSI describes:

• A transport protocol for SCSI that runs on top of TCP
• New mechanism for encapsulating SCSI commands in an IP network
• Protocol for a new generation of storage systems that will use native TCP / IP

Indignation immediately arises, I want to sort everything out in separate piles. As one of my teachers used to say: "Cutlets separately, flies separately." The fact is that the rules for delivering packets in IP and SCSI are absolutely opposite. In IP, packets are delivered to the recipient without observing a strict sequence, he also recovers the data, which consumes certain resources. At the same time, according to the SCSI specification, as a channel interface, all packets must be transmitted one after another without delay, and violation of this order leads to data loss. Despite the fact that, according to some experts, this problem brings ambiguity to the practical use of iSCSI technology, a number of devices have already been implemented that confirm its viability. The engineers who worked on iSCSI were able to solve this problem in a certain way. The iSCSI specification requires an increase in packet header sizes. Additional information is included in the header, which greatly speeds up the assembly of the packages.

According to one of the iSCSI fans, Haymore, a senior systems engineer at the University of Utah, the main obstacle to the spread of Ethernet as a basic technology for building storage networks is the relatively long latency (close to 75 microseconds), which arises from the peculiarities of the TCP / IP stack. ... On high-end systems, when accessing thousands of files at the same time, this can be a serious problem.

Those who work on iSCSI understand the significance of the latency problem. And despite the fact that a lot of tools are being developed to reduce the influence of parameters that cause delays in the processing of IP packets, iSCSI technology is positioned for building mid-range systems.

iSCSI is evolving very quickly. The need for a new standard was felt so strongly that in just 14 months since the IETF's February 2000 iSCSI proposal, enough devices have emerged to demonstrate their interoperability. In July 2000, Draft 0 on iSCSI was published, which was the beginning of work on the implementation of the technology. In January 2001, within the framework of the SNIA (Storage Networking Industry Association), the IP Storage Forum was created, which in six months already had 50 members, and in April of the same year a product was presented, which soon won the "Enterprise Networking Product" award.

What is so great about iSCSI that it finds support among the grandees of the computer industry, regardless of the contradictions existing within the standards.

Some of the most important storage applications and functions are:

Tasks that are effectively implemented using modern methods:

Consolidation of storage systems Data backup Server clustering Replication (duplication) Disaster recovery

New capabilities that are effectively implemented using IP Storage:

SAN Geographic Distribution QoS Security

At the same time, new storage systems, for which iSCSI will be the native protocol, will create many more advantages:

Provides a unified technology for connecting storage systems, servers and clients within LAN, WAN, SAN; Significant industry experience in Ethernet and SCSI technologies; Possibility of significant geographic separation of storage systems; Ability to use TCP / IP network management tools

Moreover, to transfer data to storage with an iSCSI interface, you can use not only media, switches and routers of existing LAN / WAN networks, but also ordinary network cards on the client side. However, this results in significant overhead costs of processing power on the client's side, which uses such a card. According to the developers, the software implementation of iSCSI can achieve the speeds of the Gigabit Ethernet data transmission medium with a significant, up to 100% load of modern CPUs. In this connection, it is recommended to use special network cards that will support mechanisms to offload the CPU from processing the TCP stack. At the time of this writing (June 2002), these cards were produced by Intel.

Intel PRO / 1000T IP Storage Adapter is offered by Intel for 700USD each. This device contains a powerful Xscale processor, 32M memory and carries out the transfer of computations related to the iSCSI and TCP / IP protocols, as well as the calculation of checksums of TCP, IP frames to the integrated processor. Its performance, according to internal tests of the company, can reach 500Mbit / s with 3-5% load on the CPU host system.

Let's take a closer look at iSCSI

Figure 1. IP network using iSCSI devices

In the example shown in Figure 1, each server, workstation, and drive supports an Ethernet interface and an iSCSI protocol stack. To organize network connections, IP routers and Ethernet switches are used.

With the introduction of SAN, we have been able to use the SCSI protocol in network infrastructures, providing high-speed data transfer at the block level between multiple SAN elements.

Internet Small Computer System Interface also provides block access to data, but not independently, but over TCP / IP networks.

The conventional SCSI architecture is based on a "client" / "server" model. A "client" such as a server or workstation initiates requests to read or write data from an executor - a "server" such as a storage system. The commands issued by the "client" and processed by the "server" are placed in the Command Descriptor Block (CDB). The "Server" executes the command, and the end of its execution is indicated by a special signal. Encapsulation and reliable delivery of CDB transactions between initiators and executors over a TCP / IP network is the main task of iSCSI, and it has to be carried out in an unconventional, potentially unreliable IP network environment for SCSI.

This is an iSCSI protocol layer model that provides an understanding of how SCSI commands are encapsulated for transmission over physical media.

Figure 2. Model of the lower layers of the iSCSI protocol

The iSCSI protocol monitors the transfer of blocks of data and provides confirmation of the validity of the completion of the I / O operation. Which, in turn, is provided through one or more TCP connections.

iSCSI has four components:

• Management of names and addresses (iSCSI Address and Naming Conventions).
• Session Management (iSCSI Session Management).
• ISCSI Error Handling
• Security (iSCSI Security).

Name and address management

Since iSCSI devices are members of an IP network, they have individual Network Entities. A Network Entity can contain one or more iSCSI Hosts.

Figure 3. Network entity model

The iSCSI host is the identifier for SCSI devices (in the Network Entity) that are accessible over the network. Each iSCSI node has a unique iSCSI name (up to 255 bytes), which is formed according to the rules adopted for identifying nodes on the Internet. For example: "fqn.com.ustar.storage.itdepartment.161". Such a name has a human-readable form and can be processed by a Domain Name Server (DNS). Thus, the iSCSI name ensures that the iSCSI device is correctly identified regardless of its physical location. At the same time, in the process of monitoring and transferring data between devices, it is more convenient to use a combination of IP address and TCP port, which are provided by the Network Portal. The iSCSI protocol, in addition to iSCSI names, provides support for aliases, which, as a rule, are displayed in administration systems for easy identification and management of system administrators.

Session management

An iSCSI session consists of the Login Phase and the Full Feature Phase, which is completed by a special command.

The iSCSI authentication phase is similar to the Fiber Channel Port Login (PLOGI) process. It is used to negotiate various parameters between two Net Entities and to validate the initiator's access right. If the iSCSI authentication phase succeeds, the executor confirms the login to the initiator, otherwise the login is not confirmed and the TCP connection is closed.

As soon as login is confirmed, the iSCSI session proceeds to the exchange phase. If more than one TCP connection has been established, iSCSI requires each command / response pair to go through one TCP connection. This procedure ensures that each individual read or write command will be executed without the need to additionally monitor each request as it passes through different streams. However, different transactions can be simultaneously transmitted over different TCP connections within the same session.

Figure 4. Example iSCSI Write

At the end of the transaction, the initiator sends / receives the last data, and the executor sends a response that confirms the successful data transfer.

If it is necessary to close the session, the iSCSI logout command is used, which transmits information about the reasons for the session termination. It can also send information about which connection to close in case of a connection error in order to close problem TCP connections.

Error processing

Due to the high probability of errors during data transmission in some types of IP networks, especially WAN implementations in which iSCSI can function, the protocol provides for a lot of error handling measures.

In order for error handling and crash recovery to function correctly, both the initiator and the executor must be able to buffer commands until they are confirmed. Each end device must be able to selectively recover a lost or corrupted PDU as part of a transaction to recover data transmission.

The hierarchy of iSCSI error handling and disaster recovery includes:

1. At the lowest level - error detection and data recovery at the SCSI task level, for example, retransmission of a lost or damaged PDU.
2. At the next level, an error may occur in the TCP connection that transfers the SCSI task, namely, the TCP connection may be damaged. In this case, an attempt is made to reestablish the connection.
3. Finally, the iSCSI session itself can get corrupted. Termination and restoration of the session, as a rule, is not required if the restoration is processed correctly at other levels, however, the opposite may occur. This situation requires closing all TCP connections, completing all tasks, underperforming SCSI commands and restarting the session through a repeated login.

Security

Due to the use of iSCSI on networks where unauthorized access to data is possible, the specification provides for the use of a variety of methods to improve security. Encryption tools such as IPSec, which use the lower layers, do not require additional negotiation because they are transparent to the upper layers, including iSCSI. For authentication, a variety of solutions can be used, for example, such as Kerberos, or the exchange of Private Keys, an iSNS server can be used as a key repository.

Others (iFCP, FCIP)

As part of work on network storage technologies in the Internet Engineering Task Force (IETF), an IP Storage (IPS) working group was created in the following areas:

• iSCSI (Internet Small Computer Systems Interface)
• FCIP (Fiber Channel over TCP / IP)
• iFCP (Internet Fiber Channel Protocol)
• iSNS (Internet Storage Name Service)

And also, as already noted, in January 2001, an IP Storage Forum was organized within the SNIA (Storage Networking Industry Association). Today the forum includes three subgroups: FCIP, iFCP, iSCSI. Each of which represents a protocol that is under the protection of the IETF.

FCIP- a tunnel protocol based on TCP / IP, the function of which is to connect geographically distant FC SANs without any impact on FC and IP protocols.

iFCP- created on the basis of TCP / IP protocol for connecting FC storage systems FC storage networks, using IP infrastructure together or instead of FC switching and routing elements.

iSCSI- considered above ...

For a better understanding of the positioning of these three protocols, we present a block diagram of the networks built using them.

Figure 5. Block diagram of IP storage networks

Fiber Channel over IP

The least revolutionary of the three above is Fiber Channel over IP. It makes almost no changes to the structure of the SAN and the organization of the storage systems themselves. The main idea of ​​this protocol is to realize the possibility of combining geographically distant storage networks.

This is what the FCIP protocol stack looks like:

Figure 6. Lower layers of the FCIP protocol

FCIP helps to effectively solve the problem of territorial distribution, and SAN interconnection over long distances. Its main advantages are that this protocol is completely transparent for existing FC SAN networks and is focused on using the infrastructure of modern MAN / WAN networks. Thus, to provide new functionality, users looking for opportunities to link geographically distant FC SANs will only need a FCIP gateway and a MAN / WAN connection. A geographically distributed SAN built using FCIP is perceived by SAN devices as an ordinary FC network, and for the MAN / WAN network to which it is connected, it represents ordinary IP traffic.

The Draft Standard of the IETF IPS Working Group - FCIP defines:

• rules for encapsulating FC frames for transmission over TCP / IP;
• rules for using encapsulation to create virtual communication between FC devices and FC network elements;
• a TCP / IP environment to support virtual link creation and tunneling FC traffic over an IP network, including security, data integrity, and data rate issues.

Among the applied tasks that can be qualitatively solved using the FCIP protocol: remote backup, data recovery and shared data access. When using high-speed MAN / WAN communications, you can also successfully apply: synchronous data duplication and shared distributed access to data storage systems.

iFCP

Internet Fiber Channel Protocol is a protocol that provides FC traffic over TCP / IP transport between iFCP gateways. In this protocol, the FC transport layer is replaced by the IP network transport, traffic between FC devices is routed and switched using TCP / IP. The iFCP protocol provides the ability to connect existing FC storage systems to an IP network with support for the network services that these devices need.

The iFCP protocol stack looks like this:

Figure 7. Lower layers of the iFCP protocol

iFCP Specification:

• overlays FC frames for their transport on a predefined TCP connection;
• FC messaging and routing services overlap in the iFCP gateway device, so the network structures and FC components do not merge into a common FC SAN, but are managed by TCP / IP;
• dynamically creates IP tunnels for FC frames

An important feature of iFCP is that it enables FC device-to-device communication (communication between devices) over an IP network, which is significantly more flexible when compared to SAN-to-SAN communication. So, for example, if an iFCP has a TCP link between the N_Port pairs of two FC devices, that link may have its own QoS level, which will be different from the QoS level of the other pair of FC devices.

Conclusion

Summing up, I would like to express my firm belief that Fiber Channel will not disappear anywhere in the near future, the FC SAN market will grow and develop. At the same time, IP Storage protocols will provide the ability to efficiently use SANs in those applications for which FC cannot provide an efficient implementation. Using FCIP and iFCP protocols, storage networks will become geographically dispersed. And the introduction of iSCSI, in turn, will provide an opportunity to take advantage of the SAN in areas that still remain unrealized, or are implemented ineffectively within the framework of today's technologies.

P.S.

The rapid development of storage networks has become the basis for the formation of the concept of the World Wide Strorage Area Network. WWSAN is a worldwide storage area network and provides an infrastructure that will provide high-speed access and storage of data distributed around the world. The concept is very close to the WWW existing today, but it is based on other services. One of the original examples is the service of a "manager" who travels around the world with presentations. WWWSAN provides for the transparent movement of "mobile" data following the personal movement of its owner around the world. Thus, wherever the "manager" is, he will always be able to get high-speed access to the data he needs, the work with which will not require complex, sometimes very inefficient synchronization via the WWW.

It is safe to say that the concept of building a worldwide storage area network fits perfectly with the development of modern IP storage technologies.

Terms and abbreviations:

• SAN - Storage Area Network
• CDB - command descriptor block, command descriptor (description) protocol.
• PDU - Protocol Data Unit - protocol data unit, protocol data unit.
• QoS - abbr. from Quality of Service, the quality and class of data transmission services provided (usually describes the network in terms of delay and signal bandwidth).
• SNIA - Storage Networking Industry Association, an association of the storage networking industry.
• DNS - Domain Name Server, domain name server.
• PLOGI - Fiber Channel Port Login.
• iSCSI - Internet Small Computer Systems Interface
• FCIP - Fiber Channel over TCP / IP
• iFCP - Internet Fiber Channel Protocol
• iSNS - Internet Storage Name Service
• WWSAN - World Wide Strorage Area Network

Literature:

• SAN after Fiber Channel - Lucas Merian. 02/12/2002: Computerworld, # 05/2002;
• IP Storage Tutorial, - SNIA;
• iSCSI Technical White Paper, - SNIA;
• Internet Fiber Channel Protocol (iFCP) - A Technical Overview, - SNIA;
• Storage Forum, - HP EMEA, June 12-13, 2002.

After five years of working with Fiber Channel storage area networks (SANs), I have been deeply puzzled by the advent of iSCSI: what it does and, more importantly, how it works, and how iSCSI can be used to solve real-world user problems. So, after several strenuous months of talking with many experts on this topic, I present in this article a few of my own views on iSCSI.

What exactly is iSCSI?

iSCSI sends SCSI commands in IP packets. In more detail, iSCSI is designed as a protocol for a storage initiator (usually a server) to send SCSI commands to an executor (usually a tape or disk) over IP.

Other protocols: FCIP - Sends Fiber Channel blocks over IP, essentially extending Fiber Channel connections; actually has nothing to do with SCSI. On the other hand, iFCP provides mapping of FCP (serial SCSI over Fiber Channel) to and from IP. In other words, it offers a Fiber Channel (fabric) interconnect protocol that allows connections over IP.

In other words, iSCSI is a SCSI over IP protocol that connects the server to the storage. Other protocols provide Fiber Channel to Fiber Channel interconnection with varying degrees of intelligence.

How do iSCSI devices find each other?

In the case of regular SCSI connections and Fiber Channel loops, the device discovery method is quite primitive. For Fiber Channel (fabric) networks, there is a necessary service called a Simple Name Server, or simply a domain name server that works with hundreds or thousands of devices. But in IP, theoretically, there could be several million devices.

There are two iSCSI device discovery mechanisms currently in use in the IP world. The first is SLP (service locator protocol) - a protocol of the TCP / IP family that allows automatic configuration of various resources. This service discovery protocol has been around in the IP world for some time. Recently, however, many vendors, including Microsoft, have begun to develop a new protocol - Internet Simple Name Server. In simple terms, it was based on the principles of a simple domain name server for Fiber Channel and then scaled up to the extent that it can handle the size of IP networks, while at the same time, without losing the storage features of SLP.

How can iSCSI be used?

There are three main ways to use iSCSI:

1. Dedicated iSCSI server accessing dedicated iSCSI storage.
2. A dedicated iSCSI server accessing Fiber Channel attached storage via an iSCSI-to-Fiber Channel router.
3. Fiber Channel server accessing iSCSI storage via a Fiber-Channel-to-iSCSI router.

Of course, in some cases Fiber Channel storage accesses other Fiber Channel storage (for example, for disk copy or off-host backup) and the iSCSI storage device can also access each of them.

So which is the most likely and / or practical to use? To answer this question, you need to step back a little and remember that networked storage requires flexibility, using products in different ways. Today, the use of iSCSI in servers is relatively new but simple given Microsoft's support for Windows Server 2000 and 2003.

For this reason, one way to use iSCSI is to use iSCSI servers attached to existing Fiber Channel storage through an iSCSI-to-Fiber Channel router, most likely on a Fiber Channel SAN. This means that the same ports on the same storage arrays can provide storage service for both Fiber Channel and iSCSI servers. As such, it allows you to get more value out of SAN and Fiber Channel storage than you have, and you can do it right now — the market has all the products you need.

According to my assumptions, similar events will occur in the NAS market, in fact, they are already happening. Since NAS devices already connect drives to IP networks, sharing services through Network File System (NFS) and / or Internet Common File Access Protocol (CIFS), it is enough for NAS to simply transfer data at the block level through the same ports using iSCSI , which again allows you to use existing storage solutions in new ways.

There are several other - interesting and non-standard solutions waiting for the emergence of storage specialized exclusively for iSCSI, which can work perfectly in a new place where storage consolidation has not yet been carried out, and there are only products of one solution.

Who Will Use iSCSI?

As a Fiber Channel expert with several years of experience, I unfortunately have to point out to the Fiber Channel world that iSCSI can run at wire speed and can definitely run as fast as any normal server running tasks. any normal application. For the IP community, it is necessary to note the significant prevalence of Fiber Channel, especially when comparing their number with the number of 1 GB network ports, rather than with the number of other network ports. The Fiber Channel community needs to point out that while many storage and even a significant number of powerful servers are connected to Fiber Channel, there are a number of unconnected Unix servers and a huge number of Intel servers that do not work with Fiber Channel.

So iSCSI can work for everyone, but perhaps the largest potential market is Intel servers, and high-density and ultra-thin servers (Intel or otherwise). In addition, iSCSI can sometimes be used for high-performance servers, in the case of remote offices to access the central datacenter via a SAN, and in other cases where it is too early to use Fiber Channel, after all, there are still many offline servers and storage. data.

NIC, TOE and HBA: When Should You Use Them?

In conclusion, there are three approaches to server connection:

1. Standard interface card (NIC) with iSCSI driver
2. TOE (TCP Offload Engine) NIC with iSCSI driver
3. Host Bus Adapters (HBAs) designed for iSCSI by traditional Fiber Channel adapter manufacturers.

When should you use each of them? Interest Ask. The initial assumption is that the more performance you need, the more likely you are to use a TOE card or node bus adapter instead of a standard interface card (NIC), which will of course be more expensive. There is another point of view, suggesting that some high-performance servers have sufficient clock cycles, so why not save some money and use a cheap network card.

The key point here is that, unlike Fiber Channel adapters, iSCSI pricing ranges from low (free) to high performance (accelerators) and thus can be tailored to meet application requirements. Also, the output load capacity (fan-out or oversubscription) allows the use of more economical Ethernet ports (both fast and GE) instead of dedicated FC switch ports, which further reduces costs. With iSCSI TOE cards priced at $ 300 or less, host connection costs are significantly lower than with FCs, even for TOE performance.

Since FC can run at 2Gbps, Fiber Channel is preferable for high-end servers (2Gb Ethernet doesn't exist), although to be honest, there aren't many servers out there that use this bandwidth, even on Fiber Channel. Of course, from a storage perspective, 2Gbps is more likely to be used until we see 10GB FC or even 10GB Ethernet / iSCSI ports. iSCSI opens the door to hundreds and thousands of servers, especially Intel systems, many of which may be less demanding, and many more will still benefit from networked storage.

Only time will tell exactly what will happen, although one thing is for sure - this will be a very exciting year for networked storage and for iSCSI.