Tag Archives: Azure

#Azure : Application Gateway


Like your layer 7 load balancer in your traditional datacenter, Azure application gateway takes care of your HTTP/HTTPS based requests. It works at application layer (level 7 of OSI model) and works as a reverse-proxy as well. In application gateway, client connections are terminated at gateway and then forwarded to application.

Let me show, how to create and configure application gateway step-by-step.

Login to the Azure Portal and select “+ Create a resource”. Select the “Networking” and then select “Application Gateway”.

In the basic configuration settings:

Enter the name of the application gateway. Always use a name for any components in Azure that fit for purpose and easy to distinguish.

Select the application gateway tier:

  • Standard: As any other layer 7 load balancer, it provides HTTP(S) load balancing, cookie-based session affinity, secure sockets layer (SSL) offload, end-to-end SSL, URL based content routing, multi-site routing, websocket support, health monitoring, SSL policy and ciphers, request redirect, and multi-tenant back-end support etc.
  • WAF: WAF is an advanced version of standard application gateway with application firewall capabilities that supports all standard AG features along with protection of web applications from common web vulnerabilities and exploits. Application gateway WAF comes pre-configured with OWASP (online web application security project) modsecurity core rule set (3.0 or 2.29) that provides baseline security against many of these vulnerabilities. It provides protection against SQL injection, cross site scripting, command injection, HTTP request smuggling, HTTP response splitting, remote file inclusion attack, HTTP protocol violations and anomalies, bots, crawlers, scanners, application misconfiguration and HTTP Denial of Service etc.

Select SKU size based on your requirement. AG sku comes in small, medium and large size.

Select instance count based on your need. The default instant count is 2.

Select subscription, resource group and location.

Once completed all basic configuration settings, click on OK.

In settings panel, complete following application gateway specific configuration settings:

Select virtual network and subnet that is going to associate with this application gateway.

Complete frontend IP configuration based on your application gateway requirements.

Set idle timeout settings and set the DNS name label.

Select the listener configuration protocol and associated port number.

Once completed with the configuration details, click on OK.

If you select HTTPS in listener configuration, upload PFX certificate file and provide credentials. Once completed with the configuration, click on OK.

Review the summary of the configuration and click on OK to create application gateway.

In the overview section, review the basic configuration.

In configuration panel under settings, you can change the application gateway tier, SKU size and instant count based on your requirements.

In Web application firewall panel under settings, you can upgrade to WAF tier if using standard tier and can also “enable/disable” firewall, configure firewall mode “detection/prevention”, configure rule set with OWASP and advanced configuration for your application gateway.

In Backend pools panel under settings, add and configure backend pools for application gateway. Click on add or existing backend pool to define the backend pool settings.

Click on “+ Add target” to define targets either using “IP address or FQDN” or “Virtual machine”. Click on rules to configure redirection if required.

In HTTP settings under settings, add or edit backend HTTP(S) settings such as cookie based affinity, request timeout, protocol and port etc.

In frontend IP configurations panel under settings, review IP configurations, type, status and associated listeners.

In listeners panel under settings, add basic and multi-site listeners.

In rules panel under settings, define basic and path-based rules based on your requirements.

In health probes panel under settings, you can add and edit health probes.

Once you add health probe, you define following parameters:

Name of the health probe.

Protocol either HTTP or HTTPS.

Enter the host name, path, interval in seconds, timeout in seconds and number of unhealthy thresholds.

In the properties section, you can look at the application gateway properties.

Under the locks section, you can create and configure the lock type to prevent changes and protecting the application gateway profile.

Under the “Automation script” download the script or add to library for reuse.

In the metrics panel, you can monitor the metrics of the application gateway by following parameters:

  • Current Connections
  • Failed Requests
  • Healthy Host Count
  • Response Status
  • Throughput
  • Total Requests
  • Unhealthy Host Count

In alert rules panel under settings, you can define conditional rules.

In diagnostics logs panel under settings, you can view the logs of the resources.

In backend health under settings, you can review the status of the backend pool.

I hope, this article helped you to understand, create, configure and manage Azure application gateways.

Advertisements

#Azure : VNet-to-VNet Connectivity


VNet-to-VNet connectivity is another option to connect two virtual networks. When peering was not available in Azure, VNet-to-VNet connection was the only option to connect two virtual networks either in same region or in two different regions. Connecting a virtual network to another virtual network (VNet-to-VNet) is like connecting a VNet to an on-premises site location. Both connectivity types use an Azure VPN gateway to provide a secure tunnel using IPsec/IKE.

