[TriLUG] iscsi setup

Ben Pitzer bpitzer at gmail.com
Mon Sep 25 12:22:27 EDT 2006


Very good point.  Keeping your IP SAN traffic separate keeps you from having
to worry about trying to troubleshoot network issues on your main subnet
caused by the heavy iSCSI traffic, or from trying to isolate another source
for issues on the IP SAN network.

-Ben Pitzer


On 9/25/06, OlsonE at aosa.army.mil <OlsonE at aosa.army.mil> wrote:
>
> In addition, it is highly advised to either segment out your iSCSI
> network on a VLAN, or a private switch.
>
> -----Original Message-----
> From: trilug-bounces at trilug.org [mailto:trilug-bounces at trilug.org] On
> Behalf Of Ben Pitzer
> Sent: Monday, September 25, 2006 10:59 AM
> To: Triangle Linux Users Group discussion list
> Subject: Re: [TriLUG] iscsi setup
>
> You could say I've done it once or twice.  So basically, here's the deal
> on the iSCSI options that you have:
>
> 1. Software initiator, native TCP stack
>       Pro:  Free, functional, typically fairly stable so long as you
> have a solid initiator software
>       Con:  Just getting access to your disks, before you even do any
> I/O, puts a load on your proc and memory 2. Software initiator, TOE (TCP
> offload engine) card
>       Pro: Still somewhat inexpensive.  Offloads all of the TCP work to
> the TOE card.  No native stack, so less system load for disk access.
> TOE cards can also be used for things other than iSCSI, so hardware
> costs are not completely lost if you go another direction.
>       Con:  Still some load on the system from the initiator software.
> TOE cards aren't exactly cheap.  Must confirm the TOE card's
> compatibility with your OS.
> 3.  iSCSI HBA card
>       Pro:  Fast.  All of the iSCSI and TCP work are done on the card.
> Also usually pretty stable.
>       Con: Expensive.  This can cost you almost as much as a fiber HBA.
> They only work at GigE.  They also can't be used for any other purpose
> if you decide to scrap the IP SAN later on.
>
> So cost and feasibility are required studies here.  Additionally, keep
> in mind that many vendors do not support IP link aggregation (NIC
> teaming, port bonding, whatever you want to call it) for IP SAN
> implementations.  Given the nature and sensitivity of the signal on the
> wire, I would not recommend using an IP SAN over a 10/100 network.  GigE
> is the way to go, period.
> Remember, this is a local disk so far as the OS is concerned, so the
> faster the media between host and disk the better.
>
> As far as backing up your iSCSI target LUN, it will depend on the
> vendor.
> NDMP will transfer at the block level, so that might be your best bet.
> It'll depend on what you're backing up, and where to.  What type of IP
> SAN target vendor are you looking at?  NetApp?  EMC?  OpenFiler?
> Somebody else?  We can talk about this more directly if you want.  Just
> let me know off list.
>
> -Ben Pitzer
>
>
> On 9/24/06, Jason Tower <jason at cerient.net> wrote:
> >
> > anyone have experience with iscsi on linux (both initiators and
> targets)?
> > trying to find out some best practices for running a backend server
> > (iscsi
> > target) to multiple clients (initiators).  any significant pros/cons
> > to using iscsi specific hardware HBAs?  the transport will probably be
>
> > 100mb ethernet to start, moving to gigabit as needed.
> >
> > also, what options exist for backing up my primary iscsi target to
> > another system?  are there tools that provide rsync-like capabilities
> > but at the block instead of the file level?
> >
> > jason
> > --
> > TriLUG mailing list        :
> http://www.trilug.org/mailman/listinfo/trilug
> > TriLUG Organizational FAQ  : http://trilug.org/faq/ TriLUG Member
> > Services FAQ : http://members.trilug.org/services_faq/
> >
> --
> TriLUG mailing list        :
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/ TriLUG Member
> Services FAQ : http://members.trilug.org/services_faq/
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>



More information about the TriLUG mailing list