difference between striping using mdadm and LVM
in [General Linux]
|
From: Rahul on 22 Jan 2010 13:24 David Brown <david(a)westcontrol.removethisbit.com> wrote in news:4b596aa4$0$6281$8404b019(a)news.wineasy.se: > Rahul wrote: >> David Brown <david.brown(a)hesbynett.removethisbit.no> wrote in >> news:8KednbJOTsi3FsrWnZ2dnUVZ8i2dnZ2d(a)lyse.net: >> > > It is very difficult to judge these things - it is so dependent on the > load. Don't rate my gut feeling above /your/ gut feeling! The > trouble is, the only way to be sure is to try out both combinations > and see, which is a little impractical. Exactly. Lies, damned lies and benchmarks. I spent a month on getting my vendor to run benchmarks on the intended I/O boxes but it is very difficult to estimate. In the end I decided to take a more robust decision and thus bought this config. With 3 indipendent storage boxes, 45 SAS 15 drives, and a beefy server with 48 Gigs RAM at least I have the independance thant if one layout does not give the performance I want I can move things around and try a different strategy. Worst case even put in 3 servers with one box attached to each and then spread out I/O via Lustre etc. Or even have the hack of a /home1 /home2 and a /home3 etc. > If you are able, you could do > testing with only have the disks attached to see if it makes a > measurable difference. I will. What's your tool of choice? bonnie++, iozone etc.? Or just a dd with changing parameters. > I have been imagining two layers of controllers here - your disks are > connected to one controller on a storage box, I have a MD-1000 from Dell. I don't think it has any controller on board to speak of. It's a dumb box. The PERC-6e card in the host server is the only controller that I know of. >> > > Have you considered using a clustered file system such as Lustre or > GFS? > You then have a central server for metadata, which is easy to get > fast > (everything will be in the server's ram cache), and the actual data is > spread around and duplicated on different servers. I did consider Luster, gluster hadoopFS and gfs. Problem is that they seem very tricky to set up correctly and I was scared away. Have you actually tried any of those? Any anecdotal comments? Have you used any of these distributed filesystems? > 48 GB is actually quite a lot. Whether it is enough or not is hard to > say. Run the system you have got - if people complain that it is > slow, do some monitoring to find the bottlenecks. If they don't > complain, then 48 GB is enough! I'm not even sure what's the absolute max RAM that my server will even take. -- Rahul
From: David Brown on 24 Jan 2010 17:21 Aragorn wrote: > On Friday 22 January 2010 15:56 in comp.os.linux.misc, somebody > identifying as David Brown wrote... > >> On 22/01/2010 14:42, Aragorn wrote: >> >>> On Friday 22 January 2010 00:21 in comp.os.linux.misc, somebody >>> identifying as David Brown wrote... >>> <snip to save space> >>>> [...] possibly with harddisks for bulk storage). You want good >>>> graphics and sound. For software, you want your host OS to be the >>>> main working OS - put guest OS's under Virtual Box if you want. >>> Hmm... No, I again disagree. First of all, if the host operating >>> system (or privileged guest in a Xen-context) is being used for daily >>> work, then it becomes a liability to the guest. You want the host >>> (or privileged guest) as static and lean as possible. It's the >>> Achilles heel of your entire system. >> That's true for a server - not for a workstation. You are correct >> that the guest is no safer (or more reliable) than the host, but for a >> workstation, that's fine. > > Well, only if you consider the guest to be something that needs to be > sandboxed. And of course, Windows *should* be. And sealed in behind > solid concrete walls by people wearing Hazmat suits. :p > >> You use the host for your main work, as efficiently as possible (i.e., >> direct access to hardware, etc.). If you have something risky >> (testing out software, running windows), you do it in a guest without >> risking the host. > > Yes, the sandbox scenario. For that kind of usage, host-based virtual > machine monitors are a good choice, of course. > >> But if you have something that has to be safer and more reliable than >> the system you are using as your main workhorse every day, it should >> be on a different physical system - the server. > > Well, with hardware like mine and with something as powerful as Xen, I > consider my usage of that system quite efficient and more interesting. > You also have to keep in mind here that I view a GNU/Linux (or any > UNIX) workstation as something other than "a PC". To me, any UNIX > system is a client/server architecture and I treat and view it as such. > You are in a little unusual situation, having such a powerful single machine, so it makes sense for you to want to do everything on the same physical machine. I view a server as a multi-user system, but a "workstation" is just a powerful PC. And PC means /personal/ computer - a PC should, I think, be mainly for a single person. Different people want different things from a PC, and they are often in conflict - one person wants fast and powerful, another wants small and quiet. A server has to have an emphasis on reliability and security, a workstation on ease of use and speed of interactive tasks. > It's a different philosophy from the single-user thinking that is > typical for Windows users. And thus, once again, it's all in the eye > of the beholder. ;-) > >>> Secondly, VirtualBox might be very popular with a number of desktop >>> users - and particularly so they could run Windows inside of it - but >>> I do not consider that a proper virtualization context. VirtualBox >>> runs on the host operating system as a process. It's not as >>> efficient as Xen. And not quite as cool either. :p >> It is a somewhat different concept from Xen - you are correct that it >> runs as a process on the host. But you are incorrect to write that >> off as a disadvantage or "not proper virtualization". > > Well, it obviously *is* virtualization, but as I wrote higher up, I > consider that good for sandboxing, but not for my purposes. I like the > mainframe-style approach of Xen, where everything is a virtual machine, > including the management system. > > It's a matter of taste, really, so when I said "I don't consider that" > and so on, I was really speaking of me, myself and I. ;-) > >> It is a different type of virtualisation, with advantages as well as >> disadvantages. It is easier in use, and easier to integrate (sharing >> files and clipboards, moving smoothly between guest and host, mixing >> host and guest windows, etc.). > > I have seen screenshots of a virtualization solution - don't ask me > which one because I don't remember - where GNU/Linux and Windows were > actually *sharing* the desktop. Neither was running in any windowed > context and one didn't have to switch full screen mode between the host > (GNU/Linux) and the guest (Windows). It was all seamless, with X > desktop's taskbar at the top and the Windows taskbar at the bottom of > the screen. It was weird. 8-) > Weird, but useful! >> But it doesn't allow the guest the same level of controlled >> hardware access that a hypervisor solution like Xen gives you. That's >> why I recommend VBox for workstations, but it is probably not the best >> choice for a server. Different tools for different jobs. > > And differing opinions on what constitutes "a workstation". :-) > >>>> I like to install OpenWRT on WRT54GL devices - it makes them far >>>> more >>>> flexible than the original firmware. Of course, if the original >>>> firmware does all you need, then that's fine. >>> Yeah, I know quite a few people who ue OpenWRT, but then again, at >>> present I see no reason why I would be putting myself through the >>> trouble of flashing the firmware on that thing. ;-) The standard >>> firmware is already quite good, mind you. ;-) >> If it ain't broke, don't fix it? > > Exactly! :-) > >> But it's more fun to break it, then see if you can fix it again >> afterwards... > > And if you can't, then you've got yourself an expensive paperweight. :p >
From: David Brown on 24 Jan 2010 17:29
Rahul wrote: > David Brown <david(a)westcontrol.removethisbit.com> wrote in > news:4b596aa4$0$6281$8404b019(a)news.wineasy.se: > >> Rahul wrote: >>> David Brown <david.brown(a)hesbynett.removethisbit.no> wrote in >>> news:8KednbJOTsi3FsrWnZ2dnUVZ8i2dnZ2d(a)lyse.net: >>> >> It is very difficult to judge these things - it is so dependent on the >> load. Don't rate my gut feeling above /your/ gut feeling! The >> trouble is, the only way to be sure is to try out both combinations >> and see, which is a little impractical. > > Exactly. Lies, damned lies and benchmarks. I spent a month on getting my > vendor to run benchmarks on the intended I/O boxes but it is very > difficult to estimate. In the end I decided to take a more robust > decision and thus bought this config. With 3 indipendent storage boxes, > 45 SAS 15 drives, and a beefy server with 48 Gigs RAM at least I have the > independance thant if one layout does not give the performance I want I > can move things around and try a different strategy. Worst case even put > in 3 servers with one box attached to each and then spread out I/O via > Lustre etc. Or even have the hack of a /home1 /home2 and a /home3 etc. > >> If you are able, you could do >> testing with only have the disks attached to see if it makes a >> measurable difference. > > I will. What's your tool of choice? bonnie++, iozone etc.? Or just a dd > with changing parameters. > I've used bonnie++, but I have never done any specific task-related testing. I haven't had to put together systems with performance requirements - mostly I've picked parts based on solid value for money. I think it's fun doing testing, but that's more along the lines of "that's cool - this system does X more bogomips than the old one!". For your tests, you'll want to spend a bit more time on them, and try to get something that matches your real load. In particular, you'll want something that can simulate a large number of parallel accesses, ideally using a second machine to access the server over NFS. >> I have been imagining two layers of controllers here - your disks are >> connected to one controller on a storage box, > > I have a MD-1000 from Dell. I don't think it has any controller on board > to speak of. It's a dumb box. The PERC-6e card in the host server is the > only controller that I know of. > >> Have you considered using a clustered file system such as Lustre or >> GFS? >> You then have a central server for metadata, which is easy to get >> fast >> (everything will be in the server's ram cache), and the actual data is >> spread around and duplicated on different servers. > > I did consider Luster, gluster hadoopFS and gfs. Problem is that they > seem very tricky to set up correctly and I was scared away. Have you > actually tried any of those? Any anecdotal comments? Have you used any of > these distributed filesystems? > No idea - sorry. I've read the wikipedia pages, which makes me the local expert, but I have never tried anything like this. My company would have to increase its IT budget by an order of magnitude or two before I could get the chance! >> 48 GB is actually quite a lot. Whether it is enough or not is hard to >> say. Run the system you have got - if people complain that it is >> slow, do some monitoring to find the bottlenecks. If they don't >> complain, then 48 GB is enough! > > I'm not even sure what's the absolute max RAM that my server will even > take. > > |