Jump to content
Local
inspire_871

Падают BRASы

Recommended Posts

Есть в работе несколько BRASов (6), до всех модернизаций в каждом сервере стояли 2 портовые медные интеловские сетевые карты. Было решено расширить 4 наса из 6 с помощью добавления в каждый по сетевой карте с последующим объединением 2 портов одной сетевой в бонд. Софт брасов не новый, едем на том что было ранее настроено. Как итог сейчас имеем: при кратковременном скачке электричества по районам - насы где стоят карты с бондами становятся раком (циклический ребут). Насы где нет бондинга, софт такой же как и в остальных, не уходят в ребут. Думали что проблема может быть из-за бонда, заменили на одном из насов на сетевую x520, проблема осталась. Малейший скачек света тянет в циклический ребут. При отключении электричества на районе на 3-5 минут и с последующим возобновлением проблем не наблюдается, клиенты спокойно подключаются и сервера не падают. Куда копать?

Share this post


Link to post
Share on other sites

Железо где проблемы: Xeon X3440 сокет 1156 12 Гб оперы, железо где нет проблем сокет 775 проц X5450 3.00GHz 4 Гб оперы. 

Share this post


Link to post
Share on other sites

Странно что никто не предложил полечить ээ путем установки нормальных Ups. 

Edited by Den_LocalNet
  • Like 5
  • Thanks 1
  • Haha 2

Share this post


Link to post
Share on other sites
5 часов назад, Den_LocalNet сказал:

Странно что никто не предложил полечить ээ путем установки нормальных Ups. 

ну это же не наш метод)))

Share this post


Link to post
Share on other sites

можна еще заглянуть, в бп нет ли вздутых коднеров. Еще когда было в 15 году трафика до 200мбит На 775 сокете core 2 quad 9550. Рубалась сетевая интел в сторону абонентов. В блок не простой, а из хороших чифтек, 9 кондеров надутые. Перепаяли, по сей день работают.

Share this post


Link to post
Share on other sites
9 часов назад, inspire_871 сказал:

Железо где проблемы: Xeon X3440 сокет 1156 12 Гб оперы, железо где нет проблем сокет 775 проц X5450 3.00GHz 4 Гб оперы. 

Метод исключения - не, не пробовали? Ну ладно, озвучу. Тут, на самом деле, могут быть и проблемы с БП и вздутые кондёры и проблемы с охлаждением... Вы бы специалистам™ отдали на диагностику - всяко лучше будет. Или как всегда - начальство жлобствует?

Share this post


Link to post
Share on other sites
1 час назад, ISK сказал:

Метод исключения - не, не пробовали? Ну ладно, озвучу. Тут, на самом деле, могут быть и проблемы с БП и вздутые кондёры и проблемы с охлаждением... Вы бы специалистам™ отдали на диагностику - всяко лучше будет. Или как всегда - начальство жлобствует?

так тут обычно и начальство пишет ☺️

  • Haha 1

Share this post


Link to post
Share on other sites

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

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

  • Haha 1

Share this post


Link to post
Share on other sites
1 минуту назад, Sided сказал:

так тут обычно и начальство пишет ☺️

Так это таки sehr gut! Пусть видят свои грехи - кто ж им ещё правду в глаза скажет - не подчинённые же...

Share this post


Link to post
Share on other sites
4 часа назад, zulu_Radist сказал:

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

Это как раз и происходит, проблема не со светом в серверной, в серверной упсы стоят. Моргает свет на районе и ребуты серверов, при отключении на 2-3-5 минут света на районе с последующим его включением проходит нормально, ничего не ребутится. На бутающихся серваках уже уменьшили PADI, но как оказалось от этого легче не стало. 

Share this post


Link to post
Share on other sites

Битва экстрасенсов, не иначе.  Логи? - Не не слышал. Конфиги железа? - да ну нах@р )

Давайте предположим, что БП не вытягивает нагрузку. В штатной ситуации - когда все ровно - процессор курит и переходит в режим энергосбережения. В случае ахтунга, идет увеличение нагрузки на ЦП, и соответственно увеличивается нагрузка на БП.

 

Edited by foreverok

Share this post


Link to post
Share on other sites
36 минут назад, inspire_871 сказал:

Это как раз и происходит, проблема не со светом в серверной, в серверной упсы стоят. Моргает свет на районе и ребуты серверов, при отключении на 2-3-5 минут света на районе с последующим его включением проходит нормально, ничего не ребутится. 

Не все упсы одинаково полезны. 

Share this post


Link to post
Share on other sites

Проверяйте на наличие дутых конденсаторов на материнских платах, а также в блоках питания.

