L'option serveur de secours est simple à implémenter, réduit la durée d'immobilisation à presque zéro, mais n'améliore pas les performances du serveur. Dans cette configuration, un serveur actif unique (serveur principal) est connecté à une base de données et à un système de fichiers distant. Un serveur secondaire est également configuré pour la connexion à la même base de données et au même système de fichiers, mais il n'est pas démarré. Si le noeud actif échoue, le serveur secondaire es démarré et le trafic réseau est acheminé vers le serveur secondaire. Cet événement est appelé reprise en ligne. IBM® UrbanCode Deploy ne possède pas de processus automatique de reprise en ligne mais il peut être automatisé.

Vous pouvez convertir un système de serveur de secours en système en cluster en plaçant des fichiers partagés dans un stockage réseau et en connectant les serveurs à des relais réseau. Voir Configuration des serveurs en cluster pour la haute disponibilité.
La fonction de haute disponibilité accroît l'évolutivité et la disponibilité en distribuant le traitement dans un cluster de serveurs. Chaque serveur est un noeud indépendant qui contribue à un traitement commun. L'objectif est d'être aussi tolérant aux erreurs que possible tout en ne nécessitant que peu ou pas d'intervention manuelle.
Les serveurs IBM UrbanCode Deploy créent un maillage JMS (via ActiveMQ) ; tous les serveurs ont connaissance les uns des autres. Tous les services sont actifs sur chaque serveur.

Pour des instructions d'installation, voir Configuration des serveurs en cluster pour la haute disponibilité.