[ClusterLabs] Oralsnr/Oracle resources agents

[Andrei Borzenkov]

25.02.2017 23:18, Jihed M'selmi пишет:
> [DM] I thought that oracle listener is not consuming that many resources.
> At any rate, ocf:heartbeat:oralsnr doesn't support single listener for
> multiple instances. Do you have an idea how to do that? How to deal with
> the tnsping then? Maybe you're better off with the system start script in
> this case.
> 
> [JM] According to the dba, it could lead some memory issue when the
> listener serves many instances at the same time (in my experience, I have
> never faced this issue).
> 

What "it" means in the above sentence? "Running single listener for
multiple instances" or "running each instance with own listener"?

How many instances are we talking about?

> Let's take a case when the listener is serving multiple instance, and one
> of the instance fails => ocf:heartbeat:oracle will relocate it to another
> node, the listener should follow (especially, when we use
> collocation constraint between RA oracle and oralsnr) this will have a bad
> impact on the rest of instances.
> 
> One of the option is to have two listeners (one per node) and configured
> outside the cluster to host the all instance. But, I keep looking for a
> better solution.
> 
> [DM] Hmm, what should then the RA do? Skip the instance and report it started?
> I'm not sure I follow.
> [JM] The DBA use a flag Y/N to tell if this instance should run or no. It
> could be better, for RA to use this flag too: when it's Y start the
> instance and when It's N, the RA should not start the instance and suitable
> message in log will be usefull to describe the situation. Now, the
> challenge is how to monitor this flag.
> 

DBA still needs to remember to change this flag on each node in the
cluster. In which case it can just as well remember to use different way
to disable automatic startup.

> One of the issue that I faced when the DBA when to shutdown the listener
> and the instance (for launch the cold backup) but, the RA keep pushing them
> ON. -- Note the dba team usually don't have an access to pcs to disable the
> resource during this type of operation.
> 

There is nothing new. Once you put application under HA control, you in
general cannot use native application tools to manage it. That is why
SAP introduced "cluster glue" layer that intercepts native requests to
start/stop application and forwards them to cluster for actual processing.

The solution here is really to make it possible to delegate control of
individual resources to different users, so that DBA can
start/stop/disable/unmanage individual resources (s)he owns.

If nothing else, it can be done as SUID scripts that implement this check.