Designing Networks

 Designing Networks


The Professional Cloud Architect


Virtual Private Clouds


VPCs are like a network in a data center; they are network-based organizational structures for controlling access to GCP resources. VPCs organize Compute Engine instances, App Engine Flexible instances, and GKE clusters. They are global resources, so a single VPC can span multiple regions.


A VPC is associated with a project or an organization, and projects can have multiple VPCs. Resources within a VPC can communicate with other resources in the same VPC, subject to firewall rules. Resources can also communicate with Google APIs and services.


VPC Subnets

A VPC can have subnets in each region in order to provide private addresses to

resources in the region. Since the subnets are part of a larger network, they must have distinct IP address ranges.


 For example, a VPC with three subnets might use the ranges 10.140.10.0/20, 10.140.20.0/20, and 10.140.30.0/20 for the subnets. When a VPC is created, it can automatically create subnets in each region, or you can specify custom subnet definitions for each region that should have a subnet. If subnets are created automatically, their IP ranges are based on the region. All automatic subnets are assigned IP addresses in the 10.nnn.0.0/20 range.


A subnetwork or subnet is a logical subdivision of an IP network. The practice of dividing a network into two or more networks is called subnetting. Computers that belong to a subnet are addressed with an identical most-significant bit-group in their IP addresses

Subnetting divides broadcast domains, meaning that traffic is routed efficiently, improving speed and network performance. A subnet mask ensures that traffic remains within its designated subnet. This reduces major congestion and reduces the load imparted on the network.


Common advantages of subnetting include enhancing routing efficiency, network management control, and improving network security.


VPCs use routes to determine how to route traffic within the VPC and across subnets. Depending on the configuration of the VPC, the VPC can learn regional routes only or multiregional, global routes.


Shared VPC

Sometimes, it is necessary for resources in different projects to communicate. For example, a data warehouse project may need to access a transactional database in an e-commerce project in order to load e-commerce data into the data warehouse.


For organizational reasons, it may be preferable to keep the e-commerce and data warehouse systems in separate projects. Another advantage of Shared VPCs is that you can separate project and network management duties.


 For example, some administrators may be given privileges to manage network resources, such as firewall rules, while others are given privileges to manage

project resources, like instances.


One way to allow traffic to flow between instances in each VPC is to use a Shared VPC. Shared VPCs are comprised of a host project and one or more service projects. The host project contains one or more Shared VPC networks. When a VPC is made a Shared VPC, all of the existing subnetworks become Shared VPC subnets. Service projects are attached to the host project at the project level.


VPC Network Peering

VPC network peering enables different VPC networks to communicate using private IP address space, as defined in RFC 1918. VPC network peering is used as an alternative to using external IP addresses or using VPNs to link networks.

The following are three primary advantages of VPC network peering:


■ There is lower latency because the traffic stays on the Google network and is not subject to conditions on the public Internet.


■ Services in the VPC are inaccessible from the public Internet, reducing the attack surface of the organization.


■ There are no egress charges associated with traffic when using VPC network peering.


It is important to note that peered networks manage their own resources, such as firewall rules and routes. This is different from firewall rules and routes in a VPC, which are associated with the entire VPC. Also, there is a maximum of 25 peering connections from a single VPC.


It is important to note that VPC peering can connect VPCs between organizations; VPC sharing does not operate between organizations.


Firewall Rules

Firewall rules control network traffic by blocking or allowing traffic into (ingress) or out of (egress) a network. Two implied firewall rules are defined with VPCs: one blocks all incoming traffic, and the other allows all outgoing traffic. You can change this behavior by defining firewall rules with higher priority. 


Firewall

In computing, a firewall is a network security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules. A firewall typically establishes a barrier between a trusted network and an untrusted network, such as the Internet.

Firewall rules have a priority specified by an integer from 0 to 65535, with 0 being the highest priority and 65535 being the lowest. The two implied firewall rules have an implied priority of 65535, so you can override those by specifying a priority of less than 65535.


In addition to the two implied rules, which cannot be deleted, there are four default

rules assigned to the default network in a VPC. 


These rules are as follows:


Default-allow-internal allows ingress connections for all protocols and ports among instances in the network.


Default-allow-ssh allows ingress connections on TCP port 22 from any source to any instance in the network. This allows users to ssh into Linux servers.


Default-allow-rdp allows ingress connections on TCP port 3389 from any source to

any instance in the network. This lets users use Remote Desktop Protocol (RDP) developed by Microsoft to access Windows servers.


