Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Pani Krysia z .... nie, nie - John Doe ;) z działu sieci

Jest blog o problemach Pani Krysi (jak ja nie cierpię tego imienia), jest blog o problemach w szpitalu. To dlaczego nie może być bloga o problemach na uniwerku? Może. No to i startujemy.

Pisałem już co nieco o uniwersytecie, gdzie pracuję. Maszyn mamy sporo, serwerów jak i stacji roboczych. Użytkowników jeszcze więcej, bo przecież studenci.
Mamy trzy serwerownie, w każdej sporo sprzętu, systemy chłodzące (o których będzie wpis) - serwery panelowe, routery, switche, zasilacze, upsy itd. Łącza między serwerowniami są dublowane, światłowód.
Dwa lata temu, uniwerek wprowadził tzw standby hours - czyli dyżur wieczorny. Na czym to polega? Siedzę sobie w domu i oglądam film ;) A poważniej - muszę być pod telefonem służbowym. W razie zgłoszenia awarii muszę się zalogować i spróbować naprawić. Dyżur jest od 17:00 do 21:00.

Dziś wpis o problemie jaki stworzył kolega z działu sieci.

Update switchy

Otóż dział ten zaplanował sobie update oprogramowania core switchy sieciowych. Ale tak jakby zapomnieli nas powiadomić. Ok. godziny 18:00 dzwoni do mnie koleżanka z tegoż działu utrzymania sieci. Opisuje problem - moodle nie działa.

Loguję się do sieci VPN naszego uniwerku. Loguję na mojego PC w biurze. Sprawdzam - fakt, nie działa. Ale serwery www działają, procesy httpd też, lokalnie na serwerze strona odpowiada. Jedynie przez load balancer, przez nazwę domeny - kiszka. Pytam w takim razie, czy wiadomo jej coś o jakichś pracach sieciowych. No oczywiście. Siedzi w pracy człowiek i robi update'y oprogramowania switchy. Się ja pytam dlaczego nie zostaliśmy powiadomieni?

Ona nie wie - była na urlopie.

No to przystępujemy do diagnoz.

Nie w serwerach leży problem, bo po podmianie wpisu w pliku hosts, kierującego przeglądarkę konkretnie na dany IP dla domeny moodle - serwis działa. Czyli serwery www jak i baza - działają. Szukamy dalej - route daje normalne odczyty, brama domyślna ustawiona, serwery dns znane. Pingi między serwerami chodzą. A jednak load balancer nie widzi kompletnie serwerów www. Robimy mały hack i zamiast sprawdzania portu 80, sprawdzamy po prostu czy serwer www żyje. Moodle działa - ale straaaaasznie wolno. Sprawdzam więc wydajność bazy - czasy odpowiedzi, ilość klientów podłączonych - wszystko w porządku. Dla pewności restartowałem serwisy httpd - bez zmian. Wykonałem jeszcze trochę różnych testów, restartów itd. Zmieniłem nawet konfigurację serwera, podając inną bramę domyślną - nic, zero, null, nada ... jednym słowem ja nie mogę ani zdiagnozować, ani naprawić problemu.
Koło godziny 20:00 dzwonię, któryś już raz, do kumpelki i sugeruję, że może by tak przywrócić stare oprogramowanie switchy, albo tych kilku, obsługujących daną podsieć. Dostaję zapewnienie, że mają to w planach ale jeszcze muszą sprawdzić parę rzeczy.
W końcu, koło godziny 21:00, czyli pod koniec dyżuru, telefon - przywrócili stary software, bo nie mają pojęcia co jest grane. Co ciekawe - tylko ten jeden serwis, moodle, był poszkodowany.

Wszystko inne chodzi.

Sprawdzam z domu - działa jak w dniu narodzin.

Wnioski?

Jest taki jeden dział w każdej firmie, którego akcje mogą spowodować, że mimo że wszystko działa - nie działa nic. To sieciowcy. Oczywiście jak wyłączą prąd też nic nie będzie działać, ale to będzie widać od razu ;)

Zmarnowałem tego wieczoru prawie 3 godziny na szukanie przyczyn problemu, zmiany konfiguracji, restarty itd. Awaria była spowodowana w miejscu poza moim zasięgiem.
Czasem też, na sugestie, że to prawdopodobnie zawiniła sieć - sieciowcy w ogóle nie słuchają.

