Появление возможности виртуализации сервисных ресурсов в свое время стало огромным прорывом в технологиях построения ЦОД. Ведь она позволила уйти от привязки приложений к определенному серверу и его расположению. На фоне общеизвестных сложностей, о которых так много пишут в последнее время, возникающих при построении и в процессе эксплуатации ЦОДа, весьма логично то, что сетевая инфраструктура развивается по тому же пути. Появляются решения виртуализации и в этой сфере или иными словами строятся унифицированные сетевые фабрики.
Преимущества построения ЦОД с использованием унифицированной сетевой инфраструктуры в целом очевидны. Повышается КПД использования ресурсов, стандартизируются процессы и задачи, минимизируется влияние человеческого фактора, что в совокупности приводит к сокращению сроков окупаемости проекта, повышению эффективности и качества предоставляемых сервисов.
Достигается этот результат за счет ряда функциональных особенностей, присутствующих в новых моделях коммутаторов поддерживающих унифицированный формат. А также вследствие изменения самой архитектуры решений.
Несмотря на то, что технологии развиваются достаточно быстро, мы успеваем привыкать к определенным стандартам, в частности к стандартам в построении ЦОД. Так, мы привыкли к необходимости разделения сетевой инфраструктуры на инфраструктуру передачи данных и хранения. Ключевой составляющей в ней являются серверы, которые имеют интерфейсы подключения к каждой из этих подсистем. Такое разделение ведет за собой повышенное энергопотребление, увеличение кабельной инфраструктуры, из чего следует, что нам требуются большие объемы помещений.
Что представляет собой унифицированная сетевая инфраструктура?
Одним предложением можно сказать, что унифицированная сетевая инфраструктура — это совокупность семейства новых коммутаторов Nexus и нового сетевого адаптера с поддержкой протокола Fibre Channel over Ethernet.
Семейство коммутаторов Nexus, которые пришли на смену всем хорошо известным коммутаторам Catalyst 6500, 4900, 3750, состоит из нескольких моделей. NEXUS 7000 - флагман линейки, который позиционируется как коммутатор ядра ЦОД, имеет производительность 15 Тбит/с, полностью виртуализированную архитектуру, оптимизация под 10/40/100 Гбит/с. NEXUS 5000 - коммутаторы уровня консолидации на уровне ЦОД. Имеют порты 10 GE, FC, FCoE, DCE.
NEXUS 2000 - является по сути выносным модулем Nexus 5000. Ну и наконец, программный коммутатор встраиваемый в среду VMWare - NEXUS 1000, который позволяет вслед за миграцией приложения с одной виртуальной машины на другую, осуществить миграцию сетевых политик, прописанным на порту доступа.
CONVERGED NETWORK ADAPTER (CNA) - это новый сетевой адаптер 10GE с поддержкой Fibre Channel over Ethernet. Данный адаптер позволяет заменить несколько сетевых адаптеров на сервере на один, консолидирует 10GE и FC на едином интерфейсе.
Использование вместе данных элементов позволяет сократить фактическое количество коммутаторов в сети, уменьшается количество плат в серверах, уменьшить кабельную инфраструктуру. В целом в два раза сокращается энергопотребление, затраты на охлаждение и занимаемая площадь ЦОДа в том числе.
Преимущества использования унифицированной сетевой инфраструктуры действительно прозрачны и достижимы. Почему же компании все еще задаются вопросом: «Использовать Cisco Nexus или нет?»
На переговорах мне очень часто задают вопрос:
«Ребята, вы же сами строили для нас ЦОД, причем строили фундаментально и на
века»... Конечно, при использовании нового подхода мы сэкономим на
энергопотреблении, площадях и т.д. Но что прикажете делать с тем оборудованием,
кабельной инфраструктурой, уже купленными и внедренными, которые, по всей
видимости, просто придется выкинуть? Сейчас выпускаются новые серверы со
встроенными консолидированными адаптерами, но у нас-то стоят не менее дорогие,
но без адаптера...
Вопрос финансовой эффективности, безусловно, в данном случае, требует особой внимательности. Вот что можно посоветовать.
Если у вас уже есть ЦОД
1. Считайте ROI. Даже если у вас уже полностью построен ЦОД, затраты на его модернизацию окупаются. Учитывайте затраты на электроэнергию, каналы связи и фонд заработной платы.
2. Внедрение можно производить поэтапно. Начать с замены сетевой инфраструктуры в пользу Nexus, к которым подключать имеющиеся системы хранения данных и серверы. После чего постепенно переходить на новые модели серверов со встроенным адаптером.
3. Учитывайте новые функциональные возможности Nexus. Так, в частности, Nexus 7000 обладает новым сервисом TrustSec. Он решает нетривиальную задачу шифрования на уровне L2, при скоростях 10 Гбит/с и выше, столь необходимую при передаче данных между двумя разнесенными ЦОДами. Кроме этого, в новых Nexus с помощью функционала OTV решается задача предупреждения миграции ошибок приложений по магистральной сети между территориально рас-предиленными ЦОДами. Иными словами, локализация L2 доменов. Каждая из площадок в этом случае, несмотря на то, что ЦОДы связаны между собой по L2, рассматривается как отдельный домен. Поэтому ошибка, возникающая в приложении на одном ЦОДе, здесь же локализируется и решается в рамках только этой площадки, а не «бегает» по магистрали, загружая сеть.
Если вы собираетесь строить новый ЦОД
Для вас использование унифицированной инфраструктуры - в целом беспроигрышный вариант. При этом расчет ROI никто не отменял. По-хорошему, он должен предшествовать внедрению любой системы.
Особо хочу остановиться на случаях компаний, переживающих процессы слияний и поглощений. Как правило, сделки M&A ведут к практически полной перестройке всей вычислительной инфраструктуры. Это также хороший повод перейти на унифицированную инфраструктуру и получить все преимущества.
Особенности внедрения
Как и внедрение любой другой системы, реализация проектов по построению унифицированной сетевой инфраструктуры имеет ряд особенностей.
Во-первых, нужно помнить о том, что эта архитектура кардинально отличается от используемой ранее. Я бы даже сказал, это совершенно другая идеология. Поэтому наличие опыта у подрядчика, который реализует для вас такой проект, является как никогда критичным. В проекте для Кредобанка мы убедились в этом на собственном примере.
Во-вторых, для того чтобы систему запустить необходимо провести тщательный аудит текущего состояния. И, конечно же, лучше чтобы это делали профессионалы. В случае с молодыми компаниями, ситуация проще, здесь чаще всего используются бизнес-приложения от мировых производителей, прозрачные и понятные с точки зрения взаимодействия со всей инфраструктурой. Сложнее с большими, опытными компаниями, в которых параллельно работает иногда несколько сотен приложений. Более того, многие из них являются самописными, и подчас сложно найти разработчика или хотя бы человека, который четко может описать как оно работает. А ведь для того, чтобы корректно сконфигурировать сетевую инфраструктуру в унифицированной среде необходимо четко прописать: как работает приложение, какие задержки для него являются критичными, какие пакеты данных распространяются, по какому протоколу это приложение работает, кто к нему имеет доступ, а кто не должен иметь доступ, с какими приложениями оно еще взаимодействуют и как. Полученные правила ложатся в основу архитектуры и переносятся на оборудование.
Ну и, в-третьих, помните о том, что в этом
проекте работы проводятся на стыке нескольких подсистем, различных
технологических направлений. По каждому из них работают разные специалисты,
которые должны обладать одинаковым уровнем компетенции с одной стороны, но
уметь находить общий язык с другой. Не всегда разные подрядчики могут
обеспечить единый уровень качества и согласованность по разным подсистемам,
гораздо удобнее получать решение из «одних рук».
Вадим ЗАПАРОВАНЫЙ, ведущий
инженер-консультант Департамента сетевых технологий компании «Инком»