The VNets you connect can be:

  • In the same or different regions
  • In the same or different subscriptions
  • In the same or different deployment models

Let me explain you, how to set it up step by step. Login to the Azure Portal and go to the virtual network.

As you are going to setup a VNet-to-VNet connectivity between two virtual networks, therefore a Gateway subnet and a Network gateway is required in both virtual networks.

Select subnet under settings in virtual network, select “+ Gateway subnet” to create a gateway subnet for this virtual network.

Select an address range that will be used by this network gateway. By default, it selects next available address range.

In my case, I am using last subnet of my address space for gateway subnet.

Once added, you can review all used subnets in subnet panel.

Once, you have setup the subnet gateway in your virtual network then move on and create virtual network gateway to attach with gateway subnet.

Define the name of the virtual network gateway. Select the gateway type to “VPN” as we are establishing VNet-to-VNet connection. Select VPN type either Route-based or Policy-based according to your requirements. Select the VPN SKU based on your need.

Gateway SKUs by tunnel, connection, and throughput:

SKU S2S/VNet-to-VNet
Tunnels
P2S
Connections
Aggregate
Throughput Benchmark
VpnGw1 Max. 30 Max. 128 650 Mbps
VpnGw2 Max. 30 Max. 128 1 Gbps
VpnGw3 Max. 30 Max. 128 1.25 Gbps
Basic Max. 10 Max. 128 100 Mbps

Courtesy: Microsoft

Select the resource group, location and subscription etc.

Select your virtual network for which you are setting up this virtual network gateway.

Create new public IP address for your virtual network gateway.

Create public IP address using either Basic SKU or Standard SKU.

Once you are done with all the details, click on “Create” to deploy virtual network gateway.

Follow the same steps for another virtual network as well.

Once completed above steps in both the virtual networks now this is a time to establish a connection between both virtual network gateways which belongs to their respective virtual networks so that both the virtual networks can talk to each other. To do this, go to the “+ Create a resource” and search for “connection”.

Select the “Connection”.

Click on “Create” to establish a connection between virtual networks.

In basic settings select the type of the connection to VNet-to-VNet. Select the appropriate subscription, resource group and location.

Once configured all the basic settings, select “OK”.

Select both the virtual network gateways that needs to be connected, select the checkbox “Establish bidirectional connectivity” if you want to establish two-way connection. Define first and second connection names and then shared key to establish a secure connection.

Select first virtual network gateway.

Select second virtual network gateway.

Define both first and second connection name and enter the shared key, select OK.

Review the details in summary page and select OK to create a connection between virtual network gateways.

Once completed successfully, resources can talk to each other across virtual networks.

#Azure : Virtual Networks


Azure virtual network enables Azure resources to communicate with each other in Azure network and with external resources through internet. Azure virtual network is like your traditional local area network in datacenter. Azure virtual networks can be connected with another virtual network in Azure and with your On-premises datacenter as well. Azure virtual network supports private ip addressing and subnetting as you do in your on-premises network. Azure virtual network supports subnets within a virtual network, the number of subnets can be defined based on the virtual network class and size of each subnets, and it is as same as VLAN in your traditional network. By default, subnets within virtual network can talk to each other without establishing any connection. Once a virtual network created, multiple address spaces can be added based on your need. While doing this entire exercise, please make sure that any ip address or ip addresses range is not overlapping with each other neither across your Azure virtual networks nor with on-premises network.

Let me show you, how to set up virtual networks step by step. To start login to Azure portal.

In Azure portal, select “+ Create a resource” à“Networking” à “Virtual network”.

Look at the details required to create a virtual network.

Name: Name of the virtual network, it should be unique in your Azure environment.

Address space: Define address space based on your requirement.

Subscription: Select your subscription.

Resource: Either create a new one or use existing resource group.

Location: Select location to create this virtual network resource, It will selected automatically if you are using existing resource group.

Subnet: Define the name of the subnet.

Address range: Define the address range for this subnet.

Service endpoints: Define the service endpoints, by default it is disable.

Look at the below screenshots for filled details. Once filled all the required details, click on “Create” to deploy a virtual network.


Once deployed successfully, you can find this virtual network in your resources.


