Knowledge Base


Search by either entering keywords or by selecting a product.

Configuration and Usage of iSCSI Volumes on a Buffalo TeraStation


iSCSI, which stands for Internet Small Computer System Interface, works on top of the Transport Control Protocol (TCP) and allows SCSI command to be sent end-to-end over local area networks. iSCSI works by transporting block-level data between an iSCSI initiator on a server and an iSCSI target on a storage device. The iSCSI protocol encapsulates SCSI commands and assembles the data in packets for the TCP/IP layer. Packets are sent over the network using a point-to-point connection. Upon arrival, the iSCSI protocol disassembles the packets, separating the SCSI commands so the operating system (OS) will see the storage as a local SCSI device that can be formatted as usual.

Examples iSCSI Usage

Here are some instances where iSCSI can be used to provide a useful storage alternative:


1. Adding storage to an existing server.

In this case, you may be running short of space on an existing server and don't want to have to reconfigure your network or have users change what path they use to access the existing server. Connecting a RAID backed iSCSI volume will allow you to add terabytes of storage to an existing server without shutting it down or adding physical drives. This is especially useful if the server lacks bays to add additional drives.


2. Providing storage with domain-level file and folder permissions.

If you have a need for volumes with NTFS permissions at the file or folder level, a standard TeraStation cannot provide this. By using iSCSI volumes attached to a Windows server, the volume can be formatted with an NTFS file system and administered the same as any other Windows volume.


3. Providing storage for a cluster.

Depending on the OS used on the clustered hosts, you can use iSCSI volumes on a TeraStation or another WSS NAS to provide storage for a high availability cluster. For VMware (ESXi) hosts, any TeraStation that supports iSCSI can provide storage to a cluster. If you need to run a Windows cluster (for applications like Hyper-V, SQL, or Exchange) you will need host the iSCSI target on a WSS based unit.


Rules for iSCSI

While iSCSI can provide a useful and efficient supplement to straight NAS functionality, there are some hard and fast rules that must be followed as well as some recommendations to increase performance and manageability.


1. Do not connect multiple Windows hosts to a single iSCSI volume.

This is the biggest mistake many users make with iSCSI devices. Windows uses the NTFS file system, which is not designed to be shared between hosts. Remember that iSCSI provides a block-level storage device to the host. To the OS it appears as a physical drive installed in the system. The only time that multiple Windows hosts should be connected to the same iSCSI volume is when the volume is providing storage for a failover cluster. For Buffalo devices this is only possible with a WSS-based NAS.

If you connect multiple Windows hosts to the same iSCSI volume without the benefit of MS Cluster Services to arbitrate disk access, it will result in data corruption because none of the hosts will notify each other of open files, reads, writes, or changes to the master file table. It's not a matter of if data corruption will occur - it's a matter of when.

One way to ensure that only one host is allowed to connect to the volume is to configure CHAP authentication, either one way or mutual. A link to an article explaining how to set this up is included at the end of this document.


2. Always use the correct startup and shutdown sequence.

Try to avoid having the iSCSI target (storage device) shut down while the server is still accessing it. Imagine disconnecting a hard drive from a computer in the middle of a write operation. The result will often be data loss or data corruption. When shutting down, always shut down the server(s) first, then the storage device and the switch(es) last. When starting up go in the reverse order: switch, storage, server. Make sure that each device is fully booted before moving on the next one. It is strongly recommended that all components are connected to a UPS to prevent connection loss due to a power outage. If the storage device has multiple power connections, such as the TS7120, it is recommended to connect each power supply to a different power source if possible.


NOTE: In the event that an iSCSI volume gets disconnected/reconnected from a Windows server that has shared folders on the iSCSI volume, restarting the "server" service in the services.msc snapin should re-activate the shares.


3. Do not team or trunk ports used for iSCSI.

Because of the way that iSCSI sessions are created and managed, NIC teaming or trunking will reduce the performance of iSCSI. Instead of teaming set up multiple NICs and use MPIO settings in the host's iSCSI initiator to configure multipath options. This will result in overall better performance and better utilization of multiple network paths.


4. Segregate iSCSI traffic from the rest of the LAN.

While not required, it is recommended to segregate iSCSI to a separate LAN segment, either by creating a separate VLAN or by using physically separate switches. The nature of iSCSI generates a tremendous amount of network traffic and keeping the iSCSI traffic separate will increase the performance of both the iSCSI LAN and the regular LAN. 

5. Optimize switch configuration

It is recommended to have flow control and RSTP enabled on all switch ports used for iSCSI.

 6. Jumbo frames

Enabling jumbo frames can increase performance in iSCSI environments but is not a panacea. If you are seeing very poor performance in your iSCSI environment, enabling jumbo frames will not be likely to improve performance and may degrade performance even further. The use of jumbo frames can increase performance in environments where performance is already good and all other parameters are optimal, but in some rare cases it can actually degrade performance in an otherwise well-performing environment.

Rules for using iSCSI volumes as shared storage in a clustered environment

While iSCSI can be extremely useful as shared storage for a cluster, there are some rules you need to keep in mind when planning/configuring the cluster.

1. Windows clusters can't use iSCSI volumes on a standard TeraStation for cluster storage.

Standard TeraStation devices do not support the use of SCSI-3 persistent reservations on iSCSI volumes. This is a requirement to pass the validation tests on a Windows cluster. If you need to create shared storage for a Windows cluster you will need to use a TeraStation running WSS (Windows Storage Server) instead of a standard TeraStation.


2. VMware (ESXi) clusters can use iSCSI volumes on a standard TeraStation.

If you are planning an ESXi cluster for a virtualized environment, you should have no problem using iSCSI volumes on any TeraStation products to provide the storage. Because ESXi uses VMFS (VMware File System) for datastores there is no need for persistent reservations. VMFS is a shareable file system and all attached hosts can lock the parts they are currently accessing to prevent other hosts from making changes and causing data corruption.


For more information, please see these articles:

Creating an iSCSI target on a Buffalo TeraStation

Configuring an iSCSI target in WSS 2008

Configuring an iSCSI target in WSS 2012 R2

Configuring Mutual CHAP Authentication with a Buffalo TeraStation and a Windows Host

Configuring the iSCSI Initiator in Windows Server 2008

Configuring the iSCSI Initiator in Windows Server 2012

Configuring the Software iSCSI Initiator in an ESXi 5.x Host that Contains a Single NIC

Configuring the Software iSCSI Initiator in an ESXi 5.x Host that Contains Multiple NICs

Why can't I set file-level permissions on my TeraStation?

Configuring Mutual CHAP Authentication with a Buffalo TeraStation and a Windows Host

X