Есть необходимость создать мощный сервер доступа:
поддержка туннелей/ nat / netflow.Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при работе с сетевыми интерфейсами/протоколами, linux или freebsd?
(в случае freebsd использоваться будет предположительно pf-nat/ipcad/ipfw/mpd)
(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)
>Есть необходимость создать мощный сервер доступа:
>поддержка туннелей/ nat / netflow.
>
>Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при
>работе с сетевыми интерфейсами/протоколами, linux или freebsd?
>
>(в случае freebsd использоваться будет предположительно pf-nat/ipcad/ipfw/mpd)
>(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)Подходит любая. Если вы знаете FreeBSD лучше, пользуйтесь ей.
>>Есть необходимость создать мощный сервер доступа:
>>поддержка туннелей/ nat / netflow.
>>
>>Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при
>>работе с сетевыми интерфейсами/протоколами, linux или freebsd?
>>
>>(в случае freebsd использоваться будет предположительно pf-nat/ipcad/ipfw/mpd)
>>(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)
>
>Подходит любая. Если вы знаете FreeBSD лучше, пользуйтесь ей.Мне интересно, возростет ли быстродействие/мощность freebsd при использовании скажем 2 X intel xeon 2hz вместо intel p4 3hz? Слышал, что на сетевом уровне freebsd не очень хорошо справляется с двумя процессорами , так что гнаться за процессорами смысла нет для увеличения мощности сервера. Не подскажете, насколько это правда?
>Мне интересно, возростет ли быстродействие/мощность freebsd при использовании скажем 2 X intel
>xeon 2hz вместо intel p4 3hz? Слышал, что на сетевом уровне
>freebsd не очень хорошо справляется с двумя процессорами , так что
>гнаться за процессорами смысла нет для увеличения мощности сервера. Не подскажете,
>насколько это правда?Неправда. В FreeBSD уже давно реализована поддержка SMP. Я использую многопроцессорные сервера на Xeon, с установленным FreeBSD 6.2, и все супер. Но особенно порадовала перспектива:
http://people.freebsd.org/~kris/scaling/scaling.png
>(в случае freebsd использоваться будет предположительно pf-nat/ipcad/ipfw/mpd)
>(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)На тему FreeBSD очень рекомендую попользовать патч от Paolo Pisati для linbalias и ipfw, позволяет натить большие потоки с малой нагрузкой. Единственное "но" - он накатывается только на релиз 6.2, дальше поломали, хотя в 7 включили.
>>(в случае freebsd использоваться будет предположительно pf-nat/ipcad/ipfw/mpd)
>>(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)
>
>На тему FreeBSD очень рекомендую попользовать патч от Paolo Pisati для linbalias
>и ipfw, позволяет натить большие потоки с малой нагрузкой. Единственное "но"
>- он накатывается только на релиз 6.2, дальше поломали, хотя в
>7 включили.Спасибо, но ведь ipfw сам по себе не натит ничего. (натит либо natd - в юзерленде, либо pf, в ядре, что лучше), на что влияет патч?
>[оверквотинг удален]
>>>(в случае linux ориентировочно будет использоваться ipnat/ipfiler/ipcad)
>>
>>На тему FreeBSD очень рекомендую попользовать патч от Paolo Pisati для linbalias
>>и ipfw, позволяет натить большие потоки с малой нагрузкой. Единственное "но"
>>- он накатывается только на релиз 6.2, дальше поломали, хотя в
>>7 включили.
>
>Спасибо, но ведь ipfw сам по себе не натит ничего. (натит либо
>natd - в юзерленде, либо pf, в ядре, что лучше), на
>что влияет патч?Видимо уже натит =)
но только (вопрос нерешаемый), чем он лучше pf-nat или же ip-nat.
>[оверквотинг удален]
>>>и ipfw, позволяет натить большие потоки с малой нагрузкой. Единственное "но"
>>>- он накатывается только на релиз 6.2, дальше поломали, хотя в
>>>7 включили.
>>
>>Спасибо, но ведь ipfw сам по себе не натит ничего. (натит либо
>>natd - в юзерленде, либо pf, в ядре, что лучше), на
>>что влияет патч?
>
>Видимо уже натит =)
>но только (вопрос нерешаемый), чем он лучше pf-nat или же ip-nat.Хороший сервер доступа - это аппартаное решние или у Вас там 10 клиентов)
Как альтернатива рекомендую использовать решения на основе ОС Linux, поскольку в базом виде можно многое сконфигурировать без каких-либо патчей(прошу прошения у любителей патчей).
А вообще я Вам рекомендую снало для себя определиттся, что Вам нужно и какие цели - составить некий проект и дальше исходить из возможностей...
Так же рекомендуюю не ставить сете целей получить максимальную производительность от NAS, лучше продумайте схему, когда применяется несколько серверов, продумайте варианты отказоустойчивости и распределения нагрузки, тарификации клиентов.
Реализация - это дело техники и умения инжера.
Желаю удачи.
За счет обработки данных исключительно на уровне ядра, FreeBSD выиграет при организации VPN (PPTP) c использованием MPD.
>
>
>За счет обработки данных исключительно на уровне ядра, FreeBSD выиграет при организации
>VPN (PPTP) c использованием MPD.Поймите одну простую истину, что терминация клиентов - это оказание сервисов подписчикам...А уровень этого сервиса опредеяет общее качетво - если для Вас основной принцип "главное чтоб работао" - то самое простое использовать, что угодно в том числе и PC.
Но иногда здорово подумать какой выигрыш?Если расмотривать на уровне маленького офиса 20-30 машин и если задачи возогаемые на комплекс не являются основной дейстельностью и не несут в себе особых рисков - то в этом случае устанавливайте что угодно.
Но к примеру для операторов свзяи практически у любого производителя сетевого оборудования есть предложения, заодно и посчитайте чего обходится терминация к примеру 100 клиентов.
Просто для всего есть свое решение, безусловно траншее можно рыть детским совком в виде PC на основе freebsd, а можно использовать специализированные средства...
Вероятнее всего на многое влияет опыт и уровень квалификации тех. персонала организации.
>Просто для всего есть свое решение, безусловно траншее можно рыть детским совком
>в виде PC на основе freebsd, а можно использовать специализированные средства...Системный интегратор?
>Вероятнее всего на многое влияет опыт и уровень квалификации тех. персонала организации.
+100
>
>>Просто для всего есть свое решение, безусловно траншее можно рыть детским совком
>>в виде PC на основе freebsd, а можно использовать специализированные средства...
>
>Системный интегратор?Судя по ошибкам это опять "Вася"... Писать еще не научился, а все учить норовит.
имхо, лучше циску =)
если все-таки ос, то прежде всего то, что знаете лучше.
обязательно продумайте резервирование (если бсд, то тем же carp)
ну и все-таки подробней озвучьте предпологаемые нагрузки
>Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при
>работе с сетевыми интерфейсами/протоколами, linux или freebsd?
>При грамотной настроке пох. Разница +/- 10% в ту или иную сторону непринципиальна.
Хотя в 7й фряхе заманчиво выглядят TCO/LRO
>[оверквотинг удален]
>обязательно продумайте резервирование (если бсд, то тем же carp)
>ну и все-таки подробней озвучьте предпологаемые нагрузки
>>Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при
>>работе с сетевыми интерфейсами/протоколами, linux или freebsd?
>>
>
>При грамотной настроке пох. Разница +/- 10% в ту или иную сторону
>непринципиальна.
>
>Хотя в 7й фряхе заманчиво выглядят TCO/LRO1. Есть рекомендованные рабочие решения (аппаратные) поддерживаемые
2. Есть вероятно рабочие, но не подерживаемые решенияЯ думаю, что бюджет проекта формирует же кто-то=) ?!
>[оверквотинг удален]
>обязательно продумайте резервирование (если бсд, то тем же carp)
>ну и все-таки подробней озвучьте предпологаемые нагрузки
>>Если выбирать из двухпроцессорных серверов, какая система лучше поддерживает многопроцессорность именно при
>>работе с сетевыми интерфейсами/протоколами, linux или freebsd?
>>
>
>При грамотной настроке пох. Разница +/- 10% в ту или иную сторону
>непринципиальна.
>
>Хотя в 7й фряхе заманчиво выглядят TCO/LROЧто циску это понятно.
Но пока нагрузка не выростет скажем > 90 мбит/c (либо скажем > 800 одновременных vpn) смысл брать циску? (а какой-нибудь vpn-bundle на 1500 соед. будет стоить тыщ 10$),а freebsd+mpd работает очень не плохо.
С циской работаем - знаем.Про carp тоже думаем, чтобы был резервный сервер, либо в качестве баллансровки.
А что такое TCO/LRO?
И еще вопрос, какая еще есть альтернатива для поддержки vpn (помимо cisco vpn-concentrator)
(желательно не только вендор, а именно модель)?
>И еще вопрос, какая еще есть альтернатива для поддержки vpn (помимо cisco
>vpn-concentrator)
>(желательно не только вендор, а именно модель)?а я считаю, что VPN - это технология обединения удаленных офисов/филиалов, но не как не техноолгии доступа для "массовых" клиентов.
Зачем в езернет сети нужна дополнительные грабли и дополнительная инкапсуляция ?
Есть куда более "красивые" и управляемые решения.
>>И еще вопрос, какая еще есть альтернатива для поддержки vpn (помимо cisco
>>vpn-concentrator)
>>(желательно не только вендор, а именно модель)?
>
>а я считаю, что VPN - это технология обединения удаленных офисов/филиалов, но
>не как не техноолгии доступа для "массовых" клиентов.
>Зачем в езернет сети нужна дополнительные грабли и дополнительная инкапсуляция ?
>Есть куда более "красивые" и управляемые решения.Это понятно, есть pppoe, или просто статическая привязка =)
>>>И еще вопрос, какая еще есть альтернатива для поддержки vpn (помимо cisco
>>>vpn-concentrator)
>>>(желательно не только вендор, а именно модель)?
>>
>>а я считаю, что VPN - это технология обединения удаленных офисов/филиалов, но
>>не как не техноолгии доступа для "массовых" клиентов.
>>Зачем в езернет сети нужна дополнительные грабли и дополнительная инкапсуляция ?
>>Есть куда более "красивые" и управляемые решения.
>
>Это понятно, есть pppoe, или просто статическая привязка =)можно и без привязки.
