Igroup Connectivity to Vtic

[scott_dugan]

Hi Guys,

I have several igroups that seem to be connected via the Vtic interconnect.

10:00:00:00:c9:78:82:e1 (logged in on: vtic, 0a)
        10:00:00:00:c9:78:82:e2 (logged in on: vtic, 0d)
        10:00:00:00:c9:78:83:bf (logged in on: 0a, vtic)
        10:00:00:00:c9:78:83:c0 (logged in on: vtic, 0d)
        10:00:00:00:c9:7c:fc:77 (logged in on: vtic, 0d)
        10:00:00:00:c9:7c:fe:2e (logged in on: vtic, 0a)
        10:00:00:00:c9:7c:fe:2f (logged in on: vtic, 0d)
        10:00:00:00:c9:7c:f9:de (logged in on: vtic, 0d)

/vol/vol_PNA_ESXDS01/qt_PNA_ESXDS01/PNA_ESXDS01.lun  (2 days, 9 hours, 59 minutes, 9 seconds)
        Read (kbytes)   Write (kbytes)  Read Ops  Write Ops  Other Ops  QFulls  Partner Ops Partner KBytes
             320610077       99050885        6424405   4773160    53244           0       22788                 0

What i am trying to find out is if this is normal? And should i be worries about the igroup listing the Vtic as a connection path?

Thanks in advance guiys.

[rwelshman]

From what I've read in the past, the order of devices listed after the "logged in on" information is random and doesn't have to do with the path the lun is using. And that it should use the interface on the filer the lun is hosted on as a default.

Can you reset the counters on the luns and watch to see if the partner OPS grow?

[lebedevanton]

from what I can gather, you have a lun thats a datastore on your esx host.

/vol/vol_PNA_ESXDS01/qt_PNA_ESXDS01/PNA_ESXDS01.lun

its normal to see vtic and you want to see it in your igroups.

what is not normal is to see a high amount of partner ops. that would mean that the path taken is not optimal and the data requests are going through another path, i.e partner.

[scott_dugan]

Thanks guys fr all your help.

I have reset the counters, ESX looks ok but my exchange 2007 environment running on Windows 2008 with Microsoft MPIO is not looking so good.

Any suggestions welcome.

vol/xxxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxx/xxxxxxxxxxxxx.lun  (0 hours, 0 minutes, 55 seconds)
        Read (kbytes)   Write (kbytes)  Read Ops  Write Ops  Other Ops  QFulls  Partner Ops Partner KBytes
        4112                         1588            71        59         0          0       102         5412     
    xxxxxxxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxx.lun  (0 hours, 0 minutes, 55 seconds)
        Read (kbytes)   Write (kbytes)  Read Ops  Write Ops  Other Ops  QFulls  Partner Ops Partner KBytes
        15912                     39216           1132      3282       0          0       2075        25812    
    xxxxxxxxxx/xxxxxxxxxxxxxx/xxxxxxxxxxxxxx.lun  (0 hours, 0 minutes, 55 seconds)
        Read (kbytes)   Write (kbytes)  Read Ops  Write Ops  Other Ops  QFulls  Partner Ops Partner KBytes
        53352                    13736           910       130        0          0       1023        66968    
   xxxxxxxxxxxxx/xxxxxxxxxxxx/xxxxxxxxx.lun  (0 hours, 0 minutes, 55 seconds)
        Read (kbytes)   Write (kbytes)  Read Ops  Write Ops  Other Ops  QFulls  Partner Ops Partner KBytes
        3184                     19868           307       1881       0          0       1091        11988 

Thanks in advance guys...

[rwelshman]

I haven't worked with the 2008 MPIO yet (The first 2008 server has just been setup with fibre so I'll have a crash course soon). But is there any sort of MPIO interface that you can look at any of the details? There is typically a way to specify the preferred path (you can do it in ESX and SnapDrive). And maybe Windows 2008 in its infinite wisdom has choosen the wrong path as the primary.

[stevensmithSCC]

Windows 2008 MPIO is ALUA aware. ALUA is a way to advise of the cost of a particular paths, so local paths are chosen in preference to partner. I am assuming that you have system manager installed as your first choice admin console, to check ALUA is enabled:

1. Open Storage > LUNs > Initiator Groups

2. Right Click on the iGroup > Edit

3. You will see the "ALUA (Asymmetric logical unit Access) features enabled", check the box.

4. Then update the MPIO policy to Weighted Path

This should make Windows update the paths and prevent the non-optimal comms. But being windows it may require a reboot.

Let me know how you get on.

[lebedevanton]

so hang on, if you have a VM thats running windows 2008 and its an exchange box, your ESX host is already ALUA aware, if you are running VMware ESX 4.0 or 4.1 (i think in 3.5 you have to enable ALUA).

to check for alua do a igroup show -v

it will show you all your igroups with wwns and which ports its going to.

you can then enable ALUA on your igroup by doing; igroup set <igroup name> alua yes

[stevensmithSCC]

If the Exchange Server is a Virtual Machine then ESX handles all of the MPIO, meaning nothing needs to be done in the Windows OS. But in this case it appears that the Exchange box is physical or it would not be visible in iGroup show.

Do not set ALUA to one for ESX 3.5, as it can result in Kernal Panics on the ESX Server. ESX 3.5 never got full ALUA support as it was included in 4.0 and 4.1. For ESXi you need to install Virtual Storage Console (VSC) on the Virtual Centre instance, update the configuration for the ESX and reboot to enable ALUA. Once this is completed you can go to manage paths and see the ALUA callout is in use.

[scott_dugan]

Thanks Guys for all your help/posts on this.

is not My exchange environment is not virtual. i bought this up due to the paths and partner times listed.