Select “Subnets” to look at/verify your existing subnet. Click on “+ Subnet” to create a new subnet in your existing virtual network.


Enter the name of the subnet and then enter the address range for this subnet. As we had used 172.26.0.0/20 (172.26.0.0 – 172.26.15.255), therefore the next range will start from 172.26.16.0, You can specify the new range based on your need.


Once filled the required details, select “OK” to deploy a new subnet in your existing virtual network.


Once deployed successfully, you can see both your subnets here.


Go to the Address space, if you would like to add a new address space in your virtual network.


Add the address space based on your requirement. (Example: Many organization uses different – different set of ip address ranges for different types of networks. Very simple example is Corporate and Perimeter network.) Once entered the range, click on “Save”.


Once added the address space successfully, define the subnet in that address space.


In connected device panel, you can see the devices that are using ip address from this virtual network.


In subnet panel, you can define multiple subnets based on your define address ranges.


In DNS panel, you can define the custom DNS server addresses based your network design. By default, it uses Azure-provided DNS server.


In peering panel, you can define peering between two virtual networks that belongs to the same region.


In Service endpoints panel, you can specify services endpoints based on your requirement. In general, you don’t have to define any thing here.


In properties panel, you can see the properties of your virtual network, such as resource id, location, resource group etc.


In Locks, you panel you can define the locks for your resources by defining lock type either “delete” or “read-only”.


In the Automation script panel, you can view the temple of this deployment and you also get an option for download, add to library and deploy.


In the diagram panel, you get the graphical representation of all the subnets and associated resources.


I hope, this step by step blog post helped you to create your virtual network and subnets in Microsoft Azure. To know more about the networking features such as Gateway subnet, peering etc., read the next blog post.

#Azure : Storage Accounts


Storage is an essential part of anything what you do in your day-to-day life and same applies to technology as well. Microsoft Azure Storage is a managed service provided by Microsoft cloud services. When you use any product or service, availability, resiliency, performance, scalability, durability, pricing, security and delivery play an important role, and here in case of Azure Storage it is all taken care by Microsoft.

Azure Storage provides two type of storage accounts: General Purpose and Blob.

While Azure Storage provides services in the following types:

Blob storage

File storage

Queues storage

Table storage

Disk Storage

Storage accounts and services are tightly integrated with each other. To use any one of the above service, you first create a storage account then you define the storage services based on the storage account type.

First, let understand the Storage accounts by an illustration:

Now, let understand the storage accounts in detail:

General purpose: A general purpose storage account cater all your azure storage services such as Tables, Queues, Files, Blobs and Azure virtual machine disks under a single account. This type of storage account has two performance tiers:

  • Standard storage performance tier: This performance tier fulfills all your data storage needs such as Tables, Queues, Files, Blobs and Azure virtual machine disks. This tier supports block blobs, page blobs and append blobs.
  • Premium storage performance tier: This performance tier is backed by SSDs and provides high performance IOPS, best for virtual machine disks and data intensive applications such as database. This tier supports only page blobs.

Currently, these general-purpose accounts are available in 2 versions.

General purpose v1: It is previous version of storage account and doesn’t provide latest and greatest storage capabilities, which is certainly available with new kind of storage. It also doesn’t provide access tier (Hot and Cold).

General purpose v2: This is a newer version of general purpose v1 storage and provide all the features, which are part of v1 storage. It also provides all the latest features available for blob, files, queues and tables with better performance and pricing. It also supports the access tiering (Hot and Cold) for different needs and performance.

You can upgrade your GPv1 account to GPv2 account, using PowerShell and Azure CLI.

Blob: A blob storage account is mainly to store unstructured data as blob (objects). It also provides access tier (hot and cold) to support different needs and performance. It only supports block blobs and append blobs. It provides only standard performance tier.

Access tiers: Access tiers are supported by General purpose V2 storage account and blob storage account to serve different needs.

  • Hot access tier indicates that the objects in the storage account will be more frequently accessed. This allows you to store data at a lower access cost. Premium storage always falls under this access tier.
  • Cool access tier indicates that the objects in the storage account will be less frequently accessed. This allows you to store data at a lower data storage cost.

#Azure : Map your traditional datacenter compute with cloud VMs


Cloud has completely changed the IT architecture landscape. Since early days of IT till last decade, Architecture was an abstraction that used to play a key role at the time of transformation or new development. Once Architecture developed, it used to continue for many years with very minimal changes. Since cloud came in its inception, architecture has become a key in day to day work life of an IT professional because of its agility. If not daily then most probably weekly, you can observe some changes in the public cloud world and that needs to be taken care seriously.

