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-0005.vcf>