Difference between revisions of "VMWare"
From MohidWiki
Davidbrito (talk | contribs) (→Restore VM) |
Davidbrito (talk | contribs) (→Restore VM) |
||
| Line 115: | Line 115: | ||
===Restore VM=== | ===Restore VM=== | ||
From Veeam Manual | From Veeam Manual | ||
| + | |||
In case of software or hardware malfunction, you can quickly recover a corrupted VM by failing over to its replica. When you perform failover, a replicated VM takes over the role of the original VM. You can fail over to the latest state of a replica or to any of its good known restore points. | In case of software or hardware malfunction, you can quickly recover a corrupted VM by failing over to its replica. When you perform failover, a replicated VM takes over the role of the original VM. You can fail over to the latest state of a replica or to any of its good known restore points. | ||
In Veeam Backup & Replication, failover is a temporary intermediate step that should be further finalized. Veeam Backup & Replication offers the following options for different disaster recovery scenarios: | In Veeam Backup & Replication, failover is a temporary intermediate step that should be further finalized. Veeam Backup & Replication offers the following options for different disaster recovery scenarios: | ||
| Line 123: | Line 124: | ||
In Veeam Backup & Replication, the actual failover is considered a temporary stage that should be further finalized. That is, after you test the VM replica and make sure the VM runs stable, you should take another step to perform permanent failover. However, while the replica is still in the Failover state, you also have an option to undo failover or perform failback. | In Veeam Backup & Replication, the actual failover is considered a temporary stage that should be further finalized. That is, after you test the VM replica and make sure the VM runs stable, you should take another step to perform permanent failover. However, while the replica is still in the Failover state, you also have an option to undo failover or perform failback. | ||
| − | Tools->Backup->Restore From Replica (Failover to Replica) | + | Go to Veeam Backup & Replication in VM-BackupServer and: |
| + | Tools->Backup->Restore From Replica (Failover to Replica) | ||
'''Permanent Failover''' | '''Permanent Failover''' | ||
To confirm failover and finalize recovery of a VM replica on the target host, you need to perform permanent failover. As a result of permanent failover, the VM replica ceases to exist as a replica and takes on the role of the original VM. | To confirm failover and finalize recovery of a VM replica on the target host, you need to perform permanent failover. As a result of permanent failover, the VM replica ceases to exist as a replica and takes on the role of the original VM. | ||
| − | + | The Permanent failover process should be avoid because it changes the original vm place and needs a further copy to the original host. The original host should be recovered and return operation to it (failback). | |
'''Undo Failover''' | '''Undo Failover''' | ||
| Line 138: | Line 140: | ||
Veeam Backup & Replication streamlines and automates disaster recovery by providing replica failback capabilities. Failback is the process of switching from the VM replica to the production VM. During failback, Veeam Backup & Replication uses the working replica to recover the original VM and switch back to it. | Veeam Backup & Replication streamlines and automates disaster recovery by providing replica failback capabilities. Failback is the process of switching from the VM replica to the production VM. During failback, Veeam Backup & Replication uses the working replica to recover the original VM and switch back to it. | ||
| − | Tools->Backup->Restore From Replica (Failback) | + | Go to Veeam Backup & Replication in VM-BackupServer and: |
| + | Tools->Backup->Restore From Replica (Failback) | ||
If you managed to restore operation of the source host, you can switch back to the original VM on the source host. However, if the source host is not available, you can restore the original VM to a new location and switch back to it. Veeam Backup & Replication offers three failback options: | If you managed to restore operation of the source host, you can switch back to the original VM on the source host. However, if the source host is not available, you can restore the original VM to a new location and switch back to it. Veeam Backup & Replication offers three failback options: | ||
| Line 146: | Line 149: | ||
The first two options help you decrease recovery time and use of the network traffic, as Veeam Backup & Replication will transfer only differences between the two VMs. The third option is used in cases when there is no way to use the original VM or restore the VM before performing failback. | The first two options help you decrease recovery time and use of the network traffic, as Veeam Backup & Replication will transfer only differences between the two VMs. The third option is used in cases when there is no way to use the original VM or restore the VM before performing failback. | ||
| − | The normal process should be the first, recovering it to the same host since the Maretec infrastructure is prepared to have to ESXi hosts. However in the future if current Xen server is converted to ESXi server than the rwo latter options may be considered. | + | The normal process should be the first, recovering it to the same host since the Maretec infrastructure is prepared to have to ESXi hosts (production site and Disaster and Recovery site). However in the future if current Xen server is converted to ESXi server than the rwo latter options may be considered. |
In Veeam Backup & Replication, failback is considered a temporary stage that should be further finalized. That is, after you test the recovered original VM and make sure it is running correctly, you should take another step to commit failback. However, while the replica is still in the failback state, you also have an option to undo failback and return the replica back to the failover state. | In Veeam Backup & Replication, failback is considered a temporary stage that should be further finalized. That is, after you test the recovered original VM and make sure it is running correctly, you should take another step to commit failback. However, while the replica is still in the failback state, you also have an option to undo failback and return the replica back to the failover state. | ||
Revision as of 14:06, 27 March 2012
VMWare was the second step of virtualization infraestructure in Maretec (after Xen).
Physical Machines
Installation Phase
Migrating Existing VM in Xen
Existing VM in Xen server were duplicated in VMWare environment in RAID machine (the future backup machine). Before installation in definite place (CISCO server, ESXi1) the original ones should be replaced by the news to ensure the system works.
Creating a new FTPServer
A VM was added to vShere and installed Windows Server 2008 and configured as the existing Xen FTPServer. See Creating a FTPServer in VMWare for details.
Creating a new WebServer
A VM was added to vShere and installed Windows Server 2008 R2 and configured (Web sites that were inside FTPServer). See Creating a WebServer in VMWare for details.
Creating a new OpenDAPServer
A VM was added to vShere and installed Fedora and configured as the existing Xen OpenDAPServer.
See Creating an OpenDAPServer in VMWare for the first attempt with LVM defaults from Fedora. After PVextend machine crashed.
See Creating an OpenDAPServer in VMWare2 for the second attempt with user defined LVM and till now the best creation.
Creating a new VM Domain Controller
A VM DC, VM-DC2, was added to CISCO server, ESXi1, and installed Windows Server 2008 R2. See Creating a Domain Controller in VMWare for details.
Creating a new Physical Domain Controller
A physical DC, DC1, was installed with Windows Server 2008 R2. It was similar install as the VM-DC2 but drivers for LAN, sound, video, etc had to be installed.
Creating a VM Backup Server
Creating a BackupServer in VMWare
Production Phase
Changing the bridging between the LAN and the DMZ
Opendap
eth0 - LAN
eth1 - DMZ
The steps are for changing from DMZ to LAN and (from LAN to DMZ)
- Need to add in vSphere the new interface to the VM (by default the DMZ machines should not have the two interfaces on because that would create a security issue since anyone that had control to the machines could connect the LAN and access it) - see the steps in the creation of the machines.
- Enter the VM through console access as user
- Just use network icon in rigt up corner, disconnect eth1(eth0) and connect eth0(eth1)
- It is done if change is temporary! Do not forget to remove the LAN adapter in vSphere after not needed because it creates a security issue.
- However if connection is to maintain after reboots it is better to take eth0(eth1) down definitely in network restart
Other--> Network Connections Select to not connect eth1(eth0) automatically but connect automatically eth0(eth1) 'or eth1(eth0) it would give fail in network restart after taking it down below) Save. > ifconfig ethx down 'x is 1 in case of wanting to go LAN at restart, is 0 otherwise > service network status > su > service network restart > ifconfig
- Do not forget to remove the LAN adapter in vSphere after not needed because it creates a security issue.
FTPServer
- Need to add in vSphere the new interface to the VM (by default the DMZ machines should not have the two interfaces on because that would create a security issue since anyone that had control to the machines could connect the LAN and access it) - see the steps in the creation of the machines.
- Enter the VM in console and just go to connections and disable one and enable the other.
- Do not forget to remove the LAN adapter in vSphere after not needed because it creates a security issue.
Increase /opendap size
First, do a snapshot, backup the files.
- Add a virtual disk to the VM vSphere Client from the same physical disk(default)or select other datastore.
IMPORTANT: do not add size to the existing virtual disk or the space will not be usable. Add one new disk.
- Check the name of the new disk in the VMMachine Disk Utility (Accesories). It was /dev/sdb
- Create a new partition of appropriate size using fdisk
>fdisk /dev/sdb >n (create new partition, select start and end cylinders (default), all free space is selected by default) >w (save partition table and exit) >fdisk -l (check the new partition, /dev/sdb1 was created ~10G in size)
- Create an ext3 filesystem in the partition (this step is optional, just a quick test that all is well)
>mkfs.ext4 /dev/sdb1
- Initialise the partition for use as a physical volume in lvm and add it to vg_opendap2
>pvcreate /dev/sdb1 >vgextend vg_opendap2 /dev/sdb1
- Extend LogVol00 (use 'df /' to check that / is mounted on LogVol00) as required (by 10G here)
>lvextend -L +10G /dev/vg_opendap2/lv_opendap
- If you receive errors about not enough physical extents, then reduce the size of the extension a little until it fits.
- Finally, resize the filesystem (this part normally would require unmounting /, but for ext4 it works while the partition is mounted)
>resize2fs /dev/vg_opendap2/opendap
- Type 'df -h /', to check it worked, there should be an extra 10G available
(you can use vgdisplay, pvdisplay and lvdisplay (as root) to see detailed info, pvscan for a summary)
Backup VM
The backup strategy was implemented in the VM VM-BackupServer created in the ESXi backup server (192.168.20.81)
- One Replication for each VM from 192.168.20.80 to 192.168.20.81 (FTPServer and WebServer in disk 1 and OpenDAPServer, DC2 in disk 2 (4 restore points done weekly (saturday morning)).
- One reverse incremental backup of all initial VM to Davinci 192.168.20.45 and then one backup of all machines (above + BackupServer) (2 restore points done monthly (last sunday in the morning)).
Restore VM
From Veeam Manual
In case of software or hardware malfunction, you can quickly recover a corrupted VM by failing over to its replica. When you perform failover, a replicated VM takes over the role of the original VM. You can fail over to the latest state of a replica or to any of its good known restore points. In Veeam Backup & Replication, failover is a temporary intermediate step that should be further finalized. Veeam Backup & Replication offers the following options for different disaster recovery scenarios: • You can perform permanent failover to leave the workload on the target host and let the replica VM act as the original VM. Permanent failover is suitable if the source and target hosts are nearly equal in terms of resources and are located on the same HA-site. • You can perform failback to recover the original VM on the source host or in a new location. Failback is used in case you failed over to a DR site that is not intended for continuous operations, and would like to move the operations back to the production site when the consequences of a disaster are eliminated.
Failover
In Veeam Backup & Replication, the actual failover is considered a temporary stage that should be further finalized. That is, after you test the VM replica and make sure the VM runs stable, you should take another step to perform permanent failover. However, while the replica is still in the Failover state, you also have an option to undo failover or perform failback.
Go to Veeam Backup & Replication in VM-BackupServer and: Tools->Backup->Restore From Replica (Failover to Replica)
Permanent Failover To confirm failover and finalize recovery of a VM replica on the target host, you need to perform permanent failover. As a result of permanent failover, the VM replica ceases to exist as a replica and takes on the role of the original VM.
The Permanent failover process should be avoid because it changes the original vm place and needs a further copy to the original host. The original host should be recovered and return operation to it (failback).
Undo Failover To switch back to the original VM, revert replication operations and discard changes made to the working VM replica, you can undo failover.
During failover, the state of the original VM on the source host is not affected in any way. Basically, if you need to test the replica and its restore points for recoverability, you can perform actual failover as a background process while the original VM is running. After all necessary tests, you can undo failover and go back to the normal mode of operation.
Failback
Veeam Backup & Replication streamlines and automates disaster recovery by providing replica failback capabilities. Failback is the process of switching from the VM replica to the production VM. During failback, Veeam Backup & Replication uses the working replica to recover the original VM and switch back to it.
Go to Veeam Backup & Replication in VM-BackupServer and: Tools->Backup->Restore From Replica (Failback)
If you managed to restore operation of the source host, you can switch back to the original VM on the source host. However, if the source host is not available, you can restore the original VM to a new location and switch back to it. Veeam Backup & Replication offers three failback options: • Fail back to a VM in the original location on the source host • Fail back to a VM that has been restored up-front from a backup in a new location • Fail back to an entirely new location by transferring all replica files to the selected destination The first two options help you decrease recovery time and use of the network traffic, as Veeam Backup & Replication will transfer only differences between the two VMs. The third option is used in cases when there is no way to use the original VM or restore the VM before performing failback.
The normal process should be the first, recovering it to the same host since the Maretec infrastructure is prepared to have to ESXi hosts (production site and Disaster and Recovery site). However in the future if current Xen server is converted to ESXi server than the rwo latter options may be considered.
In Veeam Backup & Replication, failback is considered a temporary stage that should be further finalized. That is, after you test the recovered original VM and make sure it is running correctly, you should take another step to commit failback. However, while the replica is still in the failback state, you also have an option to undo failback and return the replica back to the failover state.
Commit Failback To confirm failback and finalize recovery of the original VM, you need to commit failback. As a result of failback commit, Veeam Backup & Replication removes the protective snapshots and unlocks replica disk files. The state of the replica is changed from Failback to Normal.
Undo Failback If the VM to which you failed back from a replica is non-operational or corrupted, you can undo failback and switch the replica back to the failover state.
VM Copy
With Veeam Backup & Replication, you can run a VM copy job to create an independent fully-functioning copy of a virtual machine on a selected storage.
