Hvorfor ikke bruke sentralisert administrasjon av patcher?
I siste avsnitt, jeg nevnte at sentralisert administrasjon av patcher kan være en dårlig idé i store organisasjoner eller organisasjoner som er geografisk spredt. Jeg ønsker å starte med å forklare hvorfor dette er tilfelle. I store organisasjoner er det bare et spørsmål om tilbud og etterspørsel. En enkelt patch management server sannsynligvis ikke kommer til å være i stand til å holde tritt med kravene til et stort, enterprise-klassen nettverk.

For eksempel, tenk at Microsoft utgir en ny sikkerhetsoppdateringen som er 1 MB . Hvis det er 5000 arbeidsstasjoner i nettverket, så din patch management server er nødt til å overføre ca 5 GB med data bare for å sende ut dette en MB lapp til alle klientene (faktisk, ville det være mye mer data enn det på grunn av overhead i godkjennings og patching prosesser). Selv om du ikke har noe imot å ha en enkelt server sender ut 5 GB verdt av plastre samtidig, må du vurdere hva konsekvensene ville være om distribusjon av en 200 MB (service pack en terabyte med data plutselig flom nettverket).

Selv om du ikke er opptatt av volumet av trafikk som en enkelt patch management server ville måtte forholde seg til på et stort nettverk (du bør være), må du vurdere hvor mye tid det ville ta en enkelt server å lappe alle disse arbeidsstasjoner. Selv en rask server kommer til å ta en stund å lappe 5000 arbeidsstasjoner grunn av båndbreddebegrensninger og på grunn av ineffektivitet i arbeidsstasjonene selv. Å være at så mange av de oppdateringene som Microsoft utgivelser er kritiske sikkerhetsoppdateringer, er det viktig å være i stand til å bruke oppdateringer raskt.

OK, vanligvis er så en sentralisert patch management server ikke en god idé for store nettverk, så hva er alternativet? I en stor organisasjon, er det vanligvis en bedre idé å desentralisere patch management. Tanken er at du fortsatt har en sentral patch management server, men denne serveren sender aldri patcher direkte til arbeidsstasjonene. I stedet virker det som en mester patch management server og sender lapper til underordnede patch management servere. Dette tillater deg å ha en egen patch management server for hver større avdeling.

For å se hvordan dette fungerer, la oss gå tilbake til min tidligere eksempel på den organisasjonen som har 5000 arbeidsstasjoner som må lappes. Snarere enn å ha en enkelt server patch alle 5000 arbeidsstasjoner, la oss late som organisasjonen har installert en mester patch management server og fem underordnede patch management servere som hver tjeneste ca 1000 brukere.

Når en MB patch som jeg brukte i min tidligere eksempel må brukes, er det samme omtrentlige trafikkvolumet fremdeles blir plassert på nettverket. Tross alt er det fortsatt det samme antall arbeidsstasjoner som får lappen og det er litt mer indirekte enn før. Forskjellen ligger i måten at trafikken blir fordelt. For det første, vil du ikke ha en enkelt server sende ut 5 GB data. I stedet, hver av de underordnede serverne skal sende ut en mye mer håndterlig 1 GB data hver. Enda viktigere skjønt, kan disse underordnede servere plasseres i samme subnett som kundene at de tjenesteleverandører. På den måten har de fleste av nettverkstrafikken som er relatert til lappen styringsprosessen vil bli isolert til en enkelt delnett i stedet for å strømme over hele nettverket. Sluttresultatet er at trafikken vil ha mye mindre innvirkning på nettverket som helhet.

Ved hjelp av fem underordnede servere for å distribuere patcher heller enn å bruke en enkelt sentral server kan også patcher som skal distribueres raskere. Alle fem servere kan arbeide samtidig og forutsatt at alle ting er like, kan patching prosessen være ferdig omtrent fem ganger raskere enn det kunne hvis bare en enkelt patch management server var i bruk.

