FastNetMon

Friday 29 January 2016

Fast-rdiff is extremely fast impelementation of rdiff algorithm for OpenVZ ploop containers

I would like to share my project implemented at FastVPS.ru for large scale backup system.

This is very fast (thanks to C++) impelementation of rdiff algoritmh (delta difference, librsync, rdiff). Actually, rdiff should not be used in production due to significant performance issues: https://github.com/librsync/librsync/issues/6

We support only delta generation and ONLY for 1MB block files (we are using fast-rdiff for OpenVZ ploop files).

We haven't support for "rdiff path" but original rdiff could be used for this purpose. But please be careful! fast-rdiff is using md4 algorithm and you could explicitly specify it to new rdiff:= with option: --hash=md4

https://github.com/FastVPSEestiOu/fast-rdiff

Thursday 28 January 2016

Как сделать bash alias для Ubuntu 14.04?

Есть много способов, но как всегда есть тот, что предусмотрен авторами дистрибутива.

Итак, прошу:
vim ~/.bash_aliases 
Вносим там нужные алиясы один на строку:

alias cmake="/opt/fastnetmon/libraries/cmake-3.4.2/bin/cmake"

И после этого перелогиниваемся в ssh :)

Почему я предпочитаю RAID-10 реализации RAID-6, которая "теоретически" надежнее?

Исключительно практика, обычно на аппаратных RAID контроллерах стоят крайне слабые процессоры и RAID-6 они реализуют просто ОЧЕНЬ плохо.

Было несколько случаев потери данных исключительно из-за крайне сложной реализации и
крайне долгого ребилда массивов контроллерами - LSI/Adaptec. Также массивы RAID-6 были замечены повышенным износом диском и повышенным числом их отказов. Возможно, это было вызвано проблемами с выравниванием / размером страйпа.


Кромеэтого, в случае сбоя - диски с данными идут на свалку, потому что
реализация не совместима с Linux MD.

RAID-10 же прост как бревно,поэтому используется у нас на сотнях серверов по меньшей мере 5
лет без малейших проблем (разумеется, с UPS, BBU, ECC памятью) :)

Вырезание / вставка текста в vim

Shift + V, потом d для вырезания.

ESC, P или p (в зависимости от места вставки до или после курсора).

Комментирование большого блока текста в vim

Продолжаем прокачиваться в vim! Опять очень неприятная и муторная задача - комментирование/раскомментирование больших блоков текста в языках не поддерживающих multiline comments.

Esc, CTRL + V, вверх-вниз стрелками выделяем текст.  Потом жмем CTRL + I и вводим #, потом жмем ESC и ждем пока vim добавит везде в начало строк заданный символ комментария.

Как убрать или сделать отступ на множестве строк в vim?

Уже долгие годы я использую vim, но как и многие - я очень плохо умею использовать его мегафичи.

Вот озвученная в сабже тема постоянно решалась мной вручную и очень долго.

Но есть решение!

Итак, сначала нам нужно установить режим отступа, :с=4 означает, что 1 отступ - это 4 пробела.

После этого, выделяем построчно нужный текст используя команды - Esc, SHIFT + V, после этого увидим строку выделения и щелкаем клавишами вверх либо вниз чтобы выделить весь нужный нам текст.

После того, как текст выделен жмем SHIFT + >. И в результате этой операции текст сдвинется на 4 пробела вправо!

Ура! Цель достигнута! А вообще рекомендую использовать clang format либо язык Go + vimgo для автовыравнивания кода, чтобы вообще не беспокоится об отступах вручную. 

Friday 22 January 2016

C vs C++ 11 в одной странице

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

Пожалуй, я нашел ответ.

