Там, где облако встречается с периферией

Снижение задержки – основная причина, по которой облачные провайдеры предлагают периферийные (edge-) узлы как часть своей облачной инфраструктуры. Всего несколько лет назад те же провайдеры утверждали, что публичное облако, размещенное в гиперЦОДе, подходит для большинства задач. Но поскольку клиенты настаивали на уменьшении задержки и улучшении контроля над данными, они смягчили свою позицию и разработали варианты, которые позволяют развертывать ПО публичного облака ближе к заказчикам, тем самым уменьшая задержку при предоставлении облачных сервисов (см. рисунок).

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

 

Облачные провайдеры обычно рассматривают периферийную инфраструктуру – и на границе с площадкой заказчика, и на самой площадке (on-premises) – как расширение публичного облака (в конфигурации гибридного облака), а не как изолированные частные облака, работающие независимо. Они считают свои гиперЦОДы основным местом размещения рабочих нагрузок, а периферийные узлы предлагают использовать для специальных задач, для которых централизованное облако не подходит. По сути, провайдеры рассматривают периферийные узлы как тактические промежуточные пункты.

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

Поставщики услуг IaaS обычно используют термин «регион» для описания географической области, в которую входят несколько независимых зон доступности (availability zone, AZ). Каждая зона доступности состоит из минимум одного ЦОДа. В стране может быть много регионов, в каждом из которых, как правило, две или три AZ.

Облачные провайдеры также предлагают городские (metro) сайты и локации рядом с площадками заказчиков (near-premises). Эти узлы представляют собой специализированные программно-аппаратные комплексы (edge-ПАК), расположенные в небольших ЦОДах или в дата-центрах, которые предоставляют услуги colocation. Провайдеры управляют этими периферийными узлами так же, как и зонами AZ. Задержка между такими узлами и конечными пользователями составляет несколько миллисекунд. Однако периферийные облачные узлы обычно обладают меньшими функциональными возможностями и меньшей отказоустойчивостью при более высокой цене по сравнению с зонами AZ в более крупных ЦОДах.

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

Когда клиент хочет развернуть приложение в облаке, он сначала выбирает регион и зону AZ, используя графический пользовательский интерфейс или API облачного провайдера. Периферийные узлы предлагаются ему в качестве вариантов развертывания наравне с основным регионом. Если подходящая периферийная локация имеется, то получить IaaS-ресурсы в ней обычно можно за считанные минуты.

Metro-узлы не предоставляют такого набора облачных сервисов, как регионы. В них предлагаются в основном вычислительные ресурсы, хранение данных, управление контейнерами и балансировка нагрузки. В регионе есть несколько зон AZ, а на metro-уровне зона, как правило, одна, поэтому на ее основе нельзя создать полностью отказоустойчивое приложение. Таким образом, пользователи должны понимать, что, хотя облачные edge-сервисы могут уменьшить время задержки и затраты на каналы связи, отказоустойчивость может быть ниже. Metro-узлы обычно ориентированы на графически насыщенные приложения, такие как виртуальные рабочие столы, видеоигры, обработка видео-, аудио- или сенсорных данных в режиме реального времени.

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

Как и metro-локации, узлы, расположенные вблизи заказчиков, предоставляют менее широкий спектр услуг, чем зоны AZ и регионы. Существенное отличие от метро-локаций в том, что такие узлы развертываются непосредственно в инфраструктуре сетей 4G или 5G, возможно, на ближайшем сайте сотовой сети. Это сокращает число сетевых пролетов (hop), а значит, и время задержки в условиях перегрузки.

Для развертывания узлов near-premises облачные провайдеры обычно сотрудничают с крупными телеком-операторами, например, в США сервис AWS Wavelengths предоставляется в партнерстве с Vodafone, а сервис Microsoft Azure Edge Zone – с участием AT&T. Варианты использования этих решений могут включать работу приложений реального времени, таких как обработка и анализ видео в реальном времени, поддержку автономных транспортных средств и систем дополненной реальности. 5G обеспечивает подключение там, где отсутствует инфраструктура фиксированной связи, или в местах временного развертывания.

Местами размещения узлов near-premises могут быть сайты сотовой сети или узлы связи, типовая мощность – от десятков до нескольких сотен киловатт. Обслуживающий персонал на этих узлах обычно отсутствует (контроль осуществляется дистанционно), уровень резервирования может быть разным (с одним генератором или без такового).

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

