Архитектурное проектирование связано с выбором стратегии решений и модуляризацией системы. Стратегия решения призвана разрешить проблемы, связанные с построением клиентской и серверной частей системы, а ПО промежуточного слоя (middleware) необ­ходимо для "склеивания" клиента и сервера. Решение по основным строительным блокам (модулям) только отчасти зависит от выбранной стратегии решения.

Клиент и сервер - логические понятия. Клиент (client) - это вычислительный процесс, который осуществляет запросы к процессу сервера. Сервер (server) - это вы­числительный процесс, который обслуживает запросы сервера. Обычно процессы клиента и сервера выполняются на разных компьютерах, но вполне возможно реали­зовать систему клиент/сервер на одной машине.

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

Архитектуру клиент/сервер можно расширить для представления произвольной распределенной системы. Любой компьютерный узел с базой данных может играть роль клиента в одних деловых операциях, а сервер - в других операциях. Соединение подобных узлов с помощью сети связи дает начало архитектуре системы распределенной обработки, как показано на рис. 5.

Рис. 5 Архитектура системы распределенной обработки

В системе распределенной обработки клиент может осуществлять доступ к любому количеству серверов. Однако клиенту может быть разрешен доступ одновременно только к одному серверу. Это значит, что он может быть не в состоянии объединить данные от двух или более серверов баз данных в одном запросе. Если это возможно, то архитектура поддерживает систему распределенных баз данных.

Трехзвенная архитектура

Аналогично клиентскому и серверному процессу прикладной процесс представляет со­бой логическое понятие, которое может поддерживаться или не поддерживаться спе­циально выделенным для этой цели аппаратным обеспечением. Логика приложения может с равным успехом выполняться на клиентском или серверном узле, т.е. может быть встроена в клиентский или серверный процесс и реализована в виде библиотеки DLL (Dynamic Link Library- динамически компонуемая библиотека), API-интерфейса (Application Programming Interface - интерфейс прикладного программирования), RPC-вызовов (Remote Procedure Calls - удаленный вызов процедуры) и т.д.

Если логика приложения скомпилирована с клиентом, говорят об архитектуре тол­стого клиента (thick client architecture) ("клиент на стероидах"). Если она скомпилирована с сервером, говорят об архитектуре тонкого клиента (thin client architecture) ("клиент" "кожа да кости"). Возможны также промежуточные архитектуры, в которых логика приложения частично скомпилирована с клиентом, а частично - с сервером. Логику приложения можно также развернуть на отдельных вычислительных узлах, как показано на рис. 6.

Рис. 6 Трехзвенная архитектура

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

• Перевод

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

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs ) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости - такие, например, как согласованность (consistency ), доступность (availability ) или идемпотентность (idempotency ).

В данном посте я собираюсь рассказать про несколько концепций, которые мне потребовалось изучить и применить на практике при построении крупномасштабной высокодоступной распределённой системы платежей, которая сегодня работает в Uber. Это система с нагрузкой до нескольких тысяч запросов в секунду, в которой критическая функциональность платежей должна работать корректно даже в тех случаях, когда перестают работать отдельные части системы.

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

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.

SLA

В больших системах, которые обрабатывают миллионы событий в день, некоторые вещи просто по определению обязаны пойти не по плану. Вот почему прежде, чем погружаться в планирование системы, нужно сделать самый важный шаг - принять решение о том, что для нас означает «здоровая» система. Степень «здоровья» должна быть чем-то таким, что на самом деле можно измерить. Общепринятым способом измерения «здоровья» системы являются SLA (service level agreements ). Вот некоторые из самых распространённых видов SLA, с которыми мне доводилось сталкиваться на практике:

• Доступность (Availability) : процент времени, который сервис является работоспособным. Пусть существует искушение достичь 100% доступности, достижение этого результата может оказаться по-настоящему сложным занятием, да ещё вдобавок и весьма дорогостоящим. Даже крупные и критичные системы вроде сети карт VISA, Gmail или интернет-провайдеров не имеют 100% доступности - за годы они накопят секунды, минуты или часы, проведённые в даунтайме. Для многих систем, доступность в четыре девятки (99.99%, или примерно 50 минут даунтайма в год) считается высокой доступностью. Для того, чтобы добраться до этого уровня, придётся изрядно попотеть.
• Точность (Accuracy) : является ли допустимой потеря данных или их неточность? Если да, то какой процент является приемлимым? Для системы платежей, над которой я работал, этот показатель должен был составлять 100%, поскольку данные терять было нельзя.
• Пропускная способность/мощность (Capacity) : какую нагрузку должна выдерживать система? Этот показатель обычно выражается в запросах в секунду.
• Задержка (Latency) : за какое время система должна отвечать? За какое время должны быть обслужены 95% и 99% запросов? В подобных системах обычно многие из запросов являются «шумом», поэтому задержки p95 и p99 находят более практическое применение в реальном мире.

