Jump to content
Welcome to our new Citrix community!

Content switching follow up TCP session of Storefront XML to broker


Jordan Kostov

Recommended Posts

Dear all,


I have been trying an outside-of-the-box config that I want to make work.


VPX 13,1 with latest Citrix Storefront and ZDC as a test bed.


Setup is:

- Broker A in domain A

- Broker B in domain B

- domain A and domain B have no trust due to security requirements.

- NetScaler VIP 10.10.10.185 - content switch that forwards backend traffic to:

-> Broker A - if packets include XML information about Domain A

-> Broker B - if packets include XML information about Domain B
-> DEFAULT LOAD BALANCING VIRTUAL SERVER if none of the above is matched. This VIP includes both Broker A and B together.

- NetScaler SNIP 10.10.10.85

-  1 storefront in domain A which is configured to delegate user authentication to the brokers on address https://xml.domain.a

 

Users authenticate to Storefront either with domain A or B -> this goes to https://xml.domain.a at NS VIP 10.10.10.185.
10.10.10.185 uses content switch base on packet body content to forward the backend traffic from 10.10.10.85 to one of the brokers.

 

What is the problem?
When user attempts login in Storefront, 2 TCP sessions are initiated to the XML service.

- Session one - includes XML information about user and domain - this can be used for content switching.

- Session two - is empty and has no visible content that can be load balanced by the content switch. So the NS sends packets from this session to the DEFAULT LOAD BALANCING VIRTUAL SERVER of the content switch.


The problem is in the second TCP Session that goes randomly to one of the brokers so it works 50% of the time.

Is there a way to troubleshoot and fix this? i want all traffic to reach the broker it is intended to go.

 

 

Link to comment
Share on other sites

I would NOT use content switching to sort between two controllers in two difference CVAD/XD sites.

Storefront Needs to know when to fetch resources from StoreA and when to communicate to StoreB.  As this is a multi-request spanning transaction, you can't assume that every request will have that initial identifying information.  

 

5 hours ago, Jordan Kostov said:

DEFAULT LOAD BALANCING VIRTUAL SERVER if none of the above is matched. This VIP includes both Broker A and B together.

- NetScaler SNIP 10.10.10.85

This right is here is a very big problem.  Some requests for SiteB will go to Site's A controllers 50% of time and SiteA requests will go to SiteB's controllers 50% of time. Same problem if you told StoreFront Go to StoreC with ControllerA1 and ControllerB1, 50% of your traffic would be one site only. This isn't how aggregation works at all.

 

 

The way that storefront communicates to a controller and when:

1) User logs onto a storefront Store1.  Storefront performs authentication (usually).

2) StoreFront then forwards the request to the broker or brokers listed.  If a STore is aware of a single SiteA, then it will communicate with a controller in the siteA list (controllerA1 or controllerA2, for example).  If more than one Site is listed, then each site is queried separately a SiteA controller is queries and a SiteB controller is queried to retrieve the set of all apps assigned to this user. This is multi-site aggregation. 

3) The XML request to the controller at this point, hands of authentication details and asks controller to enumerate resources, returning a list of published things to storefront. StoreFront will then assemble the list of resources from SiteA's controllers, and the SiteB's controllers into one unified list of resources for the requesting user.  This is returned by StoreFront to user.

4) When the user goes to launch an application, that request identifies the Site it belongs to and StoreFront then forwards that launch request to a controller in that Site's list. That controller now generates the necessary ICA Files to return to storefront, to return to user to allow launch.  (Omitting any gateway events).

 

You shouldn't content switch this at all.

If you do, what you are effectively configuring storefront to think it is doing:

Talk to SiteC with Controllers A1 or B1 behind it.  Without awareness this should be two different site calls.

Even if content switching would work, the storefront is not able to do what it needs to do to tell the difference between a SiteA call and a SiteB Call.

 

 

If you want to use ONE store for all your users, then you must:

1) Configure SToreFront to see StoreA and controllers A1, A2 itself. Then separate "row" for StoreB and its controllers (B1,B2).

2) If you want only certain users to query SToreA vs. SToreB, then you use StoreFront's ability to map users to stores and filter after authentication GroupA to one store and GroupB to another.

3) Due to your domain separation, you really might want to consider separate Stores, so that DomainA users go to StoreA and talk to SiteA controllers only and Domain Users go to StoreB and talk to SiteB only.

 

 

Bottom line: StoreFront has to be aware of the sites/controllers in use and you can't hide this from storefront in content switching and still have it work. Storefront is designed to match site specific request to site specific controllers.

 

 

 

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...