Dear All, In previous modules, we explored different topics of VMware and other products. In this module, we are going to learn VMware Site Recovery Manager(SRM) which is an essential component of disaster recovery of your Virtual Data Center. Every VMware admin who is looking for a DR solution, should explore SRM product.
- Site Recovery Manager provides automation of failover and disaster recovery testing in your Virtual Environment.
- It provides application availability and mobility across sites in private cloud environments with policy-based management, non- disruptive testing and automated orchestration.
- You can plan, test, and run the recovery of virtual machines between a protected vCenter Server site and a recovery vCenter Server site using VMware SRM.
VMware SRM helps you to achieve the followings: –
Once Click Recovery during Disaster
Delivers Fast and Reliable IT Disaster Recovery
Uses simple Policy-Based Management
Powers Disaster Recovery as-a-Service (DRaaS)
Lowers Total Cost of ownership Up to 50%
I am not going much in depth in this article as I am going to share step by step about everything of SRM in next articles. I will try to write this complete module in such a way which can be easy to understand even for beginners.
Another most foremost thing which I would like to highlight here, that we are going to explore this complete module on recently launched VMware SRM version which 8.1.
There is quick steps to deploy VMware Site Recovery Manager which you need to understand in below points: –
I have explained each points(mentioned above in pictorial view) in different topics below and that’s too in step by step procedure so that it can helpful for you to get a better understanding.
Take a look in below topics, explore and learn Site Recovery Manager: –
Learn SRM – Part 4 – Prepare for Replicated Storage in you Home Lab (Ignore this step in Real Environment. You need to interact with Storage team for all these tasks in real environment)
Stay tuned for next articles and modules. Please do share if you found this module useful.
Downtime is something which always costs to company. VMware helps to reduce downtime at each layer.
- Component Level (NIC multi-pathing ,storage multi-pathing)
- Server level(vMotion and DRS)
- Storage level (sDRS)
Similarly vSphere HA provides a base level of protection for your virtual machines by restarting virtual machines in the event of a host failure. vSphere HA is configured on multiple ESXi hosts cluster to provide quick recovery in case of outage. vSphere give HA as cost effective solution for high availability for the application running on virtual machine. HA protects against:
- Host failure
- Data store accessibility issue.
- virtual machine against network isolation
- Application failure.
Hosts in the cluster are monitored and in the event of a failure, the virtual machines on a failed host get restarted on alternate hosts with in the cluster.
When you create a vSphere HA cluster, a single host is automatically elected as the master host. The master host communicates with vCenter Server and monitors the state of all protected virtual machines and of the slave hosts. Different types of host failures are possible, and the master host must detect and appropriately deal with the failure. The master host must distinguish between a failed host and one that is in a network partition or that has become network isolated. The master host uses network and datastore heartbeating to determine the type of failure.
Master and Subordinate Hosts
When you add a host to a vSphere HA cluster, an agent (Fault Domain Manager (FDM)) is uploaded to the host and configured to communicate with other agents in the cluster. Each host in the cluster functions as a master host or a subordinate host. After the FDM agents have started, the cluster hosts are said to be in a fault domain.Hosts cannot participate in a fault domain if they are in maintenance mode, standby mode, or disconnected from vCenter Server.
As discussed above when vSphere HA is enabled for a cluster, all active hosts participate in an election to choose the cluster’s master host. The host that mounts the greatest number of datastores has an advantage in the election.If more than one cluster hosts see the same number of datastores, the election process determines the master host by using the host managed object ID (MOID) assigned by vCenter Server.
If the master host fails, is shut down or put in standby mode, or is removed from the cluster a new election is held.
The master host in a cluster has several responsibilities:
Monitoring the state of subordinate hosts. If a subordinate host fails or becomes unreachable, the master host identifies which virtual machines must be restarted.
Monitoring the power state of all protected virtual machines. If one virtual machine fails, the master host ensures that it is restarted. Using a local placement engine, the master host also determines where the restart takes place.
Managing the lists of cluster hosts and protected virtual machines.
Acting as the vCenter Server management interface to the cluster and reporting the cluster health state.
The subordinate hosts primarily contribute to the cluster by running virtual machines locally, monitoring their runtime states, and reporting state updates to the master host. A master host can also run and monitor virtual machines.
Master host is responsible to orchestrate restarts of protected virtual machines. A virtual machine is protected by a master host after vCenter Server observes that the virtual machine’s power state has changed from powered off to powered on in response to a user action. The master host persists the list of protected virtual machines in the cluster’s datastores. A newly elected master host uses this information to determine which virtual machines to protect.
Master hosts send heartbeats periodically to subordinate hosts to know that master is live. Slave host communicate to master via management network.If the slave host does not respond within predefined timeout period, the master host declares the slave host as agent unreachable. When a slave host is not responding, the master host attempts to
determine the cause of the slave host’s inability to respond.
The datastore heartbeats are used to make the distinction between a failed and isolated or partitioned
host. vSphere HA tries to restart virtual machines only in one of these situations:
• A host has failed (no network heartbeats, no ping, no datastore heartbeats).
• A host becomes isolated and the cluster’s configured host isolation response is Power off or Shut down.
Virtual Machine Component Protection
VMCP provides protection against datastore accessibility failures that can affect a virtual machine running on a host in a vSphere HA cluster. When a datastore accessibility failure occurs, the affected host can no longer access the storage path for a specific datastore. You can determine the response that vSphere HA will make to such a failure, ranging from the creation of event alarms to virtual machine restarts on other hosts.
Only vSphere HA clusters that contain ESXi 6 hosts can be used to enable VMCP. Clusters that contain hosts from an earlier release cannot enable VMCP. Such hosts cannot be added to a cluster enabled for VMCP.
Proactive HA Failures
A Proactive HA failure occurs when a host component fails, which results in a loss of redundancy or a noncatastrophic failure. However, the functional behavior of the VMs residing on the host is not yet affected. For example, if a power supply on the host fails, but other power supplies are available, that is a Proactive HA failure.
If a Proactive HA failure occurs, you can automate the remediation action taken in the vSphere Availability section of the vSphere Client. The VMs on the affected host can be evacuated to other hosts and the host is either placed in Quarantine mode or Maintenance mode.
vSphere Standard Switch vs vSphere Distributed Switch
Continuing to vSphere 6.7 Install, Configure, and Manage modules, today we are going to cover vSphere networking which is one of the tough parts to know for VMware admins and have lot of difficulties while applying the network policies.
Points to Cover: –
- Understand Network Policies
- Security Polices
- Traffic Shaping
- Teaming & Failover
- Understand Load Balancing Policies
- What is MTU (Maximum Transmission Unit)
In last section, we learnt the concepts of vSphere Standard Switch and How to Create a vSwitch in a vSphere Environment. In this section, we are going to explore Configuring virtual switch security , traffic -shaping and load -balancing policies.
- Standard Switch policies are configured for enhancing the security of complex virtual environment in a better way.
- You can create multiple port groups in a standard switch, and then you can apply different policies at each port groups.
- You can also apply same network policies for all port groups or standard switch.
Network Policies Applies at: –
How to Apply these Policies?
- Login to vCenter server using Web client.
- Click on host and go to Networking under Configure Tab.
- Select Virtual Switch and Click on Pencil icon to Edit.
vSphere Standard Switch has following Network Policies:
Teaming & Failover
Promiscuous Mode (Accept or Reject)
- It can be defined at Virtual Switch or Port Group level.
- If you change to accept then the guest OS can recieve all traffic which passes through the vSwitch or portgroup.
- When promiscuous mode is enabled at the portgroup level, objects defined within that portgroup have the option of receiving all incoming traffic on the vSwitch.
- When promiscuous mode is enabled at the virtual switch level, all portgroups within the vSwitch will default to allowing promiscuous mode. However, promiscuous mode can be explicitly disabled at one or more portgroups within the vSwitch.
- By default, this policy is set to Reject on virtual switches (standard or distributed)
- Let’s take an example that we have two port groups PG-A and PG-B. In PG-A, we have two Virtual Machines as VM-1 and VM-2. In PG-B, we have another two Virtual machines as VM-3 and VM-4.
- If Promiscuous mode is set to Reject, PG-A and PG-B will not send traffic across and will only deliver packet as point to point delivery.
- But if you set it to accept mode, than it will transfer the traffic to both PG-A and PG-B and it’s VM-1, VM-2, VM-3, VM-4.
MAC Address Changes (Accept or Reject)
- This security policy is enabled by default in standard switch and disabled in Distributed Switch.
- If it is in accepted mode, then host accepts requests to change the effective MAC address to different one than the original.
- MAC Address Changes is concerned with incoming traffic.
- All virtual machines have two MAC addresses:
- Initial MAC – It is generated automatically and that resides in the configuration file(VMX file). Guest OS has no control over the initial MAC Address.
- Effective MAC – It is configured by the guest operating system that is used during communication with other virtual machines. The effective MAC address is included in network communication as the source MAC of the virtual machine. Sometimes you put a manual MAC address in a VM, that is a effective MAC.
- Let’s take an example, you have a Virtual machine with Initial MAC address 00:50:56:AF:3C:FG. Now, due to any reason you changed the MAC address of Virtual machine and Effective MAC address get change to 00:50:56:AF:3C:EH.
- Virtual Machine’s Initial Address and Effective Address must agree with each other. If the guest OS changes the Effective Address, the port will compare the Effective Address to the Initial Address.
- If security policy MAC Address Changes is set to Reject, then Initial Address and Effective Address will not agree with each other and it will result that Port will be administratively down.
- If security policy MAC Address Changes is set to Accept, then new Effective MAC address will be agree to Initial MAC and it will be automatically updated in ARP table and Virtual Machine will work as usual.
- All virtual machines have two MAC addresses:
Forged Transmits (Accept or Reject)
- In this case, a host do not compare source and effective MAC which are transmitted from a VM.
- Forged transmits is concerned with outgoing traffic.
- If Forged Transmits is set to Reject, then traffic will not be passed from the virtual machine to the vSwitch (outgoing) if the initial and the effective MAC addresses do not match.
- MAC Address Changes and Forged transmits are also used by Windows as a mechanism to protect against duplicate IP addresses on the network. If a Windows system detects an IP address conflict it will send out a forged transmit to reset the IP to the original MAC of the machine it think originally owned it and then take itself off the network. This protection mechanism for duplicate IP addresses won’t work without these security settings allowed.
- It is set to Accept on Standard Switch and Reject on Distributed Switch.
Traffic Shaping: –
Traffic Shaping is the feature to control the quantity of traffic that is allowed to flow across a link. That is, rather than letting the traffic go as fast as it possibly can, you can set limits to how much traffic can be sent.
You can configure a traffic shaping policy for each port group in Standard or Distributed Switch.
Traffic Shaping is defined by:
Average bandwidth (100000 Kbits/Sec)
- Establishes the number of bits per second to allow across a port, averaged over time.
- This number is the allowed average load.
- By default, traffic will get bandwidth what is defined in Average bandwidth.
Peak bandwidth (100000 Kbits/Sec)
- Maximum number of bits per second to allow across a port when it is sending or receiving a burst of traffic.
- This number limits the bandwidth that a port uses when it is using its burst bonus.
- Average bandwidth can be exceed when needed by specifying a higher “Peak Bandwidth” value.
Burst size(102400 Kbytes)
- Maximum number of bytes to allow in a burst that is allowed to be transmitted at the peak bandwidth rate in kilobytes.
- When the port needs more bandwidth than specified by the average bandwidth, it might be allowed to temporarily transmit data at a higher speed if a burst bonus is available. So, when you need to send more traffic than the average bandwidth value allows, you transmit a burst of traffic, which is more than the allowed average bandwidth.
- Traffic will be allowed to burst until the value of “Burst Size” has been exceeded.
Teaming & Failover: –
Load Balancing Policy:
Route based on the originating virtual port ID
- Each virtual machine has a virtual port ID on vSwitch. Port ID of a virtual machine is fixed while the virtual machine runs on the same host. If you migrate, power off, or delete the VM, its port ID on the virtual switch becomes free and port ID get change in next power on.
- The vSwitch selects uplinks based on the virtual machine port IDs.
- This load balancing method is used by default on Standard and Distributed Switches.
Route based on IP hash
- Load balancing is based on the source/destination IP addresses.
- vSwitch selects uplinks for virtual machines based on the source and destination IP address of each packet.
- In IP Hash load balancing policy all physical switch ports connected to the active uplinks must be in EtherChannel mod.
- This load balancing should be set for all port groups using the same set of uplinks.
- Physical adapters attached on vSwitch must be in Active/Active.
- Beacon probing is not supported with IP Hash.
Route based on source MAC hash
- Load balancing is based on Virtual machine’s MAC Address.
- To calculate an uplink for a virtual machine, the virtual switch uses the virtual machine MAC address and the number of uplinks in the NIC team.
Use explicit failover order
- It is based on Route Based on Originating Virtual Port. Virtual switch checks the load of the uplinks and takes steps to reduce it on overloaded uplinks.
Network Failure Detection Policy:
Link Status only
- It is basically use to check the link if physical NIC is Up or down.
- 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 is about checking of the health and connectivity between each vmnic (physical NIC) in the same vSwitch.
- This option detects many of the failures in depth that are not detected by link status alone.
- ESXi will send a small packet out of it’s physical network card, and see if this packet is received by the other physical network card within the same vSwitch. If the vmnic receive the packet, it means that the connectivity between these two physical network is healthy.
- You must have 3 Physical Network Port in the same vSwitch before you turn on Beacon Probing. The reason is because if you have 2 Physical Network Port in the same vSwitch, and Beacon packet cannot reach each other, switch cannot determine which NIC needs to be taken out of service.
- Do not use IP hash for load balancing.
Notify Switches Policy: (Yes/No)
- By setting up Notify switches policy to “Yes”, you can determine how the ESXi host communicates failover events.
- It is also used for updating MAC address information on physical switches.
Failback Policy: (Yes/No)
- It uses when a failed physical NIC returns online, the vSwitch sets the NIC back to active by replacing the standby NIC.
- By Default it is set to Yes.
Failover Order Policy:
It specifies how to distribute the work load for adapters.
- vSwitchContinue to use the adapter when the network adapter connectivity is available and active.
- vSwitch uses this adapter if one of the active adapter’s connectivity is unavailable.
- When a physical adapter is added to this section, vSwitch do not use this adapter.
What is MTU (Maximum Transmission Unit)?
- A MTU (maximum transmission unit) is the largest size packet or frame, specified in octets (eight-bit bytes), that can be sent in a packet- or frame-based network such as the Internet.
- Default size of MTU is 1500 Bytes which can be increased up to 9000 Bytes.
- Jumbo Frames can be enabled on a vSwitch, vDS, and VMkernel Adapter.
That’s all from this topic. As vSphere Networking is a complex and interesting topic, so I am planning to write a separate blog with detailed information on each points mentioned above. Stay tuned for coming blogs.
Thanks for visiting here. Share this article if you found it useful. Be sociable.
Understand Virtual Networking
VMware vSphere uses Virtual Networking to establish connection between Hypervisor and Virtual Machines. Hypervisor is connected to Physical Network through physical NICs and switches, whereas Virtual machine is connected through ESXi using Virtual Networking.
There is a thin layer of Virtual Networking over the VMkernel which provides entire communication for Virtual Machines with Physical Network.
We create Virtual Networking for Virtual Machine using logical layer which is known as Virtual Switch.
Points to Cover:
- Understand Virtual Networking
- Understand vSphere Standard Switch
- Standard Switch Architecture
- Components of vSphere Standard Switch
- How To – Create vSphere Standard Switch (VSS)
There are two types of Virtual Switch:
- vSphere Standard Switch
- vSphere Distributed Switch
In module of vSphere 6.7, Install, Configure, and Manage, we will more focus on Standard Switch. Let’s explore the vSphere Standard Switch.
Standard switch does the same work in software defined datacenter as physical switch does in physical datacenter.
Understand vSphere Standard Switch
You have one ESXi host which is connected to Physical switch using NICs and cable. On top of ESXi, you have Virtual machines over the kernel. Now you need to connect these Virtual Machines with Physical Network.
Now here you need a switch which can communicate to physical network via hypervisor(ESXi). This switch will be a vSphere Standard Switch which connects physical switch using physical adaptor on ESXi.
It provides different VLANs to work for Virtual Machines using Port Group. It also provides management, vMotion, and other functionality for your vSphere environment.
You always create a vSphere Standard switch on each ESXi Host.
Virtual Switch provides inter connection for VMs to communicate with each other using the same protocols that would be used over physical networking.
Components of vSphere Standard Switch
- Port Groups
- VM Port Group
- VMKernel Port Group
- NIC Teaming
- Physical Adaptor
How To – Create vSphere Standard Switch (VSS)
- Login to vCenter Server.
- Click on ESXi Host on which you want to create Standard Switch.
- Go to Action button and Click on Add Networking.
- Click on Virtual Machine Port Group for a Standard Switch. You can also choose first option which is VMkernel Network Adapter.
- VM Port Group – VM Port Group are used to connect Virtual Machine Networking.
- VMkernel Port Group – VMkernel ports are used to connect the VMkernel to services such as vMotion, Management, iSCSI, NFS, FT, VSAN. VM kernel port required an IP Address.
- Click on Next.
- Click on New Standard Switch.
- Review the information and Click on OK.
Add physical network adapters to the new standard switch. You must have to assign atleast one Physical NIC for a vSwitch.
Give name of Port group which will be created inside Standard Switch. Here in our lab, we created a Port Group called Prod_VM which will be for Production VMs.
- Review the information and Click on Finish.
- Go to Host and Click on Networking under Configure tab.
- Standard Switch with name of vSwitch1 has been created successfully.
You can also review Port Group(Prod_VM) which was created under vSwitch1. To Check this, go to Networking and Click on Datacenter. It will show all port groups.
Thanks for visiting here. Share this article if you found it useful. Be sociable.