Hi there, as we're finalizing the LPIC-3 objectives, there is one last update on 305.
Based on the your input regarding storage I've drafted a new topic 352.2, Cluster Storage Access. Besides DM-MPIO it also re-introduces iSCSI and cLVM (sorry Markus, sorry Michael, feel free to recap your concerns on the list). iSCSI is already included in LPIC-2 so it shouldn't be too much hassle for our candidates, cLVM is a quite limited topic but together they build a nice frame for multipathing. I've taken the three weights from 351.2, 351.3 and 353.3 (all of them were changed from 9 to 8). Please check the new objective out and let me know what you think. I also added 'Awareness of traffic shaping and control capabilities' of Linux to 354.4. It's as detailed as suggest on the other thread since the exam is already quite loaded, but i f you want to suggest another level of detail or moving some weights from another topics, please follow up. Looking forward to your feedback, Fabian On Mon, Apr 1, 2019 at 11:11 PM Bryan Smith <[email protected]> wrote: > To go one step further, I'd even have Device Mapper (DM) as it own, major > subject, say 355 - (or renumerate and make it 351). > > 35x Advanced Device Mapper > 35x.1 - Advanced LVM (aka DM-LVM2, at least since kernel 2.4+) > 35x.2 - Multipath I/O (aka DM-MPIO) > 35x.y - Other/Future Device Mapper facilities > > There are various Device Mapper solutions out there, expanding more every > day in the Upstream. As those solutions mature, they can be added. > > Examples, for starters? > > - Stratis, which is an Upstream project built around largely DM that adds > what a lot of Red Hat installations have long asked for - - the ability to > better 'manage' storage. This may catch on with many distributions over > time (it's in RHEL8, still trying to get it back ported to RHEL7). > > - LVM-integrated Raid - - not the old 'dm-raid,' but the newer, but > little known, Device Mapper RAID that actually uses the Multi Disk (MD) > subsystem to manage the blocks, but the meta-data/"container" is in > DM-LVM2. It solves the long-standing, old problem with old 'dm-raid' > (which some distros still use for firmware/fake RAID - - yikes!) that > cannot rebuild, whereas MD can. > > Understanding kernel Device Mapper is really what both LVM and MPIO are > built around. > > > > > > -- > Sent from my Essential PH-1, please excuse any typos > Bryan J Smith - http://linkedin.com/in/bjsmith > > > > On Mon, Apr 1, 2019, 15:53 Bryan Smith <[email protected]> wrote: > >> On Mon, Apr 1, 2019, 04:11 Fabian Thorns <[email protected]> wrote: >> >>> I just wanted to point out that there is an updated version of the >>> LPIC-305 objectives draft... The following changes were made compared to >>> the initial version of the draft: >>> * cLVM was dropped from 352.1 >>> >> >> So, this one is where I'd like to focus on. I don't think we can do >> everything that, say RH436, does. But I think there are some very >> necessary 'identification/knowledge' (weight 1) that should be included. >> >> Understand that Cluster LVM (CLVM, and the daemon, clvmd) enables a lot >> of multi-host communication, and introduces a lot of extensions. E.g., if >> you ever read my work, you'll see I have "vgchange -al[ny]" and "lvchange >> -al[ny]". The first thing people ask me is, "what does 'l' mean?" >> >> There is also the fact that pvmove, among other operations, works >> differently for clustered LVM, basically using cluster mirroring. I.e., it >> has to mirror an extent as it does a pvmove, then break it after the move, >> and that means cluster mirroring is involved. >> >> Pacemaker is also heavily involved in managing these services as well. >> >> So, again, I don't know if we need to cover everything, but the concepts >> of local v. clustered LVM identification, and what functions of Pacemaker >> are used to manage things like the CLVM and the Distributed Lock Manager >> (DLM) so people don't mess with them, might be a good >> 'identification/knowledge' level weight (1). >> >> If anything, to save my sanity, as I catch people not realizing what that >> little 'c' flag means when they run 'vgs.' >> >> _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev -- Fabian Thorns <[email protected]> GPG: F1426B12 Director of Certification Development, Linux Professional Institute
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
