When to use wwnn and wwpn pools

[miwitte]

I have deployed a few UCS installs and have used static wwnn and wwpn. The problem I see with using wwnn and wwpnn pools is that if you mask you Luns to a wwpn on the host and the service profile is removed there is the potential of the host getting a new wwpn or another host getting that wwpn from the pool. This would cause some real issues. The same goes with wwnn with zoning as the wwnn could change is a service profile is removed and re associated or pulled oto another host.  Just looking for a real world use cause where a wwnn and wwpn pool makes sense.

[Geordie Guy]

Storage subsystems allow masking of a range or list of WWNs for LUNs, I'm not aware of a storage subsystem that can't be configured in such a way that a changed source WWN/PN inescapably results in loss of access to storage.

[Robert Burns]

Once a WWPN and WWNN are assigned to a Service Profile they remain assigned for the life of that profile.  Even if you disassociate the profile from a blade it will not relinquish the WWN's back to the pool.

If you're thinking that if you delete a Service Profile that you might give access to that previously provisioned LUN to another newly created Service Profile which gets allocated the same old WWPN- then yes you're correct, this might present a problem.  Just like any physcial HBA in a server, if you were going to move it from one server to another you would be expected to remove the Array config of the LUNs.  This is server deprovisioning 101.

There's a few ways to provision storage with UCS.  You can go ahead and pre-carve up LUNs for each WWPN in your pool, or you can create your Service Profiles first, then have your SAN admin carve up LUNs as required at the time the profile is created.  This is the safest way in my opinion.  You don't burn space on your SAN, and there's greater control what/when LUNs are provisioned.

In your case just remember if you destroy a Service Profile, destroy the LUNs also.

Does that clear up your issue/question?

Regards,

Robert

[miwitte]

I didnt realize that once it was assigned it was assigned for the life of the profile. My concern was that if you dis associated the profile it would put it back into the pool and it could be reused I guess I never thought of that. I have never seen that in writing anywhere in the courses I took. Is this the same for MAC and UUID pools as well? So the hardware is stateless, but the service profile pulling parameters from pools are not and once assigned they are assigned until its deleted.  Makes perfect sense.

[Robert Burns · Accepted solution]

You're exactly correct.  MAC pools/UUID are also statically assigned for the life of a Service Profile.  They're only returned if/when the SP is deleted.

The best use-case for pools is being to tag/allocate your identifying resources accordingly.  In my lab I have a certain MAC pool for everyone in my team.
The first 3 octets of any MAC will always be Cisco's OUI (Vendor ID) and the last three I use to distinguish the UCS system, User each MAC address belongs to.

Ex

Rob-MAC-pool.

0025.b571.0001 - 0025.b571.FFFF

Legend

Cisco Vendor ID (Not modifiable)

User ID (15 people in my team)

UCS System ID (We have multiple systems)

Incremental Value

Similarly you can use this to distinguish the OS (WIn/Lin/VMW) and which systems the MACs belong to.  I find this especially handy when tracing traffic through my network or tracking down servers sending high traffic.  Anyone in my core if I see a MAC address I can immediately identify the source, OS, and/or user it belongs to

Regards,

Robert

[miwitte]

Perfect that clears it up!