Отвратительнейщий Альфа-Банк

Привет, друзья!

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

Итак, мой негативный опыт связан с Альфа Банком (alfabank.ru), есть такой российский на первый взгляд привлекательный банк, но такое впечатление сохраняется до того момента, пока этот банк не оставит вас без денег.

Меня он оставлял ВООБЩЕ БЕЗ ДЕНЕГ ровно ДВАЖДЫ.

Я являюсь (пока еще, но очень скоро хочу закрыть все свои счета) клиентом банка уже 8й год и в целом был доволен всеми услугами, за исключением двух отвратительных раз. Первый - когда мне заблокировали карту заграницей без предупреждения под десертом "заботы и безопасности", я их за это ненавидел, потому что ситуация была бесконечно мерзкая, не окажись бы рядом друзей. А второй раз - сегодня.

Но сегодняшняя ситуация меня просто убила.

Альфа-Банка БЕЗ ПРЕДУПРЕЖДЕНИЯ АННУЛИРОВАЛ МОЮ ДЕБЕТНУЮ КАРТУ, КОТОРУЮ САМ ГОД НАЗАД ПОДАРИЛ!!!!

Хер бы с ним будь эта карта платной, но аннулировать свой же подарок, это просто театр дебилов какой-то. 

Нет, это не смешно, именно так. Год назад мне позвонили с Альфа-Банка и мило поздравили меня с выигрышем и получением подарка! На что я ответил со скепсисом, предвкушая  очередную разводку. Но нет, мне дарили карту Platinum сроком на 3 года (до 2016го) совершенно без оплаты за ее обслуживание (довольно немаленькая сумма)! Но меня не обманули и через неделю в отделении вручили заветную карту, которой я начал сразу пользоваться. Кроме этого, меня заверили, что никаких условий и подвохов в этой карте нету и меня ни за что не заставят платить.

Пользовался я ровно до сегодняшнего дня, так как при попытке расплатиться и потом снять деньги в банкомате я узнал, то моя карта аннулирована банком лишь после звонка в поддержку (причем, именно в поддержку для привилегированных клиентов Альфа Банка)!

Оказывается, моя карта аж два дня была аннулирована и закрыта, по причине........ что я больше не работаю в компании, из которой уволился 6 лет назад. То, что меня не уведомили никаким образом - вообще для банка не считается, чем-то не нормальным.

Что еще более смешно, изначально мне специалист по общению с наиболее важными клиентами (выделенная линия Platinum!!!) заявил, что я лично в отделении Банка закрыл эту карту вчера (когда сидел дома)! Знаете, я чуть не поседел предвосхищая ту их многих историй, когда по поддельным документам снимали все деньги. Но аж после 10 минут висения на линии меня обрадовали реальной причиной =) Даже не извинились, ах-ах! 

Итого, друзья. Если Вы хотите, что бы Вам блокировали карты в тот самый момент, когда Вы не можете ну никак обойтись без денег - ОБРАЩАЙТЕСЬ В САМЫЙ ХУДШИЙ БАНК РОССИИ - АЛЬФАБАНК!

Вот вам такой небольшой эдвайс от меня :)

Ну а что, надежность должна быть не только в крупных ИТ системах, но и личных сбережениях. Так что обходите этот дебильный банк подальше :)

Отличная презентация об эффекте в сокращении нагрузки на CPU за счет offload фич современных сетевых карт

10GbE時代のネットワークI/O高速化 from Takuya Asada

Ага, на Японском, но таблички понятные. Кто переведет на английский будет молодец.

GRE, DDoS и туннели в нашей жизни и их неизменные грабли

GRE — очень большой источник проблем с MTU, если http их переживет более-менее нормально благодаря path mtu discovery, то UDP особенно с флагами «do not fragment» будет нищадно дропаться, на что пользователи будут очень сильно возмущаться. 

Поэтому вариант переброски всего трафика вообще по GRE — не лучшая идея сама по себе. vlan, MPLS или даже какой-либо из VPN с аппаратной поддержкой и поддержкой фрагментации внутри протокола - будет лучше. 

Решить проблемы GRE можно подняв MTU на магистрали (если у вас есть-таки резервный линк до компании по защите), но магистрали вряд ли захотят передавать пакеты с MTU более 1500, а чтобы GRE мог пропускать через себя пакеты с нормальным MTU — нужно пропускать по магистрали пакеты с MTU около 1524, что почти неосуществимо без долгих переговоров с конкретными аплинками. А если такая возможность есть, то скорее всего можно сделать и l2/vlan/mpls, а значит можно просто сделать свой анонс из другого места и это наиболее прямой и предпочтительный вариант «полной защиты» префиксов.

Обработка и фильтрация 80GE трафика на дешевом железе

Итак, стоит хитрая задача - имеется бордер-роутер Juniper MX 240, на который неким образом подведено несколько сотен гигабит интернета через несколько аплинков. 

