Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Premier contact avec Windows Server AppFabric partie I

Poster un commentaire

Dans ce premier article d’une série de 4, nous allons découvrir Windows Server AppFabric et apprendre à déployer un cluster.

Par la suite nous ferons fonctionner les différents services proposés par l’outil.

Edit 3/4/2015: Microsoft annonce la fin du support de AppFabric 1.1 pour le 2 avril 2016. Un an pour se préparer donc. Pour en savoir plus sur les options:

http://blogs.msdn.com/b/appfabric/archive/2015/04/02/windows-server-appfabric-1-1-ends-support-4-2-2016.aspx?utm_source=twitterfeed&utm_medium=twitter

 

Introduction

Windows Server AppFabric fournit deux services:

  1. Service de cache distribué.
  2. Hébergement de services WCF ou WF
    AppFabric s’appuie sur la couche IIS et WAS (Windows Process Activation Service), mais ajoute des fonctionnalités supplémentaires comme le monitoring ou la configuration des services

En parallèle, une palette de scripts Powershell sont également fournis lors de l’installation de AppFabric afin de faciliter l’administration des différents services. Les commandes disponibles sont ici:

http://technet.microsoft.com/en-us/library/hh847239.aspx

 

Pour finir l’installation ajoute des templates Visual Studio WCF et WF pour simplifier encore plus le déploiement de ces services dans AppFabric.

 

Nous allons surtout nous intéresser au service de cache.

.Net Framework propose un service de cache depuis la version 1.0. Le principal problème de ce cache est d’être lié à IIS et in process.

Il est donc compliqué d’utiliser ce cache depuis des applications type console. On peut tout au plus monter un service WCF en mode de compatibilité ASP.NET et un binding de type http pour utiliser le cache, mais il devra tout de même être hébergé dans IIS.

Depuis .Net Framework 4.0, un cache indépendant de IIS est arrivé. Il est disponible dans l’espace de noms System.Runtime.Caching. C’est mieux, mais il est toujours in process et donc pas distribué.

 

La réponse à ce problème de Microsoft est AppFabric Caching. Le cache AppFabric, anciennement appelé Velocity, est un cache distribué capable de fonctionner en cluster. On peut donc le partager entre plusieurs serveurs et applications.

Parmi les caractéristiques du cache en cluster:

  • ajout/suppression dynamique de nœuds
  • Deux à une centaine de serveurs
  • load balancing automatique
  • haute disponibilité (duplication des données)
  • intégration des sessions Asp.Net
  • Les caches nommés

 

Note: Windows Azure héberge lui aussi un cache distribué. Il est indépendant de AppFabric Caching et ne sera pas abordé dans cet article.

Fonctionnement général

Vu du code le cache ressemble à un dictionnaire. Les données stockées doivent être soit sérialisables au sens de la classe NetDataContractSerializer, soit des tableaux d’octets.

En interne le cluster utilise un algorithme de partition qui permet de disperser sur les différents serveurs. Une table de routage maintient la relation entre la clef de partition et le serveur. Lorsqu’un élément doit être retrouvé le cache client hache la clef et la recherche dans la table de partition. Il obtient ainsi le serveur où la valeur de la clef est stockée.
On peut également configurer le service de cache pour stocker en cache local les données.

Une configuration particulière appelée High Availability (HA) permet de dupliquer les données sur un serveurs dit secondaire du cluster. Il n’existe toutefois pas de notion de serveur secondaire dans AppFabric. Un même nœud peut être à la fois nœud primaire ou nœud secondaire pour différents jeux de données.
Attention, le service de cache charge les données en mémoire. Cela signifie que si tous les serveurs du cluster tombent, tout est perdu. Il vous appartiendra de veiller à ne pas les disposer dans le même rack ou le même hôte.

HA est donc une option intéressante si on a besoin de gérer des notions de session.

 

Les mains dans le cambouis

Déploiement

