Ядро сети на 2500+ абонентов

[LENS 105]

6 часов назад, ramsess сказал:

Я бы советовал присмотреться к Cisco ASR-1001X, 4х10G SFP+ интерфейса, мощный НАТ, с лицензиями никаких проблем, как BRAS самое оно. На ebay просят пять килобаксов что относительно гуманно.

У Cisco ASR 1001, 1002, 1004 и так далее в режиме BRAS существуют проблемы спонтанной перезагрузки всего устройства и не понятно почему.

На наге было много бесед насчет этого + по опыту коллег все хотят уйти от данного железа в сторону MX80 и выше

 

А если по теме, то скажу свое мнение.

Если у вас все получается на серверах и не сложно их сопровождать, то расширяйтесь на серверах.

Если с серверами не удобно и бывают проблемы (не важно какого характера) - покупайте один Juniper MX80 + MS-MIC-NAT и терминируйте клиентов на нем.
Для резерва можете не сворачивать серверную ферму, а держать ее в холодном резерве - ляжет джунипер, включите сервера.

[boroda 14]

Рассматриваем 3 варианта:

1. Добавить ещё один сервер и разделить доступ с биллингом + ещё один доступ чуть позже 

2. Биллинг на текущем сервере + 3-4 CCR 1036. ( один всегда в резерве)

3. МХ (но тут много нюансов) Согласимся, что один МХ держать на всю сеть, тоже самое что сейчас все на одном сервере, только в кучу раз дороже. 

 

P.S.

 

Никаких инвестиций и отмывания не предусматривается! Сеть своя, деньги из кармана. 

 

[Baneff 149]

58 минут назад, boroda сказал:

Рассматриваем 3 варианта:

1. Добавить ещё один сервер и разделить доступ с биллингом + ещё один доступ чуть позже 

2. Биллинг на текущем сервере + 3-4 CCR 1036. ( один всегда в резерве)

3. МХ (но тут много нюансов) Согласимся, что один МХ держать на всю сеть, тоже самое что сейчас все на одном сервере, только в кучу раз дороже. 

 

P.S.

 

Никаких инвестиций и отмывания не предусматривается! Сеть своя, деньги из кармана. 

 

Можно я ещё немножко тут насорю? У нас стоит задача повысить надёжность? Непонятно чем не устраивает то, что есть. В чём причина ненадёжности?

1. Увеличение кол-ва сущностей не увеличивает надёжность, а уменьшает её. Два сервера менее надёжны чем один, не говоря уже о большем их кол-ве. 2500 юзеров прекрасно выдержит и один сервер, это грубо где-то 3 гбит/с трафика в пиках всего-то. Туда влезет всё, если это дастаточно мощный многоядерный сервак с достаточным кол-вом памяти и он правильно настроен. Стоимость такого сервака сейчас копеечная, он уже 5 лет проработал в дата центре и ещё проработает 10 лет без проблем - там заложен большой запас прочности. В таких серваках очень развита система самоконтроля и имеется дистанционное управление, что немаловажно. Из плюсов - не надо изучать новую матчасть и не надо привлекать специалистов за деньги, всё уже известно. Далее сосредоточится на повышении надёжности. По возможности питание от двух-трёх независимых подстанций с автопереключением или генератор +  два UPS-а с аккумуляторами. Два-три независимых внешних канала с BGP. Два недорогих кондиционера для охлаждения, если это серверная без вентиляции. В самом серваке - два блока питания с горячей заменой, дисковая система с горячей заменой дисков. Диски SSD необходимого размера 3шт в RAID1 - вылет одного или двух дисков не приведёт к падению. Ну еще много чего можно сделать за деньги для повышения надёжности. Самое простое - поставить рядом такой-же точно второй сервак для горячей замены - дёшево и сердито. Замена отказавшего сервака на резервный - дело минут. Другое дело, если всё в один сервак не влазит из-за какой-то несовместимости или технологической необходимости. Ну тогда два сервака и один-два в горячем резерве. Ну это всё уже будет супернадёжно и стоить будет сильно дешевле одного MX. Да, ещё важный фактор надёжности - стабильность работы программных решений, конечно там всё должно быть вылизано до состояния работы без вмешательства оператор и перезагрузок в течение длительного времени. Никаких прихождений ногами раз в месяц и ручного вытирания! Профилактика и обновление ПО - только ночью в нерабочее время и как можно реже ибо злить юзеров - себе дороже. Работает - не трогай, никаких экспериментов на юзерах по улучшению и ускорению.

