NLB, ARR, IIS, DFS-R, Shared Configuration, SSL Offload, Windows Authentication, SNI, CCS in one place with AutomatedLab

Go to English version

[MAJ 21/12/2019] Ajout d’un binding SNI sur les noeuds ARR pour attaquer le site sans passer par le NLB. Plusieurs onglets s’ouvrent maintenant sur CA01 pour accéder directement à tous les sites en directe les serveurs sans passer par le NLB.

MAJ 16/12/2019] Une version simplifiée de cette architecture sans ARR (juste une répartition de charge de 2 serveurs IIS avec du NLB) existe ici.

Si vous ne connaissez pas AutomatedLab je vous invite fortement à vous rendre ici pour découvrir cette solution avant de poursuivre la lecture de cet article. Au passage n’hésitez pas à suivre Raimund Andrée sur GitHub et Twitter .

Dans le cadre d’un POC chez un client je devais proposer une solution redondante de deux serveurs Application Request Routing  (ARR) qui eux-mêmes devaient répartir leurs applications sur deux serveurs IIS. Au final une solution similaire à celle décrite ici (avec seulement 2 « content servers »/IIS):

 

Use of Application Request Routing and Network Load Balancing
Use of Application Request Routing and Network Load Balancing

Quelques prérequis :

  1. Pas de connection Internet disponible depuis les serveurs. (Ce qui est, rappellons-le, une bonne pratique sur les environnements de production). Donc de ce fait l’utilisation de Web Platform Installer était exclue (cf. le contenu du fichier Extensions.zip)
  2. La solution devait être automatisable de bout en bout (dans le cadre du POC).
  3. La solution devait être simple (dans le cadre du POC).

Network Load Balancing était parfait pour la répartition de charge au niveau ARR et avait l’avantage d’être natif dans Windows (simplicité).

Au passage le besoin final exprimé était plus simple que la solution finale : Authentification anonyme, pas de certificats (donc pas besoin de SSL Offload,  Server Name Indication ni de Centralized SSL Certificate Support), aucun besoin de configuration partagée (d’où le DFS-R). Mon envie d’aller plus loin a fait le reste !

Le support récent de Raimund au sujet d’un scénario AutomatedLab fonctionnel sur DSC avec SQL Server 2016 (basé sur l’article Using SQL Server 2016 for a DSC Pull Server) avait donné naissance à ce script. C’était donc l’occasion pour moi d’aller un peu plus loin avec AutomatedLab.

J’ai donc élaboré le script suivant. Ce script a besoin de :

Je n’ai implémenté aucune affinité cliente (Ni au niveau NLB, ni au niveau ARR) de manière à avoir un trafic réparti équitablement à tous les niveaux.

L’environnement est composé de 6 serveurs :

  • ARRNODE01 : Premier serveur ARR de la ferme NLB
  • ARRNODE02 : Second serveur ARR de la ferme NLB
  • IISNODE01 : Premier serveur IIS de la ferme ARR
  • IISNODE02 : Second serveur IIS de la ferme ARR
  • CA01 : Autorité de certificats
  • DC01 : Contrôleur de domaine (contoso.com)

Le nom des serveurs est écrit dans le code (faites un « Global Replace » CTRL+H si les noms ne vous conviennent pas). De même que certains autres paramètres tels que :

  • Le nom du Lab (« NLBARRLab » par défaut)
  • Le compte à utiliser (« Administrator » par défaut)
  • Le mot de passe associé (« P@ssw0rd » par défaut)
  • Le nom du domaine (FQDN et NetBIOS) (« contoso.com » et « CONTOSO » par défaut)
  • Le compte du compte de démarrage de l’application pool IIS (« IISAppPoolUser » par défaut)
  • Le nom de l’application répartie (« arr.contoso.com » par défaut)

Une fois le script terminé (~40 min sur mon Laptop : Processeur Core i7 de 8ième génération avec 8 coeurs + SSD), connectez-vous sur CA01 (utilisé en tant que poste client pour l’authentification Windows via Kerberos) et naviguez vers https://arr.contoso.com/ (Page par défaut dans IE). Vous obtiendrez alors :

