##CONTINUE##
Without a server virtualisation solution, data centre network administrators generally don't have to deal with constantly changing MAC addresses, nor do they need to track MAC addresses. This is because the MAC addresses are usually burned into the physical network interface cards (NICs) on the servers. Typically, therefore, data centre network administrators are safe when they consider the MAC address for a server to be a fixed value, and they can plan accordingly when configuring IP address reservations or when troubleshooting network connectivity.
With a server virtualisation solution, however, a virtual server's MAC address can change. For example, VMware's live migration functionality, VMotion, can move a running workload from one physical server to another with no downtime. When a virtual machine gets migrated in this fashion, though, a new MAC address is generated. Any configurations that were built around the old MAC address will no longer apply.
Granted, there are not that many instances in which data centre network administrators configure things based on the MAC address. Where these configurations do exist, however, data centre network admins are left with the option of manually generating MAC addresses and tracking the assignment of these MAC addresses to virtual machines. This manual process leaves room for error, of course, and these errors manifest themselves most commonly in the form of MAC address collisions. These MAC address collisions result in intermittent connectivity loss and can be difficult to troubleshoot. Unfortunately, there's no easy way to be "on the lookout" for MAC address collisions; erratic and intermittent connectivity problems are the only real indication.
Increased VLAN usage
VLANs can also be heavily influenced by the addition of server virtualisation. While data centre network admins are quite familiar with VLANs, they may not be quite so prepared for how extensively VLANs are used with many server virtualisation products. For example, VMware ESX and VMware ESXi have extensive support for 802.1q VLAN tags. This even includes the ability to pass 802.1q VLAN tags all the way up to the virtual machines for operating systems that have support for managing VLANs.
To take advantage of this VLAN support, however, the physical switch ports must be configured to operate as 802.1q VLAN trunks. This practice runs contrary to the way many data centre network admins configure their switches. In general, data centre network ports are configured as access ports, carrying traffic only for a single VLAN, and these ports do not pass the 802.1q VLAN tags up to servers. Without the physical switch ports configured as 802.1q VLAN trunks, it will usually require more NICs and more Gigabit Ethernet ports on the physical switches to match the same level of flexibility as with 802.1q VLAN support. This may increase the initial acquisition cost and reduce the overall ROI of the server virtualisation solution.
In addition to changing the default configuration for physical switch ports, data centre network administrators will also need to grow accustomed to a closer interaction between the VLAN configuration on their switches and the physical servers running the server virtualisation software. VLANs must not only be configured on the switches, they must also be allowed across the VLAN trunks and properly configured inside the server virtualisation software with the correct VLAN ID. This doesn't take into account native (or untagged) VLAN settings and how those interact with the server virtualisation software. An incorrect setting anywhere along the way will adversely affect network connectivity for all the workloads running on that physical server.
This tighter interaction between the data centre network administrators and the server administrators regarding VLANs and VLAN configuration is only one of several areas in which these two groups will need to work together more closely than perhaps they have in the past. Another area is link aggregation configuration.
NIC teaming and bonding
Some server virtualisation solutions also offer support for various forms of NIC teaming or bonding. Supporting NIC teaming or bonding allows the virtualisation solution to provide redundancy and/or more efficient utilisation of multiple physical NICs. In some cases, this NIC teaming or bonding also requires configuration on the physical switch, typically to enable link aggregation support via 802.3ad/LACP (Link Aggregate Control Protocol) or a proprietary alternative like Gigabit EtherChannel from Cisco or Multi-Link Trunk from Nortel.
This means that data centre network admins and server administrators will need to share information about which NICs are plugged into which network ports so that the link aggregation can be properly configured. Fortunately, some virtualisation solutions include support for technologies like Cisco Discovery Protocol (CDP) to simplify the process of matching NICs to switch ports. Making link aggregation work properly in conjunction with server virtualisation may also require changes to the load balancing configuration of the physical switches.
Finally, one of server virtualisation's greatest strengths -- the ability to provision new virtual machines quickly and easily -- may also be a data centre network admin's major headache. In some environments, the implementation of virtualisation leads to "VM sprawl," and admins must track large numbers of IP addresses and networked devices, with the addition of new virtual servers occurring frequently. Data centre network admins should be prepared for this possibility and have systems and procedures in place for handling a potentially greater demand for IP addresses.-----------------------------
BY Scott Lowe
Source：SearchNetworking.com
© 2009 TechTarget ANZ. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. Use of this web site constitutes acceptance of the TechTarget ANZ Terms and Conditions and Privacy Policy.
Posts
0 comments:
Post a Comment