Сетевая подсистема

По поводу сети. Здесь соображений  три:

1.    Необходимая пропускная способность для наших задач. Для какой-то задачи будет необходимо  выделить  сетевой контроллер в личное пользование одной ВМ. Если не хватает одного контроллера, используем группировку сетевых контроллеров, или teaming.

2.    Требуемая доступность.  Здесь  нам поможет  дублирование – опять  же за счет группировки сетевых контроллеров (Teaming).

3.    Безопасность. Здесь  может помочь физическая изоляция трафика  по разным сетевым контроллерам и/или использование VLAN.

Для реализации всех соображений  нам может потребоваться несколько (много ?) сетевых контроллеров. Абсолютный  минимум  – 1. Идеальный минимум  – 4 или даже 6, в зависимости от планируемых к использованию функций vSphere. Такие функции, как vMotion,  Fault Tolerance, работа с системами хранения поверх протокола  IP, требуют ресурсов сети, и под них рекомендуется выделять  отдельные физические контроллеры.

Как посчитать, сколько требуется в конкретном случае?

Сеть нам нужна для:

1.    Управления. Интерфейс Service Console (для ESX) или интерфейс VMker nel, настроенный для Management traffic (для ESXi).

2.    vMotion.

3.    Fault Tolerance.

4.    iSCSI и/или NFS, если они будут использоваться.

5.    ВМ. Среди ВМ может быть несколько групп ВМ, каждой из которых может потребоваться выделенный сетевой интерфейс (или не один).

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

Для vMotion нам необходим выделенный сетевой интерфейс.  С технической  точки зрения он может быть невыделенным – живая миграция будет происходить,  и если через тот же физический контроллер идет еще какой-то трафик. Но поддерживаемая  конфигурация сервера для vMotion предполагает  выделение  контрол лера под трафик  vMotion. Нужно  ли его дублировать,  зависит от того, насколько  для вас критична невозможность какое-то время мигрировать ВМ с сервера в случае проблем в сети, используемой для vMotion.

Для Fault  Tolerance  соображения примерно те же, что и для vMotion. Но, скорее всего, необходимость  наличия  дублирующего  контроллера для FT более вероятна.  Однако  нагрузка  на сетевой контроллер со стороны других задач может помешать  нормальной работе Fault  Tolerance. Верно и в обратную сторону: если трафик Fault Tolerance  будет достаточно велик, он может мешать другим задачам, если они разделяют  один и тот же физический сетевой интерфейс.

Если активно будет использоваться система хранения iSCSI или NFS, то с точки зрения производительности ее трафик лучше выделить в отдельную сеть. И в любом случае рекомендуется это сделать с точки зрения безопасности.  Для  надежности,  очевидно, следует выделить под данный трафик несколько сетевых контроллеров.

Для ВМ – зависит от ваших нужд. Какой предполагается организация виртуальной сети? Смогут ли все ВМ использовать один и тот же контроллер (группу  контроллеров)? Необходимо ли дублирование?

По результатам ответов на эти вопросы определяемся с необходимым числом сетевых контроллеров на каждый сервер ESX(i).

Также в зависимости от планируемой нагрузки  можно задуматься  над оправданностью применения контроллеров 10 Гб Ethernet. В первую очередь это может оказаться  актуально для трафика  СХД по протоколу  IP и для Fault Tolerance.

1.7.3. Масштабируемость: мало мощных серверов или много небольших?

Заключительный вопрос. Допустим,  вы определились с конфигурацией СХД. Посчитали, сколько процессорной мощности и оперативной памяти необходимо вам для размещения всех ВМ. Но как распределить их по серверам? Например, 16 процессоров  и 256 Гб ОЗУ  можно разместить  в 4 четырехпроцессорных серверах  по 64 Гб в каждом или 8 двухпроцессорных по 32 Гб. Что выбрать при прочих равных?

Здесь  (как  и везде в этом разделе)  сложно  дать однозначные рекомендации, поэтому привожу свои соображения.

1.    Модельный ряд того поставщика серверного  оборудования, с которым вы работаете.  Если  все ваши используемые серверы  (пусть  других моделей)  произведены фирмой  XYZ и вы ими довольны, настоятельно рекомендую не «разводить  зоопарк»  и не пускаться  в эксперименты с другими поставщиками. Потом сами будете не рады.

