Quale metodologia di progettazione della gestione delle versioni da utilizzare nei nodi del sistema dipendente?

0

Questa è la mia prima domanda quindi, per favore, indica se la mia domanda è troppo vaga e non comprensibile. La mia domanda è più legata al Design di alto livello. Abbiamo un sistema (in particolare uno chassis ATCA) configurato in una topologia a stella, con Master Node (MN) e altri nodi sub-ordinate (SN) . Tutti i nodi sono connessi via Ethernet e devono essere eseguiti su SO Linux con altre applicazioni proprietarie.

Devo creare un Framework design di recupero in modo che qualsiasi entità software, sia che si tratti di Linux, Ramdisk o di un'applicazione, può tornare alle versioni precedenti se si verifica qualcosa di brutto.

Quindi penso di mantenere una Matrice di versione di stato su MN, in cui ogni stato (1,2 ... n) rappresenta Good Kernel, Ramdisk e versioni di applicazione per ogni SN. Può accadere che una versione SN possa dipendere dalla versione di altri SN. Si prega di vedere lo schema seguente: -

Quindi sono in dilemma se utilizzare la metodologia di gestione dei pacchetti utilizzata dalle distribuzioni di Debian (come Ubuntu) o dalla metodologia del repository GIT; per fare un Rollback alle precedenti versioni valide su uno SN o su tutti i SN dipendenti. Il metodo dovrebbe anche essere più semplice per l'aggiornamento di SN insieme ai MN.

Alcune delle funzionalità che sto cercando di ottenere: -

1) L'upgrade di una singola entità software è ottenibile senza ostacolare gli altri.

2) I controlli di dipendenza devono essere eseguiti prima di applicare il rollback o l'aggiornamento su ciascuno dei SN

3) Il prompt utente deve essere fornito nel caso in cui la dipendenza non funzioni. Se l'utente continua a eseguire il rollback, tutti gli SN dovrebbero ricevere notifiche per il rollback delle proprie versioni (se necessario).

4) I file binari dovrebbero essere distribuiti su SN di conseguenza in modo che il processo di recupero sia più veloce; preferisco sempre ogni volta da MN.

5) Rilascio di patch dallo sviluppatore per correzioni di errori, l'ottimizzazione delle funzionalità può essere applicata al sistema in esecuzione.

6) Ogni versione può essere facilmente rintracciabile e distinguibile.

Grazie

    
posta actiononmail 06.05.2014 - 07:09
fonte

1 risposta

1

Imo, vuoi Puppet o uno strumento simile di gestione della configurazione per soddisfare le domande 1, 3 e 5 Puoi anche gestire puppet config in un git repo per soddisfare req 6. Mi sembra anche che usare i pacchetti Debian sarebbe meglio di git repos nel tuo caso per i seguenti motivi:

  • i controlli di dipendenza sono integrati in dpkg (req 2)
  • apt-get cache binari localmente (req 4)

Naturalmente, tutti questi possono essere reimplementati senza riutilizzare uno strumento di gestione della configurazione e un gestore di pacchetti, ma questo sembra più lavoro. Infine, ricorda che nessuno strumento di configurazione è l'ideale e che i seguenti problemi possono ancora presentarsi:

  • un aggiornamento di alcune entità software interrompe lo strumento di configurazione stesso
  • una nuova versione dell'entità software cambia la configurazione in un modo incompatibile all'indietro, ad es. aggiornando uno schema di database e un rollback diventa problematico
  • i gestori di pacchetti comuni come APT possono produrre comportamenti sorprendenti ( esempio )

Quindi, è ancora importante definire correttamente le modifiche (ambito, finestra temporale, ecc.) e distribuirle gradualmente.

    
risposta data 06.05.2014 - 09:04
fonte

Leggi altre domande sui tag