Наше дружное сообщество поздравляет учащихся с началом учебного года! Помните, что ученье - свет, а неученье - чуть свет, на работу.

VMware уже просто кричит о контейнерах в своем продукте. Популярность OpenStack пошла им на пользу, как мы видим.

Если честно, немного страшновато - откроешь какой-нибудь ZDNet или TheRegister, и там в каждой статье контейнер на контейнере, и экcперты, прославляющие этот величайший технологический прорыв Человечества со времен электричества. Мы-то знаем, что "контейнер", это обычный процесс, к которому в таблице процессов добавлены метки "namespace" и "control groups", которые учитываются при его работе, но люди, принимающие решения, похоже этого не знают, и всерьез сравнивают с виртуализацией и кластерами "дооблачных" времен. Есть растущее ощущение, что ушедший в ультразвук энтузиазм по поводу контейнеров обернется ужасающим разочарованием. Но пока этого не произошло, давайте наслаждаться открывшимися возможностями.

Так вот, VMware теперь рекламирует не виртуализацию, а контейнеры. Нам это нравится, т.к. это благоприятно сказывается на блудном сыне VMware, компании Pivotal, которая и помогает VMware создавать новую платформу (благо у них уже есть открытая платформа - Cloud Foundry). Для нас Pivotal, конечно, это прежде всего люди, разрабатывающие нашу любимую шину сообщений - RabbitMQ. На базе нее построен обмен сообщениями в OpenStack, и хотя есть попытки использовать конкурирующие AMQP-решения (Qpid), RabbitMQ с места просто так не сдвинуть. Он написан на Erlang, что заведомо повышает качество кода и надежность системы. Нужно отметить, что рядом лиц затрачиваются огромные усилия по включению варианта на базе ZeroMQ, но есть основания предполагать, что это не взлетит никогда. Если кто не в курсе, то у ZeroMQ помимо ряда социально-организационных проблем, есть серьезные недостатки и ограничения, которые следует учитывать. Наши друзья и коллеги, в т.ч. и участники Moscow Erlang User Group, как-то скинулись и переписали ряд особо гадких особенностей ZeroMQ. Получилось внушительно.


Коллеги узнали, что ты решил использовать ZeroMQ


Конечно, с RabbitMQ есть нюансы использования, все-таки CAP-теорему так просто не объехать, но все ведущие компании-разработчики OpenStack сейчас нанимают Erlang-разработчиков, и можно ожидать, что в ближайшее время ситуация улучшится. Сейчас RabbitMQ рассматривается ими как загадочная шкатулка с музыкой, и даже в Red Hat проблемы с ним решаются извне, не трогая код продукта, а привычно перенастраивая окружение от ядра до Glibc.

Интересно, что VMware, похоже понимает, что главное в "контейнерах", это не сами "контейнеры", а их обвязка - средства управления, живой миграции, failover, развертывание, сетевые возможности (SDN) и многое другое. Недаром она привлекает других именно этими возможностями своих проприетарных продуктов. Тем не менее, не только они тут играются. Mirantis в последнее время дружит со всеми - Mirantis и CoreOS, Mirantis и Intel, и даже Mirantis и Goldman Sachs (Голдманы, как и все финансисты, очень любят открытое, даже оборудование). Некоторые даже всерьез используют термин OpenStack Wars (как Unix Wars, только про OpenStack), но в мире OSS воевать непросто да и бессмысленно - лучше сотрудничать.

