Сервер у кожен дім 🏡, частина 2: як я використовую HPE Proliant DL560 Gen8 для навчання і роботи

Привіт всім! Пройшло вже достатньо багато часу з моменту оприлюднення першої частини цієї статті: «Сервер у кожен дім, або quick review of HPE ProLiant DL560 Gen8», тож саме час розповісти вам про мій досвід використання сервера рівня підприємства для задоволення моїх скромних потреб 😅 (навчання, роботи над FOSS проєктами і їх тестового розгортання, різноманітних експериментів, тощо).

Віддалене керування й адміністрування

Одною з переваг використання серверного обладнання рівня підприємства є існування вбудованих інструментів для їхнього віддаленого адміністрування. У серверах виробництва компанії HP Enterprise, про один з яких і йде мова у цій статті, присутній фірмовий IP-KVM модуль під назвою HPE Integrated Lights-Out (HPE iLO), а також інші вбудовані утиліти, доступ до яких можна отримати в ході запуску сервера. Вони, усі разом, дозволяють керувати серверами лінійки ProLiant на 100% віддалено, згадуючи про їх фізичне місцезнаходження лише у разі виявлення тим же модулем HPE iLO проблем зі замінними частинами сервера.

Серед засобів керування серверами HPE ProLiant, крім вже згаданого HPE iLO, можна виділити HPE Smart Storage Administrator (засіб для управління системою зберігання даних і RAID-контролерами) і HPE Intelligent Provisioning (засіб для керування усіма підсистемами сервера, оновлення прошивок, тощо). Але звертати вашу увагу на них у сьогоднішній статті я не буду.

Для мене можливість віддаленого керування сервером є необхідною, бо, як ви можете знати, я навчаюся і більшість часу проводжу у Львові, у той час як сервер знаходиться у Запоріжжі — звідки я родом. Крім неможливості розміщення такого обладнання у студентському гуртожитку (зі зрозумілих причин), є ще одна, не менш важлива: якість і швидкість доступу до мережі Інтернет. У Запоріжжі я маю стабільний гігабітний канал, у той час як у Львові на силу отримую до 50 МБіт/сек з максимально можливого тарифного плану «до 100 МБіт/сек» від державного інтернет-провайдера, ДП «УАРНЕТ».

Але, давайте не будемо про погане сьогодні 🙂!

Використання середовища для віртуалізації

На сервері встановлена актуальна версія апаратного гіпервізора VMware ESXi 7, яка має зручний веб-інтерфейс і мобільний застосунок — все необхідне для управління віртуальними машинами і вирішення проблем технічного характеру «на ходу». Більше того, у цьому гіпервізорі існує достатньо потужна підтримка «прокидування» накопичувачів і PCIe пристроїв у гостьове середовище, що забезпечує більшу продуктивність при роботі з накопичувачами і апаратним RAID масивом у тих завданнях, які я ставлю перед сервером, а підтримка PCIe passthrough дозволяє мені під'єднувати дискретні відеокарти до віртуальних машин з мінімальними втратами швидкодії.

З іншого боку, вільна альтернатива VMware ESXi, яка носить назву Proxmox, дозволяє без додаткових налаштувань розгортати контейнеризовані проєкти з використанням платформи LXC (та і Docker за наявністю великого бажання можна використовувати, прямо на хості, без створення додаткової віртуальної машини), а от passthrough накопичувачів і пристроїв на PCIe треба робити самотужки, із залученням до справи сисадмінського бубна 😂. Саме тому мій вибір припав саме на гіпервізор VMware ESXi.

Використання Docker-контейнерів

Використовувати Docker для налагодження і тестування своїх проєктів я став вже достатньо давно, тож на новопридбаному сервері я одразу розгорнув віртуальну машину під Ubuntu, на якій інсталював саму платформу, а також Portainer — GUI для зручного управління Docker-контейнерами. Хтось може поставити під сумнів швидкодію такого рішення, але для моїх невимогливих потреб цілком достатньо.

Під Docker у мене працюють кілька інстансів СКБД (MariaDB) для різних проєктів, Jenkins і його агенти побудови, та контейнери для тестування моїх проєктів. Все це економить мій час і нерви. Наприклад, якщо щось зламається всередині окремого контейнера, не треба буде турбуватися про можливі пошкодження чутливих даних з інших сервісів. Навіть не згадую про старий-добрий Jenkins 😏.

Віртуальні машини для навчання

