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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
Current OS: RHEL6Jared Still
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.
--
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