2. Каким образом это увеличит надёжность? Что выход из строя одной трети сети сильно лучше чем если всё поляжет? А вероятности-то перемножаются. Что, Микротики чем-то надёжнее? Постоянные дыры, постоянные обновления. Аппаратно там ничего нет для повышения надёжности. Цена опять же. Необходимость изучения и поддержки новых сущностей, тоже деньги. Главное - не вижу преимуществ в надёжности.

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

[sanyadnepr 305]

3 часа назад, boroda сказал:

2. Биллинг на текущем сервере + 3-4 CCR 1036. ( один всегда в резерве)

Кто предлагает этот пункт в части CCR ?

[melvin 66]

23 минуты назад, sanyadnepr сказал:

3 часа назад, boroda сказал:

2. Биллинг на текущем сервере + 3-4 CCR 1036. ( один всегда в резерве)

Кто предлагает этот пункт в части CCR ?

Как по мне, то это херовый вариант.

Уж лучше тогда на серваке все оставить.

[Kiano 616]

предложу вариант вынести всё на виртуалку, а второй сервак (можно чуток проще конфигой) держать в резерве.

бекапы баз постоянно в облако, бекап дистрибов (софта) - реже, но регулярно в облако.

б/у сервер до 20к грн. спокойно это всё разрулит

[CuriousMouse 2]

2 виртуалки vMX на 2-х разных серваках, в будущем при росте абон базы - миграция на MX5/104

[LENS 105]

1 час назад, CuriousMouse сказал:

2 виртуалки vMX на 2-х разных серваках, в будущем при росте абон базы - миграция на MX5/104

А лицензии на vmx сколько обойдутся?

[Baneff 149]

4 часа назад, Kiano сказал:

предложу вариант вынести всё на виртуалку,

 

 

2 часа назад, CuriousMouse сказал:

2 виртуалки vMX на 2-х разных серваках

А можно подробнее? Правда интересно. Что за виртуалки такие и как они помогут в данном конкретном случае увеличить надёжность? Если это виртуалки на локально расположенных серверах, то непонятно зачем, если и одного, ну на крайняк двух дешёвых физических серверов вполне хватает. Дополнительные расходы, на освоение новых сущностей и их поддержку, на лицензии. Это ж не дата центр, это серверная некрупного провайдера там нет стройных рядов стоек с серваками  под виртуализацию, там кроме этих одного-двух физических серваков и свичей вообще ничего нет. Что и где там виртуализировать? А если вопрос о виртуалке где-то в облаках или где-то в удалённом дата центре, то как туда притянуть терминацию юзеров и всё прочее, что должно быть расположено локально в силу своей специфики? Я чего-то не понимаю? Объясните, пожалуйста, подробнее.

[ramsess 186]

15 hours ago, LENS said:

У Cisco ASR 1001, 1002, 1004 и так далее в режиме BRAS существуют проблемы спонтанной перезагрузки всего устройства и не понятно почему.

На наге было много бесед насчет этого + по опыту коллег все хотят уйти от данного железа в сторону MX80 и выше

 

Курите правильные IOSы, на том же наге к этому заключению и пришли. https://forum.nag.ru/index.php?/topic/136947-vopros-nadezhnosti-cisco-asr1001-x/

И еще один нюанс ASR1001 != ASR1001X

Відредаговано 2018-12-25 14:54:27 ramsess

[boroda 14]

В 25.12.2018 в 11:12, sanyadnepr сказал:

Кто предлагает этот пункт в части CCR ?

