Lab 2.0

Не очаквах нещата да се развият толкова бързо. Мрежата вкъщи се разрасна с няколко нови попълнения, като двете основни са HP ProLiant DL380e Gen8 и QNAP TS-459 Pro II.

Малко след като се оплаках, че старият сървър ми струва излишно много пари за ток, попаднах на добра оферта в eBay и в момента основният ми сървър изглежда така:

CPU 2*Intel(R) Xeon(R) E5-2407 @ 2.20GHz
RAM 120 GB DDR3 (non-ECC)
RAID 0 Самотно 960GB A-data SSD
RAID 5 3*480GB Kingston SSD в RAID 5
So much room for activities!

Хардуерът е малко по-нов и мога да използвам ESXi 6.0 (HPE Image, Update 3). Засега не усещам особени разлики от 5.5, освен че мога да избера Debian 8 като най-нова дистрибуция при създаването на виртуална машина.

След всички “подобрения” мрежата изглежда долу-горе така:

Новите джаджи са: суич с пасивно охлаждане за “сървърното”, access point от Ubiquiti и, разбира се, двата нови сървъра. На диаграмата по-горе липсват виртуалните машини и VPN-а към droplet-а в DigitalOcean и хостинга в SiteGround.

HP

Забавата започна още с пристигането на сървъра. Не знам дали по време на транспорта или преди това му се е случило нещо, но единият му край е изкривен. За щастие е този със серийния порт и не ми пука особено много за това. Ще го мисля, когато стане време да го вкарвам в истински шкаф.

Като изключим това изкривяване, всичко друго работи идеално.

Знаех, че 2U машините са шумни, но не очаквах да е толкова шумно. Прекарах близо 8 часа първия ден да разбера защо всички вентилатори са постоянно на 20%. След всевъзможни ъпдейти, флашвания и версии на ESXi се оказа, че е заради 4-портовата LAN карта, която седи на единия PCI riser. Разкарах я и вентилаторите се оправиха.

Научих, че това с вентилаторите е основен мотив в работата с HP сървъри – ако нещо не му харесва, получаваш излитащ реактивен самолет. Хубавото е, че не винаги можеш да разбереш какво не му се харесва. В крайна сметка нещата се нормализираха и вентилаторите работят между 7 и 19%, което го прави по-тихо от настолния ми компютър. Ако не ми писне да си играя с истински машини, смятам, че следващият ми сървър ще е някой стар Dell. При тях поне вентилаторите могат да се регулират през IPMI.

Миграция

Миграцията беше забавно преживяване. Отделих малко повече време да помисля как да направя някои неща и накрая се превърна в инсталиране на повечето неща отначало.

Преди да дойде QNAP-а, важните ми данни бяха на една от виртуалните машини, която ги сервираше през Samba и NFS. Върху един (чисто нов) диск в RAID 0, който често казваше това:
Без да имам бекъп.

Подозирам, че диска се дънеше заради моя грешка. На NAS виртуалната машина бях заделил 800GB виртуален диск, но “thin provisioned”. Всичко е хубаво, докато не стигнем момента, в който на един datastore има много машини с thin provisioned дискове и започнат да се карат, защото сумарно обещаният им капацитет е невъзможен. Все още само подозирам, защото не ми се губи време и енергия в репродуциране на проблеми с данни, които са ми важни. Освен това се случваше само при последователно четене и писане на няколкостотин гигабайта.

В момента тази виртуална машина държи основно NextCloud и transmission. Чакам момента, в който ще си допиша скрипта за правилно копиране на данните по правилните места, за да не местя на ръка, каквото ми трябва. Най-вероятно този момент ще дойде, след като диска се предаде изцяло.

Най-хубавото на новата машина (освен 120-те GB RAM) е, че дърпа между 75 и 95W от контакта (според Ubiquiti mPower). Това е при 10-11 работещи виртуални машини със средна натовареност. За сравнение – предният дърпаше 256, докато не прави нищо. Relevant Grafana:

Преди и след

