If you have been following my journal over the last couple of weeks (actually this getting to be months!) you’ll know that I have been creating Organizations and Organizational Networks. In my first run through (creating a PAYG Organization vDC) I also got the very long wizard to create an Organization Network that connected to the External Network. If you remember on the first run through I ticked off the option to “Share this network with other vDC’s in the Organization.
Well I doubt 255.255.255.0/24 range of IP address to cover EVERY VM in every Organization vDC – and that all the VMs in all my vDC within an organization could use the SAME vCNS Edge Gateway. For me in lab environment I’m fine, its not like my single Edge Gateway needs NAT/Route/Firewall thousands and thousands of VM. This configuration did save me bags of time – because after creating my “Production” vDC for the CorpHQ – the Organization Network was already assigned. That’s a nice bit of automation.
Note: The observant amongst you will notice the first screen grab say 172.168.4.x but the second screen grab said 172.168.5.x. I ended up changing the IP range from x.x.4 to x.x.5 because I forgot there was stuff on that network already – namely some storage systems – and didn’t want overlap or paths being created from vApps that could anyway, get near to the storage!
So you might think my work is done. Well, not quite. If you remember there’s actually two types of Organization network – on that DOES NOT connect to the “External Network” and one that does. This can be get a bit confusing because occasionally when this gets discussed you end up using phrases like “the External Organization Network” and the “Internal Organization Network” – lay on top of that there’s there’s this separate thang called the “External Network”. You’d be forgive for getting tangled up in the phraseology. Occasionally, you will see dialog boxes and documentation talking about “Routed” and “Isolated” Organization Networks as well. For me its quite simple – an external/routed Organization Network gets to the outside world, the world outside of the Organization – that could be the wider corporate network (say to access another organization) or the Internet. Whereas an internal/isolate Organization Networks is just for comms between vApps inside the organization where outbound (or even inbound) access is never needed.
If your from a vSphere background like me – I guess one analogy would be to compare this distinction to a Standard vSwitch. Its possible to have Standard vSwitch with no vmnics, with one vmnic and with many vmnics. We could call these internal, external with no fault-tolerence/load-balancing, and we call the second one external with fault-tolerence/load-balancing. For me the Routed Org Network and the Isolated Org Network are on a much, much bigger scale the same thing.
You can kick of the creation of another Organization Network by switching to the Organization > Virtual DataCenters > Select a Datacenter, Select the Org VDC Networks tab, and hitting the big fat green plus +.
[Remember, only a SysAdmin in vDC can create Organization Networks whereas Organization Admin can manage them once they exist…]
When you hit that green button. There you will see the dialog box like so:
This takes a little bit of explanation. Like why is the option to “Create routed network by connecting to existing edge gateway” greyed/dimmed? That’s because we don’t have a “spare” vCNS Edge Gateway created. The one we do have is already in use and is backing the existing Organization Network I created earlier. The option to “Connect directly to an external network” is possible but could be highly dangerous and break the principles of multi-tenancy. The would allow a vApp to speak directly to the external network use an IP address on that external network. So rather than using a 172.168.5.x address it would need an IP from the range that normally backs my “external network” (in my case 192.168.3.x). So… if we had two Orgs connected directly to the external network a.) you would need a lot more IP address from that network range. b.) potentially OrgA could see the traffic or OrgB. There traffic would be on the SAME network using the SAME IP. To be brutally honest, although this possible – I haven’t been able to think of a good reason (yet!) to ever configure this option. Unless the idea of secure multi-tenancy is concept that doesn’t appeal to people. If that’s the case, you might need to rethink your ideas about what this cloud thingy actually is… 😉
In the “Configure Network” page I decided to use the 10.x.x.x range for the internal/isolated Organization Network. It does occur to me that my IP in my lab environment is totally topsy-turvy. I would prefer for the external networks to use 10.x.x.x, The Organization Networks to use 172.x.x.x and the vApp Networks to use 192.x.x.x. That way my classifications of IP would follow the principles of using gradually smaller IP ranges to smaller amounts of nodes. But right now given I know my lab environment is months are away from being dissembled it hardly seems worth the effort. But it is something for me to consider in my new lab environment, and especially if I wind-up writing a book on the subject.
Note: One interesting note is this deploys vCNS Edge Gateway – but only to offer up IP address from this range – the Edge Gateway is not enabled for NAT/Firewall or any other additional functionality. This because as an “isolated” Organization Network by definition it doesn’t allow for any communication outside of the Organization anyway. By the way. I later thought better of using 10.x.x.x for this Organization Network – and later I blew it away and opted for 172.168.x.x network instead.
All that was needed next was a name, description and whether the Organization Network should be made available to all the Virtual Datacenters.
Whilst this “sharing” of Organization Networks is a great time saver. It did make me wonder if I’d initially handled the “Test/Dev” Virtual Datacenter properly. It strikes me that in a Physical Datacenter – we generally put “development” environments on different kit and also on different networks. Here I am giving that “Test/Dev” Virtual Datacenter access to the wider corp network and access to the wider organization network. I figured I really needed to stop that – and give the “Text/Dev” Virtual Datacenter is own non-shared Organization network without access to the wider external network, or access to the rest of the Organization – a sort of “Corp-HQ DevelopmentOnlyOrgNetwork”
Anyway, it turned out my disabling of the Organization vDC before creating a new Organization Network was a bright idea. I perhaps misunderstood the use of the “disabling” option which stops new vApps being created and powered on. I saw it as “maintenance mode” where I could keep a Organization vDC from being used whilst I made major changes. It seems as if the Organization vDC needs to be enabled before you can add an Organization Network.
Once created the “isolated” Organization Network has a different type of icon assigned to it – compared to the Organization Network connected to an External Network – showing network traffic within the “cloud”, as opposed to network without of the “cloud”.
This task created a resource pool for CorpHQ “Production Virtual Datacenter” on the “Gold” cluster in vSphere, together with a vCNS Edge Gateway (called vse-CorpHQ-InternalOrgNetwork). So my work here was done, but my work else where was just beginning… I wanted to create an Organization Network just for my Test/Dev Organization and re-configure their Virtual Datacenter so it only access to it – with no access to CorpHQ-InternalOrgNetwork or the CorpHQ-OrgCorpNetwork. I knew I wouldn’t
Step1: Create in the Test/Dev Virtual Datacenter a new non-shared Organization vDC…
Step2: Add new “CorpHQ-DevelopmentOrgNetwork” into the existing vApps
That’s done by expanding the vApp and selecting the “Networking” tab, and using the big green + button to add in additional networks its should be allowed to access. Don’t forget to hit the “Apply” button or your changes will not take affect.
Step3: Reconfigure VMs within the vApp to use the new Organization Network
Note: With Step3/4/5 I found the vApp needed to be in a powered off state in order for me to gain full control over its networking. That makes sense if you think about it. It’s not as if you would re-patch and re-IP a physical or virtual machine without disconnecting all users.
Click the “Virtual Machines” tab, right-click each VM, and select the Hardware tab, and then change the Organization Network assignment. I found the VMs had to be powered off to be able to make this change.
Step4: Enable Guest Customization
Changing the network assignment means in many cases a change in the IP address. Additionally, this VM now resides on a different network – and that can raise issues of what happens to its MAC address. So this is a pretty major change if you think about it. You would have to ask yourself what the impact would be on the applications residing in the guest operating system.
Lather and Rinse for each vApp/VM using the “old” Organization Network.
Step5: Remove from each vApp and Remove from Organization
Returning back to the vApp “Network” tab, you can right click and Organization Network and select “Delete”. This removes the reference to the Organization Network to the vApp, but doesn’t literally delete the Organization Network altogether. I found the vApp had to be powered off to complete this task. These “delete” options need to be handled with care. Sometime “delete” means “remove this reference to…” and sometimes “delete” means permanently destroy… as you will see late…!
Step6: Remove Organization Networks from Test/Dev Organizational Virtual Datacenter
Now that I knew the neither the CorpHQ-InternalOrgNetwork or the CorpHQ-OrgCorpNetwork wasn’t in use I could remove them from the Test/Dev Organization. This turned out to be more dangerous than I’d first thought.
IMPORTANT: So earlier a did a “delete” of reference to Organization Network backing a vApp. That was safe. This could be potentially dangerous. Delete here means your trying to delete the Organization Network. If it is “shared” with other Organization vDC and not an “in use” object it will be deleted. In most case this delete will be unsuccessful because the Organization Network will be “in use” somewhere, and you will get the standard warning message. By doing this task I accidentally deleted the “InternalOrgNetwork” I created a moment ago. Opps…
Some Nebulous Thoughts:
Writing this article started to make myself question a number of things I’ve done over the last 30 odd posts. When I created my first Organization I decided to create a Test/Dev Organization Virtual Datacenter. My reason for starting with a Test/Dev vDC was because I was learning and didn’t want to do anything that would be classed as production yet. I’m wondering if that was entirely wise from admin perspective.
I mapped the Test/Dev vDC to the Silver Cluster, and made my first Organization Network – which just so happened to be connected to the External Network. Now the main vCNS Edge Gateway that I use to get to wider “Corp” External Network resides on the Silver Cluster – for some reason that just irks me. It shouldn’t so long as the vSphere Hosts servicing it are working okay. I just “feel” as if my main “production” vCNS should reside on the Silver cluster, it should be on the Gold Cluster! Also by using the “sharing” option I gave the Test/Dev vDC access to Organization Networks which I later felt was inappropriate. Having deployed a couple of vApps to Test/Dev vDC is was a quite a bit work to reconfigure the vApps, and the VMs within them. Remember that involved a re-IP process!
All this says to me its HOW important it is to plan this all about before you start clicking buttons like I did. But hey, this is learning process – and sometimes you have to have not-very-nice experiences in order to learn from those experiences. So how would I have done things differently if I had my time again. Well, I guess I might have started creating the “Production vDC” first, together with the Organization Network that allow for both access to the External Corp Network as well as an Isolated/Internal Org network – I think I would have probably used the “shared” option because in most case (apart from development) any vDC is going to need access to one of those networks. Next I would have created the Test/Dev vDC, and at the end added an Organization Network just for it – not-shared – and then removed the two Organization Networks created earlier. That means an new Organization vDC would get the my two default “Organization Network”, but not the Development Network.
It strikes me that although an initially I rather liked the “shared” option for the Organization Network, I’m wondering if you should be careful with usage. Sharing is great, don’t get me wrong – but a shared Organization Network is shared with EVERY Virtual Datacenter in the same Organization. That runs the risk of exposing networks to Organization vDC’s that shouldn’t have access. Like allowing the “Test/Dev” vDC access to the Organization Network (isolated) and Organization Network (External) that’s perhaps not something that would happen in the real world…