Default-allow-icmp allows ingress ICMP traffic from any source to any instance in

the network.


All of these rules have a priority of 65534, the second-lowest priority.

Firewall rules have several attributes in addition to priority. 


They are as follows:


The direction of traffic. This is either ingress or egress.

The action. This is either allow or deny traffic.

The target. This defines the instances to which the rule applies.

The source. This is for ingress rules or the destination for egress rules.

A protocol specification. This includes TCP, UDP, or ICMP, for example.

A port number. A communication endpoint associated with a process.

An enforcement status. This allows network administrators to disable a rule without having to delete it.


Firewall rules are global resources that are assigned to VPCs, so they apply to all VPC subnets in all regions. Since they are global resources, they can be used to control traffic between regions in a VPC.


IP Addressing and CIDR Blocks

Architects are expected to understand IP addresses and classless inter-domain routing (CIDR) block notation. IP addresses can be specified using either IPv4 or IPv6. IPv4 uses four octets, such as 192.168.20.10. IPv6 uses eight 16-bit blocks, such as FE80:0000:0000: 0000:0202:B3FF:FE1E:8329. For the purposes of the exam, understanding IPv4 addressing should be sufficient.


CIDR, which stands for Classless Inter-Domain Routing, is an IP addressing scheme that improves the allocation of IP addresses. It replaces the old system based on classes A, B, and C. This scheme also helped greatly extend the life of IPv4 as well as slow the growth of routing tables.


When you create a subnet, you will have to specify a range of IP addresses. Any resource that needs an IP address on that subnet will receive an IP address in that range. Each subnet in a VPC should have distinct, non-overlapping IP ranges.


You can specify an IP range using the CIDR notation. This consists of an IPv4 IP

address followed by a /, followed by an integer. The integer specifies the number of bits used to identify the subnet; the remaining bits are used to determine the host address.


For example, if you specified 172.16.0.0/12, this would mean that the first 12 bits of the IP address specify the subnet. This is called the subnet mask. The remaining 20 bits are used for host addresses. Since there are 20 bits available, there can be 1,048,574 IP addresses in that range.


GCP users have a few options for linking their GCP networks to external networks,

such as an on-premise data center network.




Hybrid-Cloud Networking


Hybrid-cloud networking is the practice of providing network services between an on premise data center and a cloud. When two or more public clouds are linked together, that is called a multicloud network.


 Multicloud networks may also include private data centers.

Typically, architects recommend hybrid-cloud or multicloud environments when there are workloads that are especially well suited to run in one environment over another or when they are trying to mitigate the risk of dependency on a particular cloud service.


Here are some examples:


■ A batch processing job that uses a custom legacy application designed for a mainframe is probably best run on-premises.

■ Ad hoc batch processing, such as transforming a large number of image files to a new format, is a good candidate for a cloud computing environment, especially when low-cost preemptible VMs are available.

■ An enterprise data warehouse that is anticipated to grow well into petabyte scale is well suited to run in a cloud service such as BigQuery.


Hybrid-Cloud Design Considerations

When workloads are run in different environments, there is a need for reliable networking with adequate capacity. A data warehouse in the cloud may use cloud and on-premises data sources, in which case the network between the on-premises data center and GCP should have sufficient throughput to transfer data for transformation and load operations performed in the cloud.


In addition to throughput, architects need to consider latency. When running batch processing workflow, latency is less of an issue than when running applications that depend on services in the cloud and in a local data center.




A web application running GCP may need to call an application programming interface (API) function running on premises to evaluate some business logic that is implemented in a COBOL application running on a mainframe. In this case, the time to execute the function and the round-trip time transmitting data must be low enough to meet the web application’s SLAs.


Reliability is also a concern for hybrid-cloud networking. A single network interconnect can become a single point of failure. Using multiple interconnects, preferably from different providers, can reduce the risk of losing internetwork communications. If the cost of maintaining two interconnects is prohibitive, an organization could use a VPN that runs over the public Internet as a backup. VPNs do not have the capacity of interconnects, but the limited throughput may be sufficient for short periods of time.


Architects also need to understand when to use different network topologies. Some common topologies are as follows:


Mirrored topology. In this topology, the public cloud and private on-premise environments mirror each other. This topology could be used to set up test or disaster recovery environments.


Meshed topology. With this topology, all systems within all clouds and private net-

works can communicate with each other.


Gated egress topology. In this topology, on-premises service APIs are made available to applications running in the cloud without exposing them to the public Internet.


Gated ingress topology. With this topology, cloud service APIs are made available to applications running on premises without exposing them to the public Internet.

