Константин Хлебников разработал полезную утилиту ioping, позволяющую в стиле утилиты ping наблюдать за изменением отзывчивости системы ввода/вывода в Linux. Пример выполнения: $ ioping /home 4096 bytes from /home (ext4 /dev/sda5): request=1 time=0.4 ms 4096 bytes from /home (ext4 /dev/sda5): request=2 time=0.8 ms 4096 bytes from /home (ext4 /dev/sda5): request=3 time=0.9 ms 4096 bytes from /home (ext4 /dev/sda5): request=4 time=0.3 ms 4096 bytes from /home (ext4 /dev/sda5): request=5 time=0.2 ms --- . ioping statistics --- 5 requests completed in 4266.5 ms min/avg/max/mdev = 0.2/0.5/0.9/0.1 ms
В рамках проекта WIPmania, поддерживающего общедоступную базу привязки IP-подсетей к городам, прокси, NAT-сетям и хостингам, подготовлен комплект online-утилит, позволяющий отправлять пинги и трассировки со множества серверов (на сегодня около полусотни), территориально разнесенных по всему миру. Пинги можно выполнять одновременно со всех серверов. Для трассировок подобная возможность будет доступна несколько позже. Для организации работы сервиса используется собственная программа трассировки, которая посылает пакеты трех типов одновременно, для более полноценного анализа: TCP(порт 80), UDP, ICMP. Это наиболее практичный вариант, так как некоторые маршрутизаторы не отвечают на ICMP, а другие на UDP. Визуальное отображение дистанции показывает наглядные переходы между хопами. Также выводится AS-путь и, кроме того, можно видеть, какие маршрутизаторы медленно отвечают. Например, так выглядит пинг до новых DNS-серверов Google, а так трассировка до OpenNet из Сеула и Сан-Паулу. Примеры возможных использований:
"Nagios 2.0" - подробный обзор системы мониторинга Nagios 2.0 (находится в стадии бета-тестирования, текущая версия 2.0b4), приводится сравнение возможностей с Nagios 1.x и даются инструкции по установке. "An Overview of ping" - рассказ про диагностику неисправностей сети при помощи утилиты ping, обзор опций, пример perl скрипта использующего модуль Net::Ping; "Monitoring network traffic with Ruby and Pcap" - пример написания скрипта для мониторинга проходящего трафика на языке Ruby, используя библиотеку libpcap.
Пример настройки IPsec туннеля в OpenBSD. 1. setup ip address and policy (aka. SPD, flow): # cat hostname.fxp1 inet 10.0.0.10 !ipsecadm flush !ipsecadm flow -addr 10.0.0.10/32 192.168.20.1/32 -src 10.0.0.10 -dst 192.168.20.1 -proto esp -out -require !ipsecadm flow -addr 192.168.20.1/32 10.0.0.10/32 -src 10.0.0.10 -dst 192.168.20.1 -proto esp -in -require 2. enable isakmpd (-L for debug in /var/run/isakmpd.pcap): # grep isakmpd_flags rc.conf isakmpd_flags="-L" 3. setup allow-all policy file: # cat isakmpd/isakmpd.policy Authorizer: "POLICY" # chmod 600 isakmpd/isakmpd.policy 4. generate key for IKE authentication # openssl genrsa -out isakmpd/private/local.key 1024 # chmod 600 isakmpd/private/local.key 5. extract public key: # openssl rsa -out /var/tmp/my.pub -in isakmpd/private/local.key -pubout # scp /var/tmp/my.pub peer:... 6. install public key of peers: # cp /var/tmp/peer.pub isakmpd/pubkeys/ipv4/192.168.20.1 # cat isakmpd/pubkeys/ipv4/192.168.20.1 -----BEGIN PUBLIC KEY-----
В статье "Cheap IP Takeover" рассмотрена простейшая схема обеспечения отказоустойчивости двух работающих параллельно серверов, балансировка трафика для которых осуществляется по схеме round- robin DNS (когда несколько IP прописываются для одного хоста). Проверка достижимости осуществляется через периодическое выполнение ping и посылки arp запроса, если обнаружено падение соседнего сервера, то на текущем сервере просто поднимается новый сетевой интерфейс с IP упавшего сервера. Подобная схема работает лишь при размещении серверов в одной локальной сети, если сервера расположены в разных точках - то простой подменой IP не обойтись, а главное можно определить лишь наличие сетевой достижимости между точкой мониторинга и серверами, что очень слабо оценивает реальную способность серверов в настоящий момент обслуживать клиентов (например, оба сервера активны и обслуживают клиентов, но прямая достижимость между ними нарушена).
В статье "Queuing, Traffic Shaping, and Policing" описаны методы ограничения (зажимания) трафика и выделения более приоритетного трафика на сетевых интерфейсах маршрутизатора Cisco. fair-queue, priority-group, custom-queue-list, traffic-shape и rate-limit. Описаны отличия технологий - FIFO, WFQ, RED, WRED, Предотвращаем монополизацию канала сессиями с большим трафиком в ущерб мелких "трафикогенераторов" (WFQ вместо FIFO). ! interface Serial0 fair-queue ! RED/WRED (Random early detect) - спасает ситуацию за счет дропанья пакетов в очереди. ! interface Ethernet0 random-detect hold-queue 200 out ! Принудительное определение более приоритетного трафика (в примере уменьшаем приоритет ftp). ! interface Serial0 priority-group 1 ! priority-list 1 protocol ip medium udp domain priority-list 1 protocol ip low tcp ftp priority-list 1 protocol ip low tcp ftp-data ! Ограничиваем вес определенных видов трафика в очереди (75% - WWW, 5% - DNS, и 20% все остальное) ! interface Serial0 custom-queue-list 1 !
В статье "To RAID or NOT to RAID" приводятся результаты тестирование интегрированных в материнские платы RAID контроллеров, разбираются преимущества и недостатки различных RAID уровней (0,1,5,10), даются советы в каких ситуациях RAID желателен, а в каких бесполезен. Уровни: RAID 0 (striping) 4 x 60GB = 240GB плюс: повышение производительности; минус: без резервирования низкая надежность хранения данных; RAID 1 (Mirroring) 2 x 60GB = 60GB с резервированием плюс: двойное резервирование (сохранение данных при потере одного накопителя). минус: нет прироста производительности, 50% полезной емкости. RAID 10 (0+1) (Striping + Mirroring) 4 x 60GB = 120GB плюс: двойное резервирование, повышение производительности. минус: минимум требуется 4 диска, 50% полезной емкости. RAID 5 (Striping + Parity) 4 x 60GB = 180GB (размер: N-1) плюс: повышение производительности на чтение, резервирование. минус: минимум требуется 3 диска