Create Centralized Secure Storage using iSCSI Target / Initiator on RHEL/CentOS 7 – Part 12

If You Appreciate What We Do Here On TecMint, You Should Consider:

  1. Stay Connected to: Twitter | Facebook | Google Plus
  2. Subscribe to our email updates: Sign Up Now
  3. Use our Linode referral link if you plan to buy VPS (it starts at only $10/month).
  4. Support us via PayPal donate - Make a Donation
  5. Support us by purchasing our premium books in PDF format.
  6. Support us by taking our online Linux courses

We are thankful for your never ending support.

Gabriel Cánepa

Gabriel Cánepa is a GNU/Linux sysadmin and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work.

Your name can also be listed here. Got a tip? Submit it here to become an TecMint author.

RedHat RHCE and RHCSA Certification Book
Linux Foundation LFCS and LFCE Certification Preparation Guide

You may also like...

2 Responses

  1. Thomas Williams says:

    That was a good article – thanks Gabriel. I would add a couple things. The iSCSI protocol is very robust, but the applications running on the server have an expectation of high reliability and low latency. After all, iSCSI is emulating a local hard disk, and if the disk were to start having long latency or suddenly disappear, the running applications will likely crash. Having said that, your best chance of success happens when you use an isolated, dedicated network for the iSCSI SAN. That means a dedicated NIC on all of the servers, and a dedicated Ethernet switch for the network. There should be no other traffic on the SAN, and no access to the Internet or the enterprise networks via the SAN. All of the devices on the SAN should be running at the same speed (1Gb, 10Gb, etc.). Do not mix different speed devices on the SAN. The iSCSI will work with 1500 Byte MTU, but you will see better performance with a 9000 Byte MTU on all attached devices. A common problem with iSCSI SAN’s is “out-of-order” frames (it is not supposed to, but yes, it happens). When frames arrive out of order, the receiving NIC must buffer the frames until the missing frame arrives. If the missing frame does not arrive before the buffer overflows, frames are dropped, the sender waits for the timeout period, and then re-transmits all of those frames. To check for re-transmits do “netstat-s” on the sending side.
    To minimize the re-transmit problem, use ethtool to increase the receive buffers on the SAN NICs. The details vary depending on the NIC and driver, but generally it looks like this:

    /etc/sysconfig/network-scripts/ifcfg-em2

    HWADDR=78:2B:CB:19:F2:19
    TYPE=Ethernet
    BOOTPROTO=none
    NETMASK=255.255.255.0
    IPADDR=192.168.130.34
    BROADCAST=192.168.130.255
    MTU=9000
    DEFROUTE=no
    PEERDNS=no
    PEERROUTES=no
    IPV4_FAILURE_FATAL=no
    NAME=em2
    UUID=ec00ad5e-0d34-4b1b-8d33-3fe4c8c39c05
    ONBOOT=yes
    USERCTL=no
    ETHTOOL_OPTS=”-G rx 2047 rx-jumbo 1023″

    The idea here is to increase the receive buffers to the maximum possible size on the SAN NICs.
    Last, you want to use an “Enterprise” class Ethernet switch, meaning non-blocking on all ports and large packet buffers. One example is Dell PowerConnect 4000 series. There are many others that work too, but avoid those small, cheap, office grade switches.

    The iSCSI SAN is a viable alternative to Fiber-Channel when done correctly. It also has a much smaller price tag. I hope this helps.

    -Thomas

    • @Thomas,
      Thank you for such an insightful and informative comment. I appreciate the time you put into it and would like to thank you again on behalf of the Tecmint community.
      Best,
      Gabriel

Got something to say? Join the discussion.

Your email address will not be published. Required fields are marked *

Join Over 300K+ Linux Users
  1. 177,942
  2. 8,310
  3. 37,548

Are you subscribed?