Современные коммутаторы должны полноценно работать как в физических, так и в виртуальных средах. Очевидно, что главные сложности таятся в виртуальной составляющей: решения для виртуализации зачастую постоянно перемещают приложения в рамках серверных пулов (в том числе и распределенных), чтобы обеспечить максимально эффективное использование вычислительных ресурсов и памяти. От сетевых соединений, а значит, и коммутации требуется оперативная адаптация к этим перемещениям. Точно такие же требования предъявляются к механизмам безопасности и связанным с ними настройкам. По этой причине наличие хорошего коммутатора для локальной сети крайне необходимо, но это в лучшем случае полдела. Еще одно условие — правильное управление сетью. В наше время без интенсивного взаимодействия коммутаторов и систем управления на самых разных функциональных уровнях невозможно справиться с проблемами, возникающими в виртуальных средах.
Система управления должна глубоко интегрироваться в используемую платформу для виртуализации, чтобы она могла непрерывно получать информацию о параметрах и местонахождении виртуальных машин. Те, кто заботится о независимости от конкретных производителей, должны убедиться в том, что система управления способна взаимодействовать не с одним, а с максимальным количеством наиболее популярных решений для виртуализации, таких как VMware vSphere, Microsoft Hyper-V, Citrix XenServer, Parallels, Virtuozzo и т. д. Преимущество для пользователя заключается в значительном облегчении работы администратора, поскольку ему придется решать всего одну задачу управления вместо двух. Кроме того, меньше становятся накладные расходы на согласование систем управления приложениями и сетями. В идеале интеграция платформ управления и виртуализации реализуется на базе открытых API, что обеспечивает прозрачность, гибкость и соответствие стандартам.
АДМИНИСТРИРОВАНИЕ НА БАЗЕ ПРАВИЛ
Основная задача заключается в том, чтобы в любое время предоставлять приложениям, в том числе и в виртуальных средах, вычислительные мощности, емкость хранения, сетевые ресурсы и качество сервиса, — и все это с соблюдением правил безопасности, действующих для соответствующих приложений. Традиционные методы управления на основе портов неэффективны, поскольку в таких динамичных средах вся система пребывает в непрерывном движении и изменении, а значит, и привязка к портам тоже непостоянна. Для однозначной идентификации гораздо лучше подходят MAC-адреса. Они уникальны, никогда не изменяются и фактически являются аналогом идентификаторов пользователей для машин. Точно так же, как в хорошо организованных сетях пользователи после аутентификации получают доступ к своим индивидуальным профилям с детализацией предоставляемых для них ресурсов и прав, так и здесь можно создавать виртуальные сетевые профили (Virtual Network Profile, VNP) на основе MAC-адресов.
Если теперь то или иное приложение отправится в странствование по серверам, то система управления сможет на основе профиля VNP заранее настроить сетевое окружение целевого сервера в соответствии с запросами этого приложения. И неважно, был ли процесс перемещения между серверами запущен администратором вручную или автоматически инициирован платформой виртуализации с целью оптимизации ресурсов. К примеру, когда требуется переместить с одного сервера на другой телекоммуникационную систему, реализованную в виде приложения, то сначала система управления сетью автоматически подаст команду, чтобы соединенные с целевым сервером порты коммутатора реализовали четко прописанные требования соответствующего профиля VNP к качеству сервиса (Quality of Service, QoS).
Таким образом, сеть всегда функционирует в соответствии с потребностями своих приложений. Этот подход получил название Application Fluent Networking (AFN). Профиль VNP определяет приоритет приложений, конфигурацию коммутатора, качество сервиса и требования к безопасности. VNP позволяет сделать так, чтобы сеть получала сведения о требованиях к производительности приложений и динамично управляла этими параметрами в реальном времени. Сюда входит и автоматическое перемещение виртуальных машин в коммутирующей структуре.
Чтобы коммутаторы были пригодны для использования в среде AFN, они должны изначально поддерживать ряд функций, которыми их невозможно дооснастить позднее. Коммутатор не должен терять пакеты — это свойство, именуемое Lossless Ethernet, является важнейшим условием для гарантированной высокой производительности приложений. Оно должно быть заложено на уровне архитектуры коммутатора. На практике для этого требуются очень емкие буферы памяти для отдельных портов, а также интеллектуальные механизмы формирования очередей. На уровне приложений соответствующие протоколы используют указанные буферы для обеспечения сквозной пропускной способности на должном уровне. Типичные примеры приложений с очень высокими требованиями к производительности: все приложения, запрашивающие большие массивы данных, распределенные поисковые запросы и системы для запросов к базам данных. Для всех перечисленных случаев допустимы задержки, не превышающие нескольких микросекунд.
Современные архитектуры, где реализован принцип коммутации с промежуточной буферизацией (Store and Forward), используют для лучшей координации передачи трафика во всех направлениях (в ячеистой топологии) технологию виртуальных очередей на выходе (Virtual Output Queuing, VOQ). Сочетание VOQ и емких буферов существенно повышает гибкость отдельных приложений и всей сети. Большие буферы позволяют избежать перегрузки систем, когда трафик разделяется или если поступающие от устройств данные одновременно передаются на общие серверы, что приводит к повышению нагрузки на них. Пример: сервер приложений получает данные от распределенных серверов хранения, и вся информация приходит практически одновременно. В таких случаях коммутатору необходим буфер, имеющий достаточные размеры, чтобы без потерь пересылать поступившие данные. Для обеспечения асимметричной передачи данных между сетями стандартов GbE и 10 GbE тоже нужны объемные буферы, чтобы компенсировать разницу в скоростях соединений.
ОПТИМИЗИРОВАННАЯ КОММУНИКАЦИЯ МЕЖДУ СЕРВЕРАМИ
В виртуализированных ЦОД приходится приспосабливать к требованиям «мигрирующих» приложений не только отдельные коммутаторы, но и всю коммутирующую архитектуру. Хорошие результаты достигаются при создании ячеистых структур с узлами доставки (Point of Delivery, POD). Узел POD представляет собой группу, состоящую из вычислительных, сетевых и программных ресурсов, а также компонентов хранения, которые взаимодействуют при предоставлении какой-либо услуги или приложения. Важно помнить, что POD является модульной конструкцией, и в любой момент можно внести изменения в ее состав.
Архитектура POD ориентирована в первую очередь на удовлетворение потребности в коммуникации между серверами. Серверы можно подключать напрямую к коммутаторам, находящимся в 19-дюймовых стойках (Top of Rack, ToR), и не обращаться к услугам коммутатора уровня ядра сети (Core Switch) для пересылки данных от сервера к серверу. Такой подход способствует оптимизации трафика данных между серверами и одновременно позволяет снизить затраты. В современных коммутирующих структурах подобным образом удается соединять до 14,4 тыс. серверов с портами 10GbE и использовать всего два коммутатора уровня ядра.
Что касается конвергенции сетей приложений и хранения, то современные коммутаторы должны поддерживать соответствующие технологии конвергенции. В их число входят FCoE и iSCSI. Современные сети обходятся без устаревшего протокола Spanning Tree Protocol (STP), который совершенно не пригоден для нынешних сценариев избыточности и приложений реального времени. Если все это требуется воплотить без сложных надстроек, то рекомендуется прибегнуть к механизмам Shortest Path Bridging (SPB по стандарту IEEE 802.1aq). Кроме того, SPB поддерживает прямое отображение сервисов (Mapping) на магистраль оператора (Carrier Backbone), что позволяет реализовать очень эффективное сопряжение локальных сетей с глобальными. В принципе, то же самое достигается и с помощью протокола Transparent Interconnection of Lots of Links (TRILL), правда, он используется немногими, хоть и очень крупными производителями, к тому же в этом случае соответствие необходимо устанавливать вручную. Дополнительно SPB позволяет реализовать отображение MAC-адресов (MAC Address Mapping) с поддержкой мандатного контроля — это важное преимущество для ячеистых облачных сред.
ЭНЕРГОЭФФЕКТИВНОСТЬ ЛИШЬ НА НАЧАЛЬНОМ ЭТАПЕ
.png) |
|
Рисунок 1. Современные коммутаторы должны обеспечивать более высокую производительность, потребляя при этом меньше электричества. |
В наше время энергоэффективность является обязательным условием для всех устройств ИТ в целом и коммутаторов в частности. Помимо выбора процессоров, блоков питания и других электронных деталей, огромную роль здесь играют учет требований эффективности при проектировании всей архитектуры, а также возможности интеллектуальной системы управления. Хотя сегодня каждое предприятие стремится заявить о приверженности к «зеленым» технологиям, реальное потребление до сих пор еще в значительной степени зависит от производителя оборудования. Желающим получить верное представление об аспектах энергоэффективности следует обратить внимание на результаты испытаний, проведенных независимыми исследовательскими институтами. Согласно этим тестам, современным энергоэффективным коммутаторам требуется лишь 13,34 Вт на один порт 10GbE. Некоторые коммутаторы, размещаемые в стойках (Top of Rack) или в конце рядов стоек (End of Row), вообще потребляют всего 3,5 Вт на один порт 10GbE (см. Рисунок 1).
В претворении этих тенденций в жизнь активное участие принимают специалисты из лаборатории Bell-Labs, принадлежащей Alcatel-Lucent. Уже долгие годы они активно занимаются исследованиями в области «зеленых» телекоммуникационных сетей и «умных» энергосетей. Хотя ученые из Bell и считают, что наибольший потенциал для повышения эффективности таится в мобильной связи (к 2015 году они намереваются снизить расход электроэнергии в этой сфере в 10 000 раз!), однако многие инновации можно реализовать и в локальных сетях.
Томас Рорбах — руководитель отдела продаж сетевых решений в Alcatel-Lucent Enterprise.