Category: компьютеры

chuck

FreeBSD Repos & SVN

CVS умер, да здравствует SVN - в контексте проекта FreeBSD. Эта заметка полезна только тем, кого по каким-то причинам не устраивает чисто бинарное обновление базовой системы и/или обновление дерева портов через portsnap. Collapse )

chuck

Среднее время наработки на отказ

В продолжение темы.

В сети довольно сильно растиражирована фраза о мейнфреймах: "среднее время наработки на отказ оценивается в 12-15 лет". У нас мейнфреймов нет, да и работавшая ещё в 2008-м система c FreeBSD 4.11/hylafax на 12-летнем (на тот момент) Quantum Fireball 640A и Intel Champion Low Profile/486 уже больше двух лет как отключена, но кое-что есть и сейчас.

Одна из работающих систем FreeBSD 4.11-STABLE, установленная в иногороднем филиале конторы в апреле 2004 года. Можно отметить, что уже тогда это был старый компьютер:

  • материнская плата ASUS TUSL2 (BIOS Release Date: 10/11/2001)
  • процессор Intel Celeron 850Mhz PGA Socket 370, FSB 100Mhz
  • один модуль памяти DIMM SDRAM 128MB
  • один диск 20GB UDMA100 Barracuda ATA IV, (C)opyright 2001 SEAGATE TECHNOLOGY LLC
  • две 3Com 3c905C-TX Fast Etherlink XL неизвестного года выпуска
  • тянет:

    • роутинг: выпуск в мир локальной сети (natd+squid-2.6.18) плюс пять туннелей IPSEC плюс RIPv2 и OSPF внутри туннелей (quagga)
    • isc-dhcp31-server-3.1.ESV_1,1
    • публичные первичный DNS для одного домена и вторичный ещё для шести плюс непубличный первичный сервер для ещё одного и непубличный вторичный для ещё одного домена (bind98-9.8.1) плюс кеширующий рекурсивный сервис DNS для локальной сети
    • первичный MX и почтовый сервер (SMTP и POP3) для одного домена, почтовый сервис для локальной сети (sendmail+popper, clamav-0.97, milter-regex)
    • сервер точного времени NTP (stratum 3) для локальной сети (ntp-4.2.6p1)
    • net-snmp-5.5_4
    • ipacctd и mysql-клиент для еженощной заливки в базу центрального офиса обработанных перлом логов sendmail/squid/ipacctd на случай разбора полётов.
    • openssl-1.0.0_6, openssh-portable-5.2.p1_3,1
    • по мелочи: syslogd, cron, inetd, arpwatch, bounce.
  • last pid: 14380;  load averages:  0.08,  0.11,  0.05      up 39+13:07:23  02:53:16
    41 processes:  4 running, 37 sleeping
    CPU states:  2.7% user,  0.0% nice,  0.0% system,  2.7% interrupt, 94.6% idle
    Mem: 69M Active, 15M Inact, 29M Wired, 5116K Cache, 22M Buf, 3716K Free
    Swap: 512M Total, 153M Used, 359M Free, 29% Inuse
    
Система работает абсолютно стабильно, все ребуты связаны с длительными выключениями питания, когда UPS не выдерживает. Ещё одна система, выполняющая ровно те же функции с тем же софтом в другом городе и другом филиале той же конторы была установлена в ноябре 2005-го:

  • материнская плата Abit KT333-8235 (BIOS Release Date: Release Date: 09/23/2002)
  • процессор AMD Athlon(tm) XP 1500+ (1333Mhz) Socket A, FSB 333Mhz
  • два модуля памяти DIMM DDR: 256MB+128MB (384MB всего)
  • один диск 17.2GB UDMA66 U Series 8, (C)opyright 1999 SEAGATE TECHNOLOGY LLC плюс один диск 40GB UDMA100 Barracuda ATA IV, (C)opyright 2001 SEAGATE TECHNOLOGY LLC
  • две 3Com 3c905C-TX Fast Etherlink XL неизвестного года выпуска
  • last pid: 14144;  load averages:  0.01,  0.05,  0.06  up 0+12:34:15  03:28:56
    59 processes:  5 running, 54 sleeping
    CPU:  0.0% user,  0.0% nice,  0.6% system,  1.8% interrupt, 97.6% idle
    Mem: 191M Active, 109M Inact, 53M Wired, 21M Cache, 48M Buf, 824K Free
    Swap: 256M Total, 36K Used, 256M Free
Нагрузка на системы соответствует мощности железа. Виртуализация, говорите?
stopstupid

Dispute Mechanism

#show spanning-tree interface Gi4/13

Mst Instance        Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
MST0                Desg BLK 200000    128.781  Dispute P2p

На сайте cisco.com описан Dispute Mechanism, но причин блокирования порта этим механизмом приведено только две: однонаправленный канал или некорректно настроенный EtherChannel.

