Service Virtualization

  • Private Community
 View Only
Back to Library

Tech Tips: Creating and Configuring Multiple VSEs on the Same Windows Machine 

Oct 13, 2016 12:00 PM

This is an example on Windows 7 machine. 

 

Copied VirtualServiceEnvironment.exe to VirtualServiceEnvironment2.exe.

Copied VirtualServiceEnvironment.exe to VirtualServiceEnvironment3.exe.

 

Copied VirtualServiceEnvironment.vmoptions to VirtualServiceEnvironment2.vmoptions.

Copied VirtualServiceEnvironment.vmoptions to VirtualServiceEnvironment3.vmoptions.

 

This for the VSE Servers, but you can do this for the VSE Services as well.

 

Edited the vmoptions for each vmoptions file.  This file am using the default VSE port, but wanted the name to be other than the default of VSE.

 

vmoptions1

 

Defining with VSE2 and a different unique port.

 

vmoptions2

 

Defining with VSE3 and a different unique port.

 

vmoptions3

 

Display on Server Console:

 

 

On Workstation, have a choice of the 3 VSEs to deploy to that are connected to this one Registry:

 

workstation with access to multiple vses

 

 

Note:  If putting VSEs on different machines and going to the same Registry, use the same type of method as above for the VSE Name.  Even though on different machines, if going to the same Registry, the names need to be unique. You would not have to specify different ports or log files if only one VSE on a machine.

Statistics
1 Favorited
11 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Legacy User
Mar 02, 2018 09:51 AM

There is no balancing technique within DevTest to provide this functionality. Technically, each VSE has its own endpoint (IP and/or Port) -- one reason that you might not want to run two VSEs on the same machine is that the same service should have a different endpoint port.

It is possible to add a load balancer to expose a single "consumer application facing" IP address (endpoint) and create rules within the LB to route to multiple backend VSEs & virtual services. This can get tricky though.

For example,

- Management, maintenance, and deployment of the Registeries, VSEs, virtual services, etc. should not be attempted using the consumer application facing IP endpoint. Use the actual server IP of the DevTest component. This includes connecting to the Registry from the Workstation.

- There is no notion of deploying a service from Workstation to multiple VSEs in a single action. The VS will need to be deployed to each VSE separately.

- If the conversation between the consumer and the virtual service is stateful or allows duplicate specific responses, the LB must control connections such that once a conversation starts, the conversation is "pinned" to that VSE and virtual service for the duration of the conversation. Remember, state within a virtual service is not shared across VSE memory boundaries.

- Virtual Services should exist in both VSEs or LB rules must know how to redirect traffic to the VSE containing the running service.

- Load Balancing does not guarantee an exponential increase in TPS throughput at the service level. Testing will be necessary determine TPS.

- And, there a probably a few more things...

picni01
Dec 15, 2016 06:06 AM

Thanks Marcy for your explanation. In our DevTest Cloud Manager is there a way to balance the same virtual service calls deployed on different VSEs? 

Related Entries and Links

No Related Resource entered.