{"id":32682,"date":"2019-10-31T21:48:22","date_gmt":"2019-10-31T18:48:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ishhem-problemu-ne-v-tom-meste\/"},"modified":"2019-10-31T21:48:22","modified_gmt":"2019-10-31T18:48:22","slug":"ishhem-problemu-ne-v-tom-meste","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Vi letar inte efter problemet p\u00e5 fel st\u00e4lle.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Detta \u00e4r en liten historia fr\u00e5n verklig praktik, d\u00e4r ett litet problem, v\u00e4l dolt av redundans, har blivit en huvudv\u00e4rk.
\n<\/a><\/noindex><\/p>\n

Liten disposition:<\/h2>\n

\nEn liten filial, med sin egen telefonv\u00e4xel (Asterisk + FreePBX) baserad p\u00e5 desktop-h\u00e5rdvara och en likadan lokal terminalserver med 1C, en filserver och en virtuell RO dom\u00e4nkontroller. Internet delas via Mikrotik. Filialen \u00e4r liten, vilket r\u00e4cker f\u00f6r dem.
\nDet hela b\u00f6rjade med \u00f6vervakning (p\u00e5 grund av tidsbrist och lathet \u00f6vervakar man inte allt), som rapporterade \u00f6verhettning av en servern<\/a> (med telefonv\u00e4xeln) i filialen. Medan de lokala f\u00f6rs\u00f6kte l\u00f6sa problemet, fr\u00f6s den gamla servern och skadade lite av MySQL-databasen.<\/p>\n

Mycket tycktes f\u00f6reb\u00e5da olycka, men inte detta\u2026<\/h3>\n

\nInga problem, databasen reparerades, allt borde fungera. Men de lokala klagar, samtal bryts. Okej \u2014 problem uppst\u00e5r ibland med FreePBX, jag tar en backup, \u00e5terst\u00e4ller, allt ser okej ut.
\nMen olyckan finns fortfarande, de lokala klagar fortfarande, samtal fungerar inte som de ska. N\u00e4r de f\u00e5r ett samtal verkar allt okej, men n\u00e4r de sj\u00e4lva ringer, eller ringer till varandra, \u00e4r det flera sekunders f\u00f6rdr\u00f6jning. Jag b\u00f6rjar titta p\u00e5 de omfattande och oklara loggarna fr\u00e5n Asterisk och FreePBX, men jag kan inte se problemet. Jag kommer ih\u00e5g att det fanns ett problem med STUN och ICE, som gav liknande f\u00f6rdr\u00f6jning. Jag st\u00e4nger av allt f\u00f6r gott, resultatet \u00e4r noll.<\/p>\n

F\u00f6rtvivlan \u2014 v\u00e4gen till d\u00e5liga beslut:<\/h3>\n

\nJag faller ner i f\u00f6rtvivlan, timtal av gr\u00e4vande i telefonv\u00e4xeln leder inte till n\u00e5got bra, natten \u00e4r sen och problemet \u00e4r ol\u00f6st.
\nJag l\u00e4t problemet vara till morgonen, i hopp om att vara mer klar i huvudet. P\u00e5 morgonen togs ett ytterligare misslyckat beslut: eftersom systemet har g\u00e5tt s\u00f6nder (\u00e4ven om frysen inte kan ha varit s\u00e5 f\u00f6r\u00f6dande) f\u00f6rs\u00f6ker jag reparera systemet genom att installera om alla paket. Resultatet \u00e4r n\u00e5got mer \u00e4n noll, f\u00f6rdr\u00f6jningen har minskat (inte betydligt, men \u00e4nd\u00e5 en framg\u00e5ng).
\nJag tar ytterligare ett d\u00e5ligt beslut: om delvis reparation av OS (och databasen fr\u00e5n backup) har haft en liten framg\u00e5ng, och roten till problemet fortfarande \u00e4r oklar, och dessutom har jag redan lagt ner mycket tid p\u00e5 att leta efter orsaken, s\u00e5 beslutar jag att agera radikalt: vi tar bort OS och installerar allt p\u00e5 nytt (lyckligtvis g\u00f6r automatiseringen av processen detta p\u00e5 rimlig tid). Jag \u00e5terst\u00e4ller FreePBX-konfigurationen fr\u00e5n en kopia. \u00c4nnu ett misslyckande. Resultatet \u00e4r noll!<\/p>\n

F\u00f6rtvivlan \u2014 f\u00f6rnuftet f\u00f6rm\u00f6rkas, besluten blir \u00e4nnu s\u00e4mre.<\/h3>\n

\nJag blir f\u00f6rtvivlad. Helt galna tankar b\u00f6rjar dyka upp, jag t\u00e4nker: kanske \u00e4r konferensen i backupen trasig (det h\u00e4nde mig efter flera uppdateringar som gjorde att den inte fungerade, och jag kunde aldrig hitta orsaken), det finns inget annat att g\u00f6ra: jag m\u00e5ste b\u00f6rja om fr\u00e5n b\u00f6rjan f\u00f6r hand. Vilken skam! Resultatet \u00e4r helt noll, och jag har dessutom sl\u00f6sat bort massor av tid!<\/p>\n

Acceptans \u2013 v\u00e4gen till insikt<\/h3>\n

\nI mina desperata f\u00f6rs\u00f6k att f\u00f6rst\u00e5 vad som h\u00e4nder b\u00f6rjar jag noggrant studera loggarna. Jag m\u00e4rker ett m\u00f6nster. Anropet till Extension sker exakt efter 5 sekunder, och f\u00f6r en gruppanrop av 3 Extension efter 15! Jag b\u00f6rjar googla p\u00e5 f\u00f6rdr\u00f6jning av anrop, men specificerar redan en konkret f\u00f6rdr\u00f6jning. Och jag snubblar \u00f6ver ett svar jag redan har hittat, folk s\u00e4ger att problemet ligger i DNS, men jag vet att det inte finns n\u00e5got problem, alla adresser l\u00f6ses ju!<\/p>\n

Det uppenbara \u2013 inte det troliga<\/h3>\n

\nDet finns inget annat att g\u00f6ra, jag tar fram nslookup och bingo (varf\u00f6r gjorde jag inte detta direkt)! Prim\u00e4r DNS \u00e4r nere (virtuell maskin med kontroller), och jag m\u00e4rkte det inte ens! Om det vore en enda DNS skulle det omedelbart ha blivit ett fel \ud83d\ude09<\/p>\n

Resultat<\/h3>\n

\nEtt element\u00e4rt problem som \u00f6vervakningen (som b\u00f6r konfigureras f\u00f6r alla noder) kunde ha sett, maskerat av DNS:s redundans, ledde till n\u00e4stan tv\u00e5 arbetsdagar av f\u00f6rlust p\u00e5 grund av en dum situation. Att vara lat \u00e4r ett huvudverk, att konfigurera \u00f6vervakningen tar en minut \u2013 att leta efter problemet d\u00e4r det inte \u00e4r \u2013 tv\u00e5 dagar.<\/p>\n

Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. Logga in<\/a><\/noindex>, tack.<\/p>\n

Har ni varit med om n\u00e5got liknande?<\/h2>\n