Can discovery be done without overwriting customizations?

2009-08-04 Thread Ty! Boyack

Folks,

I really fear this one is a FAQ somewhere, but I can't find the answer 
to it.

My problem is that discovering new targets overwrites any custom 
settings that have been applied to targets that already exist on a given 
portal.

Here is the sequence of events I'd like to do:

1) Create an iscsi target in our iscsi SAN (based on IET).
2) On the server that wants to use that target, do 'iscsiadm -m 
discovery...' to discover the target.
3) We use chap, so set the username/password with 'iscsiadm -m node 
-T... -o update...'
4) Log in and use that target.
(Up to here everything is great)
5) Sometime in the future (hours to months) add a new target in the 
iscsi SAN.
6) On the same server, do a discovery to discover this new target.
7) Set the username/password for the new target.
8) Log in to the new target and use the new target.

The problem is that when we do the discovery in step 6, it wipes out the 
username/password and any other customizations we've put in the record 
for the target that was discovered in step 2.  When we have only a few 
targets it's easy enough to reset all the username/passwords, but this 
is going to get cumbersome when we have quite a few targets.

Is there a way to discover a new target without overwriting the existing 
target database?

Thanks,

-Ty!

-- 
-===-
   Ty! Boyack
   NREL Unix Network Manager
   t...@nrel.colostate.edu
   (970) 491-1186
-===-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [LIST:open-iscsi] SAN

2008-08-26 Thread Ty! Boyack

I have done something similar in a home-rolled SAN, and am fairly 
pleased with the results.  I wasn't sure from your post if you were 
looking to build the in-band virtualization, or if you you had a switch 
that was capable of doing that.  I could not afford a specialized 
iscsi-switch, so I used stock ethernet switches and built my own in-band 
virtualization system.  Hopefully my experience can be of some use to you.

I use IET (iSCSI Enterprise Target) on boxes with internal disk arrays 
to make 4 iscsi targets.  Then I connect this across bonded interfaces 
and twp IP fabrics to an in-band virtualizer (two, actually, running in 
fail-over mode).  The job of this virtualizer is similar to what you are 
looking for, I think. 

Our virtualizer acts as an iscsi initiator to the 4 iscsi target 
devices, and joins them into one large raid5 device.  I then use LVM to 
carve out the virtual disks, and present them as iscsi targets to 
other systems.  If you did the same thing with raid1 (mirrored) targets, 
then an iscsi request would read in a round-robin fashion from the two 
in-sync targets at your remote locations.

The problem that I ran into was in keeping performance high.  You end up 
passing the data through a lot of layers 
(hardware-iscsi-multipath-software raid-lvm-iscsi-multipath-OS).  
If you want to ENSURE that your data lands safely on the disk, then you 
have to turn off the software caching along the way, and this really 
hurt my performance.  I now run with caching enabled in the virtualizer 
iscsi target, and performance is much better.  But if you do that you 
need to make sure that your virtualizer does not crash, or you will 
loose the dirty blocks in the cache.

I was looking for a generalized solution to hook to many different 
servers.  If you are only dealing with one application then you should 
be able to get pretty good performance by careful tuning.

The good side of going in-band is that it is generally easier and less 
invasive, since there are no agents to install in every OS to manage the 
out-of-band controls.  But the downside is that all your data must flow 
through the in-band system and that can slow things down.

Now, if you are looking at doing this inside of an iscsi-capable switch, 
then the same issues apply.  An iscsi-capable switch is like my setup, 
but they have wrapped my virtualizer and my stock ethernet switches into 
one device (which is far more specialized than my generic devices).  You 
still should look at how they handle caching in the switch, and how well 
you can tune and protect that.

One other thought -- is this necessary?  If you are just looking to read 
off of two iscsi targets that have the same data, then it might be 
simpler just to connect your server to the two iscsi targets in the SAN 
and use raid/multipath.  That should take the OS system call to read the 
data, and split that into iscsi commands that pull from each of the 
targets.  This takes some setup on the server, but it would be much simpler!

-Ty!


varun wrote:
 I am thinking of a design to improve performance of SAN. To do this i
 am thinking of an in band switch based virtualization which recieves
 an ISCSI request and splits the request into two and simultaneously
 reads data from two insync  disk at remote locations. tell me is this
 solution feasible !! and i want software based solution with minimum
 hardware involvement ! tell me how out of band storage virtualization
 can help me in this ??
 
   


-- 
-===-
  Ty! Boyack
  NREL Unix Network Manager
  [EMAIL PROTECTED]
  (970) 491-1186
-===-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: How to find out initiator connections?

2008-04-15 Thread Ty! Boyack

I'm sure that is dependent on what type of target you run - since you 
are here in the open source world, I'll venture that the iSCSI 
Enterprise Target (IET) is at least a possibility for your target.  If 
that is the case, on your target box there is some information in /proc:

cat /proc/net/iet/volume
will show which targets have been created and their parameters.

cat /proc/net/iet/session
will show the active iSCSI sessions between an initiator and target.  
This is probably what you are looking for.  Note that the initiator is 
only listed by IQN name here - you don't get an IP or any other info 
about the initiator.  So if you are pxebooting you might have to take 
some extra step to get a good initiator name assigned on the initiator.  
(Kept in /etc/iscsi/initiatorname.iscsi for open-iscsi).

-Ty!

vincenzo romero wrote:
 Thanks Konrad, I will try to do that too!

 - V

 On Mon, Apr 14, 2008 at 11:01 PM, Konrad Rzeszutek
 [EMAIL PROTECTED] wrote:
   
  On Mon, Apr 14, 2008 at 06:00:40PM -0700, v i n c e wrote:
  
   Hello all,
  
   Wanted to check if my initiators are connecting to the targets that I
   have passed on to them (pxebooting to iSCSI root).

  Vince,

  You might have better luck getting an answer to your question on the
  iSCSI _Target_ mailing list.



  

 



   


-- 
-===-
  Ty! Boyack
  NREL Unix Network Manager
  [EMAIL PROTECTED]
  (970) 491-1186
-===-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---