oles@ovh.net
03-28-2012, 07:50 PM
Sveiki,
Šiąnakt patyrėme tinklo nukreipimo problemų dėl programinės įrangos gedimo, paveikusio du pagrindinius maršrutizatorius Rubė. Cisco ASR 9010 užtikrina Rubė duomenų centrų (RBX1 RBX2 RBX3 RBX4 RBX5) perduodamų duomenų srauto nukreipimą ir sujungimą su Paryžiumi, Briuseliu, Amsterdamu, Londonu bei Frankfurtu. Kitiap sakant, Rubė tinklo maršrutizavimo centrą.
Šis gedimas jau žinomas ir susijęs su naujomis plokštėmis, kurias pradėjome diegti sausio mėn. pabaigoje (24x10G jungčiai). Dėl atsitiktinių (random) priežasčių plokštė pradeda identifikuoti RAM ECC klaidas ir nebenukreipia paketų. Bet nepaisant to, plokštė nepaskelbiama sugedusia ir lieka maršrutizatoriuje, tarsi ji būtų gera. Kituose maršrutizatoriuose ir toliau siunčiami paketai, bet jų niekas negauna. Viskas nukrenta į juodą skylę, o tinklas nustoja tinkamai veikti. Blogiausiu atveju, vyksta netikras gedimas.
Šiąnakt visos trys plokštės po 24x10G sugedo dviejuose ASR 9010 maršrutizatoriuose beveik tuo pat metu. Tai suskaidė tinklą į tris dalis: JAV/Londonas/Amsterdamas/Varšuva, Rubė ir Paryžius, Frankfurtas, Madridas, Milanas, perimant paketus Rubė. Paprastai duomenų srautas būtų buvęs dar kartą nukreiptas, bet šiuo atveju jis buvo perimtas ir užblokuotas Rubė.
Todėl nebegalėjome naudoti ir administruoti tinklo, taip pat gauti visų maršrutizatorių įrašų (logs), kad nustatytume problemos priežastį. Mes naršėme kaip ir anksčiau, naudodami atsargines/išorines jungtis prisijungimui prie kiekvieno backbone maršrutizatoriaus, kad nustatytume, ar problemą sukėlė pats maršrutizatorius. Ši operacija užtruko, nes be šio gedimo, mums prireikė laiko, kad suprastume, jog problemos priežastis ne tik rbx-g2-a9 maršrutizatorius, bet ir rbx-g1-a9. Kai tik trys plokštės buvo perkrautos, viskas veikė po 5 minučių.
Beveik prieš 3 savaites mes jau pranešėme Cisco apie RAM ECC problemą. Cisco sprendė šią problemą ir pagaliau mums suteikė programinės įrangos automatinę pataisą, kurią galime taikyti maršrutizatoriams, kad išspręstume tokią problemą. Ši operacija bus įgyvendinta šiąnakt. Nenumatyta jokio gedimo.
Mes taip pat svarstome, kaip galėtume pagerinti mūsų maršrutizatorių valdymą viso backbone gedimo atveju dėl atsitiktinių priežasčių. Mes jau žinome, kaip valdyti šį atvejį, bet tai vyksta lėtai. Labai lėtai.
Visais šiais atvejais gedimas užtruko daugiau nei 99.9% tokiems atvejams numatyto laiko, tiksliau, 1 val. 22 min., nors turime teisę tik į 43 min. neveikimo laiko per mėnesį. Todėl numatomos baudos už leistino laiko viršijimą. Pavyzdžiui, OVH skirtiesiems serveriams numatyta 5% neveikimo laiko per valandą. Mes sukursime URL adresą, kur galėsite įjungti SLA ir atsiųsti dokumentus, kad gautumėte 5% paslaugos veikimo laiko. Nuoroda bus paskelbta vykdomų darbų sąraše http://darbai.ovh.lt/?do=details&id=2571.
Mums nelabai malonu rašyti tokius laiškus, bet jeigu mes nesame tokie geri... mes tai pripažįstame ir atsiprašome.
Dar kartą atsiprašome.
Linkėjimai,
Octave
Šiąnakt patyrėme tinklo nukreipimo problemų dėl programinės įrangos gedimo, paveikusio du pagrindinius maršrutizatorius Rubė. Cisco ASR 9010 užtikrina Rubė duomenų centrų (RBX1 RBX2 RBX3 RBX4 RBX5) perduodamų duomenų srauto nukreipimą ir sujungimą su Paryžiumi, Briuseliu, Amsterdamu, Londonu bei Frankfurtu. Kitiap sakant, Rubė tinklo maršrutizavimo centrą.
Šis gedimas jau žinomas ir susijęs su naujomis plokštėmis, kurias pradėjome diegti sausio mėn. pabaigoje (24x10G jungčiai). Dėl atsitiktinių (random) priežasčių plokštė pradeda identifikuoti RAM ECC klaidas ir nebenukreipia paketų. Bet nepaisant to, plokštė nepaskelbiama sugedusia ir lieka maršrutizatoriuje, tarsi ji būtų gera. Kituose maršrutizatoriuose ir toliau siunčiami paketai, bet jų niekas negauna. Viskas nukrenta į juodą skylę, o tinklas nustoja tinkamai veikti. Blogiausiu atveju, vyksta netikras gedimas.
Šiąnakt visos trys plokštės po 24x10G sugedo dviejuose ASR 9010 maršrutizatoriuose beveik tuo pat metu. Tai suskaidė tinklą į tris dalis: JAV/Londonas/Amsterdamas/Varšuva, Rubė ir Paryžius, Frankfurtas, Madridas, Milanas, perimant paketus Rubė. Paprastai duomenų srautas būtų buvęs dar kartą nukreiptas, bet šiuo atveju jis buvo perimtas ir užblokuotas Rubė.
Todėl nebegalėjome naudoti ir administruoti tinklo, taip pat gauti visų maršrutizatorių įrašų (logs), kad nustatytume problemos priežastį. Mes naršėme kaip ir anksčiau, naudodami atsargines/išorines jungtis prisijungimui prie kiekvieno backbone maršrutizatoriaus, kad nustatytume, ar problemą sukėlė pats maršrutizatorius. Ši operacija užtruko, nes be šio gedimo, mums prireikė laiko, kad suprastume, jog problemos priežastis ne tik rbx-g2-a9 maršrutizatorius, bet ir rbx-g1-a9. Kai tik trys plokštės buvo perkrautos, viskas veikė po 5 minučių.
Beveik prieš 3 savaites mes jau pranešėme Cisco apie RAM ECC problemą. Cisco sprendė šią problemą ir pagaliau mums suteikė programinės įrangos automatinę pataisą, kurią galime taikyti maršrutizatoriams, kad išspręstume tokią problemą. Ši operacija bus įgyvendinta šiąnakt. Nenumatyta jokio gedimo.
Mes taip pat svarstome, kaip galėtume pagerinti mūsų maršrutizatorių valdymą viso backbone gedimo atveju dėl atsitiktinių priežasčių. Mes jau žinome, kaip valdyti šį atvejį, bet tai vyksta lėtai. Labai lėtai.
Visais šiais atvejais gedimas užtruko daugiau nei 99.9% tokiems atvejams numatyto laiko, tiksliau, 1 val. 22 min., nors turime teisę tik į 43 min. neveikimo laiko per mėnesį. Todėl numatomos baudos už leistino laiko viršijimą. Pavyzdžiui, OVH skirtiesiems serveriams numatyta 5% neveikimo laiko per valandą. Mes sukursime URL adresą, kur galėsite įjungti SLA ir atsiųsti dokumentus, kad gautumėte 5% paslaugos veikimo laiko. Nuoroda bus paskelbta vykdomų darbų sąraše http://darbai.ovh.lt/?do=details&id=2571.
Mums nelabai malonu rašyti tokius laiškus, bet jeigu mes nesame tokie geri... mes tai pripažįstame ir atsiprašome.
Dar kartą atsiprašome.
Linkėjimai,
Octave