Gated egress and ingress topology. This topology combines gated egress and gated

Ingress.




Handover topology. In this topology, applications running on premises upload data

to a shared storage service, such as Cloud Storage, and then a service running in GCP consumes and processes that data. This is commonly used with data warehousing and analytic services.


Depending on the distribution of workloads, throughput and latency requirements, and topology, an architect may recommend one or more of three options supported in GCP.


Hybrid-Cloud Implementation Options

Hybrid-cloud computing is supported by three types of network links.

■ Cloud VPN

■ Cloud Interconnect

■ Direct peering

Each of these options has advantages that favor their use in some cases. Also, there may be situations where more than one of these options is used, especially when functional redundancy is needed.


Cloud VPN

Cloud VPN is a GCP service that provides virtual private networks between GCP and on-premises networks. Cloud VPN is implemented using IPsec VPNs and supports bandwidths up to 3 Gbps.


Data is transmitted over the public Internet, but the data is encrypted at the origin gateway and decrypted at the destination gateway to protect the confidentiality of data in transit. Encryption is based on the Internet Key Exchange (IKE) protocol.


Cloud Interconnect


The Cloud Interconnect service provides high throughput and highly available networking between GCP and on-premises networks. Cloud Interconnect is available in 10 Gbps or 100 Gbps configurations when using a direct connection between a Google Cloud access point and your data center. When using a third-party network provider, called a Partner Interconnect , customers have the option of configuring 50 Mbps to 10 Gbps connections.

The advantages of using Cloud Interconnect include the following:


■ You can transmit data on private connections. Data does not traverse the public

Internet.

■ Private IP addresses in Google Cloud VPCs are directly addressable from on-premises devices.

■ You have the ability to scale up Direct Interconnects to 80 Gbps using eight 10 Gbps direct interconnects or 200 Gbps using two 100 Gbps interconnects.

■ You have the ability to scale up Partner Interconnects to 80 Gbps using eight 10 Gbps partner interconnects.


A disadvantage of Cloud Interconnect is the additional cost and complexity of managing a direct or partnered connection. If low latency and high availability are not required, then using Cloud VPN will be less expensive and require less management.


An alternative to Cloud Interconnect is direct peering.


Direct Peering

Network peering is a network configuration that allows for routing between networks. 


Direct peering is a form of peering that allows customers to connect their networks

to a Google network point of access. This kind of connection is not a GCP service—it is a lower-level network connection that is outside of GCP. It works by exchanging Border Gateway Protocol (BGP) routes, which define paths for transmitting data between networks. It does not make use of any GCP resources, like VPC firewall rules for linking networks: interconnect, VPN, and direct peering. 


Interconnects provide high throughput, low latency, and high availability. VPNs are a lower-cost option that does not require managing site-to-site connections, but throughput is lower. A third, not generally recommended option is direct peering. 



This is an option when requirements dictate that the connection between networks be at the level of exchanging BGP routes.


Load Balancing

Load balancing is the practice of distributing work across a set of resources. GCP provides five different load balancers for different use cases. 


To determine which load balancer is an appropriate choice in a given scenario, you will have to consider three factors.


■ Is the workload distributed to servers within a region or across multiple regions?

■ Does the load balancer receive traffic from internal GCP resources only or from external sources as well?

■ What protocols does the load balancer need to support?


The answers to these questions will help you determine when to use each of the

five types:


■ Network TCP/UDP

■ Internal TCP/UDP

■ HTTP(S)

■ SSL Proxy

■ TCP Proxy



Both TCP and UDP are protocols used for sending bits of data — known as packets — over the Internet. They both build on top of the Internet protocol. In other words, whether you are sending a packet via TCP or UDP, that packet is sent to an IP address.


Hypertext Transfer Protocol Secure is an extension of the Hypertext Transfer Protocol. It is used for secure communication over a computer network.


SSL proxy is a transparent proxy that performs SSL encryption and decryption between the client and the server.


SSL Stands for secure sockets layer. Protocol for web browsers and servers that allows for the authentication, encryption and decryption of data sent over the Internet.


Regional Load Balancing


The two regional load balancers are Network TCP/UDP and Internal TCP/UDP. Both work with TCP and UDP protocols as their names imply.


Network TCP/UDP 

The Network TCP/UDP load balancer distributes workload based on IP protocol, address, and port. This load balancer uses forwarding rules to determine how to distribute traffic. Forwarding rules use the IP address, protocol, and ports to determine which servers, known as a target pool, should receive the traffic.


