Skip to content

Latest commit

 

History

History
188 lines (158 loc) · 9.42 KB

3.4. Networking.md

File metadata and controls

188 lines (158 loc) · 9.42 KB
Raw

Networking

  • To understand difference between Azure Load Balancer and Application Gateway (also a load balancer) it's good to understand OSI layers:
    • 1: The physical layer, 2: The data-link layer, 3: The network layer, 4: The transport layer (Load Balancer), 5: The session layer, 6: The presentation layer, 7: The application layer (Application Gateway)

Azure Traffic Manager

  • Used for geo-routing.
  • It provides DNS-based routing to redirect end user traffic to globally distributed end points.

Azure Load Balancer

  • OSI Layer 4 (TCP & UDP) load balancer that distributes inbound traffic to backend pools (resources) according to rules and health probes.
    • For application-layer processing, see Application Gateway (e.g. SSL off-load)
    • For DNS load balancer (geo-based) see Traffic Manager
  • In actual Azure infrastructure there's always a load balancer.
    • No instance is really created, capacity is always available.
  • Front-end <=> Load balancer => (through load balancing rules and health probs) Back-end pools (includes VM's)
  • Features:
    • Instant scaling to applications
    • Reliability via health checks through health probes.
    • Secure: You can add NAT
      • Network Address Translation: remapping one IP to another in VM.
      • Lowers attack surface of the VMs that otherwise could be attacked directly.
    • Port forwarding => A frontend IP to a port of a back-end inside VNet.
    • Agnostic & transparent => Endpoint is only answered by VM (VM TCP handshakes)
  • There are quick start ARM templates. e.g.: 2 VMs internal load balancer.

Load balancer types

Public load balancer

  • Internet facing
    • Maps public IP+port of incoming traffic <=> private IP+port.
  • E.g. TCP port 80 <=> VM's in web tier subnet in a multi-tiered architecture.
  • Can be placed in front of public load balancer to create multi-tier application.

Internal load balancer

  • Routes traffic between VM's inside private VNet's or VNet's that use VPN access to Azure.
  • Good for:
    • Handling communication within same VNet.
    • Hybrid scenarios: On-prem to VM's in same VNet
    • Multi-tiered applications
      • E.g.: an internal load balancer can receive DB requests that needs to be distributed to back-end SQL servers.
    • Critical (line-of-business) applications.
  • Frontend IP's and VNet's are never directly exposed to internet.
    • Accessed from within Azure or on-prem resources
  • Can be used to create multi-tiered hybrid applications.

Load balancer rules

  • Determine how traffic is distributed to the backend.
  • E.g. you can spread load of incoming web request traffic across multiple webservers.
  • Settings: Port, protocol, IP version, back-end port, backend pool, health probe, session persistence, floating IP (enable/disable).
  • Back-end server pool
    • IP addresses of back-end servers.
    • Back-ends span to two VNet's, must be in same VNet.
  • Front-end port is called Listener and can have SSL certificate.
  • Frontend & backend pool are connected with rules.
    • Front-end is associated with the back-end VM through rule definition.
    • Rules reference to a health probe of target VM.
  • You can set Multiple Frontends
    • Load balance on multiple ports, multiple IP addresses or both.

    1. Default rule with no-back-end port reuse

      • Each rule must have a flow with unique IP+port

      • Multiple rules can distribute flows to same DIP on different ports.

        • DIP = destination IP of VM

      • Example:

        Rule Map frontend To backend pool
        1 💚Frontend1:80 💚DIP1:80, 💚DIP2:80
        2 💜Frontend2:80 💜DIP1:81, 💜DIP2:81

    2. Backend port reuse by using Floating IP

      • If you want to reuse back-end port across multiple rules.

      • Good for: e.g. clustering for high availability, network virtual appliances, and exposing multiple TLS endpoints without re-encryption.

      • Example:

        Rule Map frontend To backend pool
        1 💚Frontend1:80 💚 DIP1:80, 💚DIP2:80
        2 💜Frontend2:80 💜 DIP1:80, 💜DIP2:80

      • Floating IP rule allows backend ports to be re-used.

        • It must be enabled.
        • It's a part of DSR (Direct Server Return)
          • Flow topology
            • Outbound part of a flow is always correctly rewritten to flow directly back to the origin.
            • At platform level LB operates this way.
          • IP address mapping scheme
            • By changing destination IP, you can enable port re-use on same VM.

NAT rules

  • NAT rule ->
    • Must be explicitly attached to a VM (or network interface) to complete the path to the target
  • Load balancing rule
    • VM is selected from the back-end address pool or VMs
  • 📝 You would use NAT rule when you have 1 backend server or you know which backend server to get to and load balancing rule when you want to load balance to multiple backend servers.

Session persistence

  • 📝 Provides stickiness to same VM.
  • 📝 A session is a 5-tuple hash of: Source IP, source port, destination IP, destination port (public port), protocol (optional).
  • Settings
    • When adding a rule you can select only client IP or client IP + protocol.
    • Idle timeout: Default: 4 min, same server response via HTTP(S)/TCP sessions but no guarantee that connection is maintained.

Health probe

  • Allows resilience and scalability.
  • The health probe dynamically adds or removes VMs from the load balancer rotation based on their response to health checks.
  • Types:
    • HTTP: HTTP 200 => healthy (timeout : 31 seconds)
    • TCP: If connection is accepted / refused
    • Guest probe: Runs inside VM, not recommended
  • Standard SKU sends health probe status as metrics through Azure Monitor.

A high availability ports (HA ports)

  • Is a variant of a load balancing rule for internal load balancers.
  • Single rule to load-balance all TCP and UDP flows that arrive on all ports of an internal load balancer.
  • Non floating: Cannot add more rules.
  • Floating: can have same back-end instance or multiple back-ends.

Pricing

  • SKU's: Standard & Basic
  • New applications should use Standard.
    • More flexible & larger backend pools
    • Outbound rules (public IP, NAT, HTTPS), SLA is available only in Standard.
    • When back-end pool probes down
      • Standard allows TCP connections to continue
      • Basic terminates all connections.
  • Basic is free & subset of Standard.
    • HA ports are not available.
  • Not mutable, requires re-deploy.

Azure Application Gateway

  • Application Delivery Controller (ADC) as a service
  • Web traffic load balancer at Layer 7 – Application as opposed to Load Balancer that operates at Layer 4 – TCP and UDP
  • Application gateway can be configured as
    • Internet-facing gateway
    • Internal-only gateway
    • Combination of both.
  • Components
    • Frontend IP Configuration <=> Application Gateway (has WAF and is L7 LB) <=> Listener (through rules) => Backend Server Pool
    • Frontend IP configuration : Traffic-facing port
    • Backend server pool. The list of IP addresses of the backend servers.
      • The IP addresses listed should either belong to the virtual network subnet or should be a public IP/VIP.
      • Every pool has settings like port, protocol, and cookie-based affinity.
    • Listener : Front-end configuration of the gateway.
      • has a front-end port, a protocol (HTTP or HTTPS), and the SSL certificate name (optional).
      • Can terminate SSL (SSL ofloading), so that traffic flows unencrypted to the backend servers.
        • Unburdens from encryption & decryption overhead.
        • To implement this, upload certificate & set it on listener.
    • Rule
      • Binds the listener and the backend server pool
      • Defines which backend server pool the traffic should be directed to when it hits a listener.
      • Health probes can be HTTP, HTTPS, default => default webpage, you can configure custom URL.
      • Path based rules allows routing based on paths
        • /video/* => video backend, /picture/* => picture backend
      • Rules are processed in the order they are listed
    • Web application firewall (WAF).
      • Centralizes security management of web applications = Simpler management.
      • Uses rules from OWASP Core Rule Set:
        • Protection against: SQL Injection (SQLi), Cross Site Scripting (XSS), Local File Inclusion (LFI), Remote File Inclusion (RFI), PHP Code Injection, Java Code Injection, Shellshock, Unix/Windows Shell Injection, Session Fixation, Scripting/Scanner/Bot Detection, Metadata/Error Leakages
      • You can deselect rules or disable the firewall.
    • Sizing

      • 3 SKU's

        Average back-end page response size Small Medium Large
        6KB 7.5 Mbps 13 Mbps 50 Mbps
        100KB 35 Mbps 100 Mbps 200 Mbps

      • Instance count: Ensures availability: 💡 Min 2 recommended for production

    • You can configure more than one web site on same instance
      • ❗ Up to 20 web sites.
      • Each website is directed to its own backend pool of servers.
      • Implementation: 2 backend server pools, 2 listeners (type of multi-site), 2 routing rules.
    • Other features:
      • Redirection: One port to other port => enables HTTP => HTTPS and more (ex. external site
      • Session affinity: Keep a user session on the same server
      • Other features: WebSockets & HTTP/2 traffic, rewrite HTTP headers