Les instances de Devolutions Server peuvent être installées à travers différentes topologies. Les exemples suivants illustrent différentes topologies pour divers usages.
Topologie serveur unique
Le Devolutions Server et le serveur SQL peuvent être installés sur la même machine pour une petite équipe allant jusqu'à 20 utilisateurs. Avoir Devolutions Server et SQL Server sur la même machine pourrait entraîner certains problèmes de performance si vous essayez de servir plus de 20 utilisateurs.
Topologie de base recommandée
Une topologie de base recommandée se compose de deux serveurs : un pour le Devolutions Server et un pour la base de données SQL. Cela permet de faire traiter toutes les requêtes par le serveur SQL et de réduire l'impact sur les performances du serveur d'applications.
Topologie à haute disponibilité
Couche base de données uniquement
Pour une haute disponibilité de la base de données, le mirroring de base de données peut être utilisé, ce qui réplique les données vers un serveur partenaire. Le serveur de secours est prêt à tout moment lorsque le serveur principal devient indisponible. Cela assure que le Devolutions Server continue d'accéder à la source de données et reste transparent pour les utilisateurs de Remote Desktop Manager.
Topologie d'équilibrage de charge
Pour assurer une performance maximale du Devolutions Server, il peut être déployé en tant que topologie de Devolutions Server avec équilibrage de charge, comme illustré dans l'image ci-dessous. Il peut s'agir soit d'un système d'équilibrage de charge physique ou logiciel.
Basculement manuel d'instance de Devolutions Server
Pour les clients qui ne souhaitent pas acheter un équilibreur de charge ou cherchent une topologie plus simplifiée pour leur système, vous pouvez simplement utiliser deux instances de Devolutions Server sur deux serveurs Web différents et les diriger vers la même base de données SQL Server. En enregistrant les deux instances comme sources de données distinctes dans les applications client, les utilisateurs peuvent basculer manuellement entre les serveurs au cas où l'un d'eux deviendrait non réactif.