Привожу пример кода на С++ 11, который запрашивает данные из Mongo DB:
mongocxx::driver::client c{“mongo://example.com:27017”};
auto col = c[“testdb”][“testcol”];
for (auto doc : col.find({}) {
    std::cout << bsoncxx::to_json(doc) << std::endl;
 }
А теперь тоже самое на С:
    bson_error_t error;
    bson_oid_t oid;
    bson_t query;
    mongoc_init ();
    bson_init (&query);
    mongoc_client_t* client = mongoc_client_new (connection_string);
    if (!client) {
        printf("Can't connect to MongoDB database with credentials %s", connection_string);
        return false;
    }  
    mongoc_collection_t* collection = mongoc_client_get_collection (client, mongodb_database_name, collection_name);
    mongoc_cursor_t* cursor =  mongoc_collection_find (
        collection,
        MONGOC_QUERY_NONE, 0, 0, 0, &query, NULL,  / Fields, NULL for all. /
        NULL
    ); / Read Prefs, NULL for default /
    const bson_t *doc = nullptr;
    while (mongoc_cursor_next (cursor, &doc)) {
        char *str = bson_as_json (doc, NULL);
        json_document = std::string(str);
        //fprintf (stdout, "%s\n", str);
        bson_free (str);
    }
    mongoc_cursor_destroy (cursor);
    mongoc_collection_destroy (collection);
    mongoc_client_destroy (client);
    mongoc_cleanup (); 

Thursday 21 January 2016

Отличная статья про архитектуру LLVM

Full BGP table distribution by prefix length for IPv6

 ip -6 r show | grep -v "unreachable" | sed 's#/# #' | awk '{print $2}' | sort | uniq -c | sort -rg
  12044 48
   7273 32
   1311 40
   1118 44
    985 36
    933 29
    385 46
    291 33
    233 35
    230 47
    211 38
    196 34
    170 42
    141 41
    124 45
    119 39
    102 30
     91 37
     75 31
     71 28
     60 64
     35 43
     26 126
     20 24
     16 27
     14 26
     10 49
      9 20
      7 56
      6 127
      5 25
      4 23
      4 22
      3 52
      3 21
      3 124
      2 50
      2 19
      1 65
      1 62
      1 55
      1 16
      1 125
      1 12

Wednesday 20 January 2016

Full BGP table distribution by prefix length for IPv4

 315542 24
  63558 22
  54677 23
  39305 21
  36837 20
  25324 19
  12989 16
  12532 18
   7403 17
   1764 15
   1029 14
    858 29
    748 25
    637 26
    519 28
    506 13
    396 27
    264 12
    102 11
     35 10
     16 8
     13 9
      5 30
      3 31

Date: 20 Jan 2016.

Monday 18 January 2016

Что делать в случае "Please do some other work to give the OS a chance to collect more entropy"


Такой баг часто возникает на виртуальных окружениях, на которых нет оборудования реального.

Решение простое - поставить демон, который будет увеличивать энтропию:

sudo apt-get install -y haveged
/etc/init.d/haveged start

И убеждаемся, что ее стало больше:
cat /proc/sys/kernel/random/entropy_avail1795
Но строго говоря - это неверный в корне путь, избегайте генерации ключей на машинах, где недостаточно энтропии для работы генератора случайных чисел! Лучше генерируйте их на машине, на которой вы работаете в данный момент.

Только будьте аккуратны - процессор этот чудо-демон жрет очень сильно:

 1346 root       20   0  9472  3508   368 R 104.  0.0 27h02:00 /usr/sbin/haveged -w 4096

Thursday 14 January 2016

Go для программистов на С++

О роли баз данных в надежности Интернета

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

Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние  5 лет наблюдается процесс экстенсивного укрупнения Интернет компаний.

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

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

Но последнее время баланс стал нарушаться - заметна крайне активная тенденция к образованию огромных сетей транснационального масштаба, которые в десятки и иногда тысячи раз больше сетей, которые считались ранее. Это своего рода Интернет в Интернете. За одним исключением - автономная система, а следовательно компания, которая управляет этой сетью одна единственная.

К примерам таких сетей можно отнести - Facebook, Google, Youtube, Twitter (список совершенно не претендует на полноту). Это довольно разные по своей сути компании - социальные сети, хранилища контента, поисковые системы. Но их объединяет глобальный характер и популярность планетарного масштаба. Я специально не указал здесь сети, которые распространены в масштабах определенных стран, чтобы подчеркнуть именно глобальный масштаб оценки.

Так сложилось, что почти все подобные компании имеют головные офисы в США, этому есть множество причин, описание которых выходит за рамки как моей компетенции, так и статьи в целом.

И тут мы подходим к самому Интересному, базам данных. Любой кто работал с базами данных MySQL, PostgreSQL, MSSQL и Oracle сталкивался с запросами, а как же обеспечить полное резервирование этих баз данных на случае сбоя. Кроме этого, почти всегда накладывается требование - сделать это на уровне базы данных, без внесения изменений на уровне бизнес-логики приложения. К сожалению, обобщенный ответ на этот вопрос почти всегда - "никак". Каждый из вариантов резервирования - master/master, master/single slave, master/multiple slaves является компромиссом и требует очень высокого уровня как квалификации архитектора подобного решения, так и предъявляет высокие требования к квалификации персонала и резко увеличивает необходимый для поддержки решения штат.

Безусловно, решения задачи резервирования баз данных существуют и для реляционных баз данных (SQL), так и для нереляционных, так называемых key-value или document-oriented баз данных, но каждый из них требует серьезных инвестиций и серьезных изменений в архитектуре приложения.

Но самое интересное, что когда рассматривается любой вопрос обеспечения надежности хранения данных он решается в рамках LAN, локальной сети, одного города либо одной страны. Но решения задачи репликации крупной базы данных на несколько различных континентов в данный момент не существует и во многом это вина скорости света :)

И здесь мы подходим к самому интересному моменту, что даже  крупные компании из перечисленных выше эту задачу не решают в полной мере. На 2014й год вся запись информации (например, публикация нового сообщения) на сайте Facebook безусловно уходила в США. В то время как графика и статический контент могли загружаться из Дата Центра в Швеции (Лулль). Казалось бы, ничего страшного, но в масштабе сети это очень неприятное явление. Так как нарушение связанности с сетями США в виду каких-либо проблем приведет к полной потере работоспособности сервиса и последующей потери его ценности для конечного пользователя.

Может показаться, что в статье я критикую недостаточную компетенцию указанных компаний. Честно говоря, это бы звучало очень странно, тем более, что в компании Google есть прототип реально работающей географически распределенной базы данных, которая является ядром всего технологического стека этого гиганта - Google Big Table. Но, к сожалению, это проприетарная платформа и информация о ней крайне скудна. Конечно же, появление подобных продуктов на массовом рынке дало бы огромный скачек к повышению надежности как отдельных сервисов, так и сети Интернет в целом

Их нужно знать в лицо - наиболее устойчивые к сбоям протоколы.

Есть ли примеры реализации полностью устойчивых к нарушениям связанности протоколов и сервисов? Безусловно! Это наш любимый сервис - root DNS, который тоже в своем роде является очень большой географически распределенной сетью насчитывающей около тысячи узлов. Но в случае протокола DNS у нас нет необходимости менять значения для корневых зон, чаще всего меняются данные в листьях (записи в конкретной доменной зоне и записи для конкретного домена). И протокол DNS отлично справляется с обеспечением надежного хранения изменений. Несмотря на это, единая точка отказа все равно присутствует, как раз на ней хранятся данные о всех корневых серверах. Но, к счастью, в связи с довольно медленным процессом изменения данных в DNS (сравните с базой транзакций банка!) такой сбой пройдет скорее всего незамеченным даже если продлится несколько десятков часов.

Также отличной иллюстрацией абсолютно устойчивого протокола - сервиса является BitTorrent, который при использовании функционала DHT позволяет добиться полной де-централизации и независимости от какого-либо мастера (его просто не существует). Но тут также не решается проблема с изменением данных - изменение не предусмотрено в принципе.

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

Что в будущем?

Кроме этого, уже появилась реально работающая (и даже используемая в коммерческой услуге компанией Korea Telecom) реализация multipath tcp, которая позволяет добиться повышенного уровня надежности. Ранее данный функционал был реализован в протоколе sctp, но, к сожалению, он так и не обрел какой-либо серьезной популярности.

Также технологической проблемой на пути к построению реально надежных сервисом является отсутствие встроенной поддержки обеспечения высокой доступности как в протоколе HTTP, так и в протоколе HTTP2.

Выводы

Процесс укрупнения автономных систем и последующей централизации Интернета, к сожалению, неотвратим. Он очень похож на тенденции развития новых рынков. Все начинается со множества небольших компаний компаний и постепенно выкристаллизовываются несколько огромных ключевых игроков, которые замыкают на себе почти всех клиентов.

Дата написания: 10 декабря 2015 г., 22:09.

Три строчки, которые сэкономят тонну нервов с Go :)

