Search

Dev Tips Curator

A Quick Overview of #Azure Load Balancer

Azure Load Balancer delivers high availability and network performance to your applications. It is a Layer 4 (TCP, UDP) load balancer that distributes incoming traffic among healthy service instances in Cloud Services or VMs defined in a Load-Balanced Set.

It can be configured to:

  • load balance Incoming Internet Traffic to Virtual Machines (VMs). This is known as Internet-Facing Load Balancing.
  • load balance traffic
    • between VMs in a Virtual Network
    • between VMs in Cloud Services
    • between VMs and On-Premises Computers in a Cross-Premises Virtual Network.  This is known as Internal Load Balancing.
  • forward External Traffic to a specific VM.

All resources in the cloud need a Public IP address to be reachable from the Internet.

The cloud infrastructure in Azure uses non-routable IP addresses for its resources. It uses Network Address Translation (NAT) with Public IP addresses to communicate to the Internet.

Automatic Reconfiguration

The Load Balancer automatically reconfigures itself when you scale instances in or out. For example, this reconfiguration can happen when you increase the instance count for Web/Worker Roles in a Cloud Service or when you add additional VMs into the same Load-Balanced Set.

Support for Multiple Load-Balanced IP Addresses for VMs

You can get more than one load-balanced Public IP address assigned to a set of VMs. With this ability, you can host multiple SSL websites and/or multiple SQL Server AlwaysOn Availability Group listeners on the same set of VMs.
See https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-multivip

Template-Based Deployments through Azure Resource Manager

The Load Balancer can be managed through Azure Resource Manager-based APIs and tools.

For more information:

Advertisements

What is #AzureCosmosDB | #Azure #Database

Imagine a horizontally scalable database that puts data everywhere your users are.

Azure Cosmos DB is the first globally-distributed, multi-model database service for building “planet scale” apps. It lets you elastically scale storage and throughput across any number of geographical regions while guaranteeing low latency, high availability and consistency – backed by the most comprehensive SLAs in the industry.

Azure Cosmos DB started as “Project Florence” in 2010 to address developer the pain-points faced by large scale applications inside Microsoft. Observing that the challenges of building globally distributed apps are not a problem unique to Microsoft, in 2015 Microsoft made the first generation of this technology available to Azure developers in the form of Azure DocumentDB. Since that time, Microsoft has added new features and introduced significant new capabilities. Azure Cosmos DB is the result. It is the next big leap in globally distributed, at scale, cloud databases. As a part of this release of Azure Cosmos DB, DocumentDB customers, with their data, are automatically Azure Cosmos DB customers. The transition is seamless and they now have access to the new breakthrough system and capabilities offered by Azure Cosmos DB.

Azure Cosmos DB is a schema-agnostic database which automatically indexes all your data so you can perform blazing fast queries. Since no data is born relational, the multi-model and multi-API capabilities remove the friction, allowing you to build with any data model and API. While most database services force you to choose between strong or eventual consistency, Azure Cosmos DB provides multiple well-defined, intuitive consistency choices — so you can select just the right one for your app.

Azure Cosmos DB provides guarantees and comprehensive SLAs such as:

  • High Availability
  • Consistency Levels
  • Throughput
  • Guaranteed low latency at 99th percentile

Azure Cosmos DB has been powering Microsoft’s internet-scale services for years, and it is now available to the general public.

To learn more about Azure Cosmos DB, go to https://www.azure.com/cosmosDB.

A Quick Overview of #Azure Data Lake

Azure Data Lake is a family of Azure services that enables you to analyze your Big Data workloads in a managed manner.

azure-data-lake

Azure Data Lake is a batch, real-time, interactive data analysis tool which makes it easy for developers, data scientists, and analysts to store data of any size, shape and speed, and do all types of processing and analytics across platforms and languages.

It consists of these services:

Service Description
Azure Data Lake Store A data repository that enables you to store any type of data in its raw format without defining schema. The store offers unlimited storage with immediate read/write access to it and scaling the throughput you need for your workloads. The store is Hadoop Data File System (HDFS) compatible so you can use your existing tools.
Azure Data Lake Analytics An analytics service that allows you to run analysis jobs on data. Analytics using Apache YARN to manage its resources for the processing engine. By using U-SQL, you can process data from several data sources such as Azure Data Lake Store, Azure Blob Storage, and Azure SQL Database but also from other data stores built on HDFS.
Azure HDInsight An analytics service that enables you to analyze data sets on a managed cluster running open-source technologies such as Hadoop, Spark, Storm & HBase.