Если не поможет - попробуйте поменять блок питания.

Share this post


Link to post
Share on other sites
5 часов назад, inspire_871 сказал:

Это как раз и происходит, проблема не со светом в серверной, в серверной упсы стоят. Моргает свет на районе и ребуты серверов, при отключении на 2-3-5 минут света на районе с последующим его включением проходит нормально, ничего не ребутится. На бутающихся серваках уже уменьшили PADI, но как оказалось от этого легче не стало. 

Не Accel случаем стоит? Наблюдалось похожее поведение на каком-то старом асселе.

Share this post


Link to post
Share on other sites
11 минут назад, hex@set сказал:

Не Accel случаем стоит? Наблюдалось похожее поведение на каком-то старом асселе.

Accel. Нет возможности сейчас доступа к логам получить и скинуть сюда. Как лечилось в последние падения насов: отключение самых жирных веток на свитче, насы загружались и после 10 минут старта включались эти самые жирные ветки, авторизация проходила успешно, в ребут ничего не шло. В момент падения/старта 2 наса на другом железе пик PADI в 5200-5500 держат нормально, а 4 других уходят в ребут, и при старте явно что-то их долбит что они в циклический ребут идут. Получается что после выжидания времени после загрузки и включения жирных веток на проблеммные насы летит около 5550-6000 PADI и они отрабатывают и не ложатся. Вообщем как будет лог скину

Share this post


Link to post
Share on other sites
9 минут назад, inspire_871 сказал:

Accel. Нет возможности сейчас доступа к логам получить и скинуть сюда. Как лечилось в последние падения насов: отключение самых жирных веток на свитче, насы загружались и после 10 минут старта включались эти самые жирные ветки, авторизация проходила успешно, в ребут ничего не шло. В момент падения/старта 2 наса на другом железе пик PADI в 5200-5500 держат нормально, а 4 других уходят в ребут, и при старте явно что-то их долбит что они в циклический ребут идут. Получается что после выжидания времени после загрузки и включения жирных веток на проблеммные насы летит около 5550-6000 PADI и они отрабатывают и не ложатся. Вообщем как будет лог скину

Ассель давно обновляли, или как иFedora древний?)

  • Like 1

Share this post


Link to post
Share on other sites
В 30.04.2020 в 22:06, hex@set сказал:

или как иFedora древний?)

Вот Вы сейчас ностальгию мне навеяли! Сам когда-то с неё начинал c нормальными системами работать! 8-я версия была. 2007 год, если не ошибаюсь...

 

UPD: Нет, всё-таки 7-я и да, 2007 год...

Edited by ISK
UPD

Share this post


Link to post
Share on other sites

Решили проблему. На 4 насах было обновлено ядро когда добавили сетевые карты и объединены порты в бонд, этот момент забыли и так оно жило до проблем с электричеством на районе. Сегодня откатились к предыдущему ядру и проблема ушла, перезагружали сервера, лавинные PADI запросы в районе 7к были отбиты серверами доступа, то что прописывали в конфиге были обработаны и клиент подключился удачно.

Всем спасибо, проблему решили

  • Like 1

Share this post


Link to post
Share on other sites
3 часа назад, NaviNavi сказал:

Решили проблему. На 4 насах было обновлено ядро когда добавили сетевые карты и объединены порты в бонд, этот момент забыли и так оно жило до проблем с электричеством на районе. Сегодня откатились к предыдущему ядру и проблема ушла, перезагружали сервера, лавинные PADI запросы в районе 7к были отбиты серверами доступа, то что прописывали в конфиге были обработаны и клиент подключился удачно.