Стоить задача обсчитать 80GE из этого трафика и пропустить его к клиентам имея лишь 4 сервера (будем звать их фильтр-1/2/3/4 соответственно) с двумя 10GE картами (20GE на 1 сервер). За фильтр серверами стоит один диапазон /24. При этом, трафик даже на 1 IP (/32) должен распределяться по ВСЕМ машинам фильтрам.

Как это реализовать?

Очевидно, входящий трафик должен разделять исключительно роутер, поэтому мы должны выдать каждому фильтр-серверу отдельный IP и создать 4 идентичных правила роутинга по аналогии с Linux:

ip route add 31.xx.xx.xx/24 via 10.10.10.101
ip route add 31.xx.xx.xx/24 via 10.10.10.102
ip route add 31.xx.xx.xx/24 via 10.10.10.103
ip route add 31.xx.xx.xx/24 via 10.10.10.104

Но Juniper тут себя поведет не особо предсказуемо - он будет лить трафик только в один из путей, так как он устроен так :) Но это поведение легко поменять! С помощью директивы - load-balance per-packet которая активирует равномерное распределение трафика по всем путям. Таким образом, все фильтр серверы начнут получать одинаковый объем трафика.

А далее фильтр-серверы передают трафик клиентам через обычные правила роутинга (они должны быть в том же vlan).

Но как сделать чтобы трафик исходящий также балансировался? Тут нам поможет Линукс! А именно вот этот гайд - http://lartc.org/howto/lartc.rpdb.multiple-links.html Схема простая - машина должна получить все 4 фильтр-сервера как дефалт гейтвеи с идентичным weight. Тогда и исходящий трафик размажется пропорционально.

Также полагаю хорошим вариантом решения проблемы был бы MLAG, но с ним могут возникнуть проблемы.

Почему IPv6 нужен каждому сайту?

Довольно часто задают вопрос "зачем мне ваш IPv6", поэтому решил сформулировать тут.

1) Вы не платите деньги за IPv4 (если Вы явно их не платите - это не значит, что они бесплатны, цена включена в тариф). В случае IPv6 у хостера никаких затрат нету и потенциально тариф будет дешевле.
2) Вы получаете миллионы IPv6 совершенно бесплатно (/64, /96 на клиента - норма). Вынести админку на отдельный айпи? Легко. На отдельный айпи повесить почту? Каждый сайт из тысячи на отдельном IP? Легко!
3) Решаются вопросы с блэклистингом IPv4 (речь про странные списки) почтовиками, в случае IPv6, этот процесс можно сказать почти не работает, а для IPv6 взять несколько /64 сети - довольно сложно
4) Вы получаете бОльшую скорость работы сайтов. Так как оборудование для отработки v6 часто стоит отдельно и почти всегда простаивает. Кроме этого, IPv6 сам по себе решительно "легче" навороченного IPv4 и проще для отработки железом
5) Проще обеспечивать сложные сетевые конфигурации. Если Вы хотите в одно мгновение ока перекидывать сайты с ДЦ на ДЦ, делать балансировку через anycast и прочее Вы должны покупать как минимум префикс /24 IPv4, а это ОЧЕНЬ дорогое удовольствие. В случае IPv6 даже /48 сеть не стоит почти ничего, платежи в RIPE минимальны
6) При использовании виртуализации преимущества в целом также очевидны - не нужно городить огород, а просто каждая машина получает свой IPv6, в случае IPv4 это выходит крайне дорого. А учитывая мощности железа - уже почти каждый владелец дедика использует ту или иную виртуализацию, ибо иначе все ресурсы тупо не использовать
7) Отсутствие геморроя при связи с клиентом, если Вам нужна двунаправленный канал связи, то в случае NAT это превращается в страшный ад.

Как из консоли Линукса послать файл с аттачем?

echo "Bug with igb from fastVPS, evo0 hwn" | mutt -a /var/log/messages -s "Bug with igb from fastVPS, evo0 hwn" --   i@domain.com

OpenVZ, ploop и флаг O_DIRECT для MySQL

После долгого обсуждения сошлись на очень хитром эффекте, а именно, если для Innodb выставить тип коммита O_DIRECT вместо стандартного sync/fdatasync, то на OpenVZ это приведет к очень крутому ускорению работы базы данных.

Но как раз в данной статьей красиво объяснено то, что OpenVZ игнорирует O_DIRECT и тем самым указывая такой флаг для MySQL мы отключаем вообще как таковую работу с транзакциями. То есть что есть транзакция, что нету — данные будут записаны по flush таймауту ext4 (5 секунд), а не тогда, когда этого хочет MySQL.

Возможно, в случае очень высокой нагрузки это может привести к потере данных, но в общем случае конфигурация дисковой системы HWN нод подразумевает высокий уровень резервирования (BBU, кэши, UPS, дизеля) и вероятность подобного развития событий (с повреждением данных) очень низкая.

Как собрать 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/