A very proud moment for me, was when I was asked by Nimble Storage to present along side Sheldon D’Palva from Product and Solutions Marketing, Nimble Storage at the inaugural VeeamOn conference in Las Vegas.
When I was first asked to come up with something to talk about in support of Nimble and Veeam in this session, I was unsure of what topic to discuss. We have already heard about the many features that are available such as Veeam Agentless backups, Native Explorer for AD & now SQL, and how Nimble’s CASL optimises the Reads and Writes through the layers of RAM, SSD finally on to Disk.
I felt that it was especially difficult knowing what to say, as I have no idea on who would be in the audience. In the end, I decided that the best use of the time would be to concentrate on one particular aspect of the Nimble and Veeam partnership, one which shows how these products uniquely complement each other.
My company first started using Veeam around 2010, but in conjunction with Backup exec to handle our Physical estate. After a year or so we fully virtualised our Server estate some. As I said earlier, with a small IT team it is important that any product we purchase, especially something as important as Backup; needs to be Simple to Use, Provide Lots of Features and is Cost Effective to the Business.
We quickly became comfortable with Veeam and used many of it’s features to provide a strong Backup Solution to our business.
Our installation consists of a Veeam Backup Server, a number of Proxy Servers and a Fine Tuned Nimble Volumes to actually place the various Veeam Repositories on.
Veeam Proxy Anatomy
To explain this further, I would like to give you an insight into how I support the various requirements of a Veeam Proxy Appliance using the Nimble Volume Policies. The Appliance is deployed as a Windows Service and provides an optimal route for Backup and Replication traffic between locations. It can exist on a physical or virtual machine – but in my case I have opted for virtual. These Proxies utilise the Hot-Add feature of VMware, to access the virtual disks on the storage.
In practice, our Veeam Proxy servers are installed as virtual machines, one in each Data Centre. They are configured with a number of VMDK disks, each mapped to a customised datastore. Using this design, I am able to leverage the flexibility of the Nimble Volume Profile.
As I said, the Boot disk is a traditional VMDK, the Volume profile for this will be inherited from the Volume which holds the Proxy Virtual Machine.
The second partition is used for WAN Acceleration, this is a Software layer that Veeam have created which reduces the amount of traffic which is passed across WAN links. The technology involved is specific for the Veeam Backup Jobs and uses a Global Dedupe Cache. This Cache is stored locally with each Proxy at each end of the WAN link and used to ‘reduce’ the transmission of any duplicate data to the other site. As such, the Volume profile used for this disk is NOT Compressed but IS Cached – further adding to the processing speed. We use this to good effect to replicate the majority of our VM’s to the opposite Data Centre, thereby protecting our assets from physical damage.
My 3rd iSCSi disk is the actual Veeam Backup Target. This Volume is defined as Compressed but NOT Cached. To avoid flooding the SSD Cache with ‘backup data’. This gives me the combined benefit of Veeam Backup De-dupe and Nimble Storage Compression.
Finally in order to leverage the performance of the Nimble, I have chosen to create a fourth volume for my vPower/SandBox environment. My intention has been to create an environment which is capable of supporting a number of Virtual Machines at production speed – on which I can perform various patch upgrades, before committing these to the live environment.
These four volumes in my eco-system are independently managed by the Nimble Array.