Инженерная инфраструктура центров обработки данных (ЦОД)

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

«Облако» основано только на программном обеспечении

Теоретически вполне можно построить облако на стандартных серверах (x86) и интеллектуальном программном обеспечении. Объединяем несколько виртуальных устройств и получаем «облако». Но на самом деле это далеко не так. По разным причинам, таким как поддержание адекватной производительности (специализированные ASICs или выделенные аппаратные ресурсы), обеспечение совместимости (установка драйверов для каждой новой платформы x86), или функций контроля (HIPPA, PCI-DSS, ведомственная изоляция, и т. д.), еще далеко не все системные разработчики отказались от использования выделенных аппаратных ресурсов для определенных элементов своих дата-центров. В принципе неизбежность виртуализации некоторых компонентов компьютерной среды очевидна. Поэтому лидеры рынка выпускают соответствующее оборудование. Например, Nexus 1000v, который обеспечивает прозрачность трафика виртуальных машин на уровне сетевой безопасности, с встроенной технологией VN-Link, обеспечивающей мобильность сети. А также виртуальный шлюз безопасности и vWAAS. В одних случаях, клиенты выбирают виртуальные устройства. В других случаях, они предпочитают комбинацию программных и аппаратных ресурсов, например, контрольных точек, представленных Nexus 1010v. Все эти унифицированные сетевые услуги обеспечивают системных разработчиков стандартным набором приемов, позволяющих в случае необходимости совместно использовать программные и аппаратные ресурсы.

«Облако» и эластичные ресурсы

У многих поставщиков сетевого оборудования идея эластичных ресурсов не полностью реализована. Дело в том, что понятие «эластичных ресурсов» не должно ограничиваться только серверами и системами хранения данных, оно должно распространяться на все «облако», в том числе его сетевые элементы.

«Облако» и объединенные ресурсы

Это еще одна область, которую многие связывают только с серверами и системами хранения данных. В течение многих лет, до появления «облака», сеть представляла собой комплексный ресурс, который предоставлял услуги (полоса пропускания, безопасность, сегментация или изоляция, функция QoS, и т. д.) отдельным группам систем. По мере того как сети становились более виртуальными, более автоматизированными, а также росло число их арендаторов, компании, предлагающие решения на этом рынке продолжали расширять интеллектуальную логику своих продуктов, требуемую для функционирования современных «облачных» систем. Эти решения позволяют клиентам развертывать модульные виртуальные системы (например такие, как Vblock и SMT от Cisco).

Виртуализация делает «облако» более гибким

С одной стороны, это абсолютная правда, в отношении динамического распределения ресурсов и оперативного включения новых виртуальных машин с помощью шаблонов и клонов. Однако, это требует некоторых структурных изменений. Например, при использовании vMotion, Live Migration или XenMotion исходная и конечная точки должны быть в одном логическом домене.

А опрос администраторов виртуальных систем показал, что за месяц им приходится выполнять тысячи миграций виртуальных машин. Итак, в дополнение к этой гибкости им осталось только упразднить традиционное разграничение уровней. Для этого им нужно дать возможность строить большие, двухуровневые сети, лишенные постоянных проблем иерархических сетей.

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

Виртуальная машина – это тот же сервер, только программный

Это не совсем так. Действительно, приложение и гостевая операционная система, наверное, не видят никакой разницы, но сетевым администраторам и службе безопасности это совсем не безразлично. Виртуальная машина больше не начинается и не заканчивается на одном конце кабеля Ethernet. Фактически, ее трафик может вообще не иметь отношения к данному кабелю, если она общается с другой виртуальной машиной в пределах одного и того хоста. Или же она может по нескольку раз в день переходить с одного хоста на другой, занимая тем самым гигабайты трафика (виртуальная машина и система хранения данных). Поэтому гораздо разумнее ввести в «облаке» функцию регистрации всех этих миграций, назначить этим виртуальным машинам определенные политики (безопасность, функция QoS, ролевая система доступа, и т. д.), чтобы ограничить их перемещение в определенные места, и, тем самым, расширить возможности службы технической поддержки. Большинство администраторов виртуальных машин было бы радо получить такие возможности, особенно сейчас, когда у них стали требовать данные о виртуальных машинах, резервном копировании, восстановлении в аварийных ситуациях, гостевой операционной системе, системе хранения данных и всех остальных элементах, которые так или иначе связаны с виртуализацией.

«Облака» планируются, а сети администрируются

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

Мы могли бы продолжить этот список, но будем надеяться, что вы уже начинаете представлять себе общую картину. В то время как «облако» предоставляет конечным пользователям и приложениям невероятные возможности, оно предъявляет определенные требования к уровню сетевой безопасности. И эти требования можно эффективно реализовывать в рамках программных и аппаратных платформ. Если же вы ограничиваете свою архитектуру только сетями с высокой проходимостью, то вы гораздо быстрее исчерпаете свои ресурсы расширения.