[cisco-voip] UC on UCS LUN Best Practices for Co-residency

[Peter Slow]

We have separate datastores (LUNs) for every UC VM we run. We decided to do
it that way to allow the SAN guys to play more with what devices get put on
what storage volume on their back-end. What ways are most effective for
improving performance is storage vendor and array specific, but i have seen
general recommendations agree that less-stuff-per-lun is good in regard to
I/O/sec so we've done that, but it does cost more on a few levels since
what sizes of storage you have available need to be planned out much more
carefully in advance, and leaving a little overhead on each datastore uses
space.

Zoning, the SAN equivalent of MAC Address access-lists, are used to say
what WWPNs or what WWNNs can see what LUNs. (Configured in the SAN) Here,
in general, every blade in each of our UCS clusters can see all the LUNs
for servers hosted in that cluster.  (So all VMWare hosts in that VMWare
Datacenter can run see the same set of datastores and run another blade's
VM if need be.)


On Fri, Jan 20, 2012 at 10:29 AM, Chris Ward (chrward) <chrward at cisco.com>wrote:

> Hi Ted,****
>
> ** **
>
> LUNs don’t have to be dedicated to physical hardware. You setup the
> mappings on your SAN switch. So for example, in my lab, I have a 8-blade
> UCS B-Series chassis connected to an MDS with 2 SANs hanging off of it. I
> configured my MDS port mappings to allow all 8 ESXi hosts to be able to
> reach all 22 LUNS (between the two SANs). This isn’t necessarily
> recommended, but in my lab environment I am looking for flexibility more
> than anything else. So you can certainly have more than one host access a
> single LUN.****
>
> ** **
>
> I don’t really understand your first question about physical disk saving,
> but if you provide some clarity for me, perhaps I can help there also.****
>
> ** **
>
> +Chris****
>
> Hosted Collaboration Solution TME****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
> *Sent:* Thursday, January 19, 2012 9:42 PM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] UC on UCS LUN Best Practices for Co-residency****
>
> ** **
>
> Does anyone have a best practices are for LUN configuration regarding UC
> B-Series Co-Residency? I have read through the doc below regarding "shared
> storage considerations" but still have some things that don't add up (no
> pun intended)****
>
>  ****
>
> I see that LUN size should be between 500 GB and 1.5 TB and hold between 4
> and 8 UC Apps (I assume the later is to conserve physical Disk space)
> however is there a logical way that these should be dedicated to the
> physical server with regards to physical server portability down the road?
> Can a LUN be mapped to more than one physical server, I would think
> not? These may be stupid questions but I'm a bit new to VMWare/B-Series
> so I didn't know if there were some best practices from the field that
> people adhere to? If physical space was not an issue it would almost seem
> more logical to make all LUNs 500GB and just have a 1:1 mapping to VDisks
> for portability but again I'm a UCS/VMWare Noob. Thanks for any guidance**
> **
>
>  ****
>
> http://docwiki.cisco.com/wiki/Shared_Storage_Considerations****
>
>  ****
>
> T****
>
>  ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120120/82336d8a/attachment.html>