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

Как изменить подсеть Service Console в кластере ESX?

У нас есть существующий кластер VMware ESX 3.5 (6 хостов, VI 2.5), и нам необходимо переместить сервисные консоли в новую подсеть. Мы хотели бы сделать это без простоев виртуальных машин.

В своих предыдущих экспериментах я обнаружил, что проверки ограничений сети кластера блокируют мои попытки перенастроить хосты для работы в другой подсети Service Console.

Я попытался добавить дополнительную сервисную консоль (с другим именем) в новую подсеть на всех хостах и ​​установить das.AllowNetwork0, чтобы ограничить эту новую сервисную консоль, но если я настрою хост только на эту сервисную консоль, а не старый не может присоединиться к кластеру с ошибками о несовпадении сетевых конфигураций. Он не работает независимо от того, имеет ли новая служебная консоль альтернативное имя или соответствующее имя.

У нас есть транковые соединения для обеих подсетей. Конечно, мы можем временно установить сервисную консоль в подсети.

Текущая конфигурация на всех хостах (упрощена и отредактирована):

# Current service console, on port in VLAN 5
Switch Name    Uplinks   
vSwitch0       vmnic0    

  PortGroup Name      VLAN ID  Uplinks   
  Service Console     0        vmnic0    

# connected to dedicated VMotion switch
Switch Name    Uplinks   
vSwitch1       vmnic1    

  PortGroup Name      VLAN ID  Uplinks   
  VMotion             0        vmnic1    

# Old subnets
Switch Name    Uplinks   
vSwitch4       vmnic8,vmnic4

  PortGroup Name      VLAN ID  Uplinks   
  XXX.YYY.9.0_24      9        vmnic4,vmnic8
  XXX.YYY.5.0_24      5        vmnic4,vmnic8 # 

# New subnets:
Switch Name    Uplinks   
vSwitch7       vmnic11,vmnic7

  PortGroup Name      VLAN ID  Uplinks   
  XXX.YYY.27.0_25     27       vmnic7,vmnic11
  XXX.YYY.30.0_24     30       vmnic7,vmnic11
  Service Console SF  30       vmnic7,vmnic11

По сути, мы хотим переместить vmnic0 из VLAN5 в VLAN30 (для этого нужно перейти на новый кабель). У нас достаточно мощности, чтобы иметь 2 хоста в режиме обслуживания. У нас есть пара свободных портов Ethernet на хостах, и, как вы можете видеть выше, у нас также есть магистральные соединения, которые могут предоставить нам интерфейс в каждой подсети.

Я предпочитаю выделенный порт для постоянной сервисной консоли, потому что у меня был неудачный опыт перенастройки порта / vSwitch, который я использую для доступа к интерфейсу для перенастройки хоста. Мы можем захотеть сохранить консоль службы резервного копирования с другим IP-адресом в той же подсети на транкинговых соединениях в этой подсети (vSwitch7 / VLAN30).

Я рассмотрел возможность создания нового кластера в VI, копирования всех наших пулов ресурсов и другой конфигурации, помещения 2 хостов с новой сетевой конфигурацией в кластер, миграции виртуальных машин в новый кластер, а затем перемещения остальных 4 хостов в новый кластер. кластер по одному (переместите хост, переместите достаточно виртуальных машин, чтобы освободить хост в старом кластере, переместите следующий хост).

Конфигурация, которую вы упомянули, со всеми хостами, имеющими доступ к обеим сетям сервисной консоли, используя das.AllowNetwork0 для принудительного использования новой сети, а затем добавление хоста в кластер с доступом только к новой сети. Однако одно предостережение - вам необходимо отключить и снова включить HA, чтобы он переключился на новый интерфейс (и допустил новый хост, который пытается разговаривать с HA на этом интерфейсе).

О, также имейте в виду, что он не будет использовать сети, в которых по умолчанию включен vMotion - это требует das.allowvMotionNetworks = true установлен на кластере. А если вы управляете извне подсети, не забудьте отключить шлюз по умолчанию, прежде чем отключать старую сервисную консоль.

Ваш план по переходу на совершенно новый кластер также подойдет!