Tag Archives: Azure

Veeam Availability Console now available from Azure Marketplace

Posted on by

Last week the Veeam Availability Console Azure Marketplace appliance went live. This allows Veeam Cloud and Service Providers to easily deploy VAC into any Azure region. In it’s previous incarnation the Managed Backup Portal was only available as an Azure marketplace appliance and not available to install by a VCSP. Now that VAC 2.0 is out, VCSPs who don’t have the ability to host Cloud Connect or VAC on their infrastructure can deploy it in Azure and have the service up and running within fifteen minutes.

There are some limitations that come along with deploying VAC into Azure and it won’t be for everyone. The biggest caveat is that you can only have one Cloud Connect Server per VAC instance and as part of the deployment, Cloud Connect services is installed on the same Virtual Machine. You can’t offer Replication services from the Azure instance, and if offering Cloud Connect backup you need to understand it’s own scalability and performance bottlenecks. That said, as a remote management, monitoring, reporting, billing and self service platform there is a lot to like about having VAC in Azure.

Marketplace Deployment Steps:

You can start the deployment by searching for Veeam Availability Console in the Azure Marketplace or you can go direct to the product page here.

Click on Create to start the configuration steps.

The Basics includes VM name, hard disks type, username and password as well as selecting the subscription, the ability to use a new or existing resource group and finally the Azure location you want to deploy into.

In Step 2 you need to choose the Size of the Azure instance. The template provides the recommended configurations. The sizes are relative to the amount of agents and/or Backup & Replication instances you are going to be managing from this instance. You can find sizing guides here for larger environments.

I ended up going with an A2 standard for my instance which removes the load balancing functionality from the configuration and offers a little less IOPS.
Step 3 contains some optional extra’s to ensure a higher level of availability for the VM instance and lets you configure the networking.
Once that’s done you can review your configuration settings and start the deployment. It took just over 8 minutes for the deployment to succeed.

If you click on the Virtual Machine object in the Azure Portal you will see an overview of the VM and it’s configuration.

Addition Azure Configuration:

If you notice in the image above, a DNS name is listed in the overview. This was something that I had to set manually after the deployment. You set this by going into the Networking of the resource pool and click on IP Configuration. Here, you can enter in a DNS name relative to the Azure zone you are in. You can then use this to connect to the VAC Console, Cloud Connect Service and to RDP to the VM and helps in the event of having a dynamic, rather than a static Azure IP.

Speaking of networking and ports, below is a list of the default port rules created during the deployment. Note that WinRM is open as well.

Finalizing Deployment:

After deploying the Azure Marketplace appliance you can RDP into the VM and complete the setup that includes configuring Cloud Connect and VAC it’s self. A few things have been done for us as part of the deployment, however the first thing you need to do is get a license. This is a BYO license situation, so once you have deployed the Marketplace appliance you will need to source a VAC license from the Veeam Licensing Portal and apply.

Head to the VAC Web Portal and Install the License.

Once done the last step is to configure Cloud Connect from the Backup & Replication Console. Again, you will need a valid Cloud Connect license as you are greeted with the Free Edition when you connect to the console for the first time. As per normal with Cloud Connect, you need to configure the SSL Certificate first and then configure a new Cloud Gateway. Configure the Networking as shown below using the DNS name that was created in the steps above.

Once this is completed you can go into the VAC Console and work through the normal Configuration steps. The only thing you don’t need to do is add the Cloud Connect Server to the VAC instance as this has already been done during the initial deployment process.

It’s worth noting that the versions of Backup & Replication (9.5.0.1536) and Availability Console (2.0.1.1343) are up to date and include the latest Hot-Fixes for VAC. The intent is to have the templates as up to date as possible, however once deployed you can upgrade as per usual.

Conclusion:

So there you have it…within fifteen minutes you can have a fully working Veeam Availability Console instance running in Azure and ready to be used to offer all the goodness that VAC offers our Cloud and Service Provider partners. For an overview as to what VAC offers, click here and have a read of my GA post on What’s in It for Service Providers.

Links:

https://azuremarketplace.microsoft.com/en-us/marketplace/apps/veeam.veeam-availability-console?tab=Overview

 

Veeam Vault #9: Backup for Office 365 1.5 GA, Azure Stack and Vanguard Roundup

Posted on by

Welcome to another Veeam Vault! This is the ninth edition and given the last edition was focused around VMware and VMworld I thought just for a change, the focus for this edition will be Microsoft. Reason for that is over the past couple of weeks we have had some significant announcements around Azure Stack and the GA release of Backup for Office 365 1.5. I’ll cover both of those announcements, share some Veeam employee automation work that shows off the power of our new APIs and see what the Veeam Vanguard’s have been blogging about in the last month or so.

Backup for Office 365 1.5 GA:

The early part of my career was dedicated to Exchange Server however I drifted away from that as I made the switch to server virtualization and cloud computing. The old Exchange admin in my is still there however and it’s for that reason that I’m excited about the GA of our Backup for Office 365 product which is now at version 1.5. This release caters specifically for service providers adding scalability and automation enhancements as well as extended support for on-premises and hybrid Exchange setups.

New features and enhancements:

  • Distributed, scalable architecture: Enhanced scalability in distributed environments with several Remote Offices/Branch Offices and in service providers infrastructures
  • Backup proxies: take the workload off the management server, providing flexible throttling policy settings for performance optimization.
  • Support for multiple repositories: Streamlines data backup and restore processes.
  • Support for backup and restore of on-premises and hybrid Exchange organizations: Allows a variety of configurations and usage scenarios and implement those that meet your particular needs.
  • Increased performance: Restore operations allows for up to 5 times faster restores than in v1.0.
  • Restore of multiple datastore mailboxes using Veeam Explorer for Microsoft Exchange: simplifies workflow and minimizes workload for restore operators, as well as 1-Click restore of a mailbox to the original location.
  • RESTful API and PowerShell cmdlets: Helpful for automation of routine tasks and integration into existing or new portals.
  • UI Enhancements: Including main window, wizards, dialogs, and other elements, facilitating administration of the solution.
Examples of the Power of the Veeam APIs:

One of the features of Backup for Office 365 was the addition of a power set of RESTful APIs and PowerShell commandlets that are aimed are service providers automating the setup and management of their offerings around the product. A couple of our employees have written example interfaces for the Backup for Office 365 product and it shows that any service provider with some in house programming skill set can build customer portals that enhances their offerings and increases efficiency through automation.

Special welcome to Niels who this week joined our team. Great to have you on board!

Microsoft Azure Stack Support:

Last week at Microsoft Ignite, we announce our supportability for Azure Stack. This is based around our Windows Agent, Cloud Connect and Availability Console products that combine together to off an availability solution

Key benefits of Veeam’s support for the Azure Stack include:

  • Multi-tenancy: Veeam Cloud Connect isolates backup copies for each tenant ensuring security and compliance; 
  • Multiple recovery options: Veeam Backup & Replication supports both granular item level recovery through Veeam Explorers for Microsoft Exchange, SQL Server, Microsoft SharePoint, Microsoft Active Directory and for Oracle, as well as full file level restores for tenant files that were deleted or corrupted;
  • Reporting & Billing: Veeam Availability Console supports real-time monitoring and chargeback on tenant usage, allow either Hosting providers or Enterprise organizations to easily manage and bill their tenants for Availability usage.

Veeam Vanguard Blog Post Roundup:

References:

https://helpcenter.veeam.com/docs/vbo365/guide/vbo_what’s_new_in_v1_5.html?ver=15

Veeam is now in the Network Game! Introducing Veeam Powered Network.

Posted on by

Today at VeeamON 2017 we announced the Release Candidate of Veeam PN (Veeam Powered Network) which together with our existing feature, Direct Restore to Microsoft Azure creates a new solution called Veeam Disaster Recovery for Microsoft Azure. At the heart of this new solution is Veeam PN which extends an on-premises network to one that’s in Azure enhancing our availability capabilities around disaster recovery.

