В этой части хочется рассказать про то что требуется и что предлагает наш "вендор".
Часть вторая: Реализуем сервис файлового сервера на Astra Linux.
Дисклеймер
Данная статья представляет собой личное мнение автора о требованиях и работе файловых серверов. Предназначена в первую очередь чтобы поделится собственным опытом. Информация, изложенная в статье, основана на собственных исследованиях и опыте работы, и может не отражать общепринятые мнения или практики. Автор не стремится выставить кого-либо в плохом свете и призывает к конструктивному обсуждению. Рекомендуется дополнительно изучать источники для более глубокого понимания темы.
И вот пришла задача заменить Windows Server на что-то «Российского» производства
Берясь за задачу казалось что всё будет довольно "просто" т.к. файловые сервера на базе GNU/Linux существуют давно и в целом всем всё давно реализовано, и должно пройти по классической для импортозамещённых продуктов схеме затраты на лицензирование 2-4 раза больше Winodws, затраты на последующее администрирование в 3-10 раз выше. Но даже тут отечественный производитель смогу удивить....
В моём случае был взят стек Astra Linux 1.7.5 + ALDPro 2.3.0.
Хочу напомнить о том что файловый сервер это один из базовых инфраструктурных сервисов, моё мнение о требуемом функционале и то что предоставляет решение от Астры ниже в таблице.
|
Что требуется |
Наличие |
примечание |
|
Доступ по протоколам |
||
|
NFSv4 |
+/- |
Можно поднять но ALDPro им управлять не может. А это условно нативный протокол для стека на Linux. |
|
SMB (CIFS) |
+ |
|
|
WebDAV |
+/- |
Реализуемо за рамками ALDPro |
|
Администрирование |
||
|
Предоставление доступа к шаре на базе прав из каталога LDAP (Active Directory, FreeIPA, Samba) |
+ |
Почти не подвели, могут но только свой домен т.е. ALDPro, пользователей из доверенных не добавить. |
|
Разграничение доступа к файлам и папкам в рамках шары для пользователей из каталога пользователей т.е. настройка файловых прав по модели NFSv4: |
- |
Хоть шаром покати функционал отсутствует полностью (мандатный контроль простите, но это не то) |
|
Разграничение доступа в сложной доменной структуре (когда к одному серверу ходят с нескольких доменов) |
- |
Вообще технически всё есть но в GUI Astra и ALDPro Функционал отсутствует права можно добавить только через консоль |
|
Создание и управление снапшотами данных (Теневые копии) |
- |
Функционал отсутствует |
|
Создания квот и управление квотами |
+/- |
Частично функционал есть только в Astra Linux управление в рамках ALDPro отсутствует. |
|
Настройка времени хранения в папках с сроками хранения |
- |
Функционал отсутствует |
|
«Базовый» функционал |
||
|
Шифрование данных |
+/- |
Можно реализовать в ОС но не в рамках ALDPro |
|
Дедупликация данных |
- |
Функционал отсутствует |
|
Сжатие данных |
- |
Функционал отсутствует |
|
Отказоустойчивая конфигурация |
- |
Функционал отсутствует |
|
Создание единой точки входа для нескольких серверов (DFS) |
- |
Функционал отсутствует |
|
Удобный GUI для администрирования |
+/- |
GUI есть, но функционал даже не базовый для 2024. |
|
Анализатор использования пространства |
- |
Функционал отсутствует |
|
Анализатор прав доступа на файлы и папки |
- |
Функционал отсутствует |
В подтверждение своих слов приведу пару скриншотов из имеющейся под рукой ALDPro 2.3.0
Собственно можно ещё было бы забить скриншотами самой ОС Астра Linux, но функциональных элементов управления файловым сервером, что нас могут интересовать там нет. Более элементов управления файловым сервером в ALDPro 2.3.0 нет (в дорожной карте разработки, доработки функционала тоже нет)
Почему всё так?
Каждый раз смотря на подобное в продукте от российского вендора хочется плакать или всё бросить, можно долго гадать, но за последние два года общения с различными представителями вендора у меня сложилось впечатление, что наверное основное - это не понимание менеджмента какие функции и как выполняет сервис (не только описываемый). Возможно нехватка разработчиков, настоящих, а не тех которыми пытаются наводнить рынок. Возможно эта уверенность «…Дело не во владении кодом…». Ну и конечно существует ряд подводных камней во всех OpenSource решениях т.к. они всегда писались энтузиастами у которых чуть иной круг задач. И чтобы сделать сервис надлежащим образом нужно хотеть и уметь программировать, а не только комуниздить «компилировать» OpenSource решения для получения нечто похожего на решение.
Про подводные камни в GNU/Linux
(эти вопросы я задавал представителям вендора и они считают что это не проблемы)
Длина имени файлов: она ограничена условно 128 символами кириллицы т.к. в наших «отечественных» операционных системах используются компоненты которые писались для англоязычного пользователя.
Максимальная длинна имени файла ограничена 255 байтами кажется что это стандартная длинна имени файла к которой мы привыкли 255 символов, один символ=один байт? Но нет это не так, в Linux используется кодировка UTF8 а это значит что буквы латинского алфавита равны одному байту, а вот буквы кириллицы равны двум байтам отсюда длина имени файла и становится ограниченной. Тут без вмешательства в файловую систему никак....
Или наши производители соберутся и соберут свою файловую систему, объективно у столпов рынка это обычно занимает 5-10 лет, или смогут закоммитить в Linux такие правки в одну из файловых систем.
Про права доступа: В GNU/Linux базово есть права только RWX (Чтение, Запись, Исполнение) для хозяина, группы и для остальных, а требуется для нормального разграничения доступа чуть больше, если мы говорим про корпоративный сектор. Разработчики ядра Linux считают что RWX вполне достаточно. Также существует расширенные атрибуты xattr которые позволяют расширить функционал и добавлять права доступа RWX но уже большему количеству пользователей и групп. Почему ALDPro при разворачивании сервиса отказываются их использовать для меня загадка.
В Астра Linux есть «киллер фича» мандатный контроль всего. Но он поддерживается только Астрой и никем больше, т.е. его не применить для общедоступного сервиса который работает на этапе развёртывания с инфраструктурой MS AD+ ALDPro c 90+% рабочих станций на Windows.
Как можно решить задачу?
Есть понимание, пусть и не полностью но силами рядового админа задача частично/костыльное решаемая т.к. в целом Astra Linux это на 99% Debian Linux а Astra Linux 1.8 это довольно актуальный Debian 12.
Если заменить файловую систему с ext4, что штатно использует Astra Linux, на ZFS многие задачи можно закрыть. (Так сказать начать процесс импортозамещения без существенных травм в психике рядового Админа.)
Это решит проблемы:
-
Чувствительность к регистру в файловой системе.
-
Наследование прав в файловой системе
-
Создание Snapshot`ов
-
Дедупликация
-
Сжатие данных
Останутся проблемы:
-
Длина имени файлов,
-
Права доступа,
-
Отсутствует необходимый функционал в графическом интерфейсе.
Часть интерфейса, хотя бы в ОС можно «вернуть» установив недостающие библиотеки, что Astra при автоматическом развёртывании сервиса через ALDPro не делает.
Про проблемы ZFS
1 – ZFS очевидно медленнее ext4 при сравнении в лоб. Но в ZFS есть минимум 2 уровня кэша (ОЗУ и SSD), возможность построения RAID массивов в результате при желании система на ZFS даст больше чистой производительности и надёжности в пересчёте на деньги в неё вложенные.
2 – ZFS Умеет в полноценные права, но не в Linux, а в FreeBSD. Проблема на уровне ядра Linux и в результате ZFS не может работать с правами по модели NFSv4. Разработчики из iXsystems уже внедрили поддержку в модуль ядра по модели NFSv4 в ZFS, которую собирают для своего продукта TrueNAS Scale, построенного поверх Debian 12.
Также насколько я понял разработчики ZFS приняли правки от iXsystems в состав основной ветки ZFS и в релизе ZFS 2.3 можно ожидать работающие NFSv4 права поверх Linux благодаря xattr, а не только FreeBSD.
И вот вооружившись этими знаниями во второй части я расскажу, с конкретной инструкцией, про разворачиванию сервиса простого файлового сервера на базе Astra Linux 1.8 с доменами, самбой, и прочим.
Автор: SamDurak
