Hi Matt,<br><br>Raid is not the end-all be-all for disk safety, especially when you step into terabyte class computing, sorry I am taking this a bit off topic. While RAID has it's bonuses, there are drawbacks as well, take your standard RAID 5 setup, 4 Disks, 3 active, 1 Hot Spare.  Now lets say that Disk number 2 decided it was going to release it's smoke to the world (never a good thing), now your array is still alive and it is starting to rebuild onto disk 4 to make up for the death of disk 2.  During the rebuild process Disk 1 comes across a bad sector, poof, your data is gone.  Just a word of warning, don't put all your data safety eggs into the RAID basket.<br>
<br>Otherwise I agree that running via NFS from a virtualized server would probably have perfromance gains over running in the virtual invironment.<br><br>Thanks,<br>Bill <br><br><div class="gmail_quote">On Wed, Jul 29, 2009 at 10:26 AM, Matt Simerson <span dir="ltr"><<a href="mailto:matt@corp.spry.com">matt@corp.spry.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><br><div><div class="im"><div>On Jul 29, 2009, at 7:10 AM, Robert Nesius wrote:</div>
<br><blockquote type="cite"><div class="gmail_quote">On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall <span dir="ltr"><<a href="mailto:ktm@rice.edu" target="_blank">ktm@rice.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Kage,<br> <br> The main advantage is gained by avoiding I/O through the virtual<br> disk. The layout of the virtual disk tends to turn most I/O into<br> random I/O, even I/O that starts as sequential. The factor of<br> 10 performance difference between random/sequential I/O causes<br>
 the majority of the performance problem. I have not had personal<br> experience with using an NFS mount point to run a database so I<br> cannot really comment on that. Good luck with your evaluation.<br> </blockquote><div>
<br>You're trading head-seeking latencies for network latencies,</div></div></blockquote><div><br></div></div><div>No.</div><div><br></div><div>If this were a standard host environment, that would be true. But in a virtual environment, there is the overhead of the disk create/maintenance/update processes of the virtualization engine which multiply the overhead of the disk. Just run a disk benchmarking utility inside a VE running under any platform that uses disk images (vmware, xen, parallels, etc...) and then run those same tests on the host node. The difference in performance is often an order of magnitude slower for the virtual disks. </div>
<div><br></div><div>Contrast that with NFS performance, which has a small fixed overhead imposed by the network (even smaller if you use jumbo frames). If you were using a platform with a robust NFS implementation (Solaris, FreeBSD), I'd put money on the database performing better on NFS than inside most virtual machines. If you're using NFS with Linux, you will certainly have performance issues that you won't be able to get past. </div>
<div><br></div><div>If the virtualization environment provides raw disk access to the VE, my bet is off. Examples of virtualization platforms that [can] do this are FreeBSD jails and Linux OpenVZ. On several occasions, I have built VEs for MySQL and mounted a dedicated partition in the VE. Assuming you've given adequate resources to the DB VE, that works as well as a dedicated machine.</div>
<div><br></div><div>When I arrived at my current position, the SA team had put the databases into the VEs that needed them, along with the apps that accessed them. Despite having 6 servers to spread the load across, they had recurring database performance issues (a few times a week), particularly with RT. I resolved all the DB issues by building a dedicated machine with 4 disks (two battery backed RAID-1 mirrors) all the databases to it. The databases have dedicated spindles as does the OS & logging. Despite the resistance to the "all our DB eggs in one basket approach," the wisdom of that choice is now plainly evident. All the performance problems went away and haven't returned.</div>
<div class="im"><div><br></div><blockquote type="cite"><div class="gmail_quote"><div> and those are almost certainly higher.  Hosting your database server binaries and such forth in NFS is possible, though again, not optimal both from a performance and risk standpoint (NFS server drops, your DB binaries vanish, your DB server drops even though the machine hosting it was fine).  <br>
 </div></div></blockquote><div><br></div></div><div>That's not how NFS works. If the NFS server vanishes, the NFS client hangs and waits for it to return. That is a design feature of NFS. The consistency of the databases is entirely dependency on the disk subsystem of the file server. </div>
<div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>I think hosting databases in NFS can cause serious problems - I seem to remember older versions of mysql wouldn't support that.  I don't know if newer ones do...but I do know in the <i>very large</i> IT environment I worked in, all database servers hosted the DBs on their local disks or in filesystems hosted on disks (SANS?) attached via fibre-channel.  <br>
</div></div></blockquote><div><br></div></div><div>I would never host a database server on anything but RAID protected disks with block level access (ie, local disks, iSCSI, etc). Database engines have been explicitly designed and optimized for this type of disk backend.  That is starting to change, as a few new DB engines that are designed for network storage (like SimpleDB). But none I know of are production-ready. </div>
<div class="im"><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>Could solid-state drives side-step the random-access issue with virtualization, or at least make it suck less?</div></div></blockquote><div>
<br></div></div><div>Haven't tried it yet, but my guess is no.  However, I have put databases on SSD disks with excellent results. </div><div class="im"><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div> Based on how many people I know who have said "Wow, my SSD died.  I thought those were supposed to be more reliable?" ... I wouldn't bet my service uptime on it. ;) <br></div></div></blockquote></div></div>
<br><div>There's this thing called RAID, that protects against disk failures.... It works quite well with SSD disks and delivers performance numbers for a couple thousand bucks that would otherwise take a $150,000+ SAN. </div>
<div><br></div><font color="#888888"><div>Matt</div><div><br></div></font></div><br>_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
Community help: <a href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br>
Commercial support: <a href="mailto:sales@bestpractical.com">sales@bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.<br>
Buy a copy at <a href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br></blockquote></div>