On Fri, 2006-06-23 at 10:05 -0400, Marc M wrote: > I currently have an IBM LS-20 blade system at my work which we are > evaluating. Fujitsu makes some good stuff but I haven't gotten my > hands on it yet. The IBM blade unit is suppossed to support all of > the recent RHEL distributions as well as M$ and SuSE, (the CEO-less > distribution lol). I run into driver issues with all sorts of servers > (especially Dell since they are so linux UNfriendly in my opinion). > We ran into a vesa issue with RHEL but that is nothing that a little > bit of xorg.conf tweaking wouldn't fix. my concerns were mostly that closed-source raid/scsi cards. its quite annoying to wait for a vendor to provide an updated kernel-module, when the bad guys just wait for their chance. i feel quite comfortable on patching/recompiling kernels, but thats often not possible. > Right now the market is really neck and neck with HP and IBM having > about 85-90% market share. How you use it really affects the > configuration and all of the choices involved. When you say 'spread > the load out' over more blades - are you truly referring to some sort > of clustering? their sales-team told us so. :) it should be easy to move e.g. some RAM from one "blade" to another one, if this would be needed. a reboot would be needed for that of course. but we definitly need to evaluate the real hardware and dont believe their sellers. > Questions for you > > 1. The statement 'currently we install important/heavy-loaded systems > twice or triply, ' ---doesn't make sense. Explain? we install e.g. not one big (and expensive) server for a given service, but several smaller (and cheaper) ones. our firewall takes care that requests get spread over all of them. and as the firewall sends connections from IP X always to the same backend, this works fine for our needs. if a system is no longer available, the firewall notices that and uses the next one (which would break certain). one drawback is, that if one system gets overloaded, but one could still connect, you WILL get connected to that system, even if the next one has no load. not perfect but easy and affordable and meets our needs close enough. > 2. why on earth would you run Fedora on a blade in a production > environment? Is it truly that or something like a test environment? we use fedora for some systems without direct user-access, as e.g. the spamfilter or virusfilter. once a month those fedoras need a reboot, as their nfs hangs. we never had problems with el3 and el4. and for some development-systems we use fedora, too (as most of the needed packages are not yet shipped with el3 or even el4). > 3. kickstart is not a firewall, that does not make sense, please > explain.... should have been clearer on that: blades "fast deployment & installation" gets covered by kickstart installations. we reach some redundancy and load-balancing by using our firewall (as explained above). thanks for your time joe > HTH > Marc > > > > On 6/23/06, josef radinger <cheese@xxxxxxxxxxxxxx> wrote: > Hello, > > We are currently evaluating (without the actual hardware, just > by > reading whitepapers) a bladeframe system from Fujitsu-Siemens, > which > should be a relabeled egenera-system. > > maybe someone had such a system at work. > > my concerns are: > a) does fedora (4,5,...) work on that? > > b) el4 seems to be supported, but would i need to have some > special > drivers. i dont like those closed-source drivers, as we always > have to > wait for vendors to get their supported kernel patched. > > c) most of their key-features (fast installation, balancing, > redundancy,...) are already solved by kickstart, our > firewalling-system,... > currently we install important/heavy-loaded systems twice or > triply, and > use round-robin and load-balancing to achieve the same. > without fancy > gui, but who cares. the only feature i see is that hardware is > better > used, as the load gets spread over more blades, which is not > the case > with our standalone boxes right now. > > any input would be highly appreciated. > > yours > josef > > > > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-list > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