Подобрих и скрипта за scrape-ване на цената на тока. Все още тормози сайта на енергото постоянно, но поне вади точна цена.

Друго интересно нещо за този сървър е и това, че съм принуден да държа един SAS диск в него иначе вентилаторите пак скачат на 20%. Без този диск потреблението му пада и под 69W. Причината за това е, че някой не може да прочете правилно температурата на не-HP дисковете и се паникьосва. Оставяме спорът за proprietary lock-in темите за друг път.

Някъде в бъдещето може би ще му купя нови процесори, но в момента е неоправдано, защото не съм усетил нещо да ми е бавно.

Услуги

С многото памет идва и много място за игра. Към момента има 12 виртуални машини, като постоянно работят 11 от тях, а 8 са сложени с autostart. Сред по-интересните нови услуги, които пуснах са: Home Assistant, UniFi Controller, Kubernetes и Portainer.

В Home Assistant засега само следя кой колко ток дърпа.

Разклонителят, на който са вързани сървърите и AP-то, праща статистики към Home Assistant по MQTT.

Само бях чувал колко са удобни нещата на Ubiquiti. Инсталацията на контролера и adopt-ването на AP-то са елементарни. Работи толкова стабилно, че забравям за съществуването му. За разлика от предишното решение за WiFi, при което трябваше да рестартирам рутерите през ден.

Подкарването на Kubernetes cluster-а се оказа по-трудно, отколкото очаквах. Кой да предположи, че четенето на документация ще помогне. Крайният резултат е, че имам работещ cluster с един master и 4 node-а.

Целта е някои задачи в Jenkins-а спокойно да си пакетират image-ите и ги деплойват върху Kubernetes. За това пуснах машина с Portainer, на която върви контейнер с Docker Registry, където се намират няколко проекта, които трябваше да са пробни, но вече над месец са продукционни. Контейнери върху контейнери, върху контейнери…

Недостатъкът в момента е, че за всяко приложение добавям правилата в HAProxy ръчно вместо да го пусна като ingress controller. Някой ден може и до това да стигна.

Покрай цялата работа с много машини и контейнери, върху които трябва да се изпълняват едни и същи команди, започнах да си играя с Ansible. Така правенето и развалянето на клъстера се свеждаше до викане на няколко Ansible ad-hoc команди вместо да се логвам на 4 машини и да пиша едно и също. Наложи ми се да създавам клъстера (поне) 6 пъти преди да разбера какво правя грешно и да стигна до работещо решение.

Шкаф

Наложи се да сглобя “шкаф” за всичката техника, защото нещата започнаха да изглеждат много зле и чистенето на прах беше зор.

Преди

Тъй като реших да си купя истински rack чак когато имам къща, засега ще се задоволя с това произведение на инженерен гений:

В SOLIDWORKS изглеждаше лесно – 12U шкаф с масивни стени, добро охлаждане и т.н.
Реалността е малко по-различна
Отзад има какво още да се желае

QNAP

Всичко е прилежно подредено!

За QNAP-а нямам много за казване. Също като продуктите на Ubiquiti, това просто работи и забравям, че го има. Взех му 4 диска по 4 TB, за да съм сигурен, че ще имам сигурно място за важни неща още известно време. Дисковете са в RAID 5, а не 6, защото съм лаком за място. Така 4 диска по 4 TB ми дават малко над 10 TB използваемо място. След преместването на всичко от стария сървър и старата “NAS” машина, от 10-те терабайта останаха 8.59 TB. Надявам се да изкара няколко години преди да ми се наложи да го сменям, защото максимумът на volume, който може да се направи на тази машина е 16TB, което означава, че текущата конфигурация е максимумът, който мога да имам в RAID 5 без да правя компромиси. На теория можеше да сложа и 4 8-терабайтови диска, но тогава излизам от официално поддържаните конфигурации и ще е трудно да правя промени по масива.