Ten przypadek pokazuje też, że znalezienie przyczyny błędu jest tym bardziej skomplikowane, im większa jest infrastruktura danej firmy. Pokazuje też, że koniecznością staje się posiadanie dodatkowych serwisów, np. do przechowywania haseł do setek różnych serwerów, aplikacji, baz danych. Posiadanie dobrego systemu monitorującego, powiadamiającego o możliwości zaistnienia awarii, również jest pewnym wymogiem. Akurat w tym przypadku, system ten powiadomił by mnie dopiero w momencie wystąpienia awarii, zakładając, że miałby dostęp do sieci.

Mam nadzieję napisać serię artów na temat Johna Doe z univerku. Przez kilka lat pracy tutaj, zebrało się kilkanaście ciekawych przypadków.

Są koty, są i psy :)

Oto jeden z moich.

 

sprzęt oprogramowanie serwery

Komentarze

0 nowych
Samurai   16 #1 26.08.2013 17:50

Wpis przeczytałem i chciałem napisać, że fajny ale strasznie krótki. Po czym się zorientowałem, że pominąłem jeden cały akapit ;p I dlatego napiszę, że wpis jest fajny i czekam na następne :) Tak jak napisałeś jest już seria informatyka ze szpitala (a nawet dwóch), kolegi z firmy outsourceingowej a teraz jeszcze z uniwerku. Powodzenia w blogowaniu :)

siw   7 #2 26.08.2013 19:28

Miło, że Pani Krysia ma coraz więcej kolegów po fachu :D

GBM MODERATOR BLOGA  20 #3 26.08.2013 20:37

No, ale w taki wypadkach nie ratuje Nagios ? :)

Wydaję mi się że jest faworytem jeśli chodzi o rozwiązania dotyczące monitorowania.

997   5 #4 26.08.2013 21:01

Też pracowałem kiedyś na jednym uniwerku i parę przygód opisałem więc przeczytaj jakie u mnie cuda się działy ;-) Natomiast w obecnej firmie nic takiego nie ma prawa zaistnieć. Jeśli choć na 5 minut coś się schrzani to lecą głowy więc środowisko testowe mamy praktycznie takie jak środowisko produkcyjne. Tak w razie czego. A jakby ktoś chciał zrobić kawał i wyłączyć prąd to mamy zasilanie na 24 godziny + możliwość dotankowania :-P a jak ktoś utnie światło to innym kanałem idzie drugie. A jak ten utną to jeszcze jest radiolinia na dachu ;-) Tak, w razie czego....

bachus   20 #5 26.08.2013 21:02

@GBM: Nagios jest dobry z dość prozaicznego powodu: cena ;-) Wszystko zależy od sytuacji, ale jest kilka rozwiązań, które mogą spisać się lepiej - począwszy od Tivoli Monitoring na BigBrother i bardzo sympatycznym w obsłudze RMM od Level Platforms.

bachus   20 #6 26.08.2013 21:04

@997: najgorszy jest czynnik ludzki, jak przychodzi pracownik i w komentarzach chwali się, jaka jest infrastruktura i co trzeba zrobić, żeby uwalić firmę :>

GBM MODERATOR BLOGA  20 #7 26.08.2013 21:14

@Bachus: Nie mówię nie, ale póki co to styczność miałem z Nagiosem i w sumie wydaje się bardzo dobry w swoim fachu (biorąc szczególną uwagę na cenę)

@997: Stary... ja tą akcję ze światłowodami co opisałeś - to do dzisiaj pamiętam :D

bachus   20 #8 26.08.2013 21:26

@GBM: "Wydaję mi się że jest faworytem jeśli chodzi o rozwiązania dotyczące monitorowania." a potem "ale póki co to styczność miałem z Nagiosem". Hmm ;-)

Co do akcji... Pewien oddział dużej firmy państowej, miałem tam wrzucić serwer. Z tydzień wcześniej rozmawiam z lokalną "panią informatyk", coś ustalamy (czy nie ma innych sieci, serwerów, VOIP itd.) i proszę, aby sieciowiec dał info o VLANach na switchu. Przyjeżdzam na wdrożenie, wchodzimy do serwerowni, pani informatyk czegoś nerworo szuka na dnie szafy, dość zakłopotana:
- "był sieciowej i mówił, że "zdjął VLANy" ale nie wiem, gdzie położył.

