Большинство таких инструментов разметки обычно по умолчанию создают новые разделы с идентификатором раздела 0×83 (Linux). Вы можете использовать установки по умолчанию, но лучше изменить их на 0x8e (Linux LVM).

#fdisk -l /dev/sdb

Изменим тип раздела на 0x8e (Linux LVM).

fdisk /dev/sdb
 Command (m for help): t
 Selected partition 1
 Hex code (type L to list codes): 8e
 Changed system type of partition 1 to 8e (Linux LVM)
 Command (m for help): w

 

Теперь инициализируем каждый раздел с помощью pvcreate:

pvcreate /dev/hda2

Физические тома и группы томов создаются за один шаг: vgcreate:

vgcreate test-volume /dev/hda2

Команда создает логический том с именем test-volume, используя в качестве исходных физических томов /dev/hda2.

После создания группы томов test-volume ведите команду vgdisplay для просмотра общей информации о вновь созданной группе томов.

Создание новых логических томов (разделов)

lvcreate -L 5G -n data test-volume

Создается логический том размером 5 ГБ с именем data.

Создадим новый логический том nfs-121 заняв все свододное место (-l 100%FREE)

lvcreate -l 100%FREE -n nfs-121 test-volume

После создания тома data вы можете проверить наличие узла этого устройства:

root@klausk:/# ls -l /dev/mapper/test--volume-data
brw-rw---- 1 root disk 253, 4 2006-11-28 17:48 /dev/mapper/test--volume-data
root@klausk:/# ls -l /dev/test-volume/data
lrwxrwxrwx 1 root root 29 2006-11-28 17:48 /dev/test-volume/data ->
/dev/mapper/test--volume-data

Вы также можете просмотреть свойства логического тома с помощью команды lvdisplay

Монтирование логического тома

root@klausk:~# mkfs.ext4 /dev/test-volume/data
root@klausk:~# mkdir /data
root@klausk:~# mount -t ext4 /dev/test-volume/data /data/
root@klausk:~# df -h /data
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/test--volume-data
                      5.0G   33M  5.0G   1% /data

Вам также может потребоваться изменить файл fstab(5) для автоматического монтирования файловой системы во время загрузки:

mount Logical Volume 'data' under /data
/dev/test-volume/data   /data   ext4        defaults        0 2

Удалить физический том из группы томов

 vgreduce nfs /dev/sdb1

Сетевая файловая система (Network File System – NFS) служит для обеспечения доступа компьютерам сети к общим каталогам на сервере.

Итак немного теории
NFS по смыслу и по организации работы похожа на разделяемые каталоги (shared folders) в системах Windows, но в этих службах используются совершенно разные протоколы работы и между собой они не совместимы. Однако, существует несколько программных продуктов, которые устанавливают поддержку NFS в системах Windows, поэтому применение NFS в сети с различными операционными системами не представляет проблемы, надо только помнить о необходимости использовать одинаковые версии NFS. В Данный момент используется в основном 3-я версия и внедрятся 4-я.

NFS работает посредством механизма удаленного вызова процедур (RPC – Remote Procedure Call).
Идеология RPC очень проста и привлекательна для программиста. Как обычно работает сетевое приложение? Оно следует некоему протоколу (например, HTTP): формирует пакет с запросом, вызывает системную функцию установления соединения, затем функцию отправки пакета, затем ждет ответного пакета и вызывает функцию закрытия соединения. Это значит, что вся работа с сетью является заботой программиста, который пишет приложение: он должен помнить о вызове функций сетевого API системы, думать о действиях в случае сбоев сети.

RPC предполагает иной способ обмена данными между клиентом и сервером. С точки зрения программиста, приложение клиента, работающее с помощью RPC, вызывает функцию на сервере, она выполняется и возвращает результат. Пересылка запроса на выполнение функции через сеть и возврат результатов от сервера клиенту происходит незаметно для приложения, поэтому последнее не должно беспокоиться ни о сбоях сети, ни о деталях реализации транспортного протокола.

Для того, чтобы обеспечить прозрачность пересылки данных через сеть, придумана двухступенчатая процедура. На сервере любое приложение, которое хочет предоставлять свой сервис через RPC, регистрируется в программе, которая называется транслятором портов (port mapper). Функция этой программы – устанавливать соответствие между номером процедуры RPC, которую запросил клиент, и номером TCP или UDP порта, на котором приложение сервера ждет запросов. Вообще говоря, RPC может работать не только с TCP или UDP

Приложение, которое регистрируется у транслятора портов, сообщает ему номер программы, номер версии и номера процедур, которые могут обрабатываться данной программой. Эти процедуры будут впоследствии вызываться клиентом по номеру. Кроме этого, приложение сообщает номера портов TCP и UDP, которые будут использоваться для приема запросов на выполнение процедур.