Забивать это дело в /etc/profile сразу для всех юзеров :)

export PATH=$PATH:/usr/local/go/bin
export GOPATH="$HOME/gofolder"
export PATH=$PATH:$GOPATH/bin
Подразумевается, что Go установлен из tar.gz в папку /usr/local/go.

Tuesday 12 January 2016

Мой конфиг в VIM

Выглядит вот так: https://gist.github.com/pavel-odintsov/9b3375b4de6ff7098030

Приятных фишек не так много, но отполирован за годы работы :)

Monday 4 January 2016

ИТ прогноз на 2016й год от Одинцова Павла

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

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

---

Прогноз - начало массового внедрения технологии 100GE на всех уровнях инфраструктуры.

Подоплека: Intel выпускает 100GE сетевую карту: http://ark.intel.com/products/92674/Intel-Ethernet-Multi-host-Controller-FM10420

---

Прогноз - программируемая FPGA логика в серверных процессорах общего назначения.

Подоплека: Intel покупает компанию Altera, ведущего производителя FPGA чипов: http://www.bloomberg.com/news/articles/2015-06-01/intel-buys-altera-for-16-7-billion-as-chip-deals-accelerate Intel также не скрывает своих планов предоставить чипы программируемой логики

---

Прогноз - взрывной рост популярности сетевых switch'ей с прошивками на базе Linux (как проприетарными - Cumulus, так и полностью открытыми - https://opennetlinux.org/hcl)

