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

Введение

Ты наверняка видишь современную тенденцию все, от электронной почты до приложений, хранить в Сети и объединять в облака. Спрос, как известно, рождает предложение, и в настоящее время за реализацию подобных решений взялись не только коммерческие компании, но и разработчики свободного ПО. Его спектр в данной области сейчас очень широк — от PaaS-фреймворков и средств автоматизации развертывания групп систем до средств обеспечения приватности сетевого общения. Мы решили сделать обзор наиболее понравившихся проектов, так или иначе связанных с современными веяниями.

OpenDaylight

Ранее (да и по большому счету сейчас) сетевое оборудование управлялось нецентрализовано — все настройки прописывались индивидуально для каждого шлюза/свича. И это устраивало почти всех. Однако с появлением новых облачных технологий потребности изменились и понадобились новые идеи по организации управления сетями. Одной из таких идей стала SDN (Software Defined Networking). Заключается идея в том, что в сети, построенной на ее основе, управление сетью отделено от устройств передачи данных, что добавляет еще один уровень абстракции.

На базе этой идеи была разработана еще одна — NFV (Network Functions Virtualization), которая тесно пересекается с идеей SDN, причем настолько, что, подозреваю, можно будет перефразировать стихи Маяковского про Ленина и партию. NFV позволяет виртуализировать отдельные сетевые функции, которые ранее можно было реализовать только физически, — например, брандмауэр или IDS. То есть физически ты можешь находиться в Питере, а брандмауэр — вообще за океаном.

И тут мы плавно переходим к OpenDaylight. Он представляет собой платформу для организации работы этих технологий. Строго говоря, это не готовое решение, а фреймворк, на основе которого заинтересованные компании и разработчики могут строить свои продукты для SDN-сетей. Прежде чем описывать OpenDaylight дальше, нужно получить некоторое представление о структуре таких сетей. Условно можно разделить SDN-сеть на три уровня:

• На самом верхнем уровне находятся приложения, которые отвечают за сетевую и бизнес-логику и контролируют/мониторят поведение сети. Более сложные решения еще и сочетают облачные и NFV-приложения, а также проектируют сетевой трафик в соответствии с требованиями этих приложений.
• Второй уровень собственно и является слоем абстракции — на нем и происходит разделение управления сетью и передачи данных.
• Ну и наконец, последний уровень — уровень устройств передачи данных. Отмечу, что эти устройства могут быть как физическими, так и виртуальными.

OpenDaylight концентрируется на втором уровне SDN-сети и предоставляет набор RESTful API и OSGi-фреймворк для приложений верхнего уровня («северный интерфейс»), реализуя при этом C&C-протоколы для устройств передачи данных, такие как OpenFlow, BGP и SNMP («южный интерфейс»). Кроме этого, в нем реализованы различные диспетчеры — от диспетчера топологии до диспетчера переадресации трафика.

Ядро OpenDaylight написано на Java, следовательно, может работать на любой системе, где имеется JVM. Кроме того, фреймворк этот крайне гибкий и модульный, что позволяет использовать только те возможности, которые необходимы для конкретной сети.

В целом это довольно перспективное направление, которое, однако, имеет смысл лишь для крупного Enterprise-сектора, например для магистральных провайдеров. Тем не менее, пока этот проект еще молодой, имеет смысл осмотреться — быть может, в нем не хватает именно твоего приложения?

Другие статьи в выпуске:

Хакер #182. Все о Bitcoin

• Содержание выпуска
• Подписка на «Хакер»-60%

OpenIoT

Прежде чем рассказывать об этой платформе, стоит рассказать о том, что такое Internet of Things. Скажу сразу, что устоявшийся русскоязычный перевод этого понятия мне не очень нравится, — между словами «интернет вещей» так и хочется поставить дефис: кажется, что это родительный падеж слова «интернет-вещи». Поэтому в дальнейшем я буду использовать либо оригинальный англоязычный термин, либо «Сеть вещей».

Что такое сеть, вроде бы более-менее ясно, а вот под вещами здесь подразумеваются самые разные сущности — от колбасы с наклеенным RFID-чипом и умного холодильника до города (последний, впрочем, не является вещью в общепринятом смысле; тем не менее трамвай с GPS/ГЛОНАСС — часть города, и от него можно получить информацию).

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

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

Архитектуру OpenIoT условно можно разделить на три уровня:

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

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

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

Проект этот, как и само понятие Сети вещей, представляется интересным — однако навевает мысли об «Анклавах» Вадима Панова и не вышедшей еще игре от известного издателя. От всеобщего контроля, который и не снился лидерам тоталитарных государств, его отделяет почти незаметная грань. Но если Сеть вещей неизбежна, то открытая платформа выглядит гораздо более предпочтительно, нежели проприетарная, — вероятность перехода этой грани в данном случае кажется ниже.

