Соседний пост и этот список видел. Видимо, вы неправильно поняли, интересует именно отзывы пользователей «больных» железок. Хм, или я вас неправильно понял, и у вас эти железки есть и они «больны»?
История несомненно увлекательная! Но у меня возник вопрос про MTU на виртуалках. Зачем там MTU меньше чем 1500?
Мне, как конечному пользователю, привычнее видеть MTU = 1500 байт. Опять же чем меньше MTU тем больше overhead стека TCP/IP.
Разве не лучше увеличить MTU на сетевом оборудовании датацентра и спрятать туда весь транспортный overhead оверлейных сетей?
Amarao прав, хотя и другие доводы верны. С трудом поймал мысль, которая крутилась в голове при прочтении поста + комментариев.
Собственно, текущая парадигма со 100% надежностью — эта наша реальность и в ней есть диски, блочные устройства, файловые системы. Не надо пытаться изменить существующую реальность, оставьте её как есть. Как и приводили в примерах, множество данных правильно хранить именно в такой парадигме.
Просто в новой парадигме не надо использовать старые понятия. Называйте в новой парадигме СХД — вероятностная система хранения данных. Не файл, а объект или документ. Не блочное устройство, а «узел хранения». Тогда уйдет непонимание «зачем это» и придет понимание «нужен новый софт».
Ещё один момент не был озвучен в слух. В новой парадигме, программа записывая данные должна указать с какой надежностью необходимо хранить именно этот объект. Что тоже невозможно в нашей реальности.
Посмотрите в сторону бесплатных систем мониторинга. Тот же, zenoss, например. Кроме централизованного syslog умеет ещё много чего полезного. Мониторинг ещё никому не мешал, тем более если оборудования много.
Вы не правы, роутер может гораздо больше. Поищите в интернете…
А по личному опыту скажу, что вполне обычный Linux роутер ( 2 x Xeon X5260@3GHz ) без напряга переваривает в пике 150kpps и 1,5 Гбит/сек в одну сторону. Плюс где-то 80% от этого в обратную сторону. И я уверен, что он может больше. Сервер делает NAT + ipt_netflow.
Никогда не встречал «белых» MAC-адресов =)
Устойчивая фраза «белый адрес» в моём понимании — глобально маршрутизируемый IP адрес.
Ошибка или некорректное использование «термина»? Работаю с сетями и эта фраза ой как глаз режет.
Правильно ли я понял, что все прокси выходят в интернет под одним IP адресом? Т.е. прокси имеют серый IP адрес на внешнем интерфейсе и потом пограничный маршрутизатор их NAT`ит?
Если на разных прокси будет настроен свой белый IP адреса, то будет плохо работать. Веб-сервера в интернете будут получать запрос с разных IP адресов для одной сессии пользователя, а многие привязывают сессию к IP адресу… СтОит добавить в текст.
Нормальные железки это лучшее решение безусловно. Сам работаю в достаточно крупном провайдере. И настраивал Cisco 4948, 3750G, ASR/ISG, SCE трогал и ещё и ещё. И всё ок. Терминировать и шейпить одно удовольствие.
Интересно что делать провайдерам, которые не могут себе позволить портратить по 1млн руб на NAT, shaping и L3 switch.
Кстати потестил ту же vyatta с 1Гбит/сек Intel сетевухой. 500 vlan подинтерфейсов поднимаются минуту или две. Однако еще больше создать не удалось, ошибка выделения памяти.
Биллинг с БД, вообще то, не трогали. Конечно, под это свой сервак.
Всего-то залить конфиг/прошивку — не аргумент. Посмотрите в сторону vyatta, например.
А вот скорость поднятия VLAN интерфейсов — это аргумент. Указанные цифры на практике видели или это предположение?
И про производительность. L3 switch обычно может 10-тки Гбит/сек. Однако если сеть — сотни абоннентов и десяток другой свичей, то зачем стрелять из пушки по воробъям. На агрегации хватит 1-2 Гбит производительности.
К тому же узким местом будет shaping и/или NAT. Так что мощь L3 switch будет не задействована.
Всё разделять не всегда верно. Конечно всё зависит нагрузки, денег и желания. Но в бюджетном варианте совмещение shaping + терминация VLAN считаю вполне разумным. Первый кандидат на вынос, конечно, NAT.
Скорее всего, у автора на тех же серверах реализуется ещё и traffic shaping, и NAT. Собственно вынос только терминации vlan в общей схеме ничего не упрощает.
Сам пользуюсь и софтовыми и аппаратными решениями. Не являюсь сторонником какого-то одного лагеря =)
Всё-таки про плюсы аппаратного решения:
— В жёстких требованиях по производительности выигрывает всё-таки честный аппаратный RAID на быстрых винтах. Покрайней мере наш отдел билинга так считает.
— Vmware ESXi умеет ставится только на аппаратный RAID. Софтварный RAID в инсталяторе не предусмотрен.
Я могу конечно придумать, почему лучше пользоваться софтовым рейдом и почему плох железный.
Но хотелось бы услышать ваш реальный опыт до «определённого момента» и после.
Мне, как конечному пользователю, привычнее видеть MTU = 1500 байт. Опять же чем меньше MTU тем больше overhead стека TCP/IP.
Разве не лучше увеличить MTU на сетевом оборудовании датацентра и спрятать туда весь транспортный overhead оверлейных сетей?
Собственно, текущая парадигма со 100% надежностью — эта наша реальность и в ней есть диски, блочные устройства, файловые системы. Не надо пытаться изменить существующую реальность, оставьте её как есть. Как и приводили в примерах, множество данных правильно хранить именно в такой парадигме.
Просто в новой парадигме не надо использовать старые понятия. Называйте в новой парадигме СХД — вероятностная система хранения данных. Не файл, а объект или документ. Не блочное устройство, а «узел хранения». Тогда уйдет непонимание «зачем это» и придет понимание «нужен новый софт».
Ещё один момент не был озвучен в слух. В новой парадигме, программа записывая данные должна указать с какой надежностью необходимо хранить именно этот объект. Что тоже невозможно в нашей реальности.
Прочитайте ещё раз мой коммент. Этот сервер не только роутит + снимает статистику по netflow, так ещё и NAT`ит.
А по личному опыту скажу, что вполне обычный Linux роутер ( 2 x Xeon X5260@3GHz ) без напряга переваривает в пике 150kpps и 1,5 Гбит/сек в одну сторону. Плюс где-то 80% от этого в обратную сторону. И я уверен, что он может больше. Сервер делает NAT + ipt_netflow.
Устойчивая фраза «белый адрес» в моём понимании — глобально маршрутизируемый IP адрес.
Ошибка или некорректное использование «термина»? Работаю с сетями и эта фраза ой как глаз режет.
Правильно ли я понял, что все прокси выходят в интернет под одним IP адресом? Т.е. прокси имеют серый IP адрес на внешнем интерфейсе и потом пограничный маршрутизатор их NAT`ит?
Если на разных прокси будет настроен свой белый IP адреса, то будет плохо работать. Веб-сервера в интернете будут получать запрос с разных IP адресов для одной сессии пользователя, а многие привязывают сессию к IP адресу… СтОит добавить в текст.
Не знал. Спасибо, может когда-то пригодится.
Интересно что делать провайдерам, которые не могут себе позволить портратить по 1млн руб на NAT, shaping и L3 switch.
Кстати потестил ту же vyatta с 1Гбит/сек Intel сетевухой. 500 vlan подинтерфейсов поднимаются минуту или две. Однако еще больше создать не удалось, ошибка выделения памяти.
На этом предлагаю закончить, т.к. оффтоп…
Производительность шейпера во FreeBSD и Linux сравнивали?
Всего-то залить конфиг/прошивку — не аргумент. Посмотрите в сторону vyatta, например.
А вот скорость поднятия VLAN интерфейсов — это аргумент. Указанные цифры на практике видели или это предположение?
И про производительность. L3 switch обычно может 10-тки Гбит/сек. Однако если сеть — сотни абоннентов и десяток другой свичей, то зачем стрелять из пушки по воробъям. На агрегации хватит 1-2 Гбит производительности.
К тому же узким местом будет shaping и/или NAT. Так что мощь L3 switch будет не задействована.
Сам пользуюсь и софтовыми и аппаратными решениями. Не являюсь сторонником какого-то одного лагеря =)
Всё-таки про плюсы аппаратного решения:
— В жёстких требованиях по производительности выигрывает всё-таки честный аппаратный RAID на быстрых винтах. Покрайней мере наш отдел билинга так считает.
— Vmware ESXi умеет ставится только на аппаратный RAID. Софтварный RAID в инсталяторе не предусмотрен.
Но хотелось бы услышать ваш реальный опыт до «определённого момента» и после.