In this post, I’ll try to simplify the cloud architecture for compute and will compare with traditional compute architecture. Apart from the simplification, I’ll provide you a logical design thinking approach that will make your life easy no matter what role you are playing in IT.

Let start from traditional datacenter.

If you are an experience IT professional, you must have seen or heard about these names at least once in your career.

Traditional type of Servers: Tower, Rack, and Blade servers.

A true traditional server that comes with multiple configuration options such as dual-processor or quad-processor etc.

New type of platforms: Converged and Hyper-Converged.

These new platforms are basically rack based servers that provide inbuilt advanced storage and networking capabilities by leveraging software defined data center technologies.

Virtualization: In last one decade, every organization has leveraged capabilities of virtualization that enable compute to run multiple virtual machines so that you can fully utilize your high-end servers and save cost in multiple aspects.

Now, let me explain complete compute story in public cloud such as Microsoft Azure.

When you look at compute available through cloud, you can easily determine that it is same kind of virtual machines, which we used to have in our virtualized environment. But in the cloud, the only difference is that you don’t worry about the underlying hypervisor and hardware that is being used behind the scene to provide you virtual machines.

In traditional datacenter, we use multiple racks to install different types of hardware and each rack connects with different power supply units through PDUs and these power supply units connect with main power supply unit. In many scenarios each rack deploys top-of-the-rack switches to provide network connectivity to the devices installed in the rack and in some cases one or two of the racks in the same row deploy these TOR switches. To overcome the challenge of entire datacenter failure, we use multiple datacenters in the form of high-availability and site-resiliency. When an administrator performs any maintenance activity in the traditional datacenter, he/she makes sure that the quorum is maintained while performing maintenance activity to avoid any kind of unexpected failures.

In cloud, H/W level high-availability is being provided by fault domain (unexpected) and maintenance level availability is being provided by update domain, and both features fit under one umbrella that i.e. known as availability sets. To provide high availability, Microsoft Azure uses multiple datacenters (at least two-three) in each region, and to support site resiliency Azure provides multiple region options in same geography or across multiple geographies.

I hope, now you will be able to sketch a clear picture in your mind about traditional datacenter vs cloud.

Now, let me help you with the logical design thinking approach. When you think to deploy a VM or set of VMs, follow the following steps in sequential order.

  1. Think about application and its big picture, keep end-users in your mind and their respective locations.
  2. Select the best suitable cloud region.
  3. Consider different tiering of solution.
  4. Consider security, high availability, site resiliency and load balancing requirements.
  5. Illustrate your network requirements.
  6. Illustrate your storage requirements.
  7. Illustrate your compute requirements.

Once documented all the above, create design diagram and find the approach to deploy your solution. For more details specific to Microsoft Azure compute, read the following blogpost.

#Azure : Virtual Machines

#Azure : Virtual Machine Configuration

#Azure : Virtual Machines High Availability

#Azure : Step-by-step Availability Sets

#Azure : Virtual Machines Scale Sets

#Azure : Large Virtual Machines Scale Sets

#Azure : Virtual Machines Scale Sets


Microsoft Azure virtual machines scale sets are a next step in high availability and scalability of virtual machines. Virtual machine high availability can be achieved by availability sets in Microsoft Azure. Microsoft Azure virtual machines scale sets are a group of an identical compute resources deployed in multiple availability sets. It is a true scalable model of auto-scaling that can target large-scale services with big compute, large data and containerized workloads. As these virtual machine scale sets leverage multiple availability sets in the background, therefore scale operations are tacitly balanced across fault and update domains. These scale sets use five fault domains and five update domains in each availability set. Each virtual machine scale sets can host 0-1000 VMs based on platform images, and 0-300 VMs based on custom images.

To define autoscale configuration for consistent application performance, many permutation and combination can be used. Very common rules are compute, memory, and disk I/O utilization. Apart from these common rule of performance metrics, auto scaling of VMs can also depend on application response, or a fixed scheduled.

Note: Virtual Machines scale sets can also be deployed with availability zones.

