Now before I start, I have already been blogging about settings up Veeam Cloud Connect in Auzre https://msandbu.wordpress.com/2014/11/12/veeam-cloud-connect-for-microsoft-azure-walkthrough/
And its important to remember the Veeam Cloud Connect is only available for Veeam Service Providers (or VCP Veeam Cloud Providers)
This is more of a technical overview of the solution.
On-premise Veeam customers which have version 8 (should also have patch 1 installed) Can add a service provider from their console, this can be a IaaS solution running in Azure.
End customers are given a usage quota on the cloud repositories. This shows how much data they can store on their cloud repostitory.
So how to setup this in Azure ?
- Use either the template from Veeam which is in the Azure Marketplace (NOTE: This requires a paid subscribtion in order to be activated)
- Download the BITS and install it ourselves.
Now when setting this up in Azure there are a few things to take notice of.
Firstly always check of where the closest datacenter to the customers are, you can use this third-party website as a reference –> http://www.azurespeed.com/
The first two virtual machines are used as a cloud gateway proxy. They will handle the incoming data but not store the data. Important things to take note of here is the bandwidth requirements depending on how many customers, since they operate as a proxy I would try to keep them as cheap as possible. So if we look at the A-instance virtual machines
A2 gives us 200 Mbps bandwidth and should be adequate for Gateway proxy performance. On a side note here, A instances do not have SSD drives, so if we want to setup customers using WAN acceleration we should use the D-series (Which has SSD enabled drivers on the D: partition) Which gives it a good boost on doing the digest work of comparing blocks. (Ref blogpost IOPS performance in Azure –> https://msandbu.wordpress.com/2013/07/16/azure-and-iops-performance/)
There are also some other limits that need to be taken in account. First of when planning for repositories. Data disks in Azure only support up to 1 TB pr disk, meaning that if you need to store data over 1 TB you need to setup Storage spaces running across many drives (Note that storage spaces and geo-replication are not supported)
Also there is a cap for 500 IOPS or data disk, this can be increased a bit by using storage spaces as well. For a regular A4 instance (there as maximum of 16 data disks) look at this reference sheet https://msdn.microsoft.com/en-us/library/azure/dn197896.aspx there is higher amounts of IOPS for D and G-series. Also allows for higher amounts of stored data.
Then you might think (well thats not much data? a maximum amount of 32 TB) important to note that this is not a replacement for on-premise backup. And that moving 32 TB of data from Azure during an outage back on-premice might restrict itself because of the internet bandwidth available at the customer. Just for info, moving 1000 GB over 100 MBps link requires 23 hours… (If your customers require more data and better bandwidth and lower latency, well Azure is not the right solution 
Lastly its important to setup load balancing for our cloud gateways. Now the cloud gateways already have built-in load balancing, and will redirect internally based upon traffic. What we need is to load balance the initial request to the Cloud Gateway, since after the first connection, Veeam will keep a list of the availabe cloud gateways.
Now there are two ways to do this using Azure. Either we can use regular DNS based round robin, this means that we have multiple A-records for the same FQDN. When Veeam connects it is able to download all the A-records and try them one after one. Problem with DNS round is that it has no option to check health, and therefore it might take more time.
We can also use Traffic Manager (Which is Azure Load balancing) which has the ability to do health probes to check if they are alive or not. The negativ of this is that when a DNS request is make to our Traffic Manager DNS alias it will only respond with one IP-address & FQDN.
Setting up traffic manager in Azure is a pretty simple case, you just setup it up, give it a URL (Which then needs to be attached using CNAME to a FQDN of your choice on your domain.
And note that this requires that we have multiple cloud services (Which again have their own public IP address)
Now the monitoring part here is a bit tricky, since it by default uses HTTP GET commands to verify the existence of a server. Either using HTTP or HTTPS, which require installation of IIS and then setup ACL’s on the endpoints to only respond from Microsoft Traffic manager.
The instances running as a cloud gateway need to be put in a availabilty group in order to get SLA from Microsoft. When in a availability group, Microsoft knows they can take one of the roles down in the group when they have maintance, and allowing for the other one to keep running.
The repositories can be customer specific (depending on the size) but should not be placed in a availability group (since there are no options for shared storage in the backend to keep it redundant) if a virtual machine is not placed in a availability group the azure administrator will get a notice 2 weeks before hand, and in most cases it will just cause the virtual machine to reboot once and it will be up and running again.