Vmware provisioning traffic что это
Никакой центр обработки данных не может рассматриваться в качестве функционального продукта или решения если он не имеет сетевых возможностей. Это же имеет место и в отношении комплекта продуктов vSphere. В данной главе мы проведём большое изучение всех концепций сетевой среды, относящихся к инфраструктуре VMware, а также изучим как их настраивать чтобы соответствовать нашим потребностям проекта.
Данная глава охватывает следующие темы:
TCP/IP Stacks at the VMkernel Level
Default TCP/IP stack Provides networking support for the management traffic between vCenter Server and ESXi hosts, and for system traffic such as vMotion, IP storage, Fault Tolerance, and so on. vMotion TCP/IP stack Supports the traffic for live migration of virtual machines. Use the vMotion TCP/IP to provide better isolation for the vMotion traffic. After you create a VMkernel adapter on the vMotion TCP/IP stack, you can use only this stack for vMotion on this host. The VMkernel adapters on the default TCP/IP stack are disabled for the vMotion service. If a live migration uses the default TCP/IP stack while you configure VMkernel adapters with the vMotion TCP/IP stack, the migration completes successfully. However, the involved VMkernel adapters on the default TCP/IP stack are disabled for future vMotion sessions. Provisioning TCP/IP stack Supports the traffic for virtual machine cold migration, cloning, and snapshot migration. You can use the provisioning TCP/IP to handle Network File Copy (NFC) traffic during long-distance vMotion. NFC provides a file-specific FTP service for vSphere. ESXi uses NFC for copying and moving data between datastores. VMkernel adapters configured with the provisioning TCP/IP stack handle the traffic from cloning the virtual disks of the migrated virtual machines in long-distance vMotion. By using the provisioning TCP/IP stack, you can isolate the traffic from the cloning operations on a separate gateway. After you configure a VMkernel adapter with the provisioning TCP/IP stack, all adapters on the default TCP/IP stack are disabled for the Provisioning traffic. Custom TCP/IP stacks You can add custom TCP/IP stacks at the VMkernel level to handle networking traffic of custom applications.
System Traffic Types
Dedicate a separate VMkernel adapter for every traffic type . For distributed switches, dedicate a separate distributed port group for each VMkernel adapter.
Management traffic Carries the configuration and management communication for ESXi hosts, vCenter Server , and host-to-host High Availability traffic. By default, when you install the ESXi software, a vSphere Standard switch is created on the host together with a VMkernel adapter for management traffic. To provide redundancy, you can connect two or more physical NICs to a VMkernel adapter for management traffic. vMotion traffic Accommodates vMotion. A VMkernel adapter for vMotion is required both on the source and the target hosts. Configure The VMkernel adapters for vMotion to handle only the vMotion traffic. For better performance, you can configure multiple NIC vMotion. To have multi-NIC vMotion, you can dedicate two or more port groups to the vMotion traffic, respectively every port group must have a vMotion VMkernel adapter associated with it. Then you can connect one or more physical NICs to every port group. In this way, multiple physical NICs are used for vMotion, which results in greater bandwidth .
Note: vMotion network traffic is not encrypted. You should provision secure private networks for use by vMotion only.
Provisioning traffic Handles the data that is transferred for virtual machine cold migration, cloning, and snapshot migration. IP storage traffic and discovery Handles the connection for storage types that use standard TCP/IP networks and depend on the VMkernel networking. Such storage types are software iSCSI, dependent hardware iSCSI, and NFS. If you have two or more physical NICs for iSCSI, you can configure iSCSI multipathing. ESXi hosts support NFS 3 and 4.1. To configure a software Fibre Channel over Ethernet (FCoE) adapter, you must have a dedicated VMkernel adapter. Software FCoE passes configuration information though the Data Center Bridging Exchange (DCBX) protocol by using the Cisco Discovery Protocol (CDP )VMkernel module. Fault Tolerance traffic Handles the data that the primary fault tolerant virtual machine sends to the secondary fault tolerant virtual machine over the VMkernel networking layer. A separate VMkernel adapter for Fault Tolerance logging is required on every host that is part of a vSphere HA cluster. vSphere Replication traffic Handles the outgoing replication data that the source ESXi host transfers to the vSphere Replication server. Dedicate a VMkernel adapter on the source site to isolate the outgoing replication traffic. vSphere Replication NFC traffic Handles the incoming replication data on the target replication site. vSAN traffic Every host that participates in a vSAN cluster must have a VMkernel adapter to handle the vSAN traffic. vSphere Backup NFC VMKernel port setting for dedicated backup NFC traffic. NFC traffic goes through the VMKernel Adapter when vSphereBackup NFC service is enabled. NVMe over TCP VMkernel port setting for dedicated NVMe over TCP storage traffic. NVMe over TCP storage traffic goes through the VMkernel Adapter when NVMe over TCP adapter is enabled. For more information see vSphere Storage Guide . NVMEe over RDMA VMkernel port setting for dedicated NVMe over RDMA storage traffic. NVMe over RDMA storage traffic goes through the VMkernel Adapter when NVMe over RDMA adapter is enabled. For more information, see vSphere Storage Guide .
Use the provisioning TCP/IP stack to isolate traffic for cold migration, VM clones, and snapshots, and to assign a dedicated default gateway, routing table, and DNS configuration for this traffic. To enable the Provisioning TCP/IP stack, assign it a new VMkernel adapter.
By using a separate TCP/IP stack, you can handle vMotion and cold migration traffic according to the topology of the network and as required for your organization:
Route the traffic for migration of powered on or powered off virtual machines by using a default gateway. The gateway must be different from the gateway assigned to the default stack on the host.
By using a separate default gateway, you can use DHCP for IP address assignment to the VMkernel adapters for migration in a flexible way.
VMKernel Port: TCP/IP Stack Configuration Video Tutorial
Conclusion
You can choose VMkernel Port setting as per your use-case fit scenario in preconfigured TCP/IP stack options: Default stack Vs vMotion TCP/IP stack Vs Provisioning Stack.
VMKernel Port: Provisioning TCP/IP Stack
Provisioning TCP/IP Stack: utilized to isolate some virtual machine related operations such as cold migrations, cloning, snapshot, NFC related traffic.
- Supports the traffic for virtual machine cold migration, cloning, and snapshot migration.
- Provisioning TCP/IP to handle Network File Copy (NFC) traffic during long-distance vMotion.
- NFC provides a file-specific FTP service for vSphere. ESXi uses NFC for copying and moving data between datastores.
- VMkernel adapters configured with the provisioning TCP/IP stack handle the traffic from cloning the virtual disks of the migrated virtual machines in long-distance vMotion.
- By using the provisioning TCP/IP stack, you can isolate the traffic from the cloning operations on a separate gateway.
After you configure a VMkernel adapter with the provisioning TCP/IP stack, all adapters on the default TCP/IP stack are disabled for the Provisioning traffic. Read more Provisioning in dedicated TCP/IP stacks
Note: Provisioning traffic Handles the data that is transferred for virtual machine cold migration, cloning, and snapshot migration.
Необходимость в ПО для виртуальной коммутации
Большинство физических машин будут иметь одну или более сетевые платы, которые не только позволяют им взаимодействовать с прочими сетевыми компонентами, но также предоставляют уникальную сетевую идентичность в виде некоторого MAC адреса и IP адреса. Теперь, когда вы применяете некоторую отдельную машину для размещения различных виртуальных машин, исполняющих некоторые обычные операционные системы, которые когда- то работали на какой- то физической машине, всплывает на поверхность их потребность иметь некую адресацию. Общий вызов такой: как мы назначим уникальные идентификационные данные для каждой из этих виртуальных машин и как мы заставим их стать частью сетевой среды нашей организации? Часть нашего ответа вводит существенное понятие Виртуальной сетевой интерфейсной платы ( vNIC , Virtual NIC ): именно она создаётся в некоторой виртуальной машине чтобы позволить ей соединяться с имеющейся сетевой средой. Второй частью данного вызова является тот факт, что хотя вы и имеете множество vNIC, соединённых с некоторой виртуальной машиной, должен иметься некий способ направлять весь обмен vNIC прочь из хоста ESXi через его физические NIC. Этот вызов разрешается при помощи некоторого определяемого программно коммутатора ( software seitch ). Программно определяемый коммутатор не является понятием, которое дебютировало в ESXi; некая его форма уже входила в состав продукта виртуализации VMware под названием VMware Workstation. Однако, он тогда не имел названия коммутатора. Поскольку VMware Workstation выходит за пределы тем, рассматриваемых в данной книге, мы охватим только те конструкции виртуальной коммутации, которые доступны в некоторой среде vSphere. Итак, что в действительности делает программно определяемый коммутатор? Он делает возможной агрегацию сетевых соединений от множества vNIC, применяет к ним политики сетевых настроек, а также прикрепляет их к имеющимся в хостах ESXi физическим адаптерам для протекания обмена. В этом имеется нечто большее чем то, что я пытался высказать в предыдущем предложении. В данной главе мы погрузимся глубже во все концепции построения виртуальных сетевых сред.
Необходимость в ПО для виртуальной коммутации
Большинство физических машин будут иметь одну или более сетевые платы, которые не только позволяют им взаимодействовать с прочими сетевыми компонентами, но также предоставляют уникальную сетевую идентичность в виде некоторого MAC адреса и IP адреса. Теперь, когда вы применяете некоторую отдельную машину для размещения различных виртуальных машин, исполняющих некоторые обычные операционные системы, которые когда- то работали на какой- то физической машине, всплывает на поверхность их потребность иметь некую адресацию. Общий вызов такой: как мы назначим уникальные идентификационные данные для каждой из этих виртуальных машин и как мы заставим их стать частью сетевой среды нашей организации? Часть нашего ответа вводит существенное понятие Виртуальной сетевой интерфейсной платы ( vNIC , Virtual NIC ): именно она создаётся в некоторой виртуальной машине чтобы позволить ей соединяться с имеющейся сетевой средой. Второй частью данного вызова является тот факт, что хотя вы и имеете множество vNIC, соединённых с некоторой виртуальной машиной, должен иметься некий способ направлять весь обмен vNIC прочь из хоста ESXi через его физические NIC. Этот вызов разрешается при помощи некоторого определяемого программно коммутатора ( software seitch ). Программно определяемый коммутатор не является понятием, которое дебютировало в ESXi; некая его форма уже входила в состав продукта виртуализации VMware под названием VMware Workstation. Однако, он тогда не имел названия коммутатора. Поскольку VMware Workstation выходит за пределы тем, рассматриваемых в данной книге, мы охватим только те конструкции виртуальной коммутации, которые доступны в некоторой среде vSphere. Итак, что в действительности делает программно определяемый коммутатор? Он делает возможной агрегацию сетевых соединений от множества vNIC, применяет к ним политики сетевых настроек, а также прикрепляет их к имеющимся в хостах ESXi физическим адаптерам для протекания обмена. В этом имеется нечто большее чем то, что я пытался высказать в предыдущем предложении. В данной главе мы погрузимся глубже во все концепции построения виртуальных сетевых сред.
Results
After you create a VMkernel adapter on the provisioning TCP/IP stack, you can use only this stack for cold migration, cloning, and snapshots on this host. The VMkernel adapters on the default TCP/IP stack are disabled for the provisioning service. If a live migration uses the default TCP/IP stack while you configure VMkernel adapters with the provisioning TCP/IP stack, the data transfer completes successfully. However, the involved VMkernel adapters on the default TCP/IP stack are disabled for future cold migration, cross-host cloning, and snapshot sessions.
While working through VCAP6-Deploy blueprint I stumbled upon topic TCP/IP stack configuration. I have seen this many times in my lab while configuring networking stuffs and had a basic idea of what is the purpose of using custom TCP/IP stack. Suprisingly this feature is there with vSphere 5.5, but I never noticed it.
I decided to discover more about TCP/IP stack in my lab and share my experience through this write up. I will start with very basic.
What is VMkernel TCP/IP and why to use it?
The purpose of a TCP/IP Stack configuration in VMware vSphere Hosts is to setup the Networking Parameters which will allow the communication between the Hosts themselves including the Virtual Machines, other Virtual Appliances and last but not least the Network Storage.
We all know that as per networking best practices, its good to have dedicated VMkernel adapters for different type of traffics such as management, vMotion, vSAN, iSCSI and vSphere Replication etc. The TCP/IP stack creates “traffic profiles” which can be used in conjunction with VMkernel adapter configuration to achieve separation of duties.
Benefits of a Separate TCP/IP Stack
Before vSphere 5.5, there was a single TCP/IP stack and which was shared by all type of system traffic. Although there was nothing wrong this configuration, but problem arises when you want to segment traffic using multiple subnets/vLAN’s in your environment. With single TCP/IP stack all kind of traffic was using one default gateway.
In vSphere 5.5 VMware introduced capability of creating custom TCP/IP stack via command line with limitation that only certain type of traffic could make use of custom stack. Custom TCP/IP stacks can be used to handle the network traffic of other applications and services, which may require separate DNS and default gateway configurations. With custom TCP/IP stack, you get following benefits:
- Separate Memory Heap.
- Personalized ARP Table.
- Personalized Routing Table which helps avoiding routing table conflicts that might appear when many features are using a common TCP/IP stack.
- Isolate traffic to improve network security.
Default TCP/IP stacks available in vSphere
In vSphere 6, VMware introduced 2 new TCP/IP stack other than default one. Now we have following TCP/IP stacks available by default:
Default TCP/IP stack: This stack handles management traffic between ESXi hosts and vCenter server. Also other traffic like vMotion, NFS/iSCSI storage, HA and vSphere FT can use this stack. This stack shares a single default gateway between all configured network services.
vMotion TCP/IP stack: This stack is optimized for handling vMotion traffic. By creating a VMkernel port on the vMotion TCP/IP stack you can isolate vMotion traffic to this stack. The use of this stack completely disables vMotion traffic from the default TCP/IP stack.
vMotion TCP/IP stack allow vMotions to occur at a Layer 3 level for both within a single vCenter as well as from vCenter to vCenter.
Provisioning TCP/IP stack: The provisioning TCP/IP stack is used for cold VM migration, cloning and snapshotting traffic. In case of a long-distance vMotion, NFC traffic can be configured to use the provisioning TCP/IP stack.
A common use case for using dedicated provisioning TCP/IP stack is VDI environments or in those environment where VM snapshots is used frequently.
How to create custom TCP/IP stack
With vSphere 6, a custom TCP/IP stack cannot be created in the Web Client interface and we have to rely on Esxi CLI for this. However once a custom stack has been created from command line, you can edit the properties of newly created stack from Web Client.
In VMware vSphere ESXi 6.x and/or later you get the VMKernel Port settings options: Default Stack Vs dedicated vMotion TCP/IP Stack Vs Provisioning Stack, which one you need to choose ? this is very confusing right. Don’t worry i am going to share the advantages and disadvantages of VMkernel Port default stack Vs vMotion TCP/IP stack Vs Provisioning Stack optional features.
I will discuss about VMware vSphere ESXi host VMKernel port setting:
Procedure
- In the vSphere Client , navigate to the host.
- Click the Configure tab.
- Select Networking , and click VMkernel adapters .
- Click Add networking .
- On the Select connection type page, select VMkernel Network Adapter and click Next .
- On the Select target device page, select the switch for the VMkernel adapter, and click Next .
Option Description Select an existing network Use the physical adapter configuration of an existing distributed port group to send data from the VMkernel adapter to the external network. Select an existing standard switch Use the physical adapter configuration for the VMkernel adapter of an existing standard switch. New vSphere standard switch Assign a new physical adapter configuration for the VMkernel adapter on a new standard switch. - On the Port properties page, select Provisioning from the TCP/IP stack drop-down menu.
The provisioning traffic becomes the only service that is enabled. You cannot use this VMkernel adapter for traffic types other than provisioning.
Enter the IPv4 IP address and subnet mask for the VMkernel adapter.
The VMkernel Default Gateway and DNS server addresses for IPv4 are obtained from the selected TCP/IP stack.
Select the Override default gateway for this adapter check box and enter a gateway address, if you want to specify a different gateway for the VMkernel adapter.
In ESXi 6.5 and later router advertisement is enabled by default and supports the M and O flags in accordance with RFC 4861.
- Click Add IPv6 address to add a new IPv6 address.
- Enter the IPv6 address and subnet prefix length, and click OK .
- To change the VMkernel default gateway, click Override default gateway for this adapter .
The VMkernel Default Gateway address for IPv6 is obtained from the selected TCP/IP stack.
VMKernel Port: Default TCP/IP Stack
Default TCP/IP Stack is the multi-purpose stack that can be used to manage any of the host related traffic services. Shares a single default gateway between all configured network services.
Provides networking support for the management traffic between vCenter Server and ESXi hosts, and for system traffic such as vMotion, IP storage, Fault Tolerance, and so on.
- Default TCP/IP stack: Supports management traffic
- Default TCP/IP stack: Supports vMotion trafic
- Default TCP/IP stack: Supports storage traffic
- Default TCP/IP stack: Supports Fault Tolerance traffic
VMKernel Port: vMotion TCP/IP Stack
vMotion TCP/IP Stack is the isolated / dedicated vMotion traffic with more security onto its own stack for live migration of virtual machines. The use of this stack completely removes or disable vMotion traffic from the default TCP/IP stack.
If a live migration uses the default TCP/IP stack while you configure VMkernel adapters with the vMotion TCP/IP stack, the migration completes successfully. However, the involved VMkernel adapters on the default TCP/IP stack are disabled for future vMotion sessions.
Use the vMotion TCP/IP to provide better isolation for the vMotion traffic.
- vMotion TCP/IP stack: Supports the live migration, vMotion, of virtual machines
- vMotion TCP/IP stack is dedicated for vMotion traffic only, can’t use for another type of traffic
- vMotion TCP/IP stack isolate the vMotion traffic from other traffic
- vMotion TCP/IP stack traffic is more secure then default TCP/IP stack
- vMotion TCP/IP stack disable the vMotion feature on Default TCP/IP stack VMKernel Port becuase vMotion TCP/IP stack is more secure and prioritized.
Note: When you choose vMotion TCP/IP stack, only vMotion traffic will be selected and other options will be grayed out.
Note: Creating VMKernel interface with vMotion TCP/IP stack will disable vMotion on all other VMKernel ports which are using Default TCP/IP stack.
Securing System Traffic
Take appropriate security measures to prevent unauthorized access to the management and system traffic in your vSphere environment. For example, isolate the vMotion traffic in a separate network that includes only the ESXi hosts that participate in the migration. Isolate the management traffic in a network that only network and security administrators can access. For more information, see vSphere Security and vSphere Installation and Setup .
Prerequisites
Verify that the host is running ESXi 6.0 or later
Разница между физическим и виртуальным коммутаторами
Теперь, когда мы осознали необходимость в некотором виртуальном коммутаторе, существенно понимать в чём отличия некоторого виртуального коммутатора при его сравнении с неким физическим коммутатором. Основной момент состоит в том, что VMware называет его неким виртуальным коммутатором для отображения того факта, что он способен переключать кадры между своими виртуальными портами или физическими восходящими связями. Итак, существуют ли какие- то отличия от некоторого физического коммутатора? Общий ответ - да, причём в паре направлений. Одно из отличий состоит в том способе, которым имеющийся виртуальный коммутатор обрабатывает передаваемые кадры:
Рисунок 1
Когда некий кадр поступает в любой физический коммутатор, его получатель определяется определённым номером порта коммутатора, соответствующим MAC адресу его получателя в имеющейся у данного физического коммутатора таблице MAC адресов. Если у вас нет возможности найти некую запись в данной таблице MAC адресов, он направляет данный кадр во все порты, отличающиеся данного порта источника. Во многом аналогично такому физическому коммутатору, любой виртуальный коммутатор также поддерживает некую таблицу MAC адресов, однако для виртуального коммутатора отсутствует какой бы то ни было процесс обучения. Виртуальный коммутатор уже будет иметь некий перечень MAC алресов и их номеров виртуальных портов. Если в виртуальный комутатор поступает некий кадр с каким- то MAC адресом, который не представлен в имеющейся в виртуальном коммутаторе таблице MAC адресов, тогда она отсылается через физический NIC (активные восходящие соединения), подключённый к данному виртуальному коммутатору. Это остаётся верным только если источником данного потока является некая виртуальная машина или некий интерфейс vmkernel, иными словами, только в случае когда этот кадр поступает через некий виртуальный порт. Если в какой бы то ни было виртуальный коммутатор поступает некий кадр с неизвестным MAC адресом через его физическое восходящее соединение, тогда этот кадр отбрасывается данным виртуальным коммутатором. Второе отличие состоит в общем числе портов в данном коммутаторе. Физический коммутатор будет иметь фиксированное число портов; некий виртуальный коммутатор будет всё- таки иметь некий максимальный предел, однако при этом намного большее число настраиваемых портов. В настоящее время VMware поддерживает до 4 096 виртуальных портов коммутации на хост ESXi. Третье отличие состоит в том, что он в сравнении с некоторыми, или даже с большинством, физических коммутаторов не является управляемым коммутатором, что, по существу, означает отсутствие у него собственного IP адреса управления или некоторой операционной системы, наподибии Cisco IOS. Вместо этого имеющиеся виртуальные коммутаторы управляются в гипервизоре или vCenter в зависимости от самого типа применяемого виртуального коммутатора (стандартный vSitch или VDS - распределённый виртуальный коммутатор).
Нумерация физических NIC
Вы можете включить в некотором хосте ESXi в общей сложности максимально до 32 1Gbps и 16 10Gbps портов Ethernet. Эти максимальные значения регулируются созданием/ моделями/ драйверами/ свойствами имеющихся плат NIC и их комбинаций. Например, вы получаете до 32 1Gbps портов Ethernet Broadcom при использовании драйвера tg3 и отключённом NetQueue , однако тот же самый NIC с включённым NetQueue может представлять только 16 портов. Если бы вы применяли некую комбинацию портов Ethernet 10Gbps и 1Gbps, тогда можно было бы включить только 16 портов 10Gbps и четыре порта 1Gbps.
Теперь, когда ESXi имеет возможность управления большим числом физических NIC, должен иметься некий метод логического представления таких NIC для применения к ним политик настройки. Это достигается путём нумерации имеющихся физических NIC по шаблону vmnicX ( vmnic0 . vmnic32 ). Помимо этого имеется некая логика поведения такой нумерации. Все NIC последовательно нумеруются на протяжении процесса начальной загрузки ESXi при сканировании шины PCI, слота и номера порта. В настройках некоторого ESXi хоста /etc/vmware/esx.conf можно обнаружить соответствие PCI-id для vmnic :
The VMkernel networking layer provides connectivity to hosts and handles the standard system traffic of vSphere vMotion, IP storage, Fault Tolerance, vSAN , and others. You can also create VMkernel adapters on the source and target vSphere Replication hosts to isolate the replication data traffic.
Читайте также: