Re: iSCSI disk preperation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Dr. Ed Morbius wrote:
on 15:19 Mon 07 Feb, Ross Walker (rswwalker@xxxxxxxxx) wrote:
On Mon, Feb 7, 2011 at 2:36 PM, Dr. Ed Morbius <dredmorbius@xxxxxxxxx> wrote:
<snip>
If a best practices doc could be handed to you right now, what would
you like it to contain?

<grin>

I've got about 35 pages of that document sitting on my local HD now.
Negotiating with management about releasing some of it in some form or
another.

It's based on some specific vendor experience (Dell MD3200i), and
CentOS.  Among the problems: I suspect there's a range of experiences
and configuration issues.

I would suspect that it would be different whether your setting up an
initiator or a target, so maybe start by splitting it into two
sections.

Absolutely -- if you're setting up your own target, you've got a set of
problems (and opportunities) not facing those with vendor-supplied kit
with its various capabilities and limitations.


Basics:

  - Terminology.  I found the Wikipedia article and the Open-iSCSI
    README to be particularly good here.

  - Presentation of the devices.  It took us a while to realize that we
    were going to get both a set of raw SCSI devices, AND a set of
    multipath (/dev/dm-<number>) devices, and that it was the latter we
    wanted to play with.  We spent a rediculous amount of time trying to
    debug and understand what turned out to be expected and correct
    behavior, though this was either undocumented or very unclearly
    documented.  How much of this is specific to the MD3xxxi kit with
    its multiple ports and controllers isn't clear to me.

  - Basic components.  For us these were vendor tools (and identifying
    which of these were relevant was itself non-trivial), iscsiadm,
    multipath, and the CentOS netfs config scripts / environment.
    The device-mapper-mulitpath docs are shite.

  - Overview of target and initiator setup:  phyisical, cabling, network
    topology (a dedicated switched LAN or vLAN being recommended, away
    from core network traffic).

  - As appropriate: multipath, its role, where it is/isn't needed, what
    it provides.

  - Target-side set-up, including virtual disk creation, RAID
    configuration, network configuration, host-to-LUN mapping, IQN
    generation / identification, CHAP configuration (if opted), etc.

    I'd slice this into Linux/CentOS target configuration (specific
    tasks), preceded by a more generic "things you'll want to take care
    of" section.  If people/vendors want to fill in their specific
    configuration procedures in additional sub-sections, that would be
    an option.

  - Initiator-side set-up:  installation of base packages, verifying
    iscsi functionality, verifying multipath functionality, verifying
    netfs functionality.  Preparing storage (partitioning, filesystem
    creation).

  - Target discovery from initiator.  CHAP configuration (if opted),
    session log-in, state querying, log out.  DiscoveryDB querying,
    update, manipulation.

  - Configuring/disabling persistent / on-login iscsi sessions.

  - Not applicable to us, but booting to an iscsi-mounted root
    filesystem.

  - Log / dmesg error/informative messages, interpretation, debugging.

  - What to do when things go wrong.  An all too infrequent
    documentation section.

  - Monitoring and assessment.  "How can I tell if I'm properly
    configured", target/initiator-side error/issue reporting.  Good ways
    to tie into existing reporting systems/regimes (SNMP, Nagios, Cacti,
    ...).

  - Peformance issues.

  - Security.  Best I can tell this divides into:
    - Session authentication (CHAT/CHAP)
    - Target/initiator host security (specific to protocols used to
      access either).
    - Physical and network security -- not necessarily related, but the
      point being that iSCSI traffic and hardware should generally be
      isolated.  I'm not aware of encrypted network transports, though I
      suspect some sort of socket forwarding or IPSEC could be layered
      in.
    - Fileystem encryption.  I'd suspect this would be managed
      client-side, though implications on network datastreams should
      probably be noted.  Hrm... if it _is_ handled client-side, the
      network traffic should by ciphertext, not clear.

If nothing else, this should make a good framework for developing useful
docs -- the Christmas tree from which to hang the ornaments.  It's
rather much how my own document started -- unanswered questions /
unclear elements of the configuration, filled in by research and
experience.

I would be happy to draft something up and put it on a wiki somewhere,
but I would need a list of talking points to start with.
How's this do you?
Excellent - just reading the synopsis helped me get some things straight - any chance of adding this to the CentOS wiki HowTo section?
I for one would be a greatful recipient
begin:vcard
fn:Rob Kampen
n:Kampen;Rob
org:Team Torman Realty, LLC
adr:;;13019 Water Point Blvd;Windermere;FL;34786;USA
email;internet:rkampen@xxxxxxxxxxxxxxxxxxxx
tel;work:407-876-4108
tel;fax:407-876-3591
tel;home:407-876-4854
tel;cell:407-341-3815
note:LCAM & CPM Candidate
url:www.robkampen.com
version:2.1
end:vcard

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux