Highly Available Citrix StoreFront Implementation on the Microsoft Azure Public Cloud

Highly Available Citrix StoreFront Implementation on the Microsoft Azure Public Cloud

Highly Available Citrix StoreFront Implementation on the Microsoft Azure Public Cloud

This post has already been read 9217 times!

Its easy to deploy Citrix products into a Public Cloud such as Microsoft Azure, however just assuming that as it is in the Microsoft Cloud it will be resilient is often the reason that services hosted in the cloud fail to operate as expected.

This article will walk you through the process of making sure your Citrix StoreFront implementation in Microsoft Azure will stay up and operational at all times.

I am certainly NOT saying that this could or should replace the Citrix NetScaler as a load balancer however with the current limitations that the Citrix NetScaler has in Microsoft Azure it is a good option for keeping some form of fail over in your StoreFront deployment in the cloud.

This article assumes that you already have a working environment in Azure and that you have 2 StoreFront servers, on the domain, StoreFront installed and working as a Server Group.

NOTE: In this example I have 2 StoreFront servers running but NOT as a single server group.  This is because I want the appearance of each store to be different to demonstrate the load balancing working.

So, lets get to it…

01 - 2 storefront servers

As you can see I have 2 StoreFront servers running in the same region ready to go.

Step 1 – Static IP Addressing

First open up Windows Powershell for Azure and connect to your subscription that the servers are running in and type in the commands below for each StoreFront server

02 - set static addresses for machines

NOTE: The servers may restart once you assign the IP Addresses!

Step 2 – Availability Set

You need to add both of your StoreFront servers to a Availability Set.  The reason for this is that when Microsoft patch the services in Azure they do not take into account the workloads you are running.  Therefore by creating an availability set and adding both StoreFront servers into it you are instructing Microsoft to keep the servers on separate racks in the datacenter and also on different patching cycles.

Navigate to your primary StoreFront server and select Configure

03 - configure primary storefront

Select Create an Availability Set

04 - create availability set

Give the Availability Set a Name

05 - name availability set

Click Save

06 - save

Confirm the Save action – be aware that the server may be restarted as a result of this being created

07 - confirm save

If you click on Dashboard you will see that the availability set has been created but Azure is warning you that there is only 1 instance running in it currently

08 - single server availability set

Navigate to your secondary StoreFront server and click Configure

09 - configure secondary storefront server

Select your Availability Set from the drop down list provided

10 - select availability set

Click Save

06 - save

Confirm the save action – NOTE: You server may be restarted when you apply this

11 - confirm save

At this point your Availability Set has been created but you want to confirm that your 2 StoreFront servers are running on different Patch and Fault Domains.

Click on Cloud Services

12 - select cloud service

Select the Cloud Service that both your StoreFront servers are running in and select Instances.  Here you should see that the Update Domain and Fault Domain are different for both servers.  This means that the servers will never be down at the same time unless Microsoft loose a datacenter

13 - validate fault domain

Step 3 – Check Storage Replication

You will need to ensure that your Storage is Locally Redundant.  To check this click on Storage

14 - storage

Select Configure and ensure that Locally Redundant is selected

15 - locally redundant

Step 4 – Create Internal Load Balancer

Next you will need to create an Internal Load Balancer in Microsoft Azure with 2 nodes in pointing to each of your StoreFront Servers

16 - internal load balancer diag

First open up Windows Powershell for Azure and connect to your subscription.  Create a new Internal Load Balancer by typing in the below command.  ServiceName is the name of the cloud service that you want the ILB in, Give it a Name, tell it what subnet you want the Load Balancer on and give it a static IP Address that is not in use.

17 - create internal lb

Next type in the below command to ensure that the Internal Load Balancer has been created correctly

18 - validate internal load balancer

Next you need to add an End Point for your primary StoreFront server.  Type in the following command giving the End Point a Name, Internal and External Port, Protocol and a Load Balanced Set Name

19 - add primary sf endpoint 80

At this point you have set up a load balancer and bound port 80 from your primary StoreFront server to it.  You could test this by opening up a browser and putting in http://192.168.1.100 but that does not look so nice, therefore you should create a DNS record in your dns lookup zone and point it to the Load Balancer IP Address

20 - add dns record for lb

Once you have done this test that it is working by performing a nslookup on the new domain name

21 - test dns record

You should now be able to open up a browser and connect to your new dns name, whick in turn will direct you to the primary StoreFront server in your Load Balanced set

22 - test web access to storefront

Switch back to your Azure Powershell window and add the second node (Secondary StoreFront server) to the Load Balancer

23 - add secondary sf endpoint 80

OPTIONAL: You can check the End Points running on the StoreFront servers by entering the command below

24 - check end points

Step 5 – Configure NetScaler

You need to change the StoreFront Session Settings on your NetScaler to reflect the new Load Balancer IP Address.  Login to your NetScaler and Open up the Session Policies section under the NetScaler Gateway Node

27 - open session profile

Edit your Session Profile and change the Home Page Address to point to your new DNS record for StoreFront (pointing at teh Load Balancer IP Address) – In this case I have just put in the IP Address

28 - edit homepage

Do the same for the Published Application settings

29 - edit session profile

Save your NetScaler Config

Step 6 – Test the Fail Over

For this example I have changed the banner colour for StoreFront

BMUK-SF

25 - storefront 1

BMUK-SF-2

26 - storefront 2

Shutdown StoreFront Server 2

30 - shutdown storefront 2

Log into your NetScaler Gateway

31 - login to netscaler gateway

Your Apps will be displayed – Note the RED background – this session is being directed to BMUK-SF

32 - primary storefront active

Log out of your NetScaler Gateway and reverse the servers turned on.  Now BMUK-SF2 is ON and BMUK-SF is powered OFF

33 - shutdown storefront 1

Log back into your NetScaler Gateway

31 - login to netscaler gateway

Your Apps will be displayed again, however note the GREEN background – this session is being directed to BMUK-SF-2

34 - failover storefront

Thats it! Thats how to deploy a highly available Citrix StoreFront delivery in the Microsoft Azure Public Cloud.  Hope this helped some of you out, as always please comment and share.

Laters,

b@m

 

Leave a Reply

Your email address will not be published. Required fields are marked *