Kunden var en mellemstor dansk internetudbyder der drev et netværk med mere end 200 servere og 1500 individuelle installationer rundt omkring i Nordeuropa.
Vi assisterede kunden med at opbygge et såkaldt Network Operation Center, en enhed i organisationen der foretager automatisk overvågning og response på virksomhedens driftssituation.
Rent praktisk udmønter det sig i en række overvågningssystemer der løbende tester samtlige services på samtlige enheder i netværket, ligesom netværket i sig selv også overvåges. Resultaterne heraf præsenteres på en række skærme i et lokale på virksomhedens adresse, hvor virksomheden opretholder et døgnbemandet “Emergency Response Team“.
Vores opgave var at konfigurere selve driftsovervågningen, til det formål brugte vi det anerkendte Open Source-produkt Nagios, som håndterede flere tusinde samtidige tests.
Virksomhedens lokationer bestod af et større antal af forskellige, primært egenudviklede, produkter hvorfor det var nødvendigt at skrive specialtilpassede test-programmer til disse, hvilket også var en af vores opgaver.
Vi opsatte først Nagios hvis formål var at sikre sig et aktuelt overblik over den aktuelle tilstand på de overvågede services. Derudover opsatte vi Zabbix og Zennos til performanceovervågning, som beskæftigede sig med hvor godt de enkelte systemer virker og måler således på ting som svartider, hukommelsesforbrug og generelt driftsstatus over tid.
Derudover assisterede vi med den fysiske indretning af rummet, opsætning og konfiguration af informationsskærme, ticket-system og procedurer til incident response. Nogle år senere udskiftede vi løsningen med et setup baseret på den såkaldt ELK-Stack, bestående af Elasticsearch, Logstach og Kibana der udover det allerede nævnte bl.a. også tilbyder log-managent.
For andre kunder har vi tidligere bygget driftsovervågningsløsninger baseret på andre Open Source-software såsom Ganglia, MRTG, Munin og LibreNMS – ligesom vi på nye installationer formodentlig vil foretrække Incinga fremfor Nagios.
For en anden kunde, en mere klassisk hostingvirksomhed, assisterede vi over en årrække med en lang række udviklings- og driftsopgaver. Vi byggede blandt andet et Autoritativt DNS-cluster til kunden, med et webinterface hvor slutbrugeren kan administrere sine egne DNS-indstillinger.
Denne løsning var bygget med PHP, MySQL, ICS BIND, af nævneværdige features var blandt andet Two Factor Authentification med Time-based One-time Passwords (TOTP), signerede records med DNSSEC og et REST API til automatisk ændring af records til brug for automatiseret failover i forbindelse med redundante systemer.
Samtidig byggede vi en bestillingsløsning der tillod kunderne at købe både nationale og internationale domæner, direkte fra virksomhedens hjemmeside, som automatisk blev sat op med DNS, Mail og webhotel.
Sidst men ikke mindst byggede vi en central, redundant, firewall løsning med multibrugeradgang og REST API. Løsningen var baseret på to fysiske servere der kørte Linux, begge maskiner havde to netværksporte der var sat op i bridge mode, switchen foran og bagved disse maskiner kørte Rapid Spanning Tree Protocol (RSTP). Løsningen blev brugt til at beskytte virksomhedens kundeservere mod angreb udefra, men samtidig give den enkelte kunde adgang til at åbne op for trafik til egne servere efter behov.
En tredie virksomhed kontaktede os for at søge assistance til at opbygge en internetudbyder fra bunden, de havde et koncept og første kunde i hus. Virksomheden ville udbyde reklame-finansieret WiFi til byområder, ideen var at sælge lokationsbaserede reklamer der ville blive indsat i brugernes datastream og dermed vist når brugeren besøgte internettet.
Vi assisterede med at allokere MPLS-forbindelser fra det danske internet-knudepunkt DIX ved DTU i Lyngby. Her havde vi opsat udstyr der foretog adgangskontrol og filtrering, således at alt det intelligente udstyr var placeret centralt, mens de enkelte byer kun stod for selve datahåndteringen.
Systemet bestod af en captive web portal, som var det første brugeren blev mødt af når denne forbandt til netværket, herefter blev brugeren bedt om at oplyse sine personlige detaljer samt acceptere modtagelse af reklamer. Herefter ville brugerens netkort blive tildelt et andet netværk med adgang til internettet – dog filtreret af vores Dansguardian-server, der stod for injektion af reklamerne.
Virksomheden nåede kun at udbygge i én by før projektet desværre blev lukket, men vi kørte selv stresstest på hele opsætningen. Det viste sig at de centrale komponenter uden at blinke kunne håndtere 100.000 samtidige brugere med et data througput på lige omkring 1Gigabit/s, hvilket var kapaciteten på vores udgående linjer.Virksomheden nåede kun at udbygge i én by før projektet desværre blev lukket, men vi kørte selv stresstest på hele opsætningen. Det viste sig at de centrale komponenter uden at blinke kunne håndtere 100.000 samtidige brugere med et data througput på lige omkring 1Gigabit/s, hvilket var kapaciteten på vores udgående linjer.
Nagios, Incinga, Zabbix, Zennos, Elasticsearch, Logstach, Kibana, Prometheus, Ansible, Saltstack, ICS Bind, ICS DHCP, OpenDNS, Dansguardian, Ganglia, MRTG, Munin, LibreNMS, Rapid STP, Iptables.
navne er ændret eller udeladt, brancher og gruppering af opgaver kan være ændret. Men alle løsninger beskrevet i casen er nogen vi har leveret til mindst én af vores kunder.