Now, let me explain you how does this auto scaling works behind the scene. When a new VM added to the scale set, a VM instance Id will be provided to each VM that is unique within a scaleset. When you add or remove a virtual machine from the scale set, the existing Id doesn’t go anywhere. For Example: In a virtual machine scale set you have 10 VMs, if your 2 VMs removed from the scale set based on the configuration and need, and then after some time 5 VMs are added based on the load then new VMs will have Instance id 10, 11, 12, 13, 14 in an incremented manner and these VMs will be balanced across fault and update domains to maintain maximum availability.

Let see how to do it.

Login to the Azure portal and search for “scale” in the azure market place and select the “Virtual machine scale set”.

In the Virtual machine scale set panel, select “Create” to create a new Virtual machine scale set.

In the “create virtual machine scale set” fill the basics information.

Virtual machine scale set name = Enter the scale set name for your virtual machine scale set deployment.

Operating system disk image = Select the operating disk image from drop-down.

Subscription = select your subscription.

Resource group = Create a new resource group or select the existing one.

Location = Select the Azure region from drop-down.

User name = Enter the username that will be used for virtual machines.

Password = Enter the password for the user name.

Confirm password = Re-enter the password to confirm.

Scroll down and fill the required details under “Instances and Load Balancer”.

Instance count = Enter to VMs count between 0 – 100. If you enter any number more than 100 and up to 1000, all the configuration settings will be disabled except instance size. As large-scale sets with more than 100 VMs use managed disk by default and deployment of these large-scale sets take place across multiple placement groups.

Instance size = Select the VM size based on your requirement.

Enable scaling beyond 100 instances = By default “No”, if you select “Yes” then rest of the settings will be disabled as described under instance count.

Use managed disks = By default “Yes”.

Public IP address name = Define name of the public IP address that will be used for load balancer, which will be placed in front of the scale set.

Public IP allocation method = By default dynamic but Static can be selected.

Domain name label = Domain name label for the load balancer in front of the scale set.

Autoscale = By default disabled but if you enable this feature then you need to define the conditions for the auto scaling.

If Autoscale enabled, fill the required details.

Autoscale

Minimum number of VMs = Enter the minimum number of VMs that required in this scale set.

Maximum number of VMs = Enter the maximum number of VMs that required in this scale set.

Scale out

CPU threshold (%) = Enter the cpu threshold after that VM will be added.

Number of VMs to increase by = Enter the number of VMs that will added when your running VMs reach defined cpu threshold.

Scale in

CPU threshold (%) = Enter the cpu threshold after that VM will be removed.

Number of VMs to decrease by = Enter the number of VMs that will removed when your running VMs reach defined cpu threshold.

Once filled all the details, click on create to start the deployment process.

As you observed that in the entire process, virtual network and storage account was not asked anywhere because virtual machine scale sets take care of it behind the scene based on the configuration. Therefore, you don’t have to really worry about it.

#Azure : Step-by-step Availability Sets


In my previous post, I had explained about the high availability configuration for Azure virtual machines, Availability Sets, Fault domains and Update domains. In this blogpost, I’ll cover step-by-step configuration using Azure Portal. Availability Set configuration can be done in two ways, either by creating and configuring it in early stage based on your application architecture or set it up while creating a first VM for each tier and add rest of the same tier VMs to the respective availability set.

I am going to explain, how to create and configure availability set in advance.

Login to the Azure Portal and select “+ Create a resource”.

In the Azure Market Place, search for Availability Set.

From the search results, select “Availability Set”.

In the Availability Set panel, select create.

In the create availability set panel, define the parameters.

Name: Enter the name of the availability set.

Subscription: Select the subscription.

Resource group: Either create a new one or select an existing one based on your requirement.

Location: Select the location.

Fault domains: Select the number of fault domains, by default it is two but for specific Azure regions you can select up to three fault domains.

Update domains: Select the number of update domains, by default it is five but you go up to 20 update domains in each availability sets.

Use managed disks: Select Yes (by default) if you would like to use managed disk for all the VMs that will be create in this availability set otherwise “No”.

Once, you have filled all the details based on your requirement then select “create” to start the deployment of availability sets.

Wait for few seconds, your availability set will be created. Now, you can go head and create your VMs using this availability set.

While creating a virtual machine you get both the options, either select the existing availability set or create a new one.

If you select the “+ Create new” then again you have to fill the same details as filled earlier then select “OK”.

Once you created an availability set, you will not able to modify it and the same concept applies to VM as well. If you have created a VM as part of the availability set then you can’t come out or change the availability set until you delete and recreate it.