Сценарии развертывания облачной сетевой инфраструктуры Microsoft с Windows Server 8 (часть 1) — традиционный центр обработки данных

Опубликовано: 9 Марта, 2023

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в режиме реального времени

Введение

Следующее поколение Windows Server, в настоящее время известное как Windows Server 8, рекламируется Microsoft как безопасное решение. облачная операционная система — с буквально сотнями новых функций и технологий, включенных в новую платформу Windows для поддержки облаков всех типов. Это технологии, о которых мы просили более десяти лет, и теперь они, наконец, здесь! Бета-версия стала доступна 1 марта и демонстрирует несколько довольно интересных новых функций. Но как именно вы будете разворачивать безопасную облачную инфраструктуру на базе новой операционной системы, обеспечивая при этом оптимальную производительность?

Я говорил об облачных вычислениях в нескольких других статьях на этом сайте и на нашем родственном сайте WindowsSecurity.com, поэтому не хочу повторяться. Если вам нужно хорошее объяснение облачных вычислений, посмотрите лекцию моего мужа о принципах, концепциях и шаблонах облачных вычислений, которую он прочитал на TechDays 2012 в Бельгии. А для ознакомления с защитой вашей облачной среды см. Решение для защиты частного облака. на вики-сайте TechNet.

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

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

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

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

Облако Windows 8 с использованием традиционного подхода к центрам обработки данных

Первый сценарий, который описывает Microsoft, — это то, что они называют облаком с использованием традиционного подхода к центру обработки данных, и вы можете увидеть, как это работает, на рисунке ниже. Облако использует преимущества отказоустойчивого кластера Windows, и каждый член отказоустойчивого кластера Windows будет настроен одинаково, используя одно и то же оборудование (при этом используется принцип гомогенности).

фигура 1

На этом рисунке мы видим, что каждый тип трафика выделен для своего сетевого интерфейса. К типам трафика относятся:

Трафик хранилища
Трафик Live Migration
Кластерный трафик
Управление трафиком
Гостевой или клиентский трафик

Тип сетевого адаптера, который вы используете для каждого типа трафика, зависит от скорости и возможностей, которые вы хотите включить для этого трафика. Новые технологии, включенные в Windows Server 8, которые поддерживают высокоскоростную и высоконадежную сеть, в основном доступны для новых сетевых адаптеров емкостью 10 ГБ, которые появляются на рынке. Проблема с новыми высокоскоростными сетевыми адаптерами на 10 ГБ заключается в том, что они очень дороги. Сами сетевые карты стоят дорого, и стоимость порта на коммутаторе 10 ГБ также очень высока. Поэтому вам необходимо подумать о профилях трафика для каждого из типов трафика и адаптировать планы вашей сетевой карты к потребностям этого трафика.

Северный / Южный трафик

В этом «неконвергентном» сценарии (где трафик к членам кластера и от него не конвергент к одному сетевому адаптеру) вам нужно подумать о двух основных типах трафика — первый тип, называемый «Север/ Южный» трафик — это трафик, перемещающийся между членами кластера и корпоративной сетью или Интернетом. Объем трафика север/юг, который у вас есть, в основном зависит от типов рабочих нагрузок, которые вы используете для своих клиентов. Если арендаторы в основном интенсивно используют вычислительные ресурсы, а не сеть, вы, вероятно, можете обойтись без использования объединенных сетевых карт емкостью 1 ГБ для поддержки этой «сети арендаторов».

Помните, что Windows Server 8 поддерживает сетевое объединение прямо из коробки! В прошлом поставщик сетевых карт должен был обеспечивать поддержку драйверов для объединения сетевых карт. Это было большой проблемой для большинства из нас, поскольку мы считали объединение сетевых карт жестким требованием в наших центрах обработки данных. Проблема усугублялась тем фактом, что если возникала проблема с объединением сетевых карт, служба поддержки Microsoft сообщала нам, что первое, что нам нужно сделать при устранении неполадок, — это отключить объединение сетевых карт. Потом началось тыкание пальцем. Благодаря встроенной поддержке команды NIC, которая не зависит от поддержки драйверов поставщика, нам больше не нужно беспокоиться о том, чтобы указать пальцем. Кроме того, готовое объединение сетевых карт будет работать с сетевыми картами разных поставщиков. Хороший!

Восток/Запад трафик

Другой тип трафика, о котором вам нужно подумать, называется трафиком «Восток/Запад». Трафик Восток/Запад — это трафик, который перемещается между различными компонентами облака. Этот трафик, как правило, имеет более высокие требования к скорости передачи данных и, вероятно, будет трафиком, для которого вы захотите рассмотреть высокоскоростные, дорогие сетевые интерфейсные карты на 10 ГБ. Движение Восток/Запад включает:

