In this post we will know how the Veeam Availability Suite™ enables NetApp HCI virtual
machines. The following is the diagram of lab environment includes of vCenter Server, Veeam Backup Server and NetApp HCI.
First we login into vCenter Server, we can see the NetApp SolidFire Configuration and NetApp SolidFire Management are enabled on vCenter homepage.
Go to NetApp SolidFire Management and choose Datastore on Management tab, we can see the SolidFire datastore. In this demo, we will backup one MSSQL virtual machine with Veeam Availability Suite, this VM is running on this datastore.
Now we login into Veeam Backup & Replication Console.
Click on the Backup Infrastructure, we can see two components include of the vCenter server and Veeam backup server.
Now we can create a new backup job to protect this MSSQL virtual machine.
When the backcup job is completed, we can see the backup copy of MMSQL virtual machine that store on the backup disk volume.
In this simple demo we can see Veeam Availability Suite easy to protect the NetApp HCI virtual machines. We also choose three recovery options for virtual machine, “Instant VM Recovery”, “Explorer Reocovery” and “Full VM Recovery”.
“Fault domain” is a term that comes up often in availability discussions. In IT, a fault
domain usually refers to a group of servers, storage, and/or networking components
that would be impacted collectively by an outage. A common example of this is a server
rack. If a top-of-rack switch or the power distribution unit for a server rack would fail, it
would take all the servers in that rack offline even though the server hardware is
functioning properly. That server rack is considered a fault domain.
Each host in a vSAN cluster is an implicit fault domain. vSAN automatically distributes
components of a vSAN object across fault domains in a cluster based on the Number of
Failures to Tolerate rule in the assigned storage policy.
When determining how many hosts or Fault Domains a cluster is comprised of, it is important to remember the following:
• For vSAN objects that will be protected with Mirroring, there must be 2n+1 hosts or Fault Domains for the level of protection chosen.
- Protecting from 1 Failure would require (2×1+1) or 3 hosts.
- Protecting from 2 Failures would require (2×2+1) or 5 hosts.
- Protecting from 3 Failures would require (2×3+1) or 7 hosts.
• For vSAN objects that will be protected with Erasure Coding, there must be 2n+2 hosts or Fault Domains for the level of protection chosen.
- RAID5 (3+1) requires (2×1+2) or 4 hosts.
- RAID6 (4+2) requires (2×2+2) or 6 hosts.
Also consider that the loss of a Fault Domain, or hosts when Fault Domains are not configured, could result in no location to immediately rebuild to. VMware recommends having an additional host or Fault Domain to provide for the ability to rebuild in the event of a failure.
Also consider that the loss of a Fault Domain, or hosts when Fault Domains are not
configured, could result in no location to immediately rebuild to. VMware recommends
having an additional host or Fault Domain to provide for the ability to rebuild in the
event of a failure.
To mitigate this risk, we can place the servers in a vSAN cluster across server racks and
configure a fault domain for each rack in the vCenter\vSAN UI. This instructs vSAN to
distribute components across server racks to eliminate the risk of a rack failure taking
multiple objects offline. This feature is commonly referred to as “Rack Awareness”. The
screenshot shows component placement when three servers in each rack are configured
as separate vSAN fault domains.
Create Fault Domains
In Dell EMC Unity (OE 4.4), synchronous file replication can provide a zero RPO solution for file resources. The data is mirrored from a source Unity system to remote Unity system over short distances (recommended < 5ms RTT latency). Synchronous file replication supports NAS Servers, file systems and VMware NFS Datastores. The replication connection between two systems can be selected three modes:
Asynchronous – Enable Asynchronous block and file replication.
Synchronous – Enable Synchronous block and file replication.
Both – Enable both Asynchronous and Synchronous replication.
The architecture of file replication:
You can see the NAS on source Unity system at Site A that are replicated to the remote Unity system at Site B.
Replication Operation Options:
Planned Failover (From Source Unity system)
Bring up the remote resources as source and change the direction of replication to original source.
Unplanned Failover (From Destintation Unity system)
Bring up the remote resources as source and break the replication sync session.
After Planned Failover – Bring up the remote resources as source and change the direction of replication to original source.
After Unplanned Failover – Run full sync to original source then failover resources and replicate to original destination.
Pause the existing replication session and stop syncing writes to destination.
After a Pause – Resume replication session to re-sync outstanding writes and continue replication operation.
After Unplanned Failover – Run full sync to original source and restart sync operations from new source.
Delete existing replication session.
Dell EMC Unity – MetroSync (Part 1)
This video will go over the synchronous file replication and snapshot replication as part of the overall MetroSync solution on Dell EMC Unity systems.
Dell EMC Unity – MetroSync (Part 2)
This video will go over snapshot schedule replication, cabinet level failover, and asynchronous replication to a 3rd site as part of the overall MetroSync solution on Dell EMC Unity systems.
Dell EMC Unity OE version 4.4 includes SAN Copy Pull as a part of the code. SAN Copy Pull is a migration tool which migrates data from block storage resources, either standalone LUNs/Volumes or VMFS Datastores, found on supported systems to Dell EMC Unity. A SAN Copy Pull migration session can be configured over Fibre Channel (FC) or iSCSI to migrate the data. All I/Os must be suspended on the source storage resources and host access should be removed during the migraion.
Migrations utilizing Dell EMC Unity SAN Copy Pull to migrate from a source system to the target Dell EMC Unity system. SAN Copy Pull sessions is only available through UEMCLI or REST API.
Systems supported by Dell EMC Unity SAN Copy Pull:
- Dell EMC SC / Compellent
- Dell EMC PS / EqualLogic
- Dell EMC UnityVSA with iSCSI only
- Dell EMC VMAX
- HP EVA
- HPE 3PAR
- Hitachi HDS
The following are the high level migration process,
- Set up the data path connection between the source and target storage systems.
- Create a LUN on the destination system and note the CLI ID of the storage resouce.
- Remove host access to the resources on the source storage system and add Unity as a host on the source storage system.
- Data is read from source and written to the target LUN.
- Give a host access to Unity storage system.
Dell EMC Unity: Migration Technologies – White paper
This video will go over the SAN Copy Pull feature which allows for migration of block data to Dell EMC Unity systems.
I am great to finish my final goal in 5 years, published the three technical books which are related to different vendors, eg Dell EMC, Cisco and VMware.
2018 – Storage Migration – Hybrid Array to All-Flash Array
2016 – Cisco UCS Cookbook
2015 – Mastering VMware vSphere Storage
What’s new of vSphere 6.7 Update 1Fully Featured HTML5-based vSphere Client
- vCenter High Availability
- Top-N charts
- vSphere Update Manager (VUM)
- Key Management Servers
- System Configuration
- Complete remaining advanced workflows for below:
- vCenter Server Extensions