Предлагает админ по биллингу, у которого я так понимаю своя сеть на такой схеме.

Мой админ не стал отрицать такую схему, но он больше в сторону MX, хотя понимает что это не дешево. МХ выходит около 10$ с натом.

 

В 25.12.2018 в 11:36, melvin сказал:

Как по мне, то это херовый вариант.

Уж лучше тогда на серваке все оставить.

Почему? в чем конкретно все так плохо? Их легко добавить в случае нагрузки и убрать нежели с серверами. Сервера с тем же ПО микротика конечно намного производительнее, тут не поспоришь...

Відредаговано 2018-12-26 11:12:53 boroda

[sanyadnepr 305]

1 минуту назад, boroda сказал:

Предлагает админ по биллингу, у которого я так понимаю своя сеть на такой схеме.

Чисто програмерский подход. N+, верно ?

Как на "микротике" Вы планируете диагностировать ? В сравнении с тем. Как диагностика происходит сейчас ?

 

[tkapluk 908]

8 минут назад, boroda сказал:

Предлагает админ по биллингу

 

8 минут назад, boroda сказал:

Мой админ не стал отрицать такую схему, но он больше в сторону MX

Ну да, не им же свои деньги тратить.  

 

Я так понимаю у вас проблема как раз в администрировании, а не в железе. 

[boroda 14]

3 минуты назад, sanyadnepr сказал:

Чисто програмерский подход. N+, верно ?

Как на "микротике" Вы планируете диагностировать ? В сравнении с тем. Как диагностика происходит сейчас ?

 

Что именно диагностировать?

Модете от себя рассказать о всех подводных камнях и прочей нечести в такой схеме? Заране спасибо 

 

[Kiano 616]

22 часа назад, Baneff сказал:

 

А можно подробнее? Правда интересно. Что за виртуалки такие и как они помогут в данном конкретном случае увеличить надёжность? Если это виртуалки на локально расположенных серверах, то непонятно зачем, если и одного, ну на крайняк двух дешёвых физических серверов вполне хватает. Дополнительные расходы, на освоение новых сущностей и их поддержку, на лицензии. Это ж не дата центр, это серверная некрупного провайдера там нет стройных рядов стоек с серваками  под виртуализацию, там кроме этих одного-двух физических серваков и свичей вообще ничего нет. Что и где там виртуализировать? А если вопрос о виртуалке где-то в облаках или где-то в удалённом дата центре, то как туда притянуть терминацию юзеров и всё прочее, что должно быть расположено локально в силу своей специфики? Я чего-то не понимаю? Объясните, пожалуйста, подробнее.

вам нужно всё официально и со всеми лицензиями? могу подсказать другой путь

итого: всё собирается, как я выше писал, на одной железке (сервере), где крутится гипервизор, а вирт машины - линухи/роутеросы

каждая виртуалка - отдельная ОС.

1) Биллинг

2) НАС

3) Роутинг

4) БЖП

5) етц..

[NightNET 81]

В 25.12.2018 в 10:36, melvin сказал:

Как по мне, то это херовый вариант.

Уж лучше тогда на серваке все оставить.

Чем он так херов? Есть реальные ситуации отказа , выхода из строя , нестабильной работы правильно настроенного MT CCR ? 

[boroda 14]

23 минуты назад, tkapluk сказал:

 

Ну да, не им же свои деньги тратить.  

 

Я так понимаю у вас проблема как раз в администрировании, а не в железе. 

Признаю, что с этим тоже не на 100% все хорошо 

[sanyadnepr 305]

31 минуту назад, boroda сказал:

Что именно диагностировать?

Возникшие проблемы. Как Вы сейчас диагностируете ?

Відредаговано 2018-12-26 11:55:07 sanyadnepr

[boroda 14]

11 минут назад, sanyadnepr сказал:

Возникшие проблемы. Как Вы сейчас диагностируете ?

Поэтому я и спросил, что именно? 

