Re: Configuring EMC w/o ASMIB on RHEL 7.6

  • From: David Barbour <david.barbour1@xxxxxxxxx>
  • To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • Date: Sun, 7 Jun 2020 19:26:26 -0500

Hi Andrew and thanks.  Just wanted to let you know your article got me
thinking.  The symlink was the problem.  Even though the UUID of the parent
device ( e.g.:360060160e6914d00e1f3f35dba6676d8) was listed, the link
repeatedly pointed to the partition which wasn;t the case on the RHEL 6.8
nodes where is it possible to 'rename' the device.

We're not using asmlib and when the RAC was initially set up by a third
party, the asm_diskstring was specified as /dev/ora.  I played around with
several ENV{} variables and combinations but finally wondered why, since I
couldn't change the name, I couldn't create my own device using mknod to
stick in /dev/ora.

Here's a sample stanza that works perfectly:

ACTION=="add|change", SUBSYSTEM=="block",  ENV{DEVTYPE}=="partition",
KERNEL=="emcpower[a-z][a-z]?",  PROGRAM="/usr/lib/udev/scsi_id -g -u -d
$devnode", RESULT=="360060160e6914d00e1f3f35dba6676d8", RUN+="/bin/sh -c
'mknod /dev/ora/ORA-OCRVTG101 b $major $minor; chown grid:asmadmin
/dev/ora/ORA-OCRVTG101; chmod 0660 /dev/ora/ORA-OCRVTG101'"

It's all better now.  Hope this helps someone if they have servers on
different OS versions and run into something like this.



On Wed, Jun 3, 2020 at 8:28 AM Andrew Kerber <andrew.kerber@xxxxxxxxx>
wrote:

See if this helps:
https://dbakerber.wordpress.com/2019/10/16/udev-rules-for-oracle-storage/

On Tue, Jun 2, 2020 at 11:29 AM David Barbour <david.barbour1@xxxxxxxxx>
wrote:

Good Morning,

Any EMC PowerPath folks out there?  We are adding a new node to our RAC.
cluvfy from an existing node cannot recognize the disk on the new node.

The new node is third-party hosted and they have set up the storage.

On the current nodes we see simply the powerpath device without a
partition in /dev - such as emcpowerbx and it's owned by root:disk.  The
entry in /etc/udev/rules.d/99-oracle-grid-rules for this device is:

KERNEL=="emcpower[a-z][a-z]?", SUBSYSTEM=="block", PROGRAM="/sbin/scsi_id
--whitelisted --replace-whitespace /dev/$parent",
RESULT=="360060160e6914d00e1f3f35dba6676d8", OWNER="grid",
GROUP="asmadmin", MODE="0660", NAME="ora/ORA-OCRVTG101"

which results in an entry in /dev/ora (the asm_diskstring) of
'ORA-OCRVTG101' owned by grid:asmadmin.

The new node is showing the powerpath devices WITH partitions.  So we see
emcpowerbx and emcpowerbx1.  The new rule on that server sets up a symlink
to the partition and the partition in /dev is owned by grid:asmadmin.

This just isn't working.  If we use the rules from the old nodes, nothing
shows up in /dev/ora.  If we use the new rules - which look like this:

ACTION=="add|change", SUBSYSTEM=="block",  KERNEL=="emcpower[a-z][a-z]?",
PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace
/dev/$parent", RESULT=="360060160e6914d00e1f3f35dba6676d8", OWNER="grid",
GROUP="asmadmin", MODE="0660", SYMLINK+="ora/ORA-OCRVTG101"

we get this when running cluvfy:

$  cluvfy comp ssa -n 685921-db5,1103477-db7 -s /dev/emcpowerbx

Verifying Shared Storage Accessibility:/dev/emcpowerbx ...FAILED
(PRVG-0806)

Verification of shared storage accessibility was unsuccessful on all the
specified nodes.


Failures were encountered during execution of CVU verification request
"shared storage accessibility".

Verifying Shared Storage Accessibility:/dev/emcpowerbx ...FAILED
PRVG-0806 : Signature for storage path "/dev/emcpowerbx" is inconsistent
across
the nodes.
Signature was found as "" on nodes: "1103477-db7".
Signature was found as "360060160e6914d00e1f3f35dba6676d8|" on nodes:
"685921-db5".

Appreciate any insight.  So far it's a no-go with RedHat, Rackspace (the
third party cloud vendor) and of course Oracle support.

The original nodes are not using asmlib.  I'm wondering if that might be
an answer here.  I am a multipath guy.  Really do not appreciate the
additional level of abstraction.  But I am teachable.

Help!


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
 Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#m_-3745842245882012166_m_-1113539173421026090_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Other related posts: