First of all, please correct me if you can prove that i need more education !!
My question is, is IP-SAN just a dream ? how far iSCSI reached that goal ? Whats features that iSCSI have, which force to call it a SAN ? I wish to argue that its just a client-server protocol that access block storage over an IP Network. Its just a SAN access protocol, not a SAN itself.
Please beat me professionally, i would appreciate that...:-)
Peter chacko, Principal technologist, Sciendix information systems Pvt.Ltd, Bangalore, India.
Hello,
You are correct that a "SAN" is more than just a protocol. You can create
a "SAN" with SCSI, FC, infiniband, 10GbE, GbE, etc... Where I used to work,
Storage Computer, we could create a SAN with 4x 160MB SCSI ports. They
could all connect to the same volume, thus creating a SCSI SAN. You could
also add 16x FC ports and have a SCSI/FC "SAN".
However, the proof that iSCSI based SANs are here to stay is that sales of
iSCSI SANs continue to grow where others are not. Fibre Channel as a
protocol doesn't have any built in features that make it perfect for SAN
use. In fact, some of its design gets in the way. I.e. replication.
Since you can't route it, you end up having to encapsulate it with TCP/IP to
go across a WAN. Even the FC industry recognizes this. IMHO, that's a
major driving force behind FCoE.
A SAN must provide scalability, and have a feature set that customers want
at a reasonable cost. Modern iSCSI SANs can do just that. In part their
popularity is due to reduced cost to purchase, install and maintain. iSCSI
SAN vendors recognize this and focused on creating easier to setup and
maintain. Some traditional SAN products, require dedicated staff,
installation and maintenance costs are very high. It can cost thousands of
dollars to have your FC SAN reconfigured. Or additional license fees for
their advanced features.
There are even free iSCSI SANs, i.e. ietd, out there. Costing little more
than a PC with local storage, NICs and a small GbE switch.
Is an iSCSI SAN perfect for every customer? Probably not. Is the iSCSI
protocol suitable for SANs? Absolutely.
On Wed, Jun 24, 2009 at 8:59 AM, Peter Chacko <peterchack...@gmail.com>wrote:
> First of all, please correct me if you can prove that i need more
> education !!
> My question is, is IP-SAN just a dream ? how far iSCSI reached that
> goal ? Whats features that iSCSI have, which force to call it a SAN ?
> I wish to argue that its just a client-server protocol that access
> block storage over an IP Network. Its just a SAN access protocol, not
> a SAN itself.
> Please beat me professionally, i would appreciate that...:-)
> Peter chacko,
> Principal technologist,
> Sciendix information systems Pvt.Ltd,
> Bangalore, India.
I'm currently attempting to implement a Dell EqualLogic iSCSI solution connected through m1000e switches to Dell m610 blades with (2) iSCSI dedicated nics in each blade running Oracle VM Server v2.1.5 (which, I believe, is based off of RHEL5.1).
[root@oim6102501 log]# rpm -qa | grep iscsi iscsi-initiator-utils-6.2.0.868-0.7.el5 [root@oim6102501 log]# uname -a Linux oim6102501 2.6.18-8.1.15.3.1.el5xen #1 SMP Tue May 12 19:21:30 EDT 2009 i686 i686 i386 GNU/Linux
I have setup a bond with the two nics to test this out initially and had no problems. This allows for failover (active-passive bond). I discovered my targets, I logged into sessions, and recognized everything from dm-multipath. I fdisked, formatted drives, and mounted them. I then ran lots of dd's to and from the disks with speeds around 90MB/sec when `dd if=/dev/mapper/ovm-1-lun0p1 of=/dev/null bs=1M count=1000`
So since this is going to be one of many VM servers in our OVM cluster with multiple VM's running on it (of which many are database servers), I wanted to try to make this more efficient. Therefore, I read that by using the `iscsiadm -m iface` syntax you can (instead of bonding) setup (2) nics individually, each with an IP on that same segment as your iSCSI storage. From what I understand, this allows (2) sessions to be created to each volume-- which should give you a little more throughput. I did this:
dm-multipath sees 2 paths now to each volume. If I run `iscsiadm -m session -P 3` I can see which /dev/sdX device is used by which multipath device. I have multipath setup to load balance across both paths with rr_min_io set to 10 in /etc/multipath.conf (which it is my understanding that this will send 10 I/Os to one path and then switch to the other path).
my eth2 is 192.168.0.151 my eth3 is 192.168.0.161
my group is 192.168.0.19 my eql interface#1 is 192.168.0.30 my eql interface#1 is 192.168.0.31
[root@oim6102501 log]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.10.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan10 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3 0.0.0.0 10.0.10.254 0.0.0.0 UG 0 0 0 vlan10
PROBLEM: ======== I'm now having some odd issues where everything appears to work fine. I can mount drives and dd stuff around. But then I will occasionally get "Reset received on the connection" from my EqualLogic logs. I will see the same thing in /var/log/messages from my kernel scsi layer as well as dm-multipath layer. When I look at `iscsiadm -m session -P 2` I can see the following:
By the way, is that a bug? "REPOEN"? should it be "REOPEN"?
Within about 1-2 minutes it will reconnect. But I'm a bit baffled what would cause this.
QUESTION: ========= Since I am creating two iscsi sessions (one out eth2 and eth3), I'm wondering how routing plays into sessions. Since iscsiadm is given the hwaddress, does iscsid need to care much about routing? In other words, let's say that, for whatever reason, my session that I had through eth3 (that session, by the way, is connected to 192.168.0.31 on the EqualLogic) timesout. iscsid sees this and attempts to REOPEN the session. Since my routing table shows eth2 above the route for eth3, IP-wise, eth2 will be the interface that would typically be chosen for that traffic to route out of. However, is iscsid smart enough to not use that route and instead select the iface (based on hwaddress) to use for that reconnection?
On Thu, Jul 02, 2009 at 09:41:30AM -0400, Hoot, Joseph wrote:
> Hi all,
> I'm currently attempting to implement a Dell EqualLogic iSCSI solution > connected through m1000e switches to Dell m610 blades with (2) iSCSI > dedicated nics in each blade running Oracle VM Server v2.1.5 (which, I > believe, is based off of RHEL5.1).
> I have setup a bond with the two nics to test this out initially and had > no problems. This allows for failover (active-passive bond). I > discovered my targets, I logged into sessions, and recognized everything > from dm-multipath. I fdisked, formatted drives, and mounted them. I > then ran lots of dd's to and from the disks with speeds around 90MB/sec > when `dd if=/dev/mapper/ovm-1-lun0p1 of=/dev/null bs=1M count=1000`
> So since this is going to be one of many VM servers in our OVM cluster > with multiple VM's running on it (of which many are database servers), I > wanted to try to make this more efficient. Therefore, I read that by > using the `iscsiadm -m iface` syntax you can (instead of bonding) setup > (2) nics individually, each with an IP on that same segment as your > iSCSI storage. From what I understand, this allows (2) sessions to be > created to each volume-- which should give you a little more throughput. > I did this:
> dm-multipath sees 2 paths now to each volume. If I run `iscsiadm -m > session -P 3` I can see which /dev/sdX device is used by which multipath > device. I have multipath setup to load balance across both paths with > rr_min_io set to 10 in /etc/multipath.conf (which it is my understanding > that this will send 10 I/Os to one path and then switch to the other > path).
> my eth2 is 192.168.0.151 > my eth3 is 192.168.0.161
> my group is 192.168.0.19 > my eql interface#1 is 192.168.0.30 > my eql interface#1 is 192.168.0.31
> PROBLEM: > ======== > I'm now having some odd issues where everything appears to work fine. I > can mount drives and dd stuff around. But then I will occasionally get > "Reset received on the connection" from my EqualLogic logs. I will see > the same thing in /var/log/messages from my kernel scsi layer as well as > dm-multipath layer. When I look at `iscsiadm -m session -P 2` I can see > the following:
> By the way, is that a bug? "REPOEN"? should it be "REOPEN"?
> Within about 1-2 minutes it will reconnect. But I'm a bit baffled what > would cause this.
> QUESTION: > ========= > Since I am creating two iscsi sessions (one out eth2 and eth3), I'm > wondering how routing plays into sessions. Since iscsiadm is given the > hwaddress, does iscsid need to care much about routing? In other words, > let's say that, for whatever reason, my session that I had through eth3 > (that session, by the way, is connected to 192.168.0.31 on the > EqualLogic) timesout. iscsid sees this and attempts to REOPEN the > session. Since my routing table shows eth2 above the route for eth3, > IP-wise, eth2 will be the interface that would typically be chosen for > that traffic to route out of. However, is iscsid smart enough to not > use that route and instead select the iface (based on hwaddress) to use > for that reconnection?
You can also use the ethernet interface name, to make sure correct iface is always used.
# iscsiadm -m iface -I iface3 -o new New interface iface3 added
|
