← All posts tagged net

hgw ~ # vnstat -l -i enp3s0
Monitoring enp3s0...    (press CTRL-C to stop)

   rx:      348 kbit/s   574 p/s          tx:     7.96 Mbit/s   859 p/s^C


 enp3s0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                    39.82 GiB  |       10.52 GiB
--------------------------------------+------------------
          max          223.86 Mbit/s  |    98.76 Mbit/s
      average           34.51 Mbit/s  |     9.12 Mbit/s
          min              28 kbit/s  |        4 kbit/s
--------------------------------------+------------------
  packets                   35386967  |        24488839
--------------------------------------+------------------
          max              20477 p/s  |       16750 p/s
      average               3656 p/s  |        2530 p/s
          min                 34 p/s  |           8 p/s
--------------------------------------+------------------
  time                161.32 minutes

1 есть глюки с маршрутами, 192.168.0.0/16 via gw_public_ip dev ens7 c метрикой 0, но эпизодически траф улетает на дефолтроут (метрика 250), как только включаешь сниф (promiscuous) все "внезапно" начинает работать, локально же шлюз доступен
2 IP gw_public_ip > local_public_ip: ICMP host 192.168.0.89 unreachable, length 149 — такого довольно много, при том что проблем с доступностью нет
3 вообще на бордер сыпется море дерьма + эпизодически рвутся активные соединения
in:ether1-gateway out:(none), src-mac fc:fb:fb:c5:40:1b, proto TCP (ACK,PSH), 217.20.147.94:443->local_public_ip2:53165, len 77
(тут походу с pbr грабля, local_public_ip2 не принадлежит этому интерфейсу , а вообще на портскан похоже)
firewall,info forward: in:bridge-local out:ether1-gateway, src-mac 00:24:54:d7:39:ef, proto TCP (ACK,FIN), 192.168.3.220:58430->80.68.246.245:80, len 40
(опоздавший пакет?, проблемы с nat или вебсервером?,кривой браузер?)

Итак, возвращаясь к исходному вопросу — можно ли уменьшить количество слоев коммутаторов — выносим вердикт, что технически это возможно. Причем, главным плюсом такого объединения, на мой взгляд, является централизованное управление. Когда есть разграничение ответственности — есть порядок в работе сети, когда же ответственность размывается между сетевыми и серверными администраторами, такого порядка добиться гораздо сложнее. Кроме вопросов централизованного администрирования сторонники внедрения 802.1Qbg/Qbh часто говорят о том, что обработка трафика на физическом коммутаторе разгружает процессор сервера. Но, что интересно, не приводятся цифры — а насколько разгружается процессор? В то же время, оценка производительности современных vswitch (например, Open vSwitch) показывает, что они в состоянии обработать почти 10Gbps трафика, загрузив всего одно ядро процессора на 80-90% (источник — здесь). Современные же процессоры имеют на борту 4 или 8 ядер, а количество процессоров внутри сервера — два или более.

X:Немного не по теме: а кто-нибудь сравнивал производительность FreeBSD/HAST и Linux/DRBD ? Что быстрее? Особенно интересно было бы узнать результаты при использовании СУБД (Oracle и MySQL)в качестве "нагрузки".

Y:Предположу, что большой разницы не будет. Синхронная реплика в сетях tcpip ограничена по iops-ам существенно, в идельном случае ~2000-3000 IOPS-ов.

udevadm info -q all -p /sys/class/net/eth0
P: /devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0
E: DEVPATH=/devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0
E: ID_BUS=pci
E: ID_MODEL_ID=0x8168
E: ID_NET_NAME_MAC=enxc86000d9d470
E: ID_NET_NAME_PATH=enp2s0
E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_PRODUCT_FROM_DATABASE=P8P67 and other motherboards
E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd.
E: ID_VENDOR_ID=0x10ec
E: IFINDEX=2
E: INTERFACE=eth0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: USEC_INITIALIZED=163650

Разные взгляды на эти и множество других вопросов породили целый ворох протоколов с общим названием Spanning Tree: STP, RSTP, PVST, PVST+, PVRST, MSTP, VSTP, наверняка есть и еще.

Читатели, всерьез изучавшие что-нибудь из вышеперечисленного, наверняка знакомы с ощущением, схожим на комбинацию сонливости и зубной боли, которое возникает в процессе изучения всех этих бесконечных состояний портов, механизмов формирования весов, алгоритмов выбора корневых коммутаторов, и прочей скукотени, уступающей в занудстве разве что учебнику анатомии. Те же, кто успешно справился с внедрением, эксплуатацией, траблшутингом и развитием сети хотя бы из полутора десятков коммутаторов, построенной на базе spanning tree, смело могут подавать в спортлото IEEE прошение о представлении себе к награде. Им дальше читать не нужно.
habrahabr.ru