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 миграцията също е интересно нещо.

 

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

Amazon

В края на миналия месец бях на onsite интервю в Amazon за позицията Software Development Engineer, която щеше да ме закара в офиса им във Ванкувър. Ставаше въпрос за екипа в AWS, който работи по Step Functions.

Не ме харесаха.

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

Интервютата в Amazon са много интересно преживяване. Общо взето минават така:

  1. Някаква комуникация с рекрутър, инициирана от една от двете страни,
  2. Онлайн оценяване,
  3. Телефонен разговор с рекрутър,
  4. Onsite интервю.

Онлайн задачите бяха лесни. Едната се свеждаше до BFS върху матрица, а другата – продължително сортиране на списък, сумиране и премахване на първите му два елемента, докато не остане само един.  След решаването на задачите трябваше да им напиша асимптотична оценка и обоснование на алгоритмите.

На едната задача покрих само 10 от 16 теста, но въпреки това минах напред към телефонния разговор. Там мина добре и с рекрутърката си говорихме много странични неща. След разговора започна организирането на onsite интервюто.

Прекарах около месец в почти денонощно учене на всевъзможни неща от компютърните науки. Започнах от основните структури от данни и алгоритми и реших доста примерни задачи от интервюта в Google, Microsoft и Amazon. Освен основите се очаква и познание по системен и архитектурен дизайн. За това наблегнах на примери като “как скалирахме Dropbox” и “как се оправяме с хилядите (буквално) microservice-и в Uber”. Това че вкъщи имам Kubernetes клъстър и си играя с истински сървъри също помогна много.

Bit manipulation в самолета към Виена

Onsite интервюто беше в Будапеща. За тези интервюта пише всевъзможни страшни истории, но моето беше приятно и с много по-лесни въпроси, отколкото очаквах. Цялото нещо представлява 4 интервюта от по час. Всички са едно след друго и има малка почивка, ако си поискаш.

Хората бяха интересни, приветливи и с удоволствие ми обясняваха подробности за работата в Amazon.  Заради NDA-а не мога да споделя по-конкретни детайли.

Едно интервю протича основно в три части:

  1. Интервюиращият се представя (не винаги) и задава въпроси за поведение, които се базират на Amazon-ските лидерски принципи. “Кажи ми за случай, в който си получил отрицателна оценка в работата си”, “случай, в който си постигнал добри резултати за кратко време” и всякакви такива. Очакват отговорите да са структурирани по определен начин и да покриват възможно най-много от принципите,
  2. Задача за програмиране върху бяла дъска (моето беше на лист хартия). Тук освен стандартните алгоритмични задачи има и едно интервю за системен дизайн,
  3. Въпроси към интервюиращия. Питах почти всички дали им харесва да работят в Amazon. Не питах само този, който е там от 16 години. Отговорите бяха различни варианти на “Сериозно ли?” и “Ти как мислиш?”. Някои питах как спят спокойно, знаейки че ако нещо се счупи, ще влезе в новините. От това научих много за начина им на работа и всички failsafe-ове, които имат.

Не очаквах езикът да е проблем, но се наложи да обяснявам на единия интервюиращ какво е Kubernetes. Не знам дали в крайна сметка всички успяха да разберат всичко, което им говорех или не им е пукало достатъчно, за да питат за неясните неща.

Последното ми интервю беше с hiring manager-а (този, който има най-много тежест в решението за наемане). С него си говорихме много странични неща и се смяхме доста. Не знам колко е добре това, защото всички интервюиращи си водят обилни записки, които сравняват после и на база тях се взема решение за наемане. Този по едно време си затвори лаптопа и започнахме да обсъждаме дизайна, който му рисувам. Накрая ми каза, че ме е харесал и е почти сигурен, че ще си говорим пак. Явно това е заучена фраза, за да не се шашкат кандидатите.

Особеното при Amazon е, че много държат на познаването и прилагането на техните си Leadership Principles. Разликата с други компании, които имат големи твърдения е, че тези наистина спазват нещата, които говорят. Поне по моите наблюдения и разкази от хора, които работят там.

Това интервю ми беше поредното за тази година, но първото, за което се готвя сериозно. На някои от предишните интервюта, на които бях, не можах да отговоря на срамно елементарни въпроси за неща, които ползвам всеки ден.

От цялото преживяване съм доволен, защото си припомних много теория, която успешно прилагам, а и научих много нови неща, които ще ми помогнат занапред. Освен това ме разходиха до Будапеща безплатно. Архитектурата е страхотна, гулашът е супер. Ще отида пак само за да се разходя из града и да огледам всичко на спокойствие 🙂

Представите на Amazon за начин на разработване на софтуер са много близки до моите и ще ми е много интересно някой ден да успея да играя с големите деца. Дотогава – return; return; и ще решавам задачи в LeetCode от време на време.