Configuration partagée avec IIS 7
Introduction
Internet modifie la façon dont les entreprises gèrent leurs activités quotidiennes et dont elles sont concurrentielles sur le marché. Avec l’avènement des nouvelles technologies web et l’augmentation du nombre de clients accédant aux ressources disponibles via le web, il est urgent d’améliorer la scalabilité, la disponibilité, la fiabilité et la facilité de gestion des applications. Les applications doivent s’appuyer sur des systèmes qui offrent la possibilité de fournir un temps d’activité élevé, un débit de requête amélioré, une augmentation des transactions utilisateur simultanées et une meilleure valeur de retour sur investissement, comme une meilleure qualité de service, par rapport aux systèmes concurrents.
Les batteries de serveurs web, ou clusters de serveurs, sont devenues la norme pour fournir des applications hautement évolutives, disponibles et gérables en distribuant la charge. Plus précisément, ces attributs d’application sont les principales raisons sous-jacentes aux batteries de serveurs web et à l’équilibrage de charge. En utilisant une batterie de serveurs web, une organisation peut fournir un moyen évolutif d’augmenter la capacité de la base d’utilisateurs qui accède à l’application et à ses ressources simultanément.
Le cluster de serveurs offre une meilleure disponibilité, car plusieurs serveurs distribuent la charge. Le cluster s’adapte également mieux à un nombre accru de clients à un moment donné. Enfin, le cluster offre une expérience de gestion améliorée en gérant l’approvisionnement et l’administration de l’architecture de la batterie de serveurs web en toute simplicité et sans contrainte de ressources opérationnelles.
Vue d’ensemble
Cet article se concentre sur la fonctionnalité de configuration globale centralisée partagée. Cette fonctionnalité permet de prendre en charge des batteries de serveurs web homogènes où les serveurs partagent la même configuration sur un groupe de serveurs. Lorsque vous utilisez un partage UNC, toute modification apportée à un fichier de configuration maître centralisé se propage sur différents serveurs sans outils supplémentaires ou prise en charge par programme.
La première partie de cet article explique comment utiliser l’interface utilisateur d’administration d’IIS 7 ou version ultérieure pour activer et utiliser la configuration partagée. La seconde partie explique comment activer et utiliser la configuration partagée à partir de la ligne de commande.
Objectifs secondaires : ce que cet article ne couvre pas
Plusieurs aspects contribuent à un environnement de batterie de serveurs web réussi, notamment la prise en charge correcte, la facilité de gestion, l’accessibilité, la scalabilité, etc.
La configuration partagée se concentre uniquement sur l’aspect de gestion de la configuration d’une batterie de serveurs web et traite de la configuration entre serveurs. Il existe des outils et d’autres fonctionnalités qui peuvent vous aider à gérer plusieurs serveurs, à copier du contenu, à déployer des modules, à synchroniser des fichiers binaires d’application, à configurer des composants tiers, etc. Ces outils, fonctionnalités et aspects ne sont pas abordés dans cet article.
Cet article explique uniquement comment gérer la configuration à l’aide d’un fichier centralisé sur plusieurs serveurs.
Par conséquent, la configuration partagée permet à un serveur d’accéder à un fichier de configuration dans un partage UNC principal comme s’il s’agissait de sa configuration locale. Ainsi, lorsque vous mettez à jour la configuration à l’aide d’un serveur web frontal, les mises à jour sont effectuées sur tous les autres serveurs.
Il est important de prendre en compte d’autres situations, telles que l’installation d’un module tiers ou l’ajout de paramètres de configuration, et d’inclure des propriétés que seul un serveur peut comprendre et pour lesquelles il dispose des fichiers binaires et du schéma pour fonctionner correctement. Sinon, ce type d’utilisation peut interrompre les autres serveurs.
Pour éviter ce problème dans des batteries homogènes, vous devez désactiver la configuration partagée sur le cluster, mettre à jour le fichier applicationHost local afin qu’il reflète le fichier distant, déployer et mettre à jour les modules et la configuration sur un seul serveur, puis réactiver la configuration partagée sur ce serveur. Vous pouvez ensuite déployer et mettre à jour les fichiers binaires et les modules sur le reste des serveurs avant d’activer à nouveau la configuration partagée.
Environnements de domaine et hors domaine
Certains administrateurs déploient les clusters de serveurs web dans un environnement de domaine, tandis que d’autres les déploient dans un groupe de travail (hors domaine). Cet article décrit les deux scénarios et mentionne les différences et les mises en garde. Il est recommandé de configurer IIS dans un cluster dans un domaine, avec l’aide et la sécurité qu’Active Directory fournit à l’aide d’un contrôleur de domaine.
Prérequis
Vous devez effectuer les étapes suivantes dans l’ordre :
- Installez IIS sur votre serveur, qui sera appelé « serveur web » tout au long de cet article.
- Garantissez l’accès à un second serveur, qui sera appelé « serveur de fichiers » tout au long de cet article. Le serveur de fichiers héberge le partage pour la configuration et le contenu de base, accessible à l’aide d’UNC.
- Chaque étape de cet article suppose que l’étape précédente est terminée. Effectuez toutes les étapes dans l’ordre.
- Pour certaines étapes, il existe une étape équivalente qui peut être effectuée à l’aide de l’interface utilisateur. N’effectuez qu’un seul type d’étape, sauf indication contraire.
Configuration centralisée
L’interface utilisateur d’administration IIS prend en charge la configuration de la redirection de configuration, ainsi que l’exportation des fichiers de configuration et des clés de chiffrement nécessaires vers un chemin spécifié.
Pour exporter des fichiers et configurer la redirection de configuration à l’aide de l’interface utilisateur
- Ouvrez le Gestionnaire IIS.
- Dans l’arborescence, sélectionnez la connexion du serveur pour laquelle vous souhaitez configurer la redirection de configuration.
- Double-cliquez sur Configuration partagée.
- Dans le volet Actions, cliquez sur Exporter la configuration pour exporter les fichiers de configuration nécessaires du serveur local vers un autre emplacement (par exemple, un partage UNC).
- Dans la boîte de dialogue Exporter la configuration, entrez le chemin dans lequel vous souhaitez exporter les fichiers. Entrez un mot de passe pour protéger les clés de chiffrement exportées. Cliquez sur OK pour exporter les fichiers de configuration et les clés de chiffrement protégées par mot de passe.
- Activez la case à cocher Activer la configuration partagée pour activer la redirection de configuration.
- Indiquez le chemin où se trouvent la configuration et les clés de chiffrement, puis spécifiez les informations d’identification à utiliser pour accéder à ce chemin. Cliquez sur Se connecter en tant que... et entrez les informations d’identification.
- Cliquez sur Appliquer pour enregistrer les paramètres. Dans la boîte de dialogue Configuration partagée, entrez le mot de passe que vous avez spécifié pour protéger les clés de chiffrement.
- Cliquez sur OK pour terminer la configuration de la redirection de configuration.
Les étapes ci-dessus décrivent comment exporter la configuration et activer la configuration centralisée. Toutefois, vous n’avez besoin d’exporter la configuration qu’une seule fois. Effectuez les étapes 6 à 9 sur chaque serveur suivant qui utilise la configuration centralisée.
Remarques concernant l’utilisation de l’interface utilisateur
Lors de la configuration de la redirection de configuration, les fichiers exportés sont censés avoir été exportés à l’aide de l’interface utilisateur. En effet, l’interface utilisateur exporte et importe des éléments tels que les clés de chiffrement protégées par mot de passe en utilisant son propre format personnalisé.
Par exemple, si vous avez copié manuellement les fichiers administration.config et applicationHost.config dans un partage, puis exporté manuellement les clés de chiffrement, vous ne pouvez pas utiliser l’interface utilisateur pour configurer la redirection de configuration vers ces fichiers. Cela est dû au fait que les clés de chiffrement exportées ne sont pas au format requis par l’interface utilisateur.
Invite de commandes
Tout au long du reste de cet article, vous devez utiliser une invite de commandes pour exécuter certaines commandes. Il est recommandé d’utiliser une invite de commandes avec des droits d’utilisateur élevés, car certaines commandes ne fonctionnent pas si vous exécutez une invite de commandes normale.
Pour ouvrir une invite de commandes avec des droits d’utilisateur élevés
- Cliquez sur Start.
- Cliquez sur Tous les programmes.
- Cliquez sur Accessoires.
- Cliquez avec le bouton droit sur Invite de commandes, puis sélectionnez Exécuter en tant qu’administrateur.
- Suivez les invites dans toutes les boîtes de dialogue qui s’affichent.
Sauvegarde du fichier applicationHost.config actuel
Lorsque vous essayez de nouvelles fonctionnalités ou modifiez plusieurs paramètres de configuration, il est recommandé de sauvegarder le fichier applicationHost.config actuel.
Pour sauvegarder le fichier applicationHost.config
Ouvrez une invite de commandes.
Accédez au répertoire IIS, qui se trouve par défaut à l’emplacement
%WINDIR%\System32\InetSrv
. Les fichiers de configuration sont stockés dans le répertoire InetSrv\Config. Utilisez l’outil AppCmd pour créer un objet de sauvegarde et sauvegardez le fichier applicationHost.config en exécutant la commande suivante :cd /d %windir%\system32\inetsrv appcmd add backup centralConfigBackup
Remarque
L’outil AppCmd se trouve dans le répertoire InetSrv. Vous devez accéder à l’outil à partir de ce répertoire, sauf si le chemin de l’outil est ajouté aux variables d’environnement du système.
Vérifiez que l’objet de sauvegarde, qui inclut le fichier applicationHost.config et le fichier de métabase hérité pour SMTP et d’autres paramètres de serveur non-web, est présent en exécutant la commande suivante :
appcmd list backup
Pour remplacer le fichier de configuration actuel par le fichier de sauvegarde
Ouvrez une invite de commandes.
Accédez au répertoire IIS, qui se trouve par défaut dans le répertoire InetSrv. Restaurez l’objet de fichier de sauvegarde AppCmd en exécutant la commande suivante :
cd /d %windir%\system32\inetsrv\ appcmd restore backup centralConfigBackup
Création d’un utilisateur pour accéder au partage UNC pour la configuration
Dans un environnement de domaine, un administrateur doit fournir ou créer un compte dans le domaine à utiliser avec Active Directory. Ce compte doit être configuré avec les droits d’utilisateur appropriés pour accéder au partage UNC.
Dans un environnement hors domaine, un administrateur doit créer sur les deux serveurs un utilisateur local disposant de droits d’utilisateur pour accéder au contenu. Le nom d’utilisateur et le mot de passe doivent être identiques sur les serveurs pour fonctionner dans cette configuration. Les étapes suivantes permettent de créer un utilisateur pour lire le partage où réside la configuration partagée.
Pour créer un utilisateur qui peut lire le partage où réside la configuration partagée (hors domaine)
Ouvrez une invite de commandes.
Sur le serveur web (serveur frontal où IIS est installé), créez un utilisateur nommé ConfigUser1 avec le mot de passe ConfigPass1 en exécutant la commande suivante :
net user ConfigUser1 ConfigPass1 /add
Sur le serveur de fichiers (serveur principal où réside la configuration centralisée), créez un utilisateur nommé ConfigUser1 avec le mot de passe ConfigPass1 en exécutant la commande suivante :
net user ConfigUser1 ConfigPass1 /add
Création des partages UNC pour la configuration centralisée et le contenu
Le partage UNC pour la configuration héberge le fichier applicationHost.config pour tous les serveurs qui souhaitent récupérer des données de configuration à partir de cet emplacement centralisé.
Pour créer le partage UNC
Sur le serveur de fichiers, ouvrez une invite de commandes.
Accédez à la racine du lecteur. Exécutez la commande suivante pour créer un répertoire pour la configuration et partager ce répertoire, en veillant à accorder aux utilisateurs les droits d’utilisateur pour lire et écrire dans le répertoire :
md %SystemDrive%\centralconfig net share centralconfig$=%SystemDrive%\centralconfig /grant:Users,Change
Remarque
Cette commande accorde automatiquement des droits utilisateur au groupe d’utilisateurs pour ce partage. L’utilisateur créé pour le scénario hors domaine reçoit automatiquement des droits de modification, qui peuvent être restreints si nécessaire. Pour le scénario de domaine, l’utilisateur doit disposer de droits d’utilisateur définis explicitement pour accéder au partage ou être ajouté au groupe d’utilisateurs dans le système.
Scénario hors domaine : pour renforcer la sécurité du partage, vous pouvez remplacer la partie Users,Change du commutateur /grant par les paramètres ConfigUser1,Change. Seul l’utilisateur spécifié peut accéder au partage.
Scénario de domaine : pour renforcer la sécurité du partage, vous pouvez remplacer la partie Users,Change du commutateur /grant par les paramètres domain\user,Change. Seul l’utilisateur spécifié dispose d’un accès à distance au partage.
Remarque
Les droits d’utilisateur sur un partage sont une union entre les droits d’utilisateur pour le système de fichiers distant et local. Vous devez définir les droits d’utilisateur appropriés pour le répertoire pour un compte de domaine pour pouvoir lire correctement le partage de configuration.
Octroi de droits d’utilisateur aux comptes pour les partages UNC qui hébergent la configuration centralisée et le contenu
Vous devez vous assurer que le compte utilisé pour accéder à la configuration dispose des droits d’utilisateur appropriés. Ce compte est utilisé par IIS pour accéder au partage UNC de la même manière qu’il accède au contenu lorsqu’un répertoire virtuel est mappé à un partage UNC. Les droits d’utilisateur en lecture pour ce compte sont utiles pour accéder au partage uniquement. Par la suite, chaque fois que IIS lit le fichier de configuration, il revient à l’identité dont l’appelant dispose : l’API, l’outil d’administration utilisé ou l’utilisateur connecté à ce moment-là.
Remarque
Le compte ConfigUser1 (ou le compte de domaine équivalent utilisé pour lire la configuration) est différent du compte utilisé pour écrire la configuration. Ces comptes ne doivent pas disposer des droits d’utilisateur en écriture pour le partage ou le fichier de configuration.
Pour accorder des droits d’utilisateur aux comptes pour le partage UNC (domaine)
- Si le compte de domaine fait partie du groupe d’utilisateurs local et que les utilisateurs ont reçu les droits d’accès lors de la création du partage, vous pouvez ignorer les étapes suivantes pour la configuration du domaine. Toutefois, si le compte de domaine permettant d’accéder au partage de fichiers local ne fait partie d’aucun groupe d’utilisateurs local, vous devez exécuter la commande pour accorder des droits d’utilisateur.
- Sur le serveur de fichiers, ouvrez une invite de commandes.
- Fournissez des droits d’utilisateur au compte de domaine pour lire le répertoire dans lequel la configuration est stockée en exécutant la commande suivante :
icacls %SystemDrive%\centralconfig\ /grant domain\user:R
Pour ajouter l’utilisateur UNC (hors domaine et domaine)
Pour les scénarios de domaine et hors domaine, le nom d’utilisateur doit inclure la configuration du travail de traitement par lots d’ouverture de session. Il ne s’agit pas d’un paramètre par défaut dans Windows Server® 2008. Vous devez l’ajouter manuellement au serveur web.
- Cliquez sur Start. Cliquez sur Outils d’administration, puis sélectionnez Stratégie de sécurité locale.
- Sous Stratégies locales, sélectionnez Attribution des droits utilisateur.
- Double-cliquez sur Ouvrir une session en tant que tâche, puis ajoutez l’utilisateur UNC que vous avez créé.
Redirection de la configuration
Introduction
Maintenant que vous avez effectué les étapes précédentes, le serveur web est fonctionnel et le serveur web frontal doit servir le site web par défaut à l’aide de l’adresse de bouclage localhost.
Vous pouvez à présent déplacer la configuration vers un emplacement centralisé. Vous pouvez ainsi déclarer un fichier en tant que fichier maître et l’enregistrer dans un partage UNC pour la configuration de plusieurs serveurs. La modification de ce fichier approvisionne et met à jour toutes les configurations de serveur en même temps.
Pour stocker la configuration dans un partage UNC
Copiez les fichiers applicationHost.config et administration.config à partir du répertoire
%windir%\system32\inetsrv\config
sur le serveur web frontal à partager sur le serveur de fichiers principal. Si le compte d’utilisateur actuellement connecté a un accès en écriture au partage du serveur principal, vous pouvez supprimer le fichier dans le répertoire. Si ce n’est pas le cas, vous devez authentifier le compte d’utilisateur auprès du serveur principal pour effectuer cette étape.Accédez au fichier XML redirection.config existant dans le répertoire de configuration du serveur frontal :
- Utilisez l’Explorateur Windows pour accéder à
%windir%\system32\inetsrv\config
. - Ouvrez le fichier redirection.config. Ce fichier et son contenu sont créés lorsque le serveur web est configuré. Les outils et les API peuvent accéder à ce fichier pour déterminer si cette fonctionnalité est activée ou non.
- Utilisez l’Explorateur Windows pour accéder à
Ouvrez le fichier redirection.config. Définissez la configuration suivante avec le nom de serveur, le nom d’utilisateur et le mot de passe appropriés pour votre environnement.
<configuration> <configSections> <section name="configurationRedirection" /> </configSections> <configurationRedirection enabled="true" path="\\machinename\centralconfig$\" userName="ConfigUser1 or domain\user" password="ConfigPass1 or domainPassword" /> </configuration>
Enregistrez le fichier redirection.config. Vous pouvez à nouveau accéder aux sites, mais la configuration est à présent stockée dans un partage UNC.
Test de la configuration
Avec la configuration référencée à partir du serveur principal, il existe deux scénarios clés pour lesquels cette fonctionnalité a été conçue. Vous pouvez mettre à jour la configuration dans les serveurs web frontaux de deux façons :
- Vous pouvez modifier le fichier applicationHost.config directement dans le partage de fichiers. Une fois cette opération effectuée, des notifications de modification sont générées et les serveurs web récupèrent les modifications dans le fichier.
- Vous pouvez ajouter un deuxième fichier applicationHost.config dans le partage de fichiers du serveur principal et modifier le fichier redirection.config du serveur web pour qu’il pointe vers la nouvelle version du fichier. Ce principe est utile à des fins de restauration ou de déploiements intermédiaires.
Résumé
Cet article a présenté la nouvelle fonctionnalité de configuration centralisée. Cette fonctionnalité permet aux administrateurs qui ont des clusters homogènes dans un environnement de batterie de serveurs web de configurer et de déployer une configuration sur tous les serveurs de manière transparente.
Une fois la fonctionnalité configurée, qu’une modification soit apportée dans le fichier au niveau du partage UNC ou qu’un serveur soit redirigé vers un autre emplacement, les modifications sont récupérées immédiatement par le serveur web. Seules les modifications globales qui affectent plusieurs sites et applications entraînent leur recyclage. Toutefois, si des modifications sont apportées dans une étendue localisée, les sites et applications restants ne sont pas redémarrés.
Annexe 1 : Accès au fichier redirection.config par programme pour lire les valeurs
Cette étape fournit un exemple d’accès au fichier redirection.config par programme en tirant parti de la nouvelle API COM AHADMIN. Utilisez cette API pour implémenter cette API à partir du code natif ou du script et du code managé.
Pour lire les valeurs par programme
Créez un fichier texte et enregistrez-le avec l’extension .js. Le script suivant fournit un exemple de lecture de l’attribut enabled, du nom du serveur, du nom d’utilisateur et du mot de passe pour votre environnement :
try { var config = WScript.CreateObject( "Microsoft.ApplicationHost.AdminManager" ); var section = config.GetAdminSection( "configurationRedirection", "MACHINE/REDIRECTION" ); WScript.Echo( "Current redirection:" ); WScript.Echo( "enabled = " + section.Properties.Item( "enabled" ).Value ); WScript.Echo( "path = " + section.Properties.Item( "path" ).Value ); WScript.Echo( "user = " + section.Properties.Item( "userName" ).Value ); WScript.Echo( "pass = " + section.Properties.Item( "password" ).Value ); } catch(e) { WScript.Echo(e.number); WScript.Echo(e.description); }
Enregistrez le fichier redirection.js. Vous pouvez à présent exécuter ce fichier à partir d’une invite de commandes en raison de l’environnement d’exécution de scripts WSH (Windows Script Host).
Annexe 2 : Accès au fichier redirection.config par programme pour écrire les valeurs
Cette étape fournit un exemple d’accès au fichier redirection.config par programme en tirant parti de la nouvelle API COM AHADMIN. Utilisez cette API à partir du code natif ou du script et du code managé de cet objet COM.
Pour écrire les valeurs par programme
Créez un fichier texte et enregistrez-le avec l’extension .js. Le script suivant fournit un exemple d’écriture de l’attribut enabled, du nom du serveur, du nom d’utilisateur et du mot de passe pour votre environnement :
try { var config = WScript.CreateObject( "Microsoft.ApplicationHost.WritableAdminManager" ); config.CommitPath = "MACHINE/REDIRECTION"; var section = config.GetAdminSection( "configurationRedirection","MACHINE/REDIRECTION" ); section.Properties.Item( "enabled" ).Value = true; section.Properties.Item( "path" ).Value = "\\\\somemachine\\sharefile://folder/"; section.Properties.Item( "userName" ).Value = "testuser"; section.Properties.Item( "password" ).Value = "testuser"; config.CommitChanges(); } catch(e) { WScript.Echo(e.number); WScript.Echo(e.description); }
Enregistrez le fichier redirection.js.
Vous pouvez à présent exécuter ce fichier à partir d’une invite de commandes en raison de l’environnement d’exécution de scripts WSH (Windows Script Host).
Annexe 3 : Traitement des propriétés chiffrées spécifiques à l’ordinateur
Par défaut, IIS inclut deux fournisseurs principaux pour sécuriser les propriétés. Ces fournisseurs se trouvent dans la section de configuration <configProtectedData> du fichier applicationHost.config et sont définis dans l’élément <providers>.
Le fournisseur AesProvider est chargé de traiter le chiffrement et le déchiffrement des propriétés qui se trouvent dans la section system.webServer.
Le fournisseur IISWASOnlyRsaProvider est chargé de traiter le chiffrement et le déchiffrement des propriétés qui se trouvent dans la section system.applicationHost.
Ces clés se trouvent dans les conteneurs de clés iisConfigurationKey et iisWasKey et sont spécifiques de l’ordinateur. Dans un scénario de batterie de serveurs web, si le chiffrement est nécessaire, une clé d’un ordinateur (généralement celui qui a créé le fichier applicationHost.config) est exportée et introduite dans les autres ordinateurs afin que les propriétés sécurisées puissent être déchiffrées et utilisées par le serveur web.
Étapes
Ouvrez une invite de commandes. Accédez au répertoire Framework, qui se trouve par défaut à l’emplacement
%windir%\Microsoft.NET\Framework\v2.0.50727\
.Remarque
À des fins de référence, les clés d’ordinateur pour le système se trouvent dans %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys\.
Utilisez l’outil aspnet_regiis pour exporter la clé. La commande permettant de transférer la clé de configuration est indiquée ci-dessous. Le commutateur px indique que vous souhaitez exporter une paire de clés RSA. Le commutateur pri indique que vous souhaitez également inclure la clé privée et la clé publique.
Cette identification de commutateur est nécessaire pour effectuer le chiffrement et le déchiffrement ; sinon, vous pouvez uniquement chiffrer les données avec la clé exportée. Le paramètre qui suit -px est le nom du conteneur de clés à exporter. Dans ce cas, il s’agit du conteneur de clés « iisConfigurationKey ». L’autre conteneur de clés que IIS utilise est « iisWasKey ».
aspnet_regiis -px "iisConfigurationKey" "D:\iisConfigurationKey.xml" -pri
Une fois l’exportation terminée, copiez le fichier XML sur l’autre ordinateur du cluster pour y préparer son importation.
Accédez au répertoire Framework et utilisez l’outil aspnet_regiis pour importer la clé à partir du fichier XML. La commande permettant de finaliser le transfert de la clé est indiquée ci-dessous.
Le paramètre qui suit -pi est le nom du conteneur de clés à importer. Dans ce cas, il s’agit du conteneur de clés « iisConfigurationKey ». L’autre conteneur de clés que IIS utilise est « iisWasKey ».
aspnet_regiis -pi "iisConfigurationKey" "D:\iisConfigurationKey.xml"