Почему SLA нужны при создании крупной системы платежей? Мы создаём новую систему, заменяющую существующую. Чтобы убедиться в том, что мы всё делаем правильно, и что наша новая система будет «лучше», чем её предшественница, мы использовали SLA, чтобы определить наши ожидания от неё. Доступность была одним из самых важных требований. Как только мы определили цель, нам было необходимо разобраться с компромиссами в архитектуре, чтобы достичь этих показателей.

Горизонтальное и вертикальное масштабирование

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

Горизонтальное масштабирование заключается в добавлении большего количества машин (или узлов) в систему для увеличения пропускной способности (capacity ). Горизонтальное масштабирование - это самый популярный способ масштабирования распределённых систем.

Вертикальное масштабирование - это по сути «купить машину побольше/посильнее» - (виртуальная) машина с большим числом ядер, лучшей вычислительной мощностью и большей памятью. В случае с рапределёнными системами, вертикальное масштабирование обычно менее популярно, поскольку оно может быть более дорогостоящим, чем масштабирование горизонтальное. Однако, некоторые известные большие сайты, вроде Stack Overflow, успешно масштабировались вертикально для соответствия нагрузке.

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

Согласованность (consistency)

Доступность любой из систем важна. Распределённые системы часто строятся из машин, чья доступность по отдельности ниже, чем доступность всей системы. Пусть наша цель построить систему с доступностью в 99.999% (даунтайм составляет примерно 5 минут/год). Мы используем машины/ноды, которые в среднем имеют доступность в 99.9% (они находятся в даунтайме примерно 8 часов/год). Прямым путём достижения нужного нам показателя доступности является добавление ещё нескольких таких машин/узлов в кластер. Даже если некоторые из узлов будут «в дауне», другие будут продолжать оставаться в строю и общая доступность системы будет выше, чем доступность её индивидуальных компонентов.

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

Согласованность - это концепция, на осознание которой у меня ушло больше всего времени, прежде чем я понял её и оценил по достоинству. Существует несколько видов согласованности , самым широко используемым в распределённых системах является сильная согласованность (strong consistency ), слабая согласованность (weak consistency ) и согласованность в конечном счёте (eventual consistency ). Вы можете прочитать полезный практический разбор преимуществ и недостатков каждой из моделей в данной статье . Обычно, чем слабее требуемый уровень согласованности, тем быстрее может работать система - но тем вероятнее, что она вернет не самый последний набор данных.

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

Хорошо иллюстрирует это вывод списка недавних транзакций: они могут быть реализованы при помощи согласованности в конечном счёте (eventual consistency ) - то есть, последняя транзакция может появиться в некоторых частях системы лишь некоторое время спустя, но благодаря этому запрос списка вернет результат с меньшей задержкой или потребует меньше ресурсов для выполнения.

Долговечность данных (data durability)

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

Различные распределённые базы данных имеют разные уровни долговечности данных. Некоторые из них поддерживают data durability на уровне машины/узла, другие делают это на уровне кластера, а некоторые вообще не предоставляют этой функциональности «из коробки». Некоторая форма репликации обычно используется для увеличения долговечности - если данные хранятся на нескольких узлах и один из узлов перестаёт работать, данные по-прежнему будут доступны. , поясняющая, почему достижение долговечности в распределённых системах может стать серьёзным вызовом.

Почему долговечность данных имеет значение при построении платёжной системы? Если данные являются критическими (например, это платежи), то мы не можем позволить себе терять их во многих из частей нашей системы. Распределённые хранилища данных, которые мы построили, должны были поддерживать долговечность данных на уровне кластера - так что даже если инстансы будут «падать», завершенные транзакции будут сохраняться. В наши дни, большинство распределённых сервисов хранения данных - вроде Cassandra, MongoDB, HDFS или Dynamodb - все поддерживают долговечность на различных уровнях и все могут быть сконфигурированы для предоставления долговечности уровня кластера.

Сохранность сообщений (message persistence) и долговечность (durability)

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

