SecureTransport 5.4 on Azure Installation Guide Save PDF Selected topic Selected topic and subtopics All content SecureTransport in Azure Virtual Network Currently, deployment of SecureTransport on Azure VNet has been verified for Red Hat 7.2 only in the following setup: Enterprise Cluster of two servers with streaming to Standard Cluster of two edges Microsoft SQL Server 2016 GlusterFS file system with two servers A Load Balancer (optional) An Administration Host (optional) Two private and one public subnets A VPN Connection (optional) Instances are assigned to five Network security groups (NSG) All this grouped in three Availability Sets Azure operates in multiple datacenters around the world. These datacenters are grouped in to geographic regions, giving you flexibility in choosing where to build your applications. To provide additional scalability and reliability, these data center facilities are distributed in different physical locations, categorized by regions and Availability Sets. You create Azure resources in defined geographic regions. Within each region, multiple datacenters exist to provide for redundancy and availability. This approach gives you flexibility as you design applications to create VMs closest to your users and to meet any legal, compliance, or tax purposes. An availability set is a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. We recommended that two or more VMs are created within an availability set to provide for a highly available application. The availability set is composed of two additional groupings that protect against hardware failures and allow updates to safely be applied - fault domains (FDs) and update domains (UDs). A fault domain is a logical group of underlying hardware that share a common power source and network switch, similar to a rack within an on-premises datacenter. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions. An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these update domains. This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. The following diagram represents the location and distribution of instances in the availability sets. The goal is to provide a highly-available, fault-tolerant and secure setup of SecureTransport in the Microsoft Azure Cloud. The diagram illustrates a SecureTransport setup of an Enterprise Cluster in streaming mode with two Edge servers joined in a Standard Cluster. Microsoft SQL Server installed on a Virtual Machine is used as a database engine. The setup contains one public and two private subnets. The public subnet hosts the SecureTransport Edges that are grouped in an Availability Set and the Administration Host. The first private subnet hosts the SecureTransport Servers Availability Set and the external file system Availability Set. The database instance is located in a separate private subnet. The Edge servers are in a Standard cluster setup and are in a constant synchronization connection. The SecureTransport servers are in an Enterprise Cluster setup and in a constant synchronization connection as well. The SecureTransport servers are connected in streaming with the Edge servers as each server establishes streaming connections with both Edge servers. Internet-facing load balancer distributes requests among the Edge servers in the Edge Availability Set. In case of a system failure in one of the machines in an Availability Set, the other machine remains fully functional with up to date system configuration. The public subnets in the Azure Cloud are the equivalent of the DMZ (demilitarized zone) in a classic on-premise SecureTransport deployment. The Azure cloud provides security tools like Network Security Groups to protect the public and private subnets in your VNet. These tools act as the firewalls do in the classic SecureTransport on-premise deployments and control both inbound and outbound traffic at an instance and subnet level. Each group (Administration host, Edge servers, Servers, File System, Database) has a corresponding Network Security Group. The Network Security Group is a stateful firewall that works on VM or Subnet level. There is a host placed in one of the public subnets called "Administration host" also known as "Bastion host" or “Jump host” in the networking terminology. Bastion hosts are instances that typically reside within your public subnet and are usually accessed using SSH or RDP. Once remote connectivity is established with the bastion host, it then acts as a jump server, allowing you to use SSH or RDP to log in to other instances publicly inaccessible deeper within your network. When properly configured through the use of security groups, the bastion host essentially acts as a bridge to your private instances via the Internet. The Administration host is used to perform maintenance and administration tasks on the servers in the SecureTransport setup. You should always consider the resiliency and high availability of your services in cloud deployments and the best practice is to have an Availability set of Administration hosts in case one of the hosts goes down. For minimal security risks, you should stop your Administration host instances for the duration of no maintenance work and start them when you need access to your servers in Azure again. You can connect directly to your VNet using a Point-to-Site connection in case you don't want to have an Administration host in your setup (see Configure a Point-to-Site connection to your VNet section in this guide). The installation of SecureTransport on Red Hat instances in Microsoft Azure cloud follows a flow which is the same as that of an installation on a regular Red Hat machine, including the required installation prerequisites. This process is already described in the SecureTransport Installation Guide. You will pass through several Azure cloud specific setup and configuration stages until you until you are able to proceed with your SecureTransport installation. To set up SecureTransport in Azure Virtual Network, you must pass through the following steps: Create a Virtual Network. Create Availability Sets. Create Network Security Groups. Create one public and two private subnets. Set up Microsoft SQL Server. Launch the following Red Hat instances:Launch an instance for an Administration Host.Launch instances in the public subnets for SecureTransport Edge installations.Launch instances in the private subnets for SecureTransport Server installations.Launch instances in the private subnets for external GlusterFS file system. Establish VPN connection to your Azure VNet. Set up SecureTransport Enterprise Cluster. Set up Load Balancer. Related Links
SecureTransport in Azure Virtual Network Currently, deployment of SecureTransport on Azure VNet has been verified for Red Hat 7.2 only in the following setup: Enterprise Cluster of two servers with streaming to Standard Cluster of two edges Microsoft SQL Server 2016 GlusterFS file system with two servers A Load Balancer (optional) An Administration Host (optional) Two private and one public subnets A VPN Connection (optional) Instances are assigned to five Network security groups (NSG) All this grouped in three Availability Sets Azure operates in multiple datacenters around the world. These datacenters are grouped in to geographic regions, giving you flexibility in choosing where to build your applications. To provide additional scalability and reliability, these data center facilities are distributed in different physical locations, categorized by regions and Availability Sets. You create Azure resources in defined geographic regions. Within each region, multiple datacenters exist to provide for redundancy and availability. This approach gives you flexibility as you design applications to create VMs closest to your users and to meet any legal, compliance, or tax purposes. An availability set is a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. We recommended that two or more VMs are created within an availability set to provide for a highly available application. The availability set is composed of two additional groupings that protect against hardware failures and allow updates to safely be applied - fault domains (FDs) and update domains (UDs). A fault domain is a logical group of underlying hardware that share a common power source and network switch, similar to a rack within an on-premises datacenter. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions. An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these update domains. This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. The following diagram represents the location and distribution of instances in the availability sets. The goal is to provide a highly-available, fault-tolerant and secure setup of SecureTransport in the Microsoft Azure Cloud. The diagram illustrates a SecureTransport setup of an Enterprise Cluster in streaming mode with two Edge servers joined in a Standard Cluster. Microsoft SQL Server installed on a Virtual Machine is used as a database engine. The setup contains one public and two private subnets. The public subnet hosts the SecureTransport Edges that are grouped in an Availability Set and the Administration Host. The first private subnet hosts the SecureTransport Servers Availability Set and the external file system Availability Set. The database instance is located in a separate private subnet. The Edge servers are in a Standard cluster setup and are in a constant synchronization connection. The SecureTransport servers are in an Enterprise Cluster setup and in a constant synchronization connection as well. The SecureTransport servers are connected in streaming with the Edge servers as each server establishes streaming connections with both Edge servers. Internet-facing load balancer distributes requests among the Edge servers in the Edge Availability Set. In case of a system failure in one of the machines in an Availability Set, the other machine remains fully functional with up to date system configuration. The public subnets in the Azure Cloud are the equivalent of the DMZ (demilitarized zone) in a classic on-premise SecureTransport deployment. The Azure cloud provides security tools like Network Security Groups to protect the public and private subnets in your VNet. These tools act as the firewalls do in the classic SecureTransport on-premise deployments and control both inbound and outbound traffic at an instance and subnet level. Each group (Administration host, Edge servers, Servers, File System, Database) has a corresponding Network Security Group. The Network Security Group is a stateful firewall that works on VM or Subnet level. There is a host placed in one of the public subnets called "Administration host" also known as "Bastion host" or “Jump host” in the networking terminology. Bastion hosts are instances that typically reside within your public subnet and are usually accessed using SSH or RDP. Once remote connectivity is established with the bastion host, it then acts as a jump server, allowing you to use SSH or RDP to log in to other instances publicly inaccessible deeper within your network. When properly configured through the use of security groups, the bastion host essentially acts as a bridge to your private instances via the Internet. The Administration host is used to perform maintenance and administration tasks on the servers in the SecureTransport setup. You should always consider the resiliency and high availability of your services in cloud deployments and the best practice is to have an Availability set of Administration hosts in case one of the hosts goes down. For minimal security risks, you should stop your Administration host instances for the duration of no maintenance work and start them when you need access to your servers in Azure again. You can connect directly to your VNet using a Point-to-Site connection in case you don't want to have an Administration host in your setup (see Configure a Point-to-Site connection to your VNet section in this guide). The installation of SecureTransport on Red Hat instances in Microsoft Azure cloud follows a flow which is the same as that of an installation on a regular Red Hat machine, including the required installation prerequisites. This process is already described in the SecureTransport Installation Guide. You will pass through several Azure cloud specific setup and configuration stages until you until you are able to proceed with your SecureTransport installation. To set up SecureTransport in Azure Virtual Network, you must pass through the following steps: Create a Virtual Network. Create Availability Sets. Create Network Security Groups. Create one public and two private subnets. Set up Microsoft SQL Server. Launch the following Red Hat instances:Launch an instance for an Administration Host.Launch instances in the public subnets for SecureTransport Edge installations.Launch instances in the private subnets for SecureTransport Server installations.Launch instances in the private subnets for external GlusterFS file system. Establish VPN connection to your Azure VNet. Set up SecureTransport Enterprise Cluster. Set up Load Balancer.