Оптимизация инфраструктуры центра данных

Иван Пепельняк

Иван Пепельняк

Мало какие корпоративные центры обработки и хранения данных (ЦОДы или ЦОХДы), суще­ствующие на сегодняшний момент, требуют более двух коммутаторов, поэтому обсуждение коммутационных матриц и сравнение характеристик матриц от различных поставщиков не имеет большого смысла.
Но, как всегда, вы можете оказаться исключением. Вдруг у вас десятки тысяч виртуальных машин? Или огромные кластеры Hadoop? Или что-то другое, но столь же масштабное: например, базы данных SAP HANA или гигантские кластеры БД Oracle? Короче, вам вполне может оказаться нужна крупная коммутационная матрица. Однако сразу скажу: за последние пять с лишним лет я очень редко встречал заказчиков, которым не хватило бы двух коммутаторов последнего поколе­ния для ЦОДа (правда, сами клиенты обычно так не думали).

Краткий исторический экскурс
Года где-то до 2010 мы рекомен­довали сетевую инфраструктуру центров данных, похожую на ту, что изображена на рисунке 1.
Коммутаторы ЦОДов в те времена были на порядок слабее нынешних. У них также было меньше портов, из-за чего нам приходилось строить сети в три уровня: ядра, агрегиро­вания и доступа. Просто потому, что подключить все сразу к центральному коммутатору было нельзя.
Мало того, обычно нам приходилось еще обсуждать границу между пересылкой уровня 2 (сетевые мосты) и уровня 3 (маршрутизация), чтобы решить, надо ли нам распространять одну VLAN на весь ЦОД, ограничив­шись функционалом уровня 3 только в ядре, или же использовать мосты только на уровне доступа, а провести границу L2/L3 на уровне агрегирова­ния.
В существующих крупных ЦОДах обычно встречаются три решения этой проблемы:

• маршрутизация в ядре (включая аплинки к коммутаторам агрегации) и мосты внутри уровня агрегации; или
• маршрутизация на коммутаторах ядра и мосты через ядро;
• сети ЦОД на основе мостов с марш­рутизацией на сетевых приставках (брандмауэры или балансировщики нагрузки).

Независимо от того, где проходит граница между уровнями 2 и 3, в традиционных ЦОДах обычно было три уровня и множество коммутаторов. Конечно, попадались и ЦОДы, где все подключалось к двум Catalyst 6500, но как правило, в небольших фирмах.
Использование современных технологий ЦОД
Используя современные технологии и агрессивную виртуализацию, мы можем избавиться от большей части инфраструктуры ЦОД и построить нужную вам физическую инфраструк­туру всего на двух коммутаторах за несколько простых для понимания шагов:

• виртуализовать серверы;
• отказаться от устаревших технологий;
• сократить число аплинков на каж­дый сервер;
• использовать распределенную фай­ловую систему;
• виртуализовать сетевые сервисы;
• построить оптимизированную коммутационную матрицу из двух коммутаторов.

Виртуализация серверов
Первый шаг на вашем пути к опти­мизированной инфраструктуре центра данных – это беспощадная виртуа­лизация. Однако меня не перестает удивлять, сколько народу так и не внедрило виртуализацию всерьез.
С другой стороны, множество пред­приятий виртуализовали не менее 95% своей рабочей нагрузки, и все, что у них сейчас работает на «чисто железных» серверах, – это большие БД или приложения, которые иначе как на физическом сервере запустить невозможно.
Виртуализация большей части нагрузки целесообразна практически в любой среде. Например, мы много лет назад виртуализовали менеджер вызовов Cisco, хотя это тогда офици­ально не поддерживалось. Я знаю людей, у которых на виртуальных машинах работают базы данных Oracle, хотя сама Oracle поддерживает такое решение лишь ограниченно. У других моих знакомых на виртуальных машинах работают базы данных SAP HANA, ворочая более терабайта оперативной памяти.