Подоплека: партнерство Dell и Cumulus, https://cumulusnetworks.com/dell/, партнерство HP и Cumulus: http://www.networkworld.com/article/2884208/sdn/hp-latest-to-unbundle-switch-hardware-software.html, а также инициатива openswitch.net в целом.

В тоже время стоит отметить рост популярности white label производителей switch'ей, таких как: http://www.edge-core.com/

---

Прогноз - намного более разрушительные и масштабные DDoS атаки, которые удивят всех и заставят перестать игнорировать этот вопрос при стратегическом планировании.

Подоплека: 2015й год был знаменит массовыми атаками на GutHub (http://arstechnica.com/security/2015/04/ddos-attacks-that-crippled-github-linked-to-great-firewall-of-china/), корневую инфраструктуру DNS (http://www.theregister.co.uk/2015/12/08/internet_root_servers_ddos/) и крупного оператора Linode (http://www.theregister.co.uk/2016/01/04/linode_back_at_last_after_ten_days_of_hell/). С учетом отсутствия серьезной динамики по борьбе с амплификацией и спуфингом не стоит ожидать решения этого вопроса, а наоборот - стоит ожидать появления более изощренных методик атак.

---

Прогноз - крайне активное внедрение HTTP/2 и HTTPS.

Подоплека: добавление поддержки HTTP/2 крупнейшими Интернет компаниями (Google.com, https://blog.cloudflare.com/introducing-http2/). Появление новых инструментов работающих только на базе HTTP/2 (gRPC, https://nghttp2.org). Также поддержка HTTP2 внедряется в веб-серверы, негативно радует в этом вопросе популярный сервер Nginx, отключая возможность работы одновременно с очень широко распространенным SPDY/3, а также отсутствием поддержки HTTP/2 для бэкэнда, что открывает большие перспективы конкурирующим веб-серверам.

Огромный вклад в популяризацию HTTPS привносят постоянные шпионские скандалы о перехвате трафика, попытка государств контролировать Интернет.

Практическая сторона вопроса блестяще решена силами инициативы Let's Encrypt: https://letsencrypt.org/

---

Прогноз - повсеместное внедрение программно управляемых сетей (речь не только про SDN, а опять же решения на базе Cumulus/OpenSwitch) и превращение Network Engineer'ов в Network Developer Engineer'ов.

Подоплека: Расписана в пункте про switch'и на Linux. Всем сетевым инженерам, кто не знает хотя бы одного языка программирования придется крайне туго.

---

Прогноз - продолжение тотальной миграции проектов в облака.

Подоплека - тотальный рост облаков от Amazon, Google и Microsoft. Ни один "классический" провайдер не показывает таких темпов роста и подобного уровня технологичности решений.

---

Прогноз - software defined автомобили.

Подоплека: огромный рост популярности и ошеломляющий успех проекта Tesla. За почти половину века застоя автомобили наконец-то получили полноценную высокотехнологичную начинку и интеграцию с Интернетом. Если Вы считаете, что другие машины имеют что-то подобное, то попробуйте найти три полноценных компьютера и внутреннюю локальную сеть внутри них, а в Тесле - это норма! :)

---

Прогноз - развитие ИИ огромными темпами!

Подоплека - создание открытого проекта https://openai.com/blog/introducing-openai/ и выделение ему инвестиций в размере $1 млрд. Все результаты работы ученых будут опубликованы в свободном доступе. Что же это? Констатация невозможности и высочайшей сложности решения данной задачи? Пожалуй, так и есть. Но все вместе мы определенно справимся.

Также, безусловно, стоит отметить открытие проекта https://tensorflow.org с машинным обучением от Google.

---

Прогноз - дальнейшая глубокая социализация программирования и open source.

Подоплека - если раньше open source был уделом гиков, то теперь у нас есть своя "социальная сеть" - GitHub.com и ошеломляющего размера армия программистов :) Почти все крупные проекты в том или ином виде переходят под крыло GitHub, предоставляющего потрясающую по удобству и возможностям систему коммуникации между программистами. Пожалуй, сложно придумать проект, который так сильно бы продвинул удобство и организацию разработки.