Клиент, желающий вызвать выполнение процедуры на сервер, сначала отправляет запрос транслятору портов на сервер, чтобы узнать, на какой TCP или UDP порт надо отправить запрос. Транслятор портов запускается при старте системы и всегда работает на стандартном порте 111. Получив ответ от него, клиент отправляет запрос на тот порт, который соответствует требуемому приложению. Например, сервер NFS работает на порту 2049.

Процедура монтирования общего каталога через NFS

Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS, следует понять, как осуществляется монтирование удаленных файловых систем в принципе.

Клиент NFS посылает запрос на монтирование удаленному компьютеру, который предоставляет свою файловую систему (обычно – некоторую ее часть) для общего пользователя. При этом говорят, что сервер NFS «экспортирует» тот или иной каталог (подразумевается – с подкаталогами). Запрос от клиента NFS попадает на обработку демону mountd. Тот выдает клиенту NFS специальный ключ. Этот ключ является идентификатором, который однозначно идентифицирует каталог, смонтированный по сети.

По NFS можно смонтировать как целые файловые системы, так и отдельные каталоги. Из соображений безопасности запрещено монтировать каталоги «через раздел». Это означает, что если каталог /var расположен на одном разделе диска, а каталог /var/adm – на другом, то при монтировании каталога /var каталог /var/adm не будет автоматически смонтирован. Если требуется монтировать те подкаталоги экспортируемого каталога, которые расположены в другой файловой системе (на другом разделе), следует экспортировать их отдельно и указывать в /etc/dfs/dfstab еще один разделяемый каталог – тот самый подкаталог с другого раздела.

Ключ, выданный клиенту при монтировании и идентифицирующий сеанс работы с данным удаленным каталогом, сохраняется при перезагрузке NFS-сервера, чтобы после восстановления его работы клиенты, замершие в ожидании, продолжили работу с удаленным сервером как ни в чем ни бывало. При демонтировании и новом монтировании файловой системы через NFS ключ обычно изменяется. На практике перезагрузка NFS-сервера все-таки может привести к сбою в работе клиентского приложения, особенно, если приложение читает или записывает файл в удаленный каталог во время перезагрузки.

После монтирования файловой системы через NFS клиент посылает серверу запросы на передачу и прием файлов, эти запросы обрабатывает демон nfsd.

Демонтирование файловой системы выполняется также, как и демонтирование любой другой файловой системы – командой umount.

Процесс установки соединения

Cilent |                                        |  Server
       |запрос транслятору портов на сервер,    |
mount  |чтобы узнать, на какой TCP или UDP порт |
nfs    |надо отправить запрос для доступа к nfsd|
       | -------------------------------------> | 111 UDP (rpcbind)
       | <------------------------------------- |
       | Запрос к самому приложению (nfsd)      |
       | -------------------------------------> | 2049 TCP или UDP
       | <------------------------------------- | на выбор (NFSD)
       | Запрос порта приложения mountd         |
       | -------------------------------------> | 111 UDP (rpcbind)
       | <------------------------------------- |
       | Запрос на монтирование к mountd        |
       | -------------------------------------> | 12345 (выставлен руками)
       | <------------------------------------- | UDP (mountd)
       | Обмен данных по протоколу NFS          |
       | -------------------------------------> |
       | <------------------------------------- |

Настройка NFS-сервера

Для настройки NFS сервера нам потребуется выполнить настройку как минимум трех приложений: rpcbind, mountd и nfsd.

Переходим непосредственно к настройке
Вся настройка будет рассматриваться на ОС FreeBSD
Настройка NFS-сервера
Для настройки NFS сервера нам потребуется выполнить настройку как минимум трех приложений: rpcbind, mountd и nfsd.
Добавляем их в rc.conf

# NFS
# запуск nfsd
nfs_server_enable="YES"
# флаги для nfsd:
# "-u" - используем тока протокол UDP - причина - это не инет, потери пакетов
# весьма малы, а по ресурсоёмкости UDP выгодней. TCP - весьма `дорогой`
# протокол, требует больше ресурсов
# "-t" - использовать протокол TCP (можно использовать и TCP и UDP одновременно
# - выбор, в конечном итоге, за клиентом)
# "-n 1" - максимальное число одновременно подключенных клиентов
# "-h 11.22.33.44" - работать на одном адресе (интерфейсе). Если не указано -
# работате на всех. Может быть указана неоднократно. У меня на этой машине
# всего один интерфейс (не считая lo0 :)) потому её наличие бессмысленно.
nfs_server_flags="-t -n 1 -h 11.22.33.44"
# демон монтированя - принимает подключения от клиентов. Запускается
# автоматически при опции nfs_server_enable="YES". Ключи:
# "-r" - для обслуживания файлов а не тока каталогов (если я правильно понимаю
# значение - то можно расшарить файл, а не каталог. Может для кого-то и имеет
# смысл...)
# "-l" - регистрация всх запросов на монтирование
# "-n" - для возможности монтированя из-под винды (вернее, никсовую
# шару на форточки)
# "-p" - на каком порту запускать
# "-h" - работать на одном адресе (интерфейсе). Если не указано -
# работате на всех.
mountd_enable="YES"
mountd_flags="-r -p 12345 -h 11.22.33.44"
# удалённый вызов процедур - необходим для фунциклирования NFS
rpcbind_enable="YES"
rpcbind_flags="-h 11.22.33.44"
# "-h" - работать на одном адресе (интерфейсе). Если не указано -
# работате на всех.

