Что делать, если нужно, чтобы доступ к системе хранения данных был не просто быстрым, а желательно равным скорости обращения к локальному SSD-диску? Единственным реально быстрым методом будет доставка блочного устройства напрямую клиенту. Со стародавних времен серверные СХД предоставляют такой доступ по средствам протокола iSCSI, и эта статья могла бы быть про это, но в наше время появилось дополнительно требование к подобным системам - это масштабируемость и отказоустойчивость (или “Высокая доступность”). Тут на сцену выходят програмно определяемые хранилища, такие как Ceph, GlusterFS, cStor, MayaStor и другие. Но наибольшей популярностью пользуется именно Ceph, т.к., несмотря на достаточно сложный порог входа, он имеет ряд архитектурных ноу-хау, которые кажутся весьма перспективными. И, при правильной организации кластера, может быть быстрым, гибким и готовым к работе в “боевых” условиях, как говорят - “Production ready”. Он конечно не самый быстрый, но в совокупности требований к современной СХД, он подходит больше всего.

С чего всё началось. С того, что уже установленный в моей локальной сети экземпляр сервиса GitLab CE вполне успешно работал, но был расположен на обычном HDD, т.е. не SSD и не NVMe. И вполне, какзалось бы, успешно работал, но при длительном аптайме он сжирал все ресурсы оперативной памяти, которой я ему выделил - 16 Гб (что видимо мало), начинал активно использовать swap, и когда планировщик начинал заниматься очисткой/оптимизацией структуры репозиториев, мог начинать тормозить с невероятной силой, из-за того, что исчерпывал ресурc IOPS диска. Конечно, перезагрузка хоста всё решала, но сама ситуация была несколько неприятной. К тому же, для каких-то небольших проектов и небольшой инфраструктуры такой комбайн как GitLab, мне кажется, не очень-то и нужен. Плюс ко всему, у меня еще были вопросы к формату описания сценариев CI/CD пайплайнов, которые, как мне кажется, в Jenkins можно делать значительно гибче чем в GitLab. Словом, GitLab безусловно крут и незаменим в наши дни, если вы работаете в больщой команде где много подгрупп и разых проектов, но для каких-то более простых задач можно обойтись инструментами установку и настройку которых я буду описывать ниже.

WireGuard - полезный инструмент для создания шифрованных туннелей между подсетями или для организации доступа в локальную сеть. Конечно, можно делать все по памяти, либо сделать пару-тройку простеньких скриптов для выполнения каких-то повторяющихся действий по внесению изменений в настройки сервиса, но так же можно использовать UI веб-интерфейсы. На мой взгляд, это, в некоторых случаях, может давать ряд приимуществ. В данном случае, основным приимуществом для меня является то, что, при использовании wireguard-ui, можно быстро добавить нового пользователя, даже если ты уже давно этого не делал. Всё что нужно помнить - это логин и пароль от веб-интерфейса, а все остальное делается интуитивно.

Что делать если к удаленной или виртуальной машине необходимо подключить какое-то USB устройство, например, USB-ключ или веб-камеру? Тут на помощь приходит технология “USB over IP”, которя в системах Linux доступна почти из коробки. Алгоритм настройки достаточно примитивен и содержит в себе всего несколько шагов, которые будут перечислены ниже.

Для того чтобы вкоючить поддержку PCI Passtrough есть специальная страничка от разработчиков OpenNebula, но там почему-то этот вопрос рассматривается несколько поверхностно. В данной статье будет реально рабочий вариант настройки KVM-хоста с комментариями и пояснениями.

Как я понимаю, прелесть данного метода в том, что с сервера снимаеются накладные расходы на обслуживание файловой системы, т.к. клиент работает с блочным устройством и её обслуживание осуществляется полностью самим клиентом.

Условия установки:

• Ubuntu Live Server 20.04.5 LTS
• OpenNebula 6.4.0

Для организации данного сервиса был выбран облачный дистрибутив Arch Linux, который в последующем был использован в Proxmox VE по средствам клонирования шаблона созданного следующим скриптом:

Данная статья подразумевает, что в нашем кластере Kubernetes уже установлены сервисы обеспечивающие основную инфраструктуру: HAProxy-Ingress, OpenEBS и cert-manager. А так же для класса clusterissuers.cert-manager.io уже создан эмитент “letsencrypt”, для получения доверенного сертификата нашего сайта.