See inline
================= Dana Hudes UNIX and Imaging group NYC-HRA MIS +1 718 510 8586 Nextel: 172*26*16684 ================= -----Original Message----- From: Rajiv Gunja [mailto:[EMAIL PROTECTED] Sent: Friday, August 17, 2007 8:57 PM To: Hudes, Dana Cc: [EMAIL PROTECTED]; veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] could multiple filesystems dent performance? I agree with most of what Dana has to say about this. I would differ in advise on point 4. If your SAN is EMC or Netapps (hope not), then I would say let the SAN do all the mirroring for you. [Hudes, Dana] That's what I said: let the SAN do the mirroring. Let the big fancy expensive SAN controller do the work for you. This is not some little NetApp filer x86 box in disguise. Some people who have a connection to two SANs (not just two FC networks but to two distinct pools of disks) like to have their host do the mirroring between SANs, citing reliability issues with replication between SAN controllers. Nobody I've heard of does striping between SANs. With bigger databases ( greater than 2 TB ), you need need all the CPU cycles and IO over FC to your database. Since you mentioned Sybase, if you are planning to have raw devices, the better, thats what we did at my company before we moved to Oracle. [Hudes, Dana] Raw devices are a PITA you have to rely on the application keeping integrity of the data. While usually we do rely on the DBMS for backup of its data, in that we want it to dump the database, nonetheless when you bypass the filesystem you have no idea as an admin what's going on in there. Keeping Logs and binaries separate is a good idea at many levels, true it will slow down your boot up time or time to recover when the system crashes, but it will sure separate out the traffic. [Hudes, Dana] I'd have thought it was obvious that application binaries aren't on a filesystem used by the application for its data. Make sure when you configure your SAN, to have as many LUNs, extra FC cards and split your databases, than having couple of large files. [Hudes, Dana] LUNs have nothing to do with number of FC cards. One is logical the other physical. Database splitting is a DBA question and is a function of access patterns (read mostly, write mostly, sequential vs. random etc.) If you have never worked with ZFS or Veritas 5, test it out for a few months before rushing it into production. There is a learning curve and Veritas 5 has its own features, which you may or may not use. [Hudes, Dana] ZFS has its own quirks. One of which is that once you give a device to a pool in a "concat" layout it won't let you take it away even if its not used. There is no shrinking of filesystems to free up the device its more like its auto-striped across everything. Good Luck -GGR Rajiv G Gunja On 8/14/07, Hudes, Dana <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: 1. Given that you bought a SF license, presumably your are using 5.0, I would look into the Databse Edition add-on to the Enterprise license I would not use ufs I would use vxfs with the DB edition 2. This T2000, I hope yoiu are using Solaris 10 update 3 not earlier and that you applied the July firmware updare I think its 6.04 (depending on your timeframe to go live you may want to go with update 4 due late this month) 3. Sun claims that ZFS outperforms ufs and vxfs. ZFS can do either or both the volume manager or filesystem role (you can put zfs on a VxVm device). With a SANN ZFS lacks the Array Support Libraries that Veritas has to ostensibly improver performance by tighter integration with the SAN controller 4. Generakky unless you different storage requirements (layout , options) I try to keep to fewer volumes. Now you may want to split the database table space into separate volumes but only if you are using separate LUNs that the SAN maps to separate disk groups. If you afford it your index and table space will perform better with 1+1 ie mirror layout (in the SAN do not mirror or stripe LUNS from the same SAN pool inVeritas, use concat) but cost wise you get decent performance with 7+1 or 6+2 layout (RAID 5 or "6") and you do not pay for double the disk space 5 database logs I thow onto their own volume/filesystem on a separate LUN mapped to different disks than table space or indices 6. If you have multipe databases that are not used by same end users (or equivalent of Oracle instances) then if you can get them each their own LUN mapped to different disks you may have slightly better performance Oltp dnms is not same disk +/o pattern as a data warehpuse. I am unfamiliar with your autosys application and the load it places on the system nor your budget constraints or reponsiveness equirements and what drives them beyond greedy impatient users and DBAs ------Original Message------ From: [EMAIL PROTECTED] To: veritas-vx@mailman.eng.auburn.edu Sent: Aug 14, 2007 5:52 AM Subject: [Veritas-vx] could multiple filesystems dent performance? Hello there, We have a Sun T2000, 32G ram all set to run an intensive database application (AutoSys) running off of Sybase instances. We have SAN disks for the storage of the databases, Autosys instances etc all under the control of VxVM. The databases themselves will be on UFS (so that the Oracle Direct I/O can be used) and the others are vxfs. In total we are going to have 16 separate autosys 'dataservers', each with their own Sybase instance. So, so far we are likely to have 32 filesystems (plus odds and ends) but if we choose to separate logs from binaries etc then it would easily reach 64 and beyond. My question is, would having this many filesystems impact performance at all? To keep things separated out, it would be nice to utilise multiple filesystems but if this many starts thrashing the VxVM daemons then we could look towards clumping things together. Any thoughts/suggestions? Thanks! Regards, Grant Grant Dunkerton EMEA DTS Server Support My details: Ext: +44 (0)1202 346636 Int: 731 6636 Team details Phone: +44 (0)1202 346063 GDP 731 6063 Trouble tickets: X1DCSGBCOREUNIXINF ________________________________ This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are ------Original Message Truncated------ -------------------------- Sent from my BlackBerry Wireless Device _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