Настраиваем файл экспорта (/etc/exports)

# То, что расшариваем по NFS
/etc/PF/www      -alldirs  -maproot=root  11.22.33.55
/usr/ports -maproot=root -network 192.168 -mask 255.255.0.0

В первом случае расшаривание для конкретного ip.
Во втором случае расшаривание каталога /usr/ports для всей частной сети (192.168.0.0/16 — или 192.168.0.0/255.255.0.0), с правами root`a для всех root`ов с удалённых машин. Причём можно было это сделать для любого удалённого пользователя — хоть для nobody 🙂

Теперь, если перезагрузить сервак, все встанет,
либо можно перезапустить службы таким вот скриптом

#!/bin/sh
/etc/rc.d/rpcbind restart
/etc/rc.d/nfsd restart
/etc/rc.d/mountd restart

Для проверки готовности всех служб NFS к работе через rpcbind
используется команда

rpcinfo -p
showmount -ae

можно также посмотреть провесились ли демоны или нет


[root@srv /etc/rc.d]# sockstat | grep nfs
root     nfsd       41300 3  tcp4   *:2049                *:*
root     nfsd       41300 4  tcp6   *:2049                *:*
[root@srv /etc/rc.d]# 

Настройки клиента
На клиентских машинах можно(не обязательно) прописать такие строки в /etc/rc.conf:
# Эта опция в-общем-то и не нужна, всё прекрасно монтируется и без неё,
# но с ней подрубается демон nfsiod, позволяющий проводить чтение-запись
# асинхронно, не дожидаясь окончания предыдущей операции.
nfs_client_enable="YES"
# скока демонов запускать (по одному на примонтированный ресурс)
nfs_client_flags="-n 1"
И пробуем подмонтровать (в хандбуке советуют на клиентах выполнить команду nfsiod -n 4
Теперь примонтируем шару с клиента (в данном случае по TCP и если сразу не получается, монтировать в фоне)

#В FreeBSD8
/sbin/mount_nfs -o tcp -o bg -i 192.168.20.251:/usr/ports /usr/ports
#В FreeBSD7 и ранее
/sbin/mount_nfs -T -b -i 192.168.20.251:/usr/ports /usr/ports

NFS-соединение работает по клиент-серверной схеме. Один компьютер является сервером и предоставляет свои файловые системы другим машинам. Это называется “NFS-экспортирование”, а предоставляемые файловые системы называют “экспортами”. Клиенты могут монтировать экспорты сервера почти точно так же как и локальные файловые системы.

Одним из интересных свойств NFS является отсутствие привязки клиента к текущему состоянию сервера (stateless). Вы можете перезагрузить сервер, при этом клиенты не “отвалятся”. Разумеется они не смогут получить доступ к экспортам сервера когда он отключен, однако как только сервер вернется в строй, вы сможете просто продолжить работу с места вашей остановки.

Ядро должно быть собрано с опцией

options NFSSERVER

Создаем файл экспорта /etc/exports, в котором описываются локальные точки системы, доступные для монтирования клиентами.
Мой файл выглядит так

/var/datas -maproot=root -alldirs 10.15.0.9
/var/data -maproot=root -alldirs 10.15.0.9

в моем файле две точки монтирования(/var/datas и /var/data). В одной строке максимум можно прописать три точки. Если их больше, то описываем их в следующей строке, но не более чем три точки на одну строку в файле.

Права доступа на точки экспорта в нашем случае описаны следующим образом:
— maproot=user
Права данного пользователя используются для удаленного подключения как root. Права включают все группы в которые входит пользователь на локальной машине. Может быть представлен по имени или uid (как в нашем примере).

10.15.0.9 – хост которому разрешено монтирование.

Далее делаем запись в /etc/rc.conf и перегружаем машину

rpcbind_enable=«YES»
nfs_server_enable=«YES»
nfs_server_flags=«-t -n 5 -h 10.15.0.2»
mountd_flags=«-r»
mountd_enable=«yes»

Описание параметров
rpcbind
— l – Turn on libwrap connection logging
— h – биндинг адреса для UDP requests (если не указать – будет слушать на всех доступных)
mountd
— r – Allow mount RPCs requests for regular files to be served
nfsd
— h – биндинг адреса
— t – параметр, указывающий обслуживать только TCP-клиентов (если требуется работать по протоколу UDP, следует указать параметр -u)
— n – количество создаваемых серверов

Ядро должно быть собрано с опцией

options NFSCLIENT

В /etc/rc.conf добавляем

nfs_client_enable=«YES»

Ну и собственно команды для монтирования

/sbin/mount_nfs -T 10.15.0.2:/var/data /var/data/ftp/pub/video1
/sbin/mount_nfs -T 10.15.0.2:/var/datas /var/data/ftp/pub/video2

На самом деле задача тривиальная, займет не более 5-10 минут. Принцип настройки одинаков для всех дистрибутивов. Разница скорее всего будет только в установке NFS. Следующим постом опишу процедуру настройки Apple TimeMachine для резервного копирования в нашу новую NFS-шару.

Итак...

1. Устанавливаем NFS server

# sudo apt-get install nfs-kernel-server nfs-common portmap

устанавливаем NFS client

# sudo apt-get install nfs-common portmap

Для того, чтобы убедится что у вас все установилось и запустилось выполните:

# rpcinfo -p

В выводе должен присутствовать nfs и mountd.

2. Настраиваем NFS

Для начала необходимо определится с расположением шар на диске. У меня это внешний ЖД с точкой монтирования /var/nfs.

mkdir /var/nfs
chown nobody:nogroup /var/nfs

Необходимо отредактировать /etc/exports (свой привожу ниже, там у меня всего одна строчка, для моего макбука):

/var/nfs          macfrac (rw,no_root_squash,sync,no_subtree_check,insecure)

Разберем эту строку:

/var/nfs — путь до шары

macfrac — имя хоста, который будет иметь доступ к шаре. Если на шаге 3 будут проблемы с определением адреса хоста, то добавьте необходимую запись в /etc/hosts. Правила для этого хоста:

(rw,no_root_squash,sync,no_subtree_check,insecure)

Тут я думаю все понятно из названия опций (кстати, будет не лишним также почитать документацию и man для более точной настройки под себя)... Остановлюсь только на insecure — в моем случае не получилось сразу примонтировать шару на удаленном компе. mount сообщал «Operation not permited». Одна из причин данного сообщения — попытка подключения с неизвестного порта. Как результат — ничего не монтируется.  После указания данной опции все заработало.

3. Добавляем шару в список доступных для NFS

# sudo exportfs -a

Для проверки експорта смотрим список доступных в данный момент ФС)

