Ето текста на презентацията ми от Openfest 2012 за това как 700 сървъра се поддържат по-лесно от 3. Оставил съм бележка на кой слайд съм, понеже има няколко полезни картинки из презентацията (pdf, odp).
Update: видео запис.
[слайд 2]
Занимавам се със сървъри в общи линии от малък и винаги ми е било интересно. След като в последните 3 години се занимавах с една голяма система (около 750 машини, 7.5PB място, 260gbps трафик в разни моменти) открих как големите системи са по-лесни за поддръжка, понеже ни карат да правим нещата по правилния начин (иначе просто няма да се справим).
Също така искам да отбележа, че аз съм адски мързелив и не много умен (за последното даже имам издаден документ от МЕНСА) и намирам това за лесно, т.е. според мен всеки, който реши може да се справи:)
[слайд 3]
Това е снимка от едно от първите неща, с които съм се занимавал (за съжаление нямам снимка на първия си сървър, как стоеше до един шкаф с 6-7 модема и това си беше цялата система). Да сравним с
[слайд 4]
тези две снимки, на които отляво можем да видим извънгаранционни гръмнали дискове (около 400бр.), и в дясно пак извънгаранционни гръмнали сървъри (няма как да се направи снимка на работещите машини, която да е достатъчно интересна).
[слайд 5]
Малко бележки, преди да започна – аз различавам три типа “операции”.
Първият тип е малката фирма. Там има един-два-три сървъра, системният администратор поддържа всичко, от климатиците до базите данни и web сървърите, не му дават много време да спи, няма особено голям бюджет и като цяло всичко се прави по неприятен и неефективен начин.
Вторият вид са големите, “enterprise” операции – като пример мога да дам телекомите (които за мен са много повече неприятен начин на мислене, отколкото нещо друго) – това са компании, които разработват и изобщо разбират частично технологията си и основно плащат на външни фирми много пари, които после да могат да поемат вината за проблемите, и да реагират в някакво време (например 2-4 часа) за да оправят счупеното.
Третият вид са тези, за които ще говоря, и които по принцип наричам “порно компании”, поради това, че повечето от по-големите фирми, които се занимават да сервират и т.н. порно по интернет са такива (но и twitter, reddit, github също си приличат с тях). Това са операции, които сами поддържат почти цялата си инфраструктура и продукти, които използват почти ексклузивно open-source софтуер, дописват го за собствени цели и успяват с бюджет, който е с един-два пъти по-малък порядък от enterprise хората да постигнат толкова или повече.
(има четвърти тип, който пропуснах на лекцията, гигантите като facebook и google, от които идват някои от идеите по-долу).
И понеже има шанс да се появи въпросът “тия неща какво значение имат, като всичко ни е в облака”, малък отговор: облакът ни дава нещо, което е много подобно на моите железа, просто няма нужда да си поддържате сами хардуера. Поддръжката на хардуера поне при мен за 700 машини отнема средно по около час-два на седмица. Останалото си важи с пълна сила.
[слайд 6]
Големите системи ни принуждават да научим някои неща, без които никога няма да можем да се справим с натоварването. Разширяването на системите е много по-лесно от разширяването на персонала и доста по-ясно като задача, та ако не се работи правилно, много често админите на някаква система издъхват, преди да е стигнала някакви сериозни размери. Изброил съм доста от полезните уроци, които са ми улеснили много работата – повечето ги има в хубавите книги.
Изобщо, ако ви е интересна темата, идете и прочетете “The practice of system and network administration”. Ще откриете много интересни работи…
[слайд 7]
Да започнем с мониторинга. Лафът “има два типа хора, такива на които им е гърмял хард диск и такива, на които ще им гръмне” ми е толкова любим, че чак го написах в презентацията …
Поддръжката на система без monitoring е подобна на шофирането сляп и глух. Няма да имате идея какво правите, какво се случва и какво го предизвиква и в общи линии ще трябва да гадаете.
Имам една примерна случка от съвсем наскоро – един приятел има лична машина, co-locate-ната някъде, на която има два RAID1 масива с по два диска. Преди около година един диск от единия масив отказал, след това преди 3-4 месеца отказал още един диск, но от другия масив. По някое време един негов приятел минавал през colocation-а и после му казал “абе ти знаеш ли, че на твоята машина отпред светят две червени лампички?” (някъде тук моя приятел твърдеше, че colocation support-а е трябвало да му каже, че има такова нещо, но те няма откъде да знаят това дали е нормално или не, няма стандарт за нотификация от предните панели). Та, тръгнал той да сменя дисковете, но докато се накани му гръмнал още един диск, а докато backup-вал – и последния.
Както би казал Captain Hindsight в такъв случай – “трябвало е да има monitoring и това нямаше да се случи”.
Monitoring-а ви пази от downtime – ще видите гръмналия диск преди да стане бедствие, пълнещата се файлова система преди базата ви данни да спре да може да изпълнява заявки или mail server-а ви да може да приема поща, ще ви каже, че някой service ви е спрял и какво ли не още.
Също така monitoring-ът ще ви даде данни за бъдещо планиране – колко трафик правите, с каква скорост си запълвате ресурсите, в кои периоди може да очаквате повече или по-малко натоварване, и т.н., и т.н..
Аз лично ползвам nagios за всичките си машини, включително и за някои неща по работната ми станция вкъщи.
[слайд 8]
Тук съм показал как изглежда моя системен статус – това е nagios checker, plugin за firefox, който показва постоянно статуса на един или няколко nagios-а (това е редчето най-най-долу) и при on-mouse-over показва по-подробен статус (всичко останало, което се вижда в жълто/червено). На този се вижда как два от ftp сървърите са малко по-натоварени, има 4 дискови масива, които се rebuild-ват, два масива дето са изхвърлили по един диск, един масив, който си мисли по въпроса и един IPMI модул, който изглежда е изгорял.
Има варианти на plugin-а и директно за gnome или каквато работна среда ползвате, всеки както му е удобно. Много хора ползват външен монитор или нещо такова да им стои там целия статус.
[слайд 9]
Може да видите няколко публични примерни monitoring-а – моят публичен nagios, един munin пак за същите машини (страхотен tool, лесен за конфигуриране, прави много добри графики и писането на plugin-и е направо радост за душата), и един пример за великолепно подкаран nagios с много услуги. Моят например има по 7-8 услуги за машина, които се следят, те имат по 20-30 и все подходящо измислени, препоръчвам на всеки да погледне какво и как следят.
[слайд 10]
Това е нещо старо като света, даже го намерих в една книга за писане на бази данни от 1992ра. Идеята е, че за една система не трябва да се налага да се променят няколко различни места, когато се прави промяна по нея – не трябва да се пипнат конфигурациите на 8-9 различни неща и да се направят други 10 действия, понеже хората грешат, ние сме хора и ще сбъркаме нещо. Или ще пропуснем определено действие, или ще объркаме нещо, докато го правим, а ако направим скрипт, който от една централна конфигурация да създаде всичките тия конфигурации и направи действията, първо ще си спестим работа, второ ще си спестим грешки. Скриптовете определено грешат по-рядко от хората…
Този съвет за съжаление рядко е използваем в малки системи.
[слайд 11]
Тук съм дал един мой примерен скрипт, който генерира конфигурация на dhcp сървър. Скриптът е грозен до смърт и съдържа в себе си три езика – bash script, SQL и dhcp config – но съвсем накратко прави следното: генерира един конфигурационен файл, тества дали е различен от текущия, ако да – пробва да рестартира с него, и ако не сработи, ми праща mail и връща старата конфигурация. Елементарно е да се напише, работи като слънце и не ме кара да правя много неща – този скрипт и още няколко се изпълняват от cron-а и всичко се update-ва без никаква човешка намеса.
[слайд 12]
На този слайд съм показал как изглежда при мен базата, в която описвам какво имам. Определено има какво да се желае и част от нещата не са пряко свързани с конфигурирането на машините, но и тази проста схема е съвсем достатъчна, за да мога да си поддържам нещата в ред.
(например ми се иска някой ден да направя пълна инвентаризационна система в това и да мога да следя кой компонент с кой сериен номер ми пробутват обратно, след като съм го върнал за ремонт)
[слайд 13]
Автоматичните инсталации са нещо почти животоспасяващо, а и аз при мен съм решил въпроса по толкова готин начин, че не мога да не се похваля :)
По принцип началната инсталация е мястото с най-много грешки. Във всеки един инсталатор има м/у 20 и 100 избора, които трябва да се направят, особено ако става въпрос за сървър и потенциалът за грешка или просто различна инсталация е огромен. Вероятно няма начин един човек да направи 10 инсталации през debian-ския инсталатор за една седмица и да направи 10те машини еднакви (има шанс и 10те да са съвсем различни). Да си оставяте такава дейност е като да си пречите сами.
(за съжаление и това е безсмислено за по-малки системи, ако имате един сървър, няма от кой да е различен)
Това доста хора го научават бързо, и на местата, където машините се дават preinstalled (като например всичките инстанции по cloud-овете) хората си имат един малък скрипт, който качват на машината и който я довежда до желаното до тях състояние.
При мен инсталацията представлява следното: първо ми монтират машините в rack-овете и ги настройват да boot-нат по мрежа. Машините тръгват, зареждат през pxe/nfs един image, в който тръгва нормална операционна система, на която последният и boot script (/etc/conf.d/local.start, понеже е gentoo) стартира един мой скрипт, който от своя страна се свързва с една централна машина и казва “здрасти, аз съм с mac адрес еди-кой-си”. Централната система проверява този mac адрес на кой switch/port се намира, проверява в таблицата със сървърите (вижте на слайд 12) какво трябва да има там, дали е работещо или не и или казва “не прави нищо, не знам за тая машина/вече е инсталирана”, или дава нужните настройки като hostname, ip, net, gw. Ако има получени настройки, скриптът създава partition-и, прави файлови системи, настройва разни полезни неща като адреси на ipmi контролера и парола за него, разархивира един готов image, сменя по файловата система настройките като за машината, рапортува на централната система, че е готов и рестартира. Централната система си отбелязва, че машината е готова и че трябва да и даде да boot-не нещо друго на следващия път.
След което аз на сутринта си пускам лаптопа и виждам – а, имам още 18 инсталирани машини, хайде да им качвам съдържание (което също се прави с една-две команди). Мисля си, че единственият по-мързелив начин щеше да е да ми ги пращат готови инсталирани.
[слайд 14]
Тук малко ще се отклоня и ще се опитам да обясня колко важна е автоматизацията. Системните администратори сме мързеливи и ТРЯБВА да бъдем – хората, които не ги мързи ще си кажат “защо да автоматизирам това просто нещо, ще ми се налага да го правя само веднъж седмично/веднъж на ден” и в един момент се натрупват достатъчно такива дреболии, че не им остава време да се огледат и се получава “death by a thousand cuts”. Мързелът е важен, и може да видите на
[слайд 16]
програмист, който тренира за системен администратор.
[обратно на слайд 14]
Всичко, което се прави често, трябва да се автоматизира. Всичко, което се повтаря и се прави рядко – също, защото има шанс между две правения да забравим как става. Научете се да пишете код и пишете, това ще ви спаси живота. Няма нужда даже да е добре, ето един мой пример:
[слайд 15]
Това е един много прост скрипт, който проверява кои машини са report-нали, че имат проблеми с дисковите масиви, логва се да види какво се случва и ми вади списък в следния вид:
rack/cage (SD id) server port serial
XXX/DA3:20460 (CUST.YYY) s333 p9 JPW9H0HQ2XS8AH
XXX/DA3:20460 (CUST.YYY) s452 p5 JPW9J0HD1J3JMC
XXX/DA3:20460 (CUST.YYY) s542 p3 JPW9N0HZ0MN8JL
Това аз мога да го пратя на човека през океана, който да иде на място и да ги смени. Не съм направил скрипта и да праща поща, понеже има няколко случая, в които и аз трябва да погледна, преди да съм сигурен, че дисковете може да се извадят спокойно.
(някой ме беше попитал защо там има ssh root и т.н. – първо аз ползвам ssh agent и няма как някой, който се добере до машината да добие лесно достъп до всичките, и второ аз работя само от root – аз admin-ствам тези машини и почти няма команда, която да може да работи от нормален потребител, а да пиша sudo на всеки ред е безсмислено).
[слайд 17]
И една леко религиозна тема – трябва ви хубав naming convention. Това е от нещата, за които просто няма друг начин при големи системи. По принцип важното е имената да са лесни за произнасяне и запомняне (доста хора използват филми/сериали като източник (Simpsons), други използват фентъзи книги (в Толкин има около 200-300 героя, в Малазанска книга на мъртвите – около 1000)). Аз лично за тази система използвам съвсем простата конвенция от една буква, определяща функцията на машината (w – web server, d – db server, s – storage) и номер. Така знам машината какво прави само по името и е съвсем лесно да я кажа на човека отсреща, който се намира в шумния datacenter и около него вият 10-15000 вентилатора.
(от друга страна, личните ми машини имат съвсем random имена, щото са малко и защото успявам да ги запомня – marla, tyler, cassie, lain, alpha…)
[слайд 18]
Резервните пътища са нещо също много важно. Почти всеки, който някога е администрирал каквото и да е отдалечено си е отрязвал клона, на който седи (в слайда има прекрасен пример с ifconfig eth0 down).
Искам да дам три примера от при мен за резервни пътища. Първият е как всеки сървър при мен има IPMI модул, който има отделен мрежов порт, закачен за отделен switch, така че да мога да стигна до машината и да видя какво се случва с нея, ако се налага, както и да мога да я командвам. Това дава възможност да разбера например, че дадена машина е прегряла и се е изключила, вместо да се чудя дали не е проблем в мрежовия и порт.
Второто и най-явното нещо са резервни мрежови връзки, които в общи линии правят “цикъл” в мрежата и не се използват активно, но през тях може да се мине и да се стигне до сървъри, които иначе са недостъпни поради проблем в хардуера, или поради строшена (от мен) конфигурация. Някъде тук искам да кажа, че това е един от уроците, заради които казвам, че системните администратори се учат на гърба на потребителите – това човек не го схваща, докато не му се случи поне няколко пъти.
Третият пример е малко по-странен, но пак подобен – всичките ми машини по принцип boot-ват по мрежа (което улеснява много някои неща), но освен това могат да boot-нат нормалното за тях нещо от диска си, ако мрежата не им отговори на време. Така дори да има проблем със сървъра, от който тръгват или с някой switch по пътя, те пак ще запалят и ще могат да работят. Така най-малкото избягвам старта на цялата система да зависи твърде много от нещо централно.
[слайд 19]
Може би понеже аз съм тръгнал от интернет доставчик ми е странна идеята някой друг да ми оперира мрежата, но това се оказва стандарта в момента – хората си наемат/слагат машини в някой datacenter, от datacenter-а им дават internet и мрежа през един порт на всяка машина и така цялата комуникация между компонентите на една система става 1) през порта, който е и за външния трафик и се бори с него и 2) през мрежа на някой друг, с различни цели и съответно такава, на която не може да се вярва. Мрежата е централен компонент на всяка една система в наши дни и невъзможността да знаете какво се случва в нея и невъзможността да го променяте/контролирате ви ограничава сериозно.
(например моята автоматична инсталация нямаше да има начин да става толкова лесно, ако не си контролирах мрежата)
Една фирма, с която работих преди известно време имаше огромен проблем с това, че не си контролираше мрежата – те са по-големи от това, с което се занимавам (имат около 1800 машини в 4-5 големи datacenter-а) и съответно понеже им се налагаше да репликират mysql през internet, бяха правили някакви страшни и почти гениални изпълнение, за да им работят нещата, а докато бях при тях, основните проблеми идваха от мрежата.
Също така собствената мрежа ви дава възможност да пуснете BGP, да си вземете ASN и за всякакви такива други хубави трибуквени съкращения :) Така може да купувате свързаност от няколко различни доставчика и да не трябва да им търпите проблемите.
Ще говоря накрая и за една много хубава моя система за наблюдение на трафика, която пак щеше да е невъзможна без моя мрежа.
[слайд 20]
Ако някой ден се навия да направя по-голям курс по системна администрация (или цяла магистратура), изпитът на края ще се проведе по следния начин: ще хвана студентите, ще идем да пием някъде, ще ги пратя да спят и след това ще ги събудя в 4-5 сутринта да решат проблем. Оценката им ще бъде на база на това колко часа downtime са имали.
Нещата трябва да се правят просто, защото проблемите винаги ще изникват в най-лошите възможни моменти и трябва да може да се справите без значение в какво състояние се намирате. Това значи и да може да пазите цялата система в главата си, целият и state, което значи и нещата да са максимално унифицирани (защото колкото по-малко неща трябва да помните, толкова по-лесно ще ги запомните).
Препоръчвам на всички да тестват следното – да се напият, да си си легнат към 12 и да са си навили алармата за 4 сутринта, след което да станат и да се опитат да направят нещо просто (например да решат квадратно уравнение или някой прост тест за интелигентност). Вероятно ще има отрезвяващ ефект :)
Нека да цитирам Jim Gray, “Although there are no textbooks on simplicity, simple systems work and complex don’t.”. Това всички го виждат, но никой не иска да го приеме, понеже изглежда простите системи не са готини, и човек не изглежда умен, ако не направи нещо гигантско и сложно (което после се оказва невъзможно за поддръжка). Както при програмирането дебъгването е три пъти по-сложно от писането, така при правенето на системи работата с тях и оправянето на проблеми е доста по-сложно от измислянето и поне според мен хората, които правят много сложни и “умни” системи не са особено умни.
[слайд 21]
Искам да спомена и малко проблеми, които можем да срещнем в големите системи.
Първият е разпределението на натоварванията и събитията. Нека да дам за пример пасивния ми monitoring – той представлява cron скрипт, който веднъж на 5 минути се стартира и праща малко данни към един централен демон, който обработва информацията. Това при достатъчно сървъри би довело до претоварване на централната система и решението е съвсем просто – един sleep за random секунди (м/у 1 и 60), така че събитията да са пръснати във времето.
Другият е премахването на SPOF (single points of failure). Много често като наследство от времената, в които дадена система е била малка се намират разни компоненти, които ако откажат и цялата система спира да работи. В голяма система това трябва да се избягва и като цяло компонентите да могат да се заместват един-друг или да не са толкова важни, понеже колкото повече отделни части имате, толкова по-голям е шанса някоя от тях да откаже. Ако всяка част ви е жизненоважна, то ще трябва през цялото време да тичате след всеки дребен проблем и да нямате време да свършите нещо реално полезно.
Да се направи нещо дистрибутирано е сложна задача – стъпката от една до две машини (или даже от single thread до няколко thread-а) е тежка и по-сложна от тази от две до хиляда, но определено си струва. Ще ви спести будения посред нощите от големи проблеми и ще ви даде допълнително спокойствие.
(например аз почти нямам компоненти, които могат да убият цялата система със срива си, съответно мога да спя спокойно и каквото и да стане, да мога да го оправя на сутринта, като стана)
[слайд 21]
Ето един пример защо е важно да сме дублирани и да не зависим от отделни дребни неща – понеже редките явления в достатъчно голяма система стават нещо нормално. Този screenshot показва как на машина с 12 диска и 12те са гръмнали в един и същи момент.
Това ми се е случвало два пъти.
(първия път сърцето ми прескочи един път:) )
[слайд 22]
Две интересни неща, от големите системи и от при мен по принцип.
Едното е нещо, което много хора според мен не правят правилно. Много често се казва – имаме нов проект, айде да купим още web, db и т.н. сървъри и да направим отделна инфраструктура, вместо просто да се разшири текущата. Така човек се озовава с много малки компонентчета, от които който и да е ако замине, има някакъв downtime на някаква услуга и съответно пожари за гасене. Разширяването на текущите системи, и дистрибутирането (доколкото е възможно) всичко да може да работи от всяка машина дава огромно scalability, издръжливост на атаки и доста по-спокоен сън. Аз лично трябва да гледам внимателно дали някой ни DoS-ва, понеже при нас нещата са достатъчно добре разпределени, че почти да няма кой да ни засили ефективна атака.
Според мен и така трябва да се борят DoS атаките.
Другото хубаво нещо, което написахме и което исках да пусна да се ползва публично, беше система за следене на трафика и загубата на пакети. При нас ползваме web сървър, който е вътрешно производство, и той праща по един пакет статистика за всеки connection, който е завършил, с данни колко байта и пакета са минали, към кой ip адрес, за колко време, тип на трафика и колко TCP retransmit-а е имало. На база на тази статистика и BGP таблицата аз мога да видя почасово към кои мрежи и автономни системи (и през кои пътища) имам повече загуби и да преценя дали искам да изместя част от трафика някъде другаде.
(след конференцията един приятел се нави да port-не нещото за apache и да пуснем колкото можем от него open-source, та може да има новини по темата скоро)
[слайд 24]
Та, ако ви е TL;DR лекцията, какво си струва да запомните:
1) имайте (добър) monitoring
2) правете нещата толкова просто, че да може да ги ремонтирате в 4 сутринта на пияна глава
3) Автоматизирайте
4) Имайте резервни варианти
(и пращайте корекции на тоя текст, че е писан на един път)