Как только вы виртуализуете нагрузку и обретете гибкость, можно переходить к выбору подходящего размера серверов. Современные сер­веры поддерживают CPU с большим числом ядер на каждый процессор и большим числом сокетов CPU на каждый сервер. Поэтому часто можно увидеть более 50 виртуальных машин (ВМ) приличного размера (4 ГБ оперативной памяти, 1 vCPU) на одном типовом сервере.
Чтобы оптимизировать размеры серверов под вашу среду, используйте следующую последовательность действий (в предположении, что вы знаете типовые требования к ВМ):

• выберите тип сервера, который не­плохо вам подойдет;
• определите, сколько ВМ уместится на таком сервере – по числу ядер CPU, которые поддерживает выбран­ный сервер, типовому размеру ВМ и желательному уровню переисполь­зования vCPU;
• вычислите необходимый объем ОЗУ для сервера – по числу ВМ и типово­му расходу ОЗУ на каждую вирту­альную машину;
• найдите ограничивающий фактор, будь то число ядер или объем ОЗУ, и повторяйте процедуру до тех пор, пока не получите на выходе модель сервера с оптимальной стоимостью в пересчете на ядро.

Обычно выгоднее всего в пересчете на ядро оказываются серверы средне­го уровня, но так как производители серверов непрерывно обновляют свои линейки, процедуру придется повторять каждый раз при покупке новой партии серверов.
Реальна ли виртуализация высокой плотности?
Когда я рассказываю о концепции виртуализации высокой плотности, я как правило получаю два типа ответов: а) «да, мы так и делаем» и б) «какой дурак так делает?»
Как всегда, лучше основывать свои решения на данных, чем на эмоциях. Когда Фрэнк Деннеман (Frank Denneman) работал в PernixData (теперь в составе Nutanix), он вел корпоративный блог. В одном из постов он описал анонимную стати­стику, собранную по тысячам серверов ESXi (vSphere) у заказчиков. Вот что выяснилось (http://frankdenneman. nl/2015/12/23/insights-into-cpu-and-memory-configuration-of-esxi-hosts/):

• У большинства серверов два сокета (84%) и от 8 до 24 ядер (у 25% было по 16 ядер). Получается, что самая распространенная конфигурация сервера – это два сокета с 8 ядрами на сокет.
• У большинства хостов ESXi от 192 до 512 ГБ оперативной памяти, причем почти 50% приходится на интервал от 256 до 384 ГБ.

Правда, PernixData – стартап, а потому его клиенты могут быть более продвинутыми, чем средний корпоративный заказчик. Следует ожидать, что типовой корпоративный ЦОД окажется более «отсталым».
В предположении, что типичная небольшая ВМ потребует 4 ГБ памяти, на сервере, описанном в исследовании PernixData, можно будет запустить 60-70 виртуальных машин. Даже для более производительных ВМ и при небольшом уровне переиспользова­ния цифра в 50+ виртуальных машин на сервер выглядит реальной.
В другом посте Фрэнка обсуждались данные по плотности ВМ . Тут мы видим еще более интересную картину, так как данные о плотности оказались совершенно разнородными: от 10 и менее виртуальных машин на хост до 250 и более. Однако, если исключить из рассмотрения экстремально мелкие случаи, на 70% из обследованных хостов оказалось более 20 ВМ, а на 34% из обследованных хостов их было более 50. Напрашивается вывод, что многие заказчики ставят по много ВМ на свои хосты ESXi.
В тему: знакомый инженер как-то рассказывал, что регулярно видит хосты ESXi с малым количеством ВМ, но при этом на них впустую пропадает чудовищное количество ресурсов. «Можно было втиснуть в эти хосты больше, – говорил мне коллега, – но почему-то они так не делают».
Еще один источник данных – индекс Cisco Global Cloud (см. рис.2), который показывает плотность ВМ гораздо ниже обсуждавшейся. Не знаю, почему так происходит. Может, облачные провайдеры используют маломощные серверы? Или участники опроса только начали процесс виртуализации нагрузки?
Краткий итог: на один физический сервер среднего уровня без проблем влезет несколько десятков ВМ. В качестве первого этапа консолидации избавьтесь от «чисто железных» серверов и втисните свою нагрузку в как можно меньшее число вирту­ализационных хостов оптимального размера.

Вопросы для обсуждения
Вы сами видели гигантские ВМ, такие как базы данных, особенно БД с размещением в оперативной памяти, или для этого все-таки используются «чисто железные» серверы?
Я видел гигантские ВМ (30+ ядер, 1 ТБ ОЗУ) и у общедоступных облачных провайдеров, и в корпоративных центрах данных. Как правило, они конфигурируются по одной ВМ на сервер.
Огромные рабочие нагрузки виртуализуются для упрощения обслуживания: размещение сервера БД на виртуальной машине позволяет разнести обслуживание железа и обслуживание сервера.
Например, если потребуется апгрейд сервера, замена оборудования или обновление ядра гипервизора, можно перенести ВМ заказчика на другой эквивалентный сервер и спокойно выполнить техобслуживание оборудо­вания или гипервизора.
Либо, если вам нужен апгрейд виртуализованного сервера (требуется добавить больше процессоров или памяти), провайдер может перенести вашу ВМ на более мощный физиче­ский сервер, а затем просто сменить настройки виртуальной памяти и вир­туальных процессоров, не прерывая работу ВМ. В худшем случае придется перезапустить ВМ, что на порядок быстрее, чем копание в физическом сервере и установка дополнительных процессоров или памяти.
У большинства заказчиков со сверх­большими ВМ выполняется одна ВМ на физический сервер, но они все же используют виртуализацию по описан­ным выше причинам. Однако будьте осторожны при создании ВМ с очень большим числом ядер CPU. Например, если ВМ вашей базы данных требует 32 ядер, она не запустится до тех пор, пока не станут доступны как минимум 32 ядра. Поэтому выполнение 32-ядерной ВМ на 32-ядерном сервере приведет к падению быстродействия: каждый раз, когда гипервизору потребуется запустить новую задачу, он остановит ВМ, и в это время большинство ядер будет простаивать. Обязательно держите на физическом сервере больше ядер, чем требуется для ВМ.
Имеет ли смысл виртуализовать кластеры Hadoop?
Ответ на этот вопрос зависит от двух аспектов:

• Какой уровень гибкости вам нужен?
• Сколько ресурсов может потребо­вать сервер?

Если ваши серверы (или задания, которые на них выполняются) долгоживущи, имеет смысл их вир­туализовать. Если вы планируете независимые краткосрочные задания, которые не используют постоянных данных на серверах, то неважно, вир­туализованы они или нет – их в любой момент можно будет отключить.
Еще одно соображение: если ваши серверы Hadoop могут захватить все ядра CPU (или все ОЗУ) на физическом сервере (я предполагаю, что вы выполнили описанную выше процедуру и нашли оптимальную конфигурацию физического сервера), то виртуализация кластера Hadoop может и не иметь смысла, помимо преимуществ при техобслуживании/ модернизации.
Если же рабочая нагрузка на сервере не может захватить все его ресурсы ОЗУ и процессоров, то опять же виртуализация имеет смысл, чтобы выжать максимум из купленных физических ресурсов.
Универсального ответа тут нет. Единственный способ понять, можно ли выжать больше из имеющегося оборудования – мониторинг исполь­зования ресурсов на физических серверах.
Долой старье
Если вы хотите продолжать опти­мизацию вашей сети центра данных, необходимо отказаться от устаревших сетевых технологий, в первую очередь от Gigabit Ethernet в качестве основно­го средства связи между серверами и сетью.
Сегодня применение Gigabit Ethernet имеет смысл для внеполосного управления или в сетях iLO/KVM.

Краткий экскурс в прошлое
Хотя в начале 2010-х годов некоторые прогрессивные заказчики и думали о 10 Gigabit Ethernet (10GE), мы все еще настоятельно рекомендовали использовать для серверных соедине­ний Gigabit Ethernet (GE). В основном потому, что GE был хорошо известной и проверенной на деле технологией, которая уже имелась на материнских платах большинства серверов. Кроме того, GE поддерживал медные кабели, которые тогда не поддерживались 10GE.
Основным недостатком соединений GE было большое количество необходимых интерфейсов на одном сервере. По правилам дизайна VMware рекомендовалось иметь от четырех до десяти интерфейсных карт GE на один хост ESX (две для пользовательских данных, две для хранения, две для vMotion…). Также было невозможно консолидировать хранение и сеть, реализовать передачу данных без потерь по сетям GE без ущерба для обычного сетевого трафика.
В те дни ЦОДы, устанавливавшие каналы 10GE, уже использовали быстрый vMotion, а также объединяли инфраструктуры хранения и сети. Установка 10GE NIC также позво­ляла сократить число физических интерфейсов, хотя приходилось использовать аппаратные «фишки» вроде сетевой платы Cisco Palo, кото­рая разделяла физическую сетевую плату на несколько виртуальных NIC, на которых можно было реализовать правила дизайна VMware – у самих ESXi в те дни не было встроенного QOS.
Нынешние рекомендации
Если вы строите сети для нового центра данных, я вас буквально умоляю не использовать GE в качестве основной технологии подключения серверов: только для сети внеполос­ного управления – и нигде больше. Для основных каналов подключения серверов используйте 10GE и выбирайте коммутаторы, которые уже сейчас поддерживают каналы 25GE: через несколько лет на серверных материнских платах появятся сетевые карты 25GE.
В наши дни 10GE открывает массу возможностей для подключения:

• Можно использовать 10GBASE-T, если вам нужны медные кабели в рамках стойки или небольшого кластера. Коммутаторы с портами 10GBASE-T предлагают практически все поставщики коммутаторов, и нетрудно купить серверы со встро­енными интерфейсами 10GBASE-T.
• Если вам нужно использовать ин­терфейсы SFP+ или QSFP, возьмите твинаксиальный кабель для корот­ких расстояний и оптоволокно для длинных.

История из реальной жизни
В конце 2014 года меня пригласили проверить дизайн ЦОДа для финансовой организации, которая модернизировала сеть в своем дата-центре.
Заказчик менял старые коммутаторы Catalyst 6500 на новые коммутаторы от другого поставщика. У новых коммутаторов были только серверные соединения 1GE и аплинки 10GE, поэтому я спросил: «Почему? На дворе 2014 год, почему вы не покупаете 10-гигабитные линки?». И получил ожидаемый ответ: «у нас все серверы в центре данных с гигабитными NIC».

Следующий вопрос: «О’кей, вы сейчас купите коммутаторы с интер­фейсами GE, которые через несколько лет устареют. И как вы будете к ним подключать серверы нового поколения с 10GE NIC, которые вы рано или поздно все равно купите?»
К сожалению, тут сделать ничего было нельзя. Мои собеседники прекрасно понимали, что делают не лучший выбор, но серверы покупались вообще из другого бюджета, поэтому модернизация серверов никогда не синхронизировалась с модернизацией сети. Кроме того, раз большинство серверов требовало нескольких соединений GE, покупать для них коммутаторы с портами 10GE было бы неоправданно дорого.
Вывод: если вы хотите консо­лидировать свой центр данных и оптимизировать затраты, учитывайте сразу все компоненты центра данных (серверы, системы хранения и сеть), а при необходимости модернизируйте все компоненты одновременно.
Вопросы для обсуждения
Мы рассматриваем возможность перехода на 10GE, но нас отпуги­вает стоимость подлинных SFP, а вендоры не хотят поддерживать твинаксиальный кабель в смешанной среде – например, при использовании коммутаторов Cisco с серверами IBM, поэтому мы предпочли бы 10GE оптоволокно.
Понятно, что поставщики сетевых решений просто вынуждены работать с высокой маржой, чем можно объяснить тот факт, что модули RAM и SFP у них стоят дороже; но цифры, приведенные в статье, уже не лезут ни в какие ворота.
Похоже, что крупные поставщики решений для центров данных закла­дывают в цену SFP-модуля скрытую лицензионную плату за порт, чтобы снизить стоимость базового оборудо­вания и заработать побольше на SFP, которые вы вынуждены покупать у них же.
Возможно, ситуация улучшится по мере того, как появятся небрендовые коммутаторы, а инженеры центров данных поймут, что их тоже можно использовать в некоторых средах, но пройдет еще немало времени, пока корпоративные центры данных решатся покупать noname-коммутато­ры под управлением ПО независимых разработчиков.
Сокращение числа аплинков «сервер-сеть» в вашем центре данных
Простой способ свести к минимуму число трансиверов, кабелей и сете­вого оборудования в центре данных – минимизировать число аплинков на каждый сервер. Вроде бы, просто, но путь к этой цели редко бывает тривиальным.
Первое препятствие на вашем пути – то, что архитекторы виртуали­зации часто используют устаревшие руководства по дизайну vSphere. На рисунке 3 приведено сравнение рекомендаций VMware для ESXi версии 4 и более новых рекомендаций для ESXi версии 5 и выше.
В vSphere версии 4 не было QoS, а потому VMware рекомендовала использовать отдельные интерфейсы для трафика ВМ, для трафика ядра (например, VMotion) и для трафика хранения. В результате с минималь­ным резервированием получалось не менее шести сетевых интерфейсов на сервер.
Даже в vSphere 4 можно было проектировать более оптимальные сети, используя функции QoS из Cisco Nexus 1000V либо виртуальные сетевые интерфейсы из лезвийных шасси UCS.
В vSphere 5 компания VMware реализовала зачатки QoS под названи­ем NIOC (Network I/O Control) и начала рекомендовать по два интерфейса 10GE на сервер с настройкой QoS на серверных аплинках для выделения полосы трафику ВМ, хранения и vMotion.
Напомню, что сейчас используется vSphere 6, а vSphere 5 появилась в 2011 году. К сожалению, я слышал про шесть сетевых карт на каждый сервер долгие годы после выхода vSphere 5.
Как эти изменения рекомендаций по дизайну влияют на вас, если вам требуется перейти от старого сервера под управлением vSphere 4 на новый, более мощный, под управлением vSphere 5 или 6? Можно повысить уровень виртуализации (например, от десяти ВМ на сервер до 50 ВМ на сервер), в то же время сократив число интерфейсов.
Если почти десять лет назад у вас был коммутатор Gigabit Ethernet на 48 портов, к нему можно было подклю­чить шесть серверов и 80 ВМ. Сегодня к одному коммутатору 10GE на 48 портов можно подключить 24 сервера, на которых будет работать до тысячи виртуальных машин – таким образом, размер сети и ее сложность сократятся радикально.
После консолидации сетевых интер­фейсов на серверах пришло время пересмотреть дизайн сети хранения данных. На традиционных серверах были интерфейсы Ethernet, выделен­ные для ВМ или трафика управления, и отдельные интерфейсы Fibre Channel для хранилищ. В современном дизайне весь трафик консолидируется в одном наборе аплинков и исполь­зуется хранилище на базе IP или FCoE (см. рис.4).
Замена Fibre Channel на IP-хранилища (NFS или iSCSI) позволяет значительно снизить число портов и сложность:

• число серверных аплинков (вместе с оптикой и кабелями) сокращается вдвое;
• число коммутаторов доступа (ли­стьев) сокращается вдвое;
• убирается целый технологический стек.

Инженеры систем хранения данных старого закала не доверяют IP-хра­нению, потому что не имели дела с технологиями хранения на основе IP. С другой стороны, немало крупных предприятий уже не первый год эксплуатируют крупные системы на базе iSCSI или NFS.
Если вам по-прежнему нужна поддержка Fibre Channel в вашем центре данных (например, для подключения устройств резервного копирования на ленту), постарайтесь консолидировать серверные аплинки. Замените раздельные интерфейсы LAN и SAN на каждом сервере (это минимум четыре порта) на два порта 10GE с поддержкой FCoE.
Консолидация Fibre Channel и Ethernet между серверами и коммута­торами доступа вдвое снижает число точек управления, так как вам больше не нужны отдельные коммутаторы доступа для Fibre Channel и Ethernet.
Если вы хотите использовать FCoE между серверами и коммутаторами доступа, разделите трафик Fibre Channel и Ethernet на коммутаторах доступа и организуйте отдельные ядра Fibre Channel и Ethernet. Multihop FCoE привносит в дизайн ненужный уровень сложности.

Некоторые архитекторы систем хранения предпочитают отделять сети iSCSI от сетей данных или как минимум использовать отдельные каналы «доступ-ядро» и выделенные коммутаторы в ядре для iSCSI-компо­нента сети.
Однако, если вы уже выполнили остальные действия по консолидации, вам будет нетрудно настроить серверы на пересылку данных ВМ в основном через один коммутатор доступа, а другой можно задействовать прежде всего для iSCSI или NFS (при этом каждый из коммутаторов будет реализовывать все функции резерви­рования для другого).
Конечный результат: до тех пор, пока все порты работают, данные ВМ и данные хранения смешиваться не будут – они относятся к двум разным VLAN и используют отдельные ком­мутаторы доступа. Но стоит одному из коммутаторов доступа или линии от сервера к коммутатору отказать, как весь трафик автоматически переключается на второй коммутатор или линию.
Использование распределенной файловой системы
Предыдущие шаги по оптимизации инфраструктуры центра данных (от массивной виртуализации до перехо­да к двум аплинкам 10GE на сервер) уже нашли одобрение в индустрии. А вокруг использования распределенной файловой системы (VMware VSAN, Nutanix, Ceph или GlusterFS) все еще ломают копья.
Основополагающая идея очень про­ста. Вместо традиционных массивов хранения данных можно организовать локальное хранение на хостах гипер­визора (на жестких дисках или SSD) в распределенной глобальной файловой системе с репликацией между узлами гипервизора по IP-сети центра данных (см. рис.5).
Преимущества такого подхода очевидны:

• нужно меньше различных аппарат­ных компонентов;
• повышается устойчивость: центра­лизованные компоненты высокой доступности (массивы хранения) заменяются на распределенную сеть дешевых устройств;
• сокращается потенциал для сбоев – отказ одного узла в распределенной файловой системе меньше влияет на общую систему, чем отказ масси­ва хранения;
• повышается общее быстродей­ствие… если, конечно, гипервизоры в первую очередь обращаются к собственной локальной файловой системе;
• линейное масштабирование быстро­действия – чем больше узлов в рас­пределенной файловой системе, тем больше ее общее быстродействие.

Недостатки у распределенных файловых систем тоже имеются, как очевидные, так и не очень:

репликация данных между узлами требует высокопроизводительной сети центра данных;

• репликация в трех направлениях, используемая многими распреде­ленными файловыми системами, дает перегрузку в 200% по сравне­нию с 20-25% для RAID-6 (если ис­пользуется один массив хранения);
• сетевая инфраструктура становится критическим компонентом – отказ сети быстро приводит к полному коллапсу хранения;
• распределенные файловые системы еще не достигли такой зрелости, как дисковые массивы, а администрато­ры систем хранения данных – народ пугливый и консервативный.

Несколько лет назад у распределен­ных файловых систем не было шансов в большинстве корпоративных сред, даже несмотря на то, что Hyper-V и Linux поддерживали распределенные файловые системы уже довольно давно.
Сегодня распределенные файловые системы успешно работают в ряде очень крупных инсталляций. Например, общедоступные облака, построенные на базе OpenStack, часто используют Ceph или GlusterFS, или даже Swift (хранилище объектов OpenStack) для хранения образов ВМ.
Среды vSphere были последним бастионом традиционного подхода к хранению. Первая распределенная файловая система под vSphere была создана Nutanix, потом через несколь­ко лет появилась VMware VSAN (VSAN вышла в конце 2013 года).
Очевидно, вряд ли удастся убедить кого-либо хранить базу данных Oracle в распределенной файловой системе, но можно найти распределенную файловую систему, достаточно хорошую для виртуальных дисков ВМ, что позволит снизить требования к дисковым массивам.
Виртуализация сетевых сервисов
После виртуализации вычисли­тельных ресурсов и инфраструктуры хранения пришло время виртуализо­вать сетевые сервисы – а в последние несколько лет предложения виртуаль­ных сетевых устройств от различных поставщиков посыпались на рынок одно за другим. К сожалению, эти устройства обычно представляют собой всего лишь традиционные продукты в «обертке» для ВМ-фор­мата, с низкоуровневым кодом пересылки пакетов, переписанным для паравиртуальных драйверов.
Начнем с виртуальных маршрутиза­торов. Vyatta (теперь Brocade, часть Broadcom – прим. ред.) был, возможно, первым коммерческим виртуальным маршрутизатором, за ним последовал Juniper со своей виртуальной SRX (сейчас мы не будем касаться вопроса о том, правильнее считать vSRX марш­рутизатором или брандмауэром). Несколько лет назад Cisco выпустила Cloud Services Router (IOS-XE), а сегодня каждый крупный поставщик сетевых решений (включая HP и Alcatel-Lucent, теперь в составе Nokia) предлагает виртуальный маршрутизатор. Также имеются продукты для провайдеров коммуникационных услуг в виртуаль­ном формате, такие как Cisco IOS XR или Juniper vMX.
Каждый крупный поставщик бранд­мауэров предлагает виртуальный брандмауэр. Началось это уже давно, с Juniper vSRX, через несколько лет Cisco выпустила vASA и ASAv, затем после­довали Palo Alto и Checkpoint. На рынке балансировщиков нагрузки ситуация примерно та же. Сейчас в виртуальном формате предлагаются уже практически любые сетевые устройства.
Зачем может потребоваться замена физических сетевых устройств виртуальными? Вы немедленно обретаете большую гибкость, так как развертывать виртуальные устройства можно по мере надобности. Нет задержки на покупку новых стоек и кластеров, а иногда можно исполь­зовать временные лицензии, чтобы упростить процедуру приобретения и развертывать сетевые сервисы по требованию.
Интересно, что как только что-то начинает работать в производстве по временной лицензии, бюджет обычно перестает быть проблемой.
Виртуальные приставки также упро­щают дизайн для высокой доступности и аварийного восстановления:

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

В ЦОДе аварийного восстановления, построенном по виртуальным технологиям, вам нужно лишь то оборудование, которое обеспечит достаточно вычислительной мощности для обработки дополнительной нагрузки при отказе основного центра.
Экономия при использовании виртуальных устройств стала настоль­ко очевидна, что у F5 виртуальный балансировщик нагрузки стоит дороже физического: они знают, что вы купите только один, в то время как физиче­ских нужно четыре.
Мы уже говорили о том, как виртуальные устройства сокращают время развертывания. Они также минимизируют требования к запас­ному оборудованию: вам больше не нужен запасной маршрутизатор, брандмауэр, балансировщик нагрузки, IDS или дорогостоящий контракт на техобслуживание всего этого железа – все ваши сетевые сервисы работают на унифицированной компьютерной инфраструктуре.
И, наконец, виртуальные устрой­ства упрощают инфраструктуру физической сети. Вместо спутанного клубка из аппаратных устройств, подключенных к коммутаторам в ЦОДе (см. левую часть рисунка ниже), мы получим серверы, подключенные по схеме «ствол и листья».
Можно сказать, что мы виртуали­зовали этот клубок – и это будет правильно (см. рис.6).
Пойдем дальше: если вы захотите использовать распределенную файло­вую систему и виртуальные сетевые устройства в вашем центре данных, то вам потребуется всего два аппаратных компонента: коммутаторы и серверы. Представьте, насколько сократятся расходы на техобслуживание!
Некоторые инженеры дошли до того, что подключили свое закрытое облако к общедоступному Интернету прямо через виртуальные SRX на своих серверах.
Создание оптимизированной коммутационной матрицы
Подведем некоторые итоги. Мы:

• виртуализовали все серверы;
• перешли на 10GE (или 25GE);
• сократили число серверных аплин­ков (и портов коммутаторов);
• распределили хранение по хостам гипервизора; и
• виртуализовали сетевые сервисы.

В результате каждый вычислитель­ный ресурс (включая сетевые сервисы) оказался виртуализован, и вы можете разместить все это на гораздо мень­шем количестве хостов гипервизора, чем раньше.

Создание кластера сетевых сервисов
Всегда, за исключением очень маленьких сред, где просто нельзя оправдать дополнительные капита­ловложения, запускайте виртуальные сетевые устройства на отдельных физических серверах – из соображе­ний безопасности и быстродействия.
Если ваши виртуальные устройства подключаются непосредственно к общедоступной сети, подумайте о выделенных интерфейсах Ethernet для подключения к общедоступной сети, чтобы полностью отделить внутреннюю матрицу ЦОД от внешней сети, как показано на диаграмме, представленной на рисунке 7.
Создание физической инфраструктуры коммутации
Сколько коммутаторов вам нужно в оптимизированном дата-центре? По самой приблизительной оценке, двух коммутаторов вам хватит примерно на две тысячи виртуальных машин. Иван Раабок (Iwan Rahabok) проделал более тщательный анализ (http:// virtual-red-dot.info/1000-vm-per-rack-is-the-new-minimum/) и вычислил, что можно уместить примерно тысячу ВМ в одной стойке (он принял для расчетов весьма консервативный коэффициент виртуализации 30:1), а все хосты ESXi, необходимые для этого, подключить к двум коммутато­рам ToR.
Абсолютно все изготовители коммутаторов для центров данных предлагают 64-портовые коммутаторы 10GE или 25GE. Иногда в специфика­циях говорится, что у коммутатора 48 портов 10GE и 4-6 портов 40GE, но порты 40GE обычно можно развести на четыре канала по 10GE (а порты 100GE – на четыре канала 10GE или 25GE).
Cisco часто является исключением из этого «правила». Многие из ее коммутаторов используют тот же самый кремний Broadcom, что и конкуренты, но дают вам только 48 портов, потому что чипсеты Broadcom (в частности, чипсеты Trident-II) не могут пересылать небольшие пакеты со скоростью линии.
Также имеется ряд поставщиков (включая Cisco), предлагающих коммутаторы высотой 1 RU или 2 RU с более чем 64 портами на коммутатор – начиная с 96 портов 10GE у Cisco 93120 до 128 портов 10GE в некоторых коммутаторах Dell, Arista или Juniper.
Подытожим: если в вашем ЦОДе не более 2000 серверов (физических серверов или ВМ) и вы можете их виртуализовать, то вам скорее всего не потребуется больше двух комму­таторов. Большинство корпоративных дата-центров с запасом попадают в эту категорию.
Вопросы для обсуждения
Как реализовать обходные пути (multipathing) для уровня 2 в таком простом центре данных, не используя TRILL (или FabricPath) или VXLAN?
В простой сети на два коммутатора один из них используется в качестве основного для всего трафика ВМ, а второй в качестве основного для всего трафика хранения, поэтому необхо­димости в балансировке нагрузки или обходных путях просто не возникает.
Если коммутаторов больше двух, то, очевидно, потребуются обходные пути, так как нельзя ограничивать себя остовным деревом. В таких случаях я бы настоятельно рекомендовал VXLAN на коммутаторах ToR (Top of the Rack) или (если ваши коммутаторы не поддерживают VXLAN) MLAG между границей сети и коммутаторами ядра.
Если вы разделяете трафик iSCI и ВМ между двумя коммутаторами, то какой метод лучше подойдет для отказоустойчивости на случай отказа одного коммутатора?
Очевидно, оба коммутатора должны находиться в одной VLAN, т.е. ваша сеть из двух коммутаторов должна быть чистой сетью уровня 2 с мостами через канал между маршрутизатора­ми.
Дальше настройте простую отказоу­стойчивость на ваших хостах vSphere или KVM. Для каждого типа трафика создайте один основной аплинк и один резервный.

Об авторе
Иван Пепельняк, почетный член CCIE (CCIE#1354), занимается разработкой и внедрением крупномасштабных сетей поставщиков услуг и корпоративных сетей, а также преподаванием и написанием книг о передовых технологиях с 1990 года.
Он автор нескольких книг Cisco Press, а также плодовитый блогер и писатель, консультант и автор серии очень успешных вебинаров.
В настоящее время в центре его интересов крупномасштабные облачные системы, програм­мируемые сети (SDN) и центры обработки данных (SDDC), а также виртуализация сетевых функций (NFV).