iSCSI - static vs dynamic discovery?

[rickardnobel]

When using iSCSI, is there any advantage with using static discovery compared to dynamic?

From what I understand when using dynamic you point to a certain IP address and TCP port and the iSCSI initator will contact the target and ask for LUNs, which then will be accessable. When using static this information has to be specificed manual. Is that correct, and is there any reason to use static?

[marcelo_soares]

The static discovery will only acquire LUNs from the initiators you inserted. The dynamic will probe the SAN for all initiators it has so you don't need to manage this.

Does not have anything to do with the LUNs, which will keep coming in a per target way.

If you add an IP on the dynamic discovery, they will be inserted on the static.

Marcelo Soares

VMWare Certified Professional 310/410

Virtualization Tech Master

Globant Argentina

Consider awarding points for "helpful" and/or "correct" answers.

[chadwickking]

Straight from the vsphere 4 handbook:

Dynamic Discovery Also known as Send Targets discovery. Each time the initiator contacts a

specified iSCSI server, the initiator sends the Send Targets request to the server.

The server responds by supplying a list of available targets to the initiator. The

names and IP addresses of these targets appear on the Static Discovery tab. If

you remove a static target added by dynamic discovery, the target might be

returned to the list the next time a rescan happens, the HBA is reset, or the host

is rebooted.

Static Discovery The initiator does not have to perform any discovery. The initiator has a list of

targets it can contact and uses their IP addresses and target names to

communicate with them.

Vsphere iSCSI config PDF:

http://www.vmware.com/pdf/vsphere4/r40/vsp_40_iscsi_san_cfg.pdf

To answer your question I dont believe there is any real benefit that I could see in using dynamic over static.

Regards,

Chad King

VCP

"If you find this post helpful in anyway please award points as necessary"

[rickardnobel]

The static discovery will only acquire LUNs from the initiators you inserted. The dynamic will probe the SAN for all initiators it has so you don't need to manage this.

I do not really understand. The initator is the the client part of iSCSI right?

If you add an IP on the dynamic discovery, they will be inserted on the static.

Yes, so that is mostly why I wonder if there is any advantages of using static, if it is easier with the dynamic way and they end up on the Static tab anyway?

[chadwickking]

It just eliminates an additional management step that you would normally have to do. Here is another similar community post.

http://communities.vmware.com/message/1387072

Regards,

Chad King

VCP

"If you find this post helpful in anyway please award points as necessary"

[marcelo_soares]

Sorry... total typo: I was talking about targets, not initiators.

Marcelo Soares

VMWare Certified Professional 310/410

Virtualization Tech Master

Globant Argentina

Consider awarding points for "helpful" and/or "correct" answers.109619

[peterdabr]

There are at least two reason that I know of that it makes sense to use static over dynamic. First being that in many cases software based iscsi targets often listen on multiple IPs by default, if the sever is multi-homed. You don't want iscsi intiator to obtain IPs of a target for which intiator has no way of reaching.

Second being a situation when you have a iSCSI-based shared storage in an Active-Active configuration, allowing you to pin down certain hosts to certain storage nodes. That's when 'Static' comes in handy.

Cheers.

[chadwickking]

Nice response, I even recall reading something similar to that. I believe a user reported an ESX host set to Dynamic Discoovery kept trying to add LUNS that is was not authorized to use on a rescan it would run every two minutes. They ended pu changing a setting on the EMC array and a setting on the actual ESX server as well to keep this from happening. I will note this response for future questions and may even blog it to get it out there in the web world. Googling and researching didnt prove to be very productive but none the less good information to know about.

Regards,

Chad King

VCP

"If you find this post helpful in anyway please award points as necessary"

[rickardnobel]

Thanks a lot for all answers.

There are at least two reason that I know of that it makes sense to use static over dynamic. First being that in many cases software based iscsi targets often listen on multiple IPs by default, if the sever is multi-homed. You don't want iscsi intiator to obtain IPs of a target for which intiator has no way of reaching.

First: Do I understand it correct that the Dynamic Discovery does not ask for which LUNs that are present? (That was what I thought). And that it asks a certain IP address at a certain TCP port for which "targets" it has? And that the returned list could be a list of IP addresses if the iSCSI server has several?

Second: Why is it software based iSCSI targets (that would something running on a OS and not on a "real" SAN then?) more often has several IP addresses? Could not a SAN based iSCSI target have several IP addresses, perhaps to be able to spread the sessions over aggregated links (802.3ad) on switches and up to the ESX with "ip hash" load balancing?

[peterdabr · Accepted solution]

You are right, Dynamic Discovery has initiator send 'SendTargets' request to a single IP address/port and if the target listens on multiple names and addresses, all of them are sent in a form of TargetName and TargetAddress (IP:port#). I believe determining what LUNs are behind the target is not a part of Dynamic Discovery

As for your second question, server hardware is probably more flexible in terms of NICs that can be used, therefore software-based ISCSI is more flexible as well, allowing setting up multiple IPs. Multiple IP/port combinations ont the target gives many more options: one being the ability to connect to the storage from different networks (although that can also be accomplished on routed networks ), second being more paths in multipathing configuration when the same LUNs can be accessed using two different IP addresses. And lastly, so that IP hash policy could be used for better load distribution between pNICS in NIC teaming configuration on the ESX host.

[rickardnobel]

Thank you for this information!