Re: Configuring EMC w/o ASMIB on RHEL 7.6
Date: Sun, 7 Jun 2020 19:26:26 -0500
Message-ID: <CAFH+ifdFwDzn+Px8DUjQu2DG1cw2qY0jy-7R=1ZJz3aLv2Q7bA_at_mail.gmail.com>
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_at_gmail.com> 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_at_gmail.com>
> 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.'
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jun 08 2020 - 02:26:26 CEST