[CentOS] iSCSI disk preperation

[Rob Kampen]

Dr. Ed Morbius wrote:
> on 15:19 Mon 07 Feb, Ross Walker (rswwalker at gmail.com) wrote:
>   
>> On Mon, Feb 7, 2011 at 2:36 PM, Dr. Ed Morbius <dredmorbius at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rkampen.vcf
Type: text/x-vcard
Size: 322 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20110207/8b05cbfc/attachment.vcf>