In part one of this post we talked about the cluster design of the environment as well as the management pod elements. Now we will focus more on the cloud components like Networking and Virtual Datacenters.
Networking
We will use here three different types of virtual switches. The first one will be the vNetwork Standard Switch (vSS) and it will be dedicated to the vSphere environment. I personally prefer to use the vSS with MGMT, vMotion & FT networks to avoid the dependencies on vCenter Server. I’ve talked about this point previously in my vSphere design blog posts so you can have a look on them for more info.
The vSphere Networking
As you see in the diagram above, we are using here a typical design for our vNetwork Standard Switch. An Active/Passive configuration for all the three networks, the SC/MGT, vMotion and FT. Each network is active on a dedicated NIC, and standby on another one.
The Cloud Networking
We will use in our cloud networking the vNetwork Distributed Switch (vDS). You can still use the vSS (or Nexus 1000V) in your design here, but please note that this will limit your functionality. With vSS and N1KV you won’t be able to use both the vCloud Network Isolation and VLAN-baked Network Pools. This might be bearable in small to midsized private clouds where your network provisioning will grow slowly and gradually, but in case of large enterprises or service providers (public cloud space) the vDS should be the way to go in order to support the fully automated network provisioning.
In the diagram above, we have here one dedicated vDS for our network pools. All what you need to do is to create one vDS in vSphere and allocate it to your Network Pool inside the vCloud Director resources. Everything will be provisioned automatically by vDC later on whenever you create a new Organization Network and/or vApp Network. You will keep seeing these cryptic dvs.VC### port groups added on the fly as you provision more and more of your cloud networks. Obviously, you will never have to worry about them from a vSphere perspective as all the administration will always be done from your vCD portal.
In the diagram above, we have another vDS for our External Networks. These networks have to be pre-provisioned by the vSphere admin before using/consuming them in vDC. An example for that would be an Internet connection for your organizations. You basically create a new network in vSphere and hook it up with your internet backbone. Another example would be a network hooked up with a VPN tunnel to a different branch/company/partner.
Please note that you can still use one vDS for both the Network Pools and External Networks, but I would recommend separating them for easier management.
Provider Virtual Datacenter
Our Provider vDCs design will be fairly easy. I’m using two examples here to show you how you can map your vSphere clusters to vCloud Director. In the first example, the Gold vDC, we have a 1:1 mapping with the “Gold Cluster” that we created earlier in vSphere. All the resources of this cluster will be “dedicated” to that Gold Provider vDC. In the second example we have one cluster (which contains 4 high-end blades) sliced down into two resource pools. We are then carving out of these two RPs another two Provider vDCs. We will call the first one a “Silver” PvDC, and the second one “Bronze” PvDC.
Although the general recommendation of the server virtual environments is to use the scale out approach (illustrated in the Gold Cluster), there are some customers I’ve seen who prefer the scale-up approach and use high-end monster servers for that. I’m not going to go into the religious war between the two options, it all comes down to customer requirements and design choices. I just need to point out that the resource pools will make much sense in the case of high-end servers because they normally have large compute power (CPU & MEM) that you would need to utilize more efficiently.
Organization Virtual Datacenters
Now that we’ve explained the simple creation of Provider vDCs, it’s time to have a look into the Organization vDCs. The concept here is somehow similar, however, we have what we call “Allocation Models” when we carve out the resources from the PvDCs to Org-vDCs. Let’s have a closer look.
In the “Gold Org vDC” we are using the “Reservation Pool” to reserve/dedicate the compute resources down from the Gold Provider vDC. I’m showing here another 1:1 mapping although you can obviously use the same Gold vDC to allocate down more resources to another Org-vDC. In this example you can think of a very high SLA requirement and security to one of your BUs or departments where you need dedicate all the resources to it. In my case here all these resources are consumed down by the IT Operations department (or “Organization” as we will call it later).
In the second example, the Silver Org-vDC, we are using a second allocation model – the “Allocation Pool”. In this allocation model we are committing only a “percentage” of the resources available in the Provider vDC. Same thing is happening in the second “Staging” Org-vDC. We are committing another percentage of the Silver PvDC and so forth.
In the third and last example, we are using the “Pay-as-you-go” allocation model. The resources are committed here only when you create the vApps. It makes much sense to use it in case of development environment where vApps are created and used for a period of time without much SLA to guarantee.
Organizations
Last but not least in our cloud environments we have the Organizations. It’s a bit hard to explain this part as it’s quite variant how enterprises do their internal IT (remember, we are exploring here the private cloud). With that said, I’ll use a very simple scenario to keep things as much clear and less complex as possible.
We are having here two Organizations, the IT Ops and IT Dev. The former will act as our operations department that is responsible about the various services in IT, and the latter will be the one providing the internal development in terms of vApps. For various and detailed networking scenarios of the vApp and Organization networks and how they all interact together and relate down to the vSphere networking, you can checkout my diagram here.
There is one part probably missing in the diagram which is the Catalogs. Massimo Re Ferre’ has written a beautiful article on this subject you should check it out for thorough understanding about Catalogs. In our case here we can have two catalogs published by each Org. The first one will be from the IT Ops for the general purpose vApps/ISOs deployed by the whole enterprise, and the second one will be from the IT Dev for the specific internal Apps development (e.g. a SharePoint Intranet/Website or a custom HR application..etc).
Conclusion
In this two-part blog post we went through a simple design for a Private Cloud using VMware vCloud Director. It is impossible to show all the capabilities or the design scenarios for this incredibly powerful product, but hopefully you had an idea on the basic building blocks for starting your own deployment. If there is anything major you think that I missed in this article, please drop a comment or an email and I will cover it in future posts.
Source - http://www.hypervizor.com/
No comments:
Post a Comment