Windows Services - Scenari alta disponibilità e l'approccio di progettazione

Question

dire Let Ho un servizio di Windows standalone esecuzione in una macchina di Windows Server. Come assicurarsi che sia altamente disponibili?

1). Quali sono tutte le linee guida a livello di progettazione che si possono proporre?

2). Come rendere altamente disponibile come primario / secondario, ad es., Le soluzioni di clustering attualmente disponibili sul mercato

3). Come affrontare i problemi trasversali in caso di qualsiasi fail-over scenari

Se qualsiasi altro si può pensare di si prega di inserirlo qui ..

Nota: La questione è legata solo alle finestre e servizi di Windows, per favore cerca di obbedire a questa regola:)

Answer 1

Per mantenere il servizio almeno in esecuzione si può organizzare per il Service Manager di Windows per automaticamente riavviare il servizio se si blocca (si veda la scheda Ripristino sulle proprietà del servizio). Maggiori dettagli sono disponibili qui, tra cui uno script batch per impostare questi proprietà - riavviare un servizio Windows se si blocca

L'alta disponibilità non è solo mantenere il servizio fino dall'esterno - il servizio ha bisogno di essere costruito con alta availabiity in mente (ad esempio l'uso buona programmazione pratiche in tutto, Datastructures appropriate, coppie risorsa Aquire e rilascio), e la tutto lo stress-test per garantire che rimarrà sotto carichi previsti.

Per i comandi idempotenti, fallimenti tollerare intermittenti (come le risorse bloccate) può essere ottenuto mediante ri-invocando il comando di un certo numero di volte. In questo modo il servizio per proteggere il cliente dal fallimento (fino a un certo punto.) Il cliente deve anche essere codificato per anticipare il fallimento. Il cliente può gestire il fallimento di servizio in diversi modi - la registrazione, chiedere conferma all'utente, riprovare X volte, la registrazione di un errore fatale e l'uscita sono tutti i possibili gestori - che uno è giusto per te dipende da vostre esigenze. Se il servizio ha "stato di conversazione", quando il servizio non riesce difficile (cioè processo viene riavviato), il cliente deve essere consapevole e gestire THS situazione, come di solito significa stato di conversazione in corso è stato perso.

Una singola macchina sta per essere vulnerabile di un guasto hardware, quindi se avete intenzione di utilizzare una sola macchina, quindi assicurarsi che ha componenti ridondanti. HDD sono particolarmente soggetti a guasti, in modo da avere almeno un'unità disco speculare, o un array RAID. PSU sono il successivo punto debole, così PSU ridondante è anche utile, come è un gruppo di continuità.

Per quanto riguarda il clustering, di Windows supporta il servizio di clustering, e gestisce servizi utilizzando un nome di rete, piuttosto che nomi singolo computer. Questo permette al cliente di connettersi a qualsiasi computer che esegue il servizio e non un nome di hard-coded. Ma a meno di prendere misure aggiuntive, questo è Risorsa failover - che dirigono le richieste da un'istanza del servizio ad un altro. Stato converstaion di solito è perso. Se i servizi sono iscritto a un database, allora che dovrebbe anche essere raggruppati per garantire anche reliabiity e garantire le modifiche sono a disposizione per l'intero cluster, e non solo il nodo locale.

Questo è in realtà solo la punta di un iceberg, ma spero ti dà le idee per iniziare a ulteriori ricerche.

Microsoft Clustering servizi (MSCS)

Answer 2

Se abbattere i problemi che si sta cercando di risolvere, penso che probabilmente venire con alcune risposte da soli. Come Justin menzionato nel commento, non c'è una risposta. E 'del tutto dipende da ciò che il vostro servizio fa e come i clienti usarlo. Inoltre non si specifica alcun dettaglio circa l'interattività client-server. HTTP? TCP? UDP? Altro?

Qui ci sono alcune cose da pensare per iniziare.

1) Cosa fare se il servizio o il server va giù?

• Che ne dite di eseguire più di un'istanza del vostro servizio su server separati?

2) Ok, ma ora come fanno i clienti sanno circa i servizi multipli?

• È possibile codificare la lista in ciascun client (non raccomandato)
• È possibile utilizzare DNS round robin per le richieste di rimbalzo attraverso tutti loro.
• È possibile utilizzare un dispositivo di bilanciamento del carico.
• È possibile avere un servizio separato che conosce tutti gli altri servizi e può indirizzare i clienti ai servizi disponibili.

3) Che cosa se un servizio va giù?

• Fare le applicazioni client sanno cosa fare se il servizio al quale sono collegati va giù? In caso contrario, quindi hanno bisogno di essere aggiornato per gestire questa situazione.

Questo dovrebbe iniziare con l'idea di base di come iniziare ad alta disponibilità. Se si forniscono dettagli specifici circa la vostra architettura, probabilmente otterrete una risposta molto migliore.

Answer 3

Se il servizio non espone alcuna interfaccia per la connettività del client è possibile:

• Broadcast o esporre un messaggio di “Io sono vivo”, o segnalare un database / registro / tcp / qualunque cosa che sei vivo

• Avere un secondo servizio (monitor) che verifica la presenza di questi “Io sono vivo” segnali e cercare di riavviare il servizio nel caso in cui esso è giù

Ma se si dispone di un client che si connette a questo servizio attraverso NamedPipes / tcp / etc, il cliente avrebbe dovuto controllare l'indirizzo della macchina con il servizio in esecuzione in un database, o hanno qualcosa più elaborato come un interruttore intelligente al traffico di reindirizzamento .