Назад | Перейти на главную страницу

Масштабируемый дизайн для vsphere 4.1

Мы закупили 1x C7000 Chasis 2xVirtual connect 2x9124 FC коммутатор 5xBL460 G6 с двухпортовым HBA 1 NetApp Filer (FC) с двойным контроллером Active / Active 1xNetApp filer (SATA) с одним контроллером

Нам нужно развернуть масштабируемый дизайн с Vsphere 4.1.

Мы будем использовать 3 blade-сервера для VMWARE Vsphere4.1 и 2 blade-сервера в качестве физических для других приложений. Будет 6 виртуальных машин, включая Vcenter.

Каким должно быть соединение Virtual Connect, чтобы обслуживать как физическую, так и виртуальную среду в одном корпусе

Это довольно ужасный вопрос. Давайте начнем.

  1. Что вы вообще имеете в виду под «масштабируемым»? Есть все виды масштабируемости. Вам необходимо уточнить, что именно вы пытаетесь масштабировать и что создает узкие места масштабируемости в вашем приложении.
  2. Не существует универсальной масштабируемой конструкции. Мы буквально ничего не можем сказать вам о масштабировании ваших приложений, если мы не понимаем, что вы пытаетесь сделать с кластером. Даже в одном приложении разные варианты использования предъявляют совершенно разные требования к производительности. Мы не можем догадаться, что вам нужно, чтобы оставаться масштабируемым. Вы должны нам рассказать. Если вы не знаете, какие цифры вам нужны, вам может помочь VMware Capacity Planner. Установите его на свои физические серверы, дайте ему готовиться неделю, а затем вернитесь к нам.
  3. Чего вы вообще достигли, запустив пять виртуальных машин (исключая vCenter) на трех физических системах? Виртуализация дает бесчисленные преимущества аварийного восстановления, но если у вас нет более широкого проекта консолидации, похоже, вы можете сэкономить кучу денег, просто выполняя загрузку из SAN на всех своих физических хостах.
  4. Вы определенно не хотите запускать свои кластерные виртуальные машины в одном шасси блейд-сервера, особенно если вы полагаетесь на HA, чтобы сохранить доступность в случае отказа хоста - ваше шасси создает единую точку отказа во всей вашей среде . Если у вас только одно шасси для лезвий, не используйте для этого лезвия. Купите пиццабоксы 1U или 2U. Вы будете намного счастливее.
  5. Я никогда не видел SAN, которая не отставала от VMware. Однако я видел множество массивов в SAN, которые не могут этого сделать, потому что администраторы не понимали должным образом профили ввода-вывода своего приложения или то, как это влияет на структуру физического дискового массива.

Если вы не в себе и говорите так, будто не знаете, какие вопросы следует задавать, вам действительно стоит нанять консультанта или, по крайней мере, VAR, чтобы помочь вам начать работу. Виртуализация без опыта настройки или управления станет полной катастрофой для вашей организации.

Вы упустили много информации (особенно о нисходящих портах LAN или любых промежуточных коммутаторах SAN), но давайте разберем ее на части.

Самый простой из них - это SAN, просто запустите любое количество портов, которые вам нравятся, от ваших 9124 в вашем NetApp, у меня возникнет соблазн запустить их как двухточечные ссылки, если у вас нет промежуточных коммутаторов и вы используете NPIV, а не запускаете их как Магистрали ISL (не уверен, что NetApp все равно может работать с ISL). Таким образом, вы создадите две сети SAN, по одной на каждый порт хоста, и просто сопоставите их напрямую - нет необходимости в VSAN / зонах и т. Д.

Вопрос о локальной сети немного сложнее, и он не может охватить ваши физические серверы, поскольку вы не предоставили никаких требований к сети - предполагая, что ваши нисходящие порты являются коммутаторами, которые могут обрабатывать магистрали, тогда то, что я бы сделал для ваших блоков ESX, разделил бы каждый flexNIC на два vNIC, один на 2 Гбит / с, а другой на 8 Гбит / с, сделайте это для обоих адаптеров, предоставляя вашим хостам по 4 виртуальных сетевых адаптера, создайте vswitch управления / vMotion, используя как виртуальные адаптеры 2 ГБ, так и vSwitch трафика виртуальных машин с обоими виртуальными сетевыми адаптерами 8 ГБ. Создайте две сети VC, одну для двух vNIC управления / vmotion и одну для vNIC трафика виртуальных машин, поместите свои реальные магистральные порты в их группы портов, и вы уезжаете.

И для LAN, и для SAN используйте аппаратные MAC / WWN, в этой ситуации нет смысла использовать объединенные. Да, и позвольте вашему VC выполнять тегирование VLAN (если вы не планируете использовать отдельные магистрали для обеих функций, и в этом случае просто позвольте тегам пройти через ESX, чтобы они вышли из строя).

Это будет нормально для ESX и, вероятно, достаточно хорошо с точки зрения SAN для вас, но, как я уже сказал, вы не дали нам работать над физическими портами LAN.