Veeam PN allows administrators to create, configure and connect site-to-site or point-to-site VPN tunnels easily through an intuitive and simple UI all within a couple of clicks. There are two components to Veeam PN, that being a Hub Appliance that’s deployable from the Azure Marketplace and a Site Gateway that’s downloadable from the veeam.com website and deployable on-premises from an OVA meaning it can be installed onto

Veeam PN for Microsoft Azure (Veeam Powered Network) is a free solution designed to simplify and automate the setup of a disaster recovery (DR) site in Microsoft Azure using lightweight software-defined networking (SDN).

  • Provides seamless and secure networking between on-premises and Azure-based IT resources
  • Delivers easy-to-use and fully automated site-to-site network connectivity between any site

Veeam PN is designed for both SMB and Enterprise customers, as well as service providers.

From my point of view this is a great example of how Veeam is no longer a backup company but a company that’s focused on availability. Networking is still the most complex part of executing a successful disaster recovery plan and with Veeam PN easily extending on-premises networks to DR networks as well as providing connectivity from remote sites back to DR networks via site-to-site connectivity while also providing access for remote endpoints the ability to connect into the HUB appliance and be connected to networking configured via a point-to-site connection.

Look out for more information from myself on Veeam PN as we get closer to GA.

Looking Beyond the Hyper-Scaler Clouds – Don’t Forget the Little Guys!

Posted on by

I’ve been on the road over the past couple of weeks presenting to Veeam’s VCSP partners and prospective partners here in Australia and New Zealand on Veeam’s Cloud Business. Apart from the great feedback in response to what Veeam is doing by way of our cloud story I’ve had good conversations around public cloud and infrastructure providers verses the likes of Azure or AWS. Coming from my background working for smaller, but very successful service providers I found it almost astonishing that smaller resellers and MSPs seem to be leveraging the hyper-scale clouds without giving the smaller providers a look in.

On the one hand, I understand why people would choose to look to Azure, AWS and alike to run their client services…while on the other hand I believe that the marketing power of the hyper-scalers has left the capabilities and reputation of smaller providers short changed. You only need to look at last week’s AWS outage and previous Azure outages to understand that no cloud is immune to outages and it’s misjudged to assume that the hyper-scalers offer any better reliability or uptime than the likes of providers in the vCloud Air Network or other IaaS providers out there.

That said, there is no doubt that the scale and brain power that sits behind the hyper-scalers ensures a level of service and reliability that some smaller providers will struggle to match, but as was the case last week…the bigger they are, the harder they fall. The other things that comes with scale is the ability to drive down prices and again, there seems to be a misconception that the hyper-scalers are cheaper than smaller service providers. In fact most of the conversations I had last week as to why Azure or AWS was chosen was down to pricing and kickbacks. Certainly in Azure’s case, Microsoft has thrown a lot into ensuring customers on EAs have enough free service credits to ensure uptake and there are apparently nice sign-up bonuses that they offer to partners.

During that conversation, I asked the reseller why they hadn’t looked at some of the local VCSP/vCAN providers as options for hosting their Veeam infrastructure for clients to backup workloads to. Their response was, that it was never a consideration due to Microsoft being…well…Microsoft. The marketing juggernaut was too strong…the kickbacks too attractive. After talking to him for a few minutes I convinced him to take a look at the local providers who offer, in my opinion more flexible and more diverse service offerings for the use case.

Not surprisingly, in most cases money is the number one factor in a lot of these decisions with service uptime and reliability coming in as an important afterthought…but an afterthought non-the less. I’ve already written about service uptime and reliability in regards to cloud outages before but the main point of this post is to highlight that resellers and MSP’s can make as much money…if not more, with smaller service providers. It’s common now for service providers to offer partner reseller or channel programs that ensure the partner gets decent recurring revenue streams from the services consumed and the more consumed the more you make by way of program level incentives.

I’m not going to do the sums, because there is so much variation in the different programs but those reading who have not considered using smaller providers over the likes of Azure or AWS I would encourage to look through the VCSP Service Provider directory and the vCloud Air Network directory and locate local providers. From there, enquire about their partner reseller or channel programs…there is money to be made. Veeam (and VMware with the vCAN) put a lot of trust and effort into our VCSPs and having worked for some of the best and know of a lot of other service provider offerings I can tell you that if you are not looking at them as a viable option for your cloud services then you are not doing yourself justice.

The cloud hyper-scalers are far from the panacea they claim to be…if anything, it’s worthwhile spreading your workloads across multiple clouds to ensure the best availability experience for your clients…however, don’t forget the little guys!

VMworld 2016: Cross Cloud Platform – Raw Thoughts

Posted on by

I’m still trying to process the VMworld 2016 Day 1 Keynote in my mind…trying to make sense of the mixed messages that myself and others took away from the 90 minute opening. Before I continue, I’ll point out that this is going to be raw post with opinions that are purely driven buy what I saw and heard during the keynote…I haven’t had much time to validate my thoughts although from my brief discussions with others here at the conference (and on Twitter) it’s clear that the Cross Cloud migration tech preview is an attempt at VMware catering to the masses. I’ll explain below why that’s both a good and bad thing and why the vCloud Air Network should be rightly miffed about what we saw demoed on stage.

Yesterday’s opening was all about Pat trying to make sure that everyone who was listening understood that VMware is still cool and relevant. The message around be_tomorrow was lost for me by the overall message that VMware has grown up and matured, but are still capable of producing teen like excitement through cool and hip technologies. If there was ever a direct reaction to the disruptive competitors VMware has had to deal with (looking at you Nutanix) then this was corporates attempt to mitigate that threat. Not sure that it worked, but did it really need to be done when you are effectively preaching to the converted?

Pat Gelsinger used his keynote to introduce the VMware® Cross-Cloud Architecture™. This is a game-changing new architecture that, as he says, “will enable customers to run, manage, connect, and secure applications across clouds and devices in a common operating environment.

vCAN_VMworld_1

During the first part of the keynote things where looking good for the vCAN with vCloud Air not getting much of a mention over the strong growth in the vCAN as shown on stage in the image above. Pat then went through and talked about trends in public and private clouds which lead into the messaging that Hybrid Cloud is the way of the future…no one cloud will rule them all. This isn’t new messaging and I agree 100% that there is a place in the world for all types of clouds, from the HyperScalers through to the smaller but more agile IaaS providers and managed private clouds.

AWSworld? – vCloud Air Network Concerns:

The second part of the keynote was where things got a little confusing for me. We saw two demo’s of Cross Cloud Architecture in tech preview. Let me start by saying that the UI looked consistent and modern and even managed to integrate vRealize Network Insight (Arkin) seamlessly and the NSX network extension is a brilliant step forward in being able to extend cloud networks between on-premises to public to vCAN Service Provider.

Where things got a little awkward for me was when the demo of the Cross Cloud Management console went through managing services and instances on AWS and Azure…without any mention or example or listing of any vCAN service provider. Not withstanding the focus on the growing partnership with IBM Softlayer in the new Cloud Foundation ecosystem that naturally competes directly against vCAN service providers the specific focus of AWS made a lot of providers uneasy.

Now, I understand that the vCAN can’t do everything and the there is an existing and future sense of inevitability around clients using more hyper-scale cloud services…but here is why I found this to be a bit of a slap in the face to the 4000+ strong vCAN. If you are going to demo the use of cross cloud why not focus on what the hyper-scalers do best that is PaaS? Don’t demo creating and moving traditional workload instances on AWS and then move it to Azure.

Again, this is a raw post and I do need to digest this a little more and I will follow up with a more in depth post and make no mistake that I do see value in the tool…but it does nothing to build and grow the vCAN…and that is the sore point at this point in time.

Azure Stack – Microsoft’s White Elephant?

Posted on by

azure
Microsoft’s World Wide Partner Conference is currently on again in Toronto and even though my career has diverged from working on the Microsoft stack (no pun) over the past four or five years I still attend the local Microsoft SPLA monthly meetings where possible and keep a keen eye on what Microsoft is doing in the cloud and hosting spaces.

The concept of Azure Stack has been around for a while now and it entered Technical Preview early this year. Azure Stack was/is touted as an easily deployable end to end solution that gives enterprises Azure like flexibility on premises covering IaaS, PaaS and Containers. The premise of the solution is solid and Microsoft obviously see an opportunity to cash in on the private and hybrid cloud market that at the moment, hasn’t been locked down by any one vendor or solution. The end goal though is for Microsoft to have workloads that are easily transportable into the Azure Cloud.

Azure Stack is Microsoft’s emerging solution for enabling organizations to deploy private Azure cloud environments on-premises. During his Day 2 keynote presentation at the Worldwide Partner Conference (WPC) in Toronto, Scott Guthrie, head of Microsoft’s Cloud and Enterprise Group, touted Azure Stack as a key differentiator for Microsoft compared to other cloud providers.

The news overnight at WPC is that apart from the delay in it’s release (which wasn’t unexpected given the delays in Windows Server 2016) Microsoft have now said that the Azure Stack will only be available via pre-validated hardware partners which means that customers can’t deploy the solution themselves meaning the stack loses flexibility.

Neil said the move is in response to feedback from customers who have said they don’t want to deal with the complexities and downtime of doing the deployments themselves. To that end, Microsoft is making Azure Stack available only through pre-validated hardware partners, instead of releasing it as a solution that customers can deploy, manage and customize.

This is an interesting and in my opinion risky move by Microsoft. There is a precedence to suggest that going down this path leads to lesser market penetration and could turn the Azure Stack into that white elephant that I suggested in a tweet and in the title of this post. You only have to look at how much of a failure VMware’s EVO:Rail product was to understand the risks of tying a platform to vendor specific hardware and support. Effectively they are now creating a Converged Infrastructure Stack with Azure bolted on where as before there was absolute freedom in enterprises being able to deploy Azure Stack into existing hardware deployments allowing for a way to realise existing costs and extending that to provide private cloud services.

As with EVO:Rail and other Validated Designs, I see three key areas where they suffer and impact customer adoption.

Validated Design Equals Cost:

If I take EVO:Rail as an example there was a premium placed on obtaining the stack through the validated vendors and this meant a huge premium on what could have been sourced independently when you took hardware, software and support costs into account. Potentially this will be the same for the Azure Stack…vendors will add their percentage for the validated design, plus ongoing maintenance. As mentioned above, there is also now the fact that you must buy new hardware (compute, network, storage) meaning any existing hardware that can and should be used for private cloud is now effectively dead weight and enterprises need to rethink long term about existing investments.

Validated Design Equals Inherit Complexity:

When you take something in-house and not let smart technical people deploy a solution my mind starts to ask the question why? I understand the argument will be that Microsoft want a consistent experience for the Azure Stack and there are other examples of controlled deployments and tight solutions (VMware NSX comes to mind in the early days) but when the market you are trying to break into is built on the premise of reduced complexity…only allowing certain hardware and partners to run and deploy your software tells me that it walks a fine line between being truly consumable and it being a black box. I’ve talked about Complex Simplicity before and this move suggests that Azure Stack was not ready or able to be given to techs to install, configure and manage.

Validated Design Equals Inflexibility:

Both of the points above lead into the suggestion that the Azure Stack looses it’s flexibility. Flexibility in the private and hybrid cloud world is paramount and the existing players like Openstack and others are extremely flexible…almost to a fault. If you buy from a vendor you loose the flexibility of choice and can then be impacted at will by costs pressures relating to maintenance and support. If the Azure stack is too complex to be self managed then it certainly looses the flexibility to be used in the service provider space…let alone the enterprise.

Final Thoughts:

Worryingly the tone of the offical Blog Announcement over the delay suggest that Microsoft is reaching to try and justify the delay and the reasoning for going down the different distribution model. You just have to read the first few comments on the blog post to see that I am not alone in my thoughts.

Microsoft is committed to ensuring hardware choice and flexibility for customers and partners. To that end we are working closely with the largest systems vendors – Dell, HPE, Lenovo to start with – to co-engineer integrated systems for production environments. We are targeting the general availability release of Azure Stack, via integrated systems with our partners, starting mid-CY2017. Our goal is to democratize the cloud model by enabling it for the broadest set of use-cases possible.

 

