Share via

Garantie de la disponibilité de Team Foundation Server

  • Article

Mise à jour : novembre 2007

Vous pouvez contrôler à quel moment placer les serveurs hors connexion pour la maintenance. Toutefois, vous devez également envisager comment vous souhaitez gérer les échecs inattendus. En appliquant l'une de trois stratégies de base, vous pouvez vous assurer que les serveurs sont disponibles pour les clients pendant la maintenance ou les échecs. La stratégie que vous sélectionnez est déterminée par la durée d'arrêt que les utilisateurs peuvent tolérer et la topologie du système.

Stratégies de disponibilité

En général, les topologies sur un serveur et sur deux serveurs peuvent tolérer un temps d'arrêt raisonnable pour la maintenance de système ou pour la restauration en cas d'échec. Les systèmes complexes peuvent fournir un service ininterrompu grâce à des ressources dédiées. Les stratégies suivantes fournissent des degrés variables de disponibilité de Team Foundation Server.

  • Pratiques de sauvegarde standard pour les bases de données   Pour la couche Données, vous pouvez conserver les sauvegardes de bases de données en vue de les utiliser pour la récupération dans un délai raisonnable. Utilisez les mêmes meilleures pratiques que pour une base de données SQL Server. Cette stratégie ne requiert pas un ordinateur ou des ressources de maintenance supplémentaires. Pour plus d'informations, consultez Sauvegarde du serveur Team Foundation Server.

  • Ordinateur en état de secours semi-automatique pour les services d'application   Vous pouvez réduire le temps de récupération des services en installant et en gérant un serveur de couche Application distinct en état de secours semi-automatique. Cette stratégie nécessite un matériel supplémentaire et donc une maintenance supplémentaire pour tenir l'ordinateur à jour et prêt à l'emploi. Pour plus d'informations, consultez Gestion des serveurs de couche Application pour Team Foundation.

    Remarque :

    La couche Application ne peut pas faire partie d'une batterie de serveurs Web.

    L'ordinateur doit être tenu à jour pour correspondre à l'ordinateur principal. Vous pouvez utiliser cette liste pour prendre en compte la maintenance supplémentaire requise.

    • Améliorations du matériel.

    • Mises à jour du système d'exploitation.

    • Mises à jour de logiciels.

    • Modifications de comptes d'utilisateurs et d'autorisations.

    • Modifications de la clé de chiffrement Reporting Services.

    En plus de gérer les ordinateurs, l'administrateur Team Foundation Server doit répondre à un échec en demandant une mise à jour de la base de données du serveur DNS à l'administrateur de domaine et en utilisant l'utilitaire en ligne de commande TFSAdminUtil. Pour plus d'informations, consultez Comment : activer un serveur de couche Application avec basculement.

  • Clustering pour les bases de données   Pour fournir un service ininterrompu d'une couche Données, vous pouvez installer et gérer des serveurs dédiés dans un cluster. Vous pouvez envisager d'utiliser un cluster si votre organisation dispose déjà des ressources pour installer et gérer un cluster. Cette stratégie augmente considérablement le coût en ressources et en maintenance, car les configurations matérielles et logicielles requises pour le cluster sont très précises. Par exemple, le matériel doit correspondre de manière identique et appartenir à la liste du matériel approuvé. Pour plus d'informations, consultez les rubriques suivantes sur le site Web Microsoft : « Comment : créer un cluster de basculement SQL Server 2005 » pour SQL Server 2005 et « Comment : créer un cluster de basculement SQL Server (Programme d'installation) » pour SQL Server 2008.

  • **Mise en miroir des bases de données   **La mise en miroir du serveur de couche Données Team Foundation comporte plusieurs avantages. Elle permet de placer le serveur de couche Données Team Foundation principal hors connexion pour les mises à jour, la maintenance ou la réparation avec un impact minime sur les utilisateurs Team Foundation Server. Elle active également un mécanisme de récupération rapide si le serveur de couche Données Team Foundation principal devient indisponible. Vous pouvez envisager un serveur de mise en miroir pour le serveur de couche Données Team Foundation si votre organisation dispose des ressources pour installer et gérer un deuxième serveur de couche Données Team Foundation.

Dans cette section

Voir aussi

Concepts

Activation d'un serveur de couche Application avec basculement

Clustering du serveur de couche Données

Sauvegarde du serveur Team Foundation Server

Autres ressources

Gestion des données

Gestion des sauvegardes de Team Foundation Server