Re: seeking for opinions on migrate from Sun to X86: ASM vs filesystem, HA options;
- From: Li Li <litanli@xxxxxxxxx>
- To: zhuchao@xxxxxxxxx
- Date: Tue, 26 Oct 2010 22:02:32 -0500
3+ years ago we were at a similar configuration as yours: Sun V880s +
Solaris + Veritas + SAN. We moved away from it to Dell PEs + Redhat +
10gR2 RAC + ASM + SAN and so far we are very happy with it.
1. Saying ASM is immature is not true, in fact ASM has been very
stable/robust for us. We had an unexpected power outage plus UPS
crash, all the RAC server came back up without any issue.
2. don't know who is your SAN vendor, we use EMC and PowerPath has
been working fine for multipathing.
3. You already have standby, why mirror
4. You lock in any vendor you use, that's my argument here :-)
5. I think you can copy just like a filesystem with 11G ASM
6. In 11G ASM and RDBMS can be separated and managed by different people.
7. I think you can use oracle clusterware for HA even if you don't use
RAC. it used to be free but I am not sure for now.
On Tue, Oct 26, 2010 at 8:52 PM, Zhu,Chao <zhuchao@xxxxxxxxx> wrote:
> Hi, All
> We are in the progress of POC migrate from Sun Niagara platform to X86
> platform for some of our database; Previously our database platform purely
> run on top of :
> Sun HW+Solaris
> Veritas as volume manager/HA
> SAN
> and oracle on top of it;
>
> With desireto X86(some due to dual vendor strategy, some due to cost
> reason, and some due to performance reason, you know Niagara performance for
> heavy transaction), everythign has to be re-evaluated;
> Currently we have a few open discussions:
> 1. Shall we still use veritas as volume manager/ext3,ext4 of vxfs as
> filesystem?
> Our architecture is saying that and i totally disagree;
> my point is definitely we should go with ASM, no matter on SAN or local
> disk(we plan to run some database on local disk);
> a few reason:
>
> 1. From design, ASM is designed for oracle database server usage; much
> simpler than veritas, and go through 4 major release (10.1/10.2/11.1/11.2)
> and integrated with its product better;
>
> 2. On ASM, we never need to worry about IO balance across volumes, it
> always balances IO;
> on current volume manager, we have to carefully balance the IO; we have
> cases some volume(280gb/4lun from san) got 2000iops during busy hours, and
> some got very few ;
>
> 3. On ASM, we never need to worry about crash recovery (FSCK); --
> correct me I am wrong;
>
> 4. On ASM, we never need to worry about AIO; AIO is critical for
> database IO performance (especially write heavy);
> On ext3, there is no real KAIO available(my knowledge is a bit old though);
> only threaded AIO;
>
> 5. On Ext3, we have to carefully watch/manage the filesystem buffer
> cache(just like the AIX platform, sun do not have this problem); By default
> linux like to cache into buffer_cache; for oracle database we do not want
> this;
>
> 6. Last but not least, ASM is a total solution oracle recommends for
> database now; We get more vendor bless than other solution;
> And more important, if we indeed run into problem, there is no finger point
> between redhat/oracle; (maybe we want to re-evaluate redhat linux vs oracle
> enterprise linux? There is part of the poc we want to do for oracle
> enterprise kernel though);
>
>
>
> and architecture team member raised some concern:
>
> 1. ASM is still fairly immature from a volume manager and file system
> standpoint. It is not posix compliant, and the only tools to access it are
> from Oracle. You can’t get to the data easily without running Oracle.
>
> 2. You have to run another Multipathing product if you are not using
> the Veritas stack. Sometimes the MP product, is more than the entire
> Veritas stack, especially on Linux
>
> 3. There is no way to easily do delta mirrors and other functions,
> that we might and might not use in our environment.
>
> 4. It locks us into Oracle
>
> 5. Our current standby’s give us the ability to copy over a file from
> a standby.. It is going to be difficult to do this with ASM.
>
> 6. It changes the support structure, currently the unix team is
> responsible for the storage, file systems, volumes etc. This would become
> the DBA’s responsibility, or at least could.
>
> 7. Clustering becomes an issue. My gut feel is that we don’t want to
> go with RAC as a general product in the environment, because of the cost,
> complexity, and the vendor lockin. And it is difficult to use Linux HA, VCS
> etc, if we are using ASM
>
> ok, next topic is about whether we should do VCS HA or CRS HA; but i guess
> this topic is busy enough, i will open a seperate thread for the discussion;
>
>
> --
> Regards
> Zhu Chao
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