A Quick Overview of #Azure Cloud App Discovery

IT administrators are often unaware of the various cloud applications that members of their organization use to do their day-to-day work.  Understandably, this poses concerns surrounding security risks such as unauthorized access to corporate data and possible data leakage. This lack of awareness can further jeopardize the ability to formulate a plan to address these security risks.

Fortunately, a feature of Azure Active Directory (AAD) Premium called Cloud App Discovery can alleviate these concerns.

With Cloud App Discovery, you can:

  • Find the cloud applications being used and measure that usage by number of users, volume of traffic or number of web requests to the application
  • Identify the users that are using an application
  • Export data for offline analysis
  • Bring these applications under IT control and enable Single Sign-On (SSO) for user management

How it works

CloudAppDiscovery

  1. Application usage agents are installed on user’s computers to collect data from machines and devices.
  2. The application usage information captured by the agents is sent over a secure, encrypted channel to the Cloud App Discovery service.
  3. The Cloud App Discovery service evaluates the data and generates reports on the dashboard.

For more information, please see Getting Started with Cloud App Discovery.

#Azure Active Directory Editions Demystified

Azure Active Directory (Azure AD) comes in 4 editions:

  1. Free
  2. Basic
  3. Premium P1
  4. Premium P2
FREE BASIC PREMIUM P1 PREMIUM P2
Common Features
Directory Objects 500,000 Object Limit No Object Limit No Object Limit No Object Limit
User/Group Management (add/update/delete)/ User-based provisioning, Device registration  Yes  Yes  Yes  Yes
Single Sign-On (SSO) 10 apps per user (pre-integrated SaaS and developer-integrated apps) 10 apps per user (free tier + Application proxy apps) No Limit (free, Basic tiers +Self-Service App Integration templates) No Limit (free, Basic tiers +Self-Service App Integration templates)
B2B Collaboration  Yes  Yes  Yes  Yes
Self-Service Password Change for cloud users  Yes  Yes  Yes  Yes
Connect (Sync engine that extends on-premises directories to Azure Active Directory)  Yes  Yes  Yes  Yes
Security/Usage Reports 3 Basic Reports 3 Basic Reports Advanced Reports Advanced Reports
Premium + Basic Features
Group-based access management/provisioning  Yes  Yes  Yes
Self-Service Password Reset for cloud users  Yes  Yes  Yes
Company Branding (Logon Pages/Access Panel customization)  Yes  Yes  Yes
Application Proxy  Yes  Yes  Yes
SLA  Yes  Yes  Yes
Premium Features
Self-Service Group and app Management/Self-Service application additions/ Dynamic Groups  Yes  Yes
Self-Service Password Reset/Change/Unlock with on-premises writeback  Yes  Yes
Device objects two-way synchronization between on-premises directories and Azure AD (Device write-back)  Yes  Yes
Multi-Factor Authentication (Cloud and On-premises (MFA Server))  Yes  Yes
Microsoft Identity Manager user CAL  Yes  Yes
Cloud App Discovery  Yes  Yes
Connect Health  Yes  Yes
Automatic password rollover for group accounts  Yes  Yes
Conditional Access based on group and location  Yes  Yes
Conditional Access based on device state (Allow access from managed devices)  Yes  Yes
Identity Protection  Yes
Privileged Identity Management  Yes
Azure Active Directory Join – Windows 10 only features
Join a device to Azure AD, Desktop SSO, Windows Hello for Azure AD, Administrator Bitlocker recovery  Yes  Yes  Yes  Yes
MDM auto-enrollment, Self-Service Bitlocker recovery, Additional local administrators to Windows 10 devices via Azure AD Join, Enterprise State Roaming  Yes  Yes

#Azure #Networking – Quick Glossary

Application Gateway

Application Gateways provide load-balanced solutions for network traffic that is based on the HTTP protocol. They use routing rules as application-level policies that can offload Secure Sockets Layer (SSL) processing from load-balanced Virtual Machines (VMs). In addition, you can use Application Gateways for a cookie-based session affinity scenario.

