Ho scritto molte applicazioni con cluster .NET nel corso degli anni (esclusivamente per i cluster Active / Passive) e posso condividere ciò che ho imparato.
Ho sempre scritto le mie app come servizi di Windows e le includo come risorse in cluster nell'amministratore di Windows Cluster. Quando il cluster esegue il failover da Nodo1 a Nodo2, Cluster Administrator arresta il servizio su Node1 e lo avvia su Nodo2. Questa è la parte più semplice e Windows si occupa del sollevamento pesi.
A parte - Non vi è alcun motivo tecnico per cui non è possibile scrivere un'app console e farla partire dal servizio Attività pianificate (che può anche essere impostata come risorsa cluster) o altre si intende. Quando ho iniziato a scrivere app in cluster, i requisiti spesso richiedevano che il processo venisse avviato dall'arrivo di un file e che sembrava essere più adatto a un servizio che a un'app per console. Per motivi di coerenza, abbiamo continuato a scriverli come servizi.
Il design della tua app dipenderà un po 'da quello che è esattamente il suo compito. Ma concettualmente, avrai bisogno di un modo per tenere traccia di quale unità di lavoro è in esecuzione la tua app in modo che se il cluster fallisce, la tua app sul Nodo2 sa dove recuperare l'app sul Nodo1.
Se la tua app è basata su file, significa che sta eseguendo un po 'di lavoro sui file o sui dati contenuti in uno o più file, quei file dovranno trovarsi su un'unità che non riesce o è visibile a entrambi i nodi. La tua app dovrà tenere traccia di quale file stava lavorando e potenzialmente quale record all'interno del file. Il modo in cui memorizza questo progresso dipende da te e quali risorse sono disponibili, ma l'importante è che questo progresso venga archiviato in modo tale da sopravvivere al failover (ovvero, in una tabella DB o in un file su un'unità). Memorizzare questo progresso su un'unità locale del Nodo1 non ti farà bene quando l'app si avvia su Nodo2, se il Nodo1 è morto.
Durante la progettazione / codifica, continua a chiedere a te stesso - se il cluster ha fallito in questo punto esatto del processo,
- Quali dati andrebbero persi? (e sarebbe importante?)
- Dove dovrebbe partire l'altro nodo da cui dovrebbe partire? (ed è corretto?)
Non c'è magia in realtà, solo un pensiero nei dettagli. La tua app dovrebbe fare tutto il lavoro nella transazione (DB o COM +)? Questo dipende dalla complessità del compito e dei requisiti. Puoi semplicemente tagare i record in un DB mentre la tua app li completa e far lavorare l'altro nodo su record senza tag? Certo, di nuovo dipende dai requisiti.