Re: Moving 2-node RAC to AWS

Hi Sandra

"We cannot upgrade the databases (or the OS) due to a host of constraints put on us by the applications and stakeholders"

I'd love to know how those constraints are articulated. As you've discovered RAC is not supported on EC2, and indeed isn't even implementable without additional software, there is a product that offers that in a (somewhat) supported fashion but the business isn't prepared to pay for it. Given it looks like they don't value O/S or database support that's probably not that surprising, but still choosing to try and run a business application on something held together with duct tape and goodwill is an interesting approach to say the least.

We are customers of both VMWare Cloud on AWS (think of it as hosted ESx - sorry VMWare folks!), EC2 and RDS. FWIW we offer RAC to our internal customers *only *on VMWare Cloud, We do offer 19c (plus the odd 12) on EC2 +EBS but only using SIHA with ASM, and we offer RDS whereever possible. RAC on EC2 never even got started as a conversation.

All of the above leads me back to my question about constraints, if they are at heart "We can't leave 11.2 on RAC because the application/vendor/developers won't support it" then the most sensible reply would be "In that case, AWS isn't a suitable landing zone for this application, we'll have to find somewhere else or leave as is". If they are cost constraints associated with running a data centre (it sounds like cost is a big driver) then please do encourage a deep dive into what a move to AWS will actually cost, as well as a performance proof of concept. Storage and database appropriate IO performance cost real money very quickly in the Cloud. (not just AWS). In addition storage like EBS performs differently from traditional SAN or locally attached storage and the various QoS limits the Cloud Vendor provides can mean that you need to pay more than you think, for example by over-provisioning CPU so as to get sufficient EBS bandwidth.

AWS (and other Cloud) is great and definitely can be really effective. It isn't (maybe with the exception of Oracle Cloud) somewhere you can just pick up existing RAC installs, drop them and live happily ever after.

On Fri, Nov 19, 2021 at 4:24 PM Jared Still <jkstill_at_gmail.com> wrote:

> RAC is really quite complex, as you likely already know.
>
> As a fun project, I would consider setting it up with a free tool for
> multicast. Jeremiah Wilton wrote a paper on doing that.
>
> But running RAC on EC2 in production sounds like something that would
> generate a lot of unnecessary work and anxiety.
>
> Q: Why do you use RAC?
>
> Is it because the extra nodes are required to meet CPU and/or memory needs?
>
> Or is it for the failover?
>
> If it is for the failover, then perhaps consider sizing the server large
> enough to run all apps, and use DataGuard for HA. Perhaps 2 of them, one
> in a different AZ.
>
> Just a thought
>
> On Thu, Nov 18, 2021 at 10:59 Sandra Becker <sbecker6925_at_gmail.com> wrote:
>
>> Current OS: RHEL6
>> Oracle version: 11g (11.2.0.3 and 11.2.0.4)
>>
>> We have started a project to move our 50 or so on-prem RAC databases to
>> AWS EC2 servers. Some use ASM, others do not. (I think the motto of
>> previous DBAs was "consistency is for the weak.".) We cannot upgrade the
>> databases (or the OS) due to a host of constraints put on us by the
>> applications and stakeholders. Using FlashGrid also is out of the question
>> since it would be an additional software cost.
>>
>> I'm looking for good documents to read/follow that would tell us how to
>> set up ASM on the EC2 instances as well as the best method to move the RAC
>> databases. Has anyone done this that can point me to good documentation?
>> I also have some non-RAC databases to move. I was thinking of creating the
>> standby on the EC2 then doing a switchover during a migration window to
>> minimize downtime. Is this approach feasible? Would another approach be
>> preferable?
>>
>> Thank you for any suggestions,
>>
>>
>> --
>> Sandy B.
>>
>> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Principal Consultant at Pythian
> Oracle ACE Alumni
> Pythian Blog http://www.pythian.com/blog/author/still/
> Github: https://github.com/jkstill
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l