The 90% ratio is most probably caused by the fact that companies willing to send employees to training and pay several thousands of euro for this, also afford and have an SAN.
I am not an advocate for Powepath , or do I have something against multipathd. I am just stating what I have seen (and it was Rhel 5 at that time). It does get political and at least back then you had the choice of either fighting with RedHat or EMC. Plus you also need to take into account that in some enterprises they will also have Solaris, AIX running Powerpath and a sysadmin group trying to get things to a standard level; the whole point of mentioning this is that things are not black and white and it doesn't always matter which is the best or most capable technical solution. If we are talking about virtualization in the enterprise, generally it's done with VMware and then the Linux guest is not booting off the SAN or being directly connected. I know Bryan will say he disagrees , but he works for RedHat and they sell KVM based solutions :) . In the last two years I have used only KVM and Xen (working for an smb) but this doesn't change the fact that large enterprises use VMware. I think that the SAN topic is directly coupled with large enterprises and even there I still stand by my statement that it's not as common as it may be thought (at least in my experience it wasn't and I doubt I managed to find only employers which stay away from SANs). I know HA clusters will use a SAN , in the enterprise but ... most of the Linux machines are not part of HA clusters. In the SMB world you will at most encounter iSCSI. Regards, Alexandru On Fri, Jun 7, 2013 at 3:39 PM, Sander van Vugt <m...@sandervanvugt.nl>wrote: > I get about 300 people a year on the Linux courses I give. My estimate is > that 90% connects their servers to a SAN. LPIC level 2 without any SAN > topics in my opinion is like LPIC level 2 without any Apache… > Powerpath is not done in enterprise Linux like Red Hat and SUSE. > Installing powerpath gives a tainted kernel, the multipathd in current > distro's does an excellent job without breaking kernel level support. > > Regards, > Sander > > From: Alexandru Ionica <alexandru.ion...@gmail.com> > Reply-To: "This is the lpi-examdev mailing list." <lpi-examdev@lpi.org> > Date: Friday, June 7, 2013 12:08 PM > To: "This is the lpi-examdev mailing list." <lpi-examdev@lpi.org> > Subject: Re: [lpi-examdev] Where is Fibre Channel / iSCSI > > Hello, > > I tend to disagree that many Linux installations use a SAN. In my > experience most of the installations don't use a SAN. The few that use a > SAN generally use the vendor's own multipath software (for example > Powerpath) due to contractual/support needs and also feature set and > because of this (vendor tools) you can't put it in LPI. > > > > On Fri, Jun 7, 2013 at 10:33 AM, Reinier Kleipool < > rein...@opensourceacademy.eu> wrote: > >> IMHO I think that many Linux installations use a SAN. Don't you think it >> is a bit strange that an LPIC-2 Certified engineer has no knowledge about >> this common technology? Of cause there is a lot to tell about SAN's, but an >> LPIC-2 person SHOULD be able to attach a SAN LUN to a system. There is >> nothing "300" level about that, it is not advanced. >> >> We are now discussing a new revision for the 200 level topics. This will >> run for 3-4 years. Are we going to deliver LPIC laureates without SAN >> knowledge for this period (again)? Doesn't this devalue the prestige of the >> LPIC certificates? I think all parties involved: Candidates, Companies >> hiring, and LPI would benefit by having this in... >> >> Kind regards, >> Reinier Kleipool >> >> P.S. >> I struggle to imagine what topics would go into a 300 level SAN exam... >> Building a SAN with Linux, SCSI-target... Who is doing that? >> >> >> -- >> [image: OSA logo] Vriendelijke Groet / Kind Regards, >> Reinier Kleipool >> >> *Open Source Academy <http://www.OpenSourceAcademy.eu>* >> Rotterdamserijweg 122 >> 3042 AS Rotterdam >> the Netherlands >> T: +31 654 227144 >> E: rein...@opensourceacademy.eu >> >> _______________________________________________ >> lpi-examdev mailing list >> lpi-examdev@lpi.org >> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >> > > _______________________________________________ lpi-examdev mailing list > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > _______________________________________________ > lpi-examdev mailing list > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >
<<osa_logo.png>>
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
