Шта је све научено захваљујући паду сервера и сопственим грешкама

Пре неки дан је објављен не-технички и не-стручни текст, такорећи чист блогерај једног анонимног програмера који је зборио о мукама са великом платом који је из неког разлога убио са лудачким интересовањем заједнице – што је довело до огромног броја посета те уз грешку на самом хостингу и лошег тајминга објаве – све оде дођавола и сервер и сајт и све.

Ево мало детаља, можда некоме помогну у разумевању грешака са њиховим серверима

Зашто је сајт пук’о на 2 сата?

Десило се да је хостинг провајдер неколико машина под Windows Server-ом и највероватније МSSQL базама привремено пребацио на исти физички хост где се налазио блоговљев (блогов, блоговски, јебем га како се каже) VPS и ту су требали да буду дан или два макс док се не пребаце на сервер намењен само за њих. Те машине или неке од њих су у пола дана почеле са лудачким уписивањем и читањем по диску а диск је дељен са свим VPS-овима на том хосту и због великог броја тих I/O (Input/Output) операција процесору на мом VPS-у се десило нешто што се зове – крађа процесорског времена.

Колико се процената процесора краде можете видети Линукс командом top, колона st или ако имате инсталиран „sysstat“ можете видети историјски све као у фотки изнад, командом: sar -u

Нисам испратио пре објаве тог ултра читаног текста ову вредност, чак сам сличну зајебанцију са неког другог провајдера пријавио у једној од најбољих Фејсбук група намењеној тој хостинг науци Хостинг Србија.

Елем, 90% украденог CPU времена које нисам испратио на сопственом VPS-у и баш ко у инат и баш кад не треба, одобрих и објавих најчитанији текст на блогу изгледа – икада (иако ни сам не знам зашто је толико интересантан свима), огроман број http захтева на 10% процесора мученог, load сервера оде на колико се сећам 200, VPS недоступан и било га је могуће само рестартовати кроз хостинг панел.

Load сервера – то је нешто што доста људи не конта баш најбоље, али укратко: ако је load већи од броја додељених језгара то веће срање на систему.
Да објасним у „human-friendly“ формату (ово је иначе дифолт објашњавање load-а свих сисадмина људима који нису системаши): Ако сконтамо једно CPU језго као једносмерни пут са једном траком (4 језгра рецимо пут са 4 траке итд), load 1 би био да је пут пун али се саобраћај одбија нормално, load 2 би био да исти број аутомобила покушава да се прикључи путу из споредних улица и укључења тако да ће се саобраћај и даље одвијати али успорено јер ће неко морати да пропусти кола да се укључе (или неће) – и дакле, саобраћај ће се одвијати и даље али гужва на Газели, 2 пута више аутомобила него што једна трака може да поднесе, load 0.5 би значио да на путу нема гужве и има луфта за убрзање а load 0.1 би значио да на путу тек понеки ауто прође понекад. Е, ја сам имао пут са 4 траке и 30 пута више аутомобила него што су те 4 траке могле да приме аутомобила – тотални колапс саобраћаја, ни саобраћајна полиција не може да помогне. На load утиче – оптерећење процесора, меморије, активност хард диска и мрежне картице (I/O).

Научена лекција: Иако ће ме многи одмах напљувати, ма шта био званичан одговор на питање „Шта је VPS“ – VPS заправо само напреднији дељени (shared) хостинг јер и даље делите ресурсе са другим корисницима (најкритичнија ставка диск). Провајдери иначе примењују тактику да поставе I/O лимит што је у неку руку добро – због ових горенаведених разлога, а у неку и не – јер кад ти затреба нешто захтевније опет ће се десити проблем за забодом машине јер ти је I/O лимитиран.

Ако треба да будеш сам свој серверски газда онда узимај или наменски (dedicated) сервер или нешто моћније, скалабилније и са јачом инфраструктуром (IaaS) типа AWS, Google Cloud и слично.
Елем, како је хостинг провајдер суспендовао Windows машине које су гушиле диск – све прорадило али проблеми остали јер…

Зашто сајт није радио за неке кориснике скоро 3 дана после пуцања иако је load сређен?