2.    Конечно, предыдущий совет не включает ситуации, когда вас не устраивает качество или уровень поддержки имеющихся серверов, или ваш поставщик  не предлагает серверов нужной конфигурации.

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

4.    Крупные серверы создают меньшие накладные  расходы, а также позволяют вместить суммарно больше ВМ. В нашем примере это можно проиллю стрировать  следующим  образом. В каждый  из четырех серверов  по 64 Гб вы сможете с достаточным  комфортом  разместить  по 21 ВМ по 3 Гб ОЗУ

каждая (всего получается 4 ? 21 = 84 ВМ). В каждый из восьми серверов по

32 Гб – по десять таких же ВМ, всего получается  8 ?  10 = 80. Итого полу-

чается, что в более крупных  серверах плотность  размещения ВМ выше и,

соответственно,  в то же суммарное количество  ОЗУ  можно вместить больше ВМ. Если же учесть экономию от Transparent Page Sharing, то разница  станет еще более заметна.

5.    С другой стороны, нельзя  забивать  все серверы под завязку.  Надо подумать и о доступности  своих служб. Разумно  запланировать, что один из серверов может отказать, а еще один в это время может находиться  на обслуживании (например, обновлении ПО или оборудования). Итого мы хотим, чтобы наше решение  сохраняло  доступность  при одновременном выходе из строя  двух узлов. В первом случае мы таким образом лишаемся половины  (4 – 2 = 2) серверов.  И  получается,   что  мы  можем  задействовать с  пользой  лишь

256 – (2 ? 64) = 128 Гб ОЗУ  и разместить в них только (4 – 2) ? 21 = 42 ВМ.

Во втором случае нам остается  уже 8 – 2 = 6 серверов  с 256 – (2 ?  32) =

= 194 Гб, в которых поместится  (8 – 2) ?  10 = 60 ВМ! Как видим, с учетом

планирования доступности  преимущество в нашем  примере оказывается

уже на стороне более модульной архитектуры.

6.    С третьей стороны, вы ни под каким видом не сможете разделить нагрузку одной ВМ между несколькими серверами  (по крайней мере, на текущем этапе  развития технологий   виртуализации).  Иными   словами,  если  вам вдруг однажды  потребуется  создать ВМ с объемом ОЗУ  40 Гб, то второй сценарий (серверы  по 32 Гб) вам просто не подойдет (без учета возможно стей по оптимизации использования памяти, которые мы здесь не станем учитывать  для наглядности). А вот первому варианту  (серверы  по 64 Гб) такой сценарий окажется  вполне под силу.

7.    Все вышесказанное в равной степени применимо  и к другим ресурсам сервера (процессор,  подсистемы  ввода-вывода). Просто с памятью это выглядит наиболее наглядно.

8.    Серверы-лезвия (Blade servers) обладают массой преимуществ с точки зрения стоимости  владения  (затраты  на управление, обслуживание, питание и охлаждение). Они  также  отлично отвечают  пятому  соображению,  приведенному выше, – ведь каждое лезвие является сравнительно небольшой составляющей  инфраструктуры. В результате  выход  из  строя  сразу  нескольких из них вряд ли сильно уменьшит суммарную мощность системы. Блейд-серверы также  крайне  эффективны с  точки  зрения  уменьшения проблем и головной боли – куда девать все эти кабели? Предположим, что, следуя соображениям отказоустойчивости, мы будем использовать 6 одногигабитных сетевых интерфейсов (2 = управление  + vMotion,  2 = iSCSI, 2 = виртуальные машины).  Не забудем о сети IPMI\iLO – в итоге 7 интерфейсов (и кабелей)  на сервер. 8 серверов виртуализации в итоге дают нам 56 кабелей, которые к тому же надо куда-то подключать, то есть потребуется еще и 56 сетевых портов. В случае с блейд-серверами количество кабелей (и портов) сокращается до 10–12.

9.    С другой стороны, стоит задуматься  о сбоях не только на уровне каждого лезвия  в отдельности,  но и каждой корзины  (шасси).  А вот выход из строя целой корзины  окажется  все-таки  более существен, чем даже пары обычных стоечных серверов, хотя, конечно, куда менее вероятен.

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

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

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

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

Другие производители могут накладывать ограничения на перепривязку лицензий между серверами и считают таким переносом операции миграции ВМ (например, vMotion). И здесь, уже наоборот, крупные серверы, которые снижают частоту (или необходимость) переноса ВМ, могут оказаться выгоднее.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий