Дмитрий Морозов: Это оно, только очень уж обрывочно. Куча предупреждений об ошибках virtual_alias_maps, и в середине два сообщения об обработке письма amavis'ом. Факта приёма письма в процитированном участке логов не наблюдается.
Роман Мирр: как я уже говорил выше, профит от такой дедупликации будет ничтожный. А вот обслуживание дедупликации обойдётся в копеечку. В частности, дедупликация очень любит большие объёмы RAM. Дешевле будет докупить ещё дисков, нежели обеспечить дедуплицированные дисковые 40 Тб соответствующим количеством оперативки.
На лицензиях MS вы сможете только Storage Spaces крутить. Не самый плохой вариант, в общем-то. Соответственно, других вариантов, получается, что и нет.
Не, ну можете, конечно, попробовать ScaleIO или Ceph в проде :-)
Касательно ваших вопросов выше про Subversion: для SVN не нужен апач. Апач нужен только если вы веб-интерфейс собираетесь использовать к SVN. Нужен только svnserve (т.е. SVN сервер) и SVN-клиент (Например, GUI-шный TortoiseSVN). Но с SVN могут начаться тормоза, учитывая размеры ваших файлов. С другой стороны, вы ничего не теряете, если попробуете.
Репозиторий будет нужен в обязательном порядке -- это ж и есть место хранения всех ваших файлов с их версиями ;-) Но учитывая, что у вас бинарные файлы с БД, никакой дельты SVN высчитывать не будет. Так что планируйте сразу объём диска под репозиторий как сумму размеров всех копий и версий БД на N месяцев/лет вперёд.
phill kavinsky: Для того, чтобы сервер мог этими LUNами пользоваться, очевидно. А вот зачем они клиентским машинам -- вот это самый главный для меня вопрос. Вы что, собрались СХД-шку раздать юзерским рабочим станциям? Нафига? 8-[ ]
Алексей POS_troi: Непонятно только, почему все решили, что автор вопроса -- юзер :-) Может, он в хелпдеске работает. А может, он и есть этот самый админ, у которого должна быть схема коммутации, но её нет. Вот он и пытается придумать, как же её построить :-)
Евгений: это самый правильный ответ, так что сарказм тут неуместен. Если админ не в состоянии ответить на этот простой вопрос -- вооружайтесь консолью, и смотрите на ближайшем к роутеру коммутаторе, откуда он видит MAC вашего компа. И разматывайте цепочку коммутаторов.
Виталий Будаев: Если у вас жёсткий диск с wi-fi, то никакие облака вам не светят, только расшаренная папка. И то при условии, что ваш этот "жёсткий диск" умеет SMB.
SCM1:
> Или имеете ввиду, что с помощью Veeam будет происходить репликация виртуалок из одного
> хранилища в другое?
Да, именно так.
> А сам Veeam где лучше тогда устанавливать?) Получается, что если на одной из нод его ставить, то в
> случае ее выхода из строя, бэкап не развернуть?
Дело не в нодах. Если у вас выйдет хост (гипервизор) из строя, то машины останутся живы, и перезапустятся на оставшемся хосте. Но если у вас выйдет из строя хранилище -- тогда да, выйдет из строя и сервер Veeam. Поэтому его нужно держать где-то в третьем месте :-) Например, на локальном диске одного из гипервизоров, чтобы вылет общего хранилища не приводил одновременно к выходу из строя и системы репликации/восстановления. Да, при таком раскладе сервер Veeam не будет отказоустойчивым, и выпадет при выпадении этого гипервизора или его дисков. Но учитывая вашу конфигурацию -- это наиболее оптимальный вариант.
Если есть возможность -- копайте в сторону хранилища не на базе NAS-ов, а на базе микрософтовской технологии Scale-Out File server, с двумя серверами и подключенной к ним обоим дисковой корзинкой DAS по SAS-проводам.
sergey_privacy: Ну, вы спросили -- я ответил. Это единственная возможность прокачивать трафик напрямую между циской и фрёй. iperf -- идея гораздо лучше, но для этого нужно что-то размещать за роутерами и гонять трафик между фрёй и этим устройством/сервером.
В роутерах Cisco есть ip sla тесты, но там только jitter-ы. Они качество канала покажут, но не покажут пропускную способность.