Cloud Foundry

Cloud Foundry — открытая облачная PaaS-платформа от VMware, по большей части написанная на Ruby. Для начала вспомним, что такое PaaS. PaaS — своего рода фреймворк и инфраструктура для создания масштабируемых приложений любого уровня. Как правило, доступ к подобной инфраструктуре платный, и внутренности ее спрятаны где-то в глубинах дата-центров разработавшей ее компании. Соответственно, развертывание ее на собственных серверах невозможно.

Однако недаром в первом предложении прозвучало слово «открытая». Да, VMware одной из первых открыла свою облачную платформу, опубликовав ее исходники под Apache License 2.0. Таким образом, развертывание своего PaaS-облака стало доступным и для простых смертных.

Перейду к описанию архитектуры.

• Центральной частью Cloud Foundry является Cloud Controller, который управляет всеми модулями и хранит информацию о пользователях, сервисах и приложениях. Также он контролирует предоставляемые услуги. И да, он имеет как CLI, так и REST API.
• Помимо Cloud Controller, существует еще Health Manager. Он регулярно сравнивает текущую информацию, получаемую от специальных агентов (которые, к слову, отвечают еще и за изоляцию приложений), с желаемым состоянием, предоставляемым Cloud Controller, и, если обнаруживает какое-либо некорректное состояние, уведомляет центральную часть о сбое.
• Непосредственно за маршрутизацию запросов к приложениям отвечает Router. Помимо этого, он еще и распределяет нагрузку.
• За состояние той или иной службы (к примеру, СУБД) отвечает Service Gateway, а за запуск — Service Nodes.

Особенности данной облачной платформы — во-первых, не существует единственной точки, повреждение состояния которой могло бы привести к падению всей инфраструктуры. Во-вторых, поддерживается горизонтальное масштабирование. В-третьих, VMware добилась от Rails, на базе которого в основном и построено ядро Cloud Foundry, асинхронности. В-четвертых, несмотря на то что написана платформа на Ruby, в качестве средств для написания приложений могут использоваться самые разные языки и фреймворки — от Scala до Node.js. Это достигается путем создания языково-независимой системы коммуникаций.

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

Serverspec

Но перейдем от высоких материй к делам более предметным, а именно к serverspec. Данный проект предназначен для удобного тестирования работоспособности серверов. В качестве своеобразного языка для написания тестов используется RSpec. Удобен serverspec тем, что на тестируемом компьютере не требуется ставить никакого агента/бэкенда — все делается через SSH. Не буду здесь расписывать все его преимущества — проще всего привести пример spec-файла (httpd_spec.rb) для тестирования веб-сервера:

require 'spec_helper'

describe package('httpd') do
    it { should be_installed }
end

describe service('httpd') do
    it { should be_enabled }
    it { should be_running }
end

describe port(80) do
    it { should be_listening }
end

describe file('/etc/httpd/conf/httpd.conf') do
    it { should be_file }
    it { should contain "ServerName example" }
end

Как видно, язык написания тестов довольно простой, а в качестве базового языка программирования используется Ruby, то есть для установки (в случае наличия Ruby Gems) достаточно набрать следующую команду:

$ gem install serverspec

Приведу список интересных ресурсов для тестов и некоторые проверки, которые можно над ними производить:

• process — какой-либо процесс; параметры проверок, за исключением be_running, соответствуют параметрам, доступным в команде ps;
• user — какой-либо пользователь; можно проверять наличие (exist), принадлежность группе (belongtogroup), наличие указанных uid (haveuid), домашнего каталога (havehomedirectory) и login shell (havelogin_shell);
• command — результат выполнения заданной команды; можно проверять stdout, stderr и код возврата (returnstdout, returnstderr и returnexitstatus соответственно);
• zfs — файловая система ZFS; единственная стоящая проверка — have_property, показывает, соответствует ли заданный пул указанным свойствам.

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

Ansible

А этот проект предназначен для управления конфигурацией нескольких серверов. Он аналогичен Puppet и Chef, но написан на Python и имеет следующие особенности:

• Не требуется ставить агент на управляемых серверах — они управляются по SSH; при этом есть выбор: либо использовать реализацию SSH на Python, Paramiko, либо же использовать стандартный SSH. Также есть возможность ускоренного режима для больших групп серверов.
• Может быть запущен (почти) без конфигов, просто с заданием команды, к примеру для обновления:$ ansible webservers -a "/usr/bin/yum update" -k

