Vmware настройка trunk порта
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Если зайти в настройки вКоммутатора или группы портов, то последней закладкой мы увидим «NIC Teaming», группировка контроллеров. Она нам потребуется в том случае, если к вКоммутатору у нас подключен более чем один физический сетевой контроллер сервера (vmnic).
А зачем мы можем захотеть, чтобы к одному вКоммутатору были подключены несколько vmnic? Ответ прост: для отказоустойчивости в первую очередь и для повышения пропускной способности сети - во вторую.
Обратите внимание. Если мы подключаем к одному виртуальному коммутатору, стандартному или распределенному, несколько физических сетевых контроллеров, то они должны быть из одного домена широковещательной рассылки. VMware не рекомендует подключать к одному вКоммутатору сетевые карты, подключенные в разные физические сети или разные VLAN: коммутаторы виртуальные обрабатывают только кадры Ethernet (второй уровень модели OSI) и не могут осуществлять маршрутизацию.
Если у вКоммутатора только один физический сетевой контроллер, то сам этот контроллер, его порт в физическом коммутаторе и физический коммутатор целиком являются единой точкой отказа. Поэтому для доступа в сеть критичных ВМ более чем правильно использовать два или более vmnic, подключенных в разные физические коммутаторы.
Но здесь встает вопрос политики их использования. Мы можем использовать конфигурацию, дающую лишь отказоустойчивость - когда работает только один vmnic, а остальные ожидают его выхода из строя, чтобы подменить его. Или мы можем задействовать сразу несколько сетевых контроллеров сервера, тем или иным образом балансируя между ними нагрузку.
Взглянем на окно настроек - рис. 2.32.
Failover Order. Самое нижнее поле позволяет выбрать используемые (Active Adapters), запасные (Standby Adapters) и неиспользуемые (Unused Adapters) физические сетевые контроллеры из подключенных к этому вКоммутатору. Если вы хотите, чтобы какие-то vmnic стали резервными и не были задействованы в нормальном режиме работы, тогда перемещайте их в группу Standby. Все (или несколько) оставляйте в Active, если хотите балансировку нагрузки. Ну а Unused обычно нужна на уровне групп портов - когда у вКоммутатора много каналов во внешнюю сеть, но трафик именно конкретной группы портов вы через какие-то пускать не хотите ни при каких обстоятельствах.
Failback. Эта настройка напрямую относится к Failover Order. Если у вас vmnic3 Active, а vmnic2 Standby, то в случае выхода из строя vmnic3 его подменит vmnic2. А что делать, когда vmnic3 вернется в строй? Вот если Failback выставлен в Yes, то vmnic2 опять станет Standby, а vmnic3 - опять Active. Соответственно, если Failback = No, то даже когда vmnic3 опять станет работоспособным, он станет Standby. Каким образом ESX(i) понимает, что vmnic неработоспособен? См. пункт Network Failover Detection.
Notify Switches. Эта настройка включает (Yes) или выключает (No) оповещение физических коммутаторов об изменениях в MAC-адресах ВМ на ESX(i). Когда вы создаете новую ВМ и подключаете ее к группе портов (как вариант -добавляете в ВМ еще один виртуальный сетевой контроллер) или когда трафик ВМ начинает идти через другой vmnic из-за сбоя ранее задействованного - тогда ESX(i) отправит пакет rarp с оповещением вида «Такой-то MAC-адрес теперь доступен на этом порту».
Рис. 2.32. Окно настроек группировки контроллеров -NIC Teaming
Рекомендуется выставлять в Yes для того, чтобы физические коммутаторы максимально быстро узнавали о том, на каком их порту доступен MAC-адрес ВМ. Однако некоторые приложения потребуют выключения этой функции, например кластер Microsoft NLB.
Network Failover Detection. Каким образом ESX(i) будет определять, что физический сетевой контроллер неработоспособен? Вариантов два:
- Link Status Only - когда критерием служит лишь наличие линка, сигнала. Подобный режим позволит обнаружить такие проблемы, как выход из строя самого vmnic, отключенный сетевой кабель, обесточенный физический коммутатор.
Такой подход не поможет определить сбой сети в случае неправильной настройки порта, например внесение его в неправильный VLAN и т. п. Также он не поможет в случае, если обрыв сети произошел где-то за физическим коммутатором;
- Beacon Probing - эта функция нужна только тогда, когда у вКоммутатора несколько внешних подключений (рис. 2.33) к разным физическим коммутаторам. При этой настройке, кроме проверки статуса подключения, виртуальный коммутатор еще рассылает (с интервалом порядка 5-10 секунд) через каждый свой vmnic широковещательные пакеты, содержащие MAC-адрес того сетевого интерфейса, через который они ушли. И ожидается, что каждый такой пакет, посланный с одного vmnic, будет принят на других vmnic этого вКоммутатора. Если этого не происходит - значит где-то по каким-то причинам сеть не работает.
Рис. 2.33. Пример конфигурации сети, при которой имеет смысл использовать Beacon Probing
В этом примере пакеты, посланные через vmnic5, не дойдут до клиентов, подключенных к «дальним» физическим коммутаторам. Если для определения отказов сети используется «Link status only» - то ESX(i) не сможет определить такую неработоспособность сети. А beaconing сможет - потому что широковещательные пакеты от vmnic5 не будут приняты на vmnic3 и vmnic2.
Но обратите внимание: если beacon-пакеты отправляются и не принимаются в конфигурации с двумя vmnic на вКоммутаторе, то невозможно определить, какой из них не надо использовать - ведь с обоих beacon-пакеты уходят и на оба не приходят.
Тогда вКоммутатор начинает работать в режиме «Shotgun», что здесь можно перевести как «двустволка», - начинает отправлять весь трафик через оба подключения, мол, через какой-то да дойдет.
Конечно, такой ситуации лучше избегать. Сделать это можно правильной структурой физической сети, чтобы какие-то проблемы в ней решались за счет Spanning Tree. Вообще, механизм beaconing позиционируется как крайнее сред ство - если вы не можете повлиять на правильность конфигурации сети на физической стороне, то подстрахуйтесь от сбоев с помощью beaconing. Но эффективнее, когда подобные сбои в сети устраняются средствами этой сети и beaconing вам не нужен.
Наконец, самая интересная настройка.
Load Balancing. В этом выпадающем меню вы можете выбрать, по какому алгоритму будет балансироваться трафик виртуальных машин между каналами во внешнюю сеть виртуального коммутатора, к которому они подключены.
- Route based on the originating port ID - балансировка по номеру порта. У каждой ВМ (у каждого виртуального сетевого контроллера в ВМ) есть порт в вКоммутаторе, к которому она подключена. При данном варианте настройки балансировки нагрузки трафик будет делиться по этим портам - весь трафик от одного порта вКоммутатора будет идти в какой-то один vmnic; трафик из другого порта - через другой vmnic и т. д. Выбор очередного vmnic осуществляется случайным образом, не по его загрузке. Данный метод балансировки нагрузки используется по умолчанию и является рекомендуемым. Рекомендуемым он является потому, что дает какую-никакую балансировку нагрузки, а накладные расходы на анализ трафика минимальны. Однако трафик от одного виртуального контроллера не получит полосы пропускания больше, чем дает один физический интерфейс, выступающий каналом во внешнюю сеть. Косвенный вывод отсюда - виртуальная машина с несколькими виртуальными сетевыми контроллерами сможет задействовать несколько каналов во внешнюю сеть;
- Route based on source MAC hash - балансировка по MAC-адресу источника. В этом случае трафик делится на основе MAC-адреса источника пакета. Таким образом, исходящий трафик делится точно так же, как и в случае балансировки по портам. На практике метод практически не применяется;
- Route based on ip hash - балансировка по хэшу (контрольной сумме) IP. Здесь критерием разделения трафика считается пара IP-источника - IP-получателя. Таким образом, трафик между одной ВМ и разными клиентами, в том числе за маршрутизатором, может выходить по разным vmnic. Этот метод балансировки нагрузки является самым эффективным, однако он может вызвать большую нагрузку на процессоры сервера, так как именно на них будет вычисляться хэш IP-адресов для каждого пакета.
Также этот метод балансировки требует настроенной группировки портов (известной как link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на физическом коммутаторе, к которому подключен коммутатор виртуальный. Это вызвано тем, что при данном методе балансировки нагрузки MAC-адрес одной ВМ может одновременно числиться на нескольких vmnic, как следствие - на нескольких портах коммутатора физического. Что не является допустимым в штатном режиме работы, без группировки портов.
В обратную сторону - если вы хотите настроить группировку портов между физическим и виртуальным коммутаторами, то вы настраиваете ее на физическом; а на виртуальном ставите балансировку по хэшу IP для нужных групп портов - и все.
Последний нюанс: если у вас один коммутатор виртуальный подключен к нескольким физическим (из соображений отказоустойчивости), то далеко не с любыми физическими коммутаторами получится использовать этот тип балансировки нагрузки в такой конфигурации.
ESX(i) не поддерживает автоматической настройки группировки портов с помощью Link Aggregation Control Protocol (LACP).
Link Aggregation (Etherchannel) на физическом коммутаторе должен быть настроен, только если на виртуальном коммутаторе используется балансировка нагрузки по IP;
- Route based on physical NIC load - этот метод балансировки нагрузки доступен только для распределенных коммутаторов и только начиная с ESX(i) версии 4.1. Суть данного механизма напоминает работу первого варианта балансировки - по Port ID. Однако есть и значительные различия. Во-первых, при принятии решения, через какой pNIC выпускать очередную «сессию», выбор осуществляется в зависимости от нагрузки на этот pNIC, а не случайным образом. Во-вторых, выбор повторяется каждые 30 секунд (в то время как во всех прочих вариантах однажды осуществленный выбор не меняется до выключения ВМ).
Резюме: рекомендуемым в общем случае является Route based on the physical NIC load - по совокупности характеристик. Он дает балансировку нагрузки с минимальными накладными расходами (но использовать этот метод балансировки возможно только на распределенных коммутаторах, и только начиная с версии 4.1). В случае если вы твердо уверены, что вам необходима большая эффективность балансировки, используйте Route based on ip hash. Пример такой ситуации - одна ВМ, генерирующая большой объем трафика и работающая с большим количеством клиентов. Однако если нет возможности настроить etherchannel на физическом коммутаторе, то Route based on ip hash использовать невозможно.
Если не подходят и Route based on ip hash, и Route based on physical NIC load, используйте Route based on the originating port ID.
Более эффективную балансировку нагрузки рекомендуется ставить лишь для той группы портов, для которой она необходима, - с целью свести к минимуму накладные расходы в виде нагрузки на CPU сервера.
Для распределенных виртуальных коммутаторов все так же, с поправкой на абстрактность каналов во внешнюю сеть, для которых выполняется эта настройка.
B. Assign IP Address for the created VLAN (This will be the gateway of VMs)
Note: On layer 3 Switch, there should be a routing configurations so that the switch knows where to route the traffic. In this case the default route via
ip default-gateway 10.63.0.253 GW
ip route 0.0.0.0 0.0.0.0 10.63.0.253
2. Configure ESXi Host Networking
A. Create Virtual Switch
Add Networking
Connection Type: Virtual Machine
Create a vSphere Standard switch (Choose the Physical NIC e.g. vmic1; this NIC should be connected on the switch configured as Trunk above.)
Network Label: VLAN635
VLAN ID: 635
B. Configure the vSwitch Properties
Load Balancing: Route based on IP Hash
C. Set the Network Adapter of the VM to use the VM Network for VLAN635
D. Assign IP on VM and test the connectivity, you can ping the Gateway now (VLAN IP Address)
IP: 10.63.5.X
NM: 255.255.255.0
GW: 10.63.5.1 (VLAN IP Address)
3. Create more VM Network
A. On ESXi Host, Networking
B. Go to Properties, Ports
C. Add
D. Virtual Machine
E. Network Label: VLAN636
VLANID: 636
Finished
VLAN Trunking VSwitch
Sample configuration of virtual switch VLAN tagging (VST Mode) (1004074)
Purpose
This article provides a sample network configuration for isolation and segmentation of virtual machine network traffic.
Resolution
To configure Virtual Switch (vSwitch) VLAN Tagging (VST) on an ESXi/ESX host:
1. Assign a VLAN to a portgroup(s). The supported VLAN range is 1-4094.
Reserved VLAN IDs:
VLAN ID 0 (zero) Disables VLAN tagging on port group (EST Mode)
VLAN ID 4095 Enables trunking on port group (VGT Mode)
2. Set the switch NIC teaming policy to Route based on originating virtual port ID (this is set by default).
To configure the physical switch settings:
1. Define ESXi/ESX VLANs on the physical switch.
2. Allow the proper range to the ESXi/ESX host.
3. Set the physical port connection between the ESXi/ESX host and the physical switch to TRUNK mode. ESXi/ESX only supports IEEE 802.1Q (dot1q) trunking.
Physical switch is set to TRUNK mode
dot1q encapsulation is enabled
Spanning-tree is set to portfast trunk (for example, port forwarding, skips other modes)
Define VLAN interface
Assign IP Range to VLAN interface
VLAN Routing – and VLAN IsolationCaution: Native VLAN ID on ESXi/ESX VST Mode is not supported. Do not assign a VLAN to a port group that is same as the native VLAN ID of the physical switch. Native VLAN packets are not tagged with the VLAN ID on the outgoing traffic toward the ESXi/ESX host. Therefore, if the ESXi/ESX host is set to VST mode, it drops the packets that are lacking a VLAN tag.
This sample is a supported Cisco Trunk Port configuration:
interface GigabitEthernet1/2
switchport (Set to layer 2 switching)
switchport trunk encapsulation dot1q (ESXi/ESX only supports dot1q, not ISL)
switchport trunk allowed vlan 10-100 (Allowed VLAN to ESXi/ESX. Ensure ESXi/ESX VLANs are allowed)
switchport mode trunk (Set to Trunk Mode)
switchport nonegotiate (DTP is not supported)
no ip address
no cdp enable (ESXi/ESX 3.5 or higher supports CDP)
spanning-tree portfast trunk (Allows the port to start forwarding packets immediately on linkup)
Note: For more information on configuring your physical network switch, contact your switch vendor.
To assign a VLAN to a port group, there must be a corresponding VLAN interface for each VLAN on a physical switch with a designated IP range.
For example:
interface Vlan200
ip address 10.10.100.1 255.255.255.0 (This IP can be used as VLAN 200 Gateway IP)
Note: When the VLAN ID is defined on the physical switch, it can be configured for ESX. If the IP range is assigned to a VLAN, decide if any routing may be required to reach other nodes on the network.
To configure a VLAN on the portgroup using the VMware Infrastructure/vSphere Client:
1. Click the ESXi/ESX host.
2. Click the Configuration tab.
3. Click the Networking link.
4. Click Properties.
5. Click the virtual switch / portgroups in the Ports tab and click Edit.
6. Click the General tab.
7. Assign a VLAN number in VLAN ID (optional).
8. Click the NIC Teaming tab.
9. From the Load Balancing dropdown, choose Route based on originating virtual port ID.
10. Verify that there is at least one network adapter listed under Active Adapters.
11. Verify the VST configuration using the ping command to confirm the connection between the ESXi/ESX host and the gateway interfaces and another host on the same VLAN.Note: For additional information on VLAN configuration of a VirtualSwitch (vSwitch) port group, see Configuring a VLAN on a portgroup (1003825).
To configure via the command line:
esxcfg-vswitch -p “portgroup_name” -v VLAN_ID virtual_switch_name
Note: The illustration attached to this article is a sample VST mode topology and configuration with two ESXi/ESX hosts, each with two NICs connecting to the Cisco switch.
Для этого выбираем наш хост, жмем на вкладку Configure, и в разделе Networking выбираем Virtual Switches.
Поскольку у нас на хосте имеется два сетевых адаптера(как установить драйвер на неподдерживаемую сетевую карту мы рассматривали в статье), давайте добавим нашу сетевую карту в виртуальный свич и настроим так называемый тиминг(объединение сетевых интерфейсов).
Виртуальных коммутаторов на хосте может быть несколько. Если вы хотите, чтобы ваши виртуальные машины находились в изолированной сети, можно создать виртуальный коммутатор, не используя сетевые адаптеры.
Ну а мы рассмотрим настройку обычного виртуального свича.
Accessing Trunk port within VMWare Workstation on Linux
Sometimes it is helpful to get access to a trunk port in order to use VLANs within VMWare Workstation on Linux.
Where might this be useful?
Virtualized firewall for a lab that includes physical as well as virtual components that are separated using VLANs.
The following quickly shows the necessary steps to access the traffic from a physical trunk port on a switch within a virtual machine.
- Configure the trunk port on the physical switch
- Physically connect a host network interface on the configured trunk port
- Create a vmnet host-only interface within VMWare workstation
- Create a bridge on the host with the physical interface as well as the vmnet host only interface created
- Add the newly created vmnet interface to your virtual machine
Step 1. Configure trunk port on the switch
Hint: obviously you need to have already defined your VLANs on the switch prior to the following steps. Detailed instructions on how to get this done is switch specific (consult your switch manual).
Step 2. Physically connect a host network interface on the configured trunk port
In this example we will use the network interface card enx002400000001 for illustration purposes.
Step 3. Create a vmnet host only interface in VMWare Workstation
Within VMware Workstation do the following
- Use the menu EDIT->Virtual Network Editor
- enter your sudo credentials if you are not running VMWare as root user
- Select “Add Network”
- Use the offered available network for example “vmnet7” write down the name for alter reference.
- Select “Host-only” as Type
- Click “Add”
Step 4. Create a bridge on the host with the physical interface as well as the vmnet host only interface created
Execute the following steps within a terminal:
“apt-get install bridge-utils vlan”
Next we need to ensure that VLANs and bridges can be dealt with (kernel module 8021q and bridge)
“modprobe 8021q”
“modprobe bridge”
If that is successful we ensure that the 8021q and bridge modules are loaded at startup by adding the modules to the /etc/modules file:
“echo “8021q” >> /etc/modules”
“echo “bridge” >> /etc/modules”
Depending on your version of Ubuntu it might come with filter rules for iptables for the bridges or not. In order to ensure we do not run into trouble we explicitly configure it to not use any filtering and passing VLAN traffic.
In order to explicitly set the filtering we need to include another kernel module (br_netfilter)
Adding the module for startup:
“echo “br_netfilter” >> /etc/modules
Now we will deal with the filtering on our to be bridge. For configuring this we need to edit the /etc/sysctl.conf file and add the following entries to disable filtering:
“net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0”
In order to get settings applied in our system we need to issue the following command:
In case of any errors (for example newer versions in future might have different names for the kernel modules) use the following commands to explore the root cause:
Now we need to create our bridge.
We define our bridge and necessary interfaces in /etc/network/interfaces:
For illustration purposes our physical network interface on the host is:
enx002400000001
Our bridge will be named:
br1
Our VmWare Workstation network is:
vmnet7
Please ensure that you replace the above names with those that reflect your environment.
auto br1
iface br1 inet manual
bridge_ports enx002400000001 vmnet7
bridge_stp off
up /sbin/ifconfig br1 up || /bin/true
In case you want access to the interfaces on the host with an IP address you would have to use “dhcp” or “static” e.g:
iface enx002400000001.500 inet static
address 192.168.0.9/24
gateway 192.168.0.1
dns-nameservers 192.168.0.1
Now we need to make your configuration active by restarting networking:
The following command will provide you an overview of the bridges you have created:
bridge name bridge id STP enabled interfaces
br1 8000.002400000001 no enx002400000001
vmnet7
Step 5. Add the newly created vmnet7 interface to your virtual machine
Now we have our bridge up and running and can add our vmnet7 network to our virtual machine.
Right-Click on the virtual machine
-> Settings
Add Network Adapter -> Network Adapter -> Custom specific virtual network
-> Select vmnet7
-> Finish
Now you can configure individual virtual VLAN adapters within your virtual machine client OS (e.g. eth0.500) that have direct access to VLANs distributed on the physical switch trunk port.
Сети виртуальных машин.
Сеть виртуальных машин создается аналогично, только в мастере нужно выбрать Virtual Machine Port Group
Выбрать или создать VSwitch
указать название сети и VLAN
и завершить создание
После этого в нашем виртуальном коммутаторе появится еще одна сеть виртуальных машин и в настройках виртуальных машин станет доступно подключение к этой сети.
Дополнительный виртуальный коммутатор можно создать при создании VMkernel или VM Network. Как я уже говорил, наличие физического сетевого адаптера требуется только, если ВМ должны иметь доступ к внешним ресурсам(находящимся не на данном хосте ESXi).
Ну вот вкратце и всё по настройке сети VMware. Если что-то осталось не рассмотренным или непонятным, пишите в комментариях, — будем дополнять.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Немножко общей теории о виртуальных локальных сетях. VLAN поддерживаются как стандартными, так и распределенными виртуальными коммутаторами. Суть их в том, чтобы возложить на коммутатор работу по анализу и контролю трафика на втором уровне модели OSI с целью создавать не связанные между собой сети без физической их изоляции друг от друга.
Рис. 2.22. Серверы (ВМ) подключены к одному коммутатору, но к разным VLAN
Что мы здесь видим?
Все серверы (в нашем случае это ВМ, но для VLAN это не принципиально) подключены к одному коммутатору (слева), но на этом коммутаторе настроены несколько VLAN, и все ВМ подключены к разным (справа). Это означает, что на коммутаторе (в случае виртуальных машин - на вКоммутаторе) мы сделали настройку - порт для ВМ1 принадлежит виртуальной сети 1 (с идентификатором VLAN порт для ВМ2 принадлежит VLAN 2 и т. д. Это означает, что эти ВМ друг с другом взаимодействовать не могут, им не даст такой возможности сам коммутатор. Изоляция между серверами (ВМ) получается практически такой же, как если бы они были подключены к разным коммутаторам.
Небольшое примечание: на коммутаторе физическом, к которому подключены коммутаторы виртуальные, также в обязательном порядке должны быть настроены VLAN.
В общем случае VLAN - это разделение всей нашей сети на несколько как будто бы не связанных сегментов. Именно всей сети, а не отдельно взятого коммутатора.
- для того чтобы уменьшить домены широковещательной рассылки, следовательно, снизить нагрузку на сеть;
- для того чтобы повысить безопасность - хотя устройства подключены в одну сеть физически, находясь в разных vlan, они не смогут взаимодействовать по сети.
Если используются VLAN, то коммутаторы (обычно этим занимаются именно коммутаторы) добавляют в каждый кадр поле, в которое записывают так называемый «vlan id» (тег VLAN, идентификатор VLAN) - число в диапазоне от 1 до 4094. Получается, для каждого порта указано, кадры с каким vlan id могут пройти в порт, а в кадрах прописано, к какому vlan относится каждый кадр. Эту операцию называют «тегированием», добавлением в кадр тега vlan.
Обычно VLAN настраиваются на коммутаторах, и только коммутаторы о них знают - с точки зрения конечного устройства (такого, как физический сервер или виртуальная машина) в сети не меняется ничего. Что означает настроить vlan на коммутаторе? Это означает для всех или части портов указать vlan id, то есть vlan с каким номером принадлежит порт. Теперь если сервер подключен к порту с vlan то коммутатор гарантированно не перешлет его трафик в порты с другим vlan id, даже если сервер посылает широковещательный трафик.
Один VLAN может распространяться (и, как правило, распространяется) на несколько коммутаторов. То есть устройства, находящиеся в одном VLAN, могут физически быть подключены к разным коммутаторам.
Если за настройки сети отвечаете не вы, то формально, с точки зрения администрирования ESX(i), нам достаточно знать: ESX(i) поддерживает VLAN. Мы можем настроить vlan id для групп портов на вКоммутаторе, и они будут тегировать и ограничивать проходящий через них трафик.
Если тема настройки VLAN вас касается, то несколько слов подробнее.
У вас есть три принципиально разных варианта настройки vlan:
- external switch tagging, EST - установка тегов VLAN только на внешних, физических, коммутаторах. За VLAN отвечают только физические коммутаторы, на вКоммутаторы трафик приходит без тегов VLAN;
- virtual switch tagging, VST - установка тегов VLAN на виртуальных коммутаторах. Коммутаторы физические настраиваются таким образом, чтобы теги VLAN не вырезались из кадров, передаваемых на физические интерфейсы серверов ESX(i), то есть виртуальным коммутаторам;
- virtual guest tagging, VGT - установка тегов VLAN на гостевой ОС в виртуальной машине. В этом случае коммутаторы (и виртуальные, и физические) не вырезают тег VLAN при пересылке кадра на клиентское устройство (в нашем случае на ВМ), а теги VLAN вставляются в кадры самим клиентским устройством (в нашем случае виртуальной машиной).
EST - схема на рис. 2.23.
Рис. 2.23. External switch tagging
Этот подход хорош тем, что все настройки VLAN задаются только на физических коммутаторах. Вашим сетевым администраторам не придется задействовать в этом вКоммутаторы ESX(i) - порты физических коммутаторов, куда подключены физические сетевые контроллеры ESX, должны быть настроены обычным образом, чтобы коммутаторы вырезали тег VLAN при покидании кадром порта. Минус подхода EST в том, что на каждый VLAN нам нужен выделенный физический сетевой контроллер в ESX(i).
Таким образом, при реализации схемы EST уже физические коммутаторы пропускают в порты к ESX(i) пакеты только из нужных VLAN (5 и 15 в моем примере). Виртуальные машины и виртуальные коммутаторы про VLAN ничего не знают.
VST - схема на рис. 2.24.
Рис. 2.24. Схема Virtual switch tagging
Этот подход предполагает настройку VLAN и на вКоммутаторах. Удобен тем, что на один вКоммутатор (и на одни и те же vmnic) может приходить трафик множества VLAN. Из минусов - требует настройки на стороне и физических, и виртуальных коммутаторов. Те порты физических коммутаторов, к которым подключены контроллеры серверов ESX(i), следует настроить «транковые», то есть пропускающие пакеты из всех (или нескольких нужных) VLAN, и не вырезающие теги VLAN при проходе кадра сквозь порт. А на вКоммутаторах надо сопоставить VLAN ID соответствующим группам портов. Впрочем, это несложно -Configuration ^ Networking ^ свойства vSwitch ^ свойства группы портов ^ в поле VLAN ID ставим нужную цифру.
VGT - схема на рис. 2.25.
Этот подход хорош в тех редких случаях, когда одна ВМ должна взаимодействовать с машинами из многих VLAN одновременно. Для этого вКоммутатор мы настроим не вырезать теги VLAN из кадров к этой ВМ (фактически сделаем транковый порт на вКоммутаторе). Чтобы настроить транковый порт на стандартном виртуальном коммутаторе VMware, необходимо для группы портов, к которой подключена ВМ, в качестве VLAN ID прописать значение «4095». Пройдите Configuration ^ Networking ^ свойства vSwitch ^ свойства группы портов ^ в поле VLAN ID.
Рис. 2.25. Схема Virtual guest tagging
Минус конфигурации в том, что внутри ВМ должно быть ПО, обрабатывающее VLAN, - так как вКоммутатор теги VLAN вырезать не будет и они будут доходить прямо до ВМ. На физических серверах очень часто этим ПО является драйвер сетевых контроллеров. Это актуально и для ВМ.
Для реализации схемы VGT виртуальные машины должны использовать виртуальные сетевые карты типа e1000 или vmxnet3.
Драйверы vmxnet3 для Windows из состава VMware Tools позволяют настраивать VLAN, но какой-то один - см. рис. 2.26.
Рис. 2.26. Настройка VLAN в драйвере vmxnet3
Рис. 2.27. Настройка VLAN в драйвере e1000/Intel Pro 1000
К сожалению, Intel не предоставляет специального драйвера для 64-битных операционных систем.
Кроме стандартных виртуальных коммутаторов VMware, некоторые лицензии позволяют использовать распределенные виртуальные коммутаторы VMware. У них немного больше возможностей работы с VLAN (они позволяют использовать Private VLAN) и чуть-чуть по-другому выглядят окна настройки. Подробности см. в следующем разделе.
Интерфейсы VMkernel.
Думаю, нужно еще рассмотреть настройки интерфейса VMkernel, используемого для служебных нужд.
Интерфейсов VMkernel может(и должно) быть несколько, чтобы разделить трафик управления от, например, трафика iscsi. Желательно, чтобы это были физически разделенные сети, ну или, хотя бы, на уровне VLANs.
Давайте настроим несколько таких интерфейсов.
Выбираем в секции Networking вкладку VMkernel adapters, выделяем пока единственный vmk0 и жмем карандаш для редактирования
В открывшемся окне на первой вкладке выбираем тип трафика, который разрешен на этом интерфейсе(давайте разрешим здесь еще VMotion — трафик миграции ВМ).
На других вкладках этого мастера можно изменить такие настройки как MTU, настройки IPv4 и IPv6.
После нажатия ОК настройки будут сохранены.
Теперь давайте создадим еще один VMkernel для трафика, например Fault Tolerance. Настройка сети для трафика хранилищ iscsi описана в статье Как подключить iscsi-lun к хосту esxi.
Итак, жмем на глобус с плюсом, чтобы добавить новый адаптер VMkernel
Выбираем тип VMkernel Network Adapter
Выбираем, использовать имеющийся или создать новый виртуальный коммутатор(мы выберем наш единственный). Жмем Next.
На следующем экране задаем имя нашего адаптера, выбираем какой версии протокол IP будет использоваться и какой трафик
Указываем сетевые настройки(статика или DHCP)
На завершающем экране мастера проверяем настройки и жмем Finish.
Видим, что теперь у нас появился второй VMkernel адаптер, который будет использован для передачи трафика Fault Tolerance logging.
VMware настройка сети. Настройка виртуального коммутатора.
Выбираем наш единственный виртуальный коммутатор и нажимаем на значок сетевой карты
В открывшемся окне видим, что у нас сейчас активен один сетевой адаптер vmnic0. Жмем на зеленый плюс, чтобы добавить второй
Видим нашу вторую сетевуху, выбираем ее и группу адаптеров, в которую нужно ее добавить(в нашем случае Active adapters).
Active adapters — сетевая карта будет использоваться
Standby adapters — сетевая карта будет задействована в случае выхода из строя основной
Unused adapters — сетевая карта не будет использоваться.
На следующем экране видим, что наши адаптеры находятся в группе активных(можно поменять группу адаптера с помощью синих стрелок, а также удалить адаптер или добавить еще).
Жмем ОК и видим, что теперь в нашем свиче два сетевых адаптера(у меня подключен только один, поэтому VMware «сигналит», что отказоустойчивость потеряна.
В виртуальных свичах VMware есть сеть для виртуальных машин VM Network(сюда подключаются виртуальные машины) и VMkernel, предназначенный для служебного трафика(Management, VMotion, iscsi и т.п.).
Давайте настроим наш управляющий интерфейс, который используется для управления хостом.
Выделяем окно с заголовком Management Network и нажимаем на карандаш для редактирования.
В настройках Management Network вы можете изменить название сети, VLAN(если используется), настройки безопасности, traffic shaping(в стандартном свиче ограничивается только исходящий трафик) и режим файловера и балансировки нагрузки.
Читайте также: