Jumping into Azure Arc Data Services

Microsoft may have promised multiple future releases of on-premises Windows Server, but that doesn’t mean you continue to manage and use those servers the way you always have. Key to Windows Server’s future is Microsoft’s hybrid cloud strategy which gives equal weight to on-premises hardware and its Azure hyperscale cloud. Technologies such as Windows Admin Center and Azure Arc bring Web-based monitoring and administration to your servers, providing a bridge between the Azure Portal and Windows.

Using Azure Arc with databases

Azure Arc is an important piece of that puzzle, allowing you to separate physical infrastructure from virtual, adding a new tier of management tools that support your applications directly. With Arc, you use cloud-focused management tools to work with on-premises resources, deploying virtual machine images and virtual appliances, managing virtual networks and storage pools, as well as deploying managed Kubernetes services on your own hardware. It’s no wonder that Azure Arc is the management layer for the latest versions of Microsoft’s Azure Stack HCI hyperconverged server implementation.

At its 2019 launch, Microsoft promised three roles for Azure Arc: working with virtual infrastructures, managing Kubernetes, and supporting local instances of cloud databases. The first is now generally available, with Kubernetes support in preview. Now it’s time for the data services facet of Arc to get its time in the sun, with a public preview of support for Azure’s PostgreSQL Hyperscale and SQL Managed Instance, as well as for the familiar SQL Server.

Microsoft treats Arc’s database tools as two different options, separating the Arc-managed and locally hosted Azure data services from SQL Server. It’s a sensible choice if you’re looking to use Arc to manage workloads and data that may migrate from your servers to Azure. The SQL Server option lets you migrate existing on-premises data to Azure Stack HCI or another Arc-enabled server cluster as part of a migration process, getting data onto new hardware before moving it to newer, cloud-ready database technologies.

Using containers to deploy cloud applications on-premises

Working with Azure Arc’s data services has other advantages. You’re now working with Azure-managed applications on your own hardware, handing over responsibility for updates to Microsoft. The databases run in containers, with your data and any stored procedures stored on your Arc cluster’s virtualized storage array, separate from the database engine. Using Arc’s management tools, you can apply new database containers from the Azure Container Registry as new patched versions are released.

Using containers as a package like this changes the way you need to think about your databases. Instead of applying patches to a binary, having to schedule downtime and testing, you’re treating the executables as idempotent. Once downloaded and running, a container’s contents will not change, with configurations and data stored outside. Any update now means simply stopping operations to swap in a preconfigured, pretested, updated container, and restarting. If you’re running in a cluster, this can be done with nearly zero downtime: stopping one host, loading a new database container, and then restarting before failing over to the new container and updating additional nodes.

Copyright © 2021 IDG Communications, Inc.

Source link