[Картуччо]

Тема "тазики вс какой-то бренд" крайне баянная. Если поискать, то найдётся не один десяток, в том числе и очень очень объёмных.

[telecom]

В этот момент надо было принять решение - пилить дальше, или поставить аппаратное решение, опыт инсталляции и эксплуатации которого уже есть. Решили идти по второму пути - компенсировать недостаток ресурса Время, ресурсом Деньги. Тазики бы допилили в концее концов, но имидж компании за это время бы ухудшился.

Дело в том, что в жизни бывают разные варианты. Например, "тазики" то же разные существуют.

Например, у нас все сервера известного бренда, да и еще с сертификатом ССС, который стоимость добавляет, да еще и блоки питания везде сменили на DC. В итоге ценник примерно равный аппаратному решению, но функционал больше.

 

Есть конкурент в городе, который выбрал аппаратное решение, да еще и с техподдержкой. Так вот, они свою циску все вместе не один месяц пилили! Имидж их компании ухудшился....

[NiTr0]

На 300 мбит покупается б/у 7200.

Угу, софтроутер, но только с лейблом бренда :) На сеть в 500 абонов (где-то такая сеть нагенерит 300 мбит), где абон платит по $10 в среднем в месяц. И еще один купить в холодный резерв. Итого - эдак 20-30 килобаксов. При затратах только на канал порядка $2k для 300 мбит - сколько киска окупаться будет?

При этом, с такой нагрузкой справится какой-то целерон G530, с одной Intel Pro/1000 CT, и не поморщится. А если голый роутинг без туннелей - то и атома с набортным реалтеком хватит.

[Картуччо]

Что-то мне подсказывает, что взаимное непонимание происходит из-за разницы в масштабах.

У телематика оператор больше, у нитро меньше. Чем больше оператор, тем проще там использовать брендовые решения имея при этом поддержку производителя как во время разработки решения, так и далее в эксплуатации.

Денег стоит много, да, но и выручка большого оператора на порядки выше.

Маленькому же оператору не по силам покупать такие решения, спорить тут просто не о чем.

Так же, совершенно несерьёзно обсуждать расстановку тысяч маршрутизаторов на писи серверах где-нибудь в транстелекоме или билайне.

Часто приводят в пример гугл, но ведь там дешевые сервера (если они конечно еще используются) не выполняют функции сетевого оборудования.

[Zarin]

telecom, NiTr0,

 

Тут похоже не учитывается много других факторов аппаратных решений.

Для этого нужно ответить на вопросы, которые я задавал себе, пока 4 с лишним года пилил тазы под фряхой. Достаточно успешно :) (и продолжаю пилить)

 

1. У вас лялих/фря обновляются также просто как ios, junos, etc с возможностью откатится назад минуты за 3-4 ?

2. Ваши спецы уже раскурили, исходники ядра и всей обвязки необходимой для браса ? Хотя бы по мере появления очередных костылей от комунити.

3. Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

4. После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

5. У вас есть программисты с достаточным опытом, чтобы ковырять ядро фряхи/лялиха ?

 

Это не все, но было бы интересно послушать вас.

 

Я отвечая на эти вопросы, пришел к двум вариантам.

1. Либо написать свое (я про обвязку), так как в опенсорсе по большей части, отсутствует мотивация что-то делать до конца и нормально.

2. Либо использовать железо, там где это удобно. А не изобретать велик, каждый раз.

[s.lobanov]

3. Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

 

Зря вы это написали, сейчас начнут про 1+1 asbr, 1+1 bras и т.д. И в самом деле, такие схемы работают, с небольшими оговорками, но они и для брендовых шасси с 2умя mpu справделивы

[kapa]

1. У вас лялих/фря обновляются также просто как ios, junos, etc с возможностью откатится назад минуты за 3-4 ?

Зачем?

Работает - не трогай!

 

2. Ваши спецы уже раскурили, исходники ядра и всей обвязки необходимой для браса ? Хотя бы по мере появления очередных костылей от комунити.

Зачем? см. пункт 1.

Раскуривателей достаточно на форумах, в т.ч. и этом.

 

 

3. Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

А это зачем? Если сервак дохнет, то нагрузка распределяется по другим + смс дежурному и почта всем админам.

 

4. После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

Конечно. Все сразу не уволятся. А если уволятся - имеется вся документация по наработкам и актуальным конфигурациям, которая бэкапится.

 

5. У вас есть программисты с достаточным опытом, чтобы ковырять ядро фряхи/лялиха ?

Снова "зачем"?

[shicoy]

4. После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

Боюсь тут как раз и спорят специалисты которые бояться что их могут заменить в срочном порядке.

Как раз не так давно обращались, в ситуации, когда надо было разгребать что там наделано после одно такого самоделкина.