В случае распределенных систем, обмен сообщениями (messaging ) обычно выполняется при помощи некоторого распределенного сервиса сообщений - RabbitMQ, Kafka или других. Эти брокеры сообщений могут поддерживать (или настроены так, что станут поддерживать) различные уровни надежности доставки сообщений.

Сохранность сообщения означает, что когда на узле, обрабатывающем сообщение, происходит отказ, то сообщение по прежнему будет доступно для обработки после того, как проблема разрешится. Долговечность сообщений обычно используется на уровне очереди сообщений . При помощи долговечной очереди сообщений, если очередь (или узел) уходят в оффлайн когда сообщение отослано, оно попрежнему получит сообщение когда оно вернётся в онлайн. Хорошая подробная статья по данному вопросу доступна по ссылке .


Почему сохранность и долговечность сообщений имеют значение при построении крупных платёжных систем? У нас были сообщения, которые мы не могли позволить себе потерять - например, сообщение о том, что человек инициировал платёж по оплате поездки. Это означало, что система обмена сообщениями, которую нам предстояло использовать, должна была работать без потерь: каждое сообщение должно было быть единожды доставлено. Однако, создание системы которая доставляет каждое сообщение ровно один раз нежели хотя бы один раз - это задачи, значительно различающиеся по своей трудности. Мы решили реализовать систему обмена сообщениями, которая доставляет хотя бы единожды, и выбрали шину сообщений (messaging bus ), поверх которой мы решили её построить (мы остановили свой выбор на Kafka, создав кластер без потерь, который требовался в нашем случае).

Идемпотентность

В случае с распределёнными системами, может пойти не так всё, что угодно - соединения могут отваливаться посередине или запросы могут выпадать по тайм-ауту. Клиенты будут часто повторять эти запросы. Идемпотентная система гарантирует, что чтобы ни произошло, и сколько бы раз конкретный запрос ни выполнялся, действительное выполнение этого запроса происходишь всего один раз. Хороший пример - это осуществление платежа. Если клиент создает запрос на оплату, запрос успешен, но если клиент попадает в тайм-аут, то клиент может повторить тот же самый запрос. В случае с идемпотентной системой, с человека, производящего оплату, не будут дважды списаны деньги; а вот для не-идемпонетной системы это вполне возможное являение.

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

Существует множество способов достижения идемпотентности, и каждый конкретный выбор будет зависеть от ограничений системы и типа производимой операции. Проектирование идемпотентных подходов это достойный вызов для разработчика - достаточно взглянуть на посты Бена Надела, в которых он рассказывает о различных стратегиях, которые он использовал , которые включают в себя и распределённые блокировки, и ограничения (constraints ) базы данных. Когда вы проектируете распределённую систему, идемпотентность может легко оказаться одной из частей, которую вы упустили из своего внимания. В нашей практике мы сталкивались со случаями, в которых моя команда «погорела» на том, что не убедилась в наличии корректной идемпотентности для некоторых ключевых операций.

Почему идемпотентность имеет значение при построении крупной платёжной системы? Самое главное: для избежания двойных списаний и двойных возвратов средств. Учитывая, что наша система обмена сообщениями имеет доставку типа «хотя бы раз, без потерь», мы должны предполагать, что все сообщения могут быть доставлены несколько раз и системы должны гарантировать идемпотентность. Мы приняли решения обрабатывать это при помощи версионирования и оптимистической блокировки, где наши системы реализуют идемпотентное поведение используя строго согласованное хранилище в качестве своего источника данных.

Шардинг и кворум

Распределённые системы часто должны хранить гораздо больше данных, чем может позволить себе один отдельный узел. Так как же нам сохранить набор данных на нужном количестве машин? Самой популярной техникой для этого является шардинг . Данные горизонтально партиционируются при помощи некоего хеша, присвоенного партиции. Пусть многие распределённые базы данных сегодня реализуют шардинг у себя «под капотом», он сам по себе является интересной темой, которую стоит изучить - особенно решардинг . У Foursquare в 2010 году был 17-часовой даунтайм из-за попадания на краевой случай шардинга, после чего компания поделилась , проливающим свет на корень проблемы.

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

Почему кворум и шардинг имеют смысл при построении крупной платёжной системы в Uber? Обе эти концепции являются простыми и используются практически повсеместно. Я познакомился с ними тогда, когда мы настраивали репликацию в Cassandra. Cassandra (и другие распределённые системы) использует кворум и местный кворум (local quorum ) для того, чтобы обеспечить согласованность между кластерами.

Модель акторов