Докато чаках да дойдат големите дискове, бях сложил един 2 TB и вместо да копирам всичко, реших да опитам да мигрирам от RAID 0 към RAID 5 с няколко 4 TB диска, след  което да махна малкия и да мигрирам към RAID 5 с пълния капацитет на дисковете. Това се оказа изцяло ненужно упражнение, защото беше бавно (ден и половина) и в крайна сметка направих всичко наново. Онлайн RAID миграцията също е интересно нещо.

 

Смятам, че скоро нямам какво да бутам по сървърите, докато не стане време да купя още няколко диска за основния. За първи път, откакто се занимавам с тези неща, всичко ми е удобно и работи точно както го искам. Да видим колко дълго ще продължи това.

Lab

Update: Lab 2.0

Както писах преди, от доста време искам да имам физически сървър вкъщи, който да си администрирам и гавря, както реша. В началото на годината по щастливо стечение на обстоятелствата това се случи и в момента се радвам на един HP ProLiant ML350 G5.

Това се оказа несвършващ проект и от януари не съм спирал да си играя и да уча нови неща. От по-важните услуги, които се търкалят засега, са: OpenVPN, HAProxy, Let’s Encrypt, Pi-hole, FreeNAS, Jenkins, Graylog, Transmission и NextCloud.

Сървър

Първо спецификациите на сървъра в текущото му състояние:

CPU Един Intel Xeon E5440 @ 2.83GHz
RAM 32GB FBDIMM ECC (8 по 4GB)
RAID 5 3*250GB
RAID 0 1*2TB

За момента RAID конфигурацията е такава, защото: а) не съм купил дискове за повече и б) нямам caddy-та за останалите два слота. Предстои ми доста интересно приключение, когато реша да разширявам storage-а. Нямам търпение rebuild-а на някой масив да гръмне. Най-вероятно ще трябва да купя още един RAID контролер и да присадя drive cage на мястото на CD-то, за да има къде да сложа всичките дискове, които искам. Шест 4-терабайтови диска в RAID 6 биха били достатъчни за известно време.

На RAID 5 масива се намира ESXi 5.5 (HPE image) заедно с datastore-а за някои виртуални машини. На самотния 2TB диск е storage-а на NAS-а, където има разни важни файлове.

Бързо се отказах да обновявам графиката на цялата мрежа вкъщи, защото се променя постоянно. Последната стабилна итерация изглеждаше така

Малко след като нарисувах горната графика, lime2 се пенсионира и вече не е backup OpenVPN. Намира се в процес на прехвърляне на всички неща от стария OwnCloud и backup partition към NAS-а. Тази малка машинка беше цялата ми инфраструктура допреди няколко месеца.

Чувството всички (важни) машини да са свързани през гигабитова връзка е прекрасно! Мога да редактирам видео файлове в Premiere Pro, които се намират върху FreeNAS-а, който работи върху една от виртуалните машини, без да усетя някакво забавяне. Няколко клиента спокойно стриймват видео файлове през SMB, nfs и каквото още дойде, без да има никакви проблеми*.

Най-накрая подкарах и Grafana, която да ми харесва и върши работа, а не да е просто eye candy. Повечето данни идват от Telegraf, който ги събира по SNMP и ги пази в InfluxDB.

По-интересните неща, като цената на тока и данните от ESXi, идват от един Python скрипт, който използва SDK-то за ESXi (pyVmomi). Оказа се значително по-лесно така, отколкото с Java SDK-то, което работи директно със SOAP-а на ESXi. Така и не можах да го подкарам.

Цялата работа на скрипта е да се върже за VMware-а, да вземе данните, да scrape-не текущата цена на тока от сайта на Енерго-ПРО и да запише всичко в InfluxDB.

Тъй като го писах с идеята да го оправя “някой ден”, сега при всяко изпълнение се обръща до сайта на Енерго-ПРО. Това води до интереснa статистикa за последните 24 часа в Pi-hole:

 

Поиграх си доста и с ILO-то. Толкова е старо, че мога да го отворя само през Internet Explorer, защото само този браузър все още поддържа несигурни и стари SSL сертификати.

