Skip to main content

Linux on Azure


Linux on Azure
Microsoft Endorsed some versions of Linux in the Azure Marketplace in which,
·         The Linux Integration Services (LIS) drivers for Hyper-V and Azure are kernel modules that are contributed directly from MS to the upstream Linux kernel.
·         The Azure Linux Agent is already pre-installed and the source code can be found on GitHub.
For Non-Endorsed Versions of Linux
  • You can bring your own Linux image by Creating and uploading a virtual hard disk that contains the Linux OS.
Endorsed distributions - Linux
Azure SLAs applies only to the Endorsed versions
  • CentOS 6.3+
  • CoreOS 494.4.0+
  • Debian 7.9+, 8.2+
  • Oracle Linux 6.4+, 7.0+
  • RHEL 6.7+, 7.1+
  • SLES 11, SLES 12+, SLES for SAP11.3+
  • Open SUSE 13.2+
  • Ubuntu 12.04, 14.04, 16.04
Accessing of Linux VMs
Once the Linux VMs are created, it is required to access the VM.
Here are the few ways to access the VMs,
  • Azure Cloud Shell (CLI)
  • Bash Shell from Windows 10
  • Putty software
To use Linux VMs using Windows OS, we need to install Bash Shell

Managing Azure Virtual Machines
Once the VM is created, the following components must be configured to provide consistency and high availability.
  • IP Addresses
  • Availability Set
  • Auto Scaling

IP address is assigned to Azure resources to communicate with other Azure resources, on-premises network, and the Internet. It can be allocated in two ways,
  • Static Allocation
  • Dynamic Allocation
Types of IP Addresses
  • Public IP addresses - Used for communication with the Internet, including Azure public-facing services.
E.g.: VMs, Internet-facing LB, VPN GW, and Application GW.
  • Private IP addresses - Used for communication within an Azure virtual network (VNet), and on-premises network when a VPN is configured.
E.g.: VMs, Internal LB, and Application GW.
Dynamic allocation is the default method for both Private and Public IP Addresses.
Public IP Allocation
Dynamic allocation method:
  • The public IP address is allocated when you start/create the associated resource (like a VM or load balancer).
  • The IP address is released when you stop/delete the resource.
In this method IP address can change.
Static allocation method:
  • The IP address must be configured in "NIC" properties for the associated resource.
  • It is released only when you delete the resource or change its allocation method to dynamic.
In this method IP address will not change.
Private IP Addresses
Private IP Addresses
·         In both (dynamic or static) ways, the IP address is allocated from the address range of the subnet to which the resource is attached.
·         In Dynamic allocation method the IP address is automatically allocated from the resource's subnet (using DHCP). This IP address can change when the resource is stopped and started.
·         In Static allocation method, the IP address must be assigned from the allocated subnet and remains the unchanged till the VM is deleted.


Availability of Azure Virtual Machines
https://technorhythms9.blogspot.com/2020/05/availability-of-azure-virtual-machines.html


Comments

Popular posts from this blog

Troubleshooting transient connection errors to Azure SQL Database

Troubleshooting transient connection errors to Azure SQL Database Dear friends, I'm Yogesh. At my work place, I have faced these type of issues at times.  Let us understand what is this transient error?  A transient error has an underlying cause that soon resolves itself. It causes occasionally is when the Azure system quickly shifts hardware resources to better load-balance various workloads. Most of these reconfiguration events finish in less than 60 seconds.  During this reconfiguration time span, you might have connectivity issues to SQL Database.  To handle them, implement retry logic in their code instead of surfacing them to users as application errors. If your client program uses ADO.NET, your program is told about the transient error by the throw of  SqlException . What is the solution? Can Retry logic works? When your program communicates with SQL Database through third-party middleware, ask the vendor whether the middle ware contains retry logic for tr

Geo-Replication in SQL Azure Database

Geo-Replication in SQL Azure Database Geo-Replication  is one of the Azure SQL features which allows making 3 readable replicas to your database in same or different data centers. Geo-Replication option is available for all databases and service tiers in all region. If it is enabled, the application initiates to a secondary database. we will review how to set up Geo-Replication on Azure SQL databases. Geo-Replication is an Azure SQL database feature that allows you to create a readable secondary database in the same region or cross-region. We can failover to the secondary database in case of an outage for a long time on the primary database server. We can also use this feature to migrate a database from one server to another server in the same or cross region with minimal downtime. Geo-replication uses the Always-on feature to replicate committed transactions to the secondary database asynchronously. Select the database, Click on 'Geo Replication' in left hand

DTU and eDTU in Azure SQL

DTU and eDTU in Azure SQL The performance of SQL Database is based on DTU. According to Microsoft, a DTU is a unit of measure of the resources that are guaranteed to be available to a single Azure SQL Database at a specific performance level within a single database tier. A DTU combines CPU, memory, data I/O, and transaction I/O. Databases can be placed into an  elastic pool  on a SQL Database server that shares a pool of resources among those databases. The shared pool of resources are measured by  elastic Database transition units (eDTU) . The advantages of an elastic pool are: They are scaled automatically. They provide predictable costs. They are widely used for  varying  and  unpredictable usage patterns . Determining DTUs for Workloads ·          If you are planning to move your on-premises Databases to Azure SQL Database, Azure provides a  DTU Calculator  to find the approximate DTUs required for setting up the database. ·