четверг, 26 ноября 2015 г.

How to scale graphite up to X times and reduce cpu consumption twice?

So much customers who are working with Graphite could highlight two significant issues with Graphite:
1) It's coded with Python which pretty slow
2) It's bundled to single CPU core and need clustering for using all cores

I have hit first issue. I'm using Graphite with FastNetMon for awesome visual reports and I'm storing about 40 000 records per second.

So carbon daemon eat so much cpu:
top - 13:58:37 up 128 days, 19:32,  1 user,  load average: 3.88, 3.80, 3.76
Tasks: 150 total,   1 running, 149 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  8.8 sy,  0.0 ni, 66.2 id, 11.6 wa,  0.1 hi,  0.8 si,  0.0 st
KiB Mem:  32933416 total, 31923200 used,  1010216 free,   697700 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26169476 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAN  
20598 root      20   0 5343724 619232 543572 S 179.0  1.9  80770:18 fastnetmon            
22981 _graphi+  20   0  250300 128484   4756 S  21.3  0.4   0:06.81 carbon-cache          
So We could hit limit with about 200 000 records per second and it's not so fine.

I have found awesome product Go-Carbon. It's drop-in replacement for carbon daemon and it's implemented in Golang (very fast and reliable!).

So I have replaced my existing carbon with go-carbon this way. I'm using Debian 8 and all guide will be about it.

