Det är dags att gå in på djupet i hur Cisco NSO faktiskt fungerar och hur det kan implementeras i ett redan existerande företag med system och processer. Som erfarna Cisco NSO-konsulter hjälper vi företag att förstå hur NSO kan passa in och hjälpa företag att hantera sitt nätverk. Denna första del fokuserar på de tekniska grunderna för Cisco NSO och förklarar de tre huvudkomponenterna: Service Manager, Device Manager och Network Element Drivers (NED). Men låt oss börja med en teknisk översyn av Cisco NSO.
Översikt av Cisco NSO
Cisco NSO består av tre lager som samverkar för att stödja avancerad nätverksautomation: Service Manager, Device Manager och NEDs. Dessa är tätt sammankopplade via konfigurationsdatabasen (CDB) som hanterar och lagrar nätverksdata. Nedan följer en överblick av systemet och dess komponenter, där vi går igenom varje del och deras roll i nätverksautomatiseringen.
Om vi börjar nerifrån och går uppåt är det enklare att förstå vad som händer i varje lager.
Network Element Drivers
En Network Element driver är som en drivrutin för NSO att tala med nätverksutrustning, det finns redan idag NEDs för över 1000 olika typer av utrustningar, självklart det mesta som Cisco säljer såsom NX-OS och IOS-XR men även andra leverantörer som Junipers JunOS, Arista EOS och Fortigate FortiOS för att nämna några. En NEDs huvudsakliga funktion är att översätta mellan utrustningens egna språk, exempelvis CLI eller REST API, och det standardiserade NETCONF/YANG-formatet som Cisco NSO använder internt, vi kommer gå in mer på NETCONF/YANG i ett kommande avsnitt.
Skulle det saknas en NED för en specifik typ av utrustning, går det att be Cisco att utveckla en NED. Om utrustningen redan talar NETCONF/YANG korrekt kan en NED till och med genereras automatiskt med de verktyg som följer med Cisco NSO. Detta gör att Cisco NSO kan integreras med nästan all tänkbar nätverksutrustning, och våra Cisco NSO-konsulter kan hjälpa dig att ta fram rätt lösningar för just din miljö.
Device Manager
Device Manager tar in all information som varje NED (Network Element Driver) hämtar från nätverksutrustningen, inklusive detaljer som vilken typ av utrustning det handlar om, vilken version av operativsystemet (t.ex. JunOS) som körs och så vidare. Denna information lagras sedanav Cisco NSO i CDB-databasen.
CDB (Configuration DataBase) är en specialdesignad databas för att hantera YANG-strukturerad data. Men Device Manager kan göra betydligt mer än bara datalagring. Eftersom den ansvarar för att hantera alla uppdateringar i CDB, kan Device Manager även automatiskt kontrollera om utrustningen är synkroniserad med Cisco NSO. Dessutom kan enheter låsas för att förhindra oönskade ändringar, till exempel under ett planerat arbete eller när utrustningen har problem.
Utöver detta kan Device Manager automatiskt skapa och konfigurera ny utrustning när den läggs till i Cisco NSO. Ett exempel på detta är att när en ny Arista EOS-enhet läggs till kan Device Manager ha en fördefinierad regel som automatiskt applicerar en standardkonfiguration på den nya utrustningen Detta sparar tid och säkerställer att varje ny enhet följer företagets riktlinjer och krav. Vi kommer även gå in djupare på tjänster och konfigurationshantering i ett senare avsnitt.
Device Manager kan också ta emot och hantera larm från nätverksutrustningen, beroende på vilket stöd som finns i den NED som används. Dessa larm kan sedan antingen vidarebefordras för manuell hantering eller automatiskt trigga åtgärder i Cisco NSO, såsom att köra specifika kommandon eller applicera/ta bort konfigurationer. Detta gör Cisco NSO till ett kraftfullt verktyg för nätverksautomation, och våra erfarna Cisco NSO-konsulter kan hjälpa ditt företag att fullt ut utnyttja dessa möjligheter.
Service Manager
Service Manager liknar Device Manager, men istället för att hantera information om enskilda nätverksenheter, hanterar den information om de tjänster som de olika ”beställarna” ovanpå Cisco NSO behöver. I sin enklaste form kan man använda Service Manager för att hantera utrustning via CLI, men då har man egentligen inte automatiserat något – man har bara flyttat platsen där kommandon matas in, från varje enskild enhet till Cisco NSO's gemensamma interface.
Det som gör Service Manager kraftfullt är dess förmåga att ta en bredare vy av nätverket. Istället för att konfigurera en enhet i taget, kan man med hjälp av servicemodeller specificera att en tjänst omfattar flera nätverksenheter, till exempel några portar på en Cisco-router, en HP-switch och specifika portar i en Fortigate-brandvägg. Tjänsten skapas sedan som en helhet eller inte alls – precis som med Device Manager använder Service Manager NETCONF/YANG för att kommunicera med CDB och hanterar skapandet av tjänster som en transaktion Om denna transaktion inte går att utföra så tas all konfiguration bort, inte bara för den utrustning där felet uppstod.
När en servicemodell i Service Manager uppdateras, till exempel genom att justera bandbredden som tjänsten erbjuder, sparas denna uppdatering automatiskt i CDB. Detta innebär att andra system och användare som interagerar med Cisco NSO, som exempelvis ett inventariesystem via REST API, ser den senaste uppdateringen i realtid.
Service Modeller
Nu när vi har en bättre förståelse för hur Cisco NSO fungerar är det dags att adressera en av de största frågorna vid implementeringen av Cisco NSO: service modeller. En servicemodell definierar vilka parametrar en tjänst har, som exempelvis hur mycket bandbredd tjänsten ska leverera, samt vilka resurser i nätverket tjänsten förbrukar.
Genom att ha en tydlig bild av dessa parametrar kan man besvara viktiga frågor såsom:
Om en viss nätverksenhet går sönder, vilka tjänster påverkas och hur? Finns det redundans som kan ta över?
Vid planerat arbete på en enhet, vilka interna och externa kunder påverkas och hur? Har dessa tjänster redundans eller riskerar de avbrott?
Vad kostar det att leverera denna tjänst, exempelvis så är optiska moduler en stor del av kraft budgeten i modern utrustning, hur mycket av elkostnaden för denna utrustning står denna tjänst för och i förlängningen då även exempelvis EU ETS rapporter.
Finns det tillräcklig kapacitet i nätverket för att leverera denna tjänst där den behövs? Eller måste vi först bygga ut nätverket för att klara kraven?
Vid införandet av Cisco NSO är den första frågan ofta om företaget har etablerade servicemodeller för sina tjänster. Och om de finns – hur är de dokumenterade och hanterade? Det är viktigt att skilja mellan service modeller och inventariemodeller. Båda kan hanteras av samma system men fyller olika roller. En inventariemodell svarar på frågor som:
→ Hur många exemplar av en viss utrustning har vi? Vad har de kostat och när blir de avskrivna?
→ Var är utrustningen placerad, ner till våning, rum och rack? Vilken portkod behövs för att komma in, och kräver teknikerna ledsagning på platsen?
→ Hur många av dessa enheter används just nu, och till vad? Finns det enheter på lager som kan användas som reservdelar, och var är de?
→ Vad är serienumret? Vilka supportavtal gäller och när går de ut?
Ett sätt att illustrera skillnaden mellan en service modell och en inventariemodell är att tänka på vad som händer när en enhet havererar och byts ut mot en likadan. Servicemodellen förblir densamma – noden i servicegrafen behåller sitt namn och parametrar dåden nya enheten får exakt samma konfiguration som den gamla som den ersätter. Däremot uppdateras inventariemodellen med den nya enhetens serienummer och det faktum att en reservdel har förbrukats och måste ersättas.
Tyvärr är servicemodeller ofta en eftersatt del av nätverksinfrastrukturen, särskilt i traditionella on-prem-lösningar. Molntjänster som AWS och Azure tvingar sina användare att uttryckligen skapa och sedan binda resurser till tjänster, vilket gör att servicemodellerna alltid finns från dag ett.. I on-prem nätverk tenderar dock processerna att vara mer informella, vilket fungerar tills nätet blir för stort och komplext för att hanteras på det sättet. Detta är en unik utmaning för varje företag, men med hjälp av erfarna Cisco NSO-konsulter kan du börja skapa och hantera effektiva servicemodeller som passar ditt företags behov.
Behöver du hjälp med Cisco NSO?
Om ditt företag står inför utmaningar med nätverksautomation eller funderar på att implementera Cisco NSO, kan våra Cisco NSO-konsulter hjälpa dig genom hela processen. Oavsett om det handlar om att skapa service- och inventariemodeller, optimera nätverksautomation eller långsiktigt stöd, har vi den expertis du behöver. Med vår hjälp kan ditt företag maximera fördelarna med Cisco NSO, minska driftskostnader och öka effektiviteten. Kontakta oss idag för att se hur vi kan stötta dig i att lyckas med Cisco NSO!
Comments