Availability made easy for your vSphere infrastructureVeeam Storage Tips & Tricks

Jan van LeukenSr. System Engineer, BeNeLux

Edwin WeijdemaSolutions Architect, NE EMEA

Hyper-convergence is awesome, butour responsibilities don’t go away!

3 Different copies of data2 Different media1 of which is off-site

Don’t skip the 3-2-1 Rule

Running workloads “count” as one copy.

The other two are where you need to think a bit:

-Backups-Replicas-Tape-Cloud-Storage snapshots

3 Different copies of data

The 3-2-1 Rule can address nearly any failure scenario.

It also doesn’t require any specific technology.

The 3-2-1 Rule Rocks

In v9.5, with per-VM backup chains and scale-out repositories, this will be radically simplified.

Short-term retention

- Fast storage with limited space-Allows Instant VM Recovery™and SureBackup®- “Operational” restores- 30 days, 95% restores

Long-term retention

- Slower, cheaper storage with dedupe support

- Slower restores- Grandfather-father-son

retention (GFS)

The Ultimate Backup Architecture

Designing Storage

http://www.vmguru.com

Q: 10TB data, how long will it take over a 10Gbps link?

A: 10TB = 10 * 1024 (GB) * 1024 (MB) = 10.485.760 MB10.485.760 MB / 900 MB/s = 11.651 secs

11.651 secs / 60 secs = 195 Mins195 mins / 60 mins = 3.25 Hours

BYOS

Bring Your Own Storage

Backup Repositories• Use different credentials for backup storage• Have offline storage as part of the Availability strategy• Take storage snapshots on backup storage if possible• Have visibility into suspicious behavior

• Ultimately design for Failure Domains!

Visibility into Suspicious behavior

vSANIntegration

Integration > Compatibility

vSAN – a practical example

ESXi-01 ESXi-02 ESXi-03 ESXi-04

cache cache cache cache

capacity capacity capacity capacity

DC2

RAID1

vSAN – data location

vSAN – data location

ESXi-01 ESXi-02 ESXi-03 ESXi-04

cache cache cache cache

capacity capacity capacity capacity

DC2

RAID1

DISK DISKWITNESS

«Follow the vSAN!»• Avoid useless network traffic

• A virtual proxy running over a vSAN node can read data directly from the ESXi storage stack, networkless

• Ideal design: one proxy per node (if justified by the number of VM per node)

«Follow the vSAN!»

Step 1: vSAN objects enumerationContainer 'Hierarchy object "dc2". Host: "vcsa.cloudconnect.local". Reference: "vm-42". Type: "VirtualMachine". Name: "VirtualMachine".' depth 1000

[Soap] Logging on to "vcsa.cloudconnect.local", port 443, user "cloudconnect@vsphere.local", proxy srv: port:0, serviceType: public, timeout: 200000 ms

[Vsan] Starting nodes analysis. Computing data amounts direct accessible on different hosts

[Vsan] Computing direct accessible data amounts for disk 'dc2.vmdk'[Soap] QueryVsanObjects, objects uuids '9cab0857-c8f1-4ba9-d6f8-002590c0162a'[VimApi] QueryVsanObjects, Ref: 'ha-vsan-internal-system-20'[Vsan] Disk 'dc2.vmdk' Total:

[Node '569eb942-5112-55e8-edc9-0025909134c8':42953867264],[Node '569fddae-528f-6520-c933-002590c0162a':4194304],[Node '569fe96b-1a31-aa18-ffed-002590c010f8':42953867264]

[Vsan] Finished nodes analysis. Total data amounts for all disks:[Node '569eb942-5112-55e8-edc9-0025909134c8':42953867264],[Node '569fddae-528f-6520-c933-002590c0162a':4194304],[Node '569fe96b-1a31-aa18-ffed-002590c010f8':42953867264]

Step 2: access mode evaluation[ProxyDetector] Detecting storage access level for proxy [px2.cloudconnect.local][ProxyDetector] Found proxy is on suitable ESX: 'vm-747'. All disk can be processed through hotadd[Vsan] Node uuid for proxy vm 'px2' (phys host 'esx2.cloudconnect.local'): '5698370c-8410-0a5b-4b7f-0025909b6a04'[VsanProxyDetector] Proxy 'px2.cloudconnect.local' has direct access to 0 bytes and obtains HotAddDifferentHosts mode