[nuclearcat]

1. У вас лялих/фря обновляются также просто как ios, junos, etc с возможностью откатится назад минуты за 3-4 ?

У меня да.

При этом на одной из работ запилил все ядро на l3 свитч, но вот на второй не выходит.

Сочинил линукс дистрибутив, где есть подобие прошивки, только файл не один, а 4-е (откатываемые: ядро+критический userspace в initramfs, драйвера, userspace, перманентный (без версий) r/w с файловой системой) Соответственно даже круче циски:

)Заливаются отдельно файлы новой версии. Ставим boot once. Перезагружаемся, система проходит сама regression тесты (пока простые, проверка на досягаемость контрольных IP). В случае ошибки тут же грузится назад старая версия. Время загрузки системы - около 5-6 секунд. Соответственно время на тестирование около 20 секунд.

)Есть возможность обновить отдельно какую-то подсистему без остановки

 

2. Ваши спецы уже раскурили, исходники ядра и всей обвязки необходимой для браса ? Хотя бы по мере появления очередных костылей от комунити.

Давно раскурил, пишу багрепорты и патчи.

 

3. Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

Включается горячий резерв. Причем резервирование выходит гораздо дешевле аппаратных решений. Но естественно downtime может достигать секунд, в случае циски, очень часто, это меньше. Хотя ASR* вообще забавно складываются, к примеру, независимо от резервных модулей.

 

4. После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

Безусловно, кроме того, система требует обслуживания только в случае необходимости новых фич. По унификации стараюсь приблизиться к тому, чтобы при необходимости можно было заменить на циску.

 

5. У вас есть программисты с достаточным опытом, чтобы ковырять ядро фряхи/лялиха ?

Есть

 

Я отвечая на эти вопросы, пришел к двум вариантам.

1. Либо написать свое (я про обвязку), так как в опенсорсе по большей части, отсутствует мотивация что-то делать до конца и нормально.

2. Либо использовать железо, там где это удобно. А не изобретать велик, каждый раз.

Если бы было всё готовoе, только ленивый бы не занял прибыльное место.

[NiTr0]

У вас лялих/фря обновляются также просто как ios, junos, etc с возможностью откатится назад минуты за 3-4 ?

Даже еще проще. Залил на репозиторий новые пакеты, запустил скрипт, поправил конфиги с изменениями в структуре по запросу, получил готовую систему. Надо сменить версию дистра (ядро сменилось и т.п.) - залил новые пакеты хором, ребут, после - запустил детект железа для подгрузки третьестепенных модулей.

Откат еще не пилил, как-то не нужно было. Ибо ни разу не было проблем с обновлением. Станет нужно - запилю, благое дело поддерживается загрузчиком.

 

Ваши спецы уже раскурили, исходники ядра и всей обвязки необходимой для браса ? Хотя бы по мере появления очередных костылей от комунити.

Вопрос, накой что-то раскуривать, когда все прекрасно работает искаропки? :) Раскуривать что-либо нужно только если есть проблемы, либо если хочется впилить свой функционал.

 

Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

Если сдох управляющий модуль, киска продолжит работать как ни в чем не бывало? Ах, есть 2 управляющих модуля, и второй подхватит управление через некоторое время? А чем это отличается от пары тазиков с VRRP либо от пары брасов с распределением нагрузки? Ну кроме цены решения ессно.

 

После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

Открою большой секрет: у дистрибутива нет срока годности, пилить что-либо нужно только если не устраивает имеющийся функционал. Открою второй большой секрет: найти специалиста не так уж и сложно, особенно если не требовать все и сразу, а подобрать толкового студента и дать ему возможность развиваться, попутно обучая его программированию и отучая от говнокодинга.

И открою третий, просто огромный, секрет: обычно мало кто пилит дистр в одиночку, злобно защищая все наработки в своей норке, гораздо эффективнее пилить его комьюнити. А кто поступает иначе - ССЗБ.

 

У вас есть программисты с достаточным опытом, чтобы ковырять ядро фряхи/лялиха ?

У вас есть спецы с достаточным уровнем знаний для дизассемблирования ядра IOS? Нет? А почему, как же вы без этого-то с циской работаете? :)

Зачем ковырять то, что работает и так? Ну кроме особых случаев, типа своего драйвера для какой-то суперсекретной железки, или какой-то сетевой фичи, которую никак штатным набором не реализовать.

 

Мы использовали LEAF 3.1 в качестве роутерного дистра, потом уже запилили 4-ю ветку на свежем ядре, с кучей плюшек, и для браса его же приспособили. К слову, один из софтроутеров так до сих пор и работает на alpha1 или alpha2 сборке 4-й ветки. Которой уже эдак года 2 исполнилось. И ничего...

 

