Osservando il progresso di un sistema distribuito

Question

Osservando il progresso di un sistema distribuito

#1 da (1 voti)

1

Per un sistema distribuito, è necessario osservare i progressi di piccole applicazioni su computer distribuiti (runtime 5 - 20 minuti).

C'è una web fronted, che adesso mostra solo un elenco di quelli più piccoli applicazioni (chiamate job), con lo stato di ciascuna di loro, come preparing , running , finished

Quindi in web-ui, un amministratore può vedere:

nome
Stato
ora di inizio
chiama parametri

da qualsiasi computer nella rete, probabilmente per l'intero sistema.

Ciascuna proprietà è memorizzata nel database, quindi ogni lead di cambiamento dello stato a una chiamata per scrivere nel database. Potrebbero esserci migliaia di quei posti di lavoro alla volta.

Descrizione del sistema distribuito:

Componenti centrali, serviti solo in una posizione:

Server di database (contenente i risultati dei lavori per eseguire statistiche, avere una panoramica dei lavori eseguiti negli ultimi tre mesi, ecc.)
Server delle applicazioni (glassfish, java, esegue il software del server centrale)

Componenti distribuiti, ogni sito ne ha almeno uno, collegato tramite l'area Internet / WAN: (probabilmente circa 20 siti, ognuno ha 1..4 controller di lavoro, ogni controller di lavoro esegue circa 20 lavori in parallelo)

Componente controller di lavoro (windows, c #, wcf, avvia e osserva piccoli lavori)
Piccole applicazioni che eseguono attività, avviate da Job-Controller (i lavori)

Quindi, per una stima vaga:

20 sites * 4 Job-controllers * 20 jobs = 1600 jobs in parallel

each of which runs from 0 to 100 percent in about 5 minutes on average,
resulting in a progress update each 3 seconds.

giving 533 progress updates per second (over the internet)

Ora il cliente vuole vedere qualcosa come una barra di avanzamento per ognuno di questi lavori.

In un primo momento, ho pensato che questo potrebbe portare ad un traffico di rete elevato e ad una grande quantità di traffico sul server del database.

Non penso che scrivere progressi come 1%, 2%, 3% nel database sia una buona idea. Il runtime di quei lavori non è molto facile da stimare bene (quindi è abbastanza vicino ad un risultato reale), ma ogni lavoro può dire molto bene qual è il suo progresso.

Quale sarebbe un buon approccio architettonico per osservare il progresso di possibilmente migliaia di quei mini-lavori? (Si noti che viene fornita un'infrastruttura mista. Esiste il vincolo che il sistema sarà costruito su così.: Glassfish centrale + java e per sito Windows + WCF + C #)

In questo momento penso che ogni controller di lavoro possa aggiornare lo stato di avanzamento di tutti i lavori controllati ogni 10 secondi contemporaneamente. Sarebbe un approccio accettabile?

architecture design-patterns enterprise-architecture distributed-computing

posta Mare Infinitus 23.07.2014 - 21:56

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns enterprise-architecture distributed-computing

Quando utilizzare lo schema della lavagna rispetto alla chiamata diretta Prossimi passaggi per lo sviluppo di un nuovo prodotto [duplicato]

score 1 · Accepted Answer

Questo sembra un cruscotto. Là fuori c'è una serie di piattaforme di cruscotto che possono essere configurate come sorgenti di dati, intervalli di polling, ecc.

Consentitemi di suggerire un progetto approssimativo, sfidando alcune delle vostre ipotesi.

Assunzione: dichiari che esiste un database centrale che contiene i risultati di ciascun lavoro. Non vedo il requisito che tenga lo stato di ogni lavoro mentre è in esecuzione.

Presupposto: il progresso dettagliato, al livello%, non è richiesto. È sufficiente mostrare i progressi (o la mancanza di progressi, con una bandiera rossa).

Assunzione: 1400 lavori, aggiornamento a intervalli di 15 secondi ciascuno (ovvero all'incirca il 5% di incrementi), 5600 aggiornamenti al minuto o 93 aggiornamenti al secondo.

Presupposto: il componente dell'interfaccia utente può estrapolare la velocità di avanzamento dagli aggiornamenti recenti e fornire un livellamento delle animazioni del dashboard.

Per la tua architettura, considera l'utilizzo di un framework di messaggistica distribuito come Akka.NET. Ogni lavoro riporta le sue informazioni e progredisce verso un attore sul proprio computer host. Le macchine host (presumo che ci sia più di un computer host per sito) segnalano lo stato di avanzamento a un computer del sito, che inoltra il report del lavoro al server centrale. Potresti decidere di aggiornare il database con lo stato di avanzamento o meno, come ritieni opportuno.

Sul server centrale, il server Web raccoglie e riepiloga le informazioni sul lavoro. Per ogni lavoro, sono disponibili l'identificazione del lavoro, l'ora di inizio e i parametri, l'avanzamento più recente segnalato e la velocità di avanzamento, insieme al timestamp. Questo riepilogo viene inoltrato alla pagina Web stessa (tramite query AJAX), in cui l'interfaccia utente prende ciascun lavoro e visualizza la barra di avanzamento e la aggiorna periodicamente in base all'avanzamento e alla velocità di avanzamento.

Questo approccio generale alla progettazione di pagine Web consente di limitare gli aggiornamenti di avanzamento mentre si sintonizza l'applicazione, consentendo forse alla pagina Web di concentrarsi su uno o pochi siti alla volta per aggiornamenti frequenti. Inoltre scarica gli aggiornamenti della barra di avanzamento sul client dove è possibile visualizzare qualsiasi tipo di animazione.

Allo stesso modo, l'uso del framework Akka.NET fornisce comunicazioni e aggiornamenti reattivi, distribuiti e reattivi ai guasti. Ti permetterà di identificare i siti o gli host che diventano irraggiungibili, che dovrebbero probabilmente essere visualizzati sul dashboard.