Qualche tempo fa ho scritto circa l'idea di trattare infrastrutture di rete (e tutte le altre infrastrutture) come codice , e utilizzando gli stessi sviluppatori di applicazioni di processi stanno usando per scrivere, testare e implementare il codice per progettare e realizzare reti.
Questo approccio funziona bene chiaramente se è possibile virtualizzare (e clone all'infinito) tutto. Siamo in grado di virtualizzare elettrodomestici o anche router, ma le attrezzature installate e infrastrutture fisiche ad alta velocità rimangono alquanto resistente a tale idea. Abbiamo bisogno di un paradigma diverso, e la migliore analogia che potevo venire con è un database.
Immaginate un'organizzazione che ha bisogno di un grande database transazionale per eseguire la propria attività, e richiede agli operatori di prima linea per modificare i dati in quel database con istruzioni SQL (INSERT, UPDATE, DELETE). Non ho mai sentito di nessuno essere anche solo lontanamente quella stupida - ma è così che la maggior parte di noi gestiscono nostre reti. Il tempo di prendere un'altra lezione dal mondo, lo sviluppo di applicazioni.
E 'ovvio che si debba interagire con un database di produzione solo attraverso operazioni ben definite ed accuratamente testati (se li chiami transazioni , programmi applicativi o script web è irrilevante). CLI (SQL) Accesso diretto al database dovrebbe essere vietato o limitato al minimo assoluto.
Allo stesso modo, dobbiamo modificare i nostri dispositivi di rete con operazioni ben definite (esempio: CREATE VLAN o RIMUOVERE VLAN ). Tali operazioni (loro script, Playbook o ricette chiamare se lo si desidera) devono essere trattati come qualsiasi codice dell'applicazione, e testati in un ambiente di laboratorio prima di poter toccare la rete di produzione.
E ora per la consueta serie di obiezioni:
Ma non mi fido script . Fantastico. Ora dimmi: è meglio fare affidamento su qualcosa che è testato e ripetibile, o fare modifiche di configurazione al volo sperando per il meglio?
Come faccio a sapere che funzionerà? Benvenuti nel mondo dello sviluppo software. Scrivere il codice, includere test di unità e di integrazione, testare tutto, distribuire in un ambiente pilota, e infine in produzione. Schiuma, sciacquare, ripetere.
Ma potrebbe rovinare le mie configurazioni . E pensi che nessuno mai incasinato loro database? Abbiamo backup per una buona ragione - e la maggior parte delle apparecchiature di rete dispone di alcuni meccanismi di versioning configurazione e rollback.
Ma potrebbe andare in crash il mio interruttore . Potrebbe. Sistemi di database hanno i loro bug, e io sono positivo sono stati in grado di mandare in crash alcuni database con dati non validi o richieste strane a pochi decenni fa ... ma indovinate un po ': se non cominciamo a urlare ai fornitori, e votano con i nostri portafogli, non accadrà nulla cambiare.
Che dire di finestre di manutenzione? Dobbiamo usare le finestre di manutenzione nelle reti attuali, perché non possiamo fidarci del processo di configurazione manuale. Quando è stata l'ultima volta che si potrebbe fare la transazione di e-banking solo alle 2 del mattino in una mattina di Domenica? Una volta che tutti cominciano confidando le operazioni di configurazione della rete, sarete in grado di utilizzarli in qualsiasi momento.
Avete incontrato altri obiezioni? Scrivi un commento!
Infine, si potrebbe decidere che la rete non è abbastanza grande da giustificare una soluzione di automazione di rete (o che non hanno la manodopera per lavorare su di esso). La prossima cosa migliore che potrebbe fare è disaccoppiamento : spostare le parti dinamiche della vostra infrastruttura di rete nel mondo virtuale in cui è possibile trattare sia come codice , e mantenere la parte fisica della vostra infrastruttura di rete statica possibile.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.