Как собрать RAID-10 на ZFS?

Самый надежный при высокой скорости работы вариант конфигурации диском на мой взгляд. Я буду собирать на Linux, но те же самые команды (за исключением имен устройств применимы и к другим ОС).

Во-первых, нужно на всех дисках, которые планируется добавить в массив создать gpt таблицу разделов, это можно сделать через parted /dev/sdX и там вбит mklabel gpt

После этого собираем первое зеркало:

zpool create data mirror /dev/sdb /dev/sdc

А вот активация страйпа будет хитрая - надо просто в этот же вольюм добавить еще несколько зеркал!

Приступаем:

zpool add data mirror /dev/sdd /dev/sde
zpool  add data mirror /dev/sdf /dev/sdh
zpool  add data mirror /dev/sdg /dev/sdi

Вуаля, у нас создался RAID10 из 8 дисков, то есть stripe по 4м зеркалам:

zpool status
  pool: data
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    data        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
      mirror-1  ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0
      mirror-2  ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
      mirror-3  ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdi     ONLINE       0     0     0

Размером в 11Тб:

df -h /data
Filesystem      Size  Used Avail Use% Mounted on
data             11T  128K   11T   1% /data

На этом все :)

PF_RING ZC vs PF_RING non zc

Update: тесты были проведены из рук вон плохо, не ориентируйтесь на них ВООБЩЕ. Скоро выполню повторно. 

В процессе разработки и тестирования FastNetMon столкнулся с тем, что довольно мало информации о явном преимуществе в скорости выше указанного режима zero copy.

Итак, я провел немного тестов на нагрузке в районе 350 kpps ~2Gbps на i7 2600.

Non zero copy режим, multichannel  опрос сетевой в 8 потоках:

Активирован PF_RING zero copy mode:

Как можно видеть, прирост скорости просто огромный. Причем, что приятно, вовсе не потребовалось изменять интерфейсы приложения написанного под режим one-copy, чтобы заработал ZC режим. Дабы никого не смущать - всплеск на ядре - это моя работа (моего приложения) :)

UPDATE:
Самое смешное, что это оказался не ZC режим, а похоже чудесная конфигурация сетевой скриптом load_driver.sh из папки с патченным ixgbe драйвером.

Как отлажить фильтры шейпера tc в Linux и не сойти с ума?

Ваш покорный слуга занимается этим уже долгие недели и решил, что хватит это терпеть!

Если Вы работали с фильтрами tc, то, уверен, вспоминаете это время с дрожью и ненавистью.

Почему?

Ну, например, потому, что обычный фильтр (tc -s filter show dev bond0) выглядит так:

filter parent 1: protocol ip pref 10 u32 fh b:37:800 order 2048 key ht b bkt 37 flowid 1:3c  (rule hit 11 success 0)
  match 9ffd1737/ffffffff at 12 (success 0 )

Да, Вы правильно подумали, 9ffd1737 - это IP адрес, который используется в фильтре. Как же его привести в вид IP адреса из этого шестнадцатеричного бреда?

Итак, скрипт спаситель: https://gist.github.com/pavel-odintsov/8bcddca3673f97d18b8f

Он работает как фильтр и запускать его так:

tc -s filter show dev bond0| perl convert_hex_ip_to_human_ip.pl

В итоге указанный Выше участок примет вид:

filter parent 1: protocol ip pref 10 u32 fh 800::80a order 2058 key ht 800 bkt 0 link b:  (rule hit 269307 success 0)
  match 159.253.23.0/255.255.255.0 at 12 (success 32668 )
    hash mask 0.0.0.255 at 16

Пожалуйста :)

Отличный гайд по настройке tc filter на базе хэшей

http://brownian.org.ua/?page_id=6&langswitch_lang=en

Очень требуется помощь спеца по Linux шейперу - tc, htb

Буду очень благодарен за помощь вот в такой проблемине:  http://forum.nag.ru/forum/index.php?showtopic=98376

Если есть идеи, можно либо на Nag.ru либо в комментариях :)

PF_RING and Transparent Mode

