Azure-Tips & Tricks We Should Know

Tip #01- Enablement Of Ping On Windows VM

Ping is widely used to communicate from one VM to another. It uses the Internet Control Message Protocol (ICMP), which is denied through the Windows Firewall, by default. you can enable the Internet Control Message Protocol (ICMP) through the Windows firewall so that you can ping the second server.Below is the powershell command to achieve he same-

New-NetFirewallRule -DisplayName "Allow ICMPv4-In"-Protocol ICMPv4 

Tip #02- Deny All To Internet 

Most of the times you might hear Architects designing their Security layers by Denying all traffic to the Internet( In case of Azure through NSG) though this will ensure the security of your network from data leakage or malware, but at times it can lead to frustration and can break things which are suppose to function smoothly. Some times your VM's do need access to Azure IP addresses(Service like Azure Storage, Azure SQL Database, etc..).Now as these IPS also falls under the Internet tag, When you are blocking the internet unknowingly you are blocking access to these services as well. There is very good solution for such scenario by Microsoft’s Keith Mayer, you can refer his Article to have more comprehensive approach for this.

Tip #03- Storage Account Key Rotation

Any storage account creation automatically generates the Shared Key(Pair), this shared access key has proven to be a commonly used option to access Aforementioned Storage account. VNET integration with Storage account allows for access to this via VNET Service Endpoints. But this option has its operation radius which at times are limited to IaaS space only. In cases when an Azure Storage Account is accessible over the Internet (PaaS) it will make use of shared access key for accessibility.

Under given situation when an individual possessing these keys goes out of organization, it can leave them vulnerable & exposed.To mitigate this, Azure best practice warrants us to adopt robust key rotation policy, which means rotate them periodically.

When it comes Shared Access Keys they come in Pair, for enterprise grade key rotation solution, we shall integrate the Rotation policy with Azure Automation, Log Analytics and Key Vault.

• Regenerate Key-2 for Given Storage Account
• Wait for acceptable time period to ensure Key-2 is active
• Update the secret in Azure Key Vault (with new value of Key-2)
• Repeat exact steps for Key-1 Regeneration

Azure Storage - High Level Architecture

Windows Azure storage is a cloud storage service that is highly durable, available, and scalable. Once your data is stored in Azure storage, you can access that data any time and from anywhere. It provides the following four abstractions (services)- Blob storage, Table storage, Queue storage, and File storage. Each of these has different role to play, you can get more information here…

In conjunction to aforementioned services It also provides the storage foundation for Azure Virtual Machines in the form of persistent data disks.

The goal of this article is not to explain the offering but to understand the fundamentals of Azure storage using which they are able able to achieve all the design goal sets out. Let’s try to decipher how Microsoft do some of these things on Azure storage under the cover.

Any data stored on Azure Storage is triplicated by default, in normal circumstances it creates at least 3 copies of that inside storage stamp (and potentially another region with geo-resiliency enabled). So, before diving into storage architecture it’s only fair to put some lights on Stamps-

Azure Storage Stamp

Azure Divides things into Stamps where each stamp has its own fabric controller. A single Storage Stamp can best be understood as a cluster of N racks of storage nodes, where each rack is built out as a separate fault domain with redundant networking and power. Clusters typically range from 10 to 20 racks with 18 disk-heavy storage nodes per rack.

Microsoft deploys these stamps in its Azure data centers across the world, and adds more stamps as demand grows. Inside the datacenter it's used as a unit of deployment and management. They provide huge assistance in achieving fault-tolerance.

When user creates storage accounts all the data of that is stored on a single stamp. They do get migrated between stamp only when need arises, the way it works is that Microsoft always make sure that single storage stamp should only be utilized ~75% of its capacity & bandwidth. This is because ~20% is kept as a reserve for –

1. Disk short stroking to gain better seek times and higher throughput by utilizing the outer tracks of the disks
2. To continue providing storage capacity and availability in the presence of a rack failure within a stamp. When the storage stamp reaches ~75% utilization, the location service migrates accounts to different stamps using Inter-Stamp replication

Location Service

Location Service in Azure is the one responsible for storage stamps management. Another notable responsibility of this to manage the account name-spaces across all stamps. Internally this Location Service itself is distributed across two geographical locations for its own disaster recovery. That makes it immune from geo failure.

As shown in the architecture diagram- We have a Location Service with two storage stamps and within the stamps we have the all three-layer mentioned. While tracking the resources Location Service look for them at each storage stamp in production across all the locations. Now when an application requests a new account for storing data, it specifies the location affinity for the storage (e.g., US North). The LS then chooses a storage stamp within that location as the primary stamp for the account using heuristics based on the load information across all stamps (which considers the fullness of the stamps and other metrics such as network and transaction utilization). The LS then stores the account metadata information in the chosen storage stamp, which tells the stamp to start taking traffic for the assigned account. The LS then updates DNS to allow requests to now route from the name https://AccountName.service.core.windows.net/ to that storage stamp’s IP which it has exposed for external traffic

Architecture Layers inside Stamps

