Surgient Success

If we deploy two seperate application clouds, can workstations in one cloud talk to servers in another deployed cloud?  I've heard it can't be done and also that it can be done. 

Yes, this is possible.  However, it may not be possible in the way that you are expecting.

I assume you are talking about Server Configurations prepared for NAIL isolation and cloning (static IP address configuration within the guest OS image, also configured in the Server Configuration's Network Configuration editor panel).  We typically say that these Server Configurations when they are deployed have two IP addresses--their internal IP address (the static IP address configured in the guest OS image) and their external IP address (the IP address accessible on your LAN that is reserved by NAIL out of your pooled IP address ranges).  Deployed servers of different deployment groups (aka deployed Application Configuration or deployed cloud) can only communicate with each other using the external IP addresses.

The external IP address for a deployed VM is visible in the Console or VQMS.  How to programmatically get the external IP address of a deployed VM is an exercise for the reader :)

There are some details that I'm intentionally leaving out in order to not be too confusing with too much data.  If you want more details, don't hesitate to ask.

Yes, the clouds are prepared for NAIL isolation and cloning.  We want to deploy a cloud of workstations, say anywhere from 20 to 40 that testers will RDP to instead of having to deploy workstations within the applicaiton clouds which already may contain upwards to 20 servers.  The workstations in the workstation cloud would then access the various other app clouds for testing purposes, also, it would give us a pool of workstations for standalone workstation testing for workstation only apps and patches.  Any info anyone has on this would be helpful.

Would these workstations be deployed from Surgient?  If so, will they be using NAIL? 

The problem here is that NAILED machines will not be able to see each other without some rather specific settings.  You could have a different pool for these machines that is another subnet from your cloud.  In this case the only problem is getting the IP's of the servers to your testers. 

I'm familiar with this use case, and it was one of the reasons for the redesign of NAIL in VQMS 5.3.  I forgot that Raymond James is still using 5.2, so now I understand your source of confusion.  Let me explain.

In NAIL for VQMS 5.2 (now known as NAIL2), there are frequently incompatibilities with the NAIL driver implementation and certain routers.  Sometimes this incompatibility manifests itself as an inability to RDP from the user browser to the deployed VM when the end user is on the same subnet as the external IP address of the deployed VM.  The incompatibility would also manifest itself as a failure to connect from a deployed VM of one deployment group (e.g. one of the tester workstation VMs) to a deployed VM of another deployment group (e.g. a web server deployed as part of your multi-server application to test.)  Without sharing too many gory details, the incompatibility is rooted in how the NAIL driver sends all external traffic to the default gateway regardless of destination subnet, and some default gateways don't like this.  As you are probably familiar, we usually work around the problem by configuring the network such that VMs are deployed onto a dedicated VLAN (the "VR network") separated from everything else.  But the workaround gets much more complicated to solve your use case as it requires multiple VLANs and multiple pools of resources.

In NAIL for VQMS 5.3 (aka NAIL3), the potential for incompatibility is removed because NAIL driver is no longer used, and the NAIL server can distiguish network traffic properly.  I.e., external network communication that is destined to the same subnet--like one deployed VM talking to another VM deployed in another deployment group--does not get sent to the default gateway.

Klaus,

I've just come back from vacation.  Since your organization owns and manages your test network, in the simple case you don't necessarily need VLAN isolation.  You just need separate subnets for the types of workloads you want to deploy, e.g. one subnet for "clients" and one subnet for "servers", so long as client traffic is routed off its subnet, you can avoid the gateway issues described above.

I would recommend two pools: one for client workloads and one for servers.  Your testing matrix is probably more volatile from the client perspective, e.g. multiple OS service packs, browsers, etc where Servers would be deployed for a longer period, e.g. two weeks and clients could be brought up and torn down on-demand.  If your Server deployments got soiled by client testing, you would just rollback the Server deployment instead of cancelling and redeploying.

As with networking in general there are a lot of options.

Thanks Richard.  I wish you were a part of our original archetecture planning.  I also want to virtulize our workstation lab so will be needing a recommended plan going forward as to what fits best in our environment.  Thank you