This content has been marked as final. Show 4 replies
why you think the space is different between the 2 nodes?
The devices are different, that's ok, dm- is the device mapper name, and several devices will create dm-* like entries, so it's ok to have them different.
When you add a disk, you should follow an approach like:
Present the disk on the storage
Refresh the luns on all the nodes
Create the oracleasm disk on one node
refresh the oracleasm disks on all the nodes
verify the new oracleasm disk is present on all nodes in /dev/oracleasm/disks/*
At this point, you can use asmca or sqlplus in the +ASMn instance to make your asm diskgroup to grow, or create a new disk group
To add to what was said.
The kernel discovers devices at boot time. Devices can be enumerated in different orders, depending on a number of factors at that point in time. Server1 can see storage LUN0 as scsi device sdk, whereas server2 sees it as device sdg.
This is expected.
Many storage layers also provide multiple I/O paths to a LUN (e.g. dual fibre channels). So not only will LUN0 be seen as different scsi devices between server1 and server2 - server1 (and server2) will see the very same physical LUN0 on the storage layer as multiple different scsi devices. E.g. server1 can see LUN0 as device sdk and device sdm.
To get a sane and consistent view, a logical device is needed - where this device is called for example data1, and will always refer to LUN0, irrespective of what the scsi device names happen to be at the time.
This is done via WWIDs - identifier strings that uniquely identifies scsi devices sdk and sdm as being storage device LUN0.
What is also needed is the logical device, data1 in our example, to support all I/O paths to LUN0. So it should use both scsi devices sdk and sdm - and when one fails (e.g. fibre channel cable breaks), be able to fall all I/O over from the broken path (e.g. scsi sdk) to the working path (e.g. scsi sdm).
ASM diskgroups should be created using the logical and consistently named device - e.g. device data1 in our example.
In your case, ASMLib created logical devices ASM01 and ASM02. These logical devices provide you with a consistent interface to the actual storage LUNs, irrespective of what the kernel happens to call the scsi devices it creates for these LUNs.
I prefer not using ASMLib, but udev and multipath instead. These are standard Open Source drivers for Linux, and originated from, and are used in, some of the largest computing clusters in the world, for addressing storage layers with PBs of storage.