.jpg) |
|
ПО МНЕНИЮ ЭКСПЕРТОВ, сейчас в России потенциальные потребители облачных сервисов переходят от стадии обсуждения возможностей облачной модели к стадии тестирования решений и первым пилотным внедрениям. Именно поэтому облачным провайдерам так важно показать свой товар лицом и обеспечить максимально комфортные условия работы новой технологической среды |
Именно поэтому облачным провайдерам так важно показать свой товар лицом и обеспечить максимально комфортные условия работы новой технологической среды. Но в ходе выполнения пилотных проектов могут возникнуть проблемы, заложенные в самой природе IP-протокола, на основе которого и строятся облака. Операторам связи и другим компаниям, которые хотят строить облачные структуры, важно знать, как можно оптимизировать работу IP-протокола при их использовании.
«Заказчики подписывают контракты на аренду инфраструктуры и хранение резервных копий в облаках, — отмечает Вероника Тараба, заместитель генерального директора по маркетингу компании «Крок». — Но вот знакомство с облачными сервисами в 98,5% случаев перерастает в продажи и внедрения продемонстрированного или протестированного в облаке софта. Так что все мы в начале большого пути».
Проблемы аренды внешних вычислительных ресурсов обусловлены прежде всего неоптимальной архитектурой российского сегмента сети Интернет, где непредсказуемо и в самых неожиданных местах могут возникнуть «бутылочные горлышки». С развитием услуг широкополосного доступа (ШПД) почти ликвидирован дефицит полосы пропускания на участке последней мили, и теперь недостаточная емкость каналов обычно фиксируется на участке сети от провайдера ШПД до оператора облачных услуг. Действительно, если отдельному клиенту предлагается канал в несколько мегабитов, то для каждой тысячи таких клиентов провайдеру ШПД потребуется канал к технической площадке облачного провайдера емкостью уже в несколько гигабитов. Этот ресурс является платным, и провайдеры ШПД стараются сэкономить на нем.
Решить данную проблему можно, изменив инфраструктуру облачных услуг, например, таким образом, чтобы максимально приблизить облачные сервисы к клиентам и оптимизировать взаимодействие между клиентом и облаком. Возник даже отдельный класс решений, позволяющих оптимизировать потребности в скорости подключения клиентов к крупным веб-ресурсам, которые сейчас уже построены по облачным принципам. Этот класс решений основан на определенной стратегии, требующей перестройки архитектуры предоставления доступа к облакам. Но есть и тактические решения, предполагающие установку тех или иных аппаратных ускорителей трафика.
Стратегия
«Для поставщиков облачных сервисов критически важно иметь хорошую интернет-связанность, иначе качество услуг будет страдать, — отмечает Ярослав Городецкий, генеральный директор компании CDNvideo. — В принципе есть два варианта решения этой проблемы. Первый: привести на площадку максимальное количество операторов связи, но это очень трудоемкий и дорогостоящий процесс. Второй вариант: задействовать готовую инфраструктуру операторов сетей доставки контента, он позволяет при минимальных капитальных затратах значительно сократить задержки при использовании клиентами облачных сервисов».
Так называемые сети доставки контента (Content Delivery Network, CDN) предназначены для максимального приближения тяжелого контента к провайдеру ШПД. Идея в том, чтобы обслуживать клиента не с далеких серверов, например в Калифорнии, а из ЦОД на локальной точке обмена трафиком. Такие ЦОД имеют высокоскоростные каналы связи с наиболее крупными провайдерами ШПД региона, что позволяет клиенту получать услуги облачного оператора по надежным скоростным каналам. По такой схеме можно оптимизировать трафик облачных услуг в режиме реального времени, а также обеспечить распространение тяжелых данных — они сохраняются на локальных серверах CDN-оператора и раздаются клиентам уже как локальный контент; их загрузка из внешних источников выполняется только один раз.
Оператор CDN, таким образом, оптимизирует магистральный трафик провайдера ШПД, а часто и сам предлагает собственное высокоскоростное подключение, через которое поставщики облачных сервисов распространяют свои услуги. Оператор CDN заключает договор как с провайдером облачных услуг, так и с провайдером ШПД, к чьей сети по высокоскоростному соединению подключает свой локальный центр распространения трафика.
Сейчас в России только начинает создаваться рынок CDN-операторов. Крупные производители контента, такие как Mail.ru, «Яндекс», Rambler и др., уже создали собственные CDN-сети, подключив их к точкам обмена трафиком (как московским, так и региональным). Однако коммерческих операторов сетей доставки контента до недавнего времени почти не было. Сейчас уже известны проекты, которые предлагают коммерческие услуги контент-провайдерам по распространению контента среди российских пользователей Интернета. Например, созданная два года назад компания CDNvideo специализируется на распространении видео и предлагает заказчикам услуги по доставке видеоконтента в регионы России. Еще одним российским оператором распространения контента является компания NGenix. За рубежом CDN-операторы существуют давно; в частности, их услугами активно пользуются такие крупные корпорации, как Google, Amazon, Facebook и Twitter. Правда, пока присутствие западных операторов CDN в России ограничено.
Следует отметить, что для оптимизации использования облачных вычислений архитектура CDN-сетей вполне уместна. Необходимо, чтобы на локальных площадках присутствия CDN-оператора использовалась необходимая клиенту технология виртуализации. Вместе с технологией динамического перемещения виртуальных машин такая CDN-сеть позволяет переместить серверную часть приложений максимально близко к потребителям. Это будет полезно, например, при внедрении технологии VDI (Virtual Desktop Infrastructure), в которой виртуальные рабочие столы лучше загружать из ближайшего к клиенту ЦОД, да и серверная часть должна располагаться достаточно близко.
Тактика
Помимо стратегических решений по оптимизации облачного трафика, применяются и некоторые тактические приемы, ускоряющие работу облачных приложений. Например, метод исключения повторяющихся операций, использующий кэши разных уровней: в базе данных, в серверах приложений, в веб-сервере. Но есть и так называемые обратные кэши, в них сохраняются различные картинки, меню и навигационные элементы, повторяющиеся по всему серверу.
«Существует несколько решений, с помощью которых можно оптимизировать передачу данных при построении облачных сервисов, — поясняет Андрей Врублевский, менеджер проектов департамента телекоммуникаций компании «Крок». — Большой выбор таких решений есть у компании Riverbed. Это может быть аппаратный продукт, к примеру оборудование серии Steelhead или виртуальный оптимизатор Virtual Steelhead. Есть и специализированные решения для облачных сервисов, например платформа Riverbed Whitewater, которая ускоряет процессы резервного копирования и осуществляет дедупликацию и сжатие данных, хранящихся в облачной инфраструктуре».
Городецкий для оптимизации работы интернет-порталов предлагает использовать решения компании Webo.
Не менее ресурсоемкой задачей, чем работа порталов, является расшифровка защищенных соединений. К облакам, как правило, клиенты подключаются по открытым каналам, поэтому для защиты соединений необходимо использовать шифрование. Но если клиент со своей частью процедуры шифрования обычно справляется, то сервер, который должен расшифровывать большие потоки данных, может давать большую задержку. Для решения этой проблемы предназначены аппаратные шифраторы, они также устанавливаются перед веб-сервером и обратным кэшем. Эти же устройства, как правило, выполняют функции защиты информации: межсетевого экранирования, фильтрации вредоносных запросов и определения попыток взлома сети.
Современные интерфейсы, построенные на основе AJAX, постоянно обмениваются с веб-приложением XML-запросами. Обработка этих запросов тоже может быть ускорена с помощью аппаратных сетевых устройств. Кроме того, входящие запросы пользователей должны распределяться между веб-серверами в зависимости от загрузки последних. Таким образом, для оптимизации облачной инфраструктуры необходимо правильно построить обработку пользовательских запросов: кэшировать повторяющийся контент и аппаратно ускорять индивидуальные, но повторяющиеся действия.
Оптимизация облачных сервисов
Разработчики различных ИТ-систем все чаще прибегают к построению собственных облачных сервисов, чтобы предложить клиентам дополнительные услуги. Немало таких сервисов призвано обеспечить информационную безопасность. С увеличением числа клиентов у разработчика подобных сервисов могут возникнуть проблемы с качеством обслуживания, вплоть до полного отказа защитных механизмов. Что же может предпринять разработчик для оптимизации сервисов ИТ-безопасности? Обратимся к опыту компании Entensys.
«Можно предоставить заказчикам два облачных репутационных сервиса для фильтрации потенциально опасного содержимого. Первый — облачный фильтр DNS — фильтрует адреса с плохой репутацией. От оперативной работы этого фильтра зависит доступность веб-ресурсов, поскольку при больших задержках работать в Интернете будет просто невозможно. Второй сервис — фильтрация спама в почте. Этот сервис менее критичен к задержкам, но должен обрабатывать большие потоки почтового трафика», — говорит Александр Кистанов, технический директор компании Entensys.
Оба описанных выше сервиса Entensys расположены в облаке Amazon, в котором арендуются виртуальные машины. С американским облачным гигантом был заключен договор SLA, где оговорена минимальная задержка при обработке запросов к арендуемой виртуальной машине. Кстати, возможность предоставить клиентам SLA появилась у Amazon благодаря использованию коммерческой инфраструктуры CDN Akamai, переносящей арендуемые виртуальные машины ближе к потребителю. Также провайдер оптимизирует защиту трафика, с помощью которой Entensys блокирует несанкционированное использование сервиса.
Впрочем, и разработчикам Entensys пришлось потрудиться, чтобы оптимизировать работу своего сервиса. Прежде всего нужно было реализовать систему балансировки нагрузки, направляющую запрос от клиента по максимально короткому маршруту. Если запросов слишком много, система автоматически создает новую копию виртуальной машины и опять перераспределяет ресурсы. При этом программное обеспечение системы управления виртуальной средой Amazon так формирует виртуальную машину в одном из узлов CDN, чтобы максимально приблизить ее к клиентам.
Таким образом, логика оптимизации реализуется и на уровне системы управления облачным сервисом (для балансировки нагрузки и создания новых образов виртуальных машин), и на уровне провайдера инфраструктуры (для создания новых виртуальных машин), и на уровне коммерческой CDN (для перемещения этой машины максимально близко к клиентам).
Впрочем, оптимизации подлежит и клиентская часть, которая не должна посылать лишних запросов сервис-провайдеру, а наиболее востребованные данные клиентская часть должна хранить в локальном кэше, утверждают в Entensys. За логику работы локального кэша уже полностью отвечают разработчики сервиса, но эффективный кэш позволяет посылать меньше запросов в облако, что равнозначно экономии средств на аренде виртуальных машин. Таким образом, разработчик облачного сервиса должен предусмотреть логику оптимизации и на клиенте, и в облаке.