[Spacewalk-list] Clustering Spacewalk.

[Czerak, Jason]

Michael, the stability issues you speak of is absolutely not the case with today’s current RAC implementations.

Paul, Benard:
I’ve had spacewalk talking to a RAC cluster about 3 years ago. The WebUI connectivity was fine. There were problems with the background scripts when you shut down a node or two. It wasn’t smart enough to “reconnect”. I didn’t give it much effort to debug. However that was before the use of SCAN listeners in our environment. I bet leveraging the SCAN LISTENER layer spacewalk would work just fine as a whole.

Spacewalk is rather small and non-critical so it’s Schema was moved to a standalone instance. So I can’t speak for current spacewalk code.


From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Paul Robert Marino
Sent: Wednesday, February 27, 2013 9:16 AM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Clustering Spacewalk.




-- Sent from my HP Pre3

________________________________
On Feb 27, 2013 8:03 AM, Michael Mraka <michael.mraka at redhat.com<mailto:michael.mraka at redhat.com>> wrote:

Paul Robert Marino wrote:
% On Tue, Feb 26, 2013 at 5:07 AM, Michael Mraka <michael.mraka at redhat.com<mailto:michael.mraka at redhat.com>> wrote:
% > Bernard McCormack wrote:
% > % I was wondering if any one has done clustered DB (Oracle 11gr2) with
% > % spacewalk using db clustering . We want to have spacewalk stay up in a
% > % different location in case we lose the site to site link. . I have
% >
% > Hello Bernard,
% >
% > Assuming clustered DB means Oracle Real Application Cluster (aka RAC) -
% > yes, you can point spacewalk to RAC. Just create /etc/tnsnames.ora with
% > appropriate service description and pass that service name to
% > spacewalk-setup as database name.
% >
% > On the other hand RAC might be a good performance booster rather
% > recovery solution.
% >
% > % tried to set up multimaster replication (Oracle), but a number of
% > % tables are missing primary keys. Any help\ thoughts would be
% > % appreciated.
% >
% > I'm not sure what you mean by multimaster replication.
% > Correct disaster recovery solution is Oracle Data Guard (aka Standby database).
%
% Are you referring to an active active mode on a shared volume with a
% clustered file system like OCFS2?
% If so the problem you are describing sounds like your OCFS
% configuration isn't correct, otherwise one of your host would be
% fenced if there was an inconsistency like that.

Spacewalk has never been tested in active-active cluster configuration
of any kind. I'm pretty sure you'd hit inconsistency and data corruption
very sooon.

No you shouldn't have  that problem because oracle does it with a clustered volume and ram level distributed locking so its pretty transparent. The problem with it is its not the most stable config in the world and when it goes wrong it really goes wrong. Its a nightmare and a half to diagnose and fix when it breaks (and it will break occasionally). The other problem is its really slow on writes. I had to support one of these monstrosities some years back on RHEL 4 and even with the assistance of the best Oracle DBA I've ever meet let alone worked with it usually was the reason behind at least 2 24 hour days a year. The only thing that allowed us to recover at all was the fact that it was also part of a RAC with a matching cluster in an other datacenter.
It was so bad that our operations team got in the practice of backing the thing up 10 times a day in case we needed to repair it latter.
In other words it should work but its not worth the hassle a standard RAC configuration is far more reliable.

Regards,

--
Michael Mráka
Satellite Engineering, Red Hat

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130227/14a58b97/attachment.htm>