[CentOS] iSCSI disk preperation
Rob Kampen
rkampen at kampensonline.com
Mon Feb 7 22:37:07 UTC 2011
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>
More information about the CentOS
mailing list