Archive for the ‘Misc.’ Category
In this second part of the NSX 6.0 solution architectures series, we are building up on the pervious blog post. If you haven’t already done so, please take a few minutes to read that post at this link.
In this solution, we are changing the way the end-users are accessing the cloud services. In the last part it was a direct web access that was NAT’ed through the External Edge. Here, we are adopting a different approach by enabling the SSL VPN-Plus service on the very same external Edge to allow the end-users to connect directly to the external perimeter network. Let’s examine that in details.
As you can see from the diagram above, we have now one public IP address assigned to the “Uplink” interface of the external Edge. This IP address will be used as the VPN gateway that will allow our end user to passthrough to our External Perimeter network. Once this is configured, the End-user can point his/her browser to the URL: https://vpn.hypervizor.com and from there login with his/her username and password that would be assigned by the service provider. The web interface/portal that the end-user login from is actually part of the SSL VPN-Plus service of the Edge. It is highly customizable as well to reflect your corp identity.
From that portal, the end-use can either launch a publish web application (like a traffic monitory solution), or download the full VPN client to get connected to the external perimeter network as I’ve mentioned earlier. This VPN client has different versions for Windows, Linux or even Mac. Once the client is installed on the end-user machine, he/she can then authenticate (with the same user/pass) and get the applicable IP address (172.16.20.100 in our case here). At this point, the end-user can access either the vCD portal or other applications/services that are running on the external perimeter network like vCenter Operations for monitoring the VMs or perhaps vCenter Chargeback for monitoring the usage and charges and so forth.
Note here that we can still load-balance the vCD portal (https service) and the VMRC like what we did in the last post. The difference here is that we are only load-balancing (but not NAT’ing) the 172.16.10.xx IPs directly. For example, we pick a new IP address, say, 172.16.10.4 and we designate it as the virtual IP of the https service so we configure it to LB to the vCD cell IPs 172.16.10.11 & 13. Same thing holds true for the VMRC service.
Configuring the Parameters
Now let’s take a closer look into some important configuration parameters related to the SSL VPN-Plus service:
In the IP Pool as you see from the screenshot above, you (as the service provider) can set here the IP address pool(s) you want your end-customers to consume their IP configuration from (e.g 172.16.20.100-200). Note here that the IP address you give as a default gateway will be assigned automatically to the Edge. You may also want to setup a dedicated DNS on the external perimeter network for name resolution. The hostnames here would be, for example, anything.ext.hypervizor.com. And the IP addresses being resolved are basically the ones on the 172.16.10.x subnet.
The Private Networks here are the networks that you want your end-user to connect to. In our case here it is the external perimeter network (172.16.10.00/24). Of course, the External Edge will automatically take care of the routing between the 172.16.20.0/24 and 172.16.10.0/24 networks.
The last part I want to show you here is the Installation Package. Here, you can add the external hostname and IP address of the Edge Gateway (or VPN Service if you will). In our case, the hostname is vpn.hypervizor.com and it is resolving to the public IP: 188.8.131.52. You can see also that this package will be available in Windows, Linux or Mac executables.
A look from an End-User perspective
When our end-user connects to the vpn.hypervizor.com from the web, he would get this screen (which again, is customizable).
Once logged in for the first time, the user can download the VPN package (titled Hyper-VPN in our case here).
After the installation is done, the end-user can fire-up the VPN program and connect the network.
As you have seen in these two blog posts, the NSX 6.0 for vSphere product can play a major role in improving, securing and simplifying the way you used to architect and configure your L2-L7 services. We’ve just scratched the surface here to show some of the cool things that can be done with NSX. Imagine the amount of innovation and creativity you (as an architect or an administrator) can have now. What really stands out for me here is how fast you can get all this from sketching the ideas on a piece of paper to real services up and running in a matter of minutes or hours at the most!
Now that VMware NSX 6.0 for vSphere is GA, I can finally start blogging about this incredibly powerful platform! I have been working with NSX 6.0 in my lab for quite sometime and I must say, I am quite impressed with the great new functionalities and improvements over the traditional vCloud Network & Security (vCNS). My personal favorite feature is the unicast VXLAN mechanism that eliminated the requirement for the IP multicasting in your physical network. You can literally get NSX 6.0 up and running in 30min or less! You think I am exaggerating? You should have a look then on my four-part videos here : http://www.hypervizor.com/nsx/
In this post, however, I am presenting the overall NSX 6.0 system architecture. I have used some of the great VMworld2013 presentations as the foundation of this architecture (hats off to our awesome NSBU tech marketing team), but I added my own architecture components to make it thorough as much as an A4 page size could fit.
That being said, this is by no mean a complete architecture of NSX 6.0, but rather a general or high-level design of the main components and how they all interact with each other. As you would expect, I will be publishing in the near future a highly detailed architectures that are focused on technologies like: VXLAN, Distributed Firewall, VPN, Load Balancing, Dynamic Routing (just to name a few). I will be exploring also other solution architectures for NSX 6.0 with VMware products like vCloud Director, vCloud Automation Center and so forth.
Until then, I encourage you to start getting your hands down and dirty with the product through the HOL available online at this link: http://labs.hol.vmware.com/HOL/#lab/558
Before that, and if you feel you are missing the installation and configuration bit of the product, I recommend to watch first my videos on YouTube to get you up-to-speed on this part and to give you also a better understanding on how things should be built and in which order.
- VMware NSX 6.0 for vSphere: 01 Deploying the NSX vAppliance.
- VMware NSX 6.0 for vSphere: 02 Deploying the NSX Controllers.
- VMware NSX 6.0 for vSphere: 03 Preparing Hosts and Configuring Unicast VXLAN.
- VMware NSX 6.0 for vSphere: 04 Configuring a Logical Switch
I know! It’s been like what, a couple of years since I blogged anything? Ok, that’s another story for another time.
Today, however, I am excited to publish a new architecture diagram that I have been working on for quite sometime. The VMware vCloud Suite 5.x.
Before we go any further into the details, I would like to echo the same disclaimer I have on my blog since I joined VMware. The architecture of this diagram, like any other content on my blog, is strictly mine. It’s my very own interpretation of this suite of products. There is probably 100 different ways on how to represent or architect this kind of diagram. How do I know, you ask. Well, I work as a consulting architect at VMware and this is what I do, day in and day out, in the company. Speaking of which, I followed real-world scenarios from my experience with customers when I designed this diagram. It’s like a mix of many scenarios and use cases that I came across with customers. I tried to make it as rich as possible, and yet in a very high level. This is an A2 size diagram, and I can tell you that even if I tried with A0 I wouldn’t be able to have all the details I want. That said, you can’t see in this diagram any technical deep-dives into the technologies like what you are used to in my traditional diagrams.
Back to the main point, and to make a long story short: Your mileage may vary.
How to find your way around the diagram?
The diagram consists of three main areas. The first area is the huge architecture in the middle, which is flowing form the bottom of the page to the top. This is really the meat and potato of the diagram and the one we will spend most of this write-up describing. The second area is the on the right, titled: “Software-defined Datacenter”. This is, as stated on the diagram, a bunch of examples and not a limitation of the SDDC concept (again, as I personally interpret it). I divided this into three main sections – Software-defined Network, Software-defined Storage and last but not least, Software-defined Security. Now the last part of the overall diagram is the one on the top. These are the small gray boxes you can see with short descriptions of the vCS components. I know, it’s pure marketing and it is actually a copy and paste from the official VMware website. The reason why I included this is because I want any CxO standing in front of this busy diagram to understand (even in a very high-level) what is going on there.
Now let’s dig dipper into the actual diagram architecture.
My preferred way to look into this is from bottom to top. You may have already noticed by now the layered-cake approach (if you will) that I followed in the diagram. These layers are starting from “IT” at the bottom of the diagram all the way up to “Public Clouds”. You can also see the dashed lines starting from each layer and fading into the actual diagram to indicate that anything that resides between those lines belong to the designated layer from left to right.
Now into each layer in details:
- IT: these are basically the IT personnel at your organization. Be it management, operations or infrastructure teams. As you can imagine, this could significantly be different from one organization to another. What I have tried to illustrate here is some various role-based responsibilities and how would that map to the vCS products. For example, an Enterprise cloud admin would have access, of course, to the vCloud Automation Center and vCloud Director admin panels. That doesn’t mean that he/she shouldn’t access the vCenter Server/Web-Client. It all boils down to how your IT is structured.
- Products: These are some (not necessarily all) the vCloud Suite products. Now one very, very important thing to note here is that these products are not explicit to the datacenter they are residing at. They are placed in this order for illustration purposes only. In fact, they could be common across datacenters. For example, you may have vCenter Operations running in the primary datacenter only but monitoring remotely all the infrastructure components in the secondary datacenter.
- Physical/Virtual Infrastructure: that’s basically your server, storage and networking hardware along with your virtual infrastructure software including but not limited to: vSphere, Hyper-V, Xen, KVM and so forth. All these resources are endpoints managed and controlled by/through the vCloud Automation Center (vCAC). That’s why you see all these crazy arrows initiated from vCAC and terminated at each end-point.
- Private Cloud(s): Here you can see the actual cloud(s) in the final presentation. In this example, I have showed three different clouds – the IaaS, the PaaS and the Test/Dev. Why three clouds not one, or four? As I mentioned earlier, this is just an example and your use case will vary. One VMware customer would be interested in having only one cloud for IT as a Service. Another customer, like the one here, would require a Platform as a Service, perhaps for rapid application development, and also a test cloud for application testing, evaluations or sandboxes. You can see that the IaaS cloud is consuming resources from a vCloud Director cluster. This could be in your case a native vSphere cluster. Everything is just an end-point for vCAC and it is your ultimate choice where you would want your workloads to run and how. Another very important component here is the vCloud Connector (vCC). The vCC has many great features and use cases. In this particular architecture, you can see that it is being leveraged to migrate workloads on-premise (across the IaaS and Pass clouds) and off-premise to public vCloud providers. It also facilitates a stretched deployment from the on-prem IaaS cloud to an off-prem vCloud provider. Another great feature that vCC has, and not shown here, is the catalog synchronization across clouds. For example, you could have another independent IaaS cloud running at your secondary datacenter but you would like to keep your catalogs across the two clouds in sync.
- End-User Access: Moving up the stack you can see the end-users and how would they typically access the workloads on the various clouds. For example, in the IaaS cloud, an end-user could access his/her workloads either directly through RDP/SSH, or through the vCD portal (to manage his own networking, security..etc), or through the vCAC self-service portal for requesting workloads through workflows and corp governance. Again, you have the maximum flexibility here to design your cloud as you want. Mixing and matching different ways for different users are possible here to meet your business objectives and yet with the full control and governance per the corp guidelines.
- Public Clouds: Last layer in our stack is the public clouds. As the diagram suggests, this could be a vCloud Datacenter Service Provider, the newly launched vCHS (available in the US only at the time of this writing), or a 3rd party public cloud like Amazon EC2. To give you few examples: the corp could have a policy to allow specific end-users to run some workloads on EC2, those users can instantiate workloads right from the corp vCAC portal and, of course, go through the relevant approval workflow. Another example would be related to an internal application that is growing faster than expected and no immediate resources are available on-prem to accommodate this growth. In this case, an enterprise cloud admin could extend this application to a public vCloud provider and yet keeping the same networking/security features enforced.
So there you have it. My latest and very humble attempt to picture the most powerful VMware suite of products to date!