Applicazioni .NET personalizzate e clustering

3

Quindi, per un ambiente in cluster, come funzionerebbe con le tue app?

E le tue app .NET personalizzate? Ci sarebbe un modo speciale per svilupparli? So che puoi dire di creare una semplice app Hello world e un cluster, ma non sarebbe qualcosa che potresti vedere nell'interfaccia dell'interfaccia utente o altro, quindi dovrebbero effettivamente essere sviluppati come servizio Windows forse o anche come console standard app che funziona e non aspetta l'input dell'utente, ma non visualizzerai alcun output da esso (a meno che tu non reindirizzi l'output in qualche altro posto)

Quello che sto ottenendo qui è ... per coloro che hanno esperienza o sviluppato un'applicazione cluster in .NET, come l'hai fatto e quali sono le cose di cui essere a conoscenza?

Ad esempio, abbiamo il servizio cloud, fondamentalmente basato sul clustering, se c'è un'interruzione, si verifica un altro nodo e il servizio riprende normalmente ma non vediamo gran parte del tempo di inattività.

    
posta Ahmed ilyas 22.11.2012 - 00:17
fonte

1 risposta

5

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.

    
risposta data 22.11.2012 - 02:09
fonte

Leggi altre domande sui tag