Проблем особых не бывает, если конкретно проблемы с сервером, то мой админ занимается поиском и устранинерием проблем, путём анализа логов, ошибок процессов и и.д. 

Я туда не лезу, поэтому не могу описать подробные действия... 

[Baneff 149]

51 минуту назад, Kiano сказал:

вам нужно всё официально и со всеми лицензиями? могу подсказать другой путь

итого: всё собирается, как я выше писал, на одной железке (сервере), где крутится гипервизор, а вирт машины - линухи/роутеросы

каждая виртуалка - отдельная ОС.

1) Биллинг

2) НАС

3) Роутинг

4) БЖП

5) етц..

Не, это прикольно, конечно, но вопрос остаётся всё тот-же: а зачем, собственно? Даже и без лицензий. Всё перечисленное вполне работает на одном физическом компе с одной ОС. Что хорошего привнесёт полная виртуализация всей страны в данном конкретном случае?

[Baneff 149]

24 минуты назад, boroda сказал:

Проблем особых не бывает, если конкретно проблемы с сервером, то мой админ занимается поиском и устранинерием проблем, путём анализа логов, ошибок процессов и и.д. 

Я туда не лезу, поэтому не могу описать подробные действия... 

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

[melvin 66]

2 часа назад, boroda сказал:

МХ выходит около 10$ с натом.

Какой MX?

[vop 370]

On 12/25/2018 at 3:09 PM, Baneff said:

 

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

В облако можно выкинуть то, что не требует терминации. Например, тот же биллинг, управление, и т.п. Облака нынче не дорогие с хорошими параметрами надежности.

Відредаговано 2018-12-26 14:42:40 vop

[melvin 66]

3 часа назад, NightNET сказал:

Чем он так херов? Есть реальные ситуации отказа , выхода из строя , нестабильной работы правильно настроенного MT CCR ? 

Я попробую описать, если чего-то упущу, было это года 3 назад - задавайте вопросы.

CCR1009-8G-1S-1S+ (Тарифный план 90% - 100 Мбит/с ), IPoE.

250 - на реальниках, 250 - Нат.

Один микрот держал спокойно 1,2 - 1,3 Г трафика.

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

Добавили второй.

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

Если оставить в одном влане - минимально получаем флаппинг между портами на коммутаторе, в которые воткнуты микроты.

Выросли запросы на увеличение абонов по NAT.

Возникла задача натить по 64 абонента через 1 белый IP - вырос список правил, стало тяжелее микротам.

Кол-во оборудования растет.

Под это оборудование начинаешь держать "теплый" запасной микрот.

Под теплый микрот начинаешь держать уже 2 теплых конфига.

Задолбались.

Взяли сервер:

Manufacturer:HP

Model:ProLiant DL360 G6

Processors:8 CPU x 3,066 GHz

Processor Type:Intel(R) Xeon(R) CPU X5667 @ 3.07GHz

 

Накатали на него Vmware ESXI.

Создали виртуалку без ограничений на ресурсы. Накатали RouterOS. Подключили на ней x86_64, Вкарячили драйвера VMXNET 3 (драйвер позволяет видеть и работать с сетевками 10G, практически напрямую, в отличии от эмуляторов E1000), чтобы работала и видела сетевку (10G),

Поделали "export file=" на микротах, с 2-х конфигов начали лепить один на RouterOS. Слепили, начали кормить комманды в терминал в RouterOS.

Синтаксис немного отличается железячный и RouterOS (Понятно, что название интерфейсов отличаются, но отличаются еще некоторые комманды.)

Начали кормить конфиг целиком - беда, RouterOS офигивает от большего кол-ва текста и ребутится.

Начали кормить конфиги по чуть-чуть. Скормили.

Задолбались.

Максимально комфортно работают 1100 абонентов NAT . c 10 вланов, куча правил по нату. Подсаживаем абонентов дальше. начались затыки, затупы после физической загрузки сервера в 70%. Не проработала схема и недели. 

Задолбались.

Создали 3 виртуалки, в каждую усадили 512 абонов нат со своими правилами и вланами.

