Hocshop
VMware Employee
VMware Employee

How to configure the Appvol agent in the master image VM in a multi-site deploy

Jump to solution

Hi all,

I am wondering how you would configure the App Vol agent in the master image VM for a multi-site deploy.

What I have (as per the recommended architecture for multi-site deploys) is the following:

2 sites

In each site there are 2 App Vol mgrs connecting to their own local SQL DB

The 2 App Vol mgrs at each site are below a local Load balancer

When you configure the App Vol agent in a client VM for multiple App Vol managers (as recommended for redundancy), you just add extra registry dwords for each additional manager.

Therefore for the layout above would I be better to do which of the following on the master VM image (that will serve both sites)?

a) configure the registry of the master image to have all 4 App Vol mgr IPs

b) configure the registry to only have the 2 Load Balancer IP addresses

c) configure a single LB on top of the 2 existing Load Balancers and put that single IP address

I believe it doesn´t really matter as long as the master image can contact all of the IPs that are configured however I wonder if there is a "preferred" way to do it?

Anyone have any ideas?

Regards

0 Kudos
1 Solution

Accepted Solutions
techguy129
Expert
Expert

Option C would be my preferred method. If your LB can redirect to the correct LB at the site then you are good. The downside is that it adds an additional hop.

In your other scenarios, if the app volume agent tries to connect to a manager that isn't available you have to wait for the timeout. I personally would try to avoid this. I don't see any official wording but it seems the agent always checks the first one. You can adjust the timeout settings. The default for a connection is 10 seconds set by the ConnectTimeOutMs

Configuring the SVservice Parameters

View solution in original post

0 Kudos
4 Replies
techguy129
Expert
Expert

Option C would be my preferred method. If your LB can redirect to the correct LB at the site then you are good. The downside is that it adds an additional hop.

In your other scenarios, if the app volume agent tries to connect to a manager that isn't available you have to wait for the timeout. I personally would try to avoid this. I don't see any official wording but it seems the agent always checks the first one. You can adjust the timeout settings. The default for a connection is 10 seconds set by the ConnectTimeOutMs

Configuring the SVservice Parameters

View solution in original post

0 Kudos
Hocshop
VMware Employee
VMware Employee

Thanks Techguy129,

I understand what you are saying.

So would I be right in thinking that, if you have multiple AppVol Mgrs configured in the registry, the agent will try to connect to the first one first. Then, if there is a timeout, it will try Manager2 and then Manager3 etc?

The issue here is that there will be a delay in connecting to the AppVol Mgr if the agent needs to cycle through all the "down" IPs first.

If that is correct then I understand your recommendation and I completely agree.

Also I believe that if you increase the timeout the the agent will just take longer while it tries to connect to the first Manager. If that manager is down then increasing the timeout will make the client experience even worse, right?

Regards

0 Kudos
techguy129
Expert
Expert

Based on Simon Longs explanation found at the link below, I think the assumption is correct that it checks it in order. I honestly haven't tested that theory. Maybe a dev can confirm.

Yes, the experience would be worse if you increase that time. The appvol service connects to the management server at computer startup and user login. What I don't know is if it caches the management server URL that it can connect to after computer startup or it just goes through the list again. It would be simple to figure that out by viewing the app volume service logs.

AppVolumes: Add Multiple App Volume Manager addresses to the App Volumes Agent - The SLOG – SimonLon...

0 Kudos
Hocshop
VMware Employee
VMware Employee

Excellent,

Thank you very much Techguy129.

Your answers have helped me understand the issue and even extend my understanding.

Much appreciated.

Regards

Mark

0 Kudos