Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
This test is to review what "Route based on source MAC hash" does and how it perform the required traffic load balancing.
Showing posts with label VMware. Show all posts
Showing posts with label VMware. Show all posts
Tuesday, 18 October 2011
Wednesday, 12 October 2011
ESXi 5.0 Load Balancing Test: Route based on IP hash
Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash Select an uplink based on a hash of the source Ethernet.
Use explicit failover order Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
The test below is to test and study what "Route based on IP hash" does and how it perform traffic load balancing.
Route based on the originating port ID Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash Select an uplink based on a hash of the source Ethernet.
Use explicit failover order Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
The test below is to test and study what "Route based on IP hash" does and how it perform traffic load balancing.
ESXi 5.0 Load Balancing Test: Route based on the originating virtual port ID
Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria. This test is to review what "Route based on the originating port ID" does and how it perform the required traffic load balancing.
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria. This test is to review what "Route based on the originating port ID" does and how it perform the required traffic load balancing.
Tuesday, 11 October 2011
vSwitch Network Failover Detection Testing: Beacon Probing and Link Status
In ESXi 5.0, under vSwitch Network NIC Teaming, there is a Network Failover Detection field. It has two setting, Beacon Probing and Link Status Only.
Under the help Section, it state the following,
Link Status only
Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
After three days of testing over weekends, I found Beacon Probing is very confusing, but it works.
Link Status is what stated above, nothing much to test. But Beacon Probing is Beacon + Link State.
Under the help Section, it state the following,
Link Status only
Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
After three days of testing over weekends, I found Beacon Probing is very confusing, but it works.
Link Status is what stated above, nothing much to test. But Beacon Probing is Beacon + Link State.
Wednesday, 5 October 2011
vSwitch Networking Security Testing - Part 2 MAC Address Changes
In ESXi 5.0 Networking Security, each vSwitch has the following Security Policy Tab.
A Windows 2008 R2 Server VM is installed in the ESXi 5.0 Server and a Port Group is created for this VM.
Under the help menu of "Edit Security Policy for a vSphere Standard Switch". It state the difference between these two setting
The confusion is, reference to where? or from which perspective? While doing networking for so many years, I came to understand that when we come to "Inbound" traffic and "Outbound" traffic, we must think like a Router or Switch. If I am a Router, any traffic that is coming into me is an "Inbound" traffic, the traffic can be from any interfaces. That goes the same to any traffic that is going out of me, which is an "Outbound" traffic, it can also be going out of any Interfaces. That goes the same if your are a Server.
But in the case of a Server it's "Inbound" traffic is the Physical Switch "Outbound" traffic, and the Server "Outbound" traffic is the Physical Switch "Inbound" traffic. When we read the traffic, we have to know where we stand. Inside the Server? or Inside the Switch. That is what I called perspective of things.
The problem with the above statement is that it does not state the "Inbound" and "Outbound" is from which perspective. From the virtual machine or from the virtual switch.
In any case, I am doing some test to find out.
- Promiscuous Mode: Accept or Reject
- MAC Address Changes: Accept or Reject
- Forged Transmits: Accept or Reject
A Windows 2008 R2 Server VM is installed in the ESXi 5.0 Server and a Port Group is created for this VM.
Under the help menu of "Edit Security Policy for a vSphere Standard Switch". It state the difference between these two setting
- MAC Address Changes
- Reject - If you set the MAC Address Changes to Reject and the guest operating system changes the MAC address of the adapter to anything other than what is in the .vmx configuration file, all inbound frames are dropped. If the Guest OS changes the MAC address back to match the MAC address in the .vmx configuration file, inbound frames are passed again.
- Accept - Changing the MAC address from the Guest OS has the intended effect: frames to the new MAC address are received.
- Forged Transmits
- Reject - Any outbound frame with a source MAC address that is different from the one currently set on the adapter are dropped.
- Accept - No filtering is performed and all outbound frames are passed.
The confusion is, reference to where? or from which perspective? While doing networking for so many years, I came to understand that when we come to "Inbound" traffic and "Outbound" traffic, we must think like a Router or Switch. If I am a Router, any traffic that is coming into me is an "Inbound" traffic, the traffic can be from any interfaces. That goes the same to any traffic that is going out of me, which is an "Outbound" traffic, it can also be going out of any Interfaces. That goes the same if your are a Server.
But in the case of a Server it's "Inbound" traffic is the Physical Switch "Outbound" traffic, and the Server "Outbound" traffic is the Physical Switch "Inbound" traffic. When we read the traffic, we have to know where we stand. Inside the Server? or Inside the Switch. That is what I called perspective of things.
The problem with the above statement is that it does not state the "Inbound" and "Outbound" is from which perspective. From the virtual machine or from the virtual switch.
In any case, I am doing some test to find out.
Friday, 30 September 2011
vSwitch Networking Security Testing - Part 1 Promiscuous Mode
In ESXi 5.0 Networking Security, each vSwitch has the following Security Policy Tab.
A Windows 7 VM is installed in the ESXi 5.0 Server and connected to the same VLAN as the Management Traffic.
WireShark is installed in the VM to capture the traffic in the vSwitch. Microsoft Network Capture is used to open the WireShark captured packet. MS NCap is use because NCap can do a better job in sorting TCP Session as compare to WireShark.
- Promiscuous Mode: Accept or Reject
- MAC Address Changes: Accept or Reject
- Forged Transmits: Accept or Reject
A Windows 7 VM is installed in the ESXi 5.0 Server and connected to the same VLAN as the Management Traffic.
WireShark is installed in the VM to capture the traffic in the vSwitch. Microsoft Network Capture is used to open the WireShark captured packet. MS NCap is use because NCap can do a better job in sorting TCP Session as compare to WireShark.
Wednesday, 28 September 2011
ESXi 5.0 Management Network Interface Testing - Part 2
Part 2 of the Management Network Interface Testing is about miscofig of ESXi Management Network Interface.
Misconfiguration happened very day and is part of life. We learned from our mistake and gain experience from our mistake.
In this part 2 of the test, three tests will be performed
Misconfiguration happened very day and is part of life. We learned from our mistake and gain experience from our mistake.
In this part 2 of the test, three tests will be performed
- Duplicate IP address of current Management IP in the same network segment.
- Misconfig of Management Network IP.
- Delete of Management Network IP that is currently connecting to vCenter.
ESXi 5.0 Management Network Interface Testing - Part 1
During the course of upgrading my ESX 4.1 Server farm. I notice that the behaviour of ESXi Management Network Interface is different from the Service Console of ESX 4.1. With that, I decided to further test and understand the concept and deployment of multiple Management Interface of ESXi 5.0.
Test Objectives
The test objective is to test the redundancy of ESXi Management Network Interface for vCenter connectivity and SSH. Objective is to recover ESXi remotely should a portion of the network failed.
The test objective is to test the redundancy of ESXi Management Network Interface for vCenter connectivity and SSH. Objective is to recover ESXi remotely should a portion of the network failed.
Saturday, 24 September 2011
ESXi 5.0 Kickstart Installation Part 4 - The Kickstart File Result
ESX 5.0 Kickstart Installation
Below is the result of the Kickstart Script.
vSwitch0
Below is the result of the Kickstart Script.
vSwitch0
ESXi 5.0 Kickstart Installation Part 3 - The Kickstart File
# +---------------------------------------------------------------------------+
# | Kickstat File : ESX07
# +---------------------------------------------------------------------------+
# +---------------------------------------------------------------------------+
# | Start of ESXi 5.0 Kick Start Script (22 Sept 2011)
# +---------------------------------------------------------------------------+
# +---------------------------------------------------------------------------+
# | Accept License agreement
# +---------------------------------------------------------------------------+
vmaccepteula
# +---------------------------------------------------------------------------+
# | Disk Partitioning
# | Clear all partitions in first detected disk and overwrite any VMFS
# | partitions on the specified drives.
# +---------------------------------------------------------------------------+
clearpart --firstdisk --overwritevmfs
# | Kickstat File : ESX07
# +---------------------------------------------------------------------------+
# +---------------------------------------------------------------------------+
# | Start of ESXi 5.0 Kick Start Script (22 Sept 2011)
# +---------------------------------------------------------------------------+
# +---------------------------------------------------------------------------+
# | Accept License agreement
# +---------------------------------------------------------------------------+
vmaccepteula
# +---------------------------------------------------------------------------+
# | Disk Partitioning
# | Clear all partitions in first detected disk and overwrite any VMFS
# | partitions on the specified drives.
# +---------------------------------------------------------------------------+
clearpart --firstdisk --overwritevmfs
ESXi 5.0 Kickstart Installation Part 2 – Getting the Kickstart Script kicking
ESX 5.0 Kickstart Installation
Limited VMware Documentation
Under the section “Installation and Upgrade Script Commands”. You will find some commands there, but it will not bring you far for your scripting customization.
OK. I must say, looking into VMware “vSphere Installation and Setup” guide for help doesn’t do much help. Or, you only got 10% of the script required.
Limited VMware Documentation
For booting and locating the Kickstart file, you can look into vSphere 5.0 documentation
ESXi and vCenter Server 5.0 Documentation > vSphere Installation and Setup > Installing, Upgrading, or Migrating Hosts Using a Script > Enter Boot Options to Start an Installation or Upgrade Script
Under the section "Boot Options", you will find some commands option to tell ESXi where to locate the kickstart script.As for the kickstart script, you can find some information in
ESXi and vCenter Server 5.0 Documentation > vSphere Installation and Setup > Installing, Upgrading, or Migrating Hosts Using a Script > About Installation and Upgrade ScriptsUnder the section “Installation and Upgrade Script Commands”. You will find some commands there, but it will not bring you far for your scripting customization.
Most ESX 4.1 Kickstart Script Don't Work
With my experience in creating kickstart script in ESX 4.1, I decided to reuse most of my 4.1 kickstart script. To my surprise, most of the command failed. That left me with no choice but to learn how to write vSphere 5.0 kickstart from basic again.
ESXi 5.0 Kickstart Installation Part 1 - Getting the USB Drive Ready
ESX 5.0 Kickstart Installation
As I have 7 ESX 4.1 Servers in my Environment each with many VLANs, iSCSI and NFS Setting, I need to find a way to automate the installation and create a script that will bring consistency setting across my ESX farm. This is where I spend 2 days understanding the different options to automate this process.
I have dropped the use of DHCP+PXE+TFTP as it is too complicated to setup if I have another site to install. In addition, I can’t bring my whole DHCP+PXE+TFTP Servers setup into another site. In addition, if the installation site is in Customer environment, addition a DHCP+PXE+TFTP sound like a lot of things to explain and answer to customer.
Upgrade ESX 4.1 update 1 to ESXi 5
vSphere 5 is out! Manage to find some time this week to upgrade my ESX 4.1 update 1 environment to vSphere 5. For those people out there using ESX(i) whitebox, below is my whitebox configuration that works with ESX(i) 4.1 and ESXi 5.
Item | Description | Qty | Cost | Total (SGD) |
1 | Gigabyte x58A-UD3R | 1 | $ 365 | $ 365 |
2 | Intel i7-960 3.2 GHz | 1 | $ 377 | $ 377 |
3 | Asus EAH5450 Silent 1 GB DDR3 | 1 | $ 79 | $ 79 |
4 | Kingston 12800/1600 (3x4GB in a kit) | 2 | $ 219 | $ 438 |
5 | Seagate 1 TB 32MB 7200rpm | 1 | $ 82 | $ 82 |
6 | Seagate 1.5 TB 32MB 7200rpm | 1 | $ 105 | $ 105 |
7 | Andyson F650M 650W Modular 80+ | 1 | $ 135 | $ 135 |
8 | Samsung S222 22x DvD+-RW | 1 | $ 22 | $ 22 |
9 | Intel Gigabit ET Dual Port Server Adapter E1G42ET | 2 | $ 225 | $ 450 |
10 | Normal Casing | 1 | $ 72 | $ 72 |
Total (in Singapore Dollars) | $2,125 |
Subscribe to:
Posts (Atom)