Трудности, связанные с облачными центрами обработки данных
С появлением облачных вычислений проектировщикам центров обработки данных стало очень важно учитывать актуальные и постоянно возрастающие потребности облака. В этой парадигме центры обработки данных физически размещают все облачные службы, доставляемые пользователям. Облачные службы, в свою очередь, абстрагируются от базовых физических ресурсов в различных масштабах (по частной IP-сети, как в частном облаке, или через Интернет, как в общедоступном облаке), по запросу и для миллионов потенциальных подписчиков. Требования к проектированию центра обработки данных зависят от использования, размера и необходимых функциональных возможностей. Облачная модель заставляет переосмыслить подход к разработке и использованию ресурсов центра обработки данных. Облачные службы и их масштабирование предъявляют новые требования к центрам обработки данных, в которых потоки трафика варьируются, требования к пропускной способности ввода-вывода и производительности значительно возрастают, а также возникают новые проблемы безопасности. Мы расскажем о некоторых проблемах, возникающих в центрах обработки данных из-за облачных вычислений, и опишем соответствующие требования к проектированию центров обработки данных, ориентированных на облако.
Масштабируемость
В сфере облачных вычислений наблюдается постоянно растущая потребность в расширении и высокой емкости. Поэтому облачные центры обработки данных обычно проектируются на базе виртуальных машин (или экземпляров), которые являются единицами измерения вычислений в облачной парадигме. В отличие от корпоративных центров обработки данных, облачные центры обработки данных предоставляют службы миллионам потенциальных пользователей. Чтобы удовлетворить постоянно возрастающую потребность пользователей в облачных службах, обычно применяются методики виртуализации. С помощью виртуализации операторы центров обработки данных могут автоматически подготавливать виртуальные машины (ВМ) и отменять их подготовку по мере необходимости, не добавляя и не перестраивая физические устройства. Сейчас нередко приходится подготавливать 20 или больше виртуальных машин на каждый монтируемый в стойку сервер или блейд-сервер. Очевидно, что это может значительно нагружать ресурсы сервера (такие как ЦП, ОЗУ и сетевые карты). Кроме того, это может значительно увеличить число логических серверов, работающих в физической сети центра обработки данных. Например, для стойки из 64 серверов с 20 виртуальными машинами на один сервер поставщику облачных служб потребуется до 1200 IP-подсетей и виртуальных локальных сетей. (В сети локальная сеть может быть сегментирована в разные домены вещания, каждая из которых называется виртуальной локальной сетью.) Кроме того, потребуется только 10 стоек, 12 000 IP-подсетей и виртуальных ЛС. Подобная ситуация представляет серьезную проблему, так как превышает ограничение (например, в размере 4094) на число используемых виртуальных локальных сетей, установленное стандартом IEEE 802.1Q, не учитывая перегрузку физических коммутаторов и маршрутизаторов. Поставщики облачных центров обработки данных вынуждены искать решения для подобных проблем.
С другой стороны, даже максимально задействовав возможности виртуализации, в определенный момент для обеспечения роста потребуется увеличить физическую емкость. Таким образом, облачные центры обработки данных должны иметь модульную структуру, чтобы обеспечить простое наращивание физической емкости без нарушения работы приложений и служб. Проектировщики должны определить базовую емкость для обеспечения долгосрочного роста, чтобы операторы центра обработки данных могли добавлять дополнительные компоненты по мере необходимости.
Сетевые топологии
Рис. 20. Традиционная иерархическая топология центра обработки данных в виде дерева
Большинство современных сетей центров обработки данных основано на иерархических структурах в виде дерева, состоящих из трех основных уровней: уровня доступа, уровня агрегирования и базового уровня. На рисунке показан пример традиционной сетевой топологии в виде дерева. Во-первых, уровень доступа состоит из экономичных коммутаторов Ethernet, соединяющих серверы в стойке и устройства хранения на основе IP-адресов (обычно это соединения скоростью 10/100 Мбит/с или 1 Гбит/с). Во-вторых, несколько коммутаторов доступа подключаются через Ethernet (обычно с использованием соединений 1/10 Гбит/с) к одному коммутатору агрегирования. В-третьих, набор коммутаторов агрегирования подключается к уровню базовых коммутаторов. Так как виртуальные локальные сети уровня 2 не используют IP-маршрутизацию, они обычно реализуются на уровнях доступа и агрегирования. И наоборот, маршрутизация уровня 3 реализуется на базовых коммутаторах, которые пересылают трафик между коммутаторами агрегирования, интрасетью и Интернетом. Важный момент заключается в том, что пропускная способность между двумя серверами зависит от их относительного расположения в топологии сети. Например, пропускная способность между узлами в одной стойке выше, чем между узлами, которые находятся в разных стойках.
Действительно, сеть является ключевым компонентом для облачных центров обработки данных. Иерархические топологии, как показано на рисунке, не в полной мере подходят для облаков, так как они принуждают трафик между серверами проходить через несколько уровней коммутаторов, каждый из которых добавляет свою задержку. Задержка в данном контексте обозначает задержки, вызываемые несколькими проходимыми коммутаторами, потребностью в обработке и буферизации. Даже минимальные задержки в облаке могут восприниматься пользователями как снижение производительности и приводить к ухудшению продуктивности работы. Таким образом, для облачных центров обработки данных в общем случае предпочтительными являются более плоские топологии сети с меньшим количеством уровней, так как они лучше подходят для объемного трафика, чувствительного к задержкам.
Более эффективное использование и устойчивость
Как правило, в современных сетях центров обработки данных в виде дерева для обеспечения устойчивости применяются некоторые разновидности протокола связующего дерева (STP). STP — это протокол управления каналами передачи данных, обеспечивающий нециклическую топологию, когда коммутаторы и мосты взаимодействуют друг с другом несколькими путями. STP допускает только один активный путь между двумя коммутаторами, при этом остальные становятся неактивными (если предполагается наличие нескольких путей). При сбое активного пути STP автоматически выбирает вместо него другой доступный неактивный путь. На такой выбор STP может потребоваться несколько секунд, что может оказаться недопустимым для чувствительных к задержкам облачных приложений (например, веб-конференций). Кроме того, создание простаивающих резервных путей не является оптимальным решением для облачных центров обработки данных, особенно при экспоненциальном увеличении потребностей пользователей. Облачным центрам обработки данных требуются более оптимизированные и устойчивые структуры сети, обеспечивающие полноценное использование сетевых ресурсов и восстановление после сбоев в считанные миллисекунды для оперативного удовлетворения потребностей и эффективного использования ресурсов.
Безопасная мультитенантная среда
Рис. 21. Обмен данными между рабочими нагрузками в виртуализированной среде
В современных центрах обработки данных рабочие нагрузки (например, базы данных, пользовательские приложения, веб-хостинги) обычно развертываются на отдельных физических серверах, при этом взаимодействие между рабочими нагрузками осуществляется через физические подключения. Таким образом, безопасность пользователей может обеспечиваться посредством традиционных сетевых систем обнаружения и предотвращения вторжений. С другой стороны, в облачных центрах обработки данных на одном сервере в стойке можно подготовить несколько виртуальных машин, при этом каждая из них будет принадлежать отдельному пользователю. Таким образом, взаимодействие между рабочими нагрузками может происходить на одном сервере через виртуальные подключения полностью прозрачным для существующих систем безопасности образом, как показано на рисунке. Поэтому облачным центрам обработки данных необходимо изолировать пользователей, защищать виртуальные ресурсы и обеспечить безопасность обмена данными внутри сервера.
Мобильность виртуальных машин
Облачные центры обработки данных могут размещать виртуальные машины пользователей на серверах, находящихся в одной стойке, в разных стойках, но в одном центре обработки данных, а также на серверах в разных центрах обработки данных. Облако может охватывать несколько центров обработки данных (например, Amazon позволяет пользователям подготавливать виртуализованные экземпляры в нескольких центрах обработки данных). В целях проведения регулярного обслуживания, балансировки нагрузки и обеспечения отказоустойчивости облакам необходимо периодически и без проблем переносить виртуальные машины между физическими серверами, не затрагивая пользовательские службы и приложения. Такая миграция требует не только расширение домена уровня 3 (домена, в котором требуется IP-маршрутизация, такого как глобальная сеть) для перемещения виртуальных машин между центрами обработки данных. Она также требует расширение домена уровня 2 (домена, в котором маршрутизация не выполняется и используется только вещание, такое как локальная сеть), чтобы охватить несколько центров обработки данных.
Быстрый и высокодоступный транспорт хранилища
Хранилище в облачном центре обработки данных должно поддерживать мобильность виртуальных машин и постоянно быть доступным. Переносимые виртуальные машины должны сохранять связь с системами хранения. Один из способов обойти это заключается в перемещении виртуальных машин вместе с соответствующими данными и хранилищем. Очевидно, что для этого потребуется подключение к облачному центру обработки данных с высоким уровнем доступности, низкой задержкой и высокой пропускной способностью. В настоящее время используется несколько моделей хранения (например, Storage over IP [SoIP], Fibre Channel over Ethernet [FCoE] и традиционная Fibre Channel), которые требуют высокопроизводительных и высокодоступных облачных сетей.
В целом центрам обработки данных, предназначенным для облаков, потребуется следующее.
- Модульная структура для поддержки экспоненциального роста и простого добавления физической емкости без перерывов в работе служб.
- Более плоские топологии сети с меньшим количеством уровней, устройств и кабельных соединений, так как они лучше подходят для объемного трафика, чувствительного к задержкам.
- Более эффективные и устойчивые структуры сети, обеспечивающие полноценное использование сетевых ресурсов и восстановление после сбоев в считанные миллисекунды.
- Возможность полностью изолировать пользователей облака, защитить виртуальные ресурсы и обеспечить безопасность обмена данными внутри сервера.
- Мобильность виртуальных машин для оперативного и беспроблемного проведения регулярного обслуживания, балансировки нагрузки и обеспечения отказоустойчивости.
- Круглосуточная доступность служб в течение всего года, а также возможность сохранения подключения переносимых виртуальных машин к их системам хранения.
Требования к облачным центрам обработки данных
Проектировщики центров обработки данных могут обеспечивать выполнение рассмотренных ранее требований на уровне инфраструктуры, на уровне виртуализации или на обоих этих уровнях. Например, требование масштабируемости должно быть реализовано на обоих уровнях, в то время как защищенная мультитенантность может быть реализована главным образом на уровне виртуализации. Общий доступ к ресурсам и виртуализация подробно описаны в одном из последующих модулей. В этом модуле мы описываем уровень инфраструктуры. Соответственно, мы представляем лишь некоторые из ИТ-устройств (например, коммутаторы, маршрутизаторы), платформы и протоколы, которые можно использовать для удовлетворения требований к облачным центрам обработки данных. Так как этот курс посвящен облачным вычислениям, мы не будем рассматривать принципы работы устройств, протоколов и платформ, а сосредоточимся на преимуществах, которые они предоставляют облачным центрам обработки данных.
Для начала планировщики центров обработки данных могут рассмотреть возможность применения многопротокольной коммутации по меткам (MPLS) для выполнения требований к облачной инфраструктуре. MPLS — это хорошо масштабируемый механизм, который направляет данные с одного сервера на другой, используя короткие метки пути, а не длинные сетевые адреса. В частности, MPLS помечает пакеты данных и обеспечивает пересылку пакетов без проверки их содержимого, что значительно ускоряет такую пересылку, так как позволяет отказаться от поиска в таблицах маршрутизации и полагаться только на метки пакетов. Следовательно, MPLS позволяет создавать сквозные каналы через транспортную среду любого типа, что является ключевым требованием для обмена данными между серверами в облачных центрах обработки данных.
Как упоминалось ранее, в облачных вычислениях используется трафик различных типов, а требования к пропускной способности варьируются. Без использования MPLS может потребоваться создавать отдельные сети уровня 2, что, очевидно, не является масштабируемым решением для облачных центров обработки данных и может значительно увеличить капитальные и эксплуатационные расходы. И наоборот, при использовании MPLS можно совместно использовать сети, создавая виртуальные сетевые подключения, называемые путями с коммутацией по меткам (LSP). Кроме того, можно гибко контролировать качество трафика, проходящего по путям LSP. Подобный контроль трафика упрощает реализацию комплексного качества обслуживания (QoS) и обеспечивает быструю сетевую конвергенцию (приблизительно 50 мс) в случае сбоя каналов, что гораздо лучше по сравнению с STP. В результате значительно улучшается прозрачность сетевых сбоев и сокращаются перерывы в работе служб, что отражает другие ключевые требования для повышения устойчивости облачных центров обработки данных.
MPLS также позволяет включить службу виртуальной частной локальной сети (VPLS) для расширения возможностей подключения уровня 2 на несколько центров обработки данных. VPLS — это технология виртуальной частной сети (VPN). Виртуальная частная сеть обычно используется для реализации безопасных подключений между локальными сетями, расположенными на разных местах, например в центрах обработки данных, использующих общедоступные интернет-каналы. VPLS позволяет различным локальным сетям в разных центрах обработки данных обмениваться данными, как если бы они были одной локальной сетью, что является ключевым требованием для оптимизации мобильности виртуальных машин. Для мобильности виртуальных машин также можно использовать преимущества вышеупомянутых возможностей управления трафиком, предоставляемых MPLS.
Текущие разработки
Сейчас несколько поставщиков предлагают ориентированные на облако продукты для сетевого взаимодействия и вычислений, позволяющие удовлетворить несколько указанных выше требований к проектированию. Большинство этих продуктов являются вариациями того, что можно найти в традиционном центре обработки данных, с акцентом на плотности и одновременно работающих пользователях. Проектировщик центра обработки данных, желающий поддерживать частные или общедоступные облака, располагает постоянно растущим каталогом доступных продуктов.
За последние 5 лет структура центра обработки данных быстро менялась, и спад в этой тенденции пока не намечается. Через 5 или 10 лет центры обработки данных, скорее всего, будут кардинально отличаться от современных. Проектировщики центров обработки данных стремятся выполнить новые требования, одновременно повышая эффективность и совокупную стоимость владения для предоставления облачной службы. Учитывая появление предварительно спроектированных модульных центров обработки данных, в ближайшее время эти объекты станут взаимозаменяемыми компонентами, по аналогии с самим ИТ-оборудованием. Чтобы удовлетворить растущий потребительский спрос на новые облачные службы, а также потребность существующих предприятий в ИТ-инфраструктуре, будет появляться все больше центров обработки данных, которые с каждым новым поколением будут становиться все эффективнее.