А теперь ответьте мне на несколько вопросов:

1) Сколько будет стоить по деньгам/времени реализация чего-либо, отсутствующего в текущей фирмвари, для брендового железа?

2) Сколько времени будет длиться устранение бага фирмвари, приводящего скажем в определенной ситуации к крашу и ребуту? Особенно, если баг этот вылазит, в силу специфичности совокупности условий, у небольшого кол-ва клиентов?

3) Сколько специалистов-кисководов в вашем городе, которые способны определить причины внезапно возникших крашей/висов ваших кисок, и оперативно реализовать какое-либо обходное решение, до официального патча, фиксящего проблему?

4) Как много специалистов-кисководов, не занятых работой у других провов, имеется в вашем городе?

5) Сколько времени занимает ремонт киски в случае выгорания, и что случится, к примеру, если благодаря мощному грозовому разряду в здание серверной сгорит несколько железяк (все-таки импульс в несколько киловольт и током в несколько килоампер далеко не каждый фильтр/ИБП сможет погасить без последствий для нагрузки)?

6) Сколько квалифицированных программистов можно содержать в течение года на сумму, равную разнице между железным/"типа железным" и софтовым решениями для мелкого/среднего оператора с каналами эдак сотни мегабит-единицы гигабит?

7) Кто вам будет обслуживать (и за какие деньги) биллинговый сервер и прочие *nix-машины, которые в обслуживании будут сложнее, чем роутеры/брасы?

[Картуччо]

Даже еще проще. Залил на репозиторий новые пакеты, запустил скрипт, поправил конфиги с изменениями в структуре по запросу, получил готовую систему. Надо сменить версию дистра (ядро сменилось и т.п.) - залил новые пакеты хором, ребут, после - запустил детект железа для подгрузки третьестепенных модулей.

Ну как же это проще ?

Берём циску - заливаем во флеш по ftp/tftp всего один файл, говорим, что грузиться с него, перегружаемся, готово.

Откат - сказать, что грузиться со старого файла во флеш.

 

Если сдох управляющий модуль, циска продолжит работать как ни в чем не бывало?

на современном железе вполне возможно, датаплейн продолжит работать без контролплейн.

[Alex/AT]

на современном железе вполне возможно, датаплейн продолжит работать без контролплейн

Это про CRSы, или? Какая моделька умеет такое? ASR - точно нет, 76xx - тоже, даже с DFC.

 

1. У вас лялих/фря обновляются также просто как ios, junos, etc с возможностью откатится назад минуты за 3-4 ?

2. Ваши спецы уже раскурили, исходники ядра и всей обвязки необходимой для браса ? Хотя бы по мере появления очередных костылей от комунити.

3. Если сдох камень или планка памяти, сервак продолжает работать как ни в чем не бывало ?

4. После того, как ваши спецы разобрались во всех необходимых тонкостях, есть еще шансы их заменить в срочном порядке ?

5. У вас есть программисты с достаточным опытом, чтобы ковырять ядро фряхи/лялиха ?

1. Да. Образ. Более того - назад можно откатиться за несколько секунд - просто бут со вторичного корня.

2. Да.

3. Циска тоже не сумеет, если не два управляющих модуля. Серваки с резервированием по памяти и CPU, кстати, бывают. Только смысл?

На сий вопрос ответ очень прост: падает один BRAS - остальные (и вовсе не 1+1, а просто N) перехватывают его абонентов. Не на горячую, с обрывом сессий, но перехватывают. За 2 года не случалось.

4. Не знаю. Незаменимых людей не бывает.

5. Да.

Изменено 28 марта, 2012 пользователем Alex/AT

[NiTr0]

Ну как же это проще ?

Дык ребутиться не надо :) А смена версии ядра - единственное, что может потребовать ребут - редкое явление для дистра, ибо без особой нужды не происходит...

 

на современном железе вполне возможно, датаплейн продолжит работать без контролплейн.

Ну свичевать-то как-то будет. Только толку, коли на нем OSPF/BGP/что там еще отвалится...

[Картуччо]

Это про CRSы, или? Какая моделька умеет такое? ASR - точно нет

В доке на ASR написано, что может, врут ?

[Kuzema]

я так понимаю уже вопрос просто ко времени загрузки/перезагрузки системы.

 

у меня bsdrp грузится 14 секунд.

 

то есть перезагрузка/откат к старой сборке/конфигам - секунд 30.

 

сколько это у современной циски с заливкой по TFTP?

Изменено 28 марта, 2012 пользователем Kuzema

[Картуччо]

А дальше спор скатится к аптаймам :)

что время перезагрузки то не важно.

Посмотрел, на паре железок 1699 дней, в среднем 2-3 года. Какой тут смысл в 30 секундах ?

