Jump to content
Калькуляторы

z1boris

Пользователи
  • Posts

    42
  • Joined

  • Last visited

About z1boris

  • Rank
    Абитуриент
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. У меня дома с 2012 года 1043 стоит на openwrt, ни разу не завис. У большинства абонентов тоже куча разных tp-link, никаких жалоб. Если и дохнут, то только после грозы, но это очень редко случается.
  2. Б/У сервер с Linux за 50к справится с вашей задачей...
  3. А на CRS326-24S+2Q+RM будет работать в режиме Bridge Hardware Offloading?
  4. Если и пробовать, то только на свитче, который в данный момент не используется. Я изначально тестил на более дешёвом свитче DGS-1210-28X/ME, а потом перешёл на DGS-3000-28XS, который лежал на складе как резервный. Можно не рисковать и поставить на выход из ИБП DC-DC 12V стабилизатор напряжения. Он из 13.7В сделает 12В. Но есть свои минусы: дополнительные затраты, сильно греется и неизвестно на сколько уменьшится время автономной работы свитча. Через месяц закупим новую партию ИБП, попробую потестить с DC-DC стабилизатором.
  5. SC-120-12 не стал использовать. На данный момент в сети стоит пять штук PSU-5121 12V 5А, которые выдают 13.7В. Пока всё нормально, ничего не сгорело. Аккумуляторы использую 20Ач. При полностью забитом sfp-шками свитче заряда хватает на 6 часов. Делал тесты с 1 sfp-модулем, заряда хватает на 17 часов.
  6. 500 гб по гигабиту будут передаваться 1 час и 8 минут. Ради 2х - 3х сэкономленных часов в месяц стоит столько переплачивать? Я понимаю, что фирмы бывают разные, кто-то может спокойно выделить лишние деньги на такие хотелки. Но автор пишет, что у него ИП, отсюда вывод - чем дешевле, тем лучше. И всё же автор не сказал зачем ему 10G. Может он построит 10G сеть, но упрётся в скорость HDD/SSD. И, наверно, автору стоит учесть, сможет ли он оперативно заменить 10G свитч в случае поломки. Даже если это гарантийный случай, то неизвестно сколько времени свитч будет в сервисе. А если не гарантийный, то автору надо искать $ на покупку ещё одного такого свитча. А если денег нет, то придётся переходить на 1G. И тут снова проблема. Если 10G сеть была построена по оптике, то нужно покупать SFP свитч с новыми SFP модулями. Либо покупать медный свитч и оперативно кидать всем витую пару.
  7. Такое ощущение, что автор строит сеть по принципу чем быстрее, тем круче. А по факту в этой локалке будет бегать максимум 100 мбит/сек и то редко...
  8. RX-Power (mW) 0.0004 Это очень низкий сигнал. Дело тут не в SFP и не в прошивке, дело явно в волокне. Вы это уже сами поняли по рефлектограмме. Ещё ни разу не встречали модули, которые бы неверно показывали уровень входящего и исходящего сигнала. Мы считаем линк проблемным, если сигнал ниже 0.01 mW. У нас даже на 80км линках сигнал не ниже 0.01 mW. А на коротких линках сигнал может доходить до 0.4 mW.
  9. Про IO кластеры ничего не знаю, почитаю литературу, попробую разобраться. Пока что проблема решилась выставлением профиля tuned-adm profile_info network-latency. native_queued_spin_lock_slowpath теперь показывает 0%, пинг упал до 0.3 мс. При этом нагрузка на CPU выросла до 10-15%. До этого стоял профиль balanced. Раньше ничего про tuned не знал. И пока не понимаю что он оптимизирует...
  10. Экспериментирую с трафиком на стареньком Dell сервере. Характеристики: 4 камня X7560 8 x 2.27, 2 x intel x520, centos 7 (kernel 3.10.0) На сервере настроено только несколько vlan`ов и несколько маршрутов. eth0 - первый порт первой сетевой (внешка) eth3 - первый порт второй сетевой (локалка) Схема: внешка <---> eth0 <---> server <---> eth3 <---> client1 (vlan10), client2 (vlan20), client3 (vlan30) Ограничиваю на eth0 и eth3 количество очередей до количества ядер процессоров (до 8) Привязываю очереди eth0 к numa 1. Привязываю очереди eth3 к numa 2. Тест 1: На client1 качаю файл с внешки со скоростью ~ 2 гбит/сек Нагрузка на процессор 0% native_queued_spin_lock_slowpath растёт до 60% Одновременно запускаю пинг между client2 и client3 = ~ 1-2 мс Привязываю очереди eth0 и eth3 к numa 1 Тест 2: На client1 качаю файл с внешки со скоростью ~ 2 гбит/сек Нагрузка на процессор 0% native_queued_spin_lock_slowpath около 5% Пинг между client2 и client3 = 0.3 мс Почему, когда привязываю очереди разных физическиих сетевых к разным numa, сильно растёт native_queued_spin_lock_slowpath и увеличивается пинг? Читал на хабре статью "Тюнинг сетевого стека Linux для ленивых", где пишут: "Отдельные NUMA-ноды не будут полезны, если трафик приходит в порты одной сетевой карты". В моём случае трафик приходит в порты разных сетевых. Но при этом наоборот наблюдается ухудшение. numactl --hardware: available: 4 nodes (0-3) node 0 cpus: 0 4 8 12 16 20 24 28 node 0 size: 7816 MB node 0 free: 4543 MB node 1 cpus: 1 5 9 13 17 21 25 29 node 1 size: 8046 MB node 1 free: 7554 MB node 2 cpus: 2 6 10 14 18 22 26 30 node 2 size: 8062 MB node 2 free: 7757 MB node 3 cpus: 3 7 11 15 19 23 27 31 node 3 size: 8062 MB node 3 free: 7890 MB node distances: node 0 1 2 3 0: 10 20 20 20 1: 20 10 20 20 2: 20 20 10 20 3: 20 20 20 10 ethtool -g: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 ethtool -l: RX: 0 TX: 0 Other: 1 Combined: 8 ethtool -c: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 0 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 256 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0
  11. Всем привет. Ищу 10G коммутатор в ядро сети для объединения районных узлов. В магазине НАГа вижу много разных б./у. Cisco Nexus по очень привлекательной цене. За ~ 1500$ можно взять 48 x 10G портов. В них есть весь функционал что мне нужен. Вопрос в китайских 10G модулях, будут ли они в нём работать?
  12. Всем привет. Есть два аплинка, от каждого приходит full view. Есть 30 подсетей с префиксами /24. Все подсети анонсируются обоим аплинкам. Есть провайдер, который у нас берёт транзит. У него одна подсеть с /24 префиксом. Эта подсеть тоже анонсируется обоим нашим аплинкам. Стоит задача отдать один аплинк провайдеру, который у нас берёт транзит. При этом в случае падения одного из аплинков, весь трафик должен пойти через другой аплинк. То есть нельзя анонсировать наши подсети одному аплинку, а /24 подсеть провайдера, который у нас берёт транзит, другому аплинку. В таком случае при падении одного из каналов кто-то останется без интернета. Ещё есть второй вопрос. Возможно ли добавить препенды только нам, не добавляя их провайдеру, который у нас берёт транзит? Сейчас реализовано так: ! Uplink1 neighbor ... neighbor 100.100.100.1 route-map uplink1-out out ! Наши подсети access-list uplink1-out permit 1.2.0.0/24 access-list uplink1-out permit 1.2.1.0/24 ... access-list uplink1-out permit 1.2.30.0/24 ! Подсеть провайдера, который берёт транзит access-list uplink1-out permit 2.3.4.0/24 ! route-map uplink1-out permit 10 match ip address prefix-list pref-all set as-path prepend 12345