FastNetMon
Tuesday, 19 January 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
Sunday, 17 January 2016
Thursday, 14 January 2016
О роли баз данных в надежности Интернета
В данной статье хочется поделиться моим собственным видением как позитивных, так и негативных моментов в эволюции Сети Интернет. Общеизвестно, что Интернет - это сеть сетей, но с литературной точки зрения постоянное повторение слова сеть будет идеей не из лучших, поэтому я предлагаю использовать более техническое название для каждой из сетей составляющих Интернет - автономная система.
Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние 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.
Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние 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) и не обязательно к исполнению :)
Так уж вышло, что работаю я в двух сферах - хостинг и сетевые технологии, поэтому почти все прогнозы в той или иной мере будут из данных сфер.
---
Прогноз - начало массового внедрения технологии 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) и не обязательно к исполнению :)
Thursday, 26 November 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:
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:
Then open file /etc/go-carbon/go-carbon.conf
And change following options:
Then switch off python carbon and start go-carbon:
And it's lightning fast:
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.76So We could hit limit with about 200 000 records per second and it's not so fine.
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
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.debThen we need to change path to original graphite data files (it's completely back compatible but please keep backup):
dpkg -i go-carbon_0.6_amd64.deb
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 stopSo you still can use graphite web for reading data! And feed data with pickle of text protocol. It's completely back compatible.
/etc/init.d/go-carbon start
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:
Thursday, 12 November 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 :)
Источник, моя же публикация.
Thursday, 29 October 2015
Tuesday, 27 October 2015
Бесплатный журнал Интернет изнутри от MSK-IX
Прошу любить и жаловать всех, кто так или иначе связан с сетью Интернет.
Сетевикам прочтение крайне обязательно: http://www.ccni.ru/download/InternetInside/InternetInside_N1.pdf
Сетевикам прочтение крайне обязательно: http://www.ccni.ru/download/InternetInside/InternetInside_N1.pdf
Thursday, 8 October 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»После этого фикса все стало работать решительно приличнее, но совершенно никаких гарантий, что так будет и впредь.
Но если копнуть дальше, на деле это не совсем .so библиотека и привычного нам машинного кода там нету.
А есть обертки, которые вызывают код из Golang и подставляют себя С функциями.
Дада, Вы верно догадываетесь, Go's runtime запускается рядом. Не заметить это сложно - появляется 5ка тридов рядом с вашей программой Смайлик «smile»
Но это пол беды - этот рантайм запускается в момент запуска Вашего С-приложения, автоматически.
И если оно форкается или форкается и потом использует popen - горевать Вам очень долго, потому что многопоточное приложение, которым с момента запуска int main стал Ваш любимый софт из-за Go рантайма нельзя форкать, будет все крайне плохо Смайлик «smile»
Я даже молчу, что этот самый Го рантайм подменяет обработчики привычных нам сигналов и заворачивает их на себя, что может вызвать серьезный баттхерт у любителей поиграться с сигналами.
Как чинить? Линковаться динамически в рантайме, силами dlopen/dlsym, как сделал я - тут.
Вот так вот друзья - не все так просто, за все нужно платить Смайлик «smile»После этого фикса все стало работать решительно приличнее, но совершенно никаких гарантий, что так будет и впредь.
Thursday, 27 August 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 кошелька куда класть выкуп если вдруг образовалось желание вернуть свои файлы обратно.
Друзья, искренне рекомендую всем иметь надежный бэкап!
Subscribe to:
Posts
(
Atom
)