Archive

Posts Tagged ‘Azure’

Azure SQL Server VM backup failures

SQL Server VMs in Azure can be backed up using the SQL Server configuration blade in the portal. When this has been enabled the logs can be swamped by errors similar to:

2018-06-04 11:44:59.88 Backup BACKUP failed to complete the command BACKUP LOG master. Check the backup application log for detailed messages.

Fear not, it is only temporary. A SQL Server backup consists of two parts: a full backup of the database(s) and transaction logs. When no full backup has been done the transaction log backups fail with the error above. The errors should go away when the first full backup has been completed successfully.

As a side note there is no “application log”, the message refers to the calling application and in this case that is the Azure SQL Server extension. It doesn’t log anything useful.

Advertisements
Categories: Database

Azure AKS default VM size cannot be changed

Kubernetes is pushed by all the major cloud provider and Microsoft recently (well, end of 2017) rolled out managed Kubernetes, AKS. It is a great offering, but there are problems. This is to be expected from a product that is still in preview, but take care and expect a somewhat bumpy ride if you take the leap!

Create a new cluster, for example with:


az aks create --resource-group rgakstwe \
 --name akstwe \
 --node-count 2 \
 --ssh-key-value ~/.ssh/id_rsa.pub \
 --location westeurope

This creates two nodes with the default AKS VM size, at this point Standard_D1_v2. All is well, but what happens when you want to add persistent volumes? Unfortunately premium storage disks are available only for some VMs. In particular they are NOT available for Standard_D1_v2, so while it is possible to create a persistent volume claim it is not possible to run a deployment that uses it.

What to do? There is no az aks update command for changing the VM size. According to Microsoft the only way forward is to manually change the size for each individual VM. That works, but there is a problem: the default size will be used when the cluster is scaled, so if it scales down and then up again the manually tweaked nodes revert to the default VM size.

At present that is the way it is. When AKS exits preview and is rolled out for real there will be a way to change the default VM size, but for now it is important to think ahead as the only way to change the default which is used for scaling is to recreate the cluster.

In other words, plan ahead and don’t start too small.

Categories: Kubernetes