With the release of Azure Stack now 12+ months away Microsoft still has the opportunity to change the perception that the WPC2016 announcements has in my mind created. The point of private cloud is to drive operational efficiency in all areas. Having a fancy interface with all the technical trimmings isn’t what will make an on-premises stack gain mainstream adoption. Flexibility, cost and reduced complexity is what counts.

References:

https://azure.microsoft.com/en-us/blog/microsoft-azure-stack-delivering-cloud-infrastructure-as-integrated-systems/?utm_campaign=WPC+2016&utm_medium=bitly&utm_source=MNC+Microsite

https://rcpmag.com/articles/2016/07/12/wpc-2016-microsoft-delays-azure-stack.aspx

http://www.zdnet.com/article/microsoft-to-release-azure-stack-as-an-appliance-in-mid-2017/

http://www.techworld.com.au/article/603302/microsoft-delays-its-azure-stack-software-until-mid-2017/

The Reality of Cloud – Outages are Like *holes…

Posted on by

It’s been a bad couple of weeks for cloud services both around the world and locally…Over the last three days we have seen AWS have issues which may have been indirectly related to the Leap Second on Tuesday night and this morning, Azure’s Sydney Zone had serious network connectivity issues which disrupted services for approximately three to four hours.

cloud3
Closer to home, Zettagrid had a partial outage of our Sydney Zone last Wednesday morning which impacted a small subset of client VMs and services and this was on the back of a major (unnamed) provider in Europe being down for a number of days as pointed out in a blog post by Massimo Re Ferre’ linked below.

http://it20.info/2015/06/iaas-cloud-outages-get-over-it/ 

Massimo struck a cord with me and as the title of Massimo’s blog post suggests it’s time for consumers of public cloud services to get over outages and understand that when it comes to Cloud and IaaS…Outages will happen.

When you hear someone saying “I moved to the cloud because I didn’t want to experience downtime” it is fairly clear to me that you either have been heavily misinformed or you misunderstood what the benefits of a (IaaS) public cloud are

Regardless if you are juggernauts like Amazon, Microsoft or Google…or one of the smaller Service Providers…the reality of cloud services is that outages are a fact of life. Even SaaS based application are susceptible to outages and it must be understood that there is no magic that goes into the architecture of cloud platforms and while every effort goes into ensuring availability and resiliency Massimo sums it up well below.

Put it in (yet) another way: a properly designed public cloud is not intrinsically more reliable than a properly designed Enterprise data center (assuming like for like IT budgets).

That is because sh*t happens…

The reality of what can be done to prevent service disruption is for consumers of cloud services to look beyond the infrastructure and think more around the application. This message isn’t new and the methods undertaken by larger companies when deploying business critical service and applications is starting to change…however not every company can be a NetFlix or a Facebook so in breaking it down to a level that’s achievable for most…the question is.

How can everyday consumers of cloud services architect applications to work around the inevitable system outage?

  1. Think about a multi cloud or hybrid cloud strategy
  2. Look for Cloud Service Providers that have multiple Availability Zones
  3. Make sure that the Availability Zones are independent of one an other
  4. Design and deploy business critical applications across multiple Zones
  5. Watch out for Single Points of Failures within Availability Zones
  6. Employ solid backup and recovery strategies

They key to the points above is to not put all your eggs into one basket and then cry foul when that basket breaks…do not set an expectation whereby you become complacent in the fact that all Cloud Service Providers guarantee a certain level of system up time through SLA’s and then act surprised when an outage occurs. Most providers who are worth their salt do offer separate availability zones…but it’s very much up to the people designing and building services upon Services Provider Clouds to ensure that they are built to take advantage of this fact…you can’t come in stamping your feet and crying foul when the resources that are placed at your disposal to ensure application and service continuity are not taken advantage of.

Do not plan for 100% uptime…it does not exist! Anyone who tries to tell you otherwise is lying! You only have to search online to see that Outages are indeed like Assholes…everyone has them!

References:

http://au.pcmag.com/internet-products/35269/news/aws-outage-takes-down-netflix-pinterest

http://it20.info/2015/06/iaas-cloud-outages-get-over-it/

https://downdetector.com/status/aws-amazon-web-services/news/71670-problems-at-amazon-web-services