Cross-Premises Network Connectivity

Azure Virtual Network (VNet) enables you to extend your on-premises networks to the cloud.

To extend your on-premises network, you can either:

  1. Create a Virtual Private Network (VPN) between your on-premises computers/networks and an Azure VNet, or
  2. Use ExpressRoute to provide a connection to an Azure VNet that does not cross the Internet.

Using these two methods, you can enable on-premises users to access Azure services as if they were physically located on-premises in your own datacenter.

To connect to an Azure VNet from an on-premises network, you can use:

  • Point-To-Site (P2S) VPN
  • Site-To-Site (S2S) VPN
  • ExpressRoute
  • VNet-to-VNet VPN

DNS

The Domain Name System (DNS) enables clients to resolve user-friendly Fully Qualified Domain Names (FQDNs), such as http://www.microsoft.com, to IP addresses.

Azure provides a DNS system to support many name resolution scenarios. However, in some cases, such as hybrid connection you will need to configure an external DNS system to provide name resolution for VMs on a VNet.

You should also ALWAYS use Static IP Addresses for DNS Servers.

Forced Tunneling

With Forced Tunneling you can redirect internet bound traffic back to the company’s on-premises infrastructure. Forced tunneling is commonly used in scenario where organizations want to implement packet inspection or corporate audit.

IP Addresses

VMs, Load Balancers, and Application Gateways in a single VNet require unique IP addresses in the same way as clients in an on-premises subnet do. This enables these resources to communicate with each other.

There are 2 types of IP addresses that are used in a VNet:

Private IP addresses

A Private IP address is allocated to a VM dynamically or statically from the defined scope of IP addresses in the VNet. The default allocation method is dynamic. This address is used by VMs in the VNet to communicate with other VMs in the same VNet connected VNets/networks through a Gateway/ExpressRoute connection.

Public IP addresses

Public IP addresses allow Azure resources to communicate with external clients, and are assigned directly at the virtual Network Interface Card (NIC) of the VM or to the Load Balancer.

Load Balancer

To increase availability and scalability, you can create two or more VMs that publish the same application.

For example, if three VMs host the same website, you might want to distribute incoming traffic between them and ensure that if one VM fails, traffic is distributed automatically to the other two.

You can use an Azure Load Balancer to enable this traffic distribution between VMs. In this configuration, a single endpoint is shared between multiple VMs. The Azure Load Balancer automatically distributes requests across those VMs as the requests arrive at the endpoint.

You can use 2 types of Azure Load Balancers:

Internal Load Balancer

The Internal Load Balancer enables you to load balance traffic between VMs in the same cloud service (for classic model), or between VMs and a VNet with a Regional scope, where the input IP address of the load balancer is a Private IP address.

Internet-Facing (Public) Load Balancer

The Internet-Facing load Balancer enables you to load balance incoming Internet traffic to VMs.

Network Interface Card (NIC)

VMs communicate with other VMs and other resources on the network by using Virtual Network Interface Cards (NICs).

Virtual NICs configure VMs with private and optional public IP address. VMs can have more than one NIC for different network configurations.

Network Security Groups (NSG)

You can use Network Security Groups (NSG) to provide network isolation for Azure resources by defining rules that can allow/deny specific traffic to individual VMs or subnets. This enables you to design your Azure VNet to provide a network experience that is similar to an on-premises network. You can achieve the same functionality in your Azure VNet as you would in the on-premises networks, such as Perimeter Networks (also known as DMZ or Demilitarized Zone).

Regional Virtual Networks

Azure VNet is bound to Azure subscriptions and it is not possible for multiple subscriptions to use the same Azure VNet.

If you need to provide communications between different Azure subscriptions, you need to create separate Azure VNets in each subscription and then use Site-To-Site VPN or ExpressRoute, to connect them.

All new VNets are Regional Virtual Networks. This means that they can span a complete Azure region or datacenter. This differs from the legacy implementation of VNets in Azure, which were restricted to a single Affinity Group, allowing you to co-locate VNets, Storage Accounts, and services in the physical proximity to each other within the same area of a single datacenter.

If you have older VNets in your subscription, these could be tied to an Affinity Group. However, over time, you need to migrate all VNets to Regional Virtual Networks and remove their ties to specific Affinity Groups.