Когато инсталирах втората партида от 16GB RAM, се сблъсках с друго интересно нещо. Заради изгоряла плочка прекарах няколко часа в дебъгване на проблема. В NVRAM-а на дъното се беше записало, че в дадения слот има изгоряла плочка и докато не го изтрих няколко пъти, не се събуди дори само със здравите плочки.

Мрежа

За основен рутер използвам pfSense, който работи върху един HP thin client. Тънкият клиент се оказа напълно адекватен избор за това.

Външната връзка и WAN интерфейсът на рутера са сами на един VLAN, а на друг VLAN са всички останали устройства.

За първи път настройвах суич през конзолен кабел с истинска цел, а не за упражнение. Прекарах няколко вечери до 3-4 сутринта, докато се стабилизира мрежата. Добре че имаше кой да ми даде акъл.

Някога ще разделя клиентите на VLAN-и според предназначението им. Освен това ще е хубаво и да взема втори управляем суич с пасивно охлаждане. В момента в стаята ми е Zyxel-а, а вторият суич е истински, rack-mountable, 1U. Чувам го през две врати.

За безжичните устройства ползвам два обикновени consumer рутера, които работят в режим AP. Доскоро работеха с едно SSID, за да покрия нявсякъде. Имаха проблеми с някои клиенти с по-стари wi-fi модули и ги разделих на две SSID-та. Някога ще бъдат смемени с UniFi AP-та.

Първият ми тест на мрежата беше да копирам файл от основния компютър към NAS-а. Започваше със 100MB/s и почти веднага падаше на 1-2MB/s и надолу. След недоспиването от борбата с мрежите, вече бях напът да режа кабели, но пък netperf показваше, че мрежата успява да се запълни спокойно до гигабит.

Така пак научих, че върху RAID контролерите съществува кеш (в случая – с неработеща батерия), който при неправилна настройка на read/write съотношението прави писането бавно (изненада!). След като го оправих, нещата се нормализираха и вече bottleneck-а при писане върху NAS-а е само скоростта на дисковете. Тук също се радвам, че имаше кой да ми даде светлина. В момента съотношението е 5/95 за четене/запис.

Това с кеша е от нещата, които се налага да правиш изключително рядко и ако са направени правилно, забравяш, че съществуват. Също като настройването на Nagios. Както често твърдя – Nagios-а е най-стабилното нещо в живота ми.

Услуги

Основното нещо, за което исках да ползвам този сървър, е NAS и смятам, че засега се справя добре с тази си задача.

Имах много време да мисля какво искам да използвам за NAS софтуер и накрая се спрях на FreeNAS. Минах през всевъзможни варианти много преди да имам физически съврър и FreeNAS върху виртуална машина ми пасна най-добре. Разбира се, има и някои недостатъци на виртуализирането, но досега не съм се сблъсквал със сериозни проблеми.

Ако не друго, то поне охлаждането на процесора е адекватно. Все пак малко хора могат да се похвалят с процесори, които работят на температура под абсолютната нула.

Върху FreeNAS-а работят няколко jail-а. Основните са Transmission и NextCloud. Благодарение на Transmission имам една директория в share-а на NAS-а, която се следи за torrent файлове, които автоматично се добавят за теглене. Изтеглените неща се намират в друга директория, достъпна от всички устройства в мрежата. Така пиратстването свободното споделяне на медия с уредени авторски права е значително по-лесно.

 

NextCloud-а ми служи основно за синхронизиране на файловете от телефона и разни маловажни неща между компютрите. Първо ползвах OwnCloud, който се хостваше върху малкото OLinuXino (Lime2). Доскоро за off-site backup ползвах NextCloud върху единия droplet в DigitalOcean, където добавих 50GB Volume, върху който трябваше да са само най-важните неща. След известни проблеми с rsync реших, че Google Photos ми е достатъчен за off-site въпреки компресирането.

 

