{"id":35972,"date":"2019-10-31T22:08:54","date_gmt":"2019-10-31T19:08:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\/"},"modified":"2019-10-31T22:08:54","modified_gmt":"2019-10-31T19:08:54","slug":"avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","title":{"rendered":"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il SDSM \u00e8 finito, ma il desiderio incontrollato di scrivere \u00e8 rimasto. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/0\/kdpv.jpg\"><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/2da9a566e92a782cf1205a6da716d4c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Per molti anni, il nostro fratello ha sofferto nell'eseguire lavori di routine, incrociando le dita prima del commit e perdendo il sonno a causa dei rollback notturni.<br \/>\nMa le oscurit\u00e0 avranno una fine.<\/p>\n<p>Con questo articolo inizio una serie su come <i>a me<\/i> sembra l'automazione. <br \/>\nDurante il percorso, analizzeremo le fasi dell'automazione, la gestione delle variabili, la formalizzazione del design, con RestAPI, NETCONF, YANG, YDK e programmeremo molto. <br \/>\n<i>Per me<\/i> significa che a) non \u00e8 una verit\u00e0 oggettiva, b) non \u00e8 necessariamente il miglior approccio incondizionale, c) il mio punto di vista potrebbe cambiare anche nel corso della transizione dal primo all'ultimo articolo \u2014 onestamente, dalla fase di bozza alla pubblicazione ho riscritto tutto completamente due volte. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Contenuto<\/h1>\n<p><\/p>\n<ol>\n<li> <b>Obiettivi<\/b>\n<ol>\n<li>La rete \u00e8 come un organismo unico<\/li>\n<li>Testing della configurazione<\/li>\n<li>Versionamento<\/li>\n<li>Monitoraggio e auto-recupero dei servizi<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Strumenti<\/b>\n<ol>\n<li>Sistema di inventario<\/li>\n<li>Sistema di gestione dello spazio IP<\/li>\n<li>Sistema di descrizione dei servizi di rete<\/li>\n<li>Meccanismo di inizializzazione dei dispositivi<\/li>\n<li>Modello di configurazione agnostico rispetto al fornitore<\/li>\n<li>Driver specifico per interfaccia del fornitore<\/li>\n<li>Meccanismo di consegna della configurazione al dispositivo<\/li>\n<li>CI\/CD<\/li>\n<li>Meccanismo di backup e rilevamento delle anomalie<\/li>\n<li>Sistema di monitoraggio<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Conclusione<\/b>\n <\/li>\n<\/ol>\n<p>\nCercher\u00f2 di mantenere l'ADSM in un formato leggermente diverso dal SDSM. Continueranno a essere pubblicati articoli numerati dettagliati, e tra di essi pubblicher\u00f2 piccole note dall'esperienza quotidiana. Cercher\u00f2 di combattere qui con il perfezionismo e di non rifinire ciascuno di essi. <\/p>\n<blockquote><p> \u00c8 divertente dover intraprendere lo stesso percorso per la seconda volta.<\/p>\n<p> All'inizio ho dovuto scrivere io stesso articoli sulle reti perch\u00e9 non ce n'erano in Runet.<\/p>\n<p> Ora non sono riuscito a trovare un documento esaustivo che sistematizzasse gli approcci all'automazione e analizzasse con esempi pratici le tecnologie sopracitate.<\/p>\n<p> Potrei sbagliarmi, quindi inviatemi link a risorse utili. Tuttavia, ci\u00f2 non cambier\u00e0 la mia determinazione a scrivere, perch\u00e9 l'obiettivo principale \u00e8 comunque imparare qualcosa di nuovo, mentre facilitare la vita agli altri \u00e8 un piacevole bonus che soddisfa il gene della condivisione delle conoscenze.\n<\/p><\/blockquote>\n<p>Proveremo a prendere un data center LAN DC di dimensioni medie e lavoreremo su tutto lo schema di automazione. <br \/>\nFar\u00f2 alcune cose praticamente per la prima volta insieme a voi. <\/p>\n<blockquote><p> Nelle idee e negli strumenti descritti qui non sar\u00f2 originale. Dmitrij Figol ha un ottimo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=MLeiShwb7Qo&amp;list=PLSwGHYY8t8JiGI9powOXDHTAXDSs7FZqt\">canale con streaming su questo tema<\/a><\/noindex>. <br \/>\n Gli articoli si sovrapporranno a molti aspetti. \n<\/p><\/blockquote>\n<p>In LAN DC 4 ci sono 4 DC, circa 250 switch, una mezza dozzina di router e un paio di firewall. <br \/>\nNon \u00e8 Facebook, ma \u00e8 sufficiente per riflettere profondamente sull'automazione. <br \/>\nSi dice, comunque, che se avete pi\u00f9 di un dispositivo, l'automazione \u00e8 gi\u00e0 necessaria. <br \/>\nIn realt\u00e0 \u00e8 difficile immaginare che qualcuno possa vivere senza almeno un pacchetto di script per le ginocchia. <br \/>\nTuttavia, ho sentito che ci sono aziende dove la gestione degli indirizzi IP avviene in Excel, e ciascuno dei migliaia di dispositivi di rete viene configurato manualmente e ha la propria configurazione unica. Questo, ovviamente, pu\u00f2 essere considerato arte moderna, ma i sentimenti di un ingegnere saranno certamente offesi. <\/p>\n<h1>Obiettivi<\/h1>\n<p>\nAdesso poniamo obiettivi massimamente astratti:<\/p>\n<ul>\n<li>La rete \u00e8 come un organismo unico<\/li>\n<li>Testing della configurazione<\/li>\n<li>Versionamento dello stato della rete<\/li>\n<li>Monitoraggio e auto-recupero dei servizi<\/li>\n<\/ul>\n<p>\nPi\u00f9 avanti in questo articolo discuteremo quali strumenti utilizzeremo, e nei prossimi articoli, obiettivi e strumenti in dettaglio.<\/p>\n<h2>La rete \u00e8 come un organismo unico<\/h2>\n<p>\nLa frase determinante del ciclo, anche se a prima vista pu\u00f2 sembrare non cos\u00ec significativa: <b>configureremo la rete, non i singoli dispositivi<\/b>. <br \/>\nNegli ultimi anni abbiamo osservato uno spostamento di accenti verso la gestione della rete come un'entit\u00e0 unica, da cui provengono <i>Software Defined Networking<\/i>, <i>Intent Driven Networks<\/i> e <i>Autonomous Networks<\/i>. <br \/>\nInfatti, cosa serve essenzialmente alle applicazioni dalla rete: connettivit\u00e0 tra i punti A e B (beh, a volte +V-\u042f) e isolamento da altre applicazioni e utenti. <\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/f8b43928ccc6d487722ce7724f5c4829.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE cos\u00ec, il nostro compito in questa serie \u00e8 <b>costruire un sistema<\/b>, che supporti la configurazione attuale <b>dell'intera rete<\/b>, che gi\u00e0 si decompone nella configurazione attuale su ciascun dispositivo in base al suo ruolo e posizione. <br \/>\n<b>Sistema<\/b> la gestione della rete implica che per apportare modifiche ci rivolgiamo a essa, e essa a sua volta calcola lo stato necessario per ciascun dispositivo e lo configura. <br \/>\nIn questo modo, minimizziamo quasi a zero l'utilizzo manuale della CLI - qualsiasi modifica nelle impostazioni dei dispositivi o nel design della rete deve essere formalizzata e documentata - e solo dopo deve essere applicata agli elementi necessari della rete. <\/p>\n<blockquote><p> Cio\u00e8, ad esempio, se abbiamo deciso che da questo momento gli switch a torre a Kazan devono annunciare due reti invece di una, noi<\/p>\n<ol>\n<li>Per prima cosa documentiamo le modifiche nei sistemi<\/li>\n<li>Generiamo la configurazione target di tutti i dispositivi della rete<\/li>\n<li>Avviamo il programma di aggiornamento della configurazione della rete, che calcola cosa deve essere rimosso su ogni nodo, cosa aggiungere e porta i nodi allo stato desiderato.<\/li>\n<\/ol>\n<p>\n In questo caso, apportiamo modifiche manualmente solo al primo passo.\n<\/p><\/blockquote>\n<h2>Testing della configurazione<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.wikisummaries.org\/wiki\/Visible_Ops\">\u00c8 noto<\/a><\/noindex>, che l'80% dei problemi si verifica durante la modifica della configurazione: una prova indiretta \u00e8 che durante le festivit\u00e0 natalizie di solito tutto \u00e8 tranquillo. <br \/>\nPersonalmente ho assistito a decine di downtime globali a causa di errori umani: un comando errato, eseguito in un ramo di configurazione sbagliato, dimenticata la comunit\u00e0, cancellato MPLS globalmente su un router, configurate cinque macchine, ma sul sesto abbiamo notato un errore e abbiamo confermato vecchie modifiche fatte da un'altra persona. Ci sono innumerevoli scenari. <\/p>\n<p>L'automazione ci permetter\u00e0 di commettere meno errori, ma su scala pi\u00f9 ampia. Cos\u00ec si pu\u00f2 bloccare non un singolo dispositivo, ma l'intera rete contemporaneamente. <\/p>\n<p>Fin dai tempi antichi i nostri antenati verificavano la correttezza delle modifiche apportate con occhio acuto, palle di acciaio e funzionalit\u00e0 della rete dopo il rilascio. <br \/>\nQuegli antenati il cui lavoro portava a fermi e perdite catastrofiche lasciavano meno discendenti e nel tempo dovevano estinguersi, ma l'evoluzione \u00e8 un processo lento, e quindi ancora oggi non tutti verificano le modifiche in laboratorio. <br \/>\nTuttavia, all'avanguardia del progresso ci sono coloro che hanno automatizzato il processo di test della configurazione e il suo ulteriore utilizzo sulla rete. In altre parole, hanno prelevato la procedura CI\/CD (<noindex><a rel=\"nofollow\" href=\"https:\/\/img.devrant.com\/devrant\/rant\/r_1535091_ErSUL.jpg\">Continuous Integration, Continuous Deployment<\/a><\/noindex>) dagli sviluppatori.<br \/>\nIn una delle sezioni esamineremo come realizzarlo utilizzando un sistema di controllo versioni, probabilmente GitHub. <\/p>\n<blockquote><p> Non appena ti abituerai all'idea di CI\/CD nella rete, all'improvviso il metodo di verifica della configurazione applicandola alla rete operativa ti sembrer\u00e0 una forma di ignoranza medievale. Circa come colpire una testata missilistica con un martello.\n<\/p><\/blockquote>\n<p>L'evoluzione organica delle idee sulla <b>sistema<\/b> di gestione della rete e CI\/CD diventa un vero e proprio versionamento della configurazione. <\/p>\n<h2>Versionamento<\/h2>\n<p>\nConsideriamo che con qualsiasi cambiamento, anche il pi\u00f9 insignificante, anche su un dispositivo poco visibile, tutta la rete passi da uno stato a un altro.<br \/>\nE noi non eseguiamo mai il comando su un dispositivo, cambiamo lo stato della rete. <br \/>\nDiciamo che questi stati li chiameremo versioni?<\/p>\n<p>Supponiamo che l'attuale versione sia 1.0.0.<br \/>\n\u00c8 cambiato l'indirizzo IP dell'interfaccia Loopback su uno dei ToR? Questa \u00e8 una versione minore \u2014 ricever\u00e0 il numero 1.0.1.<br \/>\nSe abbiamo modificato le politiche di importazione delle rotte in BGP - un po' pi\u00f9 serio - siamo gi\u00e0 a 1.1.0.<br \/>\nSe abbiamo deciso di eliminare l'IGP e passare solo a BGP - questo \u00e8 gi\u00e0 un cambiamento radicale di design - 2.0.0.<\/p>\n<p>Inoltre, diversi DC possono avere versioni diverse - la rete si evolve, vengono installati nuovi dispositivi, dove vengono aggiunti nuovi livelli di spine, dove no, ecc.<\/p>\n<p>Su <noindex><a rel=\"nofollow\" href=\"https:\/\/semver.org\">il versionamento semantico<\/a><\/noindex> ne parleremo in un articolo separato.<\/p>\n<p>Ribadisco - qualsiasi cambiamento (eccettuate le comandi di debug) \u00e8 un aggiornamento di versione. Gli amministratori devono essere avvisati di qualsiasi deviazione dalla versione attuale.<\/p>\n<p>Lo stesso vale per il rollback delle modifiche - non si tratta dell'annullamento degli ultimi comandi, non \u00e8 un rollback tramite il sistema operativo del dispositivo - si tratta di riportare tutta la rete a una nuova (o vecchia) versione. <\/p>\n<h2>Monitoraggio e auto-recupero dei servizi<\/h2>\n<p>\nQuesta \u00e8 un compito ovvio nelle reti moderne che raggiunge un nuovo livello.<br \/>\nSpesso, tra i grandi provider di servizi, si pratica l'approccio di dover velocemente distruggere un servizio caduto e alzare un nuovo, invece di capire cosa sia successo.<br \/>\n\u00abVelocemente\u00bb significa che da tutte le parti bisogna coprirsi abbondantemente di monitoraggi, che in pochi secondi rileveranno le pi\u00f9 piccole deviazioni dalla norma.<br \/>\nE qui non sono sufficienti le metriche familiari, come il carico dell'interfaccia o la disponibilit\u00e0 del nodo. Non basta neanche il monitoraggio manuale dell'operatore.<br \/>\nPer molte cose deve esserci <noindex><a rel=\"nofollow\" href=\"https:\/\/www.irisns.com\/self-healing-network-tomorrow-look-like\/\">Self-Healing<\/a><\/noindex> \u2014 i monitoraggi si accendono di rosso e si attivano automaticamente, curando dove fa male.<\/p>\n<p>E qui monitoriamo non solo singoli dispositivi, ma anche la salute dell'intera rete, sia in modalit\u00e0 whitebox, che \u00e8 relativamente chiara, sia in blackbox, che \u00e8 gi\u00e0 pi\u00f9 complessa.<\/p>\n<p>\nDi cosa abbiamo bisogno per realizzare tali ambiziosi piani?<\/p>\n<ul>\n<li>Avere un elenco di tutti i dispositivi nella rete, la loro posizione, ruoli, modelli, versioni di software. <br \/>\n <i>kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.<\/i>\n <\/li>\n<li>Avere un sistema di descrizione dei servizi di rete. <br \/>\n <i>IGP, BGP, L2\/3VPN, Policy, ACL, NTP, SSH.<\/i><\/li>\n<li>Essere in grado di inizializzare il dispositivo. <br \/>\n <i>Hostname, Mgmt IP, Mgmt Route, Utenti, RSA-Keys, LLDP, NETCONF<\/i><\/li>\n<li>Configurare il dispositivo e riportare la configurazione alla versione desiderata (inclusa quella precedente).<\/li>\n<li>Testare la configurazione<\/li>\n<li>Controllare periodicamente lo stato di tutti i dispositivi per verificare eventuali deviazioni e informare gli interessati.<br \/>\n <i>Di notte qualcuno ha silenziosamente aggiunto una regola nell'ACL<\/i>.<\/li>\n<li>Monitorare la funzionalit\u00e0.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Strumenti<\/h1>\n<p>\nSembra abbastanza complicato per iniziare a decomporre il progetto in componenti.<\/p>\n<p>E saranno dieci:<\/p>\n<ol>\n<li>Sistema di inventario<\/li>\n<li>Sistema di gestione dello spazio IP<\/li>\n<li>Sistema di descrizione dei servizi di rete<\/li>\n<li>Meccanismo di inizializzazione dei dispositivi<\/li>\n<li>Modello di configurazione agnostico rispetto al fornitore<\/li>\n<li>Driver specifico per interfaccia del fornitore<\/li>\n<li>Meccanismo di consegna della configurazione al dispositivo<\/li>\n<li>CI\/CD<\/li>\n<li>Meccanismo di backup e rilevamento delle anomalie<\/li>\n<li>Sistema di monitoraggio<\/li>\n<\/ol>\n<blockquote><p> Questo, tra l'altro, \u00e8 un esempio di come \u00e8 cambiata la visione degli obiettivi del ciclo: nella bozza dei componenti ce n'erano 4.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/91132e29d359a4042b213529511f6d7d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNell'illustrazione ho rappresentato tutti i componenti e il dispositivo stesso. <br \/>\nI componenti sovrapposti interagiscono tra loro. <br \/>\nPi\u00f9 \u00e8 grande il blocco, maggiore attenzione deve essere dedicata a questo componente. <\/p>\n<p><\/p>\n<h2>Componente 1. Sistema di inventario<\/h2>\n<p>\n\u00c8 evidente che vogliamo sapere quale attrezzatura si trova dove e a cosa \u00e8 collegata. <br \/>\nIl sistema di inventario \u00e8 una parte essenziale di qualsiasi azienda. <br \/>\nSpesso, per i dispositivi di rete, l'azienda ha un sistema di inventario separato che affronta compiti pi\u00f9 specifici. <br \/>\nNell'ambito del ciclo di articoli lo chiameremo DCIM - Data Center Infrastructure Management. Sebbene il termine DCIM, rigorosamente parlando, includa molto di pi\u00f9.<\/p>\n<p>Per le nostre esigenze, in esso memorizzeremo le seguenti informazioni sul dispositivo:<\/p>\n<ul>\n<li>Numero di inventario<\/li>\n<li>Nome\/descrizione <\/li>\n<li>Modello (<i>Huawei CE12800, Juniper QFX5120 ecc.<\/i>)<\/li>\n<li>Parametri caratteristici (<i>schede, interfacce ecc.<\/i>)<\/li>\n<li>Ruolo (<i>Leaf, Spine, Border Router ecc.<\/i>)<\/li>\n<li>Posizione (<i>regione, citt\u00e0, data center, rack, unit\u00e0<\/i>)<\/li>\n<li>Interconnessioni tra dispositivi<\/li>\n<li>Topologia della rete<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/fac708b1bf3640a943f90247bff8216e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 ben chiaro che ci piacerebbe sapere tutto questo. <br \/>\nMa questo aiuter\u00e0 nell'automazione? <br \/>\nSenza dubbio. <br \/>\nAd esempio, sappiamo che in questo data center sui commutatori Leaf, se si tratta di Huawei, le ACL per filtrare un certo tipo di traffico devono essere applicate alla VLAN, e se si tratta di Juniper, devono essere applicate all'unit\u00e0 0 dell'interfaccia fisica. <br \/>\nO \u00e8 necessario distribuire un nuovo server Syslog su tutti i border del regionale.<\/p>\n<p>In essa memorizzeremo anche dispositivi di rete virtuali, ad esempio router virtuali o route reflector. Possiamo aggiungere server DNS, NTP, Syslog e in generale tutto ci\u00f2 che riguarda la rete. <\/p>\n<h2>Componente 2. Sistema di gestione dello spazio IP<\/h2>\n<p>\nS\u00ec, anche ai nostri tempi ci sono gruppi di persone che tengono traccia dei prefissi e degli indirizzi IP in un file Excel. Ma l'approccio moderno \u00e8 comunque un database, con frontend su nginx\/apache, API e ampie funzionalit\u00e0 per la gestione degli indirizzi IP e delle reti con suddivisione in VRF.<br \/>\nIPAM \u2014 Gestione degli indirizzi IP. <\/p>\n<p>Per le nostre esigenze, in esso conserveremo le seguenti informazioni:<\/p>\n<ul>\n<li>VLAN<\/li>\n<li>VRF<\/li>\n<li>Reti\/Sottoreti<\/li>\n<li>Indirizzi IP<\/li>\n<li>Associazione degli indirizzi ai dispositivi, delle reti alle posizioni e dei numeri VLAN<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6d476d48f95ed663d84cae052a86d129.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi nuovo, \u00e8 chiaro che vogliamo assicurarci che, assegnando un nuovo indirizzo IP al loopback del ToR, non inciampiamo nel fatto che sia gi\u00e0 stato assegnato a qualcun altro. O che usiamo lo stesso prefisso due volte in diverse estremit\u00e0 della rete. <br \/>\nMa come aiuter\u00e0 questo nell'automazione? <br \/>\nFacile. <br \/>\nRichiediamo al sistema un prefisso con ruolo di Loopbacks, in cui ci siano indirizzi IP disponibili per l'assegnazione \u2014 se trovato, assegniamo l'indirizzo, se no, richiediamo la creazione di un nuovo prefisso. <br \/>\nOppure, durante la creazione della configurazione di un dispositivo, possiamo sapere da questo stesso sistema in quale VRF deve trovarsi l'interfaccia. <br \/>\nE quando attiviamo un nuovo server, lo script accede al sistema, scopre in quale switch server, in quale porta e quale sottorete \u00e8 assegnata all'interfaccia \u2014 da essa verr\u00e0 assegnato l'indirizzo del server. <\/p>\n<p>\nSorge la volont\u00e0 di unire DCIM e IPAM in un unico sistema, per evitare di duplicare le funzioni e gestire due entit\u00e0 simili. <br \/>\nE cos\u00ec faremo. <\/p>\n<h2>Componente 3. Sistema di descrizione dei servizi di rete<\/h2>\n<p>\nSe i primi due sistemi memorizzano variabili che devono essere utilizzate in qualche modo, il terzo descrive per ogni ruolo del dispositivo come deve essere configurato. <br \/>\n\u00c8 importante distinguere tra due diversi tipi di servizi di rete: <\/p>\n<ul>\n<li>Infrastrutturali<\/li>\n<li>Clienti.<\/li>\n<\/ul>\n<p>I primi sono progettati per garantire la connettivit\u00e0 di base e la gestione del dispositivo. Qui possiamo includere VTY, SNMP, NTP, Syslog, AAA, protocolli di routing, CoPP, ecc. <br \/>\nI secondi organizzano un servizio per il cliente: MPLS L2\/L3VPN, GRE, VXLAN, VLAN, L2TP, ecc. <br \/>\nNaturalmente, ci sono anche casi borderline \u2014 dove collocare MPLS LDP, BGP? E i protocolli di routing possono essere utilizzati per i clienti. Ma questo non \u00e8 fondamentale. <\/p>\n<p>Entrambi i tipi di servizi vengono suddivisi in primitivi di configurazione:<\/p>\n<ul>\n<li>interfacce fisiche e logiche (tag\/untag, mtu)<\/li>\n<li>indirizzi IP e VRF (IP, IPv6, VRF)<\/li>\n<li>ACL e politiche di gestione del traffico<\/li>\n<li>Protocolli (IGP, BGP, MPLS)<\/li>\n<li>Politiche di instradamento (liste di prefissi, community, filtri ASN).<\/li>\n<li>Servizi di supporto (SSH, NTP, LLDP, Syslog\u2026)<\/li>\n<li>Ecc.<\/li>\n<\/ul>\n<p>\nNon so ancora come lo faremo esattamente. Ne parleremo in un articolo separato.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/092bc3a4b875f4a6422ee13fb580ba4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe parliamo di situazioni pi\u00f9 concrete, potremmo descrivere che<br \/>\nLo switch Leaf deve avere sessioni BGP con tutti gli switch Spine collegati, importare nel processo le reti collegate, accettare solo reti da un certo prefisso dagli switch Spine. Limitare CoPP IPv6 ND a 10 pps ecc. <br \/>\nA sua volta, gli Spine mantengono sessioni con tutti i Leaf collegati, fungendo da route reflector, e accettano solo percorsi di una certa lunghezza e con una certa community.<\/p>\n<h2>Componente 4. Meccanismo di inizializzazione del dispositivo<\/h2>\n<p>\nSotto questo titolo riunisco molteplici azioni che devono avvenire affinch\u00e9 il dispositivo appaia sugli schermi e possa essere raggiunto da remoto.<\/p>\n<ol>\n<li>Registrare il dispositivo nel sistema di inventario.<\/li>\n<li>Assegnare l'indirizzo IP di gestione.<\/li>\n<li>Configurare l'accesso di base: <br \/>\nNome host, indirizzo IP di gestione, rotta nella rete di gestione, utenti, chiavi SSH, protocolli \u2014 telnet\/SSH\/NETCONF<\/li>\n<\/ol>\n<p>Esistono tre approcci:<\/p>\n<ul>\n<li>Completamente tutto manuale. Il dispositivo viene portato su un banco di prova, dove una persona normale lo registra nei sistemi, si connette tramite console e lo configura. Questo pu\u00f2 funzionare in piccole reti statiche.<\/li>\n<li>ZTP \u2014 Zero Touch Provisioning. L'hardware \u00e8 arrivato, si \u00e8 posizionato, ha ricevuto un indirizzo tramite DHCP, \u00e8 andato su un server speciale, si \u00e8 auto-configurato. <\/li>\n<li>Infrastruttura dei server di console, dove la configurazione primaria avviene tramite la porta della console in modalit\u00e0 automatica.<\/li>\n<\/ul>\n<p>Parleremo di tutti e tre in un articolo separato.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6d8d061e53b508edbbcbd98fe496ca91.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 5. Modello di configurazione vendor-agnostic<\/h2>\n<p>\nFino ad ora, tutti i sistemi erano pezzi frammentati, che fornivano descrizioni variabili e dichiarative di ci\u00f2 che ci piacerebbe vedere nella rete. Ma prima o poi, sar\u00e0 necessario affrontare la concretezza. <br \/>\nA questo punto per ogni specifico dispositivo, le primitive, i servizi e le variabili vengono combinati in un modello di configurazione, che descrive effettivamente la configurazione completa di un dispositivo specifico, solo in modo non dipendente dal fornitore. <br \/>\nQual \u00e8 il vantaggio di questo passo? Perch\u00e9 non creare immediatamente la configurazione del dispositivo, che pu\u00f2 essere semplicemente caricata? <br \/>\nIn realt\u00e0, questo consente di risolvere tre compiti:<\/p>\n<ol>\n<li> Non adattarsi a un'interfaccia di interazione specifica con il dispositivo. Che si tratti di CLI, NETCONF, RESTCONF, SNMP, il modello sar\u00e0 lo stesso.<\/li>\n<li> Non mantenere il numero di modelli\/script in base al numero di vendor nella rete e, in caso di modifica del design, cambiare la stessa cosa in pi\u00f9 posti.<\/li>\n<li> Caricare la configurazione dal dispositivo (backup), predisporla in esattamente lo stesso modello e confrontare direttamente la configurazione target e quella esistente per calcolare la delta e preparare un patch di configurazione che modificher\u00e0 solo le parti necessarie o per identificare le deviazioni.<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/a154c42ebe7978fcc5b2ce4f235516c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome risultato di questa fase, otteniamo una configurazione indipendente dal vendor.<\/p>\n<h2>Componente 6. Driver specifico dell'interfaccia vendor<\/h2>\n<p>\nNon bisogna illudersi che un giorno sar\u00e0 possibile configurare un Cisco esattamente come un Juniper, semplicemente inviando loro chiamate identiche. Nonostante l'aumento della popolarit\u00e0 dei whitebox e l'emergere del supporto per NETCONF, RESTCONF e OpenConfig, il contenuto specifico fornito da questi protocolli varia da fornitore a fornitore, e questo \u00e8 uno dei loro punti di differenziazione competitivi che non cederanno facilmente. <br \/>\n\u00c8 pi\u00f9 o meno come OpenContrail e OpenStack, che hanno il RestAPI come la loro interfaccia NorthBound, ma si aspettano chiamate completamente diverse. <\/p>\n<p>Dunque, al quinto passo, il modello indipendente dal vendor deve assumere la forma in cui andr\u00e0 sull'hardware. <br \/>\nE in questo caso \u00e8 lecito usare qualsiasi mezzo: CLI, NETCONF, RESTCONF, SNMP, chi se ne frega.<\/p>\n<p>Pertanto, abbiamo bisogno di un driver che traduca il risultato del passo precedente nel formato necessario per il particolare vendor: set di comandi CLI, struttura XML.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6ed8e935183075fda60a209477f84937.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 7. Meccanismo di consegna della configurazione al dispositivo<\/h2>\n<p>\nAbbiamo generato la configurazione, ma ora dobbiamo consegnarla ai dispositivi - e ovviamente non manualmente. <br \/>\n<b>Primo<\/b>, ci si pone la domanda: quale trasporto utilizzeremo? E al giorno d'oggi le opzioni non mancano:<\/p>\n<ul>\n<li>CLI (telnet, ssh)<\/li>\n<li>SNMP<\/li>\n<li>NETCONF<\/li>\n<li>RESTCONF<\/li>\n<li>REST API<\/li>\n<li>OpenFlow (anche se esce un po' dal contesto, poich\u00e9 \u00e8 un modo per consegnare FIB, non configurazioni)<\/li>\n<\/ul>\n<p>Diamo qui chiarimenti. CLI \u00e8 legacy. SNMP... ehm... ehm.<br \/>\nRESTCONF \u00e8 ancora una bestia sconosciuta, l'API REST non \u00e8 supportata praticamente da nessuno. Quindi, nel ciclo ci concentreremo su NETCONF.<\/p>\n<p>In realt\u00e0, come gi\u00e0 compreso dal lettore, con l'interfaccia ci siamo gi\u00e0 chiariti a questo punto: il risultato del passaggio precedente \u00e8 gi\u00e0 presentato nel formato di quell'interfaccia che \u00e8 stata scelta.<\/p>\n<p><b>In secondo luogo<\/b>, quali strumenti utilizzeremo per farlo?<br \/>\nQui c'\u00e8 anche una grande scelta:<\/p>\n<ul>\n<li>Uno script personalizzato o una piattaforma. Armati di ncclient e asyncIO, faremo tutto da soli. Che ci vuole, costruire un sistema di deployment da zero?<\/li>\n<li>Ansible con la sua ricca libreria di moduli di rete.<\/li>\n<li>Salt con il suo scarso supporto per le reti e il collegamento con Napalm.<\/li>\n<li>Il vero Napalm, che conosce un paio di vendor e basta, arrivederci.<\/li>\n<li>Nornir \u00e8 un'altra bestia che tratteremo in futuro.<\/li>\n<\/ul>\n<p>Qui non \u00e8 ancora stato scelto un favorito: daremo un'occhiata.<\/p>\n<p>Cosa \u00e8 importante qui? Le conseguenze dell'applicazione della configurazione. <br \/>\nCon successo o meno. C'\u00e8 ancora accesso all'hardware o no. <br \/>\nSembra che in questo caso un commit con conferma e validazione di ci\u00f2 che \u00e8 stato caricato sul dispositivo possa aiutare. <br \/>\nQuesto, insieme a una corretta implementazione di NETCONF, restringe notevolmente il numero di dispositivi adatti: commit normali non sono supportati da cos\u00ec tanti produttori. Ma questo \u00e8 semplicemente uno dei requisiti essenziali in <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%97%D0%B0%D0%BF%D1%80%D0%BE%D1%81_%D0%BF%D1%80%D0%B5%D0%B4%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F\">RFP<\/a><\/noindex>. Alla fine, nessuno si preoccupa se nessun vendor russo pu\u00f2 soddisfare la condizione di un'interfaccia 32*100GE. O si preoccupa?<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/59d8ad3b55b9c107642550bb06fc759a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Componente 8. CI\/CD<\/h2>\n<p>\nA questo punto abbiamo gi\u00e0 pronte le configurazioni per tutti i dispositivi della rete.<br \/>\nScrivo \"per tutti\" perch\u00e9 stiamo parlando di versioning dello stato della rete. E anche se \u00e8 necessario cambiare le impostazioni di un solo switch, vengono calcolate le modifiche per l'intera rete. Ovviamente, queste possono risultare nulle per la maggior parte dei nodi.<\/p>\n<p>Ma, come gi\u00e0 detto sopra, non siamo certo barbari per lanciare tutto subito in produzione. <br \/>\nLa configurazione generata deve prima passare attraverso il Pipeline CI\/CD.<\/p>\n<blockquote><p>CI\/CD significa Continuous Integration, Continuous Deployment. Questo approccio prevede che il team non rilasci una nuova major release ogni sei mesi sostituendo completamente la precedente, ma implementi regolarmente in modo incrementale (Deployment) nuove funzionalit\u00e0 in piccole porzioni, ciascuna delle quali viene testata approfonditamente per compatibilit\u00e0, sicurezza e funzionalit\u00e0 (Integration).\n<\/p><\/blockquote>\n<p>Per questo abbiamo un sistema di controllo delle versioni che tiene traccia delle modifiche nella configurazione, un laboratorio in cui viene testato se il servizio client non si rompe, un sistema di monitoraggio che verifica questo e l'ultimo passaggio \u00e8 il rilascio delle modifiche nella rete operativa.<\/p>\n<p>Ad eccezione dei comandi di debug, tutti i cambiamenti sulla rete devono passare attraverso il CI\/CD Pipeline: \u00e8 la nostra garanzia di una vita serena e di una lunga carriera felice.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/101a5ff87c7a9c7b6776aca9daf762a4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 9. Sistema di backup e ricerca delle anomalie<\/h2>\n<p>\nNon c'\u00e8 bisogno di ribadire l'importanza dei backup. <br \/>\nLi archivieremo semplicemente in cron o in base alle modifiche nella configurazione su git.<\/p>\n<p>Ma la seconda parte \u00e8 pi\u00f9 interessante: qualcuno deve sorvegliare questi backup. E in alcuni casi, questa persona deve tornare indietro e ripristinare tutto com'era, in altri casi, avvertire qualcuno che c'\u00e8 un problema. <br \/>\nAd esempio, se appare un nuovo utente non presente nelle variabili, deve essere rimosso per evitare problemi. E se c'\u00e8 una nuova regola firewall, \u00e8 meglio non toccarla, forse qualcuno ha semplicemente attivato il debug, o forse un nuovo servizio non l'ha registrata correttamente, mentre la gente gi\u00e0 ci sta accedendo.<\/p>\n<p>Da una certa piccola delta nell'ambito dell'intera rete non possiamo comunque scappare, nonostante qualsiasi sistema di automazione e la mano ferma della direzione. Per la risoluzione dei problemi, comunque, nessuno andr\u00e0 a modificare la configurazione nei sistemi. Tanto pi\u00f9 che la loro modifica potrebbe non essere nemmeno prevista dal modello di configurazione. <\/p>\n<blockquote><p>Ad esempio, una regola firewall per contare il numero di pacchetti su un certo IP per localizzare il problema \u00e8 un'ordinaria configurazione temporanea.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/390f78139d336f1fc2c60573bccfe76c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 10. Sistema di monitoraggio<\/h2>\n<p>\nAll'inizio non avrei voluto trattare l'argomento del monitoraggio, poich\u00e9 \u00e8 un tema ampio, controverso e complesso. Ma nel corso dei lavori \u00e8 diventato chiaro che \u00e8 una parte integrante dell'automazione. E non \u00e8 possibile evitarlo, nemmeno senza esperienza pratica. <\/p>\n<p>Sviluppando il concetto, \u00e8 una parte organica del processo CI\/CD. Dopo il rilascio della configurazione sulla rete, dobbiamo essere in grado di determinare se tutto ora va bene. <br \/>\nE si tratta non solo e non tanto dei grafici di utilizzo delle interfacce o della disponibilit\u00e0 dei nodi, ma di questioni pi\u00f9 sottili: la presenza delle rotte necessarie, degli attributi su di esse, del numero di sessioni BGP, dei vicini OSPF, della funzionalit\u00e0 end-to-end dei servizi superiori.<br \/>\nE se i syslog smettessero di accumularsi sul server esterno, se l'agente SFlow si fosse guasto, se i drop nelle code cominciassero ad aumentare, o se la connettivit\u00e0 tra una coppia di prefissi fosse compromessa?<\/p>\n<p>In un articolo separato rifletteremo anche su questo.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/08aeee4939081abb21e61abadd0ce5de.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/13c186070c85fd00f7b6923df154f1b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h1>Conclusione<\/h1>\n<p>\nCome base ho scelto uno dei design moderni delle reti dei data center: L3 Clos Fabric con BGP come protocollo di routing.<br \/>\nQuesta volta costruiremo la rete su Juniper, perch\u00e9 ora l'interfaccia JunOs \u00e8 un vantaggio.<\/p>\n<p>Ci complichiamo la vita utilizzando solo strumenti Open Source e una rete multi-vendor, quindi oltre a Juniper sceglier\u00f2 anche un altro fortunato.<\/p>\n<p>Il piano delle pubblicazioni prossime \u00e8 pi\u00f9 o meno questo:<br \/>\nInizialmente parler\u00f2 delle reti virtuali. Prima di tutto, perch\u00e9 mi interessa, e in secondo luogo, perch\u00e9 senza di esse il design della rete infrastrutturale non sar\u00e0 molto chiaro.<br \/>\nPoi parler\u00f2 del design della rete: topologia, routing, politiche.<br \/>\nCostruiremo una configurazione di laboratorio.<br \/>\nRifletteremo e, magari, faremo pratica nell'inizializzazione di un dispositivo nella rete.<br \/>\nE poi parleremo di ogni componente in dettagli intimi.<\/p>\n<p>E s\u00ec, non prometto di concludere questo ciclo con una soluzione pronta. \ud83d\ude42<\/p>\n<h5>Link utili<\/h5>\n<p><\/p>\n<ul>\n<li>Prima di addentrarci nella serie, vale la pena leggere il libro di Natasha Samoylenko <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.gitbook.io\/pyneng\/\">Python per ingegneri di rete<\/a><\/noindex>. E, forse, anche seguire <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.github.io\/pyneng-online\/\">un corso<\/a><\/noindex>.<\/li>\n<li>Sar\u00e0 utile anche leggere <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7938\">RFC<\/a><\/noindex> sul design delle fabbriche dei data center di Facebook scritto da Petr Lapukhov.<\/li>\n<li>La documentazione sull'architettura ti dar\u00e0 un'idea di come funziona l'SDN basato su Overlay. <noindex><a rel=\"nofollow\" href=\"https:\/\/tungstenfabric.github.io\/website\/Tungsten-Fabric-Architecture.html\">Tungsten Fabric<\/a><\/noindex> (precedentemente Open Contrail).<\/li>\n<\/ul>\n<h5>Grazie a<\/h5>\n<p>\nRoman Gorge. Per i commenti e le correzioni.<br \/>\nArtyom Chernobai. Per KDPV.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/453516\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c. \u0414\u043e\u043b\u0433\u0438\u0435 \u0433\u043e\u0434\u044b \u043d\u0430\u0448 \u0431\u0440\u0430\u0442 \u0441\u0442\u0440\u0430\u0434\u0430\u043b \u043e\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0440\u0443\u0442\u0438\u043d\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b, \u0441\u043a\u0440\u0435\u0449\u0438\u0432\u0430\u043b \u043f\u0430\u043b\u044c\u0446\u044b \u043f\u0435\u0440\u0435\u0434 \u043a\u043e\u043c\u043c\u0438\u0442\u043e\u043c \u0438 \u043d\u0435\u0434\u043e\u0441\u044b\u043f\u0430\u043b \u0438\u0437-\u0437\u0430 \u043d\u043e\u0447\u043d\u044b\u0445 \u0440\u043e\u043b\u0431\u044d\u043a\u043e\u0432. \u041d\u043e \u0442\u0451\u043c\u043d\u044b\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0430\u043c \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u043a\u043e\u043d\u0435\u0446. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0451\u0439 \u044f \u043d\u0430\u0447\u043d\u0443 \u0441\u0435\u0440\u0438\u044e \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043d\u0435 \u0432\u0438\u0434\u0438\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f. \u041f\u043e \u0445\u043e\u0434\u0443 \u0434\u0435\u043b\u0430 \u0440\u0430\u0437\u0431\u0435\u0440\u0451\u043c\u0441\u044f \u0441 \u044d\u0442\u0430\u043f\u0430\u043c\u0438 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435\u043c \u043f\u0435\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445, \u0444\u043e\u0440\u043c\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0435\u0439 \u0434\u0438\u0437\u0430\u0439\u043d\u0430, \u0441 RestAPI, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26891,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35972","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0434\u043b\u044f \u0441\u0430\u043c\u044b\u0445 \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043d\u0443\u043b\u0435\u0432\u0430\u044f. \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione | ProHoster","description":"Il SDSM \u00e8 finito, ma il desiderio incontrollato di scrivere \u00e8 rimasto.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0434\u043b\u044f \u0441\u0430\u043c\u044b\u0445 \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043d\u0443\u043b\u0435\u0432\u0430\u044f. \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:08:54+00:00","article:modified_time":"2019-10-31T19:08:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35972","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:28:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 09:58:22","updated":"2026-01-22 01:28:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35972","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35972"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35972\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26891"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35972"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35972"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35972"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}