| Новые программы oszone.net |  |
Бродя в наши дни по магазину электроники с большим выбором, вы найдете удивительное множество «вещей», способных подключаться к сети. Не думайте только о телефонах, планшетах, ноутбуках, настольных компьютерах или телевизорах, проигрывателях Blu-ray и приставках. Вспомните о кофеварках, холодильниках, фоторамках, системах дистанционного открытия дверей гаража, системах кондиционирования воздуха и системах аварийной сигнализации. Если вы заглянете за декоративные панели в своем офисном здании, то обнаружите датчики температуры, влажности, движения (колебаний), камеры видеонаблюдения и множество других видов датчиков или контрольных переключателей внутри оборудования. Многие из этих устройств генерируют полезные данные: показания температуры, количество приготовленных чашек кофе и т. д. А инфракрасные датчики показывают, что в конференц-зале никого нет, поэтому освещение в нем можно выключить. Легко представить сценарий, где вам нужно еще и загружать некие данные в «вещь», например для передачи последних снимков ваших детей (или домашних питомцев) в фоторамку, которая стоит на серванте бабушки, или такую ситуацию, когда вы хотите переключать какой-то включатель дистанционно (даже если под «дистанционно» подразумевается ваш телефон, подключенный к сети 3G/4G), чтобы немного поднять температуру в доме. С точки зрения сетей, вы должны преодолеть три мира, но с точки зрения потребителя нет никакой значимой разницы между щелчком переключателя непосредственно в доме и из машины на обратном пути из аэропорта после двухнедельного отпуска. Легко представить сценарий, где вам нужно еще и загружать некие данные в «вещь». Возможности, связанные с подключенными устройствами, просто колоссальны. Предоставление сервисов для специализированных устройств может на самом деле принести дальновидным разработчикам для облака куда больше прибыли, чем приложения для универсальных устройств с дисплеями, например телефонов, планшетов или ПК многих форм-факторов. Это особенно верно, когда вы комбинируете такие сервисы с облачными технологиями, появляющимися для анализа «больших данных». СценарийДля обсуждения архитектуры допустим, что у нас имеется предложение Software as a Service (SaaS) для кондиционеров воздуха. Хотя этот сценарий вымышленный, равно как и все приводимые цифры, шаблоны и масштабы довольно близки к реальным сценариям, которые группа Windows Azure обсуждает с партнерами и заказчиками. Что хорошо в кондиционерах воздуха (с точки зрения бизнеса), так это высокий спрос на них, а из-за изменений в глобальном климате они явно не выйдут из моды даже в долгосрочной перспективе. Менее приятное качество кондиционеров заключается в том, что они крайне энергоемкие и могут вызвать перегрузку электрической сети в более горячих регионах, что приведет к перепадам напряжения и даже веерному отключению потребителей. Решение SaaS, для которого я обрисую архитектуру, предназначено энергетическим компаниям, которым необходим анализ использования кондиционеров с целью управления мощностями и механизм, позволяющий вносить широкие изменения в системы кондиционирования воздуха в их электросетях, когда эти сети находятся на грани коллапса. Клиенты наверняка предпочтут температуру в комнатах на более-менее приемлемом уровне 27°, а не полное отключение электросети, которое оставит их наедине с уличной температурой под 38°. Также допустим, что SaaS будет связано с рядом производителей кондиционеров, которые интегрируют в них соответствующее оборудование и протоколы. Как только устройства установлены и подключены к сервису, через магазины мобильных приложений появятся возможности продажи сопутствующих программ от энергокомпаний или производителей кондиционеров, позволяющих клиентам вести мониторинг своих кондиционеров и управлять ими со смартфонов или планшетов. Общая схема этого сценария показана на рис. 1.
Проектируя решение, вы должны учесть два основных вида трафика сообщений относительно облака: входящий (для сбора показаний и событий от устройств, агрегации данных и последующей передачи в систему анализа) и исходящий (для отправки управляющих команд устройствам). Каждое устройство кондиционирования должно уметь посылать показания влажности, температуры и состояния устройства через каждые 10–60 минут в зависимости от требований. Изменения в состоянии устройства также должны вызывать события, передаваемые в облако. Управляющие команды будут поступать гораздо реже, вероятно, не чаще одного-двух событий в день на каждое устройство. На первый год будем планировать обработку 250 000 устройств с увеличением до 2,5 миллионов к началу третьего года эксплуатации сервиса. При таких масштабах вы можете ожидать 0,25–1,5 миллиона событий в час в течение первого года и примерно 2,5–15 миллионов событий в часть к третьему году. Создание архитектуры решенияВ архитектуре нужно уделить внимание трем основным областям: подготовке (provisioning), приему событий (event fan-in) и выдаче команд (command fan-out). Подготовка Это установка и настройка новых устройств, присваивание им уникальной в рамках системы идентификации и предоставление каждому устройству какого-либо способа доказывать эту идентификацию. Более того, устройства должны быть сопоставлены с конкретными ресурсами в системе и должны принимать конфигурационный документ, содержащий всю эту информацию. Прием событий Требует проектирования такой системы, чтобы она могла обрабатывать необходимый поток событий. Цифра в 15 миллионов событий в час примерно соответствует 4200 событиям в секунду, что лишний раз подтверждает, насколько тщательно нужно подумать о правильном разделении системы. Это особенно важно, когда эти события исходят из 4200 разных источников, а каждый клиент подключен удаленно и устанавливает новый сеанс с потенциально значительными сетевыми задержками. Поскольку события и получаемая статистика от каждой жилищной единицы имеют значения не только на макроуровне, но и для жителей, которые приобретают мобильное приложение и хотят видеть точные графики тенденций, вы должны не просто передавать собранные данные для анализа, а еще и продумать, как хранить 360 миллионов событий в сутки. Выдача команд Передача команд устройствам. Команды указывают устройству изменить свою конфигурацию или запрашивают состояние, заставляя устройство сгенерировать событие, связанное с состоянием. В случаях, где энергокомпании приходится заниматься всесторонним регулированием, чтобы ослабить нагрузку на сеть, она, вероятно, предпочтет посылать единственную команду всем устройствам сразу и как можно быстрее. В случае мобильного телефона, когда житель хочет подстроить температуру под комфортное значение, команда адресуется конкретному устройству или всем устройствам в жилищной единице. В архитектуре нужно уделить внимание трем основным областям: подготовке, приему событий и выдаче команд. Прием событийРисунок 2 иллюстрирует общую схему модели приема событий в сценарии с системами кондиционирования воздуха.
Первый и наиболее очевидный аспект архитектуры — наличие разделов. Вместо анализа всей популяции подключенных устройств как единого целого вы разбиваете ее на гораздо меньшие (а значит, и более управляемые) разделы, каждый из которых охватывает по несколько тысяч устройств. Но управляемость — не единственная причина для введения разделов. Во-первых, каждый ресурс в распределенной системе имеет свой потолок по пропускной способности и емкости хранилища. Следовательно, вы захотите ограничить количество устройств, сопоставленных с одним Service Bus Topic, чтобы события, посылаемые устройствами, не превысили пропускную способность этого Topic, а любой массив сообщений, который может временно формироваться, не превысил емкость его хранилища. Во-вторых, вам нужно выделить соответствующие вычислительные ресурсы, и в этом случае вы также не захотите платить лишнее за серверное хранилище из-за слишком большого количества записей. В итоге вы должны объединить сравнительно небольшой набор ресурсов с приемлемыми и хорошо известными характеристиками производительности в автономную и максимально изолированную «единицу масштаба» («scale-unit»).” Каждая единица масштаба поддерживает максимальное количество устройств — это важно для уменьшения рисков при наращивании масштаба. Положительный побочный эффект введения единиц масштаба заключается в том, что они значительно сокращают риск перебоев всей системы. Если система зависит от единственного хранилища данных и это хранилище имеет проблемы с доступностью, пострадает вся система. Но если вместо этого система состоит из десяти единиц масштаба, каждая из которых поддерживает независимое хранилище, внезапный перебой с доступом к одному из хранилищ повредит лишь десятой доле системы. Архитектурное решение на рис. 2 заключается в том, что устройства сбрасывают все свои события в Windows Azure Service Bus Topics, а не в сам сервис. Windows Azure Service Bus изначально предоставляет горизонтально масштабируемый и защищенный шлюз сетевого сервиса для обмена сообщениями, и эту функциональность имеет смысл использовать по возможности всегда. Конкретно в этом сценарии мы исходим из того, что устройства способны поддерживать HTTPS и поэтому могут напрямую взаимодействовать с Windows Azure Service Bus в рамках существующей поддержки протоколов. Однако, чем дешевле и меньше устройство (с памятью на уровне нескольких килобайт и медленным процессором), тем проблематичнее становится поддержка SSL и HTTPS — даже HTTP может оказаться не по силам таким устройствам. В таких случаях хорошей идеей будет создание и выполнение пользовательского сетевого шлюза (см. справа внизу на рис. 2) с нужным протоколом. Каждый Ingestion Topic (Topic приема) конфигурируется с тремя подписками. Первая подписка предназначена для записи принятого события в хранилище событий, вторая — для компонента агрегации, который объединяет события и пересылает их в систему глобальной статистики, а третья — для отправки сообщений в систему управления устройствами. Положительный побочный эффект введения единиц масштаба заключается в том, что они значительно сокращают риск перебоев всей системы. Как потолок пропускной способности для каждого из этих Topic примем в среднем 100 сообщений в секунду на уровне сущностей (entity level). Если вы создаете и пересылаете три копии каждого переданного события, то можете принять в каждый Topic максимум 33 сообщения в секунду. Очевидно, что это число шокирующе мало. Причина столь большой осторожности в том, что вы имеете дело с распределенными устройствами, которые посылают сообщения один раз в час, и было бы несколько наивно предполагать, что передача сообщений будет идеально распределяться на протяжении каждого часа. Если исходить из худшего сценария с десятиминутным интервалом между событиями и одним дополнительным управляющим сообщением на каждое устройство в час, то можно ожидать семь сообщений ежечасно от каждого устройства, а значит (немного округлив значения), вы сможете подключить к каждому Topic примерно 50 000 устройств. Хотя при такой частоте потока за пропускную способность можно не беспокоиться, емкость хранилища и управляемость хранилища событий вызывают озабоченность. Данные в событии от каждого устройства при разрешении в один час для 50 000 устройств выливаются где-то в 438 миллионов записей событий в год. Даже если вы максимально сжимаете эти записи и используете, скажем, всего 50 байтов на запись, т овсе равно имеете дело с 22 Гб полезных данных ежегодно от каждой единицы масштаба. Это еще поддается управлению, но заставляет следить за емкостью хранилища и думать о ее наращивании, если вы предполагаете увеличить размер единицы масштаба. Для хранения событий лучше всего подходит Windows Azure Table Storage. Исходя из темпов ежегодного расширения, вам понадобятся пять таких единиц масштаба в течение первого года и 50 после третьего. Хранение, получение и агрегация событийТеперь подробнее рассмотрим, как будут обрабатываться и использоваться входящие события. Для иллюстрации я выделю и увеличу одну из единиц масштаба (рис. 3).
Сообщения, поступающие от устройств, можно разделить на две широкие категории: управляющие ответы (control replies) и события. Управляющие ответы фильтруются подпиской для управляющей системы. События, содержащие текущее состояние устройства и показания датчиков, направляются компоненту записи в хранилище и агрегатору через раздельные подписки. Задача компонента записи в хранилище — принять событие от подписки и записать его в хранилище событий. Для хранения событий лучше всего подходит Windows Azure Table Storage. Для поддержки модели с разбиением на разделы учетная запись хранилища будет совместно использоваться всеми разделами в системе и предусматривать одну таблицу на каждый раздел. Хранилище таблиц требует ключ раздела для создания записей данных в разделе хранилища, и вы будете использовать в качестве этого ключа идентификатор устройства, что обеспечивает приличную скорость поиска при необходимости выборки исторической статистики с целью построения графиков. В качестве ключа записи просто используйте временную метку, закодированную в строку в компактном формате «YYYYMMDDHHMMSS»; это позволяет выполнять сортировку в хронологическом порядке и обслуживать запросы диапазонов для построения графиков. Кроме того, поскольку в данном случае индивидуальные устройства никогда не будут посылать события с интервалами менее секунды, вам не придется беспокоиться о потенциальных конфликтах. Временная метка будет создаваться на основе значения свойства EnqueuedTimeUtc сообщения, которое автоматически записывается брокером Windows Azure Service Bus в каждое входящее сообщение, так что вам не понадобится полагаться на часы устройства. Если бы вы создавали высокопроизводительное решение, где были бы возможны конфликты, то могли бы дополнительно использовать свойство SequenceNumber сообщения, которое представляет собой уникальный последовательный 64-битный идентификатор, проставляемый брокером в каждом сообщении. Задача агрегатора — принимать входящие события и пакетировать их для последующей пересылки одному из общесистемных Statistics Topic, которые обеспечивают передачу данных в аналитическую инфраструктуру. Это зачастую осуществляется вычислением средних значений или сумм по набору событий за определенное время, так что пересылаются только вычисленные значения. В данном случае вас могут интересовать тенденции в расходе электроэнергии и показаниях температуры для каждого квартала с разрешением в 15 минут. Таким образом, агрегатор, выполняемый в двух веб-ролях, каждая из которых видит примерно половину данных, будет поддерживать сопоставление устройств с домами и кварталами, агрегировать данные в пакеты (корзины) для каждого квартала (neighborhood) по мере поступления событий и генерировать событие с вычисленными сводными показателями (computed aggregates) каждые 15 минут. Так как каждый экземпляр агрегатора видит лишь половину событий, аналитическим средствам, поддерживающим Statistics Topic, вероятно, потребуется выполнять заключительное объединение двух частей, чтобы получить полную картину для квартала. Первая статья в «MSDN Magazine» из этой серии «Building the Internet of Things» (msdn.microsoft.com/magazine/hh852591) посвящена использованию Microsoft StreamInsight в контексте устройств. Это отличная иллюстрация этапа агрегирования; пример, описанный в той статье, можно было бы задействовать в качестве агрегатора в данной архитектуре. Выдача команд, адресация и сбор ответовКак показано на рис. 4, управляющая система (Control System) будет посылать команды в Topic, а устройства будут принимать сообщения от подписок для получения команд.
Главный аргумент за использование подписки на устройство — надежность. Когда вы посылаете некую команду, вы хотите, чтобы она дошла до устройства, даже если в данный момент это устройство выключено или не подсоединено к сети. Значит, вам нужен для устройства эквивалент почтового ящика. Расплата за дополнительную надежность и гибкость — некоторое усложнение. Потолок пропускной способности для каждой сущности также проявляется в количестве подписок, допускаемых Windows Azure Service Bus для каждого Topic; в настоящее время лимит системы для одного Topic — 2000 подписок. Сколько подписок вы реально создадите в каждом Topic для выдачи команд, зависит от требуемой частоты передач данных. Фильтрацию и выбор сообщения в подписку можно рассматривать как операцию копирования. Поэтому частота передач данных в Topic с 1000 подписок будет составлять одно сообщение в секунду, если исходить из пропускной способности каждой сущности на уровне 1000 сообщений в секунду. В случае аварийных команд вам нужно широковещательно посылать одну команду всем подключенным устройствам. В случае адресных команд (targeted commands), где потребитель регулирует температуру с помощью конкретного устройства или в конкретном доме через приложение, подключенной к сети 3G, операция регулировки должна выполняться в течение нескольких секунд. Чтобы выяснить, годится ли одно сообщение в секунду и для адресных команд, допустим, что житель будет настраивать или запрашивать текущее состояние системы кондиционирования воздуха очень редко. Вы должны исходить из того, что большинство команд будет выдаваться при значительных погодных аномалиях. Займем пессимистическую позицию и будем считать, что каждое устройство настраивается раз в день и что эти регулировки обычно происходят между 7-00 и 17-00. Если в случае широковещательной рассылки команд вы предположили лимит в 1000 подписок для Topic, это приведет к передаче 1,4 сообщений в минуту. Даже если все включили бы свои кондиционеры в течение одного часа, у вас все было бы нормально, и вы получали бы около 16 сообщений в минуту. В результате этих соображений по масштабированию и пропускной способности ограничим каждый Fan-Out Topic до 1000 подписок, т. е. вам понадобятся 50 таких Topic на каждую единицу масштаба. Вы можете адресовать сообщения конкретным устройствам или жилищным единицам либо посылать широковещательное сообщение всем устройствам, используя фильтры подписки. Рис. 5 иллюстрирует простой фильтр, который пропускает сообщения, если в них либо есть свойство с конкретным DeviceId или HousingUnit, либо имеется собственное свойство Broadcast, установленное в true. Если любое из этих условий истинно, сообщение отбирается для подписки. Таким образом, управляющая система может использовать один и тот же Topic для широковещательных и адресных сообщений и выбирать адресаты заданием соответствующих свойств маршрутизации в сообщении.
Управляющая система также может отвечать на команды через свою подписку на принимающей стороне (fan-in side), но такие ответы проходят через специальный фильтр, и свойства в них обрабатываются аналогично. Построение новой единицы масштаба в конечном счете осуществляется скриптом управления (через Windows Azure Service Bus API), который создает новую структуру этой формы. Структура пространства имен, подготовка и идентификации устройствВ Windows Azure Service Bus используется концепция пространств имен для организации ресурсов и управления доступом к этим ресурсам. Пространства имен создаются через Windows Azure Portal и сопоставляются с конкретным региональным информационным центром. Если ваше решение охватывает несколько крупных географических регионов, вы можете создать несколько пространств имен, а затем закрепить ресурсы и клиенты за конкретным информационным центром Windows Azure, получив очевидный выигрыш за счет более коротких сетевых маршрутов. Для данного решения я мог бы создать пространство имен в регионе North/Central U.S. (clemensv-ac-ncus-prod.servicebus.windows.net) и еще одно в регионе South/Central U.S. (clemensv-ac-scus-prod) или же создать пространства имен для конкретных клиентов энергетической компании (clemensv-ac-myenergy-prod). Суффикс «prod» позволяет отличать производственные пространства имен от возможных параллельных тестовых или промежуточных пространств имен. Чтобы упростить настройку и управление единицами масштаба, используйте иерархическую структуру пространства имен. Имя единицы масштаба, образующее базовый путь для всех сущностей внутри этой единицы, может быть просто числом или сопоставлением с определенным клиентом (/myenergy-3). Поскольку у вас единственный Ingestion Topic, вы можете разместить его непосредственно на ступень ниже (/myenergy-3/fan-in), а затем поместить Fan-Out Topic в отдельный сегмент, просто нумеруя эти Topic (/myenergy-3/fan-out/01). Подписки выдачи команд (fan-out subscriptions) для индивидуальных устройств следуют той же структуре, используя идентификатор устройства в качестве имени подписки (/myenergy-3/fan-out/01/subscriptions/0123456). Построение новой единицы масштаба в конечном счете осуществляется скриптом управления (через Windows Azure Service Bus API), который создает новую структуру этой формы. Подписки для устройств и правила фильтров создаются при подготовке устройств. Конечно, вы также должны создать, развернуть и сконфигурировать соответствующие вычислительные ресурсы и ресурсы хранилища. Как уже отмечалось, для хранилища событий вы будете создавать новую таблицу на каждую единицу масштаба. Подготовка заключается в адаптации нового устройства при его установке в жилищную единицу. В этой статье я пропущу ряд деталей, таких как деактивация устройства, и просто опишу модель подготовки, в которой устройства настраиваются с использованием предустановленных на заводе уникальных идентификаторов (ID). Альтернативная модель может быть такой: с завода поступают неинициализированные устройства, и вы реализуете схему, аналогичную той, которая, возможно, известна вам по таким сервисам, как Netflix, Hulu или Twitter. В них новое устройство связывается с веб-сервисом для получения кода, а затем отображает этот код, и пользователь регистрируется на сайте активации, вводя этот код. На рис. 6 показана схема подготовки устройства, которому уже назначен идентификатор. Первый шаг в настройке устройства не приведен — он связан с подключением устройства к сети, что может осуществляться через проводной Ethernet, беспроводной Wi-Fi или некоторые другие беспроводные несущие сети.
При подготовке система запускает специальный веб-сервис, который обеспечивает настройку и управление идентификацией и конфигурацией устройства. Компонент выделения раздела (partition allocator) отслеживает, сколько устройств было активировано и к какой единице масштаба были отнесены те или иные устройства. Как только устройство сопоставлено с единицей масштаба, оно считается адаптированным в эту единицу. На этапе 1 устройство устанавливает соединение с сервисом подготовки (provisioning service), предоставляя свой идентификатор. В данной модели все выдаваемые идентификаторы устройств находятся в списке разрешений (allow list) (этап 2), который позволяет один раз активировать конкретное устройство. Как только устройство проверено и может быть активировано, сервис подготовки вызывает службу управления доступом (Access Control Service, ACS), чтобы создать новую идентификацию сервиса (service identity) и ключ для устройства (этап 3), а также создает правило разрешения Send для Ingestion Topic и правило разрешения Listen для подписки выдачи команд, создаваемой сразу после этого на этапе 4. В итоге учетная запись устройства получает только те права, которые нужны ему для взаимодействия с системой. После этапа 4 вы имеете набор URI всех ресурсов, с которыми будет взаимодействовать устройство, а также учетную запись и ключ, с помощью которых устройство может аутентифицироваться в ACS для получения маркера (token). Вся эта информация помещается в ответ на вызов активации устройства, и устройство записывает ее в долговременное хранилище конфигурации. Стоит отметить: хотя в этой статье вы познакомились с большей частью создания горизонтально-масштабируемых разделов, в приведенном здесь примере идентификации Access Control не подвергались разбиению на разделы. Чтобы исключить чрезмерную нагрузку на ACS, вы можете просто сделать так, чтобы клиент запрашивал меньшее количество маркеров. По умолчанию срок действия маркера для доверяющей стороны ACS в Windows Azure Service Bus равен 1200 секундам, или 20 минутам. Этот интервал можно увеличить до 24 часов, или 86 400 секунд. Тогда устройства будут запрашивать новые маркеры не чаще одного раза в сутки. Единственный недостаток в том, что вы не сможете аннулировать права доступа к носителю такого маркера, если он будет перехвачен, но в случае маркеров, ограниченных передачей или прослушиванием только определенных сущностей, этот риск считается допустимым. В облакеПодключение «вещей» к облаку (и через облако) — та область, которой группа Windows Azure Service Bus будет уделять значительное внимание в течение следующих нескольких лет. Архитектура, обрисованная в этой статье, рассматривается как хорошая отправная точка, и в нее заложен передовой опыт (например, концепция единиц масштаба), полученный при построении самой Windows Azure Service Bus. Здесь открывается широкий простор для оптимизаций потока сообщений, агрегации и распределения не только в терминах мощностей, но и более простых моделей программирования и конфигурирования. Вы увидите некоторые из этих оптимизаций (например, автоматическую пересылку) в Windows Azure Service Bus буквально через несколько месяцев, и группа задействует эти новые средства для создания более удобных абстракций, которые сделают сценарии с горизонтальным масштабированием (как в рассмотренном здесь примере) еще проще в управлении. Своевременное распределение событий на миллионы устройств всегда будет требовать значительного количества разнообразных системных ресурсов, но благодаря абстракциям вы сможете сократить количество видимых деталей. Чтобы сделать этот сценарий более интересным и практичным, следующая статья из этой серии поможет вам построить свой кондиционер воздуха (да-да, оборудование!), управляемый Microsoft .NET Micro Framework. Этот небольшой самодельный кондиционер будет взаимодействовать с сервисом через Windows Azure Service Bus, а его архитектура будет следовать универсальным концепциям, о которых шла речь здесь. До встречи.
Теги:
Windows Azure.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
