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

featured_instrumentriy_zeus

Введение

Ты наверняка видишь современную тенденцию все, от электронной почты до приложений, хранить в Сети и объединять в облака. Спрос, как известно, рождает предложение, и в настоящее время за реализацию подобных решений взялись не только коммерческие компании, но и разработчики свободного ПО. Его спектр в данной области сейчас очень широк — от 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-сектора, например для магистральных провайдеров. Тем не менее, пока этот проект еще молодой, имеет смысл осмотреться — быть может, в нем не хватает именно твоего приложения?

Сборка OpenDaylight
Сборка OpenDaylight

OpenIoT

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

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

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

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

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

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

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

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

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

Среда разработки приложений OpenIoT
Среда разработки приложений OpenIoT

 

Составление запроса к датчикам OpenIoT
Составление запроса к датчикам OpenIoT

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 тысяч машин. Но за все это удовольствие приходится платить излишней сложностью конфигурирования, так что в общем случае проще будет купить место в каком-нибудь платном облаке, а затем по необходимости создать свое.

 

Опасный конкурент для гиганта

Как и Cloud Foundry, OpenStack является открытой облачной платформой. Но в отличие от Cloud Foundry это IaaS, иными словами, является нижележащим слоем и предоставляет базовые ресурсы для работы с данными — то есть хранилища данных, виртуальные серверы и сетевую инфраструктуру. Делаться это должно динамически, поэтому неудивительно, что первые подобные решения были проприетарными и стоили больших денег.

OpenStack появился в результате объединения усилий NASA и Rackspace и в настоящее время имеет следующие возможности:

  • возможность наличия более чем одного арендатора облака (Multi-Tenancy). Это, в свою очередь, предполагает развитые средства логирования, биллинга и удобный веб-интерфейс;
  • масштабируемость — опять же это неотъемлемая часть любой облачной инфраструктуры;
  • поддержка множества систем хранения данных — iSCSI, AOE, SAN…;
  • в качестве бэкенда могут использоваться такие гипервизоры и технологии, как Xen, KVM, VMware/ESX и даже LXC.

OpenStack как IaaS не уступает, на мой взгляд, решению от той же Amazon. Отличается же он от последнего тем, что облако можно при желании развернуть и в своей фирме.

 

Полезные ссылки

Документация по Cloud Foundry: docs.cloudfoundry.com

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.

Установка Ansible
Установка 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-сети передачи голоса и видео — это можно только приветствовать.

Qt GUI для Tox
Qt GUI для Tox

 

Еще один графический интерфейс для Tox. Выглядит симпатичнее, чем первый
Еще один графический интерфейс для Tox. Выглядит симпатичнее, чем первый
 

Соединяя лучшее

В статье уже был дан обзор одного из средств управления конфигурацией. Rudder же, помимо собственно средства управления конфигурацией (основанного, к слову, на CFEngine), включает в себя еще и средство инвентаризации, которое, в свою очередь, основано на Fusion Inventory. Основные особенности Rudder таковы:

  • веб-интерфейс для настройки и управления узлами и их конфигурацией;
  • поддержка отчетов как на основе какой-либо роли, так и для конкретного узла;
  • поддержка как декларативного стиля описания конфигурации (удобен для неопытных пользователей, они указывают в веб-интерфейсе, что именно они хотят видеть, и Rudder сам все это делает), так и императивного — для администраторов, которые хотят управлять тем, как именно происходит конфигурирование.

Поскольку основан он на CFEngine, на узлах нужно ставить агента. Веб-интерфейс написан на Scala с использованием фреймворка Lift.

Заключение

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

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

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

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

1 комментарий

  1. 18.07.2014 at 14:35

    «Одно из возможных решений этой проблемы заключается в использовании открытого ПО»

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

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

Оставить мнение

Check Also

Как работает Linux: от нажатия кнопки включения до рабочего стола

Лучший способ понять, как работает операционная система, — это проследить поэтапно ее загр…