PF_RING has been designed for enhancing packet capture performance. This means that the RX path must be accelerated, and in particular a way to accelerate this is by reducing the journey of the packet from the adapter to userland. This is obtained by allowing the driver to push the packet from the NIC to PF_RING directly and not through the usual kernel path. For this reason PF_RING has introduced an option named “transparent mode” whose goal is to tune how packets are moved from the NIC to PF_RING. This option (that can be specified when inserting the PF_RING module via insmod) can have three values:

1. insmod pf_ring.ko transparent_mode=0
   This is the default and it means that packets are sent to PF_RING via the standard kernel mechanisms. In this setup the packets are both sent to PF_RING but to all other kernel components. All NIC drivers support this mode.
2. insmod pf_ring.ko transparent_mode=1
   In this mode, packets are sent directly by the NIC driver to PF_RING, packets are still propagated to other kernel components. In this mode packet capture is accelerated because packets are copied by the NIC driver without passing through the usual kernel path. Please note that in order to enable this mode, you must use a NIC driver that supports PF_RING. Available PF_RING-enabled drivers can be found in the drivers/ directory of PF_RING.
3. insmod pf_ring.ko transparent_mode=2
   In this mode, packets are sent directly by the NIC driver to PF_RING, packets are not propagated to other kernel components as this slows down packet capture. Please note that:
   • in order to enable this mode, you must use a NIC driver that supports PF_RING.
   • Packets are not sent to the kernel after they have been delivered to PF_RING. This means that you won’t have connectivity from NICs driven by PF_RING-aware drivers.
   • This mode is the fastest one as packets are quickly copied to PF_RING and immediately discarded after they have been processed.
   Копипаста из: http://www.ntop.org/pf_ring/pf_ring-and-transparent-mode/ А-то постоянно теряю хелп :)

Защита от DDoS атак с помощью FastNetMon

В наши дни почти у любой компании вне зависимости от сферы деятельности очень часто встает вопрос - как защититься от DDoS атак?

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

Стоимость оборудования для защиты от атак начинается с 1 миллиона рублей за 1Gbps (а такие атаки уже подбираются к категории "самые слабые", с которых все только начинается), услуги по защите стоят решительно дешевле, расценки начинаются от 10 000 рублей до 50 тысяч и более в особо сложных случаях.

Как же быть компании, которая не готова к таким тратам? Разумеется, ответ есть! Продолжение можно прочесть на LinkedIn: вот ссылка

Крутое сравнение скорости и эффективности архиваторов

http://vbtechsupport.com/1614/

Обнаружил совершенно потрясающую книгу: Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices

Люто рекомендую всем к прочтению: http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9780120884773

Парсинг бинарных UDP DNS сообщений на Go lang

Эту таску легко решить с помощью совершенно волшебного модуля от miekg (на нем работает DNS в CloufFlare, да).

Стягиваем модуль:

go get github.com/miekg/dns 

 Подключаем:

import "github.com/miekg/dns"

А вот простенький пример кода, который извлекает имя домена из пакета:

var msg dns.Msg
err = msg.Unpack(binary_date_payload)

if err != nil { // Send a FormatError back
//fmt.Println("Can't parse!", err)
continue
}

domain_name := strings.ToLower(msg.Question[0].Name)
fmt.Println(domain_name)

Лучшая на Планете замена grep - ack!

Друзья, это пожалуй лучшая тулза изобретенная со времен динозавров :) Не знаю как вы, но я каждый день по полсотни раз использую grep -HiR 'pattern' * для поиска текста в конфигах/коде, это занимает очень много времени и очень неудобно.

Но решение есть - установите ack, что в Дебияне, что в Центосе оно есть!

Прошу:

ack 'Downloaded signature is too small'
fileserver/ovz/CodeLib.pm
346:        CodeLib::debug_print("error", "Downloaded signature is too small  and we can't use it! Please check backup server!");

 За рекомендацию спасибо Alexander Fenster :)

Как добавить море полезных функций в Puppet?

Вот так:

puppet module install puppetlabs-stdlib

Подробно о полезных функциях:  https://forge.puppetlabs.com/puppetlabs/stdlib