Wide område nettverk
nå som jeg har diskutert noen grunner til at sentralisert administrasjon av patcher som regel ikke er så lurt for store nettverk, jeg ønsker å diskutere noen grunner til hvorfor det er heller ikke en veldig god passform for geografisk spredte nettverk. Mange av de samme prinsippene som jeg allerede har diskutert i forhold til store nettverk pleier også å gjelde for geografisk spredt nettverk siden de ofte også en tendens til å være store. Men sentralisert administrasjon av patcher tendens til å forårsake problemer for geografisk spredte nettverk uavhengig av størrelse. Som nettverk størrelse økning, gjør problemer har en tendens til å forstørres om

For å se hvorfor sentralisert administrasjon av patcher er problematisk selv for små geografisk spredte nettverk, la oss late som det er et selskap som har to kontorer.; en i Miami, Florida og den andre i Las Vegas, Nevada (hvorfor ikke bruke morsomme steder). Siden det er et par tusen miles mellom de to kontorene, har selskapet valgt å bruke en leid linje for å koble de to anleggene. Selskapet er liten, med 25 ansatte på hvert kontor. På grunn av selskapets liten størrelse og på grunn av budsjettbegrensninger, er selskapet ved hjelp av en T-1 linje for WAN-tilkobling, som har en gjennomstrømning på 1,544 Mbps.

OK, så hva er problemet med et selskap som dette ved hjelp av sentralisert patch management? La oss late som at selskapet har en patch management server i Las Vegas kontoret, men ikke i Miami kontoret. Nå, la oss late som Microsoft utgir en 1 MB sikkerhetsoppdatering som skal distribueres til alle arbeidsstasjoner. Den patch management server laster ned oppdateringen, og det distribuerer oppdateringen til alle arbeidsstasjonene i Las Vegas uten problem. Den patch management server så begynner å distribuere oppdateringen til arbeidsstasjoner i Miami. Problemet er at det er 25 arbeidsstasjoner i Miami. Den patch management server har til å sende samme 1 MB lapp over den langsomme WAN-kobling tjuefem ganger. Dette betyr at den langsomme koblingen blir overbelastet med 25 MB trafikk. Inntil alle lappene har blitt sendt, kan annen kommunikasjon mellom de to kontorene alvor bli hemmet.

Hvis dette var en ekte liv nettverk, ville jeg sannsynligvis plassere en uavhengig patch management server i hvert kontor. På den måten patcher aldri må sendes over WAN-kobling siden koblingshastigheten er så treg. Hvis WAN koblingen var raskere, eller hvis sentralisert administrativ kontroll var viktig, så serveren i Miami kan settes opp som en underordnet server i Las Vegas. På den måten vil serveren i Las Vegas laste ned oppdateringer og distribuere dem til arbeidsstasjonene i Las Vegas. Det ville også sende en kopi av hver patch til serveren i Miami, som i sin tur distribuere patcher til Miami baserte arbeidsstasjoner.

Konklusjon
I denne artikkelen har jeg forklart at selv om sentralisert patch Ledelsen har vunnet popularitet nylig, er det noen ganger upraktisk. Jeg forklarte noen grunner til at sentralisert patch management er ofte ineffektive i store eller geografisk spredte nettverk. Jeg fortsatte med å diskutere noen alternative ordninger

Om Brien M. Posey. Brien Posey er en prisbelønt forfatter som har skrevet over 3000 artikler og skrevet eller bidratt til 27 bøker. Du kan besøke Brien personlige hjemmeside på www.brienposey.com

WindowsNetworking.com inneholder et vell av nettverksinformasjon for administratorer: Med informasjon om hvordan du kan sette opp og feilsøke ulike nettverk i alle størrelser. Inkluderer også et omfattende arkiv av hundrevis av anmeldt nettverk programvare og maskinvareløsninger. Ofte oppdatert med artikler og tips av et team av ledende forfattere, det er fortsatt en favoritt innenfor nettverk samfunnet.