- Võrgu pudelikael on iga punkt, mis piirab üldist jõudlust, olgu selleks küllastunud ühendus, vana kommutaator või alamõõduline virtuaalmasin.
- Nähtavuse puudumine muudab ülekoormuse tegeliku allika leidmise võimatuks; seadmete, liideste, virtuaalmasinate ja rakenduste jälgimine on võtmetähtsusega.
- Jälgimisvahendid ja head disainitavad (10G magistraalvõrkudes, QoS, vahemällu salvestamine, koormuse tasakaalustamine) võimaldavad neid kitsaskohti ennetada ja leevendada.
- Riistvara täiustuste kombineerimine koodi optimeerimise, andmebaaside ja võrgupoliitikatega tagab stabiilsema ja kiirema võrgu.
Igas võrguühendusega ettevõttes, alates väikesest kontorist kuni suurkorporatsioonini, on võrgu kitsaskohad üks neist vaikivatest probleemidest , mis raiskavad aega, tootlikkust ja kannatust . Kõik näib olevat korras: pakkuja lubab 1 Gbps, WiFi "töötab hästi" ja seadmed pole eriti vanad. Kuid allalaadimised võtavad igavesti aega, jagatud failide avamine on aeglane ja videokõned on katkendlikud.
Tavaliselt on see märk sellest, et mingil hetkel on võrk kitsam kui teie liiklusvajadused . Nii nagu maanteel, mis kitseneb ühe sõidurajani, on andmed sunnitud "järjekorda ootama". Selles artiklis vaatleme lähemalt, mis on võrgu kitsaskohad, kust need tulevad, kuidas neid objektiivsete andmete abil tuvastada ja mida saate teha nende kõrvaldamiseks või vähemalt professionaalse kontrolli all hoidmiseks.
Mis täpselt on võrgu pudelikael?
Võrgu kitsaskohtade all peame silmas mis tahes punkti infrastruktuuris, mis piirab ülejäänud süsteemi jõudlust . See on ahela nõrgim lüli: pole vahet, kas teil on 10G lülitid, võimsad serverid või sümmeetrilised fiiberoptilised ühendused, kui üks võrgusegment ei suuda töödelda kogu vastuvõetud liiklust.
Kujutage ette, et teie võrk on teedevõrk: seadmed on autod, kaablid ja lülitid on sõidurajad ning ribalaius on saadaolevate sõiduradade arv . Kui võtmelõigul on ainult üks sõidurada ja kogu liiklus peab sellest läbi minema, tekib liiklusummik isegi siis, kui ülejäänud teed on suured maanteed. Täpselt see juhtub võrgus, kui port, link või seade saavutab oma võimsuse.
Pudelikael võib ilmneda paljudes erinevates kohtades: internetiühenduses, kommutaatorite vahelises magistraalvõrgus, alavõimsusega NAS-serveris või isegi alamõõdulises virtuaalmasinas . Oluline on mõista, et kogu süsteem töötab ainult nii kiiresti kui selle otsast-otsa võrgu kõige aeglasem komponent.
Ärivõrgustike kitsaskohtade tüüpilised põhjused
Enamik ettevõtete võrgu jõudlusprobleeme on korduvad. Nende mustrite tuvastamine aitab teil probleemi varem diagnoosida ja investeerida täpselt sinna, kuhu vaja , ilma et peaksite pimesi sekkuma või kulutama raha riistvarale, mis midagi ei lahenda.
Üks levinumaid põhjuseid on ebapiisav ribalaius võtmeühendustel või magistraalvõrkudel . Näiteks kui üks gigabiti kaabel toidab kommutaatorit, millega on ühendatud kümned kasutajad. Tippkasutuse ajal jagatakse seda 1 Gbps porti kõigi nende vahel ja kuigi iga tööjaam saab oma kommutaatoriga läbi rääkida 1 Gbps, konkureerivad nad praktikas sama ribalaiuse pärast.
Teine levinud põhjus on aegunud või ebapiisavalt toimivad võrguseadmed : kontorikeskkonnas töötavad kodused ruuterid , ebapiisava lülitusvõimsusega kommutaatorid või WiFi-pääsupunktid, mis ei suuda samaaegselt paljude klientidega ühendust luua. Isegi kui pordi teoreetiline kiirus on 1 Gbps, võib selle sisemine elektroonika saada pudelikaelaks.
Samuti ei tohiks unustada valesid või halvasti optimeeritud konfiguratsioone . Halvasti konfigureeritud VLAN-id, kohandamata QoS, valesti konfigureeritud ulatuv puu, lingid, mida ei koondata siis, kui peaks... Kõik see võib põhjustada tsükleid, liigset järjekorda võtmist või lihtsalt saadaoleva ribalaiuse ebaefektiivset kasutamist, luues ilma nähtava põhjuseta aeglase võrgu mulje.
Paljud ettevõtted seisavad silmitsi ka olulise probleemiga: rakenduste või teenuste kontrollimatu kasutamine, mis tarbib palju võrguressursse . Täielikud varukoopiad tipptundidel, massilised sünkroonimised, suurte failide allalaadimine kasutajate poolt või samaaegsed HD-videokõned võivad ühenduse kergesti üle koormata, kui puuduvad teenuse kvaliteedi poliitikad või planeerimine.
Traadita võrkude puhul lisavad häired ja WiFi loomupärased piirangud veel ühe keerukusastme. Teiste võrkude signaalid, paksud seinad, halvasti paigutatud seadmed või ülekoormatud kanalid võivad drastiliselt vähendada kasutatavat ribalaiust, tekitades kitsaskohti, millel pole mingit pistmist internetikiirusega, mille eest maksate.
Klassikaline juhtum: kahe korruse ühendamine ühe gigabiti kaabliga
Kontorites on väga levinud stsenaarium järgmine: esimesel korrusel on pealüliti (A), mis on ühendatud internetiruuteriga, ja teisel korrusel on teine lüliti (B), mis on ühendatud ühe CAT6 Etherneti kaabliga . Sellel teisel korrusel võib töötada 10, 15 või enam kasutajat, kes kõik on ühendatud lülitiga B.
Teoreetiliselt on igal neist tööjaamadest gigabiti port kommutaatoriga, kuid kogu nende kasutajate liiklus interneti või kommutaatoriga A ühendatud serverite suunas läbib ühte 1 Gbps ühendust A ja B vahel. Kui 17 inimest avavad ja salvestavad SharePointis suuri faile, teevad varukoopiaid või peavad videokõnesid, muutub see ühendus väga reaalseks pudelikaelaks.
Praktikas juhtub see, et iga kasutaja efektiivne läbilaskevõime väheneb samaaegsuse suurenedes . Vaiksetel aegadel on võrk välkkiire, kuid kui kõik töötavad samaaegselt suurte failidega (näiteks üle 30 MB suurused Exceli arvutustabelid, mis on salvestatud pilve või kohalikku serverisse), suureneb aegluse ja ootamise tunne märkimisväärselt.
Kui mõlemal kommutaatoril on fiiberoptilised pordid (SFP/SFP+) , on palju professionaalsem lahendus kasutada neid porte magistraalühendusena. Üleminekul 1 Gbps vase kaudu 10 Gbps-le fiiberoptiliselt nihkub pudelikael: ühendus pole enam probleem ja liiklusel on palju rohkem vaba ruumi.
See lähenemisviis on sama mis 1G-võrgult hübriidsele 1G/10G-taristule üleminekul: saate hoida lõppkasutajad 1 Gbps juures, kuid teie tugivõrgud, ühendused kriitiliste serveritega ja salvestusmassiivid tuleb pudelikaelte vältimiseks viia 10G-le . See on tõhus investeerimisviis: uuendate võrgu põhivõrku ilma, et peaksite kõiki võrgukaarte kasutajaseadmetes välja vahetama.
Hübriidsed 1G/10G võrgud ja peamine kitsaskoht hüppe tegemisel
Viimastel aastatel on üha rohkem ettevõtteid oma kõige nõudlikumate serverite, salvestusruumi ja sisekommunikatsiooni jaoks üle minemas 10 gigabaidistele võrkudele . See muutus pole pelgalt mööduv trend: see vähendab latentsust, kiirendab andmeedastust ja võimaldab kriitilistel teenustel (virtualiseerimine, varundamine, ärirakendused) töötada ilma, et need oma piire ületaksid.
Probleem tekib siis, kui üleminek toimub osaliselt või juhuslikult. Kui ühendate 10G keskkonna oma vana 1G võrguga ühe gigabiti pordi kaudu, olete ühenduspunktis loonud tohutu pudelikaela . Kümme või viisteist kasutajat, kellel kõigil on 1G võrgukaart, on sunnitud jagama seda ühte gigabiti sekundis, et suhelda 10G serveri või ülikiire NAS-iga.
Mõistlik lahendus on juurutada hübriidlüliteid, mis pakuvad 1G RJ45 porte koos 10G SFP+ portidega . Nii ühenduvad NAS-server, virtualiseerimishost või failiserverid otse 10G-ga, samal ajal kui kasutajate tööjaamad jäävad 1G-sse, kuid suure võimsusega sisemise selgrooga, mis hoiab ära nende ühenduste summa põhivõrgu ülekoormamise.
Hästi läbimõeldud arhitektuuris suudab 10G-ühendusega server teenindada kõiki kasutajaid samaaegselt kiirusega umbes 80–100 MB/s tööjaama kohta , eeldusel, et salvestusruum ja protsessor on piisavad. Kitsaskohaks pole enam võrk, vaid pigem server ise või kettasüsteem.
Võrgu nähtavus: ilma andmeteta lähete pimesi sisse
Lisaks riistvarale on administraatorite jaoks üks suurimaid väljakutseid võrgus toimuva tegeliku toimimise mõistmine . Tänapäeva infrastruktuurid on sageli tohutud, hajutatud mitmesse kohta, sisaldavad erinevate tootjate seadmeid, hübriidkeskkondi nii füüsiliste kui ka virtuaalsete masinatega ning pidevalt kasvavaid uusi teenuseid.
Keskmise suurusega või suurtes võrkudes on täieliku nähtavuse saavutamine mahu ja keerukuse tõttu keeruline . Seal on palju seadmeid, arvukalt liideseid, saitidevahelisi linke, VPN-tunneleid, koormuse tasakaalustajaid ja pilveteenuseid. Ainult peamise ruuteri vaatamisest ei piisa; liikluse kitsaskohtade kindlakstegemiseks on vaja mõista kogu ökosüsteemi käitumist.
Hajutatud arhitektuuride puhul , kus kontorid asuvad eri linnades või riikides , on probleem mitmekordistunud. Igal asukohal võivad olla oma juurdepääsulingid, pakkujad ja seadmed. Ühtse jõudlusvaate saamiseks on jälgimise koordineerimine võtmetähtsusega, et vältida detailides ekslemist ja reageerida kiiresti kaugühenduse kitsaskohtadele.
Heterogeensus töötab samuti vastu: hübriidvõrgud kohalike serverite, virtuaalsete masinate, konteinerite ja pilveteenustega raskendavad küllastuse täpse allika kindlaksmääramist. Üks virtuaalmasin võib olla ülekoormatud, teisel võib puududa piisavalt ressursse ja füüsiline host võib olla täiesti korras, samas kui virtuaalmasinatel on ebapiisav protsessor, muutmälu või eraldatud ribalaius.
Skaleeritavus lisab veel ühe raskusastme. Võrgud kasvavad pidevalt: rohkem kasutajaid, rohkem SaaS-rakendusi, rohkem IoT-seadmeid, rohkem asukohti . See, mis eile hästi toimis, võib mõne kuu pärast ebaõnnestuda, kui ressursikasutust ei jälgita ja laienemisi ette ei planeerita. Pidev piirangutel töötamine on retsept kitsaskohtade ootamatuks ilmnemiseks kõige halvimal võimalikul ajal.
Lisaks kasutavad paljud organisatsioonid mitme tootja seadmeid erinevate halduskonsoolidega . Ilma jälgimislahenduseta, mis koondab kogu teabe ühte vaatesse, on väga lihtne mööda vaadata ülekoormatud lingist, vigasest pordist või seadmest, mis on juba mõnda aega ülekoormuse hoiatusi saatnud.
Kuidas nähtavus aitab vältida kitsaskohti
Kui sul puudub võrgu üle tõeline nähtavus, siis kustutad pimesi tulekahjusid : kasutajad kurdavad aeglase kiiruse üle, aga sa ei tea, kas probleem on serveris, kommutaatoris, WiFi-s või internetiühenduses. Nähtavuse parandamine on oluline, et lõpetada oletamine ja hakata tegema andmepõhiseid otsuseid.
Tugevalt virtualiseeritud keskkondades võimaldab hea jälgimistööriist reaalajas näha iga virtuaalmasina ja selle hostide protsessori, muutmälu, ketta ja võrgu tarbimist . Selle teabe abil on palju raskem teha suurusevigu, näiteks eraldada liiga palju ressursse mitteolulistele virtuaalmasinatele, samal ajal kui teised, ettevõtte jaoks olulised, jäävad puudu ja muutuvad pudelikaelaks.
Ribalaiuse kasutamise nähtavus on samuti võtmetähtsusega konkreetsete linkide või kellaaegade ummikute tuvastamiseks . Liikluse jälgimine rakenduse, kasutaja või VLAN-i järgi aitab teil tuvastada, millised teenused võrku koormavad (nt varundamine, pilvesünkroniseerimine, videokonverentsid, voogesitus jne), ja annab teile ruumi tegutsemiseks: ülesannete ümberplaneerimiseks, QoS-i rakendamiseks või võrgu topoloogia ümberkujundamiseks.
Tänu detailsetele andmetele saitidevahelise latentsuse , rakenduste reageerimisaegade ja marsruutimise kohta on võimalik täpselt kindlaks teha WAN-võrgu segmendid, mis lisavad tarbetuid viivitusi . Marsruutide kohandamine, ühenduste parandamine või teatud teenuste lõppkasutajale lähemale viimine võib tajutavat aeglust oluliselt vähendada.
Hea nähtavuse teine eelis on võime kiiresti tuvastada ja parandada pakettide kadu . CRC-vigadega port, vigane kaabel või küllastunud liides võivad põhjustada pidevaid uuesti saatmisi ja vähendada jõudlust ilma, et midagi kohe nähtavat oleks. Liideste jälgimine mõõdikute abil vigade, kokkupõrgete ja tagasilükkamiste tuvastamiseks on oluline nende probleemsete piirkondade tuvastamiseks.
Lõpuks hõlbustab hea ajalooline andmestik tõsise intsidendi korral algpõhjuse analüüsi . Teadmine, milline oli liiklus enne probleemi, selle ajal ja pärast seda, millised seadmed näitasid alarme ja millised lingid töötasid 100% võimsusega, aitab leida tegeliku kitsaskoha ja mitte keskenduda ainult pealiskaudsetele sümptomitele.
Jälgimisvahendid ja nende roll tulemuslikkuses
Teooria on tore ja hea, aga igapäevases praktikas vajate konkreetseid tööriistu, mis näitavad teie võrgu, serverite ja rakenduste olekut . Tänapäeval on palju nii avatud lähtekoodiga kui ka kommertslahendusi, mis muudavad selle ülesande lihtsamaks.
Põhiinfrastruktuuri (protsessor, mälu, ketas, serverivõrk ja seadmed) puhul võimaldavad sellised lahendused nagu Zabbix, Nagios või sarnased tööriistad jälgida koormusi, reageerimisaegu ja teateid . Ülevaatlikult näete, millal protsessori koormus suureneb, millal RAM hakkab otsa saama või kas server kasutab pidevalt vahetusruumi ja põhjustab ketta kitsaskohta.
Kui olete mures mälukasutuse ja keerukamate tarbimismustrite pärast, aitavad jälgimisplatvormid (nt Elastic Stack või Datadog) mõõdikuid, logisid ja jälgi korreleerida, et paremini mõista, millised konkreetsed teenused tekitavad liigset koormust ja millises kontekstis.
Puhtalt võrgu poolelt võimaldavad tööriistad nagu Wireshark, PRTG Network Monitor või NetFlow/sFlow lahendused väga detailset liikluse analüüsi. Saate tuvastada viivitusi, ummikuid, ribalaiust koormavaid rakendusi, pakettide kadu teatud segmentides ja isegi anomaalseid mustreid, mis viitavad tõrgetele või turvaprobleemidele.
Ketta ja andmebaasi jõudluse jälgimiseks on väga kasulikud utiliidid nagu iostat, perfmon, New Relic ja muud rakenduste jõudluse jälgimise (APM) monitorid . Nende abil saate näha, kas SQL-päringud on hästi optimeeritud, kas indeksid toimivad õigesti või kas kitsaskoht ei ole võrgus, vaid salvestusruumis või andmebaasis endas.
Põhjaliku jälgimise valdkonnas pakuvad sellised lahendused nagu ManageEngine OpManager ühtset vaadet kogu võrgule ja selle seadmetele . Need võimaldavad teil näha mitte ainult ruuterite ja lülitite olekut, vaid ka liideseid, linkide kiirusi, iga pordi kaudu läbivat liiklust ning peamisi näitajaid, mis mõjutavad latentsust ja pakettide kadu.
Nende platvormide abil saab administraator ennetavaid teateid, kui link läheneb küllastusele, kui liideses esineb vigu või kui seade hakkab ebanormaalselt käituma . Lisaks võimaldavad paljud neist tööriistadest korduvate ülesannete automatiseerimist, vabastades aega strateegilisematele disaini- ja optimeerimisküsimustele keskendumiseks.
Võrgu ja infrastruktuuri kitsaskohtade lahendamise strateegiad
Probleemi tuvastamine on vaid pool tööd: teine pool on sobivate meetmete rakendamine kitsaskoha kõrvaldamiseks või leevendamiseks . Sõltuvalt kitsaskoha asukohast võivad lahendused ulatuda lihtsast konfiguratsioonimuudatusest kuni ulatusliku infrastruktuuri laiendamiseni.
Üks esimesi otsuseid, mis tavaliselt tekib, on see, kas valida vertikaalne skaleeritavus (ühe masina uuendamine) või horisontaalne skaleeritavus (rohkete masinate lisamine ja koormuse jaotamine) . Konkreetse serveri puhul, millel on napilt protsessorit või muutmälu, võib olla mõttekas sellele masinale rohkem ressursse lisada. Kuid saabub punkt, kus on tõhusam juurutada mitu serverit ja tasakaalustada liiklust nende vahel.
Samuti on oluline üle vaadata rakenduse kood ja andmebaasipäringud . Tihti süüdistatakse riistvara, kui tegelik probleem on ebaefektiivne loogika, indeksiteta SQL-päringud, korduvad kettapöördused või ebavajalikud andmete laadimised. Nende probleemide optimeerimine vähendab drastiliselt võrgu ja serverite koormust.
Teine oluline element kitsaskohtade leevendamisel on vahemälu ja koormuse tasakaalustamise nutikas kasutamine . Lahendused nagu Redis või Memcached võimaldavad salvestada sageli kasutatavaid vastuseid ja takistada serveritel või andmebaasidel sama teabe korduvat ümberarvutamist. Samamoodi jaotab koormuse tasakaalustaja (HAProxy, Nginx, pilveteenused jne) liikluse mitme sõlme vahel, takistades ühe serveri muutumist ummikupunktiks.
Võrgukihil on QoS-i (teenuse kvaliteet) konfigureerimine ja ribalaiuse haldamine üliolulised . Kriitilise liikluse (nt VoIP, ärirakendused, andmebaasiühendused) eelistamine vähem tundlikele kasutusviisidele (allalaadimised, värskendused, mittevajalik voogedastus) aitab tagada oluliste teenuste sujuva toimimise isegi suure koormuse korral.
Geograafiliselt hajutatud kasutajatega keskkondades võib sisuedastusvõrkude (CDN-ide) ja laivõrgu optimeerimise kasutamine olla määrava tähtsusega. Staatilise sisu paigutamine kasutajale lähemale, marsruutide optimeerimine või liikluse tihendamise ja deduplikatsioonitehnikate kasutamine vähendab latentsust ja ribalaiuse tarbimist, leevendades pikkade linkide kitsaskohti.
Lõpuks ei tohiks alahinnata hea füüsilise ja loogilise võrgudisaini olulisust : selge topoloogia, hea suurusega magistraalvõrgud, sobiv segmenteerimine ja varuühendused . Kõik see tagab, et isegi küllastuspunkti tekkimisel on võrgul võimekus liiklust teiste teede kaudu jaotada ja säilitada vastuvõetav kasutajakogemus.
Lõppkokkuvõttes ei seisne võrgu kitsaskohtade haldamine ainult kiiruse suurendamise või riistvara suurendamises. See hõlmab liiklusvoogude mõistmist, kitsaskohtade võimalike esinemiste prognoosimist ning parimate tavade rakendamist disainis, jälgimises ja pidevas optimeerimises . Selle kombinatsiooniga lakkab võrk olemast must kast, mis "on mõnikord aeglane", ja sellest saab ennustatav ja tõhus infrastruktuur, mis on kooskõlas ettevõtte tegelike vajadustega.