Эта команда запустит обновление для группы webservers, используя на удаленных хостах sudo. Если же нужно выполнять более сложные задачи, то Ansible поддерживает конфигурацию в формате YAML. Файлы конфигурации называются Playbooks, и в них допустимо использование шаблонов, что позволяет расширять функциональность. * Доступны модули для самых разных систем, в том числе и облачных инфраструктур (например, Amazon EC2, OpenStack и RackSpace). Также можно писать модули практически на любом языке программирования — главное, чтобы вывод этих модулей был в формате JSON.

Опишу чуть подробнее структуру конфигурационных файлов. Как уже отмечалось, конфигурация хранится в плейбуках. Раньше там же хранились и задачи, но сейчас добавили новый слой абстракции — «роли». Роль же — набор задач, шаблонов, триггеров и переменных. Роль может включать и другие роли. Задачи, в свою очередь, самый нижний слой абстракции. Типичная задача выглядит так (файл main.yml):

- name: installing net tools
  apt: pkg=$item
  with_items:
    - htop
    - iftop
    - tcpdump
    - wget

Первая строчка — описание задачи, вторая — модуль с параметрами. В списке объектов, если параметров модуля много, можно использовать и хеши.

Это средство конфигурирования и развертывания выглядит гораздо проще, чем аналоги, так что для сетей среднего размера лучше использовать именно его. Но для динамичной и гетерогенной среды лучше обратиться к Chef.

Чтобы получить Ansible, используй Git-репозиторий https://github.com/ansible/ansible либо, в случае с Ubuntu, PPA rquillo/ansible.

Tox

Попыток разработать альтернативу Skype было много. Tox — одна из них и кажется достаточно перспективной, несмотря на то что находится на ранней стадии разработки. Архитектурно его протокол похож на BitTorrent, с некоторыми, конечно, усовершенствованиями. Но стоит рассмотреть его подробнее:

• В качестве средства внутрисетевой адресации используется упрощенный DHT с шифрованием. В качестве алгоритма шифрования используется Curve25519, основанный на эллиптических кривых. Каждому узлу выделяется два адреса: первый адрес, являющийся идентификатором узла (32 байта), и второй, тоже 32 байта, являющийся также и открытым ключом для шифрования сессии.
• Шифрованное соединение происходит поверх протокола Lossless UDP. Замечу, что на данный момент шифруются, по-видимому, только протокол управления сессией и текстовые сообщения — аудио и видео будут идти по другому протоколу.

Что до самого клиента, то имеется как бэкенд (ProjectTox-Core), так и несколько фронтендов, причем есть не только графические, но и консольные. На данный момент фронтенды для Tox могут работать на Linux, Windows, OS X и iOS. GUI в Linux существует и на Qt (Qt GUI и ToxQML), и на Vala/GTK+ (Venom).

Проект выглядит достаточно интересным. Однако не стоит забывать, что на данный момент (около полугода разработки) он все еще очень сырой. Так, передача звука и видео находится в зачаточном состоянии — а ведь он разрабатывается как альтернатива Skype. Кроме того, добавлять пользователей путем добавления их ключей достаточно неудобно; впрочем, в дополнение к этой системе планируется создать более удобную — децентрализованные серверы ключей.

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

Таким образом, приходится признать, что к «производственному» применению в качестве альтернативы всем известного аудио- и видеомессенджера Tox еще не готов. Но если есть желание поучаствовать в разработке и тестировании открытой P2P-сети передачи голоса и видео — это можно только приветствовать.

Заключение

Современные сетевые технологии напоминают известную басню дедушки Крылова. С одной стороны, внедрение облачных инфраструктур не может не сказаться на приватности данных — кто гарантирует, что администраторы облака не могут посмотреть данные, которые пользователи хранят в нем? С другой — PRISM-истерия породила повальное распространение криптографии, клятвенных заявлений со стороны крупных компаний, что за пользователями они не следят, и попытки гиков внедрить в массы анонимайзеры наподобие Tor.

Одно из возможных решений этой проблемы заключается в использовании открытого ПО. Если, например, платформа для создания Сети вещей будет открыта, то в идеале любой человек, обладающий соответствующими знаниями и навыками, сможет убедиться, что без его ведома никто не отключит в его доме свет, а если это не так — написать соответствующее исправление. То же самое относится и к различным видам сетевого общения.

К сожалению, большей части пользователей все равно, открытое ли ПО стоит у них на компьютере или проприетарное, пользуются ли они открытой облачной инфраструктурой (если они вообще в курсе, что это такое). Но даже те, кому это не все равно, не всегда имеют нужные знания для того, чтобы в этом убедиться, — особенно это касается криптографических алгоритмов.

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