[nuclearcat]

Ну как же это проще ?

Берём циску - заливаем во флеш по ftp/tftp всего один файл, говорим, что грузиться с него, перегружаемся, готово.

Откат - сказать, что грузиться со старого файла во флеш.

Ну у меня и говорить не надо. Более того, на старом системе все BRAS-ы разбросанные по стране коннектятся на центральную ноду и сливают телеметрию (температуру, нагрузку, инфа о перезагрузках и т.п.), и принимают команды на апдейт или массовую смену конфига.

Попробуйте запилить такое на циске.

 

на современном железе вполне возможно, датаплейн продолжит работать без контролплейн.

В некоторых случаях, паника ядра не останавливает рутинг (если это не сетевой сбой). Только в большинстве случаев роутер без контролплейн бесполезен. Особенно любопытно, как он будет с дохлым плейном отвечать на BGP keepalive. Роутить он то будет, но без анонсов не видать ему траффика.

При особом желании на Линуксе можно запилить так, что единственная BGP сессия будет жить одновременно на двух роутерах (есть уже патчи для хитрого перехвата TCP сессий), только такой изврат не нужен.

[Картуччо]

Попробуйте запилить такое на циске.

Да нет с этим проблем. Есть софт от циско, который централизованно может управлять, апдейтить, править что-то в конфигах и всякое такое.

[s.lobanov]

Ну у меня и говорить не надо. Более того, на старом системе все BRAS-ы разбросанные по стране коннектятся на центральную ноду и сливают телеметрию (температуру, нагрузку, инфа о перезагрузках и т.п.), и принимают команды на апдейт или массовую смену конфига.

Попробуйте запилить такое на циске.

 

На циске "телеметрия" сливается наооборот("центральная нода" коннектится к железках и собирает данные), принимать команды на апдейт или массовую смену конфигу - легко, настраиваете snmp на циске и отправляете туда запросы.

[s.lobanov]

В некоторых случаях, паника ядра не останавливает рутинг (если это не сетевой сбой). Только в большинстве случаев роутер без контролплейн бесполезен. Особенно любопытно, как он будет с дохлым плейном отвечать на BGP keepalive. Роутить он то будет, но без анонсов не видать ему траффика.

При особом желании на Линуксе можно запилить так, что единственная BGP сессия будет жить одновременно на двух роутерах (есть уже патчи для хитрого перехвата TCP сессий), только такой изврат не нужен.

 

Для ospf, bgp и ldp есть GR(graceful restart) который как раз создан для того, чтобы в момент отмирания основного mpu (в том числе)не рвались сессии с соседями(при этом в линейных картах fib и lfib уже есть), а после того, как заработает резервный mpu, будут получены обновления по роутинговым и сигнальным протоколам и будет обновлён fib/lfib. Это реально работает, перерыва связи при этом процессе нет, но недешёвое удовольствие.

[kapa]

А дальше спор скатится к аптаймам :)

что время перезагрузки то не важно.

Посмотрел, на паре железок 1699 дней, в среднем 2-3 года. Какой тут смысл в 30 секундах ?

Какой смысл в аптаймах и времени перезагрузки, если во время перезагрузки нагрузку на себя принимают другие сервера?

Если не ребутить постоянно, то периодические разрывы сессий совершенно никого не беспокоят.

[telematic]

7) Кто вам будет обслуживать (и за какие деньги) биллинговый сервер и прочие *nix-машины, которые в обслуживании будут сложнее, чем роутеры/брасы?

 

Это ещё почему?

 

А, догадался, у вас биллинг самописный, наверное :-)

Изменено 28 марта, 2012 пользователем telematic

[Картуччо]

И снова эффект масштаба. Сетевики не обслуживают биллинг. Биллинг это биллинг. ОС и железо под него - отдельный вопрос и задача. СУБД тоже отдельно.

[Alex/AT]

Это про CRSы, или? Какая моделька умеет такое? ASR - точно нет

В доке на ASR написано, что может, врут ?

Насчет умирания RP (который по совместительству CP) - нет, без него оно не живёт. RP контролирует всю систему. Возможность использования двух RP (и ESP тоже) есть только на 1006/1013.

При отмирании софта BGP точно встает, ARP тоже. Т.е. форвардить-то оно аппаратно, если живы ESP/SPA, и interconnect fabric на RP, в теории продолжить может, но совершенно непонятно, куда.

Изменено 29 марта, 2012 пользователем Alex/AT

[BiWiS]

Картуччо тут уже написал откуда ноги у спора растут :)

Операторы работающие в ареале с 50+ тыс. домохозяйств и 5-10 тыс. находятся в разных экономических условиях как правило и имеют разные возможности наема специалистов.

Отсюда и разумность использования той или иной схемы.