system To keep the data durable, consistent and available with in specific Azure Region lest understand the different layer which constitute the stamp. Windows Azure Storage is a layered system, so let's take it from the bottom up-

Stream Layer: The first or lowest layer on this subsystem which also gets referred as DFS (Distributed File System) layer. This layer stores the bits on disk and is actually in charge of handling the disk, it’s the responsibility of this layer to persist your data on the disk by distributing and replicating the data across many servers to provide durability within a storage stamp. you can think of the underling system as JBOD with in the stamp, so your data when you store in the Azure Storage Service it gets stored in the DFS into these files which is called extent and these extend gets replicated three times across UD’s (update domain)/FD’s (fault domain). The unique thing about this file system is that this is append only file system so when you override any data azure always keeps on appending the data to these extents.

Partition Layer: Then comes the partition layer which can be called as the brain of Azure Storage service. Most of the decision making happens at this layer. It has this significance because it serves two unique purposes-First this layer is built for managing and understanding higher level data abstractions (Blob, Table, Queue, Files). So, it’s this layer which understand what blob, is table is and how to perform transaction on those objects.Secondly it providing a scalable object namespace, and responsible for massive scalable indexIn addition to above two it does help in providing transaction ordering and strong consistency for objects, storing object data on top of the stream layer.  '

Front End Layer:  And finally, at the top of Azure Storage Service we have front end layer which provides a rest protocol for those abstractions (Blob, Table, Queue, Files). The Front-End layer consists of a set of stateless servers that take incoming requests. Upon receiving a request, an FE looks up the AccountName, authenticates and authorizes the request, then routes the request to a partition server in the partition layer (based on the PartitionName). Every write request which comes to the system will have a partition key specified to it. So, in nutshell it does extend its roles for authentication/authorization.

Global Name-space

One of the key design goal of Azure Storage Service is to provide a single global namespace that allows the data to be stored and accessed in a consistent manner from any location in the world. To provide this capability Microsoft leverages DNS as part of the storage namespace and break the storage namespace into three parts: an account name, a partition name, and an object name. As a result, all data is accessible via a uniform URI of the form:

http(s)://AccountName.1.core.windows.net/PartitionName/ObjectName

Two Replication Engines

To address the replication challenge which is backbone of all the Azure Storage Service design goals Azure in general two types of replication-

 Intra-Stamp Replication: Under this replication model Azure keeps your data durable within a region or stamp. It provides synchronous replication and is focused on making sure all the data written into a stamp is kept durable within that stamp. It keeps three replicas of the data across different nodes in different fault domains/Update Domain to keep data durable within the stamp in the face of disk, node, and rack failures. Intra-stamp replication is done completely by the stream layer and is on the critical path of the customer’s write requests. Once a transaction has been replicated successfully with intra-stamp replication, success can be returned back to the customer. Under this engine Azure provides strong consistency, until data is written on all the three places transaction is not committed. And because the replication implementation is happening at stream layer it can provide

Inter-Stamp Replication: Under this replication model Azure provides asynchronous replication and is focused on replicating data across stamps. Inter-stamp replication is done in the background and is off the critical path of the customer’s request. Because of asynchronous replication the write operation is not strongly consistent. This replication is at the object level, where either the whole object is replicated or recent delta changes are replicated for a given account. Inter-stamp replication is configured for an account by the location service and performed by the partition layer. 

“Inter-stamp replication is focused on replicating objects and the transactions applied to those objects, whereas intra-stamp replication is focused on replicating blocks of disk storage that are used to make up the objects.”

Conclusion

When Windows Azure Storage was being comprehended, it had some design goals to achieve -

Consistency: One of the design goal of Microsoft for WAS was to provide strong consistency with in a region. By virtue of mentioned technological brilliance all the data which goes to Azure Storage gets triplicated and All committed data across all 3 replicas are identical.

Durability: Second design goal was that the data must be durable that means there must be proper replication mechanism in place, to address the same all data stored with at least 3 replicas

Availability: Can read from any 3 replicas; If any issues writing seal extent and continue appending to new extent

Performance/Scale: Retry based on 95% latencies; Auto scale out and load balance based on load/capacity. As it should automatically scale to meet the customers peak demand

*You also need a global name space to access the data around the world

Azure Storage - Account Monitoring

Azure supports storage account monitoring from management portal Azure Portal. While doing so via portal it uses Storage Analytics to track metrics for your account and log request data.

P.S. Storage accounts with a replication type of Zone-Redundant Storage (ZRS) do not have the metrics or logging capability enabled at this time.

How to: Configure monitoring for a storage account

1. In the Azure Portal, click Storage, and then click the storage account name to open the dashboard.
2. Click Configure, and scroll down to the monitoring settings for the blob, table, and queue services.
   
3. In monitoring, set the level of monitoring and the data retention policy for each service:
   • To set the monitoring level, select one of the following:
     Minimal - Collects metrics such as ingress/egress, availability, latency, and success percentages, which are aggregated for the blob, table, and queue services.
     Verbose - In addition to the minimal metrics, collects the same set of metrics for each storage operation in the Azure Storage Service API. Verbose metrics enable closer analysis of issues that occur during application operations.
     Off - Turns off monitoring. Existing monitoring data is persisted through the end of the retention period.