Привычный словарь, который мы используем для описания практик программирования - вещи вроде переменных, интерфейсов, вызова методов - предполагают системы из одной машины. Когда мы говорим о распределённых системах, то мы должны использовать другие подходы. Распространенным способом описания таких систем является модель акторов , в рамках который код видится нам в терминах коммуникации. Эта модель является популярной в силу того, что она совпадает с ментальной моделью того, как мы представляем себе, например, взаимодействие людей в организации. Другой, не менее популярный способ описания распределённых систем - это CSP, взаимодействующие последовательные процессы .

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

Гетерогенные мультикомпьютерные системы

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

Соединяющая их сеть также может быть сильно неоднородной.

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

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

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

Наиболее ранней и фундаментальной распределенной архитектурой является «клиент-сервер», в которой одна из сторон (клиент) инициирует обмен данными, посылая запрос другой стороне (серверу). Сервер обрабатывает запрос и при необходимости посылает ответ клиенту (рис. 2.7).

Рис. 2.7. Модель взаимодействия клиент сервер

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

Рис. 2.8. Логические уровни приложения

Рассмотрим некое типичное приложение, которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 2.8): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных (БД). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области.

Поскольку на практике разных пользователей системы обычно интересует доступ к одним и тем же данным, наиболее простым разнесением функций такой системы между несколькими компьютерами будет разделение логических уровней приложения между одной серверной частью приложения, отвечающим за доступ к данным, и находящимися на нескольких компьютерах клиентскими частями, реализующими интерфейс пользователя. Логика приложения может быть отнесена к серверу, клиентам, или разделена между ними (рис. 2.9).

Рис. 2.9. Двухзвенная архитектура

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

Развитием архитектуры клиент-сервер является трехзвенная архитектура , в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис 2.10).

Рис. 2.10. Трехзвенная архитектура

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

Рис. 2.11. Распределенная система розничных продаж

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

В качестве другого примера распределенной системы можно привести сети прямого обмена данными между клиентами (peer-to-peer networks) . Если предыдущий пример имел "древовидную" архитектуру, то сети прямого обмена организованы более сложным образом, рис 2.12. Подобные системы являются в настоящий момент, вероятно, одними из крупнейших существующих распределенных систем, объединяющие миллионы компьютеров.

Рис. 2.12. Система прямого обмена данными между клиентами

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

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

Распределенная архитектура AggreGate необычайно гибка. Технически она основана на формировании одноранговых связей между серверами и прикреплении частей единой модели данных одних серверов («поставщиков») к другим («потребителям»).

Цели распределенных операций

Основными целями распределенной архитектуры являются:

• Масштабируемость . Серверы нижнего уровня могут быть сильно нагружены, собирая данные и управляя большим количеством устройств в режиме, близком к реальному времени. Однако на практике количество устройств, которые могут обслуживаться с помощью одного сервера, ограничено до нескольких тысяч. При масштабировании системы для управления большим числом устройств разумно установить несколько серверов и объединить их в рамках распределенной установки.
• Балансировка нагрузки . Каждый сервер в распределенной установке решает свою задачу. Серверы управления сетью проверяют доступность и производительность сетевой инфраструктуры, серверы контроля доступа обрабатывают запросы от контроллеров дверей и турникетов. Операции контроля, такие как генерация отчетов и их рассылка по почте, могут выполняться на центральном сервере.
• Защита от вторжений . Вторичные серверы-зонды могут быть установлены в удаленных местах и подключены к центральному серверу. Системные операторы подключаются только к центральному серверу, при этом отпадает необходимость в настройке VPN и проброса портов к этим серверам.
• Централизация . Вторичные серверы могут работать в полностью автоматическом режиме, в то время как их настройка и мониторинг осуществляется через основной сервер, установленный в центральной диспетчерской.

Распределение ролей сервера

В данном простом сценарии два сервера объединены в распределённую инфраструктуру. Операторы системы постоянно подключены к серверу мониторинга, выполняя свои ежедневные обязанности. Руководство компании подключается к серверу отчётности и аналитики тогда, когда нужно получить срез данных. Независимо от объёмов данных и нагрузки на сервер, данная операция не повлияет на работу операторов.

Крупномасштабная облачная IoT-платформа

Поставщики телекоммуникационных и облачных услуг предлагают IoT-сервисы по моделям IaaS/PaaS/SaaS. В этих случаях речь идёт о миллионах устройств, принадлежащих тысячам пользователей. Обслуживание такой огромной инфраструктуры требует сотни серверов AggreGate, большинство из которых можно объединить в две группы:

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

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

