тут возник теоретический вопрос как бы сделать систему почтовую которая состоит из нескольких серваков, которые при нагрузке будут отдавать часть траффика другим, так сказать кластер, вобщем сделать то не сложно тока вопрос встал в том как они будут почту собирать в какое то единое хранилище, чтоб потом ее оттуда забирать, вот у МС есть такое решение кластеризации, есть мысли по этому поводу?
Ставили кластер на openmosixe там есть фича с единым каталогом которые по сети шарится, тока неизвестно как это в реале будет работать, интересны готовые решения, я че то поискал - не нашел.
>тут возник теоретический вопрос как бы сделать систему почтовую которая состоит из
>нескольких серваков, которые при нагрузке будут отдавать часть траффика другим, так
>сказать кластер, вобщем сделать то не сложно тока вопрос встал в
>том как они будут почту собирать в какое то единое хранилище,
>чтоб потом ее оттуда забирать, вот у МС есть такое решение
>кластеризации, есть мысли по этому поводу?
>Ставили кластер на openmosixe там есть фича с единым каталогом которые по
>сети шарится, тока неизвестно как это в реале будет работать, интересны
>готовые решения, я че то поискал - не нашел.решение есть, делаешь несколько MX + dbmail(dbmai.org), на каждом MX'e настрашиваешь чтобы dbmail-smtp использовал удаленный sql сервер, на удаленном sql сервер поднимаешь dbmail-[pop3d|imap4d].
>>тут возник теоретический вопрос как бы сделать систему почтовую которая состоит из
>>нескольких серваков, которые при нагрузке будут отдавать часть траффика другим, так
>>сказать кластер, вобщем сделать то не сложно тока вопрос встал в
>>том как они будут почту собирать в какое то единое хранилище,
>>чтоб потом ее оттуда забирать, вот у МС есть такое решение
>>кластеризации, есть мысли по этому поводу?
>>Ставили кластер на openmosixe там есть фича с единым каталогом которые по
>>сети шарится, тока неизвестно как это в реале будет работать, интересны
>>готовые решения, я че то поискал - не нашел.
>
>решение есть, делаешь несколько MX + dbmail(dbmai.org), на каждом MX'e настрашиваешь чтобы
>dbmail-smtp использовал удаленный sql сервер, на удаленном sql сервер поднимаешь dbmail-[pop3d|imap4d].
>Esli vopros v hranilische - beresh' server so SCSI RAID, gigabit ethernet card, podnimaesh' na nem NFS. Vse MX clustera natravlivaesh' na etot NFS. Sobstvenno vse. Esli potoki vhodyaschej pochty bol'shie (a zachem esche cluster) - sovetuju ispol' qmail - bystryj + maildir est'. A na NFS maildir - samoe ono.
Как уже было сказано:
Делаешь сервер для хранения почты и расшариваешь по NFS. Делаешь сервера с поддержкой CARP и примаунтиваешь туда хранилище. И получаешь в результате высоконадёжный кластер. Только ещё надо придумать как хранилище заделать надёжно.
некоторый опыт общения с НФС показал его нестабильную работу - отваливание,коннект не с первоого раза, не спорю что можно хорошо настроить, это все было из области баловства, но осадок остался, с хранилищем через сиквеловский сервак идея куда больше нравится 8)
Все таки интересно услышать как это в МС реализовано
Про HA системы и NFS сами придумали или прочитали где?
>Про HA системы и NFS сами придумали или прочитали где?Сами, всё сами... :)
>>Про HA системы и NFS сами придумали или прочитали где?
>Сами, всё сами... :)
Я так и подумал...
>>>Про HA системы и NFS сами придумали или прочитали где?
>>Сами, всё сами... :)
>Я так и подумал...Забыть про NFS как страшный сон.
Делать так. Ставишь cisco, модель не помню, нужно чтобы она умела смотреть статус канала. Один MX на эту циску. Одно хранилище в подержкой sql. Необходимое кол-во серверов с MTA - опять же с поддержкой sql.
Коннект идет на cisco, она пробрасывает его на наименее загруженный сервер. Сервер с помощью sql достает необходимые данные с хранилища.
>>>>Про HA системы и NFS сами придумали или прочитали где?
>>>Сами, всё сами... :)
>>Я так и подумал...
>
>Забыть про NFS как страшный сон.
>Делать так. Ставишь cisco, модель не помню, нужно чтобы она умела смотреть
>статус канала. Один MX на эту циску. Одно хранилище в подержкой
>sql. Необходимое кол-во серверов с MTA - опять же с поддержкой
>sql.
>Коннект идет на cisco, она пробрасывает его на наименее загруженный сервер. Сервер
>с помощью sql достает необходимые данные с хранилища.Чушь, а не решение. Любая циская умеет статус канала смотреть. вопрос в другом, статус канала как link up/down и переодический ping хоста в этой задаче бесполезное решение. А если хост в порядке и лишь smtp демон упал (от ручек или флуда или мало чего)? ваша циска его проверит? Ну дорогущий pix проверит, а если просто в это время smtp разгребает кучу? Баннер почтарь засветит, приглашение покажет, только ничего принимать/отправлять не будет. Глупое решение с циской.
Кстати почему sql? прошу на пальцах обьяснить "использование sql как безотказного хранилища."
Автору топика: вам в начале ответили о нескольких mx и нескольких агрегированных хранилищах. больше изобретать ничего не надо.
Если же так горит именно кластер, то распределённый файловые системы в *nix представленны более чем достаточно. хотя если вы читали про openmosix, почему вы недочитали до главы о dfs?
кстати
а почему именно sql?
>>>>>Про HA системы и NFS сами придумали или прочитали где?
>>>>Сами, всё сами... :)
>>>Я так и подумал...
>>
>>Забыть про NFS как страшный сон.
>>Делать так. Ставишь cisco, модель не помню, нужно чтобы она умела смотреть
>>статус канала. Один MX на эту циску. Одно хранилище в подержкой
>>sql. Необходимое кол-во серверов с MTA - опять же с поддержкой
>>sql.
>>Коннект идет на cisco, она пробрасывает его на наименее загруженный сервер. Сервер
>>с помощью sql достает необходимые данные с хранилища.
>
>Чушь, а не решение. Любая циская умеет статус канала смотреть. вопрос в
>другом, статус канала как link up/down и переодический ping хоста в
>этой задаче бесполезное решение. А если хост в порядке и лишь
>smtp демон упал (от ручек или флуда или мало чего)? ваша
>циска его проверит? Ну дорогущий pix проверит, а если просто
>в это время smtp разгребает кучу? Баннер почтарь засветит, приглашение покажет,
>только ничего принимать/отправлять не будет. Глупое решение с циской.
>
>Кстати почему sql? прошу на пальцах обьяснить "использование sql как безотказного хранилища."
>
>
>Автору топика: вам в начале ответили о нескольких mx и нескольких агрегированных
>хранилищах. больше изобретать ничего не надо.
>Если же так горит именно кластер, то распределённый файловые системы в *nix
>представленны более чем достаточно. хотя если вы читали про openmosix, почему
>вы недочитали до главы о dfs?
>
>
>кстати
>а почему именно sql?
я не только читал про опенмозикс, я его собрал на 6 машинах, правда требуюмую задачу распараллелить не удалось, а другую - тестовую удалось,было это года полтора назад. Про ДФС скорее всего уже просто запамятовал. Прочту. Только мне так и не ответили как это у Майкрософта работает с эксенджем, не верю что тут нет тех кто не знаком с их технологией
>Чушь, а не решение. Любая циская умеет статус канала смотреть. вопрос в
>другом, статус канала как link up/down и переодический ping хоста в
>этой задаче бесполезное решение.
Не link up/down смотреть, а именно балансировку делать.
>А если хост в порядке и лишь
>smtp демон упал (от ручек или флуда или мало чего)? ваша
>циска его проверит? Ну дорогущий pix проверит, а если просто
>в это время smtp разгребает кучу? Баннер почтарь засветит, приглашение покажет,
>только ничего принимать/отправлять не будет. Глупое решение с циской.
Если сервер перестает принимать почту - он автоматом исключается из списка доступных серверов.
>
>Кстати почему sql? прошу на пальцах обьяснить "использование sql как безотказного хранилища."Про "безотказное хранилище" я нигде не говорил. Просто почти все MTA поддерживают sql, не надо ничего придумывать.
>
>Автору топика: вам в начале ответили о нескольких mx и нескольких агрегированных
>хранилищах. больше изобретать ничего не надо.
>Если же так горит именно кластер, то распределённый файловые системы в *nix
>представленны более чем достаточно. хотя если вы читали про openmosix, почему
>вы недочитали до главы о dfs?
Да, или делать кластер. В любом случае решение будет дорогое.