pfSense е доста полезен инструмент. Освен стандартните услуги, които трябва да предоставя един рутер (DHCP, DNS, etc.), в момента върху него работят доста неща, като по-интересните са: HAProxy, OpenVPN и plugin, който се грижи за Let’s Encrypt сертификатите.

OpenVPN-ът ми върши идеална работа. Няма много за писане откъм конфигурация, защото интерфейсът на pfSense е достатъчно прост и цялата работа се свежда до нацелване на разни стойности. Предишният VPN, който бях подкарал върху OLinuXino-то, беше по-интересен, защото цялата инсталация беше на ръка с всичките генерирания на сертификати за сървъра и клиента, както и настройването на рутирането и firewall-а. В pfSense всичко е графични интерфейси.

Сега мога да се закача за мрежата вкъщи, където и да съм, и с едно mount nas.miskin.in:/mnt/whatever /mnt/nas/ имам достъп до NAS-а.

Не бях работил с HAProxy преди това. Засега имам 20 frontend-а и 13 backend-а. Фронтендите са разделени под два основни за услугите с и без SSL. В общия случай са огледални – вместо да се реже достъпа без SSL, има frontend, който прави 301 redirect към същия адрес, но с “https://”.

20-те фронтенда могат да се свият до два, но засега така ми изглежда по-подредено и лесно за поддръжка. Бекендите са толкова малко, защото на Apache-тата отзад са конфигурирани виртуални хостове и е достатъчно да закарам заявката до правилната машина. След това уеб сървърът се дооправя с рутирането.

Както казах, повечето услуги работят през https. Това става благодарение на Let’s Encrypt. Оказа се малко по-интересна заигравка с HAProxy, за да мога да отговарям правилно на challenge-ите, които идват от Let’s Encrypt при издаване и подновяване на сертификати.

 

Ако не си личи, мразя рекламите с яростта на 1337 слънца. Благодарение на това всички компютри, до които имам достъп, веднага биват снабдени с някакъв AdBlock софтуер. С телефоните това се оказва излишно сложно и неудобно – не искам да ползвам друг браузър, не искам да root-вам телефона и т.н. За спирането на поне част от рекламите върху устройствата в мрежата използвам  Pi-hole. Тъй като все още нямам Raspberry Pi, се наложи да инсталирам Pi-hole върху старото OLinuXino (a.k.a sexy). Не му пречеше особено, че прекара няколко години затворено в кутия и в момента всички DHCP клиенти в мрежата (дори някои от тези с резервирани адреси) го ползват като главен DNS. Получи се доста добре и не усещам никакво забавяне, където и да е. Не помня всички проблеми, които излязоха по време на “инсталацията”. Помня само, че ми се наложи да ровя из инсталационния скрипт, защото имаше допуснати разни предположения за системата, които може и да са верни за Raspberry Pi, но при OLinuXino седят по различен начин. Намерих и полезен скрипт, който събира статистика от Pi-hole в InfluxDB (pi-hole-influx) за ползване в Grafana.

 

Друга основна услуга, която ползвам редовно, е Jenkins. Инсталирането и конфигурирането са тривиални. Забавата тук е при конфигурирането на job-овете.

Разделил съм ги на основно два типа – backend и frontend. Backend job-овете се отнасят до Spring Boot проекти, а другите – Node JS базирани (най-често Vue). Всеки един job се задейства при push в конкретен бранч на конкретен проект. Това става с прост hook в GitLab. Тук идва едно от многото удобства на HAProxy – понеже не исках Jenkins да се вижда извън локалната мрежа, настроих Jenkins frontend-а да приема заявки отвън само от GitLab.

Общо взето за всички проекти правя build и deploy по сходен начин. Java проектите се компилират и пакетират с Gradle. Преди build-а Jenkins се закача за сървърa, на който ще се деплойва, и затрива старите jar-ове. След това се нагласят конфигурационните файлове, с които трябва да работи Docker Image-а (cp log4j2_docker.xml log4j2.xml например) и се започва с Gradle-а. При успешен build готовия jar се копира на целевия сървър и се trigger-ва job-а за redeploy (ако за конкретния проект ми трябва автоматичен redeploy).

