Moderni verkko on lähes mahdotonta ajatella ilman mediasisältöä: lähes jokaisella isoäidillä on älypuhelin, kaikki ovat sosiaalisissa verkostoissa ja palveluseisokit ovat yrityksille kalliita. Huomioi, kopio yrityksen tarinasta siitä, kuinka hän organisoi valokuvien toimituksen laitteistoratkaisun avulla, mitä suorituskykyongelmia hän kohtasi prosessissa, mikä ne aiheutti ja kuinka nämä ongelmat ratkaistiin Nginxiin perustuvalla ohjelmistoratkaisulla varmistaen samalla vikasietoisuuden kaikilla tasoilla (). Kiitämme tarinan kirjoittajia Olegia Efimova ja Alexandra Dymova, jotka jakoivat kokemuksensa konferenssissa .
Aloitetaan pienellä esittelyllä valokuvien tallentamisesta ja välimuistista. Meillä on kerros, johon tallennamme ne, ja kerros, johon tallennamme valokuvat välimuistiin. Samalla, jos haluamme saavuttaa suuren tempun ja vähentää tallennustilan kuormitusta, meille on tärkeää, että jokainen yksittäisen käyttäjän valokuva on yhdellä välimuistipalvelimella. Muuten meidän pitäisi asentaa niin monta kertaa niin monta levyä kuin meillä on enemmän palvelimia. Osumaprosenttimme on noin 99 %, eli vähennämme tallennustilamme kuormitusta 100 kertaa, ja tätä varten meillä oli 10 vuotta sitten, kun kaikkea tätä rakennettiin, 50 palvelinta. Näin ollen näiden kuvien antamiseksi tarvitsimme itse asiassa 50 ulkoista verkkotunnusta, joita nämä palvelimet palvelevat.
Tietenkin heti heräsi kysymys: jos yksi palvelimistamme kaatuu ja ei ole käytettävissä, minkä osan liikenteestä menetämme? Katsoimme markkinoiden tarjontaa ja päätimme ostaa raudan, jotta se ratkaisisi kaikki ongelmamme. Valinta osui F5-verkkoyhtiön (joka muuten osti NGINX, Inc:n ei niin kauan sitten) ratkaisulle: BIG-IP Local Traffic Manager.
Mitä tämä rautapala (LTM) tekee: se on rautareititin, joka tekee rautaisen redundanssin ulkoisista porteistaan ja antaa sinun reitittää liikennettä verkon topologian, joidenkin asetusten perusteella ja suorittaa terveystarkastuksia. Meille oli tärkeää, että tämä rautapala voidaan ohjelmoida. Näin ollen voisimme kuvata logiikkaa, kuinka tietyn käyttäjän kuvat palautettiin tietystä välimuistista. Miltä se näyttää? On laitteisto, joka etsii Internetiä yhdelle toimialueelle, yhdelle IP-osoitteelle, suorittaa ssl-latauksen, jäsentää http-pyynnöt, valitsee välimuistin numeron IRulesta, minne mennä ja päästää liikenteen sinne. Samalla se tekee kuntotarkistuksia ja koneen epäkäytettävyyden sattuessa teimme niin, että liikenne meni tuolloin yhdelle varapalvelimelle. Kokoonpanon kannalta on tietysti joitain vivahteita, mutta yleensä kaikki on melko yksinkertaista: määritämme kartan, tietty numero vastaa IP-osoitetta verkossa, sanomme, että kuuntelemme portteja 80 ja 443, sanomme, että jos palvelin ei ole käytettävissä, sinun on annettava liikenne siirtyä varmuuskopioon, tässä tapauksessa 35., ja kuvailemme joukon logiikkaa, kuinka tämä arkkitehtuuri pitäisi purkaa. Ainoa ongelma oli, että kieli, jolla raudanpala on ohjelmoitu, on Tcl-kieli. Jos joku muistaa tämän ollenkaan ... tämä kieli on enemmän vain kirjoitus kuin ohjelmointiin sopiva kieli:
Mitä saimme? Saimme laitteiston, joka varmistaa infrastruktuurimme korkean käytettävyyden, reitittää kaiken liikenteemme, tarjoaa terveystarkastuksia ja vain toimii. Lisäksi se on toiminut melko pitkään: viimeisten 10 vuoden aikana siitä ei ole ollut valittamista. Vuoden 2018 alussa renderöimme jo noin 80 80 kuvaa sekunnissa. Tämä on noin XNUMX gigabittiä liikennettä molemmista palvelinkeskuksistamme.
Mutta…
Vuoden 2018 alussa näimme listoilla ruman kuvan: kuvien palautusaika on selvästi pidentynyt. Ja se ei enää sopinut meille. Ongelmana on, että tämä käyttäytyminen näkyi vain liikenteen ruuhkassa - yrityksellemme tämä on yö sunnuntaista maanantaihin. Mutta muun ajan järjestelmä toimi normaalisti, ei merkkejä rikkoutumisesta.
Ongelma oli kuitenkin ratkaistava. Tunnistamme mahdolliset pullonkaulat ja aloimme poistamaan niitä. Ensinnäkin tietysti laajensimme ulkoisia uplink-yhteyksiä, suoritimme sisäisten uplinkkien täydellisen revision ja löysimme kaikki mahdolliset pullonkaulat. Mutta kaikki tämä ei antanut ilmeistä tulosta, ongelma ei hävinnyt.
Toinen mahdollinen pullonkaula oli itse valokuvakätköjen suorituskyky. Ja päätimme, että ehkä ongelma on heissä. No, olemme laajentaneet suorituskykyä - periaatteessa valokuvavälimuistien verkkoportteja. Mutta taaskaan selvää parannusta ei näkynyt. Loppujen lopuksi kiinnitimme tarkasti huomiota itse LTM:n suorituskykyyn ja tässä näimme kaavioissa surullisen kuvan: kaikkien prosessorien latautuminen alkaa sujua mutkattomasti, mutta lepää sitten jyrkästi hyllyssä. Samaan aikaan LTM lakkaa reagoimasta riittävästi terveystarkastuksiin ja uplinkeihin ja alkaa sammuttaa niitä satunnaisesti, mikä johtaa vakavaan suorituskyvyn heikkenemiseen.
Eli olemme tunnistaneet ongelman lähteen, tunnistaneet pullonkaulan. On vielä päätettävä, mitä teemme.
Ensimmäinen ilmeinen asia, jonka voimme tehdä, on modernisoida itse LTM. Mutta tässä on joitain vivahteita, koska tämä rauta on melko ainutlaatuinen, et mene lähimpään supermarkettiin ostamaan sitä. Se on erillinen sopimus, erillinen lisenssisopimus, ja se vie paljon aikaa. Toinen vaihtoehto on alkaa ajatella itse, keksiä oma ratkaisu omiin komponentteihin, mieluiten avoimen lähdekoodin ohjelmalla. On vain päätettävä, mitä tarkalleen valitsemme tähän ja kuinka paljon aikaa käytämme tämän ongelman ratkaisemiseen, koska käyttäjät eivät saaneet valokuvia. Siksi on välttämätöntä tehdä tämä kaikki hyvin, hyvin nopeasti, voitaisiin sanoa - eilen.
Koska tehtävä kuulosti "tee jotain mahdollisimman nopeasti ja käyttämällä olemassa olevia laitteita", ensimmäinen asia, jonka ajattelimme, oli vain irrottaa edestä joitain ei kaikkein tehokkaimpia koneita, laittaa sinne Nginx, jolla tiedämme kuinka työskennellä ja yrittää toteuttaa kaikkea samaa logiikkaa kuin rautapala teki. Eli itse asiassa jätimme laitteistomme, asensimme vielä 4 palvelinta, jotka meidän piti määrittää, teimme niille ulkoiset toimialueet samalla tavalla kuin 10 vuotta sitten... Menetimme hieman käytettävyyttä, jos nämä koneet putosivat. , mutta kuitenkin ratkaisi käyttäjien ongelman paikallisesti.
Vastaavasti logiikka pysyy samana: asennamme Nginxin, se voi tehdä SSL-offloadin, voimme jotenkin ohjelmoida reitityslogiikan, tehdä konfiguraatioiden kuntotarkistuksia ja yksinkertaisesti kopioida aiemmin käyttämämme logiikka.
Istumme alas kirjoittamaan asetuksia. Aluksi näytti, että kaikki oli hyvin yksinkertaista, mutta valitettavasti jokaiselle tehtävälle on erittäin vaikea löytää käsikirjoja. Siksi emme suosittele yksinkertaisesti googlettamaan "miten Nginx määritetään valokuville": on parempi viitata viralliseen dokumentaatioon, joka näyttää, mitä asetuksia tulisi koskettaa. Mutta on parempi valita tietty parametri itse. No, sitten kaikki on yksinkertaista: kuvailemme palvelimia, jotka meillä on, kuvaamme varmenteita ... Mutta mielenkiintoisin asia on itse asiassa itse reitityslogiikka.
Aluksi meistä tuntui, että kuvailemme vain sijaintimme, yhdistämme siihen valokuvavälimuistimme numeron, kuvailemme käsillämme tai generaattorilla kuinka monta ylävirtaa tarvitsemme, jokaisessa ylävirran puolella osoitamme palvelimen, jolle liikenteen pitäisi mennä, ja varapalvelin - jos pääpalvelin ei ole käytettävissä:
Mutta luultavasti, jos kaikki olisi niin yksinkertaista, menisimme kotiin emmekä kertoisi mitään. Valitettavasti Nginxin oletusasetuksissa, jotka yleensä tehtiin useiden vuosien kehitystyön aikana ja eivät aivan tätä tapausta varten ... konfiguraatio näyttää tältä: jos jossain ylävirran palvelimessa on pyyntövirhe tai aikakatkaisu, Nginx aina vaihtaa liikennettä seuraavaan. Samanaikaisesti ensimmäisen epäonnistumisen jälkeen palvelin sammuu myös 10 sekunnin sisällä sekä vahingossa että aikakatkaisussa - tätä ei voi edes konfiguroida millään tavalla. Eli jos poistamme tai nollaamme aikakatkaisuvaihtoehdon ylävirran käskystä, vaikka Nginx ei käsittele tätä pyyntöä ja vastaa jollain ei-niin hyvällä virheellä, palvelin sammuu.
Tämän välttämiseksi teimme kaksi asiaa:
a) he kielsivät Nginxiä tekemästä tätä manuaalisesti - ja valitettavasti ainoa tapa tehdä tämä on yksinkertaisesti asettaa enimmäisvirheasetukset.
b) muistimme, että muissa projekteissa käytämme moduulia, jolla voit tehdä taustan terveystarkastuksia - vastaavasti teimme melko usein terveystarkastuksia, jotta meillä on mahdollisimman vähän seisokkeja onnettomuuden sattuessa.
Valitettavasti tässäkään ei ole vielä kaikki, sillä kirjaimellisesti tämän järjestelmän kaksi ensimmäistä toimintaviikkoa osoittivat, että TCP:n kuntotarkastus on myös epäluotettava asia: ei Nginx tai D-tilassa oleva Nginx voidaan käynnistää ylävirran palvelimella, ja Tässä tapauksessa ydin hyväksyy yhteyden, kuntotarkastus läpäisee, mutta se ei toimi. Siksi korvasimme sen heti http:n kuntotarkastuksella, teimme tietyn, joka, jos se antaa jo 200, niin kaikki toimii tässä skriptissä. Voit tehdä lisälogiikkaa - esimerkiksi välimuistipalvelimien tapauksessa tarkista, että tiedostojärjestelmä on asennettu oikein:
Ja se sopisi meille, paitsi että tällä hetkellä piiri toisti täysin sen, mitä rautapala teki. Mutta halusimme tehdä paremmin. Aiemmin meillä oli yksi varmuuskopiopalvelin, ja tämä ei todennäköisesti ole kovin hyvä, koska jos sinulla on sata palvelinta, niin kun useita kaatuu kerralla, yksi varapalvelin ei todennäköisesti kestä kuormitusta. Siksi päätimme jakaa varauksen kaikkien palvelimien kesken: teimme yksinkertaisesti toisen erillisen ylävirtaan, kirjasimme kaikki palvelimet sinne tietyillä parametreilla sen mukaan, mitä kuormaa ne voivat palvella, lisäsimme samat terveystarkastukset, jotka meillä oli aiemmin:
Koska et voi mennä toiseen ylävirtaan yhden ylävirran sisällä, oli tarpeen varmistaa, että jos ylävirran pää, johon yksinkertaisesti kirjoitimme oikean, tarpeellisen valokuvavälimuistin, ei ollut käytettävissä, menimme yksinkertaisesti takaisin error_page-sivun kautta, mistä menimme varmuuskopioon ylävirtaan:
Ja kirjaimellisesti lisäämällä neljä palvelinta, saimme tämän: korvasimme osan kuormituksesta - poistimme LTM:stä näille palvelimille, toteutimme siellä saman logiikan vakiolaitteistolla ja ohjelmistolla, saimme heti bonuksen, että näitä palvelimia voidaan skaalata, koska ne voidaan skaalata. laita vain niin paljon kuin tarvitset. No, ainoa negatiivinen asia on, että olemme menettäneet korkean käytettävyyden ulkoisille käyttäjille. Mutta tuolloin minun piti uhrata tämä, koska ongelma oli ratkaistava välittömästi. Joten poistimme osan kuormasta, se oli tuolloin noin 40%, LTM parani, ja kirjaimellisesti kaksi viikkoa ongelman alkamisen jälkeen aloimme antaa ei 45 55 pyyntöä sekunnissa, vaan 20 XNUMX pyyntöä. Itse asiassa kasvoimme XNUMX % - tämä on selvästi liikenne, jota emme antaneet käyttäjälle. Ja sen jälkeen he alkoivat miettiä, kuinka ratkaista jäljellä oleva ongelma - varmistaa korkea ulkoinen saatavuus.
Meillä oli tauko, jonka aikana keskustelimme, mitä ratkaisua käyttäisimme tähän. Oli ehdotuksia luotettavuuden varmistamiseksi DNS:n avulla joidenkin itse kirjoitettujen komentosarjojen, dynaamisten reititysprotokollien avulla ... vaihtoehtoja oli monia, mutta jo kävi selväksi, että valokuvien todella luotettavan palautuksen saamiseksi sinun on otettava käyttöön toinen kerros joka seuraa tätä. Kutsuimme näitä koneita valokuvaohjaajiksi. Ohjelmisto, johon luotimme, oli Keepalived:
Aluksi, mistä Keepalived koostuu. Ensimmäinen on verkkolaitteiden laajalti tuntema VRRP-protokolla, joka sijaitsee verkkolaitteissa ja tarjoaa vikasietoisuuden ulkoiselle IP-osoitteelle, johon asiakkaat muodostavat yhteyden. Toinen osa on IPVS, IP-virtuaalipalvelin, joka tasapainottaa valokuvareitittimien välillä ja tarjoaa vikasietoisuuden tällä tasolla. Ja kolmas on terveystarkastukset.
Aloitetaan ensimmäisestä osasta: VRRP – miltä se näyttää? On olemassa tietty virtuaalinen IP, jossa on merkintä osoitteessa dns badoocdn.com, johon asiakkaat muodostavat yhteyden. Jossain vaiheessa meillä on IP-osoite yhdellä palvelimella. Säilytettävät paketit kulkevat palvelimien välillä VRRP-protokollalla, ja jos isäntä katoaa tutkasta - palvelin on käynnistynyt uudelleen tai jotain muuta, niin varapalvelin nostaa tämän IP-osoitteen automaattisesti - manuaalisia toimenpiteitä ei tarvita. Isäntä ja varmuuskopio eroavat toisistaan, pääasiassa prioriteetti: mitä korkeampi se on, sitä todennäköisemmin koneesta tulee isäntä. Erittäin suuri etu on, että sinun ei tarvitse määrittää IP-osoitteita itse palvelimelle, riittää kun kuvailet ne asetuksissa, ja jos IP-osoitteet tarvitsevat mukautettuja reitityssääntöjä, tämä on kuvattu suoraan asetuksissa, sama syntaksi kuin VRRP-paketissa on kuvattu. Et tule tapaamaan mitään tuntemattomia asioita.
Miltä se näyttää käytännössä? Mitä tapahtuu, jos yksi palvelimista kaatuu? Heti kun isäntä katoaa, varmuuskopiomme lakkaa vastaanottamasta ylennyksiä ja hänestä tulee automaattisesti isäntä. Jonkin ajan kuluttua korjasimme masterin, käynnistimme uudelleen, nostimme Keepalivedin - mainokset, joilla on korkeampi prioriteetti kuin varmuuskopio, saapuvat ja varmuuskopio kääntyy automaattisesti takaisin, poistaa IP-osoitteet itsestään, manuaalisia toimenpiteitä ei tarvita.
Näin olemme varmistaneet ulkoisen IP-osoitteen vikasietoisuuden. Seuraava osa on jollakin tavalla tasapainottaa liikennettä ulkoisesta IP-osoitteesta valokuvareitittimiin, jotka jo lopettavat sen. Tasapainotusprotokollien avulla kaikki on tarpeeksi selvää. Tämä on joko yksinkertainen round-robin, tai vähän monimutkaisempia asioita, wrr, listayhteys ja niin edelleen. Tämä on pohjimmiltaan kuvattu dokumentaatiossa, siinä ei ole mitään erityistä. Mutta toimitustapa ... Täällä asumme yksityiskohtaisemmin - miksi valitsimme yhden niistä. Nämä ovat NAT, suora reititys ja TUN. Tosiasia on, että määritimme välittömästi 100 gigabitin liikenteen palautuksen sivustoilta. Jos ymmärrät sen, tarvitset 10 gigabitin korttia, eikö niin? 10 gigabitin korttia yhdellä palvelimella - tämä on jo ainakin meidän "vakiovarusteiden" käsitettämme enemmän. Ja sitten muistimme, että emme anna vain liikennettä, vaan valokuvia.
Mikä on ominaisuus? - Valtava ero saapuvan ja lähtevän liikenteen välillä. Saapuva liikenne on hyvin pientä, lähtevä liikenne erittäin suurta:
Jos katsot näitä kaavioita, näet, että tällä hetkellä ohjaajalle lähetetään noin 200 Mb sekunnissa, tämä on tyypillisin päivä. Annamme takaisin 4,500 Mt sekunnissa, suhde on noin 1/22. On jo selvää, että voidaksemme tarjota lähtevän liikenteen täysin 22 toimivalle palvelimelle, riittää yksi, joka hyväksyy tämän yhteyden. Tässä suora reititysalgoritmi, reititysalgoritmi, tulee avuksemme.
Miltä se näyttää? Valokuvaohjaajamme siirtää yhteydet valokuvareitittimiin taulukkonsa mukaan. Mutta valokuvareitittimet lähettävät käänteisen liikenteen suoraan Internetiin, lähettävät sen asiakkaalle, se ei mene takaisin valokuvaohjaajan kautta, joten tarjoamme vähimmäismäärällä koneita täyden vikasietokyvyn ja kaiken liikenteen pumppauksen. Konfiguroinnissa se näyttää tältä: määritämme algoritmin, meidän tapauksessamme se on yksinkertainen rr, tarjoamme suoran reititysmenetelmän ja sitten alamme listata kaikki oikeat palvelimet, kuinka monta niitä meillä on. Mikä määrää tämän liikenteen. Siinä tapauksessa, että meillä on yksi tai kaksi lisää, useita palvelimia ilmestyy sinne, tällainen tarve syntyy - lisäämme tämän osan konfiguraatioon ja älä huoli liikaa. Oikeiden palvelimien puolelta valokuvareitittimen puolelta tämä menetelmä vaatii pienimmän konfiguroinnin, se on kuvattu täydellisesti dokumentaatiossa, eikä siinä ole sudenkuoppia.
Erityisen miellyttävää on, että tällainen ratkaisu ei tarkoita paikallisverkon radikaalia muutosta, tämä oli meille tärkeää, meidän piti ratkaista se pienin kustannuksin. Jos katsot sitten katsotaan miltä se näyttää. Täällä meillä on tietty virtuaalipalvelin, portissa 443, kuuntelee, hyväksyy yhteyden, kaikki toimivat palvelimet on listattu ja on selvää, että yhteys on plus tai miinus sama. Jos katsomme saman virtuaalipalvelimen tilastoja, meillä on saapuvia paketteja, saapuvia yhteyksiä, mutta lähteviä ei ollenkaan. Lähtevät yhteydet menevät suoraan asiakkaalle. No, onnistuimme tasapainottamaan. Mitä nyt tapahtuu, jos yksi valokuvareitittimistämme epäonnistuu? Loppujen lopuksi rauta on rautaa. Se voi joutua ytimen paniikkiin, se voi rikkoutua, virtalähde saattaa palaa. Mitä tahansa. Tätä varten terveystarkastukset ovat. Ne voivat olla niinkin yksinkertaisia kuin portin aukioloajan tarkistaminen, tai monimutkaisempia, jopa itse kirjoitettuja skriptejä, jotka jopa tarkistavat liiketoimintalogiikan.
Pysähdyimme jossain puolivälissä: meillä on https-pyyntö tietystä sijainnista, komentosarja kutsutaan, jos se vastaa 200. vastauksella, uskomme, että kaikki on kunnossa tämän palvelimen kanssa, että se on elossa ja voidaan käynnistää melko helposti .
Miltä tämä taas näyttää käytännössä. Palvelin sammutettu, sallittu ylläpitoon - esimerkiksi BIOSin vilkkuminen. Lokeissa meillä on heti aikakatkaisu, näemme ensimmäisen rivin, sitten kolmen yrityksen jälkeen se merkitään "epäonnistuneeksi" ja se poistetaan yksinkertaisesti luettelosta.
Toinen käyttäytyminen on myös mahdollista, kun yksinkertaisesti VS asetetaan nollaan, mutta valokuvan palauttamisen tapauksessa tämä ei toimi hyvin. Palvelin nousee, Nginx käynnistyy siellä, terveystarkastukset ymmärtävät heti, että yhteys toimii, että kaikki on kunnossa, ja palvelin ilmestyy listallemme ja siihen alkaa välittömästi kohdistua kuormitus automaattisesti. Päivystäjältä ei vaadita manuaalisia toimia. Yöllä palvelin käynnistyi uudelleen - valvontaosasto ei soita meille tästä yöllä. He kertoivat sinulle, mitä tapahtui, kaikki on hyvin.
Joten, melko yksinkertaisella tavalla, pienen palvelinmäärän avulla ratkaisimme ulkoisen vikasietoisuuden ongelman.
On vielä sanottava, että kaikkea tätä on tietysti seurattava. Erikseen on syytä huomata, että Keepalivedellä, hyvin kauan sitten kirjoitettuna ohjelmistona, on joukko tapoja valvoa sitä, sekä käyttämällä DBus-, SMTP-, SNMP- että standardin Zabbix-tarkistuksia. Lisäksi hän itse osaa kirjoittaa kirjeitä melkein jokaiseen aivastamiseen, ja ollakseni rehellinen, jossain vaiheessa jopa ajattelimme sammuttaa sen, koska hän kirjoittaa paljon kirjaimia mihin tahansa liikennekytkimeen, sisällyttämiseen, jokaiseen IP-shnikiin ja niin edelleen. Tietysti, jos palvelimia on paljon, voit täyttää itsesi näillä kirjeillä. Vakiomenetelmillä valvomme nginxiä valokuvareitittimillä, eikä laitteiston valvonta ole kadonnut. Tietenkin neuvoisimme vielä kahta asiaa: ensinnäkin ulkoisia terveystarkastuksia ja saavutettavuutta, koska vaikka kaikki toimisikin, on itse asiassa mahdollista, että käyttäjät eivät saa kuvia ulkoisten palveluntarjoajien ongelmien tai jonkin monimutkaisemman takia. Aina kannattaa pitää jossain toisessa verkossa, amazonissa tai jossain muualla erillistä konetta, joka voi pingata palvelimia ulkopuolelta, ja kannattaa myös käyttää joko poikkeamien havaitsemista, hankalan koneoppimisen taitavien tai yksinkertaista seurantaa, ainakin sen jäljittämiseksi, ovatko pyynnöt vähentyneet jyrkästi vai päinvastoin kasvaneet. Se on myös hyödyllistä.
Yhteenvetona: itse asiassa korvasimme rautaisen ratkaisun, joka ei jossain vaiheessa enää sopinut meille, melko yksinkertaisella järjestelmällä, joka tekee kaiken samoin, eli se tarjoaa HTTPS-liikenteen lopettamisen ja edelleen älykkään reitityksen tarvittavalla kunnossa - tarkastukset. Olemme lisänneet tämän järjestelmän vakautta, eli meillä on edelleen korkea käytettävyys jokaiselle kerrokselle, plus saimme bonuksena, että se on melko helppo skaalata jokaiselle tasolle, koska tämä on vakiolaitteisto vakioohjelmistolla, eli Näin tekemällä olemme yksinkertaistaneet mahdollisten ongelmien diagnosointia.
Mihin päädyimme? Meillä oli ongelma tammikuun 2018 lomilla. Ensimmäisen kuuden kuukauden aikana, kun otimme tätä järjestelmää käyttöön, laajensimme sitä kaikkeen liikenteeseen, jotta kaikki liikenne LTM:stä saadaan poistettua, kasvoimme vain yhden datakeskuksen liikenteessä 40 gigabitistä 60 gigabittiin ja samalla koko vuoden 2018 ajan pystyivät antamaan lähes kolme kertaa enemmän kuvia sekunnissa.
Lähde: will.com