Гемор уменьшился, заработало стабильно. Остановились на том, что одна виртуалка с RouterOS на 512 абонов ната.

Виртуалки растут. Больше 3-х на этом железе не получается - все те же 70% CPU

Под сервак держим еще один теплый сервак с виртуализацией и виртуальными машинами. Следим, чтобы каждая виртуалка с одного сервака распаковывалась на такую же виртуалку другого сервака. Переодически сверяем маки, которые выделены под сетевые интерфейсы в Vmware и маки, которые назначены в RouterOS, чтобы они совпадали.

Держим отдельную машину под Veeam Backup & Replication.

Отдельно сливаем бэкапы в облако и на внешний HDD.

Задолбались.

Много чего упустил в тексте.

Перешли на Juniper серии MX.

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

Задавайте вопросы.

Відредаговано 2018-12-26 15:02:15 melvin

[Kiano 616]

5 минут назад, melvin сказал:

Я попробую описать, если чего-то упущу, было это года 3 назад - задавайте вопросы.

CCR1009-8G-1S-1S+ (Тарифный план 90% - 100 Мбит/с ), IPoE.

250 - на реальниках, 250 - Нат.

Один микрот держал спокойно 1,2 - 1,3 Г трафика.

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

Добавили второй.

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

Если оставить в одном влане - минимально получаем флаппинг между портами на коммутаторе, в которые воткнуты микроты.

Выросли запросы на увеличение абонов по NAT.

Возникла задача натить по 64 абонента через 1 белый IP - вырос список правил, стало тяжелее микротам.

Кол-во оборудования растет.

Под это оборудование начинаешь держать "теплый" запасной микрот.

Под теплый микрот начинаешь держать уже 2 теплых конфига.

Задолбались.

Взяли сервер:

Manufacturer:HP

Model:ProLiant DL360 G6

Processors:8 CPU x 3,066 GHz

Processor Type:Intel(R) Xeon(R) CPU X5667 @ 3.07GHz

 

Накатали на него Vmware ESXI.

Создали виртуалку без ограничений на ресурсы. Накатали RouterOS. Подключили на ней x86_64, Вкарячили драйвера VMXNET 3 (драйвер позволяет видеть и работать с сетевками 10G, практически напрямую, в отличии от эмуляторов E1000), чтобы работала и видела сетевку (10G),

Поделали "export file=" на микротах, с 2-х конфигов начали лепить один на RouterOS. Слепили, начали кормить комманды в терминал в RouterOS.

Синтаксис немного отличается железячный и RouterOS (Понятно, что название интерфейсов отличаются, но отличаются еще некоторые комманды.)

Начали кормить конфиг целиком - беда, RouterOS офигивает от большего кол-ва текста и ребутится.

Начали кормить конфиги по чуть-чуть. Скормили.

Задолбались.

Максимально комфортно работают 1100 абонентов NAT . c 10 вланов, куча правил по нату. Подсаживаем абонентов дальше. начались затыки, затупы после физической загрузки сервера в 70%. Не проработала схема и недели. 

Задолбались.

Создали 3 виртуалки, в каждую усадили 512 абонов нат со своими правилами и вланами.

Гемор уменьшился, заработало стабильно. Остановились на том, что одна виртуалка с RouterOS на 512 абонов ната.

Виртуалки растут. Больше 3-х на этом железе не получается - все те же 70% CPU

Под сервак держим еще один теплый сервак с виртуализацией и виртуальными машинами. Следим, чтобы каждая виртуалка с одного сервака распаковывалась на такую же виртуалку другого сервака. Переодически сверяем маки, которые выделены под сетевые интерфейсы в Vmware и маки, которые назначены в RouterOS, чтобы они совпадали.

Держим отдельную машину под Veeam Backup & Replication.

Отдельно сливаем бэкапы в облако и на внешний HDD.

Задолбались.

Много чего упустил в тексте.

Перешли на Juniper серии MX.

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

Задавайте вопросы.

Именно про есхи я и писал, меня очень устраивает.