Verifica la coerenza dei dati tra più server

Question

Verifica la coerenza dei dati tra più server

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

3

Attualmente sto lavorando su un'architettura che abbia la seguente struttura:

                            (central server)
                           /        |       \
            (local server)    (local server)  (local server)
             /       |          |        |        |       \
          (PC)  ... (PC)      (PC)  ... (PC)     (PC) ... (PC)

C'è un server centrale che comunica con più server locali (oltre 100) e ogni server locale parla con più PC.

Il server centrale riceve una grande quantità di dati ogni giorno più volte al giorno e dopo una certa manipolazione sincronizza i dati sul server locale, dopo che i server locali hanno diffuso i dati sui loro PC.

Tutte queste macchine comunicano tra loro tramite richieste HTTP, ogni scambio di dati avviene con un POST HTTP di un file JSON.

È fondamentale che tutte le informazioni ricevute dal server centrale siano correttamente ricevute e archiviate sul server locale prima e sul PC dopo.

Ora devo testare se la sincronizzazione funziona correttamente e voglio automatizzare i test in modo che uno script venga eseguito continuamente sul server centrale e controllare se i dati appena arrivati sono sincronizzati con le macchine sottostanti.

Quindi la mia prima domanda è: ha senso testare ogni volta TUTTI i dati ricevuti dal server centrale? (Stiamo parlando di decine di migliaia di voci di database per ogni singolo server locale, quindi centinaia di migliaia in totale.)

Anche per i PC le prestazioni sono un grosso problema, non posso rubare troppe risorse CPU o RAM da loro.

Se la risposta è no, ha senso testare solo un sottoinsieme dei dati presi casualmente?

Se no, qual è il modo migliore per agire?

UPDATE I dati vengono passati al server locale in questo modo: Un servizio sul server centrale riceve i dati e li archivia su un database, viene chiamato un altro servizio, questo preleva i dati dal database in formato COPY e colloca COPY in un file. Il file viene inviato al server locale tramite una richiesta HTTP POST.

server-side web-services

posta k4ppa 30.01.2017 - 18:04

fonte

4 risposte

Leggi altre domande sui tag server-side web-services

Se ho accesso diretto al commit, c'è qualche ragione per creare una richiesta di pull per una piccola modifica che non richiede feedback? Introduzione delle differenze comportamentali in un modello di dominio complesso

score 1 · Answer 1

Hai citato parecchio test, ma non menzionare il meccanismo utilizzato per attivare gli aggiornamenti o trasmettere i dati ai server locali. Temo che possa essere cresciuto in casa, il che renderebbe l'affidabilità più sospetta e test più essenziali.

Per questo tipo di replica fan-out, master-slave, potrebbe essere meglio investire in un meccanismo di trasferimento affidabile che ti dia molta confidenza ("garanzie") su ciò che è presente sui server locali (o PC) il server centrale. Rsync, Git o Mercurial possono essere utilizzati in modo molto efficiente per effettuare il trasferimento; tutti forniscono tecniche di integrità dei dati forti. Quando vedi commit 4740488633dd83c175788aa61824205513b825cf su un server locale o PC, puoi essere certo che è identico al commit con lo stesso id (hash) sul server.

Oppure, se vuoi solo verificare che un file (o pacchetto o altra unità di informazioni) sia lo stesso su un server locale o PC come è sul server centrale, prendi un hash strong (o "somma di controllo" ") di esso, ad esempio SHA-1 e confronta con l'hash / checksum calcolato" a monte ". Questa è una tecnica di hash che è stata spesso utilizzata dai sistemi di controllo delle versioni. Puoi avere una sicurezza estremamente elevata che se hash(a) == hash(b) , that a e b sono completamente identici. Se sei particolarmente paranoico riguardo alla possibilità di differenza, ci sono anche hash di contenuto più forti e più lunghi che puoi utilizzare (ad es. SHA- 2 famiglia; IIRC Mercurial si sta evolvendo verso l'istanza SHA-256 bit).

score 1 · Answer 2

Dipende

Lo scopo del test è ridurre il rischio.

Il modo in cui il test è progettato dipende dal rischio che stai tentando di mitigare.

Alcune opzioni

Se ritieni che vi sia il rischio che gli aggiornamenti possano fallire completamente, dovrebbe essere sufficiente eseguire un controllo a campione dei dati, poiché sarebbe un modo efficace per rilevare un errore.
Se ritieni che ci sia qualche rischio che l'aggiornamento possa avere successo, ma potrebbe contenere dati corrotti, allora è necessario un controllo completo dell'intero set di dati.
Se hai solo bisogno di un controllo generale end-to-end, il miglior tipo di test sarebbe simulare un utente (magari usando un utente di test designato per questo scopo) ed eseguire le attività più comuni che fallirebbero se i dati non fossero aggiornati.

score 1 · Answer 3

Il mio pensiero iniziale è di usare ampiamente l'hash, mi piace particolarmente MD5. Ha una velocità di collisione estremamente bassa e fornisce un semplice meccanismo per verificare l'integrità del trasferimento dei dati.

Non riesco a commentare re: uso di risorse del PC poiché la domanda non entra in dettagli sufficienti sui tipi e la frequenza delle operazioni eseguite dalla CPU del PC

score 0 · Answer 4

Per prima cosa considero Local Server e PC separati.
Non è compito del server principale distribuire ai PC.

Quanto spesso si prova è separato dalla procedura di test.

Avresti bisogno e ID per la spinta.
Sembra che dovresti avere i seguenti test:

Dai record di convalida centrali ricevuti (come in PK) su un server locale per un ID push
Dai record di convalida centrali ricevuti (come in PK) su un server locale e tutti i dati sono coerenti per un ID push
Da centrale convalida una sincronizzazione totale con locale
Non richiesto ma da locale convalida una sincronizzazione totale con centrale

Per il PC è una storia diversa, come dubito che tu spinga. Non chiaro. Potresti avere un account privilegiato che può interrogare sia centrale che locale e confrontare durante le ore di pausa.