# showmount -e

В принципе, шару можно считать настроенной. Как подключить шару с хоста macfrac?! Вот рабочий (у меня) пример команды mount:

# sudo mount -t nfs <IP-адрес сервера NFS>:/var/nfs /media/nfs

Performance Tuning

NFS does not need a fast processor or a lot of memory. I/O is the bottleneck, so fast disks and a fast network help. If you use IDE disks, use hdparam to tune them for optimal transfer rates. If you support multiple, simultaneous users, consider paying for SCSI disks; SCSI can schedule multiple, interleaved requests much more intelligently than IDE can.

On the software side, by far the most effective step you can take is to optimize the NFS block size. NFS transfers data in chunks. If the chunks are too small, your computers spend more time processing chunk headers than moving bits. If the chunks are too large, your computers move more bits than they need to for a given set of data. To optimize the NFS block size, measure the transfer time for various block size values. Here is a measurement of the transfer time for a 256 MB file full of zeros.

# mount files.first.com:/home /mnt -o rw,wsize=1024
# time dd if=/dev/zero of=/mnt/test bs=16k count=16k
16384+0 records in
16384+0 records out

real 0m32.207s
user 0m0.000s
sys 0m0.990s

# umount /mnt

This corresponds to a throughput of 63 Mb/s.
Try writing with block sizes of 1024, 2048, 4096, and 8192 bytes (if you use NFS v3, you can try 16384 and 32768, too) and measuring the time required for each. In order to get an idea of the uncertainly in your measurements, repeat each measurement several times. In order to defeat caching, be sure to unmount and remount between measurements.

# mount files.first.com:/home /mnt -o ro,rsize=1024
# time dd if=/mnt/test of=/dev/null bs=16k
16384+0 records in
16384+0 records out

real 0m26.772s
user 0m0.010s
sys 0m0.530s

# umount /mnt

Your optimal block sizes for both reading and writing will almost certainly exceed 1024 bytes. It may occur that, like mine, your data do not indicate a clear optimum, but instead seem to approach an asymptote as block size is increased. In this case, you should pick the lowest block size which gets you close to the asymptote, rather than the highest available block size; anecdotal evidence indicates that too large block sizes can cause problems.