Subnets

You can further divide your network by using Subnets for logical and security isolation of Azure resources. Each Subnet contains a range of IP addresses that fall within the VNet address space.

Traffic Manager

Azure Traffic Manager is another load-balancing solution that is included within Azure. You can use Traffic Manager to load balance between endpoints that are located in different Azure regions, at hosted providers, or in on-premises datacenters. These endpoints can include Azure VMs and Azure websites. You can configure this load-balancing service to support priority or to ensure that users connect to an endpoint that is close to their physical location for faster response.

User Defined Routes (UDR)

User Defined Routes (UDR) control network traffic by defining routes that specify the next hop of the traffic flow. You can assign UDR to VNet subnets.

Virtual Network (VNet)

Azure Virtual Network (VNet) is a fundamental component that acts as an organization’s network in Azure. Organizations can use VNets to connect resources. Azure VNets are network overlays that you can use to configure and control connectivity between Azure resources such as VMs and Load Balancers.

Which #Linux Distributions are supported on #Azure?

The following table lists the Linux distributions and versions that are endorsed by Azure:

Distribution Version Drivers Agent
CentOS CentOS 6.3+, 7.0+ CentOS 6.3: LIS download

CentOS 6.4+: In kernel

Package: In repo under “WALinuxAgent”
Source code: GitHub
CoreOS 494.4.0+ In kernel Source code: GitHub
Debian Debian 7.9+, 8.2+ In kernel Package: In repo under “waagent”
Source code: GitHub
openSUSE openSUSE Leap 42.1+ In kernel Package: In Cloud:Tools repo under “python-azure-agent”
Source code: GitHub
Oracle Linux 6.4+, 7.0+ In kernel Package: In repo under “WALinuxAgent”
Source code: GitHub
Red Hat Enterprise Linux RHEL 6.7+, 7.1+ In kernel Package: In repo under “WALinuxAgent”
Source code: GitHub
SUSE Linux Enterprise SLES/SLES for SAP
11 SP4
12 SP1+
In kernel Package:

for 11 in Cloud:Tools repo
for 12 included in “Public Cloud” Module under “python-azure-agent”
Source code: GitHub

Ubuntu Ubuntu 12.04, 14.04, 16.04, 16.10 In kernel Package: In repo under “walinuxagent”
Source code: GitHub

 

Please refer to Support for Linux and open source technology in Azure for more detailed information.

#Azure VM Sizes and Series Demystified

The sheer number of Azure Virtual Machine (VM) series and size options can be overwhelming to some Azure practitioners.  In a nutshell, Azure VM sizes consist of the following series:

Series Description
A-series Entry-level Economical VMs for Dev/Test
D-series General Purpose Compute
F-series Compute Optimized Virtual Machines
G-series Memory and Storage Optimized Virtual Machines
H-series High Performance Virtual Machines
L-series Storage Optimized Virtual Machines
N-series GPU enabled Virtual Machines

 

You can configure your VMs with a variety of options for memory, CPU, and IOPS.

Note: You can easily resize your VM in Azure as your requirements change in the future.

Here is a helpful chart for determining which sizes to choose when configuring your VMs:

Type Sizes Description
General purpose A0-7, Av2, D, Dv2, DS, DSv2 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.
Compute optimized F, Fs High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers.
Memory optimized DS, DSv2, G, GS High memory-to-core ratio. Great for relational database servers, medium to large caches, and in-memory analytics.
Storage optimized Ls High disk throughput and IO. Ideal for Big Data, SQL, and NoSQL databases.
GPU NC, NV Specialized virtual machines targeted for heavy graphic rendering and video editing. Available with single or multiple GPUs.
High performance compute A8-11, H The fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).

How to Show a Modal Message Box UI in #PowerShell

Here is a generic PowerShell MsgBox function that you can add to your scripts for displaying a modal message box UI. Only 2 lines of code!

Function MsgBox($Message, $Title)
{
   [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.VisualBasic")
   [Microsoft.VisualBasic.Interaction]::MsgBox($Message, "SystemModal,Information", $Title)
}

MsgBox "This is my modal message box demo." "My Modal Message Box"

Here is the result:

ModalMsgBox

 

Create a website or blog at WordPress.com

Up ↑