…док се све ово дешавало, рекох „хајде да док чекам провајдера д’убије крадљивце CPU-а, ја ово кокнем на CDN и угушим load колико толико, ништа ме не кошта“ ионако блог није корпоративни или ми доноси некакав профит па да се нешто стресирам, да не ради и месец дана не бих се нешто потресао.

Отворим ти ја налог на CloudFlare-у, додам сајт, пустим пропагацију нових CloudFlare NS (Name Server) уноса, завршило се у року од 5 минута али….али кита – бесплатни план CloudFlare CDN-а, са постојећим SSL сертификатом на сајту се шиба, долази до грешке при приступу сајту а решење би било пребацивање сајта на http, па постављање неког бесплатног SSL сертификата које CloudFlare нуди и ради само на неким браузерима – али ме мрзело да се јебавам тим, па вратих све као што је било тј вратим назад NS уносе као што су и били и пар минута после суспензије VPS-ова крадљиваца. Дакле од пребацивања на CloudFlare NS па до враћања на NameCheap NS који сам користио пре ове јебаде – је било око 20 минута. Нови NS су постали живи после 10-так минута, приступ сајту је био опет могућ. брз и најнормалнији, погледам у Гугл Аналитици у реалном времену – посета око 600, а load око 0.5 (8x мање оптерећење од дозвољеног за 4 CPU језгра)…

…али само за неке кориснике. Неки корисници нису могли сајту да приступе ни после 2 дана, иста грешка. Иако је пропагирање дифолт DNS рекорда прошло скроз (проверавао на dnschecker.org) неким корисницима је kompjuteras.com и даље бацао IP адресу CloudFlare-а (хвала Николи Илићу на провери). Све провере које сам радио – бацале су да домен гађа исправан сервер – али су неки корисници и даље приступали CloudFlare-у, зашто?

Проблем су правили локални DNS cache на самом лаптопу и DNS cache код наших интернет провајдера. Онај коме је DNS био подешен рецимо на Google (8.8.8.8 и 8.8.4.4) је сајту приступао нормално, онај коме је DNS био дифотни од интернет провајдера – имао је горенаведену грешку. Сајту се приступало нормални и преко Тора и преко kproxy.com и многих осталих јавних вебпроксија које сам проверавао. Неким корисницима којима јесте био подешен Google DNS и даље се јављала грешка – зашто? Јер је компјутер вукао локални DNS cache. Тако рекох горепоменутом Николи да очисти локални DNS cache, како је то урадио проблема више није било.

Иначе локални DNS cache се на Виндовсу чисти тако што се отвори command prompt (као Администратор) и окине команда: ipconfig /flushdns (некао је потребан и рестарт браузера који користите). На Линуксу, зависи од дистроа до дистроа – на ЦентОС 7-ици је ако се не варам: systemctl restart dnsmasq.service. Опција „Зољом га звекни“ јесте рестарт компа. Локални DNS cache код провајдера – на њега не можете да утичете и он док сам не излапи – џаба ти. Дакле – иако сам се са променом NS уноса, CloudFlare-ом и враћањем на старо зајебавао укупно 30 минута – због пропагирања DNS-а, и DNS cache уноса код корисника и интернет провајдера проблем је остао наредна максимална 72 сата. Контактирао сам и NameCheap подршку везано за овај проблем и она је потврдила исто – морате сачекати максимум 72 сата да се пропагирање заврши.

Научена лекција: Кад се играш са DNS рекордима – ако ниси сигуран шта радиш (као ја што нисам био сигуран за комбинацију CloudFlare – постојећи SSL) – немој да радиш. Иако се поиграш на пола сата – проблем можеш имати наредна 72 сата колико максимално може трајати пропагирање тих уноса (мада обично потраје око сат-два-три, али ето – Марфи)

Не вели џаба матори људи – на грешкама се учи. Грешке праве сви, неки их јавно истртљају, неки их направе па крију како знају и умеју, неки их праве мало, неки их праве много. Грешке су нормалне (погледај обавезно овај gif о успонима и падовима). И највећи стручњаци на планети могу направити грешку. Ја волим рећи – „Једина непоправљива и глупа грешка која те може коштати и из које не можеш научити неку животну лекцију је – да се убијеш“ а има и она стара српска пословица која каже – shit happens. Јебига, научиш нешто из свега и ћерај даље.