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

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

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

Итак, мой негативный опыт связан с Альфа Банком (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, дизеля) и вероятность подобного развития событий (с повреждением данных) очень низкая.