Hvordan oppdatere nettverksutstyr i en stor bedrift uten å stoppe produksjonen? Han snakker om et storstilt prosjekt i «åpen hjertekirurgi»-modus Linxdatacenter prosjektleder Oleg Fedorov.
I løpet av de siste årene har vi merket økt kundeetterspørsel etter tjenester knyttet til nettverkskomponenten i IT-infrastrukturen. Behovet for tilkobling av IT-systemer, tjenester, applikasjoner, overvåking og operasjonelle virksomhetsstyringsoppgaver i nesten alle områder tvinger bedrifter i dag til å være mer oppmerksomme på nettverk.
Utvalget av forespørsler spenner fra å sikre nettverksfeiltoleranse til å opprette og administrere et autonomt klientsystem med å kjøpe en blokk med IP-adresser, sette opp rutingprotokoller og administrere trafikk i samsvar med organisasjonens retningslinjer.
Det er også en økende etterspørsel etter omfattende løsninger for bygging og vedlikehold av nettverksinfrastruktur, først og fremst fra kunder hvis nettverksinfrastruktur blir opprettet fra bunnen av eller er foreldet, som krever alvorlige modifikasjoner.
Denne trenden falt sammen med utviklingsperioden og kompleksiteten til Linxdatacenters egen nettverksinfrastruktur. Vi utvidet geografien til vår tilstedeværelse i Europa ved å koble til eksterne nettsteder, noe som igjen krevde forbedring av nettverksinfrastrukturen.
Selskapet har lansert en ny tjeneste for klienter, Network-as-a-Service: vi tar oss av alle klienters nettverksproblemer, slik at de kan fokusere på sin kjernevirksomhet.
Sommeren 2020 ble det første store prosjektet i denne retningen fullført, som jeg gjerne vil snakke om.
I begynnelsen
Et stort industrikompleks henvendte seg til oss for å modernisere nettverksdelen av infrastrukturen ved en av bedriftene. Det var nødvendig å erstatte gammelt utstyr med nytt utstyr, inkludert nettverkskjernen.
Den siste moderniseringen av utstyret ved bedriften fant sted for omtrent 10 år siden. Den nye ledelsen i bedriften bestemte seg for å forbedre tilkoblingen, og startet med å oppdatere infrastrukturen på det mest grunnleggende, fysiske nivået.
Prosjektet ble delt i to deler: oppgradering av serverparken og nettverksutstyr. Vi var ansvarlige for den andre delen.
Grunnleggende krav til arbeidet inkluderte å minimere nedetid på bedriftens produksjonslinjer under utførelse av arbeid (og i noen områder fullstendig eliminering av nedetid). Ethvert stans betyr direkte økonomiske tap for klienten, som ikke under noen omstendigheter burde ha skjedd. På grunn av anleggets driftsmodus 24x7x365, samt å ta i betraktning det fullstendige fraværet av perioder med planlagt nedetid i virksomhetens praksis, fikk vi i oppgave å utføre i hovedsak åpen hjertekirurgi. Dette ble det viktigste kjennetegnet ved prosjektet.
Gå
Arbeidet ble planlagt i henhold til prinsippet om bevegelse fra nettverksnoder fjernt fra kjernen til nærmere, så vel som fra de som i mindre grad påvirker arbeidet til produksjonslinjer til de som direkte påvirker dette arbeidet.
Hvis vi for eksempel tar en nettverksnode i salgsavdelingen, vil ikke et kommunikasjonsavbrudd som følge av arbeid i denne avdelingen påvirke produksjonen på noen måte. Samtidig vil en slik hendelse hjelpe oss som entreprenør å kontrollere riktigheten av den valgte tilnærmingen til arbeid på slike enheter og, etter justering av handlingene, arbeide med de neste stadiene av prosjektet.
Det er nødvendig ikke bare å erstatte noder og ledninger i nettverket, men også å konfigurere alle komponenter riktig for riktig drift av løsningen som helhet. Det var konfigurasjonene som ble testet på denne måten: Ved å starte arbeidet vekk fra kjernen, så vi ut til å gi oss selv "retten til å gjøre feil" uten å sette risikoområder som er kritiske for driften av virksomheten.
Vi identifiserte områder som ikke påvirker produksjonsprosessen, samt kritiske områder - verksteder, laste- og losseenhet, varehus osv. På nøkkelområder ble akseptabel nedetid for hver nettverksnode separat avtalt med oppdragsgiver: fra 1 til 15 minutter. Det var umulig å helt unngå å koble fra individuelle nettverksnoder, siden kabelen fysisk må byttes fra gammelt utstyr til nytt, og under bytteprosessen er det også nødvendig å løse "skjegget" av ledninger som ble dannet i flere års drift uten riktig omsorg (en av konsekvensene av å sette ut arbeid for installasjon av kabellinjer).
Arbeidet var delt inn i flere etapper.
Stage 1 – Revisjon. Utarbeidelse og koordinering av tilnærmingen til arbeidsplanlegging og vurdering av beredskapen til teamene: byggherren, installasjonsentreprenøren og vårt team.
Stage 2 – Utvikling av format for gjennomføring av arbeid, med dyp detaljanalyse og planlegging. Vi valgte et sjekklisteformat med en presis indikasjon på rekkefølgen og rekkefølgen av handlinger, helt ned til rekkefølgen for å bytte patchledninger etter port.
Stage 3 – Utføre arbeid i skap som ikke påvirker produksjonen. Estimering og justering av nedetid for etterfølgende arbeidsledd.
Stage 4 – Utføre arbeid i skap som direkte påvirker produksjonen. Estimering og justering av nedetid for sluttfasen av arbeidet.
Stage 5 – Utføre arbeid i serverrommet for å bytte gjenværende utstyr. Start på ruting på den nye kjernen.
Stage 6 – Konsekutiv veksling av systemkjernen fra gamle nettverkskonfigurasjoner til nye for en jevn overgang av hele systemkomplekset (VLAN, ruting, etc.). På dette stadiet koblet vi til alle brukere og overførte alle tjenester til den nye maskinvaren, verifiserte at tilkoblingen var riktig, sørget for at ingen av bedriftstjenestene ble stoppet, sørget for at hvis det skulle oppstå problemer, ville de kobles direkte til kjernen, som gjorde det lettere å feilsøke mulige problemer og endelig oppsett.
Trådskjeggfrisyre
Prosjektet viste seg å være vanskelig også på grunn av de vanskelige startforholdene.
For det første er det et stort antall noder og deler av nettverket, med en intrikat topologi og klassifisering av ledninger i henhold til deres formål. Slike "skjegg" måtte tas ut av skapene og møysommelig "kjemmes", for å finne ut hvilken ledning som kom fra hvor og hvor den førte.
Det så omtrent slik ut:
som følger:
eller så:
For det andre, for hver slik oppgave var det nødvendig å utarbeide en fil som beskriver prosessen. "Vi tar ledningen X fra port 1 på det gamle utstyret, plugger den inn i port 18 på det nye utstyret." Det høres enkelt ut, men når du har 48 fullstendig tilstoppede porter i kildedataene dine, og det ikke er noe nedetidsalternativ (vi husker ca. 24x7x365), er den eneste utveien å jobbe i blokker. Jo flere ledninger du kan trekke ut av gammelt utstyr på en gang, jo raskere kan du gre dem og sette dem inn i ny nettverksmaskinvare, slik at du unngår feil og nedetid i nettverket.
Derfor, på det forberedende stadiet, delte vi nettverket i blokker - hver av dem tilhørte et spesifikt VLAN. Hver port (eller en undergruppe av dem) på gammelt utstyr er en av VLAN-ene i den nye nettverkstopologien. Vi grupperte dem slik: de første portene til svitsjen inneholdt brukernettverk, den midterste – produksjonsnettverk, og den siste – tilgangspunkter og oppkoblinger.
Denne tilnærmingen gjorde det mulig å trekke ut og gre fra gammelt utstyr ikke bare 1 ledning, men 10-15, på en gang. Dette satte fart i arbeidsprosessen flere ganger.
Slik ser forresten ledningene i skapene ut etter kjemming:
eller for eksempel slik:
Etter å ha fullført 2. trinn tok vi en pause for å analysere feil og prosjektdynamikk. For eksempel dukket det opp små defekter umiddelbart på grunn av unøyaktigheter i nettverksdiagrammene som ble gitt til oss (feil kontakt på diagrammet betyr feil kjøpt patchledning og behovet for å erstatte den).
Pausen var nødvendig, siden når du jobbet fra serversiden, var selv en liten feil i prosessen uakseptabel. Hvis målet var å sikre nedetid på en nettverksdel på ikke mer enn 5 minutter, så kunne den ikke overskrides. Eventuelle avvik fra tidsplanen måtte avtales med oppdragsgiver.
Forhåndsplanlegging og oppdeling av prosjektet i blokker gjorde det imidlertid mulig å møte den planlagte nedetiden på alle områder, og i de fleste tilfeller unngå den helt.
Tidenes utfordring - et prosjekt under COVID
Det var imidlertid ikke uten ekstra vanskeligheter. Selvfølgelig var koronaviruset en av hindringene.
Arbeidet ble komplisert av det faktum at pandemien startet, og det var umulig for alle spesialister som var involvert i prosessen å være tilstede under arbeidet på klientens sted. Kun ansatte i installasjonsorganisasjonen fikk komme inn på stedet, og kontroll ble utført gjennom et Zoom-rom - i det var det en nettverksingeniør fra Linxdatacenter, meg selv som prosjektleder, en nettverksingeniør fra klienten som var ansvarlig for arbeidet, og et team som utfører installasjonsarbeid.
Det oppsto uforklarlige problemer under arbeidet, og justeringer måtte gjøres i farten. På denne måten var det mulig å raskt forhindre påvirkning av den menneskelige faktoren (feil i kretsen, feil ved fastsettelse av status for grensesnittaktivitet, etc.).
Selv om fjernarbeidsformatet virket uvanlig i begynnelsen av prosjektet, tilpasset vi oss raskt de nye forholdene og nådde sluttfasen av arbeidet.
Vi har lansert en midlertidig konfigurasjon av nettverksinnstillinger for å la to nettverkskjerner – gamle og nye – kjøre parallelt for å oppnå en jevn overgang. Det viste seg imidlertid at en ekstra linje ikke ble fjernet fra konfigurasjonsfilen til den nye kjernen, og overgangen skjedde ikke. Dette tvang oss til å bruke litt tid på å lete etter problemet.
Det viste seg at hovedtrafikken ble overført riktig, og kontrolltrafikken nådde ikke frem til noden gjennom den nye kjernen. Takket være den klare inndelingen av prosjektet i etapper, var det mulig å raskt identifisere den delen av nettverket der problemet oppsto, identifisere problemet og fikse det.
Og som et resultat
Tekniske resultater av prosjektet
Først og fremst ble det opprettet en ny kjerne i det nye bedriftsnettverket, som vi bygget fysiske/logiske ringer for. Dette gjøres på en slik måte at hver svitsj i nettverket har en "andre arm". I det gamle nettet var mange brytere koblet til kjernen langs én rute, én arm (uplink). Hvis den gikk i stykker, ble bryteren helt utilgjengelig. Og hvis flere brytere var koblet sammen gjennom én opplink, ville ulykken deaktivere en hel avdeling eller produksjonslinje ved bedriften.
I et nytt nettverk vil ikke selv en ganske alvorlig nettverkshendelse under noe scenario kunne ødelegge hele nettverket eller en vesentlig del av det.
90 % av alt nettverksutstyr er oppdatert, mediekonvertere (signalutbredelsesmedieomformere) er tatt ut av drift, og behovet for dedikerte kraftledninger for strømforsyning av utstyr er eliminert ved å koble til PoE-svitsjer, hvor strøm tilføres via Ethernet-ledninger.
Dessuten er alle optiske forbindelser i serverrommet og i feltskap merket - ved alle sentrale kommunikasjonsnoder. Dette gjorde det mulig å utarbeide et topologisk diagram over utstyr og forbindelser i nettverket, som gjenspeiler dets faktiske tilstand i dag.
Nettverksdiagram
Det viktigste resultatet i tekniske termer: ganske storskala infrastrukturarbeid ble utført raskt, uten å skape noen innblanding i bedriftens arbeid og nesten ubemerket av dets personell.
Forretningsresultater av prosjektet
Etter min mening er dette prosjektet interessant først og fremst ikke fra den tekniske, men fra den organisatoriske siden. Vanskeligheten lå først og fremst i å planlegge og tenke gjennom trinnene for å implementere prosjektoppgaver.
Suksessen til prosjektet lar oss si at vårt initiativ for å utvikle nettverksområdet innenfor Linxdatacenter-tjenesteporteføljen er det riktige valget for selskapets utviklingsvektor. En ansvarlig tilnærming til prosjektledelse, en kompetent strategi og tydelig planlegging gjorde at vi kunne fullføre arbeidet på riktig nivå.
Bekreftelse av kvaliteten på arbeidet er en forespørsel fra klienten om å fortsette å tilby tjenester for nettverksmodernisering på de gjenværende stedene i Russland.
Kilde: www.habr.com