Deux modèles de déploiement sont supportés:

  1. Sur chaque serveur hébergeant l’application
  2. Sur des serveurs indépendants

2014-07-07_21-39-43

On peut télécharger gratuitement AppFabric ici:

http://www.microsoft.com/en-US/download/details.aspx?id=27115

A ce jour il s’agit de la version 1.1. Les prérequis sont donnés sur la fiche ci-dessus.

Pour avoir testé les deux méthodes, je conseille vivement de faire l’installation avec Web Platform Installer qui présente l’avantage de configurer tout ce qui est nécessaire sur le serveur et d’installer toutes les dépendances.

 Description de l’environnement de test

J’ai installé l’application cliente sur mon poste de travail (Windows 8) et déployé le cluster de cache sur deux VM (Windows 2008 R2) installées sur Windows Azure. L’hébergement Azure n’est en rien indispensable, il faut un hébergement. L’architecture est donc la suivante:

2014-07-10_13-28-38

AmethCluster1 héberge un dossier partagé appelé AppFabricConfig  accessible aux serveurs du cluster de cache via un réseau virtuel.

Ce dossier est utilisé pour entreposer la configuration du cluster. Une alternative est de la placer dans une base de données.

  1. Si vous optez pour le dossier partagé:
    http://msdn.microsoft.com/fr-FR/library/hh351245.aspx
  2. Si vous optez pour la base SQL
    http://msdn.microsoft.com/fr-fr/library/ee790826.aspx

AppFabric supporte 3 fournisseurs:

  1. Fichier XML
  2. Microsoft SQL Server Compact
  3. Microsoft SQL Server

 

Chaque machine se voit dotée d’un compte amethysteAppFabric (même mot de passe).

Important: Ce compte doit être admin local sur le poste qui détient le dossier partagé et doit avoir un accès en lecture seule pour les autres serveurs de cache du cluster.

 

Pour des raisons pratiques j’ai installé un réseau point à site ce qui oblige à se connecter manuellement depuis chaque serveur du cluster. Vous trouverez des informations sur le montage d’un réseau virtuel Azure ici:

https://amethyste16.wordpress.com/2014/06/27/windows-azure-creer-un-reseau-virtuel-point-a-site/

Et en ce qui concerne la déclaration de ressources dans un réseau virtuel Azure:

 https://amethyste16.wordpress.com/2014/07/15/attacher-une-ressource-a-un-reseaux-virtuels-azure/

 

Les IP internes des deux clusters sont:

  • AmethCluster1: 10.0.1.6
  • AmethCluster2: 10.0.1.7

AmethCluster1 jouera le rôle de lead host.

 

Commençons par configurer les deux nœuds du cluster.

Installation du cache serveur: premier nœud

La première phase consiste à installer AppFabric avec WIP. Si on arrive à cet écran, alors tout va bien:

2014-07-10_22-06-35

Vérification

  • Les 3 services suivants sont installés:

2014-07-10_22-09-23On en démarrera plus tard le service de cache une fois le cluster en place le service de cache.

  • IIS Manager s’enrichit de la section AppFabric:

2014-07-10_22-15-02

Ce sont des outils de monitoring.

  • De nouveaux menus apparaissent:

2014-07-10_22-11-44

Ensuite on configure AppFabric en lançant Configure AppFabric.

Le premier écran intéressant est:

2014-07-09_19-54-06

Ces réglages ne nous intéresserons que si l’on utilise AppFabric pour héberger des services WCF ou WF. On va se consacrer au cache dans un premier temps.

  • On garde les options par défaut et on fait Next et on arrive au formulaire de configuration des caches:

2014-07-10_22-22-06

  1. On sélectionne un compte utilisateur pour faire tourner le service (amethysteAppFabric dans notre cas). Le compte par défaut ne peux être utilisé si la machine est dans un groupe de travail
  2. Le provider sera XML puisque l’on a choisit de déposer la configuration dans un répertoire partagé
    Le répertoire est sur la machine que l’on est en train de configurer dans notre cas.
  3. On déclare le répertoire en question justement. Un login sera demandé avec un compte admin sur le PC local
  4. On sélectionne New cluster pour créer un cluster
  • Faire Next