У ході кожного семестру навчання на Факультеті електроніки та комп’ютерних технологій ми знайомимось з різними технологіями і програмним забезпеченням, яке покликане простити нашу роботу. Зараз, наприклад, ми вивчаємо процеси програмування і налагодження мікропроцесорних і мікрокомп’ютерних систем на прикладі Infineon/Cypress PSoC і Raspberry PI/NVIDIA Jetson Nano відповідно. А перед тим будували електронні схеми у середовищі NI MultiSim, використовували OriginLab OriginPro для аналізу отриманих даних, тощо.

З часом такого програмного забезпечення може накопичитись надто багато, що уповільнюватиме роботу ноутбука чи персонального комп’ютера (на прикладі моїх одногрупників і загалом студентів нашого факультету). Мені ж така проблема не страшна, бо кожного семестру я створюю дві нові віртуальні машини, назвемо їх ubuntu-education і windows-education, перед тим видаляючи старі дві. Це дозволяє не тільки не засмічувати основну робочу «машину», але й надавати доступ до згаданого програмного забезпечення своїм друзям і одногрупникам.

Віртуальні машини для роботи

Для над проєктами мною було створено дві віртуальні машини: одна на базі Ubuntu 20.04, інша — на базі Windows Server 2019 LTSC. На кожній з них встановлено необхідний мінімум для розробки і тестування програмного забезпечення, який здебільшого складається з IDE від компанії JetBrains і платформи Visual Studio Code. На ці дві віртуальні машини припадає більшість ресурсів серверної платформи, бо я часто граю у багатозадачність, тож вони мають витримувати одночасну роботу двох IDE, вебпереглядача, ну і два-три запущених у режимі зневадження програмки.

Ubuntu Server на всі випадки життя

Ніколи не знаєш, у який несподіваний момент тобі треба буде підняти щось на старому-доброму Apache, чи запустити якусь програмку, яка точно не може працювати у контейнері (наприклад, якщо вона утилізує «особливі» системні виклики, або ж її швидкодія у контейнері буде неприйнятною). Саме тому я тримаю на сервері ще й таку віртуальну машину на базі Ubuntu Server 20.04. На ній встановлено Apache і всі основні сервіси, які можуть стати у пригоді.

На тому Apache, до речі, розгорнуто динамічне і статичне (в залежності від потреби) реверс-проксіювання деяких портів (HTTP, WebSockets, etc) деякого діапазону IP адрес локальної мережі, у якій знаходиться сам сервер. Це зроблено для зручного дестування вебзастосунків. Доступ до «динамічних портів» (вживаю трішки неправильне формулювання, тож сподіваюся, що ви мене за це пробачите 🙂) можна отримати з доменних імен у зоні *.zp.int.sirkadirov.com.

Загальні враження від використання

Використання вживаного сервера HPE ProLiant DL560 Gen8 як основної робочої станції виявилося досить цікавим для мене, і, що найголовніше, жодних проблем з ним за час використання не виникало. До того ж, магазин Servak, у якому я його купляв, надає розширену гарантію на сервер і його запчастини — ще менше приводів хвилюватися через можливі поломки і проблеми з його використанням.

Ще одною несподіванкою стало те, що до нього стабільно «приходять» оновлення прошивок, серед іншого — для IP-KVM модуля; для RAID-контроллера; для мережевих адаптерів; для інших замінних частин сервера.

Що ж, зважаючи на свій досвід використання такого рішення, зі впевненістю можу сказати, що воно ідеально підійде для використання малим бізнесом і такими ж «ентузіастами» як я сам 😅. Головне — перед прийняттям рішення про придбання подібних серверів рівня підтриємства, необхідно зважити усі «за» і «проти», і мати розуміння, що адміністрування такого «заліза» у деяких рисах дуже відрізняється від звичайних комп’ютерів і робочих станцій.

Відеоогляд HPE ProLiant DL560 Gen8

Довгий час я стежу на YouTube-каналом MyPlayHouse, де автор розглядає різні «залізячні» цікавинки. Наповнення каналу дуже вартове, тож раджу вам підписатися на нього, і, за можливості, підтримати автора за допомогою Patreon.

Нещодавно, на цьому каналі з’явився огляд мого HPE DL560 Gen8. Впевнений, що краще за автора цього відео про мою «улюблену залізяку» не розповість ніхто.

Замість завершення

Дякую, що дочитали цю статтю до кінця! Сподіваюся, що вона була для вас цікавою. Хотілося б почути думку щодо неї, та й ідеї на тему того, якими можуть бути наступні статті з цього циклу. У будь-якому випадку, до нових зустрічей 😉!