Серверы хранения и обработки данных используют ресурсы (тревоги, модели, рабочие процессы, инструментальные панели и т.д.), полученные от серверов шаблонов, которые в свою очередь хранят мастер-копии данных ресурсов.

Многоуровневая инфраструктура Интернета вещей

Благодаря распределённой инфраструктуре AggreGate любое решение может включать в себя множество серверов разных уровней. Часть из них может работать на IoT-шлюзах, собирая данные, другие - хранить и обрабатывать информацию, а оставшаяся часть - осуществлять высокоуровневую агрегацию и распределённые вычисления.

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

Управление умным городом

Это пример основанной на AggreGate многоуровневой архитектуры для комплексной автоматизации большой группы зданий:

• Уровень 1 : физическое оборудование (сетевые маршрутизаторы, контроллеры, промышленное оборудование и т.д.)
• Уровень 2 : серверы управления (серверы мониторинга сети, серверы контроля доступа, серверы автоматизации зданий и другие)
• Уровень 3 : центры управления серверами зданий (один сервер на здание, который собирает информацию со всех серверов второго уровня)
• Уровень 4 : серверы районов города (конечный пункт назначения для эскалации оповещений более низкого уровня, мониторинг в реальном времени, интеграция с Service Desk-системами)
• Уровень 5 : серверы головного офиса (контроль серверов района, сбор и обобщение отчетов, оповещений)

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

Управление мультисегментной сетью

AggreGate Network Manager построен на платформе AggreGate и является типичным примером использования распределенной архитектуры. Большие сегментированные сети корпораций и операторов связи не могут контролироваться из единого центра из-за ограничений маршрутизации, политики безопасности или ограничений пропускной способности каналов связи с удаленными сегментами сети.

Таким образом, распределенная система мониторинга как правило состоит из следующих компонентов:

• Первичный или центральный сервер, собирающий информацию со всех сегментов сети
• Вторичные серверы или серверы-зонды , выполняющие опрос устройств в изолированных сегментах
• Специализированные серверы, такие как серверы анализа трафика, обрабатывающие миллиарды NetFlow-событий в день

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

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

Высокопроизводительное управление событиями

Некоторые сценарии использования платформы AggreGate, такие как централизованное управление инцидентами, предполагают, что значительное количество событий должно получаться, обрабатываться и постоянно храниться в структурированном формате. Порой потоки могут достигать объёмов в миллионы событий в секунду, причём полученных из разных источников.

В подобных случаях один сервер AggreGate не справится со всем потоком событий. Организовать обработку событий поможет распределенная архитектура:

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

Цифровое предприятие

AggreGate может выступать как координирующая платформа для цифрового предприятия. Каждый из серверов AggreGate может выполнять различные функции, начиная от мониторинга и управления удалёнными объектами и заканчивая высокоуровневыми сервисами, такими как бизнес-аналитика или, например, управление инцидентами.

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

По утверждению известного специалиста в области информатики Э. Таненбаума, не существует общепринятого и в то же время строгого определения распределенной системы. Некоторые остряки утверждают, что распределенной является такая вычислительная система , в которой неисправность компьютера, о существовании которого пользователи ранее даже не подозревали, приводит к остановке всей их работы. Значительная часть распределенных вычислительных систем, к сожалению, удовлетворяют такому определению, однако формально оно относится только к системам с уникальной точкой уязвимости (single point of failure ).

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

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

Как основу описания взаимодействия двух сущностей рассмотрим общую модель взаимодействия клиент- сервер , в которой одна из сторон (клиент) инициирует обмен данными, посылая запрос другой стороне (серверу). Сервер обрабатывает запрос и при необходимости посылает ответ клиенту (рис. 1.1).

Рис. 1.1.

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

Рис. 1.2.

Рассмотрим некое типичное приложение , которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 1.2): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных ( БД ). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области .

Поскольку на практике разных пользователей системы обычно интересует доступ к одним и тем же данным, наиболее простым разнесением функций такой системы между несколькими компьютерами будет разделение логических уровней приложения между одной серверной частью приложения, отвечающим за доступ к данным, и находящимися на нескольких компьютерах клиентскими частями, реализующими интерфейс пользователя. Логика приложения может быть отнесена к серверу, клиентам, или разделена между ними (рис. 1.3).

Рис. 1.3.

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

Развитием архитектуры клиент- сервер является трехзвенная архитектура , в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис. 1.4).

Рис. 1.4.

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