А на клиенты эта библиотека притянется автоматически при синхронизации :)

Как понять в каком месте завис Perl скрипт?

Берем вот этот скрипт: https://raw.githubusercontent.com/ahiguti/gdbperl/master/gdbperl.pl

Стягиваем gdb: yum install -y gdb

Получаем нечто вот такое:

perl gdbperl.pl 755934
command:
gdb -silent -nw /usr/bin/perl 755934

environ:
SHELL=/bin/sh
MAILTO=root
USER=root
PATH=/usr/bin:/bin
PWD=/root
SHLVL=1
HOME=/root
LOGNAME=root
_=/usr/bin/fastvz_backup.pl

c_backtrace:
#0  0x0000003f7540da70 in __read_nocancel () from /lib64/libpthread.so.0
#1  0x0000003f774f0990 in PerlIOUnix_read () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#2  0x0000003f774f5055 in PerlIOBuf_fill () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#3  0x0000003f774ef848 in Perl_PerlIO_fill () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#4  0x0000003f774f4cbf in PerlIOBase_read () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#5  0x0000003f774f4dfb in PerlIO_getc () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0000003f774a29b0 in Perl_sv_gets () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0000003f7748dbd3 in Perl_do_readline () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x0000003f7748a37e in Perl_runops_standard () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x0000003f774380ba in perl_run () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x00000000004017bc in main ()

perl_backtrace:
[5] Tool::get_backups_list("7xxxxx", "xxx", "7549") <- /usr/local/lib/perl/FastBackup.pm:253(FastBackup)
[4] Tool::get_last_full_backup_info("xxxx", "xxxx", "7549") <- /usr/bin/fastssad.pl:268(main)
[3] (other) <- /usr/bin/faxxx.pl:266(main)
[2] (loop) <- /usr/bin/fasxxxxx.pl:224(main)
[1] main::function() <- /usr/bin/faxxxx.pl:156(main)

Источник: http://www.slideshare.net/hirose31/inspect-runningperl

Странные проблемы rsync при работе с флагом -z

Итак, есть 16 Гб крупным бинарным файлом.

Пробуем перелить его силами rsync без флага -z:

time rsync -a --progress /vz/private/1210 root@technode4.fv.ee:/tmp/1210

Потребление процессора разумное (32%):

395053 root      20   0  106m 1500  988 R 32.3  0.0   0:06.84 rsync                                                         

Итоги:

sent 16906158370 bytes  received 96 bytes  103 401 580.83 bytes/sec
total size is 16904094532  speedup is 1.00
real 2m42.437s
user 1m23.115s
sys 0m38.441s

Пробуем перелить с флагом -z:

time rsync -az --progress /vz/private/1210 root@technode4.fv.ee:/tmp/1210

Сразу в процессе видно, что скорость падает с 100 мегабайт/секунду до 20, а rsync начинает висеть вот в таком мерзком виде в top (да, да, он целиком выедает ядро процессора): 

391791 root      20   0  106m 1812 1020 R 99.7  0.0   0:54.36 rsync   

В итоге пришлось прервать процесс, так как он не завершился бы в разумные сроки - половина скопировалось лишь за 5 минут и скорость упала до 5 мегабайт/секунду:

real 5m54.894s
user 4m24.249s
sys 0m20.234s

В итоге данные в лучшем случае перелились бы за 10-20 минут, что уже в 4-5 раз хуже, чем вариант без использования сжатия.

Почеум так? Сжатие силами протокола gzip довольно требовательно к процессору и очень быстро упирается в производительность одного ядра, которая даже на топовых процессорах очень слабая.

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

Утилита для монтирования OpenVZ ploop дисков на любой машине с Linux

Предлагаю к Вашему вниманию очередную разработку нашей компании: ploop userspace. Это утилита для монтирования дисков в формате ploop, которые используются системой виртуализации OpenVZ.

Поддерживаются оба формата хранения - v1 и v2. Поддержка записи не планируется в виду высокой сложности задачи.

Прошу: GitHub