LINUX.ORG.RU
Форум — Admin  

Dovecot ящики на NFS

 , , , ,


0

1

Приветствую.
1. VPS Ubuntu, aaPanel, почтовый сервер Postfix+Dovecot..,
2. Сетевое хранилище Freenas, NFS.
Сервер 1 в Интернете на другой территории, 2-й в локальной сети офиса.
В планах сделать ящики, например «Архив», с каталогом хранения на Freenas. Основная цель экономия места на впс.
Бэкап каталога почты пользователей делается с помощью rsync, синхронизация на Freenas.

Два вопроса:
1.В случае сбоев сети Freenas, размонтирования сетевого диска и др., будут ли почтовые клиенты получать сообщение об ошибке?

2. Правильный конф?
```
namespace archive {
type = private
disabled = no
hidden = no
list = yes
inbox = no
prefix = Архив/
separator = /
location = maildir:/mnt/network_drive/%d/%u
mailbox Входящие {
auto = subscribe
}
mailbox Отправленные {
auto = subscribe
}
}
```



Последнее исправление: randreevich (всего исправлений: 3)
← Настройка хранения логов в elasticsearch
Запуск программ с GUI (графическим интерфейсом) из chroot. Новогодний рецепт. →
Ответ на: комментарий от usermod

Без перезагрузки всего сервера ничего работать не будет.

Это если NFSv3.

С NFSv4 оно, конечно, встанет раком при обращении к упавшей шаре, но отвиснет как только NFS-сервер вернётся в строй. Хотя на убунтах это может не работать, мне на дебиане NFS-клиента подключить к NFS-серверу на FreeBSD вообще не удалось (но, честно говоря, я не так уж и старался).

mord0d ★★★★★
()

размонтирования сетевого диска

Если прям размонтирования, то у тебя будет просто пустая директория, которая являлась маунтпоинтом для NFS-шары, если Dovecot имеет права на запись в эту диру (которые могут отличаться от прав на шару!), то он создаст структуру, и отдаст клиенту что там пусто.

Если же шара отвалится, то тут два сценария:

  • NFSv3: приложение, которое попытается обратиться к повисшей шаре, тоже зависнет, причём настолько намертво, что kill -9 $PID не поможет. Насколько я помню, NFSv3 не умеет сообщать о том, что оно вернулось в строй, потому перезагрузка машины неизбежна.

  • NFSv4: приложение, которое попытается обратиться к повисшей шаре, тоже зависнет, тоже намертво, его тоже не убить через kill -9 $PID, НО, NFSv4 умеет сообщать (если и на клиенте и на сервере работают соответствующие RPC-сервисы) что оно вернулось (и вроде даже что оно пошло в ребут, если он штатный), и как только соединение будет восстановлено, приложение отвиснет.

FIXME: В Linux поведение NFS может отличаться.

будут ли почтовые клиенты получать сообщение об ошибке?

Да, они отвалятся по таймауту. (%

И почему нет тега nfs? (=

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 2)
Ответ на: комментарий от anc

Почему именно nfs?

Не знаю других поддерживаемых протоколов. Ну и на Freenas другого нет. iSCSI вроде не будет работать, не поддерживается.
Рассматриваю любые варианты.

randreevich
() автор топика
Последнее исправление: randreevich (всего исправлений: 1)
Ответ на: комментарий от randreevich

Почему именно nfs?

Ну и на Freenas другого нет. iSCSI вроде не будет работать, не поддерживается.

Похоже что вы обманываете. Во всяком случае в анонсе FreeNAS 0.686b1 датированном 01.11.2007 есть строки «Upgrade Samba to 3.0.26a.» и «Upgrade iSCSI Target to version 20070925.».

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от router

зависнет, причём настолько намертво, что kill -9 $PID не поможет

А что, параметр «soft» для nfs уже отменили?

На v3 все ещё не очень было, но на лоре говорили, что в v4 починили окончательно.

anc ★★★★★
()
Ответ на: комментарий от router

На NFSv3 это позволяет отмонтировать зависшую шару до того, как к ней кто-то обратился (тоже не всегда), если уже кто-то завис, то umount тоже зависнет.

На NFSv4 проблему решили (причём soft вроде даже не нужен теперь), но необходимы(!) RPC-сервисы.

mord0d ★★★★★
()
Ответ на: комментарий от router

umount тоже зависнет

umount -l -f

-l - «lazy»

Нет такой опции во FreeBSD. (=
Есть -f — force, но на зависшие NFS он не влияет.

-N

Do a forced dismount of an NFS mount point without checking the mount path. This option can only be used with the path to the mount point node and the path must be specified exactly as it was at mount time. This option is useful when a process is hung waiting for an unresponsive NFS server while holding a vnode lock on the mounted-on vnode, such that umount with the -f flag can’t complete. Using this option can result in a loss of file updates that have not been flushed to the NFS server.

mord0d ★★★★★
()
Ответ на: комментарий от mumpster

У солярки реализация NFS отличается от фряхи. А в линуксе отличается и от солярки и от фряхи. Вот и получается что кто-то лучше дружит, кто-то хуже.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

С NFSv4 оно, конечно, встанет раком при обращении к упавшей шаре, но отвиснет как только NFS-сервер вернётся в строй. Хотя на убунтах это может не работать, мне на дебиане NFS-клиента подключить к NFS-серверу на FreeBSD вообще не удалось (но, честно говоря, я не так уж и старался).

Имею опыт работы с nfc. В плюсе быстрая работа, поддержка локов. С джамбо-фреймами скорость близка к максимуму соединения. Работает через туннели. Но и недостатков хватает. nfsv4 внезапно ругается на размер кадра и теряет данные. Зашибись. Принудительно выставляю v3, вроде работает. Но тут на днях опять ерунда. Две ноды в стойке, на одной шара работает, а на другой просто висит и все. Пока не зашел руками и не отмонтировал, висела как писюн на морозе. Отмонтировал, она автоматом соединилась и вперед, все работает. Не совсем это все то, на что я рассчитывал… И это все в идеальной системе 10G оптика сервер-свич-клиент.

usermod
()
← Настройка хранения логов в elasticsearch
Admin
Запуск программ с GUI (графическим интерфейсом) из chroot. Новогодний рецепт. →