One of the features of edge gateways in VMware vCloud Director is the capability of implementing load balancer for HTTP, HTTPS and TCP-based applications in a virtual data center. For web applications (in specific HTTP), session management is an important matter. If web developers don’t implement session management in application level (using database, … to store sessions) and rely on Cookies, load balancer could be an issue. In these cases, network administrators are asked to configure load balancer with sticky session. Simply it means that if a client is forwarded to a web server for the first time (especially login page), it should stick to that specific server in later web requests. If it doesn’t happen, user may be forced to login again that would be frustrating!
By the way, when it comes to configuring vShield Edge Gateway to do load balancing, there is no obvious option to choose Sticky Session but it’s possible to do this by specifying proper value for Cookie name in the Virtual Server. As it’s shown in the picture, the procedure is as follows. I assume that you already know how to implement Load Balancer by creating Pool Servers and Virtual Server. See this link fore more information on how to create Load Balancer.
- Right Click on the Edge Gateway and choose ‘Configure Services’
- Select ‘Load Balancer’ tab
- Go to ‘Virtual Servers’ section
- Edit selected Virtual Server
- Choose ‘Cookie’ as Persistence Method instead of default ‘None’
- Type proper value as Cookie Name; i.e, ‘ASP.NET_SessionId’ for .NET application, ‘PHPSESSID’ for PHP, … (ask your developer)
Last week I attended a seminar about SDN (Software Defined Networking) and SDDC (Software Defined Data Center) and I met some high profile people from high profile companies. It seems this topic will be hot in coming years and many manufacturers and providers are coming in to this road. The good news is that there are some standards like OpenFlow managed and maintained by Open Networking Foundation (ONF) and OpenStack that will help in orchestration and inter-operatability to the benefit of customers.
Although, there are some different ideas about the approaches to SDN; for example VMware likes to implement SDN in an all-software solution (NSX) , while Cisco (and other device manufacturers) apparently prefers hardware implemented devices which support SDN. For this latter one, imagine that you have a SDN-enabled switch with some API’s that you can program it to perform in your desired way. That’s cool! Maybe, somethings like load balancing or geofencing can be implemented on the fly by using these APIs in a networking appliance!
For someone with hardware background like myself, this hardware approach seems more attractive and I’m thrilled how it goes. As a matter of fact, a while ago I was thinking: if we can have a tiny device doing a lot of things that can be programmed by developers (I meant Smartphone), why we don’t do the same with more advanced equipments like networking devices? And now it’s coming to the reality! Smart switch or router! combining them with Virtualization and Cloud and on-demand services, customers can implement interesting functionalities which are more cost effective and agile. HP networking was talking about HP SDN App Store! You see! I’m not an advocate of HP but as a result of this, maybe we see a revolution in networking area!
When you want to upgrade VMware vCloud Director 5.1 to version 5.5, VMware vCloud Networking and Security should be upgraded to 5.5 as well because vCloud Director 5.5 is not backward compatible with vShield 5.1. Unfortunately and surprisingly, the documentation on VMware website to do so is not accurate! and it took some time for me to realize what’s the correct procedure. So, I thought it would be useful to share it here for those who can’t find the things mentioned in VMware website to upgrade VMware vCloud till they modify the documentation.
Actually, the part which is not accurate is where it explains the steps to upgrade vShield Edge appliances and it is a crucial part because failing to do this will result in failure in managing Edge gateways through vCloud Director interface. Since there would be one vShield Edge system appliance for each Edge Gateway that is created in Virtual Data Centers, you will have considerable number of vShield Edges in your environment and you should take care of them one by one. By the way, after upgrading vShield Manager to 5.5 is done (it’s easy, just uploading the upgrade bundle in vShield web console and reboot), the most important one is Upgrading vShield Edge.
Let’s look at the document on VMware website: Best practices for upgrading to VMware vCloud Networking and Security 5.5 , it says:
If you have vShield Edge 5.1.0 or later instances, upgrade each Edge:
- Log in to the vSphere Client.
- Click the data center for which vShield Edge instances are to be upgraded.
- Click the Network Visualization tab. All existing vShield Edge instances are shown in the listings page. An arrow icon is shown for each vShield Edge that must be updated.
- Click an Edge and click Upgrade from Actions to start the upgrade. When the Edge is upgraded, the arrow icon no longer appears.
- Repeat for each vShield that must be upgraded
After logging in to vSphere client, you will notice that there is no “Network Visualization” tab, but instead “Network Virtualization” tab. It must be a typo but even after clicking on “Network Virtualization” you will face some errors complaining about not having Acrobot Adobe Reader and so on! While the proper way to do this is to Log in to vShield Manager Web console (not vSphere Client) and look for Network Virtualization (instead of Visualization) under your DataCenter and the rest of steps are the same. You need to choose each Edge, select “Actions” on the top and choose “Upgrade” which will result in an automatic upgrade of that special Edge Gateway to new version.
I hope they modify their document because it is considered as the most reliable one.
Migrating and relocating VMs is a great feature in Virtualized environments. You can do migration and perform your maintenance without disrupting any service. Migration in VMware is easy by utilizing vMotion in vCenter. You right click on VM, then choose Migrate and follow the instructions. But how we can relocate (change datastore or storage vMotion) a VM in vCloud Director?
Actually I was expecting the procedure in vCloud Director to be similar to vCenter, but when I right-clicked on the VM, I couldn’t find a ‘Migrate’ option or something like that. And apparently it’s not a good practice to migrate a VM which is controlled by vCloud Director through vCenter. But fortunately storage vMotion is possible in vCloud Director if you have separate Storage Profiles. To do this kind of relocation, right-click on the VM, then choose ‘Properties’; in ‘General’ tab you will find a pulldown menu for changing Storage Profile. Simply change Storage Profile to the desired one and bingo! Storage will be changed. You can even see the progress of relocation in vCenter.
- As mentioned, changing datastore is possible if proper storage profiles are defined in the environment. That being said, it’s not possible to relocate to an individual, specific datastore. Actually, storage profile is another abstract layer over storage infrastructure that is being used by vCloud Director. To be honest, I didn’t have deeply realized what’s the main purpose of introducing storage profile and storage capability yet and why it doesn’t use datastore cluster instead. By the way, keep in mind that you need to create separate storage profiles if you have separate storages and you want more flexibility in vCloud. To get more information, look at this link: Using Storage Profiles with vCloud Director.
- I couldn’t find much resources on the effects of migrating a VM from one host to another in vCloud Director environment; it is possible to perform this in vCenter and I did it in some cases with no issues. I suppose vCloud Director is working on higher level and will be notified of the changes.
I’ve got some design considerations about creating Volumes in storage which supposed to be used by virtualization infrastructure (VMware 5.1) as datastore; I ended up reading this great article by Michael Webster which saved my day and I would like to share:
The Case for Larger Than 2TB Virtual Disks and The Gotcha with VMFS
Overall, it seems that VMware vSphere 5.5 has good advantages and improvements over 5.1.
In VMware vCloud Director 5.1, NAT (Network Address Translation) and PAT (Port Address Translation) can be implemented using Edge Gateway of a vDC. Edge Gateway is created by Networking and Security component if you want a routed network in your Virtual Data Center.
Both NAT and PAT rules can be added/configured in Edge Network Services under NAT tab. There you can define Source NAT/PAT (SNAT) or Destination NAT/PAT (DNAT) rules. Apparently, SNAT provides connectivity to external network for your internal network users/machines and DNAT provides access to your internal network (the whole network or a specific machine or a specified port) from an external network.
The interesting point is that as it shown in the figure, in both cases, either SNAT or DNAT you have to choose your external network (‘Internet’ in this example) as the ‘Applied on’ network.
The other important thing is that you need to have a Firewall rule for NAT/PAT rules. For example if you are PAT’ing port 80 of an external IP to port 80 of an internal IP (DNAT), there must be a rule in Firewall that allows access to port 80 of external IP. In fact, in this case it is firewall that acts first; after firewall allows the connection, translation (DNAT) would be done.