Install it:
wget https://github.com/lomik/go-carbon/releases/download/v0.6/go-carbon_0.6_amd64.deb
dpkg -i go-carbon_0.6_amd64.deb
Then we need to change path to original graphite data files (it's completely back compatible but please keep backup):

Then open file /etc/go-carbon/go-carbon.conf

And change following options:
schemas-file = "/etc/carbon/storage-schemas.conf"
data-dir = "/var/lib/graphite/whisper/"
user = "_graphite"
max-updates-per-second = 500 (because it's standard configuration for graphite: MAX_UPDATES_PER_SECOND = 500)

Then switch off python carbon and start go-carbon:
 /etc/init.d/carbon-cache stop
/etc/init.d/go-carbon start
So you still can use graphite web for reading data! And feed data with pickle of text protocol.  It's completely back compatible.

And it's lightning fast:
top - 13:57:44 up 128 days, 19:32,  1 user,  load average: 3.85, 3.78, 3.75
Tasks: 149 total,   1 running, 148 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.6 us, 12.5 sy,  0.0 ni, 62.0 id, 10.7 wa,  0.1 hi,  1.0 si,  0.0 st
KiB Mem:  32933416 total, 31888556 used,  1044860 free,   697680 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26161116 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
20598 root      20   0 5343724 619232 543572 S 208.1  1.9  80768:40 fastnetmon  
21882 _graphi+  20   0  446480 102512   8028 S  10.7  0.3   6:59.83 go-carbon   
As you can see we got two times CPU usage reduction!  But you could use workers = X and max-cpu = X option for scaling go-carbon over all available cores!

We have awesome picture from author:


четверг, 12 ноября 2015 г.

Эффективность работы антивирусов на платформе Linux

В течение последних 2-3 недель (с конца апреля до 8го мая 2014) с помощью Antidoto и в процессе его отладки мною было обнаружено большое число зловредного ПО на различных Linux машинах. Оно по-разному пробиралось на серверы, но было обнаружено и удалено с машин с исправлением исходных причин заражения. В процессе этого было изъято большое число исполняемых файлов, которые были тщательным образом проанализированы в запущенном виде и после этого нейтрализованы. Наиболее интересные экземпляры исследованы здесь.После изъятия все файлы были проверены ведущими антивирусами и результаты проверок приведены ниже.

  • apache2_rootkit_from_srv_277274 ced2ebfccfe2d52f362908020acd5831 0/51
  • apache_rootkit_from_srv_277274 614ad37e6755ef7443addd2df27256c2 0/51
  • atd_virus_ovz17 36f6c1169433cc8a78498d54393132ed 1/51 только Kaspersky, после репорта
  • fake_sshd_mc e3305c8ae035d81d75cf0d4ea2ba1131 0/52
  • irc_bouncer_hidden_as_ssh_from_5560 d7cb8d530dd813f34bdcf1b6c485589b 1/52только Avast, ELF:PsyBNC-A [PUP]
  • jawa 36c97cdd3caccbacb37708e84b22a627 0/52
  • libworker.so a6765b7ab914e042a6f8e1adb59c08b9 2/52 Kaspersky Avast
  • pine_virus_from_2441 88cc70e9f07654d5afc392bf4e135d87 0/52
  • ps_virus_ct_6205 21f9a5ee8af73d2156333a654130f3f8 1/49 Kaspersky, после нашего репорта.
  • sfewfesfs f9ad37bc11a4f5249b660cacadd14ad3 3/52 Avast, Gdata, Qihoo-360
  • sfewfesfsh 9b6283e656f276c15f14b5f2532d24d2 5/52 DrWeb, Kaspersky, Qihoo-360, TrendMicro-HouseCall, ViRobot
  • sshd_32_bit_fake_from_2453 0c0dc04b427e8e2bf90fcc4e6dc6cbc9 0/52
  • virus_from_43165 a6752df85f35e6adcfa724eb5e15f6d0 1/52 Только Kaspersky, после нашего репорта
  • named_bitcoin_virus 99ca61919f5afbdb3c0e07c30fad5bb1 9/52 Avast, Bkav, DrWeb, ESET-NOD32, Fortinet, Kaspersky, TrendMicro, TrendMicro-HouseCall, VBA32
Все вирусы были отправлены на Virustotal и могут быть найдены по хэшам (в том числе сотрудниками AV компаний), все вирусы были перданы в компанию ClamAv, часть вирусов была передана в компанию Kaspersky.

Итого, 14 типов подтвержденно зловредного ПО:

    • 6 из них не определяются никаким антивирусным ПО
    • 3 определяются антивирусом Касперского только после получения багрепорта от нас
    • 1 определяется только антивирусом Avast
    • 4 типа зловредного ПО определяются более чем одним антивирусом.
    Победителей я бы распределил так:
    • Avast (безоговорочная победа)
    • Kaspersky (более-менее, наши посылки не учиытвались в анализе)
    • DrWeb (2 вируса, мало, но лучше, чем что-то)
    Хочется обратить внимание на то, что все указанное зловредное ПО было обнаружено с помощью пакета Antidoto, которое имеет эвристические алгоритмы обнаружения каждого из них.
    Update: в данный момент все вирусы были полностью отправлены в DrWeb и Kaspersky, ClamAV. Остальным отправлять очень лениво.

    Выводы

    А они печальные - даже от базовых очень стандартных вирусов (многие из приведенных мною загружались на VirusTotal еще несколько лет назад и до сих пор никем не определяются) антивирусы не предоставляют НИКАКОЙ ЗАЩИТЫ вообще.
    Что же делать? Иметь очень хорошего системного администратора и использовать проверенные диагностические утилиты - netstat, ss, lsof и другие в дополнение к тулкиту Antidoto :)

    Источник, моя же публикация

    четверг, 8 октября 2015 г.

    Реалии использования динамических библиотек скомпилированных силами Go из С/С++

    Всем известно, что начиная с версии 1.5 Golang научился делать бинарные динамические .so библиотеки (go build -buildmode=c-shared -o libgobgp.so *.go), которые можно прилинковать к православному C коду.

    Но если копнуть дальше, на деле это не совсем .so библиотека и привычного нам машинного кода там нету.

    А есть обертки, которые вызывают код из Golang и подставляют себя С функциями.

    Дада, Вы верно догадываетесь, Go's runtime запускается рядом. Не заметить это сложно - появляется 5ка тридов рядом с вашей программой Смайлик «smile»

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

    И если оно форкается или форкается и потом использует popen - горевать Вам очень долго, потому что многопоточное приложение, которым с момента запуска int main стал Ваш любимый софт из-за Go рантайма нельзя форкать, будет все крайне плохо Смайлик «smile»

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

    Как чинить? Линковаться динамически в рантайме, силами dlopen/dlsym, как сделал я - тут.

    Вот так вот друзья - не все так просто, за все нужно платить Смайлик «smile»После этого фикса все стало работать решительно приличнее, но совершенно никаких гарантий, что так будет и впредь.

    четверг, 27 августа 2015 г.

    Недостатки используемых в данный момент способов доставки приложений и библиотек

    Меня всегда удивлялся идиотическая черта пропагандируемая всеми без исключения дистрибутивами, построенными на бинарных пакетах.

    Кто эти люди, кто считает, что старый, неактуальный код полутора летней давности НАДЕЖНЕЕ того же самого кода, который был выправлен от пары-тройки критичных багов, скажем, неделю назад?

    Я изо дня в день выбиваю баги, которых нету в актуальной версии библиотеки/программы, но они есть и цветут в красе в той версии, которую сунул чудесный дистрибутиво-собиратель.

    Единственные, кто хотя бы отчасти радует в этом мире идиотизма - это Ubuntu LTS, которые нарушили все кармические запреты и обновляют ядро до разумных версий!

    Red Hat со своим чудо-ядром класса 2.6.32 на стероидах с тыщей бэкапорт патчей сверху (да пропади оно пропадом сто раз - баголовище и багокостылище) не просто задрал, а задрал - нисказанно Смайлик «smile»


    Алсо, друзья, какие выходы из этой патовой ситуации Вы видите?

    Мы уже местами упоролись в конец и собираем то-что-нам-нужно (на богобоязныенных Го и Си Плас Плас) вручную и нужных-нам-версий, используя от дистрибутива лишь базовые вещи (хотя под час там даже базовый компилятор - старье и им просто-напросто не собрать актуальный проект, скажем, на С++ 11).

    Докеры и прочее прошу не рекомендовать - я хочу решение, а не костыль и желательно без 7ми слоев виртуализаци и изоляции даже если она делается во благо мне Смайлик «smile»

    Gentoo/LFS это кому-то может быть и вариант, но не для продакшена явно. Радуют в вопросе CoreOS - но там богобоязнныенне конейнеры и нарушение многих привычных мне парадигм.

    Хочется дистибутив, который использует в меру стабильное, но актуальное ядро, имеет полный арсенал языков программирования и ключевых библиотек актуальных стабильных версий (с соотвествующим обновлением).

    Но при этом хочется возможности фиксировать библиотеки. Скажем - я опираюсь на xxx, yyy, zzz и просто не хочу получать обновления на их следующие версии, а только обновления, скажем, безопасности.

    Из готовых решений имеющих более-менее адекватных разработчиков кеомендую присмотреться к пакетному менеджеру Nix и ОС на его базе - Nix OS.

    Также вместо докера с его огромным ворохом проблем рекомендую посмотреть на CoreOS + Rocket (годная и адекватная замена Doker спроектированная инженерами, а не хипстерами).

    А что думаете Вы?

    Остерегайтесь! Криптеры файлов дошли до мира Linux серверов

    Кажется эре наплевательского отношения к безопасности в сфере хостинга наступает конец.
    Буквально несколько дней назад столкнулись с о взломами клиентских выделенных серверов и VPS, когда вместо очередного ботнет-контроллера, спам-скрипта или же флудера гостевых книг (c) (tm) появилось нечто новое.
    Это "нечто" заимев root полномочия на машине (отдельный вопрос - как, но в целом данный вектор атаки работает даже без рутания) зашифровало к чертям все от начала до конца файлы (а это - десятки гигабайт) на сервере относящиеся к сайтам (текст скриптов) и базам данных (все внутренности mysql) и услужливо разложило везде файлик info с указанием Bitconin кошелька куда класть выкуп если вдруг образовалось желание вернуть свои файлы обратно.
    Друзья, искренне рекомендую всем иметь надежный бэкап!

    пятница, 24 июля 2015 г.

    Effectiveness of ZFS usage for OpenVZ

    This article is a detailed answer to conversation about simfs vs ploop vs ZFS from OpenVZ maillist.

    Because I have finished very detailed tests of ZFS for VPS storage I would like to share they with my Dear Community. 

    Source data (real clients, real data, different OS templates, different OS templates versions, server running for ~1year, production server full copy):
    Size: 5,4T
    Used: 3,5T
    Avail: 1,7T
    Usage:69%
    This data from HWN with OpenVZ with ploop.

    Our internal toolkit fastvps_ploop_compacter show following details about this server:
    Total wasted space due to ploop bugs: 205.1 Gb
    Wasted space means difference between real data size and ploop disks size, i.e. ploop overhead.

    gzip compression on ZFS

    We have enabled ZFS gzip compression and move all data to new created ZFS volume.

    And we got following result:
    NAME          SIZE   ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT data  8,16T  3,34T  4,82T    40%  1.00x  ONLINE  -

    As you can see  we save about 160 GB of data. New ZFS size of this data is: 3340 GB, old size: 3500 GB.

    lz4 compression on ZFS

    So, ZFS developers do not recommend gzip and we will try lzr4 compression as best option.

    We copy same data to new ZFS storage with lz4 compression enabled and got following results:
    ALLOC: 2,72Tb
    Wow! Amazing! We save about 600 Gb of data!  Really!

    ZFS deduplication

    As you know, ZFS has another killer feature - deduplication! And it's best option when we store so much containers with fixed number of distributions (debian, ubuntu, centos).

    But please keep in mind, we have disabled compression on this step!

    We have enabled deduplication for new storage and copy all production data to new storage with deduplication.

    When data copy was finished we got this breath taking results:

    zpool list
    NAME         SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOTdata  8,16T  2,53T  5,62T    31%  1.33x  ONLINE  -

    We have saved 840 GB of data with deduplication! We are really close to save 1Tb!

    For very curious readers I could offer some internal data regarding ZFS dedup:
    zdb -D data
    DDT-sha256-zap-duplicate: 5100040 entries, size 581 on disk, 187 in core
    DDT-sha256-zap-unique: 27983716 entries, size 518 on disk, 167 in core
    dedup = 1.34, compress = 1.00, copies = 1.02, dedup * compress / copies = 1.31
    ZFS compression and deduplication simultaneously

    So, ZFS is amazingly flexible and we could use compression and dedulication in same time and got even more storage save. And this tests is your own home task :) Please share your results here!

    Conclusion

    That's why we have only single file system which ready for 21 century. And ext4 with derivative file systems should be avoided everywhere if possible.  

    So, will be fine if you help ZFS on Linux community with bug reporting and development! 

    вторник, 7 июля 2015 г.

    How to enable Autonomus System Lookup for tshark/wireshark?

    In article http://www.stableit.ru/2015/04/how-to-enable-geoip-support-in-tshark.html we discuss GeoIP feature. If you interested in AS numbers of client hosts, please execute this reference.

    Install GeoIP:
    apt-get install -y geoip-database
    Then download ASN database:
    wget http://geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz
    gunzip GeoIPASNum.dat.gz
    mv GeoIPASNum.dat  /usr/share/GeoIP/
    Then you should specify folder with GeoIP databases to Wireshark:
    mkdir -p ~/.wireshark
    echo '"/usr/share/GeoIP"' > ~/.wireshark/geoip_db_paths
    Let's start:

    tshark -i eth0 -n -T fields -e ip.geoip.src_asnum -o "ip.use_geoip: TRUE"
    And you will get following output:
    AS60781 LeaseWeb B.V.
    AS34757 Sibirskie Seti Ltd.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS60781 LeaseWeb B.V.
    AS200000 Hosting Ukraine LTD
    AS60781 LeaseWeb B.V.
    AS23947 PT.Mora Telematika Indonesia
    AS60781 LeaseWeb B.V.
    AS2914 NTT America, Inc.
    AS60781 LeaseWeb B.V.
    AS18881 Global Village Telecom

    воскресенье, 5 июля 2015 г.

    Селективный блэкхол

    Видимо, пошло оно от selective blackhole. На удивление недавно (на ENOG9) обнаружил, что термин частенько не понимается многими и вовсе не является обще принятым :)

    Что же он означает? Речь идет о RTBH (remote triggered black hole), который обычно висит на BGP комьюнити 666. При его активации он блокирует весь трафик с/на узел.

    Селективный же блокирует либо заданный протокол (часто - UDP) либо же набор протоколов по определенным параметрам (например, популярные UDP амплификаторы).

    Операторы, кто поддерживает это дело - редки, делимся в комментах :)

    вторник, 23 июня 2015 г.

    Настройка роутинг демона BIRD для экспорта содержимого локальной роутинг таблицы по BGP

    Все тесты будут вестись на CentOS 6 :)

    Итак, установим Bird:
    yum install -y bird

    Откроем его конфиг:
    vim /etc/bird.conf 

    И закомментируем там все, что нам не закомментировано дабы избежать конфликтов.

    После этого забиваем следующий конфиг:
    protocol kernel {
        persist;                # Don't remove routes on bird shutdown
        learn;                  # Learn all alien routes from the kernel
        export none;            # Default is export none
        import all;
        scan time 20;           # Scan kernel routing table every 20 seconds
        device routes yes;
    }

    protocol device {
        scan time 10;           # Scan interfaces every 10 seconds
    }

    filter test_filter {
        # filter out private subnets
        if net ~ 10.0.0.0/8 then reject;
        if net ~ 192.168.0.0/16 then reject;
        if net ~ 172.16.0.0/12 then reject;

        # filter link local for IPv4
        if net ~ 169.254.0.0/16  then reject;

        accept;  
    }


    protocol bgp {
        local as 65000;

        source address 10.0.131.2;
        # do not connect to remote peers, work as route server now!
        # passive;

        import all;
        export filter test_filter;
        neighbor 10.0.129.2 as 65000;
    }
    Данный конфиг приводит к тому, что будет установлена BGP сессия с заданным узлом и в нее будут проанонсированы все маршруты из локальной таблицы Linux (в моем случае это маршруты до OpenVZ VPS).

    После этого применяем изменения (в лоб, потому что тесты. В продакшене нужно делать через birdc):
    /etc/init.d/bird restart

    Убеждаемся, что BGP сессия поднялась:
    show protocols all bgp1
    name     proto    table    state  since       info
    bgp1     BGP      master   up     15:07:32    Established  
      Preference:     100
      Input filter:   ACCEPT
      Output filter:  test_filter
      Routes:         0 imported, 27 exported, 0 preferred
      Route change stats:     received   rejected   filtered    ignored   accepted
        Import updates:              0          0          0          0          0
        Import withdraws:            0          0        ---          0          0
        Export updates:             29          0          2        ---         27
        Export withdraws:            0        ---        ---        ---          0
      BGP state:          Established
        Neighbor address: 10.0.129.2
        Neighbor AS:      65000
        Neighbor ID:      10.0.129.2
        Neighbor caps:    AS4
        Session:          internal multihop AS4
        Source address:   10.0.131.2
        Hold timer:       109/180
        Keepalive timer:  2/60

    Все! :)

    Аггрегация огромных сетей

    Довольно часто приходится работать с реально огромными списками сетей. Как пример - можно взять любой IX, я возьму ближайший географически ко мне DATA-IX.

    Итак, выдернем все их сети с помощью BGPq3:
    /opt/bgpq3/bin/bgpq3 AS-DATAIX|awk '{print $5}' > /root/dataix_networks_list.dat
    Наберется очень много - 251 тыща сетей:
    wc -l /root/dataix_networks_list.dat
    251009 /root/dataix_networks_list.dat
    Посчитаем, сколько это в хостах:
    cat  /root/dataix_networks_list.dat | sed 's#/# #' |awk '{print $2}'|perl -e 'my$total=0; do{ $_ = int($_); next unless $_; $total += 2**(32-$_) } for <>; print "Total networks size: $total\nTotal Internet size: " . 2**32 . "\n"'
    Total networks size: 410 650 370
    Total Internet size: 4 294 967 296
    Согласитесь, смотрится совершенно неплохо даже на фоне размера всего адресного пространства IPv4.

    Но что если там есть дублирующиеся сети или сети вложенные друг в друга? Это реально сложно проверить и еще сложнее починить "в лоб".

    Но есть чудесная тулза - aggregate.

    Устанавливаем ее:
    apt-get install -y aggregate
    И запускаем аггрегацию:

    cat /root/dataix_networks_list.dat| aggregate > /root/dataix_networks_list_aggregated_new.dat
    Она будет потреблять приличное количество CPU ресурсов и будет работать несколько минут:
    real    2m29.608s
    user    2m29.564s
    sys    0m0.012s
    Но на выходе мы получим просто потрясающие результаты! Число сетей сократится в 10 раз:
    wc -l  /root/dataix_networks_list_aggregated_new.dat
    24628 /root/dataix_networks_list_aggregated_new.dat
    А число хостов вдвое:
    Total networks size: 232866112
    Total Internet size: 4294967296
    Это особенно актуально, когда Вы сильно стеснены в аппаратных ресурсах (число ACL на свиче, число route префиксов l3 свиче).

    Такой же способ оптимизации можно использовать и для FastNetMon, чтобы зазря не выделять память для сетей, которые вложены друг в друга :) 



    Generate BGP filters with BGPQ3

    Build it:
    cd /tmp
    wget http://snar.spb.ru/prog/bgpq3/bgpq3-0.1.31.tgz
    tar -xvzf bgpq3-0.1.31.tgz
    cd bgpq3-0.1.31/
    ./configure --prefix=/opt/bgpq3
    sudo mkdir -p /opt/bgpq3/bin
    sudo make install
    Generate filter list by ASN (actually you could use AS-SET here too):
     /opt/bgpq3/bin/bgpq3 AS24940
    no ip prefix-list NN
    ip prefix-list NN permit 5.9.0.0/16
    ip prefix-list NN permit 46.4.0.0/16
    ip prefix-list NN permit 78.46.0.0/15
    ip prefix-list NN permit 85.10.192.0/18
    ip prefix-list NN permit 88.198.0.0/16
    ip prefix-list NN permit 91.220.49.0/24
    ip prefix-list NN permit 91.233.8.0/22
    ip prefix-list NN permit 136.243.0.0/16
    ip prefix-list NN permit 138.201.0.0/16
    ip prefix-list NN permit 144.76.0.0/16
    ip prefix-list NN permit 148.251.0.0/16
    ip prefix-list NN permit 176.9.0.0/16
    ip prefix-list NN permit 176.102.168.0/21
    ip prefix-list NN permit 178.63.0.0/16
    ip prefix-list NN permit 185.12.64.0/22
    ip prefix-list NN permit 185.50.120.0/23
    ip prefix-list NN permit 188.40.0.0/16
    ip prefix-list NN permit 193.25.170.0/23
    ip prefix-list NN permit 193.28.90.0/24
    ip prefix-list NN permit 193.110.6.0/23
    ip prefix-list NN permit 193.223.77.0/24
    ip prefix-list NN permit 194.42.180.0/22
    ip prefix-list NN permit 194.42.184.0/22
    ip prefix-list NN permit 194.145.226.0/24
    ip prefix-list NN permit 195.248.224.0/24
    ip prefix-list NN permit 197.242.84.0/22
    ip prefix-list NN permit 213.133.96.0/19
    ip prefix-list NN permit 213.169.144.0/22
    ip prefix-list NN permit 213.239.192.0/18
    This toolkit supports so much options for diffrent vendors (and even json!).

    Great thanks to author, Alexander Snarski.

    Official site: here.

    В случае ошибки:
    FATAL ERROR:Partial write to radb, only 7 bytes written: Connection reset by peer
    На Linux делаем вот так:
    sysctl -w net.ipv4.tcp_window_scaling=1
    sysctl -w net.core.rmem_max=33554432
    sysctl -w net.core.wmem_max=33554432
    sysctl -w net.ipv4.tcp_rmem="4096 87380 33554432"
    sysctl -w net.ipv4.tcp_wmem="4096 65536 33554432"

    суббота, 20 июня 2015 г.

    How to run netmap on single queue and use another queues for Linux stack

    Hello, folks!

    I will do some ixgbe magic here! Please stay tuned =)

    Here I could provide short reference about netmap compilation with patched ixgbe driver.

    First of all you should get my patched driver. In this driver I have assigned first (0) queue to netmap and assigned another queues to Linux network stack.

    Get driver sources and put they to "fake" Linux kernel source tree (netmap build system expect this):
    cd /usr/src
    mkdir -p /usr/src/fake_linux_kernel_sources/drivers/net/ethernet/intel
    cd /usr/src/fake_linux_kernel_sources/drivers/net/ethernet/intel
    git clone https://github.com/pavel-odintsov/ixgbe-linux-netmap-single-queue.git ixgbe_temp
    mv ixgbe_temp/ixgbe-3.23.2.1/src/ ixgbe

    Let's get netmap:
    cd /usr/src
    git clone https://github.com/luigirizzo/netmap.git -b next
    cd netmap/LINUX/
    Do some netmap patching:
    sed -i 's/#define ixgbe_driver_name netmap_ixgbe_driver_name/\/\/\0/'  ixgbe_netmap_linux.h
    sed -i 's/^char ixgbe_driver_name\[\]/\/\/\0/'  ixgbe_netmap_linux.h
    sed -i '/$t\s\{1,\}if \[ \-f patches/d' configure
    Let's compile it:
    ./configure --kernel-sources=/usr/src/fake_linux_kernel_sources --drivers=ixgbe
    make
    Unload old ixgbe not patched driver:
    rmmod ixgbe
    Load netmap:

    insmod /usr/src/netmap/LINUX/netmap.ko
    insmod /usr/src/netmap/LINUX/ixgbe/ixgbe.ko
    Well, we have netmap which could process only first NIC hardware queue.

    We should check it. For tests I will use flow director and flow all udp packets to 53 port to first queue:
    ethtool -K eth5 ntuple on
    ethtool --config-ntuple eth5 flow-type udp4 dst-port 53 action 0
    Then we should built test environment.

    Please compule test netmap receiver:
    cd /usr/src/netmap/examples/
    make

    Yes, we are ready for tests!

    Please run linux network stack receiver app in one console session:
    tcpdump -n -i eth5

    And netmap reciver app in another console session:
    /usr/src/netmap/examples/pkt-gen -f rx -X -i netmap:eth5
    Actually, we need external machine and please start pinging of target host from it and let's send udp packet to it from another session.

    For udp packets generation you could use nc:
    echo asdasda| nc -u 10.10.10.221  53

    And you will saw:
     ./pkt-gen -f rx -i netmap:eth5 -X
    689.290532 main [1651] interface is netmap:eth5
    689.290977 extract_ip_range [288] range is 10.0.0.1:0 to 10.0.0.1:0
    689.291015 extract_ip_range [288] range is 10.1.0.1:0 to 10.1.0.1:0
    689.517212 main [1848] mapped 334980KB at 0x7fcf508ea000
    Receiving from netmap:eth5: 1 queues, 1 threads and 1 cpus.
    689.517331 main [1910] --- SPECIAL OPTIONS:

    689.517345 main [1934] Wait 2 secs for phy reset
    691.517508 main [1936] Ready...
    691.517870 nm_open [456] overriding ifname eth5 ringid 0x0 flags 0x1
    691.522007 receiver_body [1184] reading from netmap:eth5 fd 4 main_fd 3
    692.523020 main_thread [1448] 0 pps (0 pkts in 1001104 usec)
    692.525560 receiver_body [1191] waiting for initial packets, poll returns 0 0
    693.524487 main_thread [1448] 0 pps (0 pkts in 1001468 usec)
    693.528806 receiver_body [1191] waiting for initial packets, poll returns 0 0
    694.525850 main_thread [1448] 0 pps (0 pkts in 1001363 usec)
    694.532073 receiver_body [1191] waiting for initial packets, poll returns 0 0
    695.526988 main_thread [1448] 0 pps (0 pkts in 1001137 usec)
    695.535358 receiver_body [1191] waiting for initial packets, poll returns 0 0
    696.528438 main_thread [1448] 0 pps (0 pkts in 1001450 usec)
    696.538669 receiver_body [1191] waiting for initial packets, poll returns 0 0
    697.529608 main_thread [1448] 0 pps (0 pkts in 1001170 usec)
    697.542189 receiver_body [1191] waiting for initial packets, poll returns 0 0
    698.530749 main_thread [1448] 0 pps (0 pkts in 1001141 usec)
    698.545628 receiver_body [1191] waiting for initial packets, poll returns 0 0
    699.531875 main_thread [1448] 0 pps (0 pkts in 1001126 usec)
    699.549208 receiver_body [1191] waiting for initial packets, poll returns 0 0
    700.532999 main_thread [1448] 0 pps (0 pkts in 1001124 usec)
    700.552431 receiver_body [1191] waiting for initial packets, poll returns 0 0
    ring 0x7fcf50954000 cur     0 [buf   4611 flags 0x0000 len    60]
        0: 90 e2 ba 83 3f 25 90 e2 ba 78 26 8d 08 00 45 00 ....?%...x&...E.
       16: 00 24 ce 85 40 00 40 11 43 49 0a 0a 0a 0a 0a 0a .$..@.@.CI......
       32: 0a dd ed 13 00 35 00 10 4f 47 61 73 64 61 73 64 .....5..OGasdasd
       48: 61 0a 00 00 00 00 00 00 00 00 00 00
    701.534128 main_thread [1448] 1 pps (1 pkts in 1001129 usec)
    702.535260 main_thread [1448] 0 pps (0 pkts in 1001132 usec)
    703.536380 main_thread [1448] 0 pps (0 pkts in 1001120 usec)
    And in tcpdump window:
    tcpdump -n -i eth5
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth5, link-type EN10MB (Ethernet), capture size 262144 bytes
    08:01:36.520074 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 21, length 64
    08:01:36.520114 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 21, length 64
    08:01:37.519971 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 22, length 64
    08:01:37.520009 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 22, length 64
    08:01:38.520028 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 23, length 64
    08:01:38.520060 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 23, length 64
    08:01:39.520091 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 24, length 64
    08:01:39.520130 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 24, length 64
    08:01:40.520096 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 25, length 64
    08:01:40.520134 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 25, length 64
    08:01:41.520030 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 26, length 64
    08:01:41.520064 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 26, length 64
    08:01:42.520016 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 27, length 64
    08:01:42.520053 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 27, length 64
    08:01:43.520086 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 28, length 64
    08:01:43.520125 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 28, length 64
    ^C
    16 packets captured
    16 packets received by filter
    0 packets dropped by kernel
    As you can see. Linux haven't saw UDP packets to 53 port but still process icmp packets. Everything works well! Hurra!

     Folks, be aware. This patch is very rude and not tested well. And we need some way for detaching this queue from Linux side because for ICMP packets case Linux try to send reply packets over detached queue. Haha, actually, we could do it very simple. We could disable tx queue detaching and use it for Linux.

    And we need do some custom RING number tuning for ixgbe driver.

    Finalyly, this approach working but need some enhancements :) 

    пятница, 19 июня 2015 г.

    Сборка libbgpdump на Debian 8 Jessy

    Офсайт: http://www.ris.ripe.net/source/bgpdump/
    apt-get install -y libbz2-dev zlib1g-dev
    cd /usr/src
    wget http://www.ris.ripe.net/source/bgpdump/libbgpdump-1.4.99.15.tgz
    tar -xf libbgpdump-1.4.99.15.tgz
    cd libbgpdump-1.4.99.15
    ./configure --prefix=/opt/libbgpdump
    make install
    Добавляем:
    echo "/opt/libbgpdump/lib" > /etc/ld.so.conf.d/libbgpdump.conf
    ldconfig
    Вызываем:
     /opt/libbgpdump/bin/bgpdump

    Самый простой способ использовать новое ядро в Debian Jessie - взять из Sid

    Друзья! Этот вариант для суровых экспериментаторов, которые знают, как починить систему после такого вандализма! Если Вы не знаете - то и ядро Вам обновлять не нужно, честно говорю! 

    Скачать отсюда:  https://packages.debian.org/sid/amd64/linux-image-4.0.0-2-amd64/download

    Так:
    wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-headers-4.0.0-2-amd64_4.0.5-1_amd64.deb
    wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-image-4.0.0-2-amd64_4.0.5-1_amd64.deb
    wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-4.9-x86_4.0.5-1_amd64.deb
    wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-headers-4.0.0-2-common_4.0.5-1_amd64.deb
    wget http://ftp.us.debian.org/debian/pool/main/l/linux-tools/linux-kbuild-4.0_4.0.2-1_amd64.deb

    И поставить через:
    dpkg -i linux-compiler-gcc-4.9-x86_4.0.5-1_amd64.deb  linux-kbuild-4.0_4.0.2-1_amd64.deb
    dpkg -i linux-image-4.0.0-2-amd64_4.0.5-1_amd64.deb
    dpkg -i linux-headers-4.0.0-2-common_4.0.5-1_amd64.deb
    dpkg -i linux-headers-4.0.0-2-amd64_4.0.5-1_amd64.deb

    вторник, 16 июня 2015 г.

    How to run netmap on ixgbe Virtual Function on Debian 8 Jessie

    UPDATE: folks, please be AWARE! In this mode netmap working only in single-copy mode and will not work enough fast (1-2 mpps is a limit). For full support we need another patch for ixgbevf driver.

    If you want zero copy support, please poke netmap guys here: https://github.com/luigirizzo/netmap/issues/63

    First of all, install Netmap and ixgbe module: http://www.stableit.ru/2014/10/netmap-debian-7-wheezy-intel-82599.html

    Please add this code to /etc/rc.local (please remove -e flag from /bin/sh in first line of /etc/rc.local):
    insmod /usr/src/netmap/LINUX/netmap.ko
    modprobe mdio
    modprobe ptp
    modprobe dca
    insmod /usr/src/netmap/LINUX/ixgbe/ixgbe.ko max_vfs=2,2
    insmod /lib/modules/3.16.0-4-amd64/kernel/drivers/net/ethernet/intel/ixgbevf/ixgbevf.ko
    And reload server!

     Then, I have physical NIC eth6 which represented as 2 virtual NICs (ip link show):
    8: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 90:e2:ba:4a:d8:e8 brd ff:ff:ff:ff:ff:ff
        vf 0 MAC 90:e2:ba:55:aa:bb, spoof checking on, link-state auto
        vf 1 MAC 90:e2:ba:55:bb:cc, spoof checking on, link-state auto
    15: eth10: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/ether 90:e2:ba:55:aa:bb brd ff:ff:ff:ff:ff:ff
    16: eth11: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/ether 90:e2:ba:55:bb:cc brd ff:ff:ff:ff:ff:ff
    Then, I configure MAC's for both virtual functions:
    ip link set eth6 vf 0 mac 90:e2:ba:55:aa:bb
    ip link set eth6 vf 1 mac 90:e2:ba:55:bb:cc
    And reload ixgbevf driver (required for configuration):
    rmmod ixgbevf
    modprobe ixgbevf
    After this operations all interfaces become ready:
    ethtool eth6
    Settings for eth6:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                       drv probe link
        Link detected: yes
    [email protected] ~ # ethtool eth10
    Settings for eth10:
        Supported ports: [ ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: Unknown!
        Auto-negotiation: off
        Current message level: 0x00000007 (7)
                       drv probe link
        Link detected: yes
    [email protected] ~ # ethtool eth11
    Settings for eth11:
        Supported ports: [ ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: Unknown!
        Auto-negotiation: off
        Current message level: 0x00000007 (7)
                       drv probe link
        Link detected: yes
    And run pkt-get example app on ixgbe VF:
    ./pkt-gen -f rx -i netmap:eth10
    361.732713 main [1651] interface is netmap:eth10
    361.733491 extract_ip_range [288] range is 10.0.0.1:0 to 10.0.0.1:0
    361.733506 extract_ip_range [288] range is 10.1.0.1:0 to 10.1.0.1:0
    361.734155 main [1848] mapped 334980KB at 0x7f5f9804f000
    Receiving from netmap:eth10: 1 queues, 1 threads and 1 cpus.
    361.734182 main [1934] Wait 2 secs for phy reset
    363.734288 main [1936] Ready...
    363.734328 nm_open [456] overriding ifname eth10 ringid 0x0 flags 0x1
    363.734384 receiver_body [1184] reading from netmap:eth10 fd 4 main_fd 3
    364.735415 main_thread [1448] 3 pps (3 pkts in 1001042 usec)
    365.736481 main_thread [1448] 1 pps (1 pkts in 1001065 usec)
    366.737542 main_thread [1448] 1 pps (1 pkts in 1001061 usec)
    ^C367.134692 main_thread [1448] 0 pps (0 pkts in 397151 usec)


    понедельник, 8 июня 2015 г.

    среда, 27 мая 2015 г.

    Linux CPU Info Intel(R) Xeon(R) CPU D-1540

    Very interesting CPU:
    processor    : 15
    vendor_id    : GenuineIntel
    cpu family    : 6
    model        : 86
    model name    : Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
    stepping    : 2
    microcode    : 0x7
    cpu MHz        : 800.390
    cache size    : 12288 KB
    physical id    : 0
    siblings    : 16
    core id        : 7
    cpu cores    : 8
    apicid        : 15
    initial apicid    : 15
    fpu        : yes
    fpu_exception    : yes
    cpuid level    : 20
    wp        : yes
    flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap
    bogomips    : 4000.14
    clflush size    : 64
    cache_alignment    : 64
    address sizes    : 46 bits physical, 48 bits virtual
    power management:

    четверг, 21 мая 2015 г.

    kernel BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392!

    Выбили вот такой мерзопакостный баг на Debian 7 попытавшись с машины,
    где примонтирован LUN сделать smartctl -all:  
    [184269.064497] device eth3 left promiscuous mode
    [186412.825825] iscsi_trgt: BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392 assert(req->tio)
    [186412.825876] Pid: 2488, comm: istiod2 Tainted: G O 3.2.0-4-amd64 #1 Debian 3.2.54-2
    [186412.825879] Call Trace:
    [186412.825888] [<ffffffffa01cd3f1>] ? send_data_rsp+0x45/0x1f4 [iscsi_trgt]
    [186412.825893] [<ffffffffa01d60df>] ? ua_pending+0x19/0xa5 [iscsi_trgt]
    [186412.825898] [<ffffffffa01d4db4>] ? disk_execute_cmnd+0x1cf/0x22d [iscsi_trgt]
    [186412.825903] [<ffffffffa01d0a3d>] ? worker_thread+0xfd/0x255 [iscsi_trgt]
    [186412.825908] [<ffffffff8103f6ba>] ? try_to_wake_up+0x197/0x197
    [186412.825912] [<ffffffffa01d0940>] ? nthread_stop+0x35/0x35 [iscsi_trgt]
    [186412.825947] [<ffffffff8105f681>] ? kthread+0x76/0x7e
    [186412.825956] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10
    [186412.825963] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139
    [186412.825971] [<ffffffff81356ef0>] ? gs_change+0x13/0x13
    [186412.825995] ------------[ cut here ]------------
    [186412.826011] kernel BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392!
    [186412.826072] invalid opcode: 0000 [#1] SMP
    [186412.826130] CPU 1
    [186412.826138] Modules linked in: iscsi_trgt(O) crc32c loop snd_pcm coretemp snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel snd_timer aes_x86_64 acpi_cpufreq mperf aes_generic sb_edac snd processor i2c_i801 iTCO_wdt ioatdma soundcore iTCO_vendor_support cryptd edac_core joydev i2c_core thermal_sys pcspkr evdev wmi container button ext3 mbcache jbd usbhid hid sg sd_mod crc_t10dif ehci_hcd ahci libahci libata usbcore igb dca usb_common megaraid_sas scsi_mod [last unloaded: scsi_wait_scan]
    [186412.826712]
    [186412.826749] Pid: 2488, comm: istiod2 Tainted: G O 3.2.0-4-amd64 #1 Debian 3.2.54-2 Intel Corporation S2600CP/S2600CP
    [186412.826857] RIP: 0010:[<ffffffffa01cd3f1>] [<ffffffffa01cd3f1>] send_data_rsp+0x45/0x1f4 [iscsi_trgt]
    [186412.826948] RSP: 0018:ffff88022a547e10 EFLAGS: 00010286
    [186412.826997] RAX: 0000000000000000 RBX: ffff8802216b1ae0 RCX: 0000000000001d05
    [186412.827079] RDX: 0000000000001d05 RSI: ffff88022a547f58 RDI: ffff88022a547f58
    [186412.827160] RBP: 0000000000000000 R08: 0000000000000002 R09: 00000000fffffffe
    [186412.827242] R10: 0000000000000000 R11: 0000000000000002 R12: ffff880230281160
    [186412.827323] R13: ffff880071534000 R14: ffff88022d5dde58 R15: ffff88022d5dde68
    [186412.827405] FS: 0000000000000000(0000) GS:ffff880235820000(0000) knlGS:0000000000000000
    [186412.827490] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [186412.827541] CR2: 00007fff65423ba8 CR3: 0000000001605000 CR4: 00000000000406e0
    [186412.827623] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [186412.827705] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [186412.827787] Process istiod2 (pid: 2488, threadinfo ffff88022a546000, task ffff880230281160)
    [186412.827871] Stack:
    [186412.827908] ffff880200000000 ffff88023421c0c0 0000000000013780 ffffffffa01d60df
    [186412.828005] ffff88022a547fd8 ffff8802216b1ae0 ffff880230281160 ffff880230281160
    [186412.828102] ffff880071534000 ffff88022d5dde58 ffff88022d5dde68 ffffffffa01d4db4
    [186412.828198] Call Trace:
    [186412.828241] [<ffffffffa01d60df>] ? ua_pending+0x19/0xa5 [iscsi_trgt]
    [186412.828298] [<ffffffffa01d4db4>] ? disk_execute_cmnd+0x1cf/0x22d [iscsi_trgt]
    [186412.828382] [<ffffffffa01d0a3d>] ? worker_thread+0xfd/0x255 [iscsi_trgt]
    [186412.828437] [<ffffffff8103f6ba>] ? try_to_wake_up+0x197/0x197
    [186412.828491] [<ffffffffa01d0940>] ? nthread_stop+0x35/0x35 [iscsi_trgt]
    [186412.828546] [<ffffffff8105f681>] ? kthread+0x76/0x7e
    [186412.828596] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10
    [186412.828650] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139
    [186412.828703] [<ffffffff81356ef0>] ? gs_change+0x13/0x13
    [186412.828752] Code: 48 85 ed 75 28 48 c7 c1 38 7d 1d a0 ba 88 01 00 00 48 c7 c6 a7 79 1d a0 48 c7 c7 df 79 1d a0 31 c0 e8 5c c1 17 e1 e8 8b a6 17 e1 <0f> 0b 48 89 df e8 d0 fa ff ff 8b 55 14 39 d0 0f 46 d0 85 d2 0f
    [186412.829173] RIP [<ffffffffa01cd3f1>] send_data_rsp+0x45/0x1f4 [iscsi_trgt]
    [186412.829232] RSP <ffff88022a547e10>
    [186412.829825] ---[ end trace e43aba698581fccf ]---
    [186413.508062] general protection fault: 0000 [#2] SMP
    [186413.508324] CPU 0
    [186413.508403] Modules linked in: iscsi_trgt(O) crc32c loop snd_pcm coretemp snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel snd_timer aes_x86_64 acpi_cpufreq mperf aes_generic sb_edac snd processor i2c_i801 iTCO_wdt ioatdma soundcore iTCO_vendor_support cryptd edac_core joydev i2c_core thermal_sys pcspkr evdev wmi container button ext3 mbcache jbd usbhid hid sg sd_mod crc_t10dif ehci_hcd ahci libahci libata usbcore igb dca usb_common megaraid_sas scsi_mod [last unloaded: scsi_wait_scan]
    [186413.512625]
    [186413.512730] Pid: 2486, comm: istd2 Tainted: G D O 3.2.0-4-amd64 #1 Debian 3.2.54-2 Intel Corporation S2600CP/S2600CP
    [186413.513108] RIP: 0010:[<ffffffff81036280>] [<ffffffff81036280>] __wake_up_common+0x3d/0x77
    [186413.513336] RSP: 0018:ffff88022ab73ce0 EFLAGS: 00010083
    [186413.513451] RAX: ffff88022a547e90 RBX: 0000000000000001 RCX: 0000000000000000
    [186413.513599] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88022a547e90
    [186413.513746] RBP: 0000000000000003 R08: 0000000000000000 R09: ffffffff81406060
    [186413.513894] R10: 0000000000013780 R11: 0000000000003428 R12: ffffffffffffffe8
    [186413.514042] R13: 0000000005010500 R14: 0000000000000000 R15: ffff88022d5dde70
    [186413.514191] FS: 0000000000000000(0000) GS:ffff880235800000(0000) knlGS:0000000000000000
    [186413.514342] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [186413.514459] CR2: 00007f7bd8ca9594 CR3: 0000000001605000 CR4: 00000000000406f0
    [186413.514607] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [186413.514755] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [186413.514903] Process istd2 (pid: 2486, threadinfo ffff88022ab72000, task ffff88022b5b6ea0)
    [186413.515053] Stack:
    [186413.515157] 00000000000008d0 0000000000000000 0000000000000246 ffff88022d5dde68
    [186413.515593] 0000000000000286 000000000000dba9 000000000000dbaa ffff880135ee0098
    [186413.516028] 0000000000000001 ffffffff81037f81 0000000000000009 0000000000000000
    [186413.516464] Call Trace:
    [186413.516573] [<ffffffff81037f81>] ? __wake_up+0x35/0x46
    [186413.516693] [<ffffffffa01ce20c>] ? iscsi_session_push_cmnd+0x1ba/0x24f [iscsi_trgt]
    [186413.516845] [<ffffffffa01cfcca>] ? istd+0x500/0x101e [iscsi_trgt]
    [186413.516966] [<ffffffff812ddf60>] ? inet_dgram_connect+0x72/0x72
    [186413.517087] [<ffffffff8134ea11>] ? __schedule+0x5f9/0x610
    [186413.517205] [<ffffffffa01cf7ca>] ? nthread_wakeup+0x2c/0x2c [iscsi_trgt]
    [186413.517328] [<ffffffff8105f681>] ? kthread+0x76/0x7e
    [186413.517446] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10
    [186413.517566] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139
    [186413.517685] [<ffffffff81356ef0>] ? gs_change+0x13/0x13
    [186413.517800] Code: 53 89 d3 48 83 ec 18 48 8b 57 08 4c 8b 22 48 8d 42 e8 49 83 ec 18 eb 35 44 8b 28 4c 89 c1 4c 89 44 24 08 44 89 f2 89 ee 48 89 c7 <ff> 50 10 85 c0 4c 8b 44 24 08 74 0a 41 80 e5 01 74 04 ff cb 74
    [186413.522659] RIP [<ffffffff81036280>] __wake_up_common+0x3d/0x77
    [186413.522849] RSP <ffff88022ab73ce0>
    [186413.522959] ---[ end trace e43aba698581fcd0 ]---

    Как починить:  https://www.vaspects.com/2013/11/01/esxi-5-5-crashes-linux-iscsi_trgt/ коротко - обновляйтесь версию айскази модуля на ту, что поставляется в сорцах либо переходите на Jessie :)

    среда, 20 мая 2015 г.

    Technical comparison of OpenVZ and commercial Virtualization Platforms from Parallels/Odin


    There are bunch promotion articles about PCS (Parallels/Odin Cloud Server) and Virtuozzo. But I can't find any technical comparison between OpenVZ (open source and free) and commercial platforms.

    I have 7 years experience with OpenVZ and 2 year experience with PCS in heavy production, thus I could create this comparison table manually :)


    Feature Commercial OpenVZ
    API Yes No
    Central management Yes, PVA (awfully buggy) No, multiple open source solutions
    Toolkit for compaction of fat ploop images Yes, pcompact No, but could be done in few lines of code with vzctl compact
    Toolkit for migration physical servers to containers Yes, p2c migrate No
    Rebootless kernel update (without physical server rebootm kernel reboot only) Yes, vzreboot No
    Pure kernel live updates (without physical server reboot, no kernel reboot) No, only with external tool KernelCare No, only with external tool KernelCare
    Repair mode for VPS Yes No
    Live migration between servers (no zero downtime) Yes Yes
    Live migration between servers (zero downtime) Yes No
    Flexible container OS templates Yes, vztemplates No, only precreated templates
    Memory deduplication for binary files Yes, pfcache techology No
    Support for cloud storages for containers Yes, Parallels Cloud Storage No, only NFS
    Completely isolated disk subsystem for containers Yes, ploop Yes, ploop
    Support for fully virtualized virtual machines Yes, bundled support for Parallels VM No but works perfectly with KVM on same server
    Fast and reliable kernel on top of RHEL 2.6.32 Yes (same version as OpenVZ) Yes
    Full backup capability Yes No but open source solutions exists
    Incremental backup Yes No and no open source solutions
    NUMA optimization (balancing) Yes No, but some open source solutions exists
    Finally, you could decide what are you want and select proper product for your company.