Ok, so this isn’t really UCS related.\u00a0\u00a0 Just a random thought I had today while working on a lab project… why don’t we have Private VSANs?\u00a0\u00a0 As in, the same type of technology as Private VLANs (PVLANs)?<\/p>\n
First, some background.\u00a0\u00a0 Standard SAN best practice for access control is to use single-initiator\/single-target zoning.\u00a0\u00a0 This means that there’s one zone for each combination of host and storage, tape, virtualization platform, etc port.\u00a0\u00a0\u00a0 Some administrators think this is overkill, and create just a few zones of lots of initiators to single targets, but this is overall a bad idea.\u00a0\u00a0 The purpose of this post is not to argue for single-initiator zoning, since it’s accepted recommended practice.<\/p>\n
Private VLANs provide a method for simplifying access control within a L2 Ethernet domain, restricting access between nodes.\u00a0\u00a0 Community PVLANs allow communication only between members of the same community, and the promiscuous port(s).\u00a0\u00a0 This is actually fairly close to the idea of a fibre channel zone, with the distinction that fibre channel doesn’t have promiscuous ports.\u00a0\u00a0 Isolated PVLANs allow communication only between each individual node and the promiscuous port(s).\u00a0\u00a0 In a way, you could compare this to having a lot of nodes (initiators) zoned only to a single target node (target) in fibre channel – but without the administrative overhead of zoning.<\/p>\n
So, why not combine these approaches?\u00a0\u00a0 Having the concept of an Isolated Private VSAN would simplify some types of fibre channel deployments, by enforcing recommended practices around access control without the administrative overhead.\u00a0 In a smaller environment, you could simply create an Isolated Private VSAN to contain the ports for a given fabric – set the storage ports as promiscuous, and all node ports would be restricted to connecting only to the storage ports – and prevented from communicating with each other.\u00a0\u00a0 In fact, I’d imagine that this would be enforced with standard FC zoning (since that’s the hosts are expecting when they query the name server anyway) – really we’d just be automating the creation of the zones.\u00a0\u00a0 Cisco already does something similar by automatically creating zones when doing Inter-VSAN Routing (IVR).<\/p>\n
For slightly larger environments, I could even see adding in the idea of Community Private VSANs – whereby you group initiators and specify specific target (promiscuous) ports per community – without having to add additional VSANs.<\/p>\n
Now that I’m thinking out-loud, why not have isolated zones instead?\u00a0\u00a0 Mark a zone as “isolated”, and tag any necessary WWNs\/ports\/etc as promiscuous, and enforce the traditional zoning behind the scenes.<\/p>\n
True, this approach wouldn’t accomplish anything that traditional VSANs and zoning do not.\u00a0 The implementation would likely have to use traditional zoning behind the scenes.\u00a0\u00a0 Just as PVLANs aren’t used in every situation, nor would PVSANs, but I could definitely see some use cases here.\u00a0 So what do you think?\u00a0\u00a0 Am I completely insane?\u00a0\u00a0 Thoughts, comments, rebukes are all welcome.\u00a0 \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
Ok, so this isn’t really UCS related.\u00a0\u00a0 Just a random thought I had today while working on a lab project… why don’t we have Private VSANs?\u00a0\u00a0 As in, the same type of technology as Private VLANs (PVLANs)? First, some background.\u00a0\u00a0 Standard SAN best practice for access control is to use single-initiator\/single-target zoning.\u00a0\u00a0 This means that … Continue reading Private Isolated VSANs?<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5],"tags":[22,62],"class_list":["post-158","post","type-post","status-publish","format-standard","hentry","category-miscellaneous","tag-fc","tag-vsan"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/158","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=158"}],"version-history":[{"count":0,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/158\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=158"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}