GBM MODERATOR BLOGA  20 #9 26.08.2013 21:44

@bachus: brak edycji (przepraszam) - powinienem dopisac że bazuję na opiniach znajomych, którzy są bardziej doświadczeni w kwestia adminowania :)

A to stara anegdota jak świat ;p

bachus   20 #10 26.08.2013 21:48

@GBM: wrzuciłem to w kilka miejsc, więc może i anegdota z tego powstała.

GBM MODERATOR BLOGA  20 #11 26.08.2013 21:49

@bachus: Słyszałem ją ostatnio w pracy (nie pierwszy raz ;d)

bachus   20 #12 26.08.2013 22:00

@GBM: historia gdzieś z 2006-2007 roku, wrzucałem na kilka for, w ostatnim czasie na antyweb.pl i WSS.pl. Mi też już tą historię opowiadano jako "swoją" z tym, że z podaniem dokładnie nazwy firmy i oddziału - czyli któryś współpracownik dokładnie powtórzył :>

GBM MODERATOR BLOGA  20 #13 26.08.2013 22:05

@bachus: Patrz Pan, widzisz - takie cenne doświadczenie że każdy sobie przypisuje, nic tylko zazdrościć :D

Samurai   16 #14 26.08.2013 22:30

@997
Pamiętałem, że ktoś już opisywał swoje perypetie z siecią uczelnianą, ale nie umiałem sobie przypomnieć kto ;p

@GBM i bachus
Każdy taki system powiadomień odpowiednio skonfigurowany jest dobry (czy to płatny czy nie) problem pojawia się właśnie jak odetnie się go od sieci i nie jest w stanie nas powiadomić ;p

Co do anegdot. Kolega administrował kiedyś siecią osiedlową podzieloną na 3 segmenty w dwóch właśnie miał ustawiony jakiś system monitorujący (nie pamiętam jaki) w ostatnim segmencie nie miał. Pytanie jakie pierwsze się pchało do głowy dlaczego? Na co on odparł w tym ostatnim segmencie miał użytkownika, który jak nie miał internetu 2 min od razu dzwonił, że coś jest nie tak z netem niezależnie od pory dnia czy nocy. Powiedział, że to był najlepszy system monitorujący jaki w życiu używał ;p

Shaki81 MODERATOR BLOGA  38 #15 26.08.2013 22:46

No i jak zwykle - problemem jest człowiek, a nie nowoczesne technologie:)

dzikiwiepsz   12 #16 26.08.2013 22:52

ciekawe czy tu też będzie cała seria "John Doe"

jaredj   10 #17 27.08.2013 00:53

@Samurai - dzięki
@bachus - dość mocno lobbowałem, żeby zakupić Tivoli, ale po podliczeniu wyszło, że nas na razie nie stać, szczególnie przy darmowych alternatywach. testowaliśmy też zabbix, oracle grid control I jeszcze parę innych. na razie jest zabbix.
@dzikiwieprz - mam tematy na przynajmniej kilka wpisów. seria to już dwa ;) ale mam nadzieję, że na dwóch się nie skończy.

djDziadek   17 #18 27.08.2013 07:58

@jaredj - świetny wpis, zawsze najfajniejsze są te "z życia wzięte", czekam na więcej, bo pamiętam moje uczelniane czasy i cuda z siecią, które się wtedy działy ;)
Co do sieciowców... sam się w to bawiłem i zawsze problemem były braki w komunikacji... :)

jaredj   10 #19 27.08.2013 10:20

@djDziadek - dzięki :)
Sieciowcy są często bardzo pewni działania "swej" sieci ;) Niestety czasem dzieją się rzeczy, które nawet oni nie są w stanie przewidzieć. Napiszę wpis o tym też, teraz króciutko - był kiedyś problem z pojedynczym serwerem, po prostu nie widział nic poza swoją podsiecią. Okazało się, że jeden ze switchy był skonfigurowany pod to konkretne IP i miał nie puszczać go poza tą podsieć. IP było dzierżawione przez inny serwer, złomowany już. Ale byli pewni, że to nie ich wina, dopóki nie udowodniłem, że z serwerem wszystko okay, tylko coś mu nie daje wydostać się poza pule 255 adresów.

Z programów monitorujących testowaliśmy jeszcze Spiceworks. Nie podszedł mi bo oparty na windowsie, ale poza tym - całkiem przyjemny.