[ProxyDetector] Detecting storage access level for proxy [px4.cloudconnect.local][ProxyDetector] Found proxy is on suitable ESX: 'vm-749'. All disk can be processed through hotadd[Vsan] Node uuid for proxy vm 'px4' (phys host 'esx4.cloudconnect.local'): '569fe96b-1a31-aa18-ffed-002590c010f8'[VsanProxyDetector] Proxy 'px4.cloudconnect.local' has direct access to 42953867264 bytes and obtains HotAddSameHost mode

[ProxyDetector] Detecting storage access level for proxy [px1.cloudconnect.local][ProxyDetector] Found proxy is on suitable ESX: 'vm-746'. All disk can be processed through hotadd[VsanProxyDetector] Proxy 'px1.cloudconnect.local' has direct access to 42953867264 bytes and obtains HotAddSameHost mode

[ProxyDetector] Detecting storage access level for proxy [px3.cloudconnect.local][ProxyDetector] Found proxy is on suitable ESX: 'vm-748'. All disk can be processed through hotadd[VsanProxyDetector] Proxy 'px3.cloudconnect.local' has direct access to 4194304 bytes and obtains HotAddSameHost mode

Step 2: access mode evaluation

ESXi-01 ESXi-02 ESXi-03 ESXi-04

cache cache cache cache

capacity capacity capacity capacity

PX4

Same

DISK DISKWITNESS

PX3

Same*

PX2

Different

PX1

Same

Step 3: best proxy selectionVM [Name: dc2, Ref: vm-42] is running.VM IP addresses: fe80::286f:5e60:f915:104d, 10.10.51.22

- Request: ViDisk_|ViProxyRepositoryPairResourceRequest, ProxyResourceRequest: [ViProxy, source proxies:[Vi proxy resource [id=7cb7a5d0-26f1-4534-8aa1-2a2ac8922188 : srv name=px2.cloudconnect.local : access level=HotAddDifferentHosts : max usage=2 : vddk modes=hotadd;nbd]],[Vi proxy resource [id=6563db50-f5b7-4c0d-bf69-834500a6bb3b : srv name=px4.cloudconnect.local : access level=HotAddSameHost : max usage=2 : vddk modes=hotadd;nbd]],[Vi proxy resource [id=2703c214-a476-4f1a-a7d1-9b6364716ed3 : srv name=px1.cloudconnect.local : access level=HotAddSameHost : max usage=2 : vddk modes=hotadd;nbd]],[Vi proxy resource [id=4a78c7f8-a148-4362-bf3f-ee98323b7c17 : srv name=px3.cloudconnect.local : access level=HotAddSameHost : max usage=2 : vddk modes=hotadd;nbd]] ],

- - Response: Count: 1, details: [Subresponses: [Responces: [Vi proxy resource [id=6563db50-f5b7-4c0d-bf69-834500a6bb3b : srv name=px4.cloudconnect.local : access level=HotAddSameHost : max usage=2 : vddk modes=hotadd;nbd]],[Repository : resource allocated]

- - Request: ViSnapshot, host: esx4.cloudconnect.local, datastores: vsanDatastore- - Request: Prepare Vi VMs, Vm 'dc2' on Host: 'esx4.cloudconnect.local'- - - - Response: VMs allocated for processingSet status 'InProgress' for task session '075169e9-81e3-4428-a56d-6a8c82106f94', object name 'dc2'

Step 3: best proxy selection

ESXi-01 ESXi-02 ESXi-03 ESXi-04

cache cache cache cache

capacity capacity capacity capacity

PX4

Same

DISK DISKWITNESS

PX3

Same*

PX2

Different

PX1

Same

Ensure FULL backup and restore support when it comes to protecting VMs on vSAN. Veeam is vSAN aware:

• Proxy on each host• Queries vSAN data• Moves data from

best node

What about availability?

Acknowledgement

The Storage Policy-Based Management association is critical when it comes to backup and restore.

Otherwise, why use the new frameworks if you can’t ensure their service levels on restore.

Specifically for VVOL and VSAN

SPBM Association on restore

If using next generation storage technologies (VVOLs or vSAN) ensure that Storage Policy-Based Management is supported upon restore. This is NOT what you want to see:

More advanced VMware storage

Free Stuff! All at Veeam.com

https://bp.veeam.expert for the full Veeam best practices

Summary

Edwin Weijdema

Edwin.Weijdema@Veeam.com

@Viperian

www.vmguru.com

Jan van Leuken

Jan.vanLeuken@Veeam.com

@Veeam

www.veeam.com