Sono abbastanza familiare con il clustering di failover di Windows. È una grossa fetta di lavoro e budget di amministrazione (se effettivamente tollerante ai guasti, ovvero non utilizza un singolo file server SMB3 per l'archiviazione condivisa). È frequentemente settimanale o mensile fallito per nessun motivo visibile. Quando fallisce, il servizio viene perso per qualche istante mentre il nuovo server attivo si occupa delle risorse (indirizzo IP, disco, ecc.). La manutenzione in corso è irritante perché alcune impostazioni devono essere configurate su ciascuna macchina. Questo può richiedere il fallimento del server e la ripetizione delle modifiche di configurazione. Alcune cose supportano la configurazione condivisa, evitando questo. (ad esempio IIS, tuttavia IIS non è clusterabile in modo nativo e richiede la configurazione di uno script per migrarlo tra i server)
Tutto questo per dire, assicurati che la tua azienda sia a conoscenza dei costi prima di decidere di seguire questa strada.
Un'opzione leggermente meno coinvolta è Bilanciamento carico di rete ( NLB). Puoi usarlo come attivo / attivo. Gestirà i guasti ed eviterà i server guasti. Non richiede archiviazione condivisa come fa il clustering di failover. Ricordare che è progettato per il bilanciamento del carico, non per la disponibilità. Puoi impostarlo per un tipo di scenario attivo / passivo assegnando a un server la piena priorità, ma split-brain potrebbe essere possibile lì. Potrebbero essere necessari anche alcuni aggiustamenti del livello di rete, a seconda di come si imposta NLB.
Esiste anche l'approccio DNS Round Robin in cui essenzialmente si imposta un record DNS che punta a più indirizzi IP . Ogni indirizzo IP appartenente a un diverso server con il servizio installato. Il server DNS restituisce gli indirizzi IP in ordine di rotazione. Ma la fattibilità di questo dipende strongmente dall'implementazione del cliente. Spesso il sistema del client ne sceglie uno e memorizza il risultato in cache. Questo può portare a tempi di inattività percepiti perché il server in particolare che il client ha memorizzato nella cache potrebbe essere quello inattivo.
In ogni caso, il tuo servizio deve davvero essere configurato per essere apolidi. In caso contrario, la richiesta successiva potrebbe essere gestita da un server che non è a conoscenza della sessione precedente dell'utente su un server diverso. (Lo stato potrebbe essere centralizzato, ma di nuovo avrebbe dovuto essere nel cluster quindi non era un singolo punto di errore. Noterete che il clustering è un buco nero che assorbe anche le preoccupazioni circostanti. A proposito ...)
Nessuno di questi indirizzi risolve altri singoli punti di errore, come rete, database, driver hardware (driver sì ... alcune persone arrivano fino a ottenere hardware diverso da produttori diversi per garantire che un errore del driver o dell'hardware non abbia un impatto tutti i sistemi).
Potresti anche approfittare di un'offerta cloud per la ridondanza, come Azure nel mondo MS. C'è troppo da elencare su questo argomento, ma questi servizi tendono a offrire una serie di funzionalità ad alta disponibilità, inclusi i livelli di rete, di archiviazione e di database.
Sono sicuro che questo non è un elenco completo delle tue opzioni. E come sempre nessuno di loro è strettamente "migliore" ... ci sono dei compromessi.
Aggiunto
Ho anche pensato ai dispositivi di bilanciamento del carico hardware. È un dispositivo di rete come un router o uno switch con server collegati. Ma l'idea di base è che ascolta un IP e le richieste a quell'IP vengono inoltrate ai server collegati in modo alternato. L'utilizzo di un solo bilanciamento del carico è un singolo punto di errore, poiché è un dispositivo che può interrompere l'accesso in caso di errore. Per eseguire il bilanciamento del carico ridondante, sono necessari percorsi di rete ridondanti e un protocollo di routing in grado di gestirlo.