L’écran suivant s’ouvre:

2014-07-09_20-21-19

On laisse les options par défaut. On coche juste AppFabric Server Caching Service.

Note: L’installation se charge de gérer le pare feu si c’est celui de Windows. Si vous utilisez un pare feu tiers, il faudra le faire à la main. Le protocole est TCP.

 

  • Faire Next

2014-07-09_20-24-50

  • Faire Next

Une fois terminé on constate l’apparition du fichier de configuration du cluster dans le répertoire partagé.

 

 Installation du cache serveur: deuxième nœud

La procédure est largement la même. Une fois AppFabric installé, on configure.

Le seul écran différent est celui-ci:

(il y a une erreur sur la copie d’écran, c’est 10.0.1.6 que l’on doit lire)

2014-07-10_23-04-15

On sélectionne Join cluster et on choisit le répertoire partagé sur le premier serveur. Puisque l’on n’a pas monté de DNS on mettra l’adresse IP interne du serveur.

En cliquant sur Browse on vérifie au préalable que l’on parvient à accéder au répertoire partagé.

  • Faire Next.

L’écran Cache node est paramétré comme dans le premier nœud.

Configuration complémentaire

Résolution des noms

En l’absence de DNS il faudra compléter le fichier hosts avec une déclaration de ce type:

  • 10.0.1.6 AmethCluster1

Pour AmethCluster2 et:

  • 10.0.1.7 AmethCluster2

Pour AmethCluster1

Configuration de Powershell

Les scripts doivent être lancés avec élévation de privilège. On les prépare en lançant la commande:

Set-ExecutionPolicy Unrestricted

Les endpoints

On est sous Azure, il faudra donc déclarer des endpoints pour les ports suivants (si vous avez pris les ports par défaut):

  •  22233
  • 22234
  • 22235
  • 22236

Lancement du cluster de cache

Note: si vous avez un compte local il est préférable de lancer la commande depuis le nœud principal (le lead host), c’est à dire celui sur lequel a été créé le fichier de configuration.

 

Depuis un des serveurs du cluster, on lance la console Powershell, puis les commandes:

Use-CacheCluster

Grant-CacheAllowedClientAccount « NT Authority\Network Service »

Suivit de:

Start-CacheCluster

Cette commande démarre le service de cache qui est OFF par défaut. On voit s’afficher:

2014-07-16_09-27-52Si on a un seul nœud, on peut préférer lancer:

Start-CacheHost

 

 

On peut même le lancer à la main comme n’importe quel service, mais ce n’est pas super pratique pour un cluster!

Puis on vérifie que tout va bien en lançant:

Get-Cache

2014-07-16_20-10-17

 

On trouvera dans cet article des informations pour mettre en place le démarrage automatique du cache:

http://jamesbroo.me/automatically-starting-the-windows-server-appfabric-caching-service/

Les fichiers de configuration 

Lorsque l’on choisit SQL comme provider de configuration on ne dispose pas de moyens direct pour modifier la configuration. La commande suivante:

Export-CacheClusterConfig

Permet de récupérer un fichier de configuration au format XML

On réimporte la configuration avec:

Import-CacheClusterConfig

 

 

 Bibliographie

  1. http://blog.infine.com/prise-en-main-du-cache-distribue-microsoft-appfabric-2040
  2. http://www.hanselman.com/blog/InstallingConfiguringAndUsingWindowsServerAppFabricAndTheVelocityMemoryCacheIn10Minutes.aspx
  3. http://jefferytay.wordpress.com/2013/12/11/installing-appfabric-on-windows-server-2012/

 

 

 

 

 

 

 

 

 

 

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s