Seagate, традиционный участник RICON, сдержал свое обещание открыть исходный код Kinetic Storage Platform (они пообещали сделать это на прошедшем OpenStack Summit, о чем вы уже могли слышать). В рамках проекта будет развиваться платформа распределенного хранилища данных (Software-defined Storage. К проекту уже присоединились Cisco, Cleversafe, Dell, Digital Sense, Huawei, NetApp, Open vStorage, Red Hat, Scality, Seagate, SwiftStack, Toshiba, Western Digital.

Хранилище сразу спроектировали не на базе устаревшего и неподходящего для распределенных систем стандарта POSIX (о его недостатках мы регулярно рассказываем), а как KV-хранилище с незамысловатым протоколом, использующим protocol buffers. Добавление поддержки в WIreshark будет сравнительно несложным делом.

Ну пока еще этот Kinetic взлетит, а до тех пор народ будет использовать традиционные хранилища, и их разработчикам еще работы будет много. Если вы из "Ceph vs. Gluster" выбрали последний, то наверное уже слышали, чтоб в конце весны вышла версия GlusterFS 3.7.0 (новость уже обсуждалась на OpenNET.ru). Из особо понравившихся фич можно выделить "bitrot detection", поддержка NFSv4 и pNFS, и шардинг, но новинок там гораздо больше.

Приглашаем на встречу разработчиков Linux-контейнеров — мероприятие сообщества OpenVZ, которое пройдёт 19 сентября в московском офисе Яндекса. Оно пригодится всем, кто интересуется применением контейнеров и контейнерной виртуализацией.

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

Участие во встрече бесплатное, однако нужно зарегистрироваться.

Программа:

  • 11:00 Регистрация
  • 11:30 Живая миграция контейнеров: плюсы, минусы, подводные камни. Павел Емельянов, Odin
  • 12:00 Управление памятью контейнеров в проекте OpenVZ. Владимир Давыдов, Odin
  • 12:30 Перерыв
  • 12:40 LibCT и контейнеры на уровне приложений. Андрей Вагин, Odin
  • 13:10 Использование контейнерных технологий в DevOps. Дмитрий Лазаренко, Jelastic
  • 13:40 Перерыв
  • 14:30 Опыт использования виртуальных контейнеров в работе сервис-провайдера. Константин Анисимов, Русоникс
  • 15:00 CRIU: ускорение запуска PHP в CloudLinux OS. Руслан Куприев, CloudLinux
  • 15:30 Перерыв
  • 15:40 Развёртывание приложений Docker в контейнерах Virtuozzo. Павел Тихомиров, Odin
  • 16:10 Проблема фрагментации виртуальных дисков и способы её решения. Дмитрий Монахов, Odin
  • 16:40 Закрытие
Как проехать:

Москва. Ул. Льва Толстого, 16. Конференц-зал «Экстрополис»

Информация из доклада "Какие Linux и Unix используют федеральные органы власти России":

Наиболее популярной ОС с открытым исходным кодом является продукт американской компании Red Hat. На его базе функционирует оборудование 25 ФГИС. Доли других ОС приведены в таблице.

Разновидности Linux, используемые в ФГИС

Число ФГИС
Red Hat
25
Debian
15
CentOS
15
Ubuntu
11
Fedora
8
Mandriva
7
SUSE
5
МСВС
2
Alt Linux
1
Oracle Enterprise Linux
1

Данные: аналитический центр TAdviser Report, август 2015

Самым популярным дистрибутивом Unix, согласно исследованию, является FreeBSD. Доли остальных разновидностей приведены в таблице.

Разновидности Unix, используемые в ФГИС

Число ФГИС
FreeBSD
13
Oracle Solaris
8
IBM AIX
7
HP-UX
2
Циркон
1

Данные: аналитический центр TAdviser Report, август 2015

На базе российских дистрибутивов Linux - МСВС и Alt Linux - работают серверы только трех ФГИС.

Наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, разразился серией статей о том, как использовать systemd-networkd (с небольшим перекосом на тему Rackspace, где Fedora всегда была доступна) - использование systemd-networkd в серверах Rackspace OnMetal, как устроены предсказуемые названия сетевых интерфейсов в systemd, и как смастерить сетевой роутер с помощью systemd-networkd (у нас есть некоторые замечания по поводу именно этой заметки, но в целом там все хорошо).

Постепенно развивается flannel. В версии 0.5.0 исправили гадкую ошибку в наиболее скоростном режиме работы, т.е. VxLAN, когда терялся самый первый пакет, добавили поддержку Google's Compute Engine, добавили возможность создавать несколько сетей, и добавили интересную возможность клиент-серверного режима работы. В версии 0.5.1 добавили socket activation для клиент-серверного режима. В версии 0.5.2 добавили возможность работы за NAT. А в недавно вышедшей версии 0.5.3 его полностью привели к пока еще секретному стандарту CNI, о котором мы вам по секрету-же уже сообщили.

В компании Docker Inc тоже решили поработать над своими сетевыми проблемами, и в начале лета анонсировали SDN-плагин. В стотыщепятисотый раз скажем, что SDN, это уже не будущее, это настоящее. На технологию возлагаются большие надежды в сотовых сетях следующих поколений (если вы были на прошедшем Red Hat Forum 2015 в Москве, те могли слышать интересные новости во время выступления нашего товарища, Jan Wildeboer). Интересно, что компания VMware очень серьезно настроена на SDN/NFV-систему на базе OpenStack (или наоборот). Время проприетарных решений уходит, и видимо они вовремя заметили запросы на стандартное открытое решение.

С ростом интереса к SDN и сложным сетевым решениям, в полный рост стали видны проблемы производительности сети (которые возникают порой в довольно неожиданных местах). Системы должны справляться просто с диким объемом пакетов, приходящих на огромной скорости. В Red Hat работа ведется с двух сторон. Во-1 разгоняется сетевая подсистема ядра, что будет заметно даже обычным десктопным пользователям. А во-2 разгоняется весь вертикальный стек управления трафиком. Тут плюсы увидят, наверное, лишь производители и разработчики SDN-систем.

И о грустном. Из РФ эвакуировали еще один офис. Компания F5, разработчик SDN для OpenStack, о которой мы мельком упоминали, приняла решение о срочной перевозке всего томского офиса в США. Жаль, конечно. Еще на несколько специалистов в РФ меньше.

Наконец-то, GCC начал переход на Git с Subversion! Вот этого реально давно ждали!

Из других новостей - наш коллега, инженер Red Hat, Carlos O'Donell, объявил о выходе Glibc 2.22 (уже перевели на русский). К сожалению, после прочтения анонса складывается впечатление, что после Glibc 2.20, где объявили о слиянии с Eglibc (прощай, Eglibc, нам будет не хватать веселья), народ не очень желает "пиарить" процесс разработки. Непонятно, то ли subversion являлся одной из характерных черт этого закрыто-открытого процесса, но ведь и правда о новостях Glibc / GCC слышно как-то немного. На линукс-сайтах пишут по результатам пресс-релизов, а на пульсе проекта руку никто вроде бы и не держит. А новинок там навалом!

Мы периодически пишем о больших новинках базовых компонентов, например, про offloading в GCC, но нашей энергии хватает лишь на те новости, что прямо или косвенно касаются нас или сделаны нашими коллегами. Этого, конечно, мало. Мы всегда призывали участников других коммьюнити читать не только (микро)блоги, но и GitHub, списки рассылок, баг-трекеры, IRC/XMPP-чаты разработчиков - там самая движуха и "эксклюзивные" новости. Например, навскидку про Glibc / GCC за последние полгода:



Вообще, несмотря на необходимую осторожность, количество изменений в базовые компоненты не снижается, и в т.ч. в их инфраструктуру. Самым главным улучшением является удобная VCS (т.е. Git) и тестирование. В GCC тесты уже включают, в Glibc с тестированием не все так однозначно (например, почитайте транскрипт выступления нашего коллеги, бывшего инженера Red Hat, Roland McGrath). Одна из проблем тестирования базовых компонентов, таких, как ядро или Libc, это то, что они слишком уж низкоуровневые. Непросто не только написать юнит-тесты, но и тестировать установленную копию. Изолироваться тут не получается, кроме как в виртуальной машине. А там может быть непросто воспроизвести ситуацию, приводящую к ошибке (но, кстати, тем ценнее инструкции по тому, как тестировать с помощью systemtap наживую).

Ну и из изменений в Fedora - наконец-то локали в Glibc будут упакованы отдельно (померяйте размер /usr/lib/locale, если кто-то сомневается, зачем это нужно). Раньше для этого, как вариант, приходилось указывать флаги для rpm где-нибудь в /etc/rpm/macros.locales. Вторая новость, это расставание Fedora с давно устаревшей библиотекой librtkaio.

И наконец, не совсем про базовые компоненты (хотя кому как) - Vim тоже перешел на GitHub (и на Git с Mercurial). Все-таки как хорошо, что Google Code закрывается!

shot0002
Пользователь Mercurial недоволен переходом GCC на Git и отказом Vim от Mercurial



"I'm sorry to everybody involved here in containers, I'm so happy that the kernel tends to be fairly far removed from all of these issues, all of the buzzwords and all the new technologies." (Linus Torvalds на прошедшем LinuxCon 2015)

Daniel Stenberg, наш хороший знакомый, с которым мы теперь регулярно видимся на FOSDEM, и инженер Mozilla Foundation, год назад добровольно установил кейлоггер на свой рабочий компьютер. Конечно, он его использовал не так, как обычно используют в Windows и Mac OS X, где с помощью кейлоггеров обворовывают и так обделенных пользователей этих проприетарных операционных систем, а для сбора статистики. И теперь он проанализировал ее и опубликовал результаты. Оказалось, что за год он сделал почти 7 миллионов нажатий, что в среднем дало почти 2000 нажатий на условный рабочий час. Но были и более плодотворные рабочие часы. Например, однажды кейлоггер насчитал 8842 нажатия в час, а это ведь за 3600 секунд, если кто не пересчитал сразу в уме! А за самый продуктивный день он сделал 63757 нажатия.

Что будем делать? Завидовать будем! И не только завидовать, но и стремиться к результатам старших товарищей!

Дружественная нам организация, One Laptop Per Child, благодаря которой Fedora одно время была самым массовым Linux-дистрибутивом, предустанавливаемым на ноутбуки (до того, как появился Chromebook) может и отошла на покой, но дело ее живет!

Вы помните, в начале прошлого года будущее OLPC представлялось скорее негативно, но люди-то, зараженные идеями компьютеризации третьего мира, остались, и вскоре появился проект Endless PC, о котором вы уже слышали. А вот на днях появился еще один проект - One Education, созданный бывшим австралийским филиалом OLPC. К сожалению, они полностью перешли на Android, и с нашей точки зрения, это ошибка. Все-таки Android больше рассчитан на потребление контента (это такой интернет-телевизор), в отличие от полноценной Linux-системы, Sugar OS, но учитывая, что их поджимали сроки, это решение вполне объяснимо. В этом смысле Endless PC выглядит поинтереснее, но пускай так.


Пусть расцветают сто цветов, пусть соперничают сто школ!

Страницы