Всем спасибо, проблему решили

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Xiovi
      Здравствуйте. Такая история. Есть abills 0.55b и nas mikrotik. Количество абонентов растёт, и решено поделить сеть на вланы. В микротике добавил vlan'ы, на этих вланах добавил pppoe сервера. Вланы прокинул до абонентов. Маки в вланах вижу, но пппое сессии не поднимаются. Если выключаю работающий pppoe сервер, то начинает работать один из новосозданных. В общем одновременно более 1 pppoe сервера не работает.
      Есть такая же связка в другом городе, только там стоит abills 0.54b. Там всё работает. Крутится 11 pppoe сервером и всё без проблем. 
      Кто то с таким сталкивался?
       






    • By Amourmort
      Доброго времени суток!
      Был шлюз, настроенный неизвестно когда неизвестным админом. Всё прекрасно работало, интернет людям раздавался, пока не возникла необходимость перейти на другого провайдера.

      У предыдущего провайдера IP шлюзу не выдавался, адрес и шлюз был настроен прямо в rc.conf.
      У нового провайдера PPPoE
      Штатными средствами фряхи у меня поднять соединение не получилось... Вернее, соединение поднималось только вручную, командой /etc/rc.d/ppp start - при перезагрузке соединение автоматически не стартовало.
      Решил использовать утилиту mpd5 для PPPoE. Вот содержимое mpd.conf:
      default: load pppoe_client pppoe_client: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static B1 # set iface enable nat ##NAT is configured elsewhere set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 create link static L1 pppoe set link action bundle B1 set auth authname ******** set auth password ******** set link max-redial 0 set link mtu 1492 set link keep-alive 10 60 set pppoe iface igb0 set pppoe service "" open Внёс правки в rc.conf, добавив туда запуск mpd5 и убрав интерфейс igb0. Так же, убрал строку defaultrouter - она была нужна для работы с предыдущим провайдером, с новым резолвер получает данные автоматически.
      Далее, в качестве фаервола используется PF.
      В /etc/pf.conf, к счастью, использованы переменные для конфигурации. Меняю одну переменную ext_if = "igb0" на ext_if = "ng0" и думаю, что дело сделано. Соединение при перезагрузке поднимается, доступ в интернет есть... Довольный собой уехал с объекта домой.
      Вроде бы всё хорошо.
      Но вдруг оказывается, что доступ есть далеко не к каждому сайту. Например, к укр.нет доступ есть. А к bitrix24.ua - нет.
      Пингую с сервака:
       
      ping bitrix24.ua PING bitrix24.ua (18.232.195.40): 56 data bytes ^C --- bitrix24.ua ping statistics --- 26 packets transmitted, 0 packets received, 100.0% packet loss ЧЗН? Спидтест:
       
      speedtest-cli Retrieving speedtest.net configuration... Testing from LIMANET Ltd. (141.105.132.238)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by ISP Black Sea (Одесса) [0.43 km]: 5034.671 ms Testing download speed................................................................................ Download: 0.00 Mbit/s Testing upload speed................................................................................................ Upload: 0.00 Mbit/s АААААААААААААААААААА!!!! Что это???
       
      ping korinf-group.com PING korinf-group.com (91.234.33.240): 56 data bytes 64 bytes from 91.234.33.240: icmp_seq=0 ttl=58 time=13.654 ms 64 bytes from 91.234.33.240: icmp_seq=1 ttl=58 time=13.475 ms 64 bytes from 91.234.33.240: icmp_seq=2 ttl=58 time=13.332 ms 64 bytes from 91.234.33.240: icmp_seq=3 ttl=58 time=13.913 ms 64 bytes from 91.234.33.240: icmp_seq=4 ttl=58 time=14.873 ms 64 bytes from 91.234.33.240: icmp_seq=5 ttl=58 time=14.033 ms 64 bytes from 91.234.33.240: icmp_seq=6 ttl=58 time=13.743 ms ^C --- korinf-group.com ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 13.332/13.860/14.873/0.469 ms ping google.com.ua PING google.com.ua (216.58.215.67): 56 data bytes 64 bytes from 216.58.215.67: icmp_seq=0 ttl=120 time=27.686 ms 64 bytes from 216.58.215.67: icmp_seq=1 ttl=120 time=27.766 ms 64 bytes from 216.58.215.67: icmp_seq=2 ttl=120 time=27.738 ms 64 bytes from 216.58.215.67: icmp_seq=3 ttl=120 time=27.651 ms 64 bytes from 216.58.215.67: icmp_seq=4 ttl=120 time=27.603 ms 64 bytes from 216.58.215.67: icmp_seq=5 ttl=120 time=27.781 ms 64 bytes from 216.58.215.67: icmp_seq=6 ttl=120 time=27.562 ms ^C --- google.com.ua ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.562/27.684/27.781/0.077 ms Как такое может быть? Куда копать?
      При этом, если на компе юзера включить какой-нибудь "впн", с туннелем через Киев или Берлин, доступ к любым сайтам есть, как положено...
    • By Alexander 9954
      Каждые пять минут или меньше включается и выключается интернет. 
      log (1).txt

    • By slush_kiev
      нужна помощь в настройке Juniper, MX80, BRAS.
      подробности в личку.
    • By dima22
      Добрый день. Столкнулся с такой проблемой, есть олт bdcom p3616 подключаем onu picotel pu-e710 подымаем pppoe, меряем скорость и получаем резултаты не более 10 мбит, при этом что мы видим в статистике:
      Убираем pppoe, запускаем ipoe скорость 100 из 100. Подключаем onu bdcom\anyk\ngpon скорость соответствует. Кто то сталкивался с похожей ситуации ?
×