Harald Maaßen wrote: > That's an interesting question. I think iSCSI is not to enterprise-y > (nice word :-), because it can be implemented with non expensive hardware. > Fibre Channel is an expensive technology, so I would perfer this topic in LPIC-3.
Ingo Wichmann wrote: > Not to cross the line of "non expensive hardware" seems like a good idea to me. > But if iSCSI, why not DRBD, AoE and NBD? In LPIC1, a student should have > "Knowledge of basic features of LVM". I think, in LPIC2 "Knowledge of basic > features of iSCSI, DRBD, AoE and NBD" would be sufficient. I'd avoid to ask for > specific tools here. I look at things in a client v. server analysis, which I feel is more "objective" than "subjective." When people start talking about "cost," that gets really subjective. Storage is an advanced platform concept, so in my view ... 200-level: Clients -- e.g., - GPL iSCSI initiators - GPL Kernel DeviceMapper (DM) integrated/support facilities such as LVM, MPIO, etc... - etc... 300-level: Services -- e.g., - block software-based storage like DRDB, FCoE, iSCSi, etc... - service software-based storage** like Ceph, Gluster, etc... - Cloud APIs** like Apache Hadoop/MapReduce, OpenStack Swift/UFO, etc... - etc... Reinier Kleipool wrote: > Well if you say FC, you are talking enterprise, thus resiliency thus > multipath... As many agree on this list. To accommodate "people > from around the world" we should only test it at the conceptual level. > * Purpose of MP. > * Name of OSS implementation. No configuration. > * Understand that vendors may use other tools The "identification" sounds like CompTIA Server+ and Storage+, Bloom'ss "Knowledge" only [1]. I've always understood LPI to focus on higher levers than just the basic "Knowledge," but also "Comprehension" and "Application." I guess that's why I'm really "scratching my head" when I see these types of posts. I would consider a CompTIA program to be about "Knowledge" only (6 months experience), whereas LPI is at least 1, 2 and 3 -- with corresponding weights, respectively -- as it is far more involved (18-24 and 36+ months experience at level 1 and 2, respectively). I know understanding of DeviceMapper (DM) Device and Volume Management facilities is considered "optional" by a lot of "enthusiasts," but under I've seen understanding of either LVM and MPIO considered "optional" in neither "low-cost" nor "costly hardware" shops. To me, it's just DeviceMapper -- something I have to understand at boot, at run-time, for failover, for performance -- whether DM-LVM, DM-MPIO or any other faciliity. There's nothing "special" about MPIO, just like LVM. It's just a set of DeviceMapper approaches for devices, both udev and labeling as well as bringing devices on or off-line, rescanning busses, etc... I.e., if you didn't know, DeviceMapper is _always_ used to define devices, slices (partitions), logical addressing, contiguous blocks, etc... in kernel 2.6+, whether you understood or not, whether you modified udev rules, lvm.conf, etc... or not. ;) If you have a server, regardless of "FibreChannel," knowing how these work -- for on-line reconfiguration -- is a critical and _common_ to sysadmin functions. E.g., Just Section 24, "Online Storage Mangaement," in RHEL6's "Storage Administration Guide" is a perfect example of "day-to-day, client-only," knowledge that I _expect_ sysadmins to know. When I say "expect," I mean, when people don't know these things, or follow their step-by-step for on-line storage reconfiguration (and much applies to local disks, not just iSCSI, FC, etc...), they usually have _data_loss_. ;) Again, being a fluent Microsoft Windows Server 2008 or 2012 professional (enough that my employer pulls my SoW enough saying, "he does open source, and cannot be your Windows Server AD and Infrastructure architect"), understanding NT6's MPIO is _not_ optional in environments either. NT6's MPIO is just an extension of Microsoft's existing SCSI HAL layer, and designed to address the "vendor in-fighting" (stomping on each other) much like DM-MPIO did in the Linux world, using Device Specific Modules (DSM) from vendors with MPIO. Again, I _expect_ people to _know_ what is in a lvm.conf at 200-level. They should also know what a serial number is in udev, the scsi_id output, etc...and how it factors into lvm.conf, multipath.conf, etc... and other Kernel DeviceMapper facilities and support. Matt Rice wrote: > http://wiki.lpi.org/wiki/LPIC-2_BoK > Unfortunately, I'm the only one that added a chapter :( > Honestly, this is why I'm in favour or a recertification programme such as > for the PMP and/or CISSP ... It would be nice to see a CBoK that not just all open source vendors, but even open standards groups, could contribute to so all open standard interfaces and all open source technologies that implement them could be considered. But that would take commitment and investment by open source vendors. -- bjs [1] http://en.wikipedia.org/wiki/Bloom's_Taxonomy#Cognitive [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Storage_Administration_Guide/index.html#idm43844088 **NOTE: Understand my role since the beginning of the year has been the _primary_ Storage (Gluster) Subject Matter Expert (SME) in my organization for IHV and Cloud partners, so knowledge of services-based solutions built around Storage (Gluster), including OpenStack SWIFT UFO, MapReduce for Apache Hadoop (with no NameNode server, as Gluster does not require a meta-data server), NFSv3/4.1-pNFS, SMB 1.0/2.0. So as much as I'd _love_ to see things into 200-level, I think "services" should be left to a consideration for a 300-level course. I.e., I'm "holding back," especially since Service Software-based Storage (like Gluster w/oVirt) is crucial to Cloud (like OpenStack) on both public and private HyperVisors (like KVM w/oVirt stack). E.g., And for those that don't think KVM is "catching on," as IBM pointed out here this week at Summit, 95% of all OpenStack deployments are KVM-based. KVM is going on Power and other platform beyond x86. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