Трафик хранилища
Трафик Live Migration
Кластерный трафик
Управление трафиком

В целом трафик Live Migration, кластера и управления не будет сильно нагружать пропускную способность сети. Когда вы выполняете динамическую миграцию, вы не перемещаете само хранилище, вы просто перемещаете файлы конфигурации и содержимое памяти на другой член кластера Hyper-V. Если рабочая нагрузка невелика, Live Migration не должна требовать большой пропускной способности сети. Конечно, если вы выполняете рабочие нагрузки с объемом памяти 16 ГБ, 32 ГБ или более, требования к пропускной способности становятся значительными, и в этом случае вы можете подумать об использовании высокоскоростного сетевого адаптера 10 ГБ для трафика Live Migration. Но даже в этом случае служба продолжает работать даже во время Live Migration, и если во время Live Migration возникнет сетевое прерывание, она продолжит работу. Это означает, что даже если у вас есть рабочие нагрузки с высокими требованиями к памяти, вы, возможно, не сможете привести веские аргументы в пользу высокоскоростной сетевой карты на 10 ГБ. Вы можете объединить несколько сетевых адаптеров с пропускной способностью 1 ГБ и получить необходимую пропускную способность в большинстве случаев.

Для трафика кластера и управления трудно понять, где вам потребуется более одной сетевой карты для каждого из этих классов трафика. Кластерный трафик предназначен для управления состоянием кластера, что, безусловно, не будет облагать налогом сетевой адаптер емкостью 1 ГБ. И трафик управления также относительно мал по сравнению с пропускной способностью, обеспечиваемой сетевым адаптером емкостью 1 ГБ. Почти во всех случаях для кластера и трафика управления будет использоваться один несвязанный сетевой адаптер емкостью 1 ГБ, по крайней мере, с точки зрения пропускной способности.

Однако существует перспектива надежности, которую вы, возможно, захотите учесть. Поскольку облако предназначено для предоставления услуг и использования подхода поставщика услуг, вы можете захотеть использовать более одной сетевой карты для трафика Live Migration, кластера и управления. Имейте в виду, что «официальное» название объединения сетевых карт в Windows 8 — «Балансировка нагрузки и отказоустойчивость (LBFO)». До этого момента мы сосредоточивались на требованиях к пропускной способности, но также необходимо учитывать требования к высокой доступности.

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

Наконец, есть трафик хранилища. Хранение немного отличается, так как вы можете работать или не работать с Ethernet при подключении к хранилищу. Другие варианты включают Fibre Channel и Infiniband. Решения FC и IB, как правило, требуют больших затрат не только с точки зрения аппаратного обеспечения, но и с точки зрения поиска людей с опытом в этих областях для их развертывания. Напротив, решения для хранения данных на основе iSCSI и JBOD используют Ethernet, и, конечно, опыт в этой области является обычным делом.

Трафик хранилища требует высокой скорости и низкой задержки. Нам нужно максимально приблизиться к скорости автобуса для такого типа трафика. В прошлом это было большой проблемой, потому что сетевого оборудования и программного обеспечения, обеспечивающих производительность, близкую к подключенному к DAS хранилищу, просто не было — вот почему нам нужны FC и IB. Однако с выходом Windows Server 8 эта игра изменилась.

Новые технологии в Windows Server 8, такие как удаленный прямой доступ к памяти (RDMA) и блок сообщений сервера 2.2 (SMB 2.2), позволяют получить производительность хранилища примерно на 97 % выше, чем у хранилища с прямым подключением (DAS). Ух ты! Если вы объедините пару сетевых адаптеров по 10 ГБ для трафика хранилища, у вас будет в общей сложности более 20 Гбит/с вверх и вниз. Трудно набить такую большую трубу. И это понадобится вам для миграции живых хранилищ, которую вы сможете выполнять с помощью Windows Server 8 Hyper-V.

Резюме

В этой статье мы начали с краткого введения в облако и вопросов, связанных с облачной сетевой инфраструктурой. Затем мы описали первый из трех сетевых сценариев облачного центра обработки данных, в котором каждому классу трафика был назначен отдельный физический сетевой адаптер или отдельные группы физических сетевых адаптеров. Мы обсудили некоторые из новых технологий Windows Server 8, которые оптимизируют сетевую инфраструктуру для облака, а также некоторые соображения, которые следует учитывать при рассмотрении трафика север/юг и восток/запад. В следующей статье мы закончим рассказом о двух других сценариях развертывания облачных сетей. Тогда увидимся! – Деб.