The Network TCP/UDP is a non-proxied load balancer, which means that it passes data through the load balancer without modification. This load balancer only distributes traffic to servers within the region where the load balancer is configured.


All traffic from the same connection is routed to the same instance. This can lead to imbalance if long-lived connections tend to be assigned to the same instance.


Internal TCP/UDP

The Internal TCP/UDP load balancer is the only internal load balancer. It is used to

distribute traffic from GCP resources, and it allows for load balancing using private IP addresses. It is a regional load balancer.

Instances of the Internal TCP/UDP load balancer support routing either TCP or UDP packets but not both. Traffic passes through the Internal TCP/UDP load balancer and is not proxied.


The Internal TCP/UDP load balancer is a good choice when distributing workload

across a set of backend services that run on a Compute Engine instance group in which all of the backend instances are assigned private IP addresses.

When traffic needs to be distributed across multiple regions, then one of the global load balancers should be used.


Global Load Balancing

The three global load balancers are the HTTP(S), SSL Proxy, and TCP Proxy Load

Balancing load balancers. All global load balancers require the use of the Premium Tier of network services.

HTTP(S) Load Balancing


The HTTP(S) load balancer is used when you need to distribute HTTP and HTTPS traffic globally, or at least across two or more regions.

HTTP(S) load balancers use forwarding rules to direct traffic to a target HTTP proxy.

These proxies then route the traffic to a URL map, which determines which target group to send the request to based on the URL.


For example, https://www.example.com/documents

will be routed to the backend servers that serve that kind of request, while https://www.example.com/images would be routed to a different target group.


The backend service then routes the requests to an instance within the target group

based on capacity, health status, and zone.


In the case of HTTPS traffic, the load balancer uses SSL certificates that must be

installed on each of the backend instances.


SSL Proxy Load Balancing


The SSL Proxy load balancer terminates SSL/TLS traffic at the load balancer and distributes traffic across the set of backend servers. After the SSL/TLS traffic has been decrypted, it can be transmitted to backend servers using either TCP or SSL. SSL is recommended.


Also, this load balancer is recommended for non-HTTPS traffic; HTTPS traffic should use the HTTP(S) load balancer.


The SSL Proxy load balancers will distribute traffic to the closest region that has capacity. 


Another advantage of this load balancer is that it offloads SSL encryption/decryption  for backend instances.



TCP Proxy Load Balancing


TCP Proxy Load Balancing lets you use a single IP address for all users regardless of where they are on the globe, and it will route traffic to the closest instance.


TCP Proxy load balancers should be used for non-HTTPS and non-SSL traffic.

GCP provides load balancers tailored for regional and global needs as well as specialized to protocols. When choosing a load balancer, consider the geographic distribution of back-end instances, the protocol used, and whether the traffic is from internal GCP resources or potentially from external devices.


Summary


VPCs are virtual private clouds that define a network associated with a project. VPCs have subnets. Subnets are assigned IP ranges and all instances within a subnet are assigned IP addresses from its range. VPCs can share resources by setting up Shared VPCs. Shared VPCs have one host project and one or more service projects. VPC network peering enables different VPC networks to communicate using a private IP address space, as defined in RFC 1918. 


VPC network peering is used as an alternative to using external IP addresses or

using VPNs to link networks. The flow of traffic within a VPC is controlled by firewall rules. Two implied rules allow all outgoing traffic and deny most incoming traffic. Implied rules cannot be deleted, but they can be overridden by higher-priority rules. When subnets are automatically created for

a VPC, a set of default rules are created to allow typical traffic patterns, such as using SSH to connect to an instance.


Hybrid-cloud networking is the practice of providing network services between an on-premise data center and a cloud. Design considerations include latency, throughput, reliability, and network topology. Hybrid cloud networks can be implemented using Cloud VPN, Cloud Interconnect, and direct peering.


Load balancing is the practice of distributing work across a set of resources. GCP provides five different load balancers: Network TCP/UDP, Internal TCP/UDP, HTTP(S), SSL Proxy, and TCP Proxy Load Balancing. Choose a load balancer based on regional or multiregional distribution of traffic, protocol, and internal or external traffic.



No comments:

Post a Comment

Office hours tomorrow(Tuesday) 5:00pm-6:00pm, 4/26/2021, 5:13 PM, English, 4/26/2021, 5:13 PM

Your assigned language is: English Classroom blog: googleclouduconn.blogspot.com 4/26/2021, 5:13 PM Office hours tomorrow(Tuesday) 5...