Re: Priozier for remote port on fibre channel devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Hannes,

sorry for top-posting, but crappy Notes is not really a good client for mailing-list - at least I don't know how to avoid such mess.

The output is

[root@fru3710e ~]# sg_inq /dev/sdc
standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  version=0x04  [SPC-2]
  [AERC=0]  [TrmTsk=0]  NormACA=1  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  BQue=0
  EncServ=0  MultiP=1 (VS=1)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
    length=193 (0xc1)   Peripheral device type: disk
 Vendor identification: EMC    
 Product identification: Invista        
 Product revision level: 5100
 Unit serial number: CKM00xxxxxxxxx

and well, 'weightedpath' is also available in RHEL, but only queries for the device name and the SCSI-address. I wanted to query the remote-port of the storage-device - which is the frontend wwn of the storage device.

Cheers,

Andreas





From:        Hannes Reinecke <hare@xxxxxxx>
To:        dm-devel@xxxxxxxxxx,
Date:        11.01.2013 08:28
Subject:        Re: [dm-devel] Priozier for remote port on fibre channel devices
Sent by:        dm-devel-bounces@xxxxxxxxxx




On 01/11/2013 08:11 AM,
Andreas.Bleischwitz@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> Hello List,
>
> I'm currently facing a problem with a storage virtualization device
> which is located in two different datacenters and shows up as
> another path to a configured SAN-LUN.
> The virtualization device is from EMC² and is called V-PLEX.
>
> So I have something like this:
>
>          DC A
> Host ---VPLEX-DC A---LUN storage A
>    |     |
> ..|...........|...................
>    |     DC B  |
>    ------VPLEX-DC B---LUN storage B
>
> The VPLEX device itself is for storage based mirroring and
> synchronizes write access to storage A to storage B and the other
> way around.
>
> My problem is, that the virtual LUN I get from the VPLEX does not
> have any prioritization given by dm-multipath and looks like this:
>
> mpath3 (36000144000000010e06d8f12ec30dfef) dm-9 EMC,Invista
> [size=5.0G][features=1 queue_if_no_path][hwhandler=0][rw]
> \_ round-robin 0 [prio=1][active]
>   \_ 5:0:1:2 sdad 65:208 [active][ready]
>   \_ 5:0:4:2 sdak 66:64  [active][ready]
>   \_ 5:0:5:2 sdap 66:144 [active][ready]
>   \_ 4:0:0:2 sdc  8:32   [active][ready]
>   \_ 4:0:1:2 sdh  8:112  [active][ready]
>   \_ 4:0:4:2 sdo  8:224  [active][ready]
>   \_ 4:0:5:2 sdt  65:48  [active][ready]
>   \_ 5:0:0:2 sdy  65:128 [active][ready]
>
> That way, write access is made round-robin and access to the
> "remote-devices" - device located in the other DC - creating
> duplicate traffic through the
> SAN switches as the access has to be routed to the remote VPLEX-B
> and it will write to the local VPLEX-A.
>
> I wanted to solve this problem by giving priorities to a path by its
> remote-port - which is different for each connection to a SAN
> device. Unfortunately
> there currently doesn't exist any priorizer and I have to write one
> on my own.
> To make the definition flexible, I would like to have a file with a
> list of port-wwns associated with a priority.
>
> For versions shipped with RHEL5 this could be a simple shell script
> which simply looks up the sysfs file structures of a given device.
> For RHEL6 this has to be
> a binary library. So writing a binary version will make more sense
> than maintaining two different solutions.
>

Well, at least on SLES we're shipping a prioritizer named
'weightedpath' which does exactly this.

However, chances are that the VPLEX is supporting ALUA, so you might
want to use the 'alua' prioritizer here.

What is the output of 'sg_inq /dev/sdc' ?

Cheers,

Hannes
--
Dr. Hannes Reinecke                                        zSeries & Storage
hare@xxxxxxx                                                         +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux