Thanks to : http://www.yellow-bricks.com Really a Huge fan of his work “duncan Epping”. thats what his moto is “Be Social, Share!”
So i am sharing the same for you….
I am Planning to Go for a Cloud Certification so I start studying about vCloud Multi-tenant archiecture:
Networking within vCD is built up out of 3 distinct layers.
- External Network
- Org Network
- vApp Network
These three layers have been created to give the end-user the flexibility needed in a multi purpose virtual datacenter. I have depicted all three layers in the following diagram which shows the logical relationship between the layers:
Some of you technical guys might say, that’s nice but I would like to see something less abstract. I created the following diagram which depicts the different layers in a different way. The diagram shows the three layers. I created a single External Network which links to two Org Networks. These Org Networks in its turn connect to multiple VMs(Org Y) and multiple vApps(Org X).
This is just an example however that illustrates possible network connections and as can clearly be seen it can be rather complex. As demonstrated there are multiple ways to connect vApps to each other or the outside world.
Now that we know some of the basics I will break down the three layers of networking. The first before we will discuss any of the advanced options like vShield Edge or network pools
The External Network is used for inter-Cloud connections. Or as I like to call it “your connection to the outside world”. It is the first network “object” that you create within vCD. An External Network is always backed by a Portgroup, meaning that a portgroup needs to exist within vSphere before you can create this vCD network object. This portgroup can be on a regular vSwitch, a dvSwitch or you could use Nexus 1KV. It all works, and all of them are supported!
Of course it is heavily recommended to set this portgroup up with a VLAN for layer 2 isolation, again note that this is an outbound facing connection for your Org or for multiple Orgs.
Examples of External Networks are:
- VPN to customer site
- Internet connection
As said, an external network can be shared between organizations but is typically created per organization and is your connection from or to your virtual datacenter.
I would to stress that, the external network is your exit from your virtual datacenter or your entrance!
The second object that is created is the Org Network. The Org Network is used for intra-Cloud connections. Or as I like to call it “Cloud internal traffic”. An Org Network is linked to an organization and can be:
- Directly connected to an External Network
- NAT/Routed connected to an External Network
- Completely Isolated
With that meaning that although an Org Network is primarily intended for internal traffic, it can be linked to an External Network to create an entry to or exit from your virtual datacenter. Note that it doesn’t necessarily need to be connected to an External Network, it could be completed isolated and used for “Cloud internal traffic” only! A use case for this would be for instance a test/dev environment where vApps will need to communicate with each other but not with the tenants back-end.
It should also be noted that the Org Network is mandatory! Every organization needs an Org Network, it is the only mandatory network object.
Just for completeness, an Org Network consumes a segment from a Network Pool when it is NAT/Routed or Isolated. A network pool is a collection of L2 networks which will be automatically consumed by vCD when needed, and what I call a segment is one of those L2 networks… basically a portgroup. I will explain Network Pools more in-depth in part 2.
When an Org Network is directly connected it is just a logical entity and physically doesn’t exist. Again in one of the following articles(part 3) I will explain what that looks like in vCenter.
The vApp Network kind of resembles the Org Network as it also consumes a segment from a Network Pool. The vApp Network enables you to have a vApp internal network, this could be useful for isolating specific VMs of a vApp. The vApp Network can be:
- Directly connected to an Org Network
- NAT/Routed to an Org Network
- Completely Isolated
It should be noted that the “directly connected” option for both the Org Network and the vApp Network is just a logical connection. In the back-end it will be directly connected to the layer above.
As shown in an earlier diagram and explained above a vApp can contain multiple networks. This can be used to isolate specific VMs from the outside world. An example is shown in the following diagram where only the Web Server has a connection to the Org Network and the App and Database servers are isolated but do connect to the Web server.
vCD has three different layers of networking. Each of these layers has a specific purpose. The External Network is your connection to the outside world, the Org Network is linked to a specific Organization and the vApp network only resides within a vApp.
That is it for Part 1. Part 2 will focus on the Network Pools and Part 3 will focus on what these vApp, Org and External Networks look like on a vSphere layer and some general best practices.
My tip of the day, if you want to get to know vCD really well, check vCenter every time you make a change and see what happens!
Thanks to : http://www.yellow-bricks.com
In Part 1 of this series we described the different layers of networking. We already briefly spoke about Network Pools and that both a vApp Networks and Org Networks consume a segment out of a pool. In order to fully understand vCD (VMware vCloud Director) networking we will need to explain the foundation for all Cloud Internal traffic first which is the Network Pool.
As described in one of my earlier articles vCD mainly revolves around pooling of resources. This also goes for networking and more specifically for the Org Network and the vApp Network. Each vApp and Org Network will consume a network (segment) out of a defined pool. This network pool typically isolates network “segments” on layer 2 from the other networks in the pool. There are currently 3 types of network pools:
- VLAN Backed
- vCloud Network Isolation Backed (VCNI)
- Portgroup Backed
Each of these pools have specific requirements, recommendations and constraints and they will be listed below. However all of the three different types of pools are interchangeable; with that meaning a segment from a VLAN-Backed Pool and a Portgroup-Backed pool each offer the same functionality to your Org and vApp network and basically should be seen as a means of intra-Cloud transportation. Or to simplify it even further, it provides a wire. This wire enables VMs in a vApp to communicate to each other or vApps in an Org to communicate to each other. This also means, and that might sound very logical to some, the distributed vSwitch / Nexus / vSwitch needs physical uplinks in order to enable communication across multiple hosts in a cluster!
When is a segment of the network pool used? The answer is simple, whenever you create a vApp or Org Network which is not directly connected to the above layer a segment of your designated network pool will be used. Before you ask, the reason the network pool is not used in the case of a “directly” connected Org or vApp network is because the Org/vApp network is just a logical object in that case and the VM/vApp ends up directly in the portgroup the layer above. I will show you what that looks like in Part 3 of this series which will tie part 1 and 2 together including vShield Edge.
Now lets assume you created a VLAN-backed or a vCloud Network Isolation-backed pool. When an isolated or NAT routed vApp/Org network is created vCD will automatically instantiate a new network segment. This segment is essentially a portgroup on a distributed vSwitch. This portgroup will provide layer two isolation between the different segments. As a distributed vSwitch is used every host in your cluster will instantly have the same portgroups available. There is a very specific reason I only mentioned the VLAN Backed and the VCNI Backed pool, for the Portgroup Backed pool you will need to manually pre-create all portgroups and of course ensure all those portgroups are available on every host in the cluster.
To visualize it a bit more I took three screenshots. The first one shows the network pool. The pool is VLAN backed and holds VLAN 1000 through 1100 and these networks will be created on the distributed vSwitched labeled as “dvSwitch”:
Now that we have created a network pool we can create an isolated Org Network, in this case we create a fully isolated Org Network. This isolated org Network aka “Internal network” enables the vApps within your virtual datacenter to communicate to each other:
In order to be able to communicate we need a network segment. This network segment is provisioned from the Network Pool we created earlier, which was VLAN Backed.
After you fill out some of the other details and click “finish” a portgroup is automatically created within vSphere. Although difficult to read the portgroup name contains the Org Network and the VLAN ID. (VLAN 1008 and Org Network “YB-ISO-ORG”). You can even see the task at the bottom of the screenshot:
Hopefully that visualizes the process a bit more. I dropped some steps for the creation of the pool and the Org Network to keep it relatively simple. You can find a full detailed video here. Now as stated earlier each of the the three types of pools have very specific requirements and constraints I listed them below so you can make a decision based on the requirements or constraints you might have.
VLAN-backed network pools require availability of a set of unused VLANs. When an Org or vApp network is created which is based on a VLAN-backed network pool a portgroup is created on a dvSwitch and a VLAN is assigned to this portgroup. It should be noted that all VLANs specified for the pool will need to be trunked to the host and that in most environment the amount of available VLANs is limited.
- Requirements: Distributed vSwitch, pool of available VLANs, Physical uplinks need to support VLAN Trunks.
- Recommendations: n/a
- Constraints: Nexus 1000v and regular vSwitches are not supported currently, amount of available VLANs in most environments.
vCloud Network Isolation Backed
vCloud Network Isolation-backed(VCNI) network pools are flexible, easy to configure and do not require VLANs. vCNI provides layer 2 isolation by utilizing a network overlay. This network overlay is provided by MAC in MAC encapsulation and requires a vDS. For each consumed network vCloud Director creates a portgroup and assigns this portgroup a network ID number. This network ID number is used for the encapsulation of the traffic. As explained vCD uses MAC in MAC for the encapsulation of traffic. However, because of that the use of VCNI requires an increase in the MTU of the underlying transport network(dvSwitch) to avoid frame fragmentation due to the minor overhead cause by the MAC in MAC encapsulation.
Now this is a very thin explanation, but I don’t want to go to deep into this as it would only complicate things.
- Requirements: Distributed vSwitch
- Recommendations: minimum of 1 VLAN, MTU Increase (24Bytes, 1500 –> 1524).
- Constraints: Nexus 1000v and regular vSwitches are not supported currently.
Portgroup-backed pools require pre-created portgroups within the vSphere environment. Portgroup-backed pools are in my opinion the least flexible of all three options. However, Portgroup-backed pools do not require vDS and can be based on vSS, vDS or Cisco Nexus 1000v which can be a specific customer or even platform requirement.
- Requirements: All portgroups need to be pre-created and available on all hosts of your cluster
- Recommendations: Use a scripted solution or host profiles to create the portgroups to ensure consistency
- Constraints: n/a
Hopefully this clarifies network pools a bit. As explained, when creating and Org of vApp network which is not directly connected to the layer above a network of your Network Pool will be used to provide intra-cloud communication. For those who haven’t used vCD at all, believe me it took me a while to grasp these concepts so don’t be shy and ask questions/comment if anything is unclear.
vApp directly connected to an External routed Org Network
- Internet connection for the VMs in your virtual datacenter. Firewall can be enabled to block all incoming traffic.
- Publicly publishing a single “service” externally by enabling NAT on the vShield Edge device. In this case all incoming traffic will be blocked and only a single IP will be translated and route back to that particular VM.
We will start with the basics. The flow of the network in this case will be:
As explained in Part 1 the External Network is backed by a Portgroup. This portgroup can be a regular portgroup on a vSwitch, or one on a dvSwitch or even the Nexus 1Kv. We will start by creating a dvPortgroup.
Lets first create a dvPortgroup within vCenter. This is the dvPortgroup that the External Network will use. We will give it a VLAN ID for layer 2 isolation. In this case we use VLAN ID 105 and label the dvPortgroup as “dvExternal-105″.
Now we will need to create a network within vCD that enables your vApp and Organization to use this dvPortgroup we just created. We do this by creating an “External Network”. (option 3 on your home screen in vCD.) First we will need to select the correct dvPortgroup we created:
Next thing to do is specify the associated IP Range, Gateway, Netmask etc. The IP-Range is used for any VMs that are directly connected to this External Network and for the vShield Edge devices. But we will show that later in this article.
Next up is is giving the External Network a name, we will keep it simple and name it “External – vlan 105″:
That is it for the External Network part. Now lets create an Org Network.
We will create an External Org Network which is routed to an External Network. (On your home screen go to “7 Add another network to an organization”.) Select the Organization it needs to connect to first and then the real magic starts.
We will use the typical setup. We have unticked “Create an internal network”, and we have selected “Routed connection”:
The cool thing about the network section of vCD is that is shows you what it is building. In this case you can see that the vApp is directly connected to the External Org Network (NAT-Routed) which in its turn is connected to the External Network through a vShield Edge device. The next step is to select the correct External Network that this External Org Network connects to:
Please note that we also have selected a network pool, in this case the vCloud Network Isolated Pool! Next we will need to specify the associated IP Range, Gateway, Netmask for the Org Network. Now you might think that we have already done this but that was for the External Network! The pool of addresses will be used for any device that sits within the Org Network boundaries.
Of course the final step is giving this Org Network a name:
As this post is about networking I will skip the creation of the vApp itself but will show you what we have done in a single screenshot. As this screenshot below shows the VM is directly connected to the Org Network labeled “YB-NAT-Ext-Org”:
Connecting the dots
Now that we have shown you how this is created within vCD you would probably want to know what this results in on a vSphere layer. When we created the Org Network a dvPortgroup was automatically created. This automatic creating was enabled by the use of a network pool. The network pool in this case was a vCloud Network Isolation backed network pool.
The screenshot below shows the dvPortgroup that represents the Org Network. The VM that was created called “Direct”, however vCD uses IDs to uniquely identify VMs and as such it is labeled as “1227504509-Direct” within vSphere. Please note the “F46″ in the name of the dvPortgroup. This means that it is using a fenced network with ID 46. (fenced –> vCloud Network Isolation) This Network Pool happens to use VLAN 107 (V107), which was defined when the pool was created and is also shown in the screenshot below.
In order for VM “1227504509-Direct” to communicate to the outside world it will need a connection to the External Network. As shown and described above VMware vCloud Director uses vShield Edge to do this. In other words, the vShield Edge device will have multiple NICs. This is shown in the following screenshot. The External Network portgroup contains a vShield Edge device (vse-651240915) which is the same device as shown in the screenshot above.
This is the vShield Edge device that enables the VM “1227504509-Direct” to communicate with the outside world, as it is connected to both portgroups.
As it took me a while to understand how this worked, I have created a couple of diagrams. The first diagram shows all components we created and how they are linked:
I guess this is still not saying much. Lets add the flow of the traffic to this diagram by extending it with another vApp. What if you would have two vApps connected to the same Org Network and both VMs of these vApps are on a different host in your cluster and the first VM wants to connect to the second VM? What does the flow of traffic look like? As you can see in the diagram below the VM of the first vApp is connected to the same dvPortgroup. However as both vApps reside on a different host the traffic will need to go to the physical switch layer first:
The other scenario I wanted to show is where a vApp wants to connect to a device on the outside world. In this case I labeled it as “internet” but it could be anything. Also I have assumed that the vShield Edge device resides on a different host than the VM that wants to connect to the internet.
It took me a while to write this “use case”. I hope this makes vCD networking slightly better to understand… but again the key here is to play around with it. If there are any questions please don’t hesitate to reach out to me! If I can find the time I will write another “use case” or maybe I will ask some of the other guys in my team to do something similar.
UPDATE: for a full schematic overview check Hany’s awesome diagram.
One of the core tasks when setting up XenDesktop is to integrate it with the existing customer infrastructure, such as the virtualization platform. Following you can find a screenshot of the respective wizard:
When integrating XenDesktop with vSphere or vCenter respectively, you might encounter the following error message:
„Cannot connect to the vCenter server due to a certificate error. Make sure that the appropriate certificates are installed on the vCenter server, and install the appropriate certificates on the same machine that contains all instances of the host service.“
As the error message indicates, XenDesktop is not able to connect to vCenter because it does not trust the server certificate in use. That commonly happens in POC environments where the customer has not replaced the self-signed server certificate, which is added to the vCenter server during installation, with a certificate signed by a trusted internal/external CA.
According to the XenDesktop Admin Guide in Citrix eDocs (http://support.citrix.com/proddocs/topic/xendesktop-7/cds-vmware-rho.html) a simple solution to this challenge is to connect to vCenter using IE, accept the security warning, click on the certificate warning and install the server certificate on the XenDesktop Broker. Unfortunately this does not work in all cases. But luckily there is another option to make it work:
Update for vCenter / vSphere 6: With vCenter 6 the file structure on the vCenter server has been changed and the approach outlined in the blog does not work any longer. Please use the steps outlined within eDocs – Prepare the virtualization environment: VMware to import and trust the default certificate. In my lab environment importing the vCenter certificate directly from within Internet Explorer worked flawlessly. Make sure to import it for the Local Machine and into the Trusted People store.
vCenter / vSphere 5.5
1. Connect to your vCenter server and browse to „C:\ProgramData\VMware\VMware VirtualCenter\SSL“
2. Copy the cacert.pem file to your XenDesktop Broker (to the C:\Temp directory for example)
3. Open a Microsoft Management Console (by running the mmc.exe command) as an Administrator
4. Add the Certificates Snap-In and select to manage certificates for the local computer account.
5. Browse to „Trusted Root Certification Authorities“ and select Import
6. Import the cacert.pem file. (You need to select „All Files“ from the dropdown menu in the lower right hand corner, to be able to see it)
7. Now you should be able to see the vCenter certificate in the list of trusted certificates and XenDesktop should connect to vCenter without any error message.
Obviously there are good reasons for not using self-signed certificates in production environments, so you should use the aforementioned technique for POC environments only. For all other cases go and get a proper server certificate.
Posted in Citrix Blogs
Below are some of the points where user might face slow logons in accessing citrix apps/desktops:
Winlogon Troubleshooting Steps
Before investing too much time in troubleshooting Citrix, be sure to log onto the Xenapp server via RDP to make sure that logons remain slow there as well.
If you want to know everything that is happening during the logon process, there are verbose logs that can be enabled. In Server 2003, you can enable the USERENV logging by following the KB article: http://support.microsoft.com/kb/221833
If you are using Server 2008, then you can enable something similar following this process:
Let’s examine some of the usual suspects:
In order to prove whether or not there are networking problems in an environment, you’ll need to use some networking tools. Some admins like tools like Wireshark for tracing network communication so you can pick up dropped packets, etc. Recently, I found a great tool for Citrix called SMCC, which can be installed on a trouble Xenapp server. The tool will give you instant feedback on whether there are network problems impacting the server. Read more about it here:
Roaming profiles are public enemy number 1 in a Citrix environment. While there have been countless articles written about why roaming profiles are no longer the best practice, we can never seem to get away from them. They are especially popular in hospital environments where user customization is important, and this is the way they’ve always done it. These profiles can often grow very large in size, and before the Citrix administrator knows it – he is dealing with profiles that are 200MB+ in size. For this reason, when you get a slow Citrix logins call, the first place you should look would be at the profile size. Beyond size you should also look at the location of your roaming profiles, because if there is a wan connectivity issue or any networking problems – it could also impact the speed at which the roaming profile is loaded. Be aware that you can rule roaming profiles in or out quickly by creating a local account for testing purposes, with no reference to the roaming profile.
Windows Group Policy
When a virtualized application is launched through Citrix, it kicks off a huge stream of events. Profiles are engaged, printers are mapped, and policies are applied. Some companies have more complex GPO structure than others, so it’s important to keep it simple whenever possible. In environments where a Citrix farm might have been “inherited” from previously staff that is no longer there, you will sometimes deal with clients who have no idea what their GPO’s are doing or how they are set up. When you suspect GPO’s are the cause of slow application launch, you should isolate a single Citrix server into a fresh OU, and block inheritance completely. Test logins again, and if they improve drastically – you know to focus your efforts on simplifying GPO’s in the environment.
Now that you can accomplish just about anything in Server 2008 via GPO, it’s logon scripts are something that should become a thing of the past shortly. You will still see a lot of these in use in many environments today, so it’s important to know what they do and monitor them closely. If a particular set of Citrix users is experiencing slow logons, it may be important to isolate what logon script is causing the issue. You can test the logon script by running it line-by-line from the command prompt of the Xenapp server that you have isolated for testing. If you find a particular line that hangs for an extended period of time, you’ll know to investigate more closely.
Drive mappings can work great for years, and suddenly stop working for many reasons. Maybe a fileserver has a loose cable, or maybe there is a network problem. The result can be a long delay during logon until the bad drive mapping times out. Most of the time you will discover these bad drive mappings in a log on script, or perhaps a GPO. Once again you can test by logging in with a user account that doesn’t have a log on script or GPO applied to it to see if the log in speed increases.
The volume of printers a user has may cause a slow login depending on how your Citrix policies are configured. Best practice is usually to configure your printer mappings to load in the background during the logon process. If you have a policy that says to do the opposite, you could be waiting a long time to see your virtualized application pop up.
There have been several hotfixes included in the various roll up packs for Xenapp and Presentation server over the years to address slow logons. For this reason, it is best practice to always make sure you are on the most recent roll up package available from Citrix. If you ever end up opening a case with Citrix support, you will find that this will be one of the first things they check for.
There are various causes of slow logons in Citrix environments. Be methodical with your troubleshooting methods, and limit your troubleshooting to a single user account on a single server. By experimenting with AD GPO’s and enabling/disabling logon scripts, you should be able to narrow down the root cause of the issue quickly.
Posted in CitrixTechs.com
Also check Citrix’s “Optimization Guide: User Logon”
I would try:
- Removing or blocking as many GPOs as possible.
- Removing or disabling your logon script. Also check no one has snuck anything into usrlogon.cmd on the XenApp server
- Disable Citrix Client Drive Mapping
- Disable Citrix Client Printer Mapping
- Disable Roaming Profiles
- Check there are no dodgy entries in DNS or in your hosts file on the XenApp server