Мотивация
Одной
из причин отказа от фабричной Linux, установленной на один из entry-level
NAS архитектуры Marvell Korkwood, стала негибкость управления "экспортируемыми
ресурсами" с помощью встроенного (сразу оговорюсь, прекрасно продуманного)
web-интерфейса. Снова оговорюсь, что web
admin tool превосходно "расшарит" папку как таковую (или множество папок).
Рассмотрим, подойдёт ли web admin tool как инструмент планирования и
реализации архитектуры ИС (например, модели каталогов).
Условия задачи
Разработать
и имплементировать средствами ОС информационную модель домашнего сервера.
Начальные условия
Система
задумана как файл-сервер, сервер для обслуживания версий кода (svn), торрент-качалка ( принимает от клиентов торрент-файлы или магнитные ссылки,
сохранённые в каталоги сервера, записывает закачки в разделяемые папки).
По
мере накопления знаний и опыта
планируется запуск более специфических услуг: медиа- сервер, сервер time machine backup, сервер оцифровки медиа, BOINC-клиент.
В нашем
распоряжении следующая архитектура (см иллюстрацию):
Hardware:
I/O, HDD1, HDD2.
Software:
Ос Linux, Unix - модель каталогов ("/" - root ), концепции
"монтирования", "связывания" и службы экспорта каталогов.
Концепция
Приводится
на иллюстрации.
Сорри,
рисовал для себя.
Обозначу очень кратко следующие моменты:
- Разделение private и public ветвей ресурсов в древе каталогов;
- Удобство "монтирования", то есть построения связи rootfs и второй, массовой, файловой системы. Поменьше точек монтирования в /mnt
- Связать "узлы" (ака корни дерева каталогов) массовой файловой сисемы (/dev/sdb) и rootfs (/dev/sdb)! В перспективе экспорта каталогов несомненно удобнее в /etc/exports ссылаться на разумный минимум узлов rootfs, указывающих на узлы массовой файловой системы
- Опционально думаем об удобстве администрирования системы. Например, если мы привыкли рассматривать /srv (в footfs, проще говоря "/" системного веника HDD1) традиционно как корневую систему для всяких сервисов, то необходимо создать ссылки на таковые подкаталоги сервисов (nfs, svn), физически реализованные в массовой файловой системе (попросту "большом" венике HDD2), чтобы мы всегда видели все "каталоги сервисов" в /srv
Сформулирую задачу планирования каталогов Unix
более абстрактно:
- "Разделяй данные": Пути для данных различной природы (личные, публикуемые) не пересекаются;
- "Строй кратчайшие пути": Построить кратчайшие пути от "/" (rootfs) к любому запланированному ресурсу в любой доступной файловой сиcтеме;
Далее
я сделал для себя вывод, что при всех достоинствах web
tool не поможет мне справиться с реализацией
спланированной архитектуры ввиду ограничения: он может создать папку в строго
отведённом месте, и её расшарить. Если пункт 1 "разделяй данные" с помощью тула я решу, то вот 2
(оптимизация) - нет.
Реализация
Реализацию
как рутинное добавление
записей-описателей в файлы
/etc/fstab (directory model to physical model, map rootfs to massive
data storage)
/etc/exports (exported resource model to
directory model)
рассматриваем как самостоятельное упражнение.
Комментариев нет:
Отправить комментарий