Поскольку заказчик сам выбирает место для размещения облачной инфраструктуры, характеристики соответствующего ЦОДа и его оснащение могут быть разными. Типовая мощность объекта – от десяти до нескольких сотен киловатт; он может быть в собственности или аренде; размещаться в переоборудованных помещениях или использовать специальные решения для организации edge-ЦОДов. Уровни избыточности и квалификации персонала также разнятся от одного проекта к другому. Некоторые поставщики оборудования для периферийных дата-центров предоставляют дополнительные услуги удаленного мониторинга. Подключение может осуществляться через линии связи или локальное оптоволокно, задержка сигнала между площадкой и конечным пользователем также значительно варьируется.

Поставщики услуг colocation все чаще стараются выделиться на рынке за счет прямого пиринга с сетями облачных провайдеров, чтобы сократить время задержки сигнала. Например, Google Cloud рекомендует свой сервис Interconnect для задач, в которых задержка между публичным облаком и узлом colocation не должна превышать 5 мс. К Google Cloud подключены уже более 140 сайтов colocation, в том числе принадлежащие компаниям Equinix, NTT, Global Switch, Interxion, Digital Realty и CenturyLink. Другие облачные провайдеры имеют схожие договоренности с поставщиками услуг colocation.

Существуют три основных варианта расширений облака, которые могут быть размещены у заказчика. Они различаются главным образом тем, насколько легко настроить комбинацию аппаратного и программного обеспечения. Специализированное edge-устройство (edge-ПАК) просто в инсталляции, но имеет ограниченные возможности настройки; сервер с оплатой по мере использования (pay-as-you-go) обеспечивает гибкость в выборе производительности и интеграции с облаком, но требует дополнительной настройки; наконец, контейнерная платформа обеспечивает гибкость в выборе аппаратного и программного обеспечении и возможности мультиоблачной работы, но требует высокого уровня экспертизы персонала.

Edge-ПАК. Это предварительно сконфигурированное устройство с предустановленным ПО оркестрации. Клиент размещает его в своем ЦОДе для подключения к провайдеру публичного облака. У него есть ограниченная возможность конфигурирования такого устройства, но, как правило, нет прямого доступа к аппаратному обеспечению и ПО.

Разворачивание ИТ-ресурсов осуществляется с помощью того же графического интерфейса и API-интерфейсов, которые используются при работе с основным облаком в регионах и зонах AZ. В большинство случаев для задач администрирования требуется подключение к публичному облаку. Устройство остается собственностью поставщика облачных услуг, и покупатель обычно арендует его, скажем, на три года. Примеры: AWS Outposts, Azure Stack Hub и Oracle Roving Edge Infrastructure.

Сервер pay-as-you-go. Это физический сервер, сдаваемый в аренду клиенту и оплачиваемый им соответственно выделенным и потребленным ресурсам. Провайдер обслуживает и обновляет сервер, удаленно учитывает потребление ресурсов, предлагая при необходимости увеличить производительность. Он может также установить на сервер ПО – с оплатой по тому же принципу. Такое ПО может состоять из инструментов облачной оркестровки, которые предоставляют возможности частного облака и подключения к публичному облаку для реализации гибридной модели. Клиенты могут выбирать технические характеристики оборудования и использовать ПО не только облачного провайдера, но и третьей стороны. Примеры: HPE Green Lake и Dell APEX.

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

Облачные провайдеры предлагают управляющее ПО для удаленных узлов, совместимое с публичными облаками. Примерами могут служить Google Anthos, IBM Cloud Satellite и Red Hat OpenShift Container Platform. В этом варианте клиенты могут выбирать свое аппаратное обеспечение и некоторые компоненты ПО для оркестрации (например, контейнерные движки), и они также сами отвечают за построение системы и управление сложным набором компонентов.

Заказчики могут быстро и легко размещать приложения в периферийных узлах, предлагаемых облачными провайдерами на metro-уровне или в близлежащих локациях. Там, где подходящий узел недоступен или заказчик предпочитает использовать локальные ЦОДы (на своей территории), у него есть несколько вариантов расширения возможностей публичного облака до edge-ЦОДа.

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

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!