Redeploy job-овете са изключително прости. През SSH се закачам към сървъра, където ще се деплойва, правя Docker Image от jar-а, спирам, изтривам и стартирам наново контейнера, в който работи приложението.

При неуспешен build си пращам имейл, за да знам, че нещо се е омазало.

За фронтенд проектите е аналогично. Разликата е основно в това, че вместо gradle build се извикват npm install и npm run build.

 

Споменах, че за Spring приложенията се налага използване на различна конфигурация. Причината за това е, че някои от страничните проекти заживяха интересен живот и се наложи да са достъпни публично. Така приложението се налага да може да работи на три среди – local, dev и prod. Очевидно е какво е local. Dev средата се използва при изпълнение на тестовете по време на Jenkins build-а, а prod е това, което се вижда, когато проектът се достъпи публично.

Засега използвам Graylog за събиране на логовете от всички приложения. Това, обаче, ми излиза скъпо, защото на една машина вървят ElasticSearch, MongoDB и Graylog. На практика излиза, че 10GB RAM са недостатъчни, когато идват над 20 съобщения в секунда и се усеща забавяне. Излиза ми скъпо, защото потреблението на ток на сървъра скача осезаемо, когато се върши някаква работа с Graylog и се хабят изчислителни ресурси нещо, което може да се реши по по-лесен начин.

Обмислям да бутна приложенията да пращат имейл при някакъв проблем вместо да логвам всичко навсякъде. Поне докато не стигна някаква възвръщаемост, която оправдава по-високата цена на работата с Graylog.

 

Освен всичко описано дотук, по разните виртуални машини вървят всевъзможни други услуги: MySQL, PostgreSQL, RabbitMQ, Redis и още, и още. Все още успявам да се справя с поддръжката на всичко сам и ми е все по-интересно. По-горе писах, че използвам GitLab. Смятам скоро да си пусна една инстанция при мен, за да видя дали все още е толкова лаком за ресурси.

Проблеми

Основният ми проблем със сървъра е, че като сравнително стара enterprise машина, не е обърнато много внимание на ефективността на потреблението и във всеки един момент дърпа около 256W. Това е при включено само едно от двете 1000W захранвания. При две idle потреблението скача до около 280W. Грубата сметка идва около 40лв. на месец (без ДДС и всички такси: за пренос, загуба, “да има” и др.). Не е най-скъпото удоволствие на света, имайки предвид колко много неща мога да уча благодарение на него, но като знам, че мога да ги постигна с по-малко похабена енергия, ме човърка.

Друг проблем е шумът от вентилаторите. С качването на температурата през последните седмици, все по-често заварвам следната гледка:
Интересно е, че при по-ниска температура навън паметта достига 75-76 градуса без да вдигне осезаемо скоростта на вентилаторите. Въпреки това, суичът си остава по-шумен.

Преди няколко седмици трябваше да изключа всичко, защото имаше профилактика на захранването. Беше забавно, защото чак тогава си дадох сметка колко много неща съм закачил през последните месеци.

Бях оставил всичко да събере прах, за да се чувствам като в истински datacenter.

След включването на всичко, изненадващо, имах само един малък проблем – конфигурацията на суича не се беше запазила и SNMP-то му беше спряно, заради което в Grafana-та не излизаха статистиките за него. Всичко друго заработи без да се оплаква.

Оттук нататък приоритет ми е събирането на дискове за разширяване на storage-а, тъй като той ми умалява най-бързо. Може би и втори процесор, за да няма празни дупки.

Следващото най-важно нещо е да се сдобия с по-съвременна машина, която да не е толкова лакома за ток и да поддържа SSD по-лесно.

Мога да пиша още много, защото постоянно излизат интересни неща, които искам да пробвам, но ще спра дотук.


*Ако не броим нестабилността на sshfs и nfs mount-овете на лаптопа, които решават да потрошат всичко, когато го приспя и събудя. Някой ден ще дойде и неговия ред.