В моём случае временное включение spanning-tree bpdufilter на этом транке приводило к разблокировнию порта и трафик начинал ходить нормально, да и портканалом тут не пахло. Причина оказалась банальна - на свиче с другой стороны линка был включен RSTP. Переключение в MSTP на той стороне проблему убрало полностью, spanning-tree на этой стороне перестал блокировать порт.

chuck

Тюнинг FreeBSD 8.2. Часть 1. Стабильность.

В продолжение темы.

Итак, FreeBSD это конструктор, части которого требуют ручной доводки напильником, но результат получается хороший (см. ссылку выше). Тем, кого с души воротит от таких конструкторов, можно дальше не читать, а отправляться искать дистрибьютора Cisco, например.

Collapse )

chuck

mpd-5.5

Первый стресс-тест mpd-5.5/PPPoE под FreeBSD 8.2-STABLE/amd64 на реальной нагрузке.

Система настроена решать одну задачу - терминировать пользовательские сессии PPPoE с AAA через RADIUS, с шейпингом трафика и анонсированием абонентских IP-адресов в ядро сети через OSPF. На машине нет NAT (адреса реальные), нет netflow (собирается на другом роутере), нет BGP.

В час наибольшей нагрузки отмечено:

  • 1812 сессий PPPoE;
  • средняя нагрузка по ядрам процессора 2% user time / 88% (system time + interrupts) (CPU0: 2+90, CPU1: 2+89, CPU2: 2+90, CPU3: 3+86);
  • 1184.9Mbit/s трафика в сторону клиентов и 830.9Mbit/s от них (итого 2015.8Mbit/s);
  • 549.8Kpps: на интерфейсе lagg0 136.2Kpps in, 120.3Kpps out и на lagg1 139.0Kpps in, 154.3Kpps out;
  • до 102K прерываний в секунду (device polling не использовался);
  • использовано памяти:

    Mem: 101M Active, 41M Inact, 486M Wired, 1644K Cache, 138M Buf, 3314M Free

  • в среднем на одну PPPoE-сессию приходилось 654.1Kbit/s трафика на вход и 434.2Kbit/s на выход.

То есть, на каждый процент загрузки CPU пришлось по 20 сессий.
Система продолжала быть отзывчивой на ssh так же, как и без нагрузки.

Железо:

  • SuperMicro SuperServer 5016T-MTFB с двумя гигабитными интегрированными сетевыми Intel 82574L (драйвер em) и платой IPMI 2.0 с выделенным портом 100M;
  • дополнительная двухпортовая сетевая карта Intel 82576 (драйвер igb);
  • процессор Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (четыре ядра, гипертрединг отключен в BIOS Setup, 4M Cache, 4.80 GT/s Intel® QPI);
  • 4GB памяти ECC;
  • в качестве загрузочного носителя SSD 64GB (KINGSTON SNV425S264GB), при загрузке монтируется только для чтения (система собрана в виде NanoBSD, без свопа).

Общая стоимость железа около 60 тысяч рублей (всё железо новое).

Сетевые em0 и em1 объединены в lagg0, на нём есть IP-адрес и нет vlan-ов, это аплинк. Сетевые igb0 и igb1 объединены в lagg1, на котором нет IP, зато создано 596 vlan-ов, каждый из которых несет PPPoE-трафик пользователей. Шейпинг выполнен через ipfw/dummynet - на каждого подключенного пользователя dummynet динамически (pipe ... mask) создает по две индивидуальных трубы, на вход и на выход, в соответствии с тарифом пользователя. Весь шейпинг делается двумя правилами ipfw, список правил не растет при росте количества абонентов:

pipe tablearg ip from any to table(11) in
pipe tablearg ip from table(12) to any in


Для сравнения: бывшая в употреблении Cisco 7201 на usedcisco.ru стоит $11400 $10900 (примерно в 5.5 раз дороже), срок поставки 3 недели. На этой же задаче и на этих же пользователях обрабатывает около 10 сессий на процент загрузки CPU (то есть, вдвое меньше), причем при высоких загрузках вносит большие задержки и сама с трудом управляется по telnet. Поэтому приходится ограничивать количество сессий на ней (не более 700), чтобы держать нагрузку в пределах 75%. Стоит отметить, что при маленьких нагрузках (ближе к нулю) количество сессий на процент загрузки CPU у обоих систем растет в разы.

Зато Cisco - продукт, и умеет гораздо больше, например, ISG. А FreeBSD - конструктор, и требует существенного тюнинга. Про тюнинг как-нибудь в другой раз.

Update: для проверки провёл второй тест на FreeBSD с целью удержать загрузку в пределах 75%. При прочих равных условиях для этого оказалось нужным ограничить количество сессий PPPoE в 1500. Подтверждается прямая пропорциональность: 1800/0.9=1500/0.75=2000, что даёт нам прогноз стопроцентной загрузки при 2000 сессиях.

На деле у меня пока достаточно железок, чтобы держать нагрузку в пике на уровне 35% :-)