copper ingot
We are currently having Controller A and Controller B configured for iSCSI connection with Port No. Controller A - 0a & 0b | Controller B - 0a & 0b.
My Host VM is on VMware vSphere and Host VM is connected to NetApp Storage via iSCSI Connection.
The problem is Controller A and B is working as active passive. When I take down Controller A then Controller B is becoming active. Both Controllers are not working as active active.
frank thistle
For a single LUN/Volume, the ownership of the LUN is on a per-controller basis with E-Series. Both controllers do not read/write to the same LUN at the same time.
Typically the first Volume you create is owned by Controller A, and the next by Controller B, and so-forth in a round-robin style. You can look at the "Preferred Owner" and "Current Owner" of your volumes to see the controller that ALUA will advertise the optimal paths via (you can see this in Storage > Volumes, and add the extra columns to the view). You can redistribute the volumes so they are sent back to their Preferred Owner (https://docs.netapp.com/us-en/e-series-santricity/sm-storage/redistribute-volumes.html).
How many volumes do you have? And do you have "Automatic Load Balancing" enabled in Settings > System (its down the bottom).
copper ingot
@frank thistle - Thanks for the reply...I have only one volume in place as of now
Do we have any NetApp KB Article for this information - For a single LUN/Volume, the ownership of the LUN is on a per-controller basis with E-Series. Both controllers do not read/write to the same LUN at the same time.
copper ingot
Automatic Load Balancing is enabled
frank thistle
@copper ingot So that would be why. Each volume has a "Preferred Owner" and "Current Owner". The Current Owner is the controller that currently controls the reads and writes to that volume, and will be advertised as the Optimised paths. Preferred Owner is who the volume wants to be owned by. If automatic load balancing is enabled then the Preferred Owner is mostly meaningless, as volumes can switch ownership between controllers based on controller loads.
There is a description of this archicture starting on Page 30 "SANtricity Storage Features" here: https://www.netapp.com/pdf.html?item=/media/17120-tr4724pdf.pdf
copper ingot
<@867144350356865045> So that would be why. Each volume has a "Preferred Owner" ...
Let me check the document
copper ingot
My Controller B both 0a and 0b is not establishing the iSCSI connection towards Host.
frank thistle
Are the baseboard ports, 0a and 0b, configured for FC or iSCSI? The baseboard ports (the two onboard ports on the controller) can typically operate as 16Gb FC or 10GbE iSCSI. SANtricity has a process, called the Feature Pack, to convert the personality of those ports.
The instructions are located here: https://library.netapp.com/ecmdocs/ECMLP2773527/html/GUID-234B7897-2ED2-4D8B-9177-0FBE405E913B.html.
If in doubt, please log a support case and they can walk you through it.
copper ingot
Configured on iSCSI with 10GbE iSCSI. Case is already Logged and Issue is resolved now. Controller B 0b Port SFP replaced and changed the cable connectivity at NetApp End.
Thanks @frank thistle for your help
frank thistle
Awesome to hear you gor it solved.