PDA

View Full Version : SLES 12 High Availability Extension Resources not starting



6529034
15-Dec-2014, 09:35
Hello,

I have used SLES 11 SP2 High Availbility Extension and configured DRBD, XEN VM''s etc without issue.

I am now trialing SLES 12 with its High Availability Extensions. Getting used to Hawk is interesting enough (loved pacemaker GUI).

My issue is that I tried to create a DRBD resource (the same as I did on SLES 11 SP2) and it will not start. I also created a Pingd resource and it too will not start.

This was a given in SLES 11 SP2, yet in SLES 12 I cannot understand why its failing.

An error message Hawk shows is

linux3: WARN: passwordless ssh to node(s) linux4 does not work
Permission denied (publickey,keyboard-interactive).
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Where linux3 and linux4 represent my 2 SLES 12 servers.

I do not recall configuring SSH for HA in SLES 11 SP2 before - it just worked.

I cannot seem to find any documentation on this error or how to set it up for HA use.

Can anybody shed some light on this issue?

John

Automatic reply
21-Dec-2014, 14:30
6529034,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

Has your issue been resolved? If not, you might try one of the following options:

- Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.suse.com)

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php

If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.

Good luck!

Your SUSE Forums Team
http://forums.suse.com

ab
22-Dec-2014, 04:51
I setup SLES 11 SP3 HAE a couple of months ago and as part of that I used
the sleha-init script which sets up password-less SSH access. I used HAWK
in that environment as well for almost everything since that made a since
remotely-accessible UI for the customer for whom I was implementing it:

https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_installation_setup_auto.html

I have not yet used the SLES 12 version, but am excited to.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

6529034
23-Dec-2014, 06:24
I found that starting the ms drbd resource brings up drbd on both nodes into slave/secondary state. However, when the cluster tries to promote it to master/primary state, it fails with a message in the log stating that the drbd resources need to be in an 'uptodate' state.

I am able to bring the drbd devices on both nodes to primary state without issues manually-outside of the cluster manager.

If I then performes a 'clean up' on the ms resource, the ms resource brings the drbd devices to master/primary state on both nodes without error.
I can then perform a demote, promote, and stop successfully on the running ms resource.

I decided to see what would happen if I shutdown the 2 nodes and powered them up again. I was happy to see the the ms resource went into master state without error.

I can work with this.

John

6529034
26-Mar-2015, 00:29
I have successfully set up passwordless SSH communications between my 2 nodes (found good documentation on this using the ssh-kegen command and copying the resulting id_rsa.pub key to the authorized_key file of the other node).

My drbd issue is now resolved (please see my other post on this).

John

ab
26-Mar-2015, 03:59
On 03/25/2015 05:34 PM, 6529034 wrote:
>
> I have successfully set up passwordless SSH communications between my 2
> nodes (found good documentation on this using the ssh-kegen command and
> copying the resulting id_rsa.pub key to the authorized_key file of the
> other node).

Well done, and thank-you for posting back your results. For fun, you may
want to look at the ssh-copy-id command which will do the pub key copying
to the remote authorized_keys file for you, and be sure permissions are
correct, and with current versions (on my openSUSE 13.1 system anyway)
copy multiple keys (if available), but only if not already copied (to
avoid duplicates, in case you've copied in the past).



ssh-copy-id user@remote.system.here


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...