Vous constaterez alors les points suivants :

  • Le contenu dynamique est servi par les serveurs IIS (IISNODE01 ici).
  • Les images (ainsi que d’autres ressources statiques) sont servies par les serveurs ARR (ARRNODE01 et ARRNODE02 en alternance)
  • L’authentification Windows via Kerberos est opérationnelle et vous êtes authentifié sur un serveur IIS (IISNODE01 ici).

Un certain nombre d’articles m’ont été utiles pour la mise en place de cette solution :

Aller à la version française

[Update 12/21/2019] Adding an SNI binding on the ARR nodes to reach the site without going through the NLB. Several tabs now open on CA01 to directly reach all the sites directly to the servers without going through the NLB.

[Update 12/16/2019] A simplified version of this architecture without ARR (just a load balancing of 2 IIS servers with NLB) exists here.

If you do not know AutomatedLab I strongly urge you to go here to discover this solution before continuing reading this article. In the meantime do not hesitate to follow Raimund Andrée on GitHub and Twitter .

In the context of a POC for a customer I had to propose a redundant solution of two Application Request Routing (ARR) servers which themselves had to distribute their applications on two IIS servers. Finally a solution similar to the one described here (with only 2 « content servers » / IIS):
Use of Application Request Routing and Network Load Balancing

Some prerequisites:

  • No internet connection available from the servers. (Which is, let’s remember, a good practice on production environments.) So the use of Web Platform Installer was excluded (see the contents of the Extensions.zip file)
  • The solution had to be fully automatable (as part of the POC).
  • The solution had to be simple (as part of the POC).

Network Load Balancing was perfect for load balancing at the ARR level and had the advantage of being built in in Windows (simplicity).

The expressed final need was simpler than the final solution: Anonymous authentication, no certificates (no need for SSL Offload,  Server Name Indication or Centralized SSL Certificate Support), no need for shared configuration (hence the DFS-R). My desire to go further has done the rest!

Raimund’s recent support for a functional AutomatedLab scenario on DSC with SQL Server 2016 (based on the article Using SQL Server 2016 for a DSC Pull Server) gave birth to this script. It was an opportunity for me to go a step further with AutomatedLab.

So I developed the following script. This script needs:

I did not implement any client affinity (Neither at the NLB level nor at the ARR level) so as to have a traffic distributed equitably at all levels.

The environment is composed of 6 servers:

  • ARRNODE01: First ARR Server on NLB Webfarm
  • ARRNODE02: Second ARR Server on NLB Webfarm
  • IISNODE01: First IIS server on the ARR webfarm
  • IISNODE02: Second IIS server of the ARR webfarm
  • CA01: Certificate Authority
  • DC01: Domain Controller (contoso.com)

The name of the servers is written in the code (make a « Global Replace » CTRL+H if the names do not suit you). As well as certain other parameters such as:

  • Lab name (« NLBARRLab » by default)
  • The account to use (« Administrator » by default)
  • The associated password (« P@ssw0rd » by default)
  • The domain name (FQDN and NetBIOS) (« contoso.com » and « CONTOSO » by default)
  • The IIS application pool identity (« IISAppPoolUser » by default)
  • The name of the load balanced application (« arr.contoso.com » by default)

Once the script is done (~ 40 min on my Laptop: 8th Gen Core i7 Processor with 8 cores + SSD), connect to CA01 (used as a client workstation for Windows authentication via Kerberos) and navigate to https://arr.contoso.com/ (Default page in IE). You will then get:

 

You will see the following points:

  • Dynamic content is served by IIS servers (IISNODE01 here).
  • The images (as well as other static resources) are served by the ARR servers (ARRNODE01 and ARRNODE02 alternately)
  • Windows authentication via Kerberos is operational and you are authenticated on an IIS server (IISNODE01 here).

Here are some other links I found helpful during my personal configuration:

 

Laurent.

Feel free to share:)
Tweet
Étiqueté avec , , , ,