Some trivia for Azure public cloud (continued from previous article)

Operational requirements for hosting solutions on Azure public cloud:

·        Disaster recovery – Azure Site Recovery services contributes to application-level protection and recovery. It provides near-synchronous replication for any workloads for single or multi-tier applications, works with active-directory and sql server replication. It protects Sharepoint, Dynamics AX and Remote Desktop services It has flexible recovery plans with a rich automation library. One of its biggest use cases is to replicate VMs to Azure. It provides end to end recovery plans.

·        Data redundancy – Azure storage services come with built-in redundancy which also improves durability of the existing Blob services. The Geo-redundant storage (GRS) copies data synchronously three times within a single physical location in the primary region using the LRS. The Geo-zone-redundant storage service (GZRS) copies data synchronously across three availability zones in the primary region using ZRS. Then the other regions are replicated asynchronously. Read Access GRS (RA-GRS) can provide redundancy just for read access.

·        Blob rehydration to the archive tier can be for either hot or cool tier. There are two options for rehydrating a blob that is stored in the archive tier. A) One can copy an archived blob to an online tier using the reference of the blob or its URL. B) Or one can change the blob access tier to an online tier. It can rehydrate the archived blob to hot or cool by changing its tier. Rehydrating might take several hours but several of them can be done concurrently. Rehydration priority might also be set.

·        Storage costs can be optimized by managing the data lifecycle. Azure storage lifecycle management offers a rule-based policy that can be used to transition blob data to the appropriate access tiers or to be set with expiration. The lifecycle policy definition has attributes for actions, baseblobs and filters.

·        Azure monitors are full stack monitoring service. Many Azure services use it to collect and analyze monitoring data. The Blob storage collects the same kind of monitoring data as other Azure resources. Platform metrics and activity logs are automatically collected.

·        Virtual Network peering allows us to connect virtual networks in the same region or across regions as in the case of Global VNet Peering through the Azure Backbone network. When the peering is setup, traffic to the remote virtual network, traffic forwarded from the remote virtual network, virtual network gateway or Route server and traffic to the virtual network can be allowed by default.

·        Transaction processing in Azure is not on by default. A transactions locks and logs records so that others cannot use it, but it can be bound to partitions, enabled as distributed transactions and with two phase commit protocol. Transaction processing requires two communication steps for a resource manager and a response from the transaction coordinator which are costly for a datacenter in Azure. It does not scale as the number resource to calls expands as 2 resources – 4 network calls, 4 resources – 16 calls, 100 resource – 400 calls. Besides, the datacenter contains thousands of machines, failures are expected, and the system must deal with network partitions. Waiting for response from all resource managers has costly communication overhead.

·        Applications can be installed in Virtual machine scale sets with an Azure Template. A custom script extension can be added to the template. The reference to location of the script can be passed in as a parameter. Alternatively, http calls can also be made.

·        A site to site VPN gateway can be configured between Azure and on-premise. Site to Site VPN gateway can provide better continuity for the workload in hybrid cloud setup with Azure.