• To set the data retention policy, in Retention (in days), type the number of days of data to retain from 1 to 365 days. If you do not want to set a retention policy, enter zero. If there is no retention policy, it is up to you to delete the monitoring data. We recommend setting a retention policy based on how long you want to retain storage analytics data for your account so that old and unused analytics data can be deleted by system at no cost.

1. When you finish the monitoring configuration, click Save.

You should start seeing monitoring data on the dashboard and the Monitor page after about an hour.

Until you configure monitoring for a storage account, no monitoring data is collected, and the metrics charts on the dashboard and Monitor page are empty.

After you set the monitoring levels and retention policies, you can choose which of the available metrics to monitor in the Azure Portal, and which metrics to plot on metrics charts. A default set of metrics is displayed at each monitoring level. You can use Add Metrics to add or remove metrics from the metrics list.

Metrics are stored in the storage account in four tables named $MetricsTransactionsBlob, $MetricsTransactionsTable, $MetricsTransactionsQueue, and $MetricsCapacityBlob. For more information, see About Storage Analytics Metrics.

How to: Customize the dashboard for monitoring

On the dashboard, you can choose up to six metrics to plot on the metrics chart from nine available metrics. For each service (blob, table, and queue), the Availability, Success Percentage, and Total Requests metrics are available. The metrics available on the dashboard are the same for minimal or verbose monitoring.

1. In the Azure Portal, click Storage, and then click the name of the storage account to open the dashboard.
2. To change the metrics that are plotted on the chart, take one of the following actions:
   • To add a new metric to the chart, click the colored check box next to the metric header in the table below the chart.
   • To hide a metric that is plotted on the chart, clear the colored check box next to the metric header.
     
3. By default, the chart shows trends, displaying only the current value of each metric (the Relativeoption at the top of the chart). To display a Y axis so you can see absolute values, select Absolute.
4. To change the time range the metrics chart displays, select 6 hours, 24 hours, or 7 days at the top of the chart.

How to: Customize the Monitor page

On the Monitor page, you can view the full set of metrics for your storage account.

• If your storage account has minimal monitoring configured, metrics such as ingress/egress, availability, latency, and success percentages are aggregated from the blob, table, and queue services.
• If your storage account has verbose monitoring configured, the metrics are available at a finer resolution of individual storage operations in addition to the service-level aggregates.

Use the following procedures to choose which storage metrics to view in the metrics charts and table that are displayed on the Monitor page. These settings do not affect the collection, aggregation, and storage of monitoring data in the storage account.

How to: Add metrics to the metrics table

1. In the Azure Portal, click Storage, and then click the name of the storage account to open the dashboard.
2. Click Monitor.
   The Monitor page opens. By default, the metrics table displays a subset of the metrics that are available for monitoring. The illustration shows the default Monitor display for a storage account with verbose monitoring configured for all three services. Use Add Metrics to select the metrics you want to monitor from all available metrics.
   

   Note

   Consider costs when you select the metrics. There are transaction and egress costs associated with refreshing monitoring displays. For more information, see Storage Analytics and Billing.
3. Click Add Metrics.
   The aggregate metrics that are available in minimal monitoring are at the top of the list. If the check box is selected, the metric is displayed in the metrics list.
   
4. Hover over the right side of the dialog box to display a scrollbar that you can drag to scroll additional metrics into view.
   
5. Click the down arrow by a metric to expand a list of operations the metric is scoped to include. Select each operation that you want to view in the metrics table in the Azure Portal.
   In the following illustration, the AUTHORIZATION ERROR PERCENTAGE metric has been expanded.
   
6. After you select metrics for all services, click OK (checkmark) to update the monitoring configuration. The selected metrics are added to the metrics table.
7. To delete a metric from the table, click the metric to select it, and then click Delete Metric.
   

How to: Customize the metrics chart on the Monitor page

1. On the Monitor page for the storage account, in the metrics table, select up to 6 metrics to plot on the metrics chart. To select a metric, click the check box on its left side. To remove a metric from the chart, clear the check box.
2. To switch the chart between relative values (final value only displayed) and absolute values (Y axis displayed), select Relative or Absolute at the top of the chart.
3. To change the time range the metrics chart displays, select 6 hours, 24 hours, or 7 days at the top of the chart.

How to: Configure logging

For each of the storage services available with your storage account (blob, table, and queue), you can save diagnostics logs for Read Requests, Write Requests, and/or Delete Requests, and can set the data retention policy for each of the services.

1. In the Azure Portal, click Storage, and then click the name of the storage account to open the dashboard.
2. Click Configure, and use the Down arrow on the keyboard to scroll down to logging.
   
3. For each service (blob, table, and queue), configure the following:
   • The types of request to log: Read Requests, Write Requests, and Delete Requests.
   • The number of days to retain the logged data. Enter zero is if you do not want to set a retention policy. If you do not set a retention policy, it is up to you to delete the logs.
4. Click Save.

The diagnostics logs are saved in a blob container named $logs in your storage account. For information about accessing the $logs container, see About Storage Analytics Logging.