---

Прогноз - начало снижения популярности классических Linux дистрибутивов (Ubuntu, Debian, RHEL, CentOS) при установке непосредственно на сервер. Расцвет гибридных ОС основанных на технологии Docker и Linux контейнерах (CoreOS, http://www.projectatomic.io/).

Подоплека: высокое удобство, легкость масштабирования, готовность проекта Docker для промышленного использования.
---

Прогноз - добавление возможности запуска в Docker контейнерах полноценных ОС, а не только ограниченных в функционале приложений.

Подоплека - огромная работа со стороны компании Virtuozzo (Odin, Parallels) и RedHat для повышения безопасности контейнеров. В тоже время крайне не радует, что данные проекты сконцентрированы вовсе не на ванильном  Linux ядре, а на сильно старых и уже заведомо устаревших форках ядра (Linux 3.10).

Также стоит отметить появление сервиса https://aws.amazon.com/blogs/aws/cloud-container-management/ в публичной доступности!

---

Прогноз - продолжение стремительного роста и повышение популярности NoSQL баз данных (MongoDB, Couchbase, RethinkDB, RocksDB, Redis, Cassandra)

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

Стоит отдельно отметить, что даже классические БД, такие как MySQL и PostgreSQL пошли по пути копирования функционала из NoSQL, например, в недавнее время в них была добавлена поддержка JSON.


Заключение.

Все выше сказанное является лишь субъективным мнением автора (Pavel Odintsov, pavel.odintsov at gmail.com) и не обязательно к исполнению :)