{"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\/nl\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","title":{"rendered":"Automatisering voor de kleintjes. Deel nul. Planning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>SDCM is afgelopen, maar het ongecontroleerde verlangen om te schrijven is gebleven. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/0\/kdpv.jpg\"><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/2da9a566e92a782cf1205a6da716d4c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Jarenlang heeft onze broer geleden onder het uitvoeren van routinematige taken, met gekruiste vingers voor de commit en slaaptekort door nachtelijke rollbacks.<br \/>\nMaar aan donkere tijden komt een einde.<\/p>\n<p>Met dit artikel begin ik een serie over hoe <i>mij<\/i> automatisering zich laat zien. <br \/>\nIn de loop van de tijd zullen we de fasen van automatisering bespreken, het opslaan van variabelen, het formaliseren van het ontwerp, met RestAPI, NETCONF, YANG, YDK, en we zullen heel veel programmeren. <br \/>\n<i>Voor mij<\/i> betekent dat a) dit is geen objectieve waarheid, b) het is niet zonder meer de beste benadering c) mijn kijk kan zelfs tijdens de overgang van het eerste naar het laatste artikel veranderen \u2013 eerlijk gezegd, van het concept tot de publicatie heb ik alles in totaal twee keer volledig herschreven. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Inhoud<\/h1>\n<p><\/p>\n<ol>\n<li> <b>Doelen<\/b>\n<ol>\n<li>Het netwerk - als \u00e9\u00e9n organisme<\/li>\n<li>Configuratietests<\/li>\n<li>Versiebeheer<\/li>\n<li>Monitoring en zelfherstel van diensten<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Hulpmiddelen<\/b>\n<ol>\n<li>Inventarisatiesysteem<\/li>\n<li>Systeem voor IP-beheer<\/li>\n<li>Systeem voor het beschrijven van netwerkdiensten<\/li>\n<li>Mechanisme voor apparaatinitialisatie<\/li>\n<li>Vendor-agnostisch configuratiemodel<\/li>\n<li>Vendor-specifieke driver interface<\/li>\n<li>Mechanisme voor het verzenden van configuratie naar een apparaat<\/li>\n<li>CI\/CD<\/li>\n<li>Mechanisme voor back-up en afwijkingsdetectie<\/li>\n<li>Monitoring systeem<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Conclusie<\/b>\n <\/li>\n<\/ol>\n<p>\nIk zal proberen ADSCM te leiden in een iets andere opzet dan SDCM. Er zullen nog steeds grote, gedetailleerde genummerde artikelen verschijnen, en daartussen zal ik kleine notities uit de dagelijkse ervaring publiceren. Ik zal proberen hier te strijden tegen perfectionisme en niet elk van hen te verfijnen. <\/p>\n<blockquote><p> Het is grappig dat je voor de tweede keer dezelfde weg moet bewandelen.<\/p>\n<p> Eerst moest ik zelf artikelen over netwerken schrijven omdat die niet beschikbaar waren in het Russisch.<\/p>\n<p> Nu kon ik geen uitgebreid document vinden dat de benaderingen van automatisering systematiseerde en de bovenstaande technologie\u00ebn aan de hand van eenvoudige praktische voorbeelden uitlegde.<\/p>\n<p> Misschien vergis ik me, dus gooi gerust links naar goede bronnen. Toch zal dit mijn vastberadenheid om te schrijven niet veranderen, want het belangrijkste doel is uiteindelijk om iets zelf te leren, en het verlichten van het leven van anderen is een prettige bonus die de verspreiding van ervaring bevorderd.\n<\/p><\/blockquote>\n<p>We zullen proberen een middelgroot datacenter LAN DC te nemen en het volledige automatiseringsschema uit te werken. <br \/>\nSommige dingen zal ik bijna voor het eerst samen met jullie doen. <\/p>\n<blockquote><p> In de beschreven idee\u00ebn en hulpmiddelen zal ik niet origineel zijn. Dmitry Figol heeft een uitstekende <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=MLeiShwb7Qo&amp;list=PLSwGHYY8t8JiGI9powOXDHTAXDSs7FZqt\">kanaal met livestreams hierover.<\/a><\/noindex>. <br \/>\n De artikelen zullen in vele opzichten met hen overlappen. \n<\/p><\/blockquote>\n<p>In LAN DC 4 Datacenters, ongeveer 250 switches, een handvol routers en een paar firewalls. <br \/>\nGeen Facebook, maar genoeg om diep na te denken over automatisering. <br \/>\nEr bestaat echter de mening dat als je meer dan 1 apparaat hebt, automatisering al nodig is. <br \/>\nHet is eigenlijk moeilijk voor te stellen dat iemand tegenwoordig zonder ten minste een stapel scripts kan leven. <br \/>\nHoewel ik heb gehoord dat er bedrijven zijn waar IP-adressen in Excel worden bijgehouden, en elk van de duizenden netwerkapparaten handmatig wordt ingesteld met een unieke configuratie. Dit kan natuurlijk worden gepresenteerd als moderne kunst, maar de gevoelens van de ingenieur zullen zeker gekwetst zijn. <\/p>\n<h1>Doelen<\/h1>\n<p>\nLaten we nu de meest abstracte doelen stellen:<\/p>\n<ul>\n<li>Het netwerk - als \u00e9\u00e9n organisme<\/li>\n<li>Configuratietests<\/li>\n<li>Versiebeheer van de netwerkstaat.<\/li>\n<li>Monitoring en zelfherstel van diensten<\/li>\n<\/ul>\n<p>\nLater in dit artikel zullen we kijken naar de middelen die we gaan gebruiken, en in de volgende artikelen naar zowel de doelen als de middelen in detail.<\/p>\n<h2>Het netwerk - als \u00e9\u00e9n organisme<\/h2>\n<p>\nDe bepalende zin van de cyclus, hoewel deze op het eerste gezicht niet zo significant lijkt: <b>we zullen het netwerk instellen, niet afzonderlijke apparaten.<\/b>. <br \/>\nIn de afgelopen jaren hebben we een verschuiving gezien naar het omgaan met netwerken als \u00e9\u00e9n enkele entiteit, en daarom komen <i>Software Defined Networking<\/i>, <i>Intent Driven Networks<\/i> en <i>Autonomous Networks<\/i>. <br \/>\nWant wat hebben applicaties globaal van het netwerk nodig: connectiviteit tussen punt A en B (en soms +B-Y) en isolatie van andere applicaties en gebruikers. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/f8b43928ccc6d487722ce7724f5c4829.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn zo is onze taak in deze serie om <b>een systeem op te bouwen<\/b>, dat de actuele configuratie ondersteunt <b>van het hele netwerk<\/b>, dat al wordt gedecomprimeerd tot de actuele configuratie op elk apparaat, afhankelijk van zijn rol en locatie. <br \/>\n<b>Systeem<\/b> netwerkbeheer houdt in dat we voor wijzigingen in het netwerk informatie opvragen, en het vervolgens de juiste staat voor elk apparaat berekent en instelt. <br \/>\nOp deze manier minimaliseren we bijna tot nul het handmatig werken in CLI \u2014 alle wijzigingen in de instellingen van apparaten of netwerkontwerpen moeten worden geformaliseerd en gedocumenteerd \u2014 en pas daarna uitgerold naar de juiste netwerkcomponenten. <\/p>\n<blockquote><p> Bijvoorbeeld, als we besluiten dat de rack switches in Kazan vanaf nu twee netwerken in plaats van \u00e9\u00e9n moeten aankondigen, dan<\/p>\n<ol>\n<li>documenteren we eerst de wijzigingen in de systemen<\/li>\n<li>Generen we de doelconfiguratie van alle netwerkapparaten<\/li>\n<li>Starten we het programma voor het bijwerken van de netwerkconfiguratie, dat berekent wat op elke node moet worden verwijderd, wat moet worden toegevoegd, en brengt de nodes in de gewenste toestand.<\/li>\n<\/ol>\n<p>\n In deze fase voeren we handmatig wijzigingen alleen in de eerste stap door.\n<\/p><\/blockquote>\n<h2>Configuratietests<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.wikisummaries.org\/wiki\/Visible_Ops\">Het is bekend<\/a><\/noindex>, dat 80% van de problemen zich voordoen tijdens het wijzigen van de configuratie \u2014 een indirect bewijs hiervoor is dat het meestal rustig is tijdens de kerstvakantie. <br \/>\nIk heb persoonlijk tientallen wereldwijde downtime's meegemaakt door menselijke fouten: een verkeerde opdracht, niet in de juiste configuratietak uitgevoerd, vergeten om de community in te voegen, MPLS wereldwijd op de router gewist, vijf apparaten ingesteld, maar op de zesde een fout niet opgemerkt, oude wijzigingen die door iemand anders zijn aangebracht gecommitteerd. Er zijn ontelbare scenario's. <\/p>\n<p>Automatisering helpt ons om minder fouten te maken, maar op een grotere schaal. Zo kan je niet slechts \u00e9\u00e9n apparaat, maar het hele netwerk in \u00e9\u00e9n keer onbruikbaar maken. <\/p>\n<p>Van oudsher controleerden onze voorouders de juistheid van de aangebrachte wijzigingen met een scherp oog, stalen zenuwen en het functioneren van het netwerk na hun implementatie. <br \/>\nDe voorouders wiens werk leidde tot stilstand en catastrofale verliezen, lieten minder nageslacht achter en zouden met de tijd moeten uitsterven, maar evolutie is een traag proces, en daarom controleren nog steeds niet iedereen de wijzigingen vooraf in een laboratorium. <br \/>\nEchter, aan de voorhoede van de vooruitgang zijn degenen die het proces van het testen van configuraties hebben geautomatiseerd, en de verdere toepassing in het netwerk. Met andere woorden \u2014 hebben ze de CI\/CD-procedure (<noindex><a rel=\"nofollow\" href=\"https:\/\/img.devrant.com\/devrant\/rant\/r_1535091_ErSUL.jpg\">Continuous Integration, Continuous Deployment<\/a><\/noindex>) van ontwikkelaars overgenomen.<br \/>\nIn een van de secties zullen we bekijken hoe dit kan worden gerealiseerd met behulp van een versiebeheersysteem, waarschijnlijk GitHub. <\/p>\n<blockquote><p> Zodra je het idee van netwerk CI\/CD accepteert, zal de methode om de configuratie te controleren door deze in het werkelijke netwerk toe te passen je ineens middeleeuwse onwetendheid lijken. Bijna alsof je met een hamer op een kernkop klopt.\n<\/p><\/blockquote>\n<p>De organieke uitbreiding van idee\u00ebn over <b>het netwerk<\/b> beheer en CI\/CD resulteert in een volledige versiebeheer van de configuratie. <\/p>\n<h2>Versiebeheer<\/h2>\n<p>\nWe will assume that with any changes, even the slightest, even on one unnoticed device, the entire network transitions from one state to another.<br \/>\nAnd we never execute a command on the device; we change the state of the network. <br \/>\nSo, shall we call these states versions?<\/p>\n<p>Let\u2019s say the current version is 1.0.0.<br \/>\nIs het IP-adres van de Loopback-interface gewijzigd op \u00e9\u00e9n van de ToR's? Dit is een minor release \u2014 het krijgt versie 1.0.1.<br \/>\nReviewing the route import policies in BGP\u2014this is a bit more serious\u2014already 1.1.0.<br \/>\nDeciding to get rid of the IGP and only switch to BGP\u2014that\u2019s already a radical design change\u20142.0.0.<\/p>\n<p>At the same time, different DCs may have different versions\u2014the network evolves, new equipment is installed, new levels of spines are added somewhere, and not elsewhere, etc.<\/p>\n<p>Over <noindex><a rel=\"nofollow\" href=\"https:\/\/semver.org\">semantic versioning<\/a><\/noindex> we will discuss this in a separate article.<\/p>\n<p>I repeat\u2014any change (except for debugging commands) is a version update. Administrators should be notified of any deviations from the current version.<\/p>\n<p>The same applies to rolling back changes\u2014this is not cancelling recent commands, nor is it a rollback by the operating system of the device\u2014it is bringing the entire network to a new (old) version. <\/p>\n<h2>Monitoring en zelfherstel van diensten<\/h2>\n<p>\nThis self-evident task in modern networks is reaching a new level.<br \/>\nOften, large service providers adopt the approach that a fallen service must be quickly resolved and a new one raised instead of figuring out what happened.<br \/>\n\"Very\" means that from all sides, there should be ample monitoring that will detect any deviations from the norm within seconds.<br \/>\nAnd here, the usual metrics like interface load or node availability are not enough. Manual monitoring by the on-duty staff is also insufficient.<br \/>\nFor many things, there should be <noindex><a rel=\"nofollow\" href=\"https:\/\/www.irisns.com\/self-healing-network-tomorrow-look-like\/\">Self-Healing<\/a><\/noindex> - monitoring lights up red and goes to apply a band-aid where it hurts.<\/p>\n<p>And here we also monitor not only individual devices but the health of the entire network, both in white-box (which is relatively clear) and black-box (which is already more complex) terms.<\/p>\n<p>\nWhat do we need to implement such ambitious plans?<\/p>\n<ul>\n<li>To have a list of all devices in the network, their locations, roles, models, and software versions. <br \/>\n <i>kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.<\/i>\n <\/li>\n<li>To have a system for describing network services. <br \/>\n <i>IGP, BGP, L2\/3VPN, Policy, ACL, NTP, SSH.<\/i><\/li>\n<li>Vermogen om een apparaat te initialiseren. <br \/>\n <i>Hostname, Mgmt IP, Mgmt Route, Gebruikers, RSA-Keys, LLDP, NETCONF<\/i><\/li>\n<li>Het apparaat configureren en de configuratie naar de gewenste (inclusief oude) versie terugbrengen.<\/li>\n<li>De configuratie testen<\/li>\n<li>Periodiek de status van alle apparaten controleren op afwijkingen van de actuele situatie en het juiste bericht versturen.<br \/>\n <i>Iemand heeft 's nachts stilletjes een regel aan de ACL toegevoegd<\/i>.<\/li>\n<li>Toezicht houden op de werking.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Hulpmiddelen<\/h1>\n<p>\nDat klinkt behoorlijk ingewikkeld om het project in componenten te decomponeren.<\/p>\n<p>En het zullen er tien zijn:<\/p>\n<ol>\n<li>Inventarisatiesysteem<\/li>\n<li>Systeem voor IP-beheer<\/li>\n<li>Systeem voor het beschrijven van netwerkdiensten<\/li>\n<li>Mechanisme voor apparaatinitialisatie<\/li>\n<li>Vendor-agnostisch configuratiemodel<\/li>\n<li>Vendor-specifieke driver interface<\/li>\n<li>Mechanisme voor het verzenden van configuratie naar een apparaat<\/li>\n<li>CI\/CD<\/li>\n<li>Mechanisme voor back-up en afwijkingsdetectie<\/li>\n<li>Monitoring systeem<\/li>\n<\/ol>\n<blockquote><p> Dit is trouwens een voorbeeld van hoe de kijk op de doelstellingen van de cyclus is veranderd - in de conceptversie waren het er vier.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/91132e29d359a4042b213529511f6d7d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOp de afbeelding heb ik alle componenten en het eigenlijke apparaat afgebeeld. <br \/>\nOverlappende componenten communiceren met elkaar. <br \/>\nHoe groter het blok, hoe meer aandacht aan deze component gegeven moet worden. <\/p>\n<p><\/p>\n<h2>Component 1. Inventarissysteem<\/h2>\n<p>\nHet is duidelijk dat we willen weten welk apparaat waar staat en waaraan het is aangesloten. <br \/>\nHet inventarissysteem is een essentieel onderdeel van elke onderneming. <br \/>\nVaak heeft een onderneming voor netwerkapparaten een apart inventarissysteem dat meer specifieke taken behandelt. <br \/>\nIn de reeks artikelen zullen we dit DCIM - Data Center Infrastructure Management - noemen. Hoewel de term DCIM strikt genomen veel meer omvat.<\/p>\n<p>Voor onze doeleinden gaan we hierin de volgende informatie over het apparaat opslaan:<\/p>\n<ul>\n<li>Inventarisnummer<\/li>\n<li>Naam\/beschrijving <\/li>\n<li>Model (<i>Huawei CE12800, Juniper QFX5120, enz.<\/i>)<\/li>\n<li>Kenmerken (<i>kaarten, interfaces, enz.<\/i>)<\/li>\n<li>Rol (<i>Leaf, Spine, Border Router, enz.<\/i>)<\/li>\n<li>Locatie (<i>regio, stad, datacenter, rack, eenheid<\/i>)<\/li>\n<li>Interconnects tussen apparaten<\/li>\n<li>Netwerk topologie<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/fac708b1bf3640a943f90247bff8216e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet is volkomen begrijpelijk dat we zelf al deze informatie willen hebben. <br \/>\nMaar helpt dit bij automatiseringsdoelen? <br \/>\nZeker. <br \/>\nBijvoorbeeld, we weten dat in dit datacenter op Leaf-schakelaars, als het Huawei is, ACL's voor het filteren van bepaalde verkeer op VLAN moeten worden toegepast, en als het Juniper is, dan op unit 0 van de fysieke interface. <br \/>\nOf we moeten een nieuwe Syslog-server op alle borders van de regio implementeren.<\/p>\n<p>In deze zullen we ook virtuele netwerkapparaten opslaan, bijvoorbeeld virtuele routers of route-reflectoren. We kunnen DNS-servers, NTP, Syslog en eigenlijk alles toevoegen dat op de een of andere manier met het netwerk te maken heeft. <\/p>\n<h2>Component 2. IP-adresbeheer systeem<\/h2>\n<p>\nJa, ook tegenwoordig zijn er groepen mensen die voor het bijhouden van prefixen en IP-adressen een Excel-bestand gebruiken. Maar de moderne aanpak is toch een database, met een frontend op nginx\/apache, API en uitgebreide functies voor het beheren van IP-adressen en netwerken met scheiding in VRF.<br \/>\nIPAM - IP Adresbeheer. <\/p>\n<p>Voor onze doeleinden slaan we hierin de volgende informatie op:<\/p>\n<ul>\n<li>VLAN<\/li>\n<li>VRF<\/li>\n<li>Netwerken\/Subnetten<\/li>\n<li>IP-adressen<\/li>\n<li>Koppeling van adressen aan apparaten, netwerken aan locaties en VLAN-nummers<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/6d476d48f95ed663d84cae052a86d129.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet is duidelijk dat we er zeker van willen zijn dat wanneer we een nieuw IP-adres voor de loopback van de ToR toewijzen, we niet tegen de situatie aanlopen dat het al aan iemand is toegewezen. Of dat we dezelfde prefix twee keer hebben gebruikt aan verschillende uiteinden van het netwerk. <br \/>\nMaar hoe helpt dit bij de automatisering? <br \/>\nEenvoudig. <br \/>\nWe vragen in het systeem het prefix met de rol Loopbacks aan, waarin beschikbare IP-adressen zijn voor toewijzing - als het gevonden wordt, wijzen we het adres toe, als dat niet zo is, vragen we om een nieuw prefix te cre\u00ebren. <br \/>\nOf bij het maken van de configuratie van een apparaat kunnen we vanuit hetzelfde systeem achterhalen in welk VRF de interface moet zijn. <br \/>\nBij de opstart van een nieuwe server gaat het script naar het systeem, ontdekt in welke serverswitch, op welke poort en welk subnet aan de interface is toegewezen - hieruit wordt het serveradres toegewezen. <\/p>\n<p>\nHet dringt zich op om DCIM en IPAM te combineren in \u00e9\u00e9n systeem, om functies niet te dupliceren en niet twee vergelijkbare entiteiten te onderhouden. <br \/>\nDat gaan we doen. <\/p>\n<h2>Component 3. Systeem voor het beschrijven van netwerkservices<\/h2>\n<p>\nAls de eerste twee systemen variabelen opslaan die nog op de een of andere manier moeten worden gebruikt, beschrijft de derde voor elke rol van het apparaat hoe het moet worden ingesteld. <br \/>\nEr zijn twee verschillende typen netwerkservices te onderscheiden: <\/p>\n<ul>\n<li>Infrastructuur<\/li>\n<li>Klantservices.<\/li>\n<\/ul>\n<p>De eerste zijn bedoeld om basisconnectiviteit en apparaatbeheer te waarborgen. Dit omvat VTY, SNMP, NTP, Syslog, AAA, routeringsprotocollen, CoPP, enz. <br \/>\nDe tweede organiseert een dienst voor de klant: MPLS L2\/L3VPN, GRE, VXLAN, VLAN, L2TP, enz. <br \/>\nNatuurlijk zijn er ook grensgevallen - waar moeten we MPLS LDP, BGP onderbrengen? En routeringsprotocollen kunnen ook voor klanten worden gebruikt. Maar dat is niet cruciaal. <\/p>\n<p>Beide typen services worden onderverdeeld in configuratie-primitive:<\/p>\n<ul>\n<li>fysieke en logische interfaces (tag\/untag, mtu)<\/li>\n<li>IP-adressen en VRF (IP, IPv6, VRF)<\/li>\n<li>ACL en verkeersverwerkingspolicies<\/li>\n<li>Protocollen (IGP, BGP, MPLS)<\/li>\n<li>Routeringsbeleid (prefix-lijsten, communities, ASN-filters).<\/li>\n<li>Service Services (SSH, NTP, LLDP, Syslog...)<\/li>\n<li>Etc.<\/li>\n<\/ul>\n<p>\nHoe we dit precies gaan doen, heb ik nog geen idee. We zullen het in een apart artikel uitzoeken.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/092bc3a4b875f4a6422ee13fb580ba4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls we iets dichter bij het leven blijven, zouden we kunnen beschrijven dat<br \/>\nDe leaf-switch moet BGP-sessies hebben met alle verbonden spine-switches, de verbonden netwerken importeren in het proces en alleen netwerken van een bepaald prefix van spine-switches accepteren. CoPP IPv6 ND beperken tot 10 pps, enz. <br \/>\nOp hun beurt houden de spine-switches sessies met alle verbonden leafs, fungeren als route-reflectors en accepteren alleen routes van bepaalde lengte en met een bepaalde community.<\/p>\n<h2>Component 4. Mechanisme voor apparaatinitialisatie<\/h2>\n<p>\nOnder deze titel verzamel ik de vele acties die moeten plaatsvinden zodat het apparaat op de radar verschijnt en van afstand benaderd kan worden.<\/p>\n<ol>\n<li>Het apparaat registreren in het inventarissysteem.<\/li>\n<li>Een IP-adres voor beheer toewijzen.<\/li>\n<li>Basis toegang configureren: <br \/>\nHostname, beheers-IP-adres, route naar het beheernetwerk, gebruikers, SSH-sleutels, protocollen \u2014 telnet\/SSH\/NETCONF<\/li>\n<\/ol>\n<p>Er zijn drie benaderingen:<\/p>\n<ul>\n<li>Helemaal handmatig. Het apparaat wordt naar de stand gebracht, waar een gewone organische persoon het in systemen registreert, zich aansluit via de console en het configureert. Dit kan werken in kleine statische netwerken.<\/li>\n<li>ZTP \u2014 Zero Touch Provisioning. De hardware is aangekomen, is aangesloten en heeft via DHCP een adres ontvangen, is naar een speciale server gegaan en heeft zichzelf geconfigureerd. <\/li>\n<li>Infrastructuur van console-servers, waar de eerste configuratie via de consolepoort automatisch plaatsvindt.<\/li>\n<\/ul>\n<p>We zullen het over alle drie in een apart artikel hebben.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/6d8d061e53b508edbbcbd98fe496ca91.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Component 5. Vendor-onafhankelijke configuratiemodel<\/h2>\n<p>\nTot nu toe waren alle systemen losse lappen die variabelen en een declaratieve beschrijving gaven van wat we in het netwerk zouden willen zien. Maar vroeg of laat, zullen we met de specificiteit te maken krijgen. <br \/>\nIn deze fase worden primitieve, diensten en variabelen voor elk specifiek apparaat gecombineerd in een configuratiemodel dat feitelijk de volledige configuratie van het specifieke apparaat beschrijft, maar op een vendor-onafhankelijke manier. <br \/>\nWat levert deze stap op? Waarom zouden we niet meteen de configuratie van het apparaat maken die we gewoon kunnen uploaden? <br \/>\nIn feite lost dit drie problemen op:<\/p>\n<ol>\n<li> Zorg ervoor dat je niet afhankelijk bent van een specifiek apparaatinterface. Of het nu CLI, NETCONF, RESTCONF of SNMP is - het model blijft hetzelfde.<\/li>\n<li> Houd het aantal sjablonen\/scripts niet gelijk aan het aantal leveranciers in het netwerk, en wijzig bij een herontwerp niet hetzelfde op meerdere plaatsen.<\/li>\n<li> Laad de configuratie van het apparaat (back-up), leg deze in precies hetzelfde model, en vergelijk vervolgens de doelconfiguratie met de bestaande om de delta te berekenen en een configuratiepatch voor te bereiden die alleen die delen wijzigt die nodig zijn, of om afwijkingen vast te stellen.<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/a154c42ebe7978fcc5b2ce4f235516c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls resultaat van deze fase krijgen we een leverancieronafhankelijke configuratie.<\/p>\n<h2>Component 6. Leverancier-specifieke interface driver<\/h2>\n<p>\nHoud jezelf niet voor de gek met de hoop dat je ooit Cisco op dezelfde manier kunt configureren als Juniper, simpelweg door identieke aanroepen naar hen te sturen. Ondanks de toenemende populariteit van whiteboxen en de opkomst van ondersteuning voor NETCONF, RESTCONF en OpenConfig, verschilt de specifieke inhoud die door deze protocollen wordt geleverd van leverancier tot leverancier, en dit is een van hun concurrentievoordelen die ze niet zomaar opgeven. <br \/>\nDit is eigenlijk vergelijkbaar met OpenContrail en OpenStack, die REST API gebruiken als hun NorthBound-interface en totaal verschillende oproepen verwachten. <\/p>\n<p>Dus in stap vijf moet het leverancieronafhankelijke model de vorm aannemen waarin het op de hardware kan worden ge\u00efmplementeerd. <br \/>\nEn hier is alles toegestaan (niet echt): CLI, NETCONF, RESTCONF, SNMP, gewoon bij het afschaffen.<\/p>\n<p>Daarom hebben we een driver nodig die het resultaat van de vorige stap omzet naar het juiste formaat van de specifieke leverancier: een set CLI-commando's, een XML-structuur.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/6ed8e935183075fda60a209477f84937.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Component 7. Mechanisme voor het afleveren van configuraties op het apparaat<\/h2>\n<p>\nWe hebben de configuratie gegenereerd, maar deze moet nog op de apparaten worden afgeleverd - en dat doen we uiteraard niet met de hand. <br \/>\n<b>Firstly<\/b>, dat brengt ons bij de vraag welk transport we gaan gebruiken? En de keuze van vandaag is al behoorlijk groot:<\/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 (hoewel dit uit de lijst valt, omdat het een manier is om FIB af te leveren, niet om instellingen)<\/li>\n<\/ul>\n<p>Laten we hier de puntjes op de i zetten. CLI - dat is legacy. SNMP... khem-khem.<br \/>\nRESTCONF is vooralsnog een onbekend beestje, REST API wordt bijna door niemand ondersteund. Daarom zullen we ons in de cyclus concentreren op NETCONF.<\/p>\n<p>Eigenlijk, zoals de lezer al heeft begrepen, hebben we op dit punt al besloten over de interface \u2014 het resultaat van de vorige stap is al gepresenteerd in het formaat van de gekozen interface.<\/p>\n<p><b>Secondly<\/b>, en met welke tools gaan we dat doen?<br \/>\nHier is de keuze ook groot:<\/p>\n<ul>\n<li>Een zelfgeschreven script of een platform. We bewapenen ons met ncclient en asyncIO en doen alles zelf. Wat staat ons in de weg om een deployment-systeem vanaf nul op te bouwen?<\/li>\n<li>Ansible met zijn rijke bibliotheek aan netwerkmodules.<\/li>\n<li>Salt met zijn beperkte netwerkfunctionaliteit en integratie met Napalm.<\/li>\n<li>Eigenlijk Napalm, dat slechts een paar leveranciers kent en verder niets, tot ziens.<\/li>\n<li>Nornir \u2014 nog een beestje dat we in de toekomst zullen ontleden.<\/li>\n<\/ul>\n<p>Hier is er nog geen favoriet gekozen \u2014 we gaan verder kijken.<\/p>\n<p>Wat is hier nog meer belangrijk? De gevolgen van het toepassen van de configuratie. <br \/>\nSuccesvol of niet. Is de toegang tot de hardware behouden of niet? <br \/>\nHet lijkt erop dat hier een commit met bevestiging en validatie van wat in het apparaat is geladen kan helpen. <br \/>\nDit, in combinatie met een correcte implementatie van NETCONF, beperkt het aantal geschikte apparaten aanzienlijk \u2014 normale commits worden door niet zo veel fabrikanten ondersteund. Maar dit is gewoon een van de vereiste voorwaarden 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>. Uiteindelijk maakt niemand zich zorgen dat geen enkele Russische leverancier voldoet aan de voorwaarde van 32*100GE-interface. Of maken ze zich daar wel zorgen over?<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/59d8ad3b55b9c107642550bb06fc759a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Component 8. CI\/CD<\/h2>\n<p>\nOp dit moment hebben we al een configuratie voor alle netwerkapparaten.<br \/>\nIk schrijf 'voor alle', omdat we het hebben over versiebeheer van de staat van het netwerk. En zelfs als we alleen de instellingen van \u00e9\u00e9n switch moeten wijzigen, worden de wijzigingen voor het gehele netwerk berekend. Voor de meeste knooppunten kunnen deze uiteraard nul zijn.<\/p>\n<p>Maar, zoals eerder al werd gezegd, zijn we geen barbaren die alles in \u00e9\u00e9n keer in productie gooien. <br \/>\nDe gegenereerde configuratie moet eerst door de CI\/CD-pipeline gaan.<\/p>\n<blockquote><p>CI\/CD staat voor Continuous Integration, Continuous Deployment. Dit is een aanpak waarbij het team niet \u00e9\u00e9n keer per half jaar een nieuwe grote release uitbrengt die de oude volledig vervangt, maar regelmatig incrementeel nieuwe functionaliteit introduceert (Deployment) in kleine porties, waarbij elke portie uitgebreid wordt getest op compatibiliteit, veiligheid en functionaliteit (Integration).\n<\/p><\/blockquote>\n<p>Hiervoor hebben we een versiebeheersysteem dat de wijzigingen in de configuratie bijhoudt, een laboratorium waar gecontroleerd wordt of de klantendienst werkt, een monitoring systeem dat deze feiten controleert, en de laatste stap is het uitrollen van wijzigingen naar het productienetwerk.<\/p>\n<p>Met uitzondering van debug-commando's moeten alle wijzigingen in het netwerk via de CI\/CD Pipeline gaan \u2014 dit is onze garantie voor een zorgeloos leven en een lange, gelukkige carri\u00e8re.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/101a5ff87c7a9c7b6776aca9daf762a4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Component 9. Back-up- en afwijkingsdetectiesysteem<\/h2>\n<p>\nEr hoeft niet veel gezegd te worden over back-ups. <br \/>\nWe zullen ze gewoon op cron of bij iedere wijziging in de configuratie in Git opslaan.<\/p>\n<p>Maar het tweede deel is interessanter \u2014 iemand moet deze back-ups in de gaten houden. In sommige gevallen moet deze persoon alles terugdraaien naar hoe het was, en in andere gevallen moet hij of zij iemand verwittigen dat er iets niet klopt. <br \/>\nBijvoorbeeld, als er een nieuwe gebruiker is ge\u00efntroduceerd die niet in de variabelen is opgenomen, moet je deze verwijderd houden van de hacks. En als er een nieuwe firewallregel is \u2014 beter niet aanraken, misschien heeft iemand gewoon de debug ingeschakeld, of misschien heeft een nieuwe dienst, onhandig, deze niet volgens het reglement ingesteld, terwijl mensen er al gebruik van maken.<\/p>\n<p>Van een bepaalde kleine delta binnen het gehele netwerk zullen we hoe dan ook niet kunnen ontsnappen, ongeacht welke automatiseringssystemen en de strikte hand van het management. Voor het debuggen van problemen zal niemand de configuratie in systemen aanbrengen. Bovendien is het mogelijk dat het configuratiemodel deze zelfs niet ondersteunt. <\/p>\n<blockquote><p>Bijvoorbeeld, een firewallregel voor het tellen van het aantal pakketten voor een bepaald IP, voor het lokaliseren van een probleem \u2014 is een vrij gangbare tijdelijke configuratie.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/390f78139d336f1fc2c60573bccfe76c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Component 10. Monitoringsysteem<\/h2>\n<p>\nIn eerste instantie was ik niet van plan om het onderwerp monitoring te behandelen \u2014 het is immers een omvangrijk, controversieel en complex onderwerp. Maar al snel bleek dat het een integraal onderdeel van automatisering is. En je kunt er simpelweg niet omheen, zelfs niet zonder praktische ervaring. <\/p>\n<p>Als we die gedachte verder ontwikkelen \u2014 dit is een organisch onderdeel van het CI\/CD-proces. Na het uitrollen van de configuratie naar het netwerk, moeten we kunnen vaststellen of alles nu in orde is. <br \/>\nEn het gaat niet alleen om grafieken van het gebruik van interfaces of de beschikbaarheid van knooppunten, maar ook om meer verfijnde zaken \u2014 de aanwezigheid van de benodigde routes, de attributen daarop, het aantal BGP-sessies, OSPF-buren, end-to-end functionaliteit van de hogere services.<br \/>\nZijn er geen problemen meer met het verzamelen van syslogs op de externe server, is de SFlow-agent niet defect, zijn de drops in de wachtrijen niet toegenomen en is de connectiviteit tussen een paar prefixes niet verbroken?<\/p>\n<p>In een apart artikel zullen we hier ook over nadenken.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/08aeee4939081abb21e61abadd0ce5de.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><img decoding=\"async\" alt=\"Automatisering voor de kleintjes. Deel nul. Planning\" src=\"\/wp-content\/uploads\/2019\/07\/13c186070c85fd00f7b6923df154f1b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h1>Conclusie<\/h1>\n<p>\nAls basis heb ik een van de moderne ontwerpen van datacenter-netwerken gekozen \u2014 L3 Clos Fabric met BGP als routeringsprotocol.<br \/>\nWe zullen deze keer het netwerk bouwen met Juniper, omdat de JunOs-interface nu gebruiksvriendelijk is.<\/p>\n<p>We zullen het ons moeilijk maken door alleen Open Source-tools en een multi-vendor netwerk te gebruiken \u2014 daarom kies ik naast Juniper ook een andere gelukkige leverancier.<\/p>\n<p>Het plan voor de komende publicaties is ongeveer als volgt:<br \/>\nEerst zal ik vertellen over virtuele netwerken. Allereerst omdat ik dat graag wil, en ten tweede omdat het ontwerp van het infrastructuurnetwerk zonder dit niet echt duidelijk zal zijn.<br \/>\nDan ga ik het hebben over het ontwerp van het netwerk: topologie, routering, beleidsregels.<br \/>\nWe zullen een laboratoriumstand opzetten.<br \/>\nWe zullen nadenken en misschien oefenen met het initialiseren van het apparaat in het netwerk.<br \/>\nEn daarna over elk component in intieme details.<\/p>\n<p>En ja, ik beloof niet om deze cyclus elegant af te sluiten met een kant-en-klare oplossing. \ud83d\ude42<\/p>\n<h5>Nuttige links<\/h5>\n<p><\/p>\n<ul>\n<li>Voordat we verder ingaan op de serie, is het de moeite waard om het boek van Natasha Samoylenko te lezen, <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.gitbook.io\/pyneng\/\">Python voor netwerkingenieurs<\/a><\/noindex>. Misschien moet u ook de <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.github.io\/pyneng-online\/\">cursus<\/a><\/noindex>.<\/li>\n<li>lezen over het ontwerp van datacenterfabrieken van Facebook, geschreven door Petr Lapukhov. <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7938\">RFC<\/a><\/noindex> De documentatie over de architectuur geeft je een idee van hoe Overlay SDN werkt,<\/li>\n<li>De documentatie over de architectuur geeft je een idee van hoe Overlay-gebaseerde SDN werkt. <noindex><a rel=\"nofollow\" href=\"https:\/\/tungstenfabric.github.io\/website\/Tungsten-Fabric-Architecture.html\">Tungsten Fabric<\/a><\/noindex> Roman Gorg\u00e9. Voor opmerkingen en correcties.<\/li>\n<\/ul>\n<h5>Bedankt<\/h5>\n<p>\nArtem Chernobai. Voor KDPV.<br \/>\nAutomatisering voor de allerkleinsten. Deel \u00e9\u00e9n (deze komt na nul). Netwerkvirtualisatie<br \/>\n<br \/>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster","description":"SDCM is afgelopen, maar het ongecontroleerde verlangen om te schrijven is gebleven.